Codex内容生产系统怎么搭建？我给乐行库整理出来的方案，不是准备一个万能写作Prompt，而是把内容生产串成一条可以重复执行的流程：记录真实工作、分析选题、人工确认、按规则写作、发布前检查，再把文章放回专题和知识库。
今天这套系统已经实际运行了一遍。一份今日记录先被拆成三个主题，确定优先级以后，再分别完成文章写作。它现在还不是完全自动化的“内容工厂”，但已经解决了以前最麻烦的问题：每天不用再对着空白页面想写什么。
本文目录
我为什么要搭建Codex内容生产系统
以前使用AI写文章，最容易做的事情就是直接发一句：“帮我写一篇关于Codex的文章。”
这样当然能生成正文，但它不知道网站长期服务谁，不知道哪些事情是我真正做过的，也不知道网站已经写过什么。
结果通常有两个。要么文章很空，像把公开资料重新整理了一遍；要么什么都想讲，网站定位、Prompt、自动化和SEO全部塞进同一篇文章。
我后来发现，问题不是AI不会写，而是我没有给内容生产建立上游和下游。
上游缺少真实素材和选题判断，下游缺少发布检查、专题规划和经验沉淀。只盯着中间的“生成正文”，无论Prompt写得多长，都很难形成稳定内容。
内容来源从今日记录开始
乐行库的内容生产不是从关键词工具开始，而是从今日记录开始。
每天工作结束后，我会记录今天真正完成了什么、遇到了什么问题、用了什么方法、得到了什么判断，以及还有哪些问题没有解决。
这一步只记录事实，不急着写文章，也不需要故意总结出一个漂亮观点。
例如，今天的记录里写了三件真实发生的事情：重新整理乐行库的Codex框架，发现多个文件职责重复，以及继续梳理Codex每天工作的机制。
这些内容看起来只是普通工作笔记，但它们比临时找来的热门关键词更适合成为文章素材。因为问题真的遇到过，调整也真的做过，写出来才有经验感。
今日记录不是日记，而是内容生产系统的原始素材库。
Codex先分析选题，不直接写正文
今日记录完成以后，Codex不会马上开始写文章，而是先进入选题分析。
每件事情都要判断几个问题：它是否解决了真实问题，是否获得了新的经验，是否符合网站定位，是否有人可能搜索，以及能不能长期帮助读者。
如果一件事情只是突然冒出来的想法，没有测试，也没有结果，就先保留，不急着发布。
如果一条记录同时包含多个问题，还要继续拆分。今天整理Codex框架这件事，就被拆成了三个主题：
- 为什么Codex应该是一套工作流程，而不是一堆Prompt。
- Codex项目中的不同文件应该怎样划分职责。
- Codex内容生产系统应该怎样搭建。
这三个主题来自同一次实践，但分别解决不同问题。把它们硬塞进一篇文章，内容看起来很完整，搜索意图反而会变得模糊。
为什么选题完成后必须停下来
不是所有值得写的内容都要在当天完成。
我会根据经验是否真实、问题是否已经解决、用户是否需要，以及对网站长期价值有多大，对选题进行排序。
今天刚完成、结论明确、能够形成真实案例的内容优先处理；只有想法但还没有实践的内容，先进入待写或者继续观察。
选题分析完成以后，Codex必须停止，等待我确认。只有收到“开始写”或者“写第一篇”以后，才进入写作阶段。
这个确认节点看起来会降低自动化程度，但它能避免一个更大的问题：AI分析出几个主题以后，不考虑网站计划，一口气全部写完。
对于内容网站来说，决定写什么比快速生成正文更重要。这个判断目前仍然应该掌握在人手里。
写作阶段按需调用规则和知识库
选题确认以后，Codex才开始读取写作阶段需要的文件。
网站定位负责限制文章方向；写作规则负责语气、结构、真实性和HTML格式；SEO规则负责搜索意图、标题、关键词、标签和内链；知识库则根据文章主题按需调用。
例如，写Codex内容工作流时，需要参考AI工具知识库和网站运营知识库，但没有必要读取WordPress故障处理或者联盟营销资料。
知识库也不能代替自己的实践。它只能帮助补充背景、统一术语和避免明显错误，文章真正的过程和结论仍然要来自当天的工作。
我现在不会让Codex每次写作都读取所有资料。读得越多不一定越准确，无关文件太多，反而容易把文章带到其他主题上。
发布前检查为什么要单独执行
文章写完并不代表可以发布。内容系统还需要一个独立的质量检查环节。
发布前，我会重新检查：
- 文章是否符合网站定位。
- 标题和正文是否解决同一个搜索问题。
- 经验、过程和结论是否真实。
- HTML能否直接粘贴进WordPress。
- 文章是否存在明显的AI味和模板味。
- 分类、标签和内链是否准确。
- 图片是否真正帮助读者理解内容。
如果发现问题，Codex不只给出修改建议，而是直接调整正文，最后重新输出可以发布的版本。
把写作和检查分开以后，文章更容易保持聚焦。写作阶段负责把事情讲清楚，检查阶段负责发现重复、夸张、格式和SEO问题，两者不用在同一步里互相干扰。
文章发布后还要回到专题和知识库
单篇文章发布以后，内容生产还没有结束。
它需要加入对应栏目和专题，并与相关内容建立内链。新的实践如果补充了旧文章，也应该优先更新原文，而不是重复发布一篇相似内容。
这次产生的三篇文章都属于“Codex内容工作流”专题。第一篇解决工作流程认知，第二篇解决文件分工，这一篇则负责说明整个内容生产过程。
以后继续测试今日记录、选题分析、自动运行、AGENTS.md和Skills时，新文章都可以加入这个专题。这样网站积累的不是几篇孤立内容，而是一套能够持续扩展的经验体系。
真正稳定的内容系统应该形成一个循环：
- 真实工作产生今日记录。
- 今日记录经过分析产生选题。
- 选题经过确认以后进入写作。
- 文章经过发布前检查。
- 文章进入栏目、专题和内链结构。
- 新的经验继续更新知识库和旧文章。
完成一轮以后，下一天重新从真实工作开始，而不是重新打开关键词工具寻找一个陌生题目。
这套内容生产系统实际运行了一次
今天的处理过程，正好验证了这套系统最基本的闭环。
最开始只有一份工作记录，里面包含框架整理、文件职责重复和每日运行机制等内容。Codex读取网站定位和内容生产系统以后，没有直接生成一篇大而全的文章，而是先拆成多个主题。
确认优先级以后，我先完成“Codex为什么不能只是一堆Prompt”，再处理“Codex项目文件职责怎么划分”，现在继续完成这篇内容生产系统文章。
这个过程至少证明了一件事：一份真实记录可以产生多个独立选题，而且每篇文章都有不同的搜索问题，不需要为了更新而临时编内容。
当然，目前的验证时间还很短。文章后续有没有收录、哪些主题真正有人搜索、系统能不能连续运行几个月，都需要继续观察。我不会因为一天跑通，就把它包装成成熟的自动化系统。
这套系统和Codex官方能力是什么关系
这套编号目录、今日记录格式和发布检查流程，是我根据乐行库实际需求整理的个人方案，并不是OpenAI规定的固定内容生产结构。
OpenAI在Codex使用说明中介绍了通过项目文件夹组织工作，并使用插件和Skills支持可重复流程。
OpenAI的Codex自定义文档则把不同载体的职责分开：AGENTS.md适合保存长期项目指导，Skills适合封装可重复流程，MCP用于连接外部工具和资料。
我现在完成的是内容流程本身，还没有把它完全封装成Skill，也没有实现无人确认的自动发布。等流程经过更长时间验证以后，再决定哪些部分值得自动化。这个顺序更稳，也更符合实际。
搭建内容生产系统，先从最小流程开始
如果重新开始，我不会一次建立大量目录和规则。最小可用版本只需要四样东西：
- 一份明确的网站定位。
- 一份每天持续更新的今日记录。
- 一套选题、写作和发布检查流程。
- 至少一个必须等待人工确认的节点。
先让这个最小流程连续运行，再根据真实问题增加SEO规则、知识库、专题规划和自动化机制。
内容生产系统不是文件越多越好，而是每天都知道素材从哪里来、下一步做什么、做到哪里应该停止。只要这三个问题能够稳定回答，Codex才真正从临时写作工具变成可以长期协作的工作系统。
常见问题
Codex内容生产系统需要很多文件吗？
不需要。刚开始只要明确网站定位、素材来源、基本流程和确认节点即可。出现真实需求以后再增加文件，比一开始建立复杂框架更容易维护。
今日记录和待写文章有什么区别？
今日记录保存当天发生的事实，不提前判断是否值得写；待写文章保存已经通过分析，但暂时没有安排写作的选题。
为什么不能让Codex读取记录后直接写文章？
因为一份记录可能包含多个问题，也可能包含尚未解决的想法。先分析和确认，可以避免主题混乱以及把未验证内容写成经验。
知识库是不是越完整，文章质量越高？
不一定。知识库需要与当前主题相关，并且不能代替真实实践。读取大量无关资料，反而容易让文章偏离核心问题。
这套系统可以完全自动运行吗？
部分重复步骤以后可以尝试自动化，但选题、事实核对和发布目前仍然保留人工确认。是否继续提高自动化程度，需要根据长期运行结果决定。
