一点不同意见。 如果是程序发生了错误，那首先这是代码问题，代码问题不一定是 Codex 的锅。你让它再怎么改 AGENTS.md，也不见得下次就不会犯同样的错误。 从软件工程的角度来说，通常处理错...
TL;DR · AI 摘要
文章指出代码错误应优先修复而非依赖AI规则更新，强调软件工程中恢复生产、根因分析和预防措施的正确流程。
核心要点
- 优先恢复生产，再分析错误原因。
- 错误根因不同，对应的解决方式也不同。
- AGENTS.md 应用于项目特定知识，而非通用错误修复。
结构提纲
按章节快速跳转。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- 软件工程中的错误处理
- 处理顺序
- 恢复生产
- 找根因
- 避免再次发生
- AGENTS.md 的使用
- 适用于项目特定知识
- 不适用于通用错误修复
金句 / Highlights
值得收藏与分享的关键句。
先恢复生产再找原因，尤其是线上紧急问题。
错误的根因不同，对应的解决方式也不同。
AGENTS.md 应用于项目特有的约定或上下文，而非通用错误修复。
宝玉 on X: "一点不同意见。 如果是程序发生了错误，那首先这是代码问题，代码问题不一定是 Codex 的锅。你让它再怎么改 AGENTS.md，也不见得下次就不会犯同样的错误。 从软件工程的角度来说，通常处理错误的顺序是这样的： 1）恢复生产" / X
宝玉
@dotey
一点不同意见。 如果是程序发生了错误，那首先这是代码问题，代码问题不一定是 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
15h
错误发生 → 修复问题 → 追问原因 → 写入 AGENTS.md → 以后 AI 记住规则。
7:16 AM · Jun 20, 2026
19K
Views
4
2
42
1
11
0
3
103
8
83
Read 42 replies