宝玉@dotey · X宝玉认为处理错误应先恢复生产（回滚或打补丁，保留日志），再找根因（逻辑错误、边界条件、需求理解偏差），最后根据根因决定如何避免。仅当根因是AI对项目特有约定缺乏了解时（如命名规范、API隐含限制、团队测试规范），才应更新AGENTS.md。其他情况应分别用新增测试用例、重构架构、改进Code Review等方式解决。将一切塞入AGENTS.md会导致文件臃肿、规则繁多，AI反而忽略关键规则。
一点不同意见。
如果是程序发生了错误，那首先这是代码问题，代码问题不一定是 Codex 的锅。你让它再怎么改 AGENTS.md，也不见得下次就不会犯同样的错误。
从软件工程的角度来说，通常处理错误的顺序是这样的：
1）恢复生产 先恢复再找原因，尤其是线上紧急问题。要么回滚要么打补丁，先把生产恢复了再说。但也要注意保留日志和现场，方便后续追查。
2）找根因 错误发生了，找 Root Cause 是必须的。到底是逻辑错误、边界条件没处理、还是对需求理解有偏差？不同的根因，对应不同的解法。
3）避免再次发生 这一步当然没问题，但怎么做有讲究，不是一句更新 AGENTS.md 就能解决所有情况的。
比如边界条件没覆盖，那就加测试用例；代码架构有缺陷，那就重构；Code Review 流程有漏洞，那就改进 review 流程。具体怎么做，要根据根因来定。
那什么情况下才应该更新 AGENTS.md？
当错误的根因是 AI 对项目特有的约定或上下文缺乏了解的时候。 比如项目有特定的命名规范或目录结构约定，代码里看不出来； 比如某些 API 有隐含的使用限制，文档里没写清楚； 比如团队有特殊的测试规范或提交规范。
这些属于项目知识，写进 AGENTS.md 是合理的。
但如果一个 bug 应该靠测试来防，那就写测试；应该靠 Code Review 来防，那就改流程。把什么都往 AGENTS.md 里塞，反而会让它变得大而无用还占 Token，规则越多越不精准，AI 反而更容易忽略真正重要的那几条。