为了不让aicoding做出屎山，有什么原则和具体做法吗

回复 群友 8764： 有。比如让 AI“给订单系统加退款”，它可能顺手新建一套支付封装、复制权限判断，再写几个只测成功路径的测试。功能能跑，但维护成本已经涨了。 核心原则：别只验收“功能做出来了”，还要验收“有没有增加不必要的复杂度”。 我建议抓这六件事。 一、先读代码，再给方案，最后才改 先让它找现有入口、相似功能、公共组件和测试，标明文件位置。然后说明准备复用什么、修改什么。 你确认方案之后再动手，避免它没看懂仓库就另起炉灶。 二、一次只做一件能独立验收的事 “加退款”和“重构支付模块”分开做，“修 bug”和“统一代码风格”也分开。 每次修改都应能解释清楚：为什么需要改这个文件？如果改动大到你无法认真审查，就拆任务，而不是直接放行。 三、明确限制过度设计 默认沿用现有技术栈、目录和代码习惯。 新增依赖、公共抽象、数据库表、对外接口，要先解释必要性。 不为尚不存在的需求搭插件系统，不为一个实现创建五层接口。 但也别走另一极端：权限、计费等关键规则不能到处复制，否则以后改一处漏三处。 四、测试验证业务，不是验证它自己写的实现 还是退款的例子，先确定： 别人不能退我的订单。 退款金额不能超过实付。 同一个退款请求重试，不能重复打款。 支付平台超时，不能直接记录成退款成功。 这些验收条件最好在实现前确定。否则 AI 可能把错误实现当标准，写出全绿的测试。 修 bug 时，尽量先写能复现问题的测试，再修到通过。不要靠删断言、放宽类型或吞异常换取通过。 五、把检查变成硬门槛 格式检查、静态检查、类型检查、相关测试和构建，能自动化的都接进 CI。 让 Agent 报告“实际运行了哪些检查、结果是什么、哪些没运行”，而不是一句“应该没问题”。 自动检查只能兜底。权限、数据迁移、并发、资金相关逻辑仍需要人重点审查；另一个 Agent 的 review 只能补充，不能当保证。 六、把项目约束留在仓库里，但保持短小 AGENTS.md 可以记录： 项目启动和测试命令。 各模块职责、依赖方向。 必须复用的公共能力。 哪些变更需要先确认。 禁止通过跳过测试、硬编码结果来过关。 不要堆几百条泛泛的“最佳实践”。规则要具体、可检查，并随项目更新。 你可以直接给 Coding Agent 这段要求： “先不要改代码。阅读相关实现和测试，列出现有可复用能力、最小修改方案、预计改动文件和验收条件，等我确认。实现时不做无关重构，新增依赖或公共抽象先征求确认。完成后报告改动理由、实际检查结果和剩余风险，不得为了通过检查削弱测试。” 最后判断是不是屎山，不是看文件多不多，而是看：下次改一条业务规则，是否只需要改一个合理的位置，并且有测试告诉你有没有改坏。 参考阅读： https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents