如何防止Codex写代码的时候过度工程化？约束写进项目的AGENTS.md

用 Codex 写代码时，最容易踩的坑之一就是过度工程化。

很多人用Codex开发功能时会发现：本来只想加一个小功能，它却默默干了好几倍的工作量。原本改几行代码就能解决的事，它会拆成独立的小模块，甚至做成一个个单独的小应用；测试也会写得又长又全，远超实际需要。X上也有不少开发者吐槽同样的问题，有人甚至遇到过生产代码几千行、测试代码十几万行的极端情况。

这其实是典型的过度工程化。新的模型被训练得追求完美、避免出错，会主动把事情做完整、做稳妥；再加上一次授权后它会持续推进，不太会自己喊停。结果就是范围悄悄膨胀，代码变重，维护成本上升。

应对的方法其实很直接，核心就三个最小。

有网友总结了一句很实用的提示词：“最小实现，最小修复，最小测试”。意思是只做能完成当前需求的最小改动，优先改已有代码，不新建不必要的文件和抽象；只修当前问题，不顺手重构周边；只加能验证本次改动的最少量测试，不写全面测试。

更稳妥的做法是把这类约束写进项目的AGENTS.md里，或者每次明确要求“先确认范围再动手，做完就停”。先用计划模式让它输出方案，你审核过再执行，也能有效压住范围。

真正省心的用法，是用清晰的边界告诉它：做到什么程度就够了。可以把它写得更强硬、更具体一点，直接放进对话或 AGENTS.md：

严格遵守以下原则，任何情况下不得违反：
1. 最小实现：只做能完成当前需求的最小改动。优先修改已有代码，禁止为了“更好”而新建文件、新模块、新抽象层或独立小应用。2. 最小修复：只修当前问题，不顺手重构周边代码，不添加防御性代码（除非我明确要求）。3. 最小测试：只添加能验证本次改动的最少量测试。禁止写全面单元测试、边界测试或额外测试基础设施。如果现有测试已能覆盖，就不要新增。4. 先确认范围再动手：如果发现需要做超出需求的事，先停下来告诉我具体是什么、为什么必要，等我确认后再继续。5. 完成后立即停止：做完就停止，不要主动扩展、优化或“顺便”做其他事情。