Codex项目文件职责怎么划分？我这次整理乐行库框架后，确定了一条最实用的原则：一个文件只负责一类问题。网站定位决定写不写，内容系统决定先写什么，写作规则决定怎么写，知识库提供资料，今日记录保存事实。
之前的问题并不是文件太少，而是相同规则被写进多个地方。一条要求修改以后，其他文件没有同步，Codex就可能同时读到两种说法。文件看起来很完整，实际维护起来却越来越乱。
本文目录
Codex项目文件为什么容易出现职责重复
刚开始搭建框架时，我担心规则不够完整。只要想到一条重要要求，就会顺手写进当前文件。
比如“文章必须符合网站定位”，可能同时出现在网站定位、写作规则和内容生产系统里；“选题完成后不要直接写正文”，又可能被重复写进入口Prompt、选题系统和更新规则。
这些要求单独看都没有错，但重复以后会产生两个实际问题。
第一个是维护成本。以后修改网站定位，不能只改一个文件，还要检查其他文件里有没有旧版本。
第二个是规则冲突。不同文件对同一件事给出不同要求时，Codex只能根据当前上下文临时判断，输出自然很难长期保持稳定。
上一篇文章讨论的是为什么Codex需要完整工作流程。这次继续往下整理，我真正解决的是更具体的问题：工作流程里的每类文件究竟应该负责什么。
划分文件职责前，先写出一句话说明
我现在判断一个文件是否应该保留，首先会问：能不能用一句话说明它负责什么？
如果一个文件同时负责网站定位、SEO标题、文章写作和发布检查，那它基本已经失去边界了。以后遇到问题，既不知道应该在哪里修改，也不知道哪一份文件才是最终标准。
这次整理以后，我给乐行库现有目录重新确定了主要职责：
- 00 使用说明：保存任务入口、常用Prompt和知识库维护说明。
- 01 网站定位：决定网站服务谁、长期写什么，以及哪些内容不能写。
- 02 写作规则：规定选题确认以后，文章应该怎么写、怎么输出。
- 03 内容生产系统：负责分析今日记录、发现选题、判断优先级和规划专题。
- 04 SEO规则：负责搜索意图、关键词、标题、内链、标签和网站结构。
- 05 网站资料：沉淀AI工具、网站运营、SEO和WordPress等长期知识。
- 07 今日记录：保存当天真正完成、遇到和解决的事情。
- 09 项目规划：保存网站长期目标、发展方向和后续项目。
这些编号只是我自己的整理方法，并不是Codex官方规定。编号的作用是方便查找，真正重要的是不同目录之间不要互相抢职责。
网站定位和写作规则怎么区分
这两个文件最容易混在一起。
网站定位解决的是“该不该写”。例如，乐行库服务的是想利用AI建立互联网收入的人，所以纯AI新闻、没有实践的赚钱项目和与网站方向无关的流量词都不应该写。
写作规则解决的是“确定要写以后，应该怎么写”。它负责文章语气、真实性、结构、WordPress HTML和发布要求。
我的处理方法是，写作规则可以简短引用网站定位，但不再复制整套定位内容。以后网站方向发生调整，只修改定位文件，不需要到多个地方同步替换。
内容生产系统和写作规则怎么区分
内容生产系统决定“今天写哪篇”，写作规则决定“这一篇具体怎么写”。
例如，Codex读取今日记录后，发现今天处理了文件职责重复的问题。它需要判断这件事是否符合网站定位、有没有真实经验、能不能成为独立文章。这属于内容生产系统。
等我确认开始写以后，文章采用什么语气、如何安排段落、是否加入FAQ、怎样输出HTML，才属于写作规则。
以前没有分清这两个阶段时，Codex容易在选题分析完成后直接开始写正文。现在我会把“分析”和“写作”拆开，并在中间保留人工确认。
知识库和今日记录不能混在一起
今日记录保存当天发生的事实，知识库保存未来能够反复调用的内容。
比如“今天重新整理了Codex框架，发现几个文件职责重复”，应该先进入今日记录。经过实际处理以后，得到“一份文件只负责一类问题”的判断，才有机会沉淀成长期经验。
AI工具知识库可以记录工具的定位、使用场景和真实测试；网站运营知识库可以沉淀内容规划、数据分析和网站变现经验。但是“文章必须先分析搜索意图”属于执行规则，应该放在SEO规则里，而不是知识库。
说白了，知识库保存的是“以后可以用什么”，规则文件保存的是“每次必须怎么做”。两者混在一起，知识越多，Codex反而越难找到真正需要执行的内容。
普通文件放进项目后，Codex会自动读取吗
不能默认认为会自动读取。把一批Markdown文件放进项目目录，只是完成了资料整理，并不代表Codex会在每个任务中主动打开全部文件。
我目前的处理方式，是在任务入口中明确写出需要读取的目录。例如分析今日选题时读取网站定位、内容生产系统和最新今日记录；确认写作后，再读取写作规则、SEO规则和相关知识库。
OpenAI官方的Codex自定义文档对不同载体的职责也有明确区分：AGENTS.md适合保存需要长期生效的项目指导，Skills适合封装可重复执行的工作流程，MCP用于连接外部工具和资料。
这也提醒了我一件事：乐行库的编号目录是内容管理结构，不是Codex自动读取机制。以后如果想减少每次手动指定文件的工作，还需要用简洁的AGENTS.md提供读取路线，或者把已经稳定的流程整理成Skill。
Prompt在文件系统里应该负责什么
我现在更倾向于让Prompt只负责启动任务，而不是重复保存全部规则。
例如每天工作结束以后，入口Prompt只需要告诉Codex读取哪些文件、完成什么任务、输出哪些结果，以及执行到哪里必须停止。具体判断标准仍然保存在对应规则文件中。
这样调整以后，修改SEO规则不需要重写所有Prompt，更新网站定位也不需要检查每个任务入口。Prompt只是把Codex带到正确的位置，真正需要长期维护的是项目文件。
新增文件前，我会先检查五个问题
- 这个文件能不能用一句话说明职责？
- 里面的内容是否已经由其他文件负责？
- 它保存的是事实、规则、流程、知识，还是长期规划？
- 修改它时，是否还要同步修改多个文件？
- Codex在什么任务中才需要读取它？
如果无法回答这些问题，我不会急着新建文件，而是先判断内容能否归入现有目录。
文件越多并不代表系统越专业。真正清楚的项目结构，应该让人和Codex都能快速判断：遇到什么问题，应该去哪里找答案。
这次调整以后得到的结果
重新划分职责以后，乐行库的Codex框架还没有完全实现自动运行，但至少解决了规则重复和修改困难的问题。
现在，长期方向回到网站定位，表达要求回到写作规则，执行顺序交给内容生产系统，真实素材保存在今日记录，经过验证的经验再进入知识库。
项目文件的价值不在数量，而在边界。边界越清楚，后面修改规则、增加内容和扩展流程时，付出的维护成本就越低。
下一步，我会继续测试怎样让Codex更准确地找到对应文件，以及哪些项目规则适合放进AGENTS.md，哪些重复流程适合整理成Skill。等实际运行稳定以后，再继续记录结果。
常见问题
Codex项目文件是不是越多越好？
不是。每个文件都应该有明确用途。如果两个文件长期处理同一类问题，优先考虑合并或者重新划分职责。
普通Markdown文件会被Codex自动读取吗？
不能默认认为会自动读取。可以在任务中明确指定文件，或者使用AGENTS.md、Skills等Codex支持的机制提供项目指导和流程入口。
网站定位可以直接写进写作规则吗？
可以保留简短引用，但不建议复制整套定位内容。否则定位调整以后，很容易留下多个不同版本。
什么内容适合放进知识库？
适合保存已经整理、未来能够反复调用的知识和真实经验。当天发生的事情先进入今日记录，尚未验证的想法不要直接包装成长期知识。
AGENTS.md和普通规则文件有什么区别？
AGENTS.md适合保存Codex在项目中需要长期遵循的指导；普通规则文件可以承载更详细的专项内容，但需要通过任务指令或其他流程明确调用。
