大家都是怎么深度使用 Codex 的？我现在让它自己沉淀项目经验，但感觉还不够体系化

[Rliey]

最近一直在用 Codex 辅助开发项目。

我目前的用法大概是：指定一个项目目录，然后让它直接看代码、改代码、实现功能、修 bug 。除此之外，我也尝试让 Codex 在项目里自己沉淀一些经验，比如项目结构说明、开发规范、业务流程、常见问题、接口约定之类的内容。

简单说，就是希望它不要每次都像一个新来的开发，而是能逐渐积累这个项目的上下文。

这种方式确实有用，但我现在感觉还不够体系化，主要有几个困惑：

1. 项目经验到底应该沉淀在哪里？ README 、AGENTS.md 、docs 、rules ，还是单独建一个 AI 知识库？
2. 哪些内容适合让 Codex 自己总结，哪些内容必须人工整理？
3. skill 一般适合沉淀什么能力？比如代码审查、接口生成、SQL 检查、测试生成、排查日志？
4. MCP 在真实项目里大家都怎么用？会接数据库、Git 、Issue 、文档系统、浏览器吗？
5. 对 Java / Spring Boot 这种后端项目，有没有比较推荐的 Codex 工作流？
6. 怎么避免它沉淀出来的经验过时、错误，或者和真实代码不一致？

我现在的目标不是让它完全自动开发，而是希望它更像一个熟悉项目规范的开发助手：

能理解项目结构、遵守代码风格、知道常见业务约定，减少我每次重复解释项目背景的成本。

想请教一下大家真实使用中的经验：

• 你们会不会专门维护给 AI 看的项目说明文件？
• 这些文件一般写到什么粒度？
• skill / MCP 有没有真正提升效率？
• 项目经验是人工维护，还是让 AI 自己总结后再人工审核？
• 有没有踩过什么坑？
• 有没有一套比较舒服、稳定的 Codex 工作流？

感谢各位。

[lujiaosama]

SPEC 文档，设计文档就是专门给 AI 看的项目说明文件。SUPERPOWER 这类技能虽然重，对于模块级别的需求还是有正向作用的。项目经验只能是人去掌控和沉淀，AI 只负责发散思维补充细节，最后总结。没啥稳定舒服的说法，LLM 一个降智你叠什么猴戏都不好使。

[HeStudy]

我的做法是，弄一个单独文件夹把规范整理进去，比如技术栈，自定义组件，状态码规范等等，然后把 agent.md 文件当做路由来用，在里面写清楚每个文件对应的职责的位置。再就是最重要的，每次让它写代码前，都先让它写实施计划，这一步可以校验你的 agent.md 里的规范还缺少什么，你 review 一下实施计划，发现有缺少的，就继续补充你的规范文件夹里的内容，然后再让它重新定计划，直到你觉得计划完美了为止，这样几轮下来，你的规范文件夹和 agent.md 基本就是基于你的项目进行深度定制的了

[reliefe]

是这样的，我对 Agent 能完全遵守你的项目已有框架和组件进行开发，抱有悲观态度，因为哪怕是另一个人也不可能完全按照你的想法来。我们基础架构给了标准的 JSON 库和版本，以及各种使用案例，也封装了方法。但是一统计下来实际使用有七八个库，二十几个版本。这还是之前因为 JSON 格式化造成过线上事故，整顿过的情况下。

我们现在是这么用的
1. 首先不会从项目进入，要从上层进入，除非你只有一个项目。但即使你只有一个项目，也不建议这么做。因为这个目录下还可以放工作日志和最新的非代码的要求。
2. 先让 Agent 通过 subagent 搞懂每个项目，再总结起来项目的定位，项目之间的联系，然后再去写每个项目的代码规范。其实所有公司的规范只有一句话：之前怎么弄现在就怎么弄。使用之前用过的框架，之前的代码格式，之前的 commit 格式等。
3. 总结完的信息放到一个 skill 里去，skill 的名字是你们公司的名字或者产品的名字。


把 skill 当成活的东西，每次通过 skill 去做事，都要去维护 skill ，最低也要写个工作日志。
如果一开始没有自动加载 skill 的话，就在目录下的 agent.md 里写上「做任何事之前首先加载 xxx skill 」

这个流程我们公司所有人都在用，通过一个 skill 掌管了四十几个项目，以及项目之外的业务也通过 skill 来做，而且只有这一个 skill 。

也同时推荐给了其他公司，现在反馈都还不错，因此还弄了个 org-altas skill 可以一键来初始化专属 skill 。正在计划把这个开源。

