正在打开每日关注
正在打开每日关注
内容指出 Sol 类模型常把小改动做成框架，并主张用 AGENTS.md 约束实现范围与复杂度。
Codex Sol's overengineering problem is real. Small task, 3x the code you asked for. This AGENTS.md approach fixes it 👇
How to stop GPT-5.6 Sol from overengineering your codebase. Sol-class models don't write wrong code. They write too much code. You ask for a config change, you get a framework. You fix a bug, you get an adapter layer. Tests pass, CI green, looks professional. Then you touch one thing next week and there are four layers between you and the logic. Fix below.👇
是什么 这不是对某个仓库的技术拆解，而是对 Sol 类代码代理行为的批评：任务本身很小，产出的代码却显著膨胀，最终形成“框架—适配层—业务逻辑”的间接链路。原文用配置修改、修复 bug 和“下周再改一处”作为例子，强调维护成本才是隐藏代价。
核心设计 内容提出将 AGENTS.md 作为仓库级约束入口，把“完成任务”从能运行、测试通过，进一步定义为只改必要范围、遵循既有结构、拒绝无需求的抽象，并让代理解释新增层的必要性。这里能确认的是这一治理方向；引用中没有给出完整规则文本，因此不能把某套具体模板当成已验证方案。
关键洞察 它抓住了 Agent 工程的评价错位：代码正确性和 CI 绿灯并不等于变更质量。复杂度、认知负担、未来修改路径和审查成本同样应成为输出指标。对资深工程师而言，最有价值的提示不是让模型“写得更专业”，而是明确任务边界与不应引入的机制。
边界与风险 AGENTS.md 只能提供约束，不能替代架构判断、差异审查和回归测试；规则过于绝对也可能阻止必要的重构。实际落地应结合任务规模、现有设计和风险分级验证，持续检查新增代码是否真正降低长期成本。