别一出bug就怪AI，也别什么都写进AGENTS.md。这篇讲了如何按软件工程流程正确应对，很实在。
处理AI编程助手（如Codex）产生的代码错误时，应优先恢复生产（回滚或打补丁），再找根因（逻辑错误、边界条件、需求偏差）。根据根因决定解决方案，边界问题加测试用例，架构缺陷重构，代码审查漏洞改进流程。仅当错误根因是AI缺乏项目特有约定（如命名规范、API隐含限制）时才更新AGENTS.md。否则会导致AGENTS.md臃肿、规则失效，AI反而忽略重要规则。
一点不同意见。 如果是程序发生了错误，那首先这是代码问题，代码问题不一定是 Codex 的锅。你让它再怎么改 AGENTS.md，也不见得下次就不会犯同样的错误。 从软件工程的角度来说，通常处理错...
一点不同意见。 如果是程序发生了错误，那首先这是代码问题，代码问题不一定是 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 反而更容易忽略真正重要的那几条。 虎小象 @hx831126 错误发生 → 修复问题 → 追问原因 → 写入 AGENTS.md → 以后 AI 记住规则。 🔗 View Quoted Tweet 💬 0 🔄 0 ❤️ 0 ⚡