[Rliey]

@lujiaosama
@HeStudy
@reliefe
感谢各位分享，这个思路我大概理解了。
之前我一直是从单个项目目录进去用 Codex ，每次都要重新解释各个项目背景和规范。
你这个从上层 workspace 进入，再让 Agent 先理解多个项目之间的关系，最后沉淀成一个公司/产品级 skill 的方式，我感觉更像是给 Agent 建一套组织级上下文和工作手册。
我准备按这个方向实践一下。我们公司现在对模型辅助开发也还没有形成统一规范，基本还是各个组自己摸索、自己沉淀。所以我先在自己的项目里试试看，把项目结构、代码规范、历史约定、常见坑、工作日志这些东西整理进 skill ，再观察一下实际效果。

[reliefe]

@Rliey

好的，用好了忽悠公司给你们报销，我这有质保的 codex cc 能开专票 :)

[qaq13037]

@reliefe 你说的这个 skill 不就是将 agent.md 从项目层提到了公司层面吗，每次通过 skill 做事，和自动读取 agent.md 去编码，然后遇到未完善的内容回来再更新 agent.md ，这个流程是一样的啊。我没能理解这样做的优点在哪里，真心求问，是不是我的理解有偏差

[clearlight002]

@reliefe 厲害！

[reliefe]

@qaq13037 有相同之处，但又不太一样

1. agent.md 各个 Agent 的规范和文件名都不太一样，不方便跨 Agent 迁移
2. agent.md 过于隐秘，类似 memory 你不知道 agent 在哪记了什么东西。agent.md 也是，可能全局有，可能目录下有。
3. skill 下可以有文档有脚本有 tools ，相比 agent.md 更加灵活
4. skill 可以用 npx skills 在一处管理到处应用。更可以通过 git 在团队之间相互同步。


理论上来说 skill, agent.md, memory 都是给 agent 提供上下文的方案，不同的场景可以选择不同的方案，但我倾向于把一种给优化到极致。

[AdminNB]

1 、AGENTS.md 用来介绍整个项目架构、模块、技术栈，跟他说它去哪里读文档、推荐用什么工具、读 rules ，就把他当成 readme 就行，经验跟着项目走是最方便的，如果多个项目都用到了，可以考虑放到全局
2 、每个项目不同的功能都有自己业务流程以及自己的工具库，这些可以让它自己总结。人工可以对某个业务流程简述，让 ai 去读代码来确定整个业务流程，如果开发文档比较丰富，那么可以人工整理好放到对应的位置进行整理
3 、任何常用的操作都可以封装为 skill ，如果某个功能开发上有固定的流程，那么完全可以封装一个 skill ，让它开发功能的时候调用 skill 。
4 、数据库必定要接，分析代码的时候让它参照现有数据是最好的，如果怕他乱改数据，那么给只读权限，如果有团队的知识库，那么完全可以接入
5 、大多数 Java / Spring Boot 项目业务都比较复杂，你们平时怎么开发的就怎么让 ai 去模仿就行
6 、codex 支持定时任务，比如设置一个每周让它读一遍本周的 git 提交记录，根据提交记录中的内容进行更新沉淀的经验

开发文档很重要，业务流程文档也很重要，如果缺文档，那么只能在开发过程中不断的沉淀，遇到什么就沉淀什么，这样能够变得越来越好用，越来越听话
AI 沉淀的文档一定要看一遍，对不合理的地方可以手动修改，不然 ai 肯定会跑偏

[AdminNB]

@AdminNB 再补充一句，每个人都有每个人的用法，适合自己的才是最好的

[Rliey]

@AdminNB 多谢多谢~ 我先去实践下，理解的大体流程就是：先给项目说明、再给业务流程、再给工具权限、最后让 codex 持续写项目经验，人再去校验 codex 输出的经验是否正确

[kaori]

有个现成的工作流 trellis 可以满足你的要求

[Rliey]

@kaori 多谢分享 我去研究下看看

[AIIsHallucFree]

我都是问模型下一步应该做什么，然后让它给提示词，再接着执行，

[jimx]

@kaori 听你这么一说，我也有用 trellis ，确实感觉有点像，每次做完改完，多会触发复盘沉淀

[auhah]

trellis 好好研究，挺好用的。。别管他开发流程这那的，纯粹当一个渐进式披露的项目知识库就很好用了
你搭建一个项目知识库，什么时候读维护起来很麻烦，还不如直接使用这种做好的框架

[chongdianbao]

关于项目知识都沉淀，可以参考 deepwiki 或者 qoder 的 repo wiki 这些的功能