@mitchellh: 我的经验法则是，任何由AI代理生成的超过约1500行的diff都太大了，表明问题需要分解。

我的经验法则是，任何由AI代理生成的超过约1500行的diff都太大了，表明问题需要分解。以下是我现在进行功能开发的一般模式： 1. 尝试实现整个功能，仅给予松散指导。我称之为“draw the owl”提示，源自那个梗。期望得到垃圾，你确实会得到垃圾。 2. 如果diff少于1500行，就审查并按正常方式迭代。如果diff超过1500行，则提示代理将问题分解为原子化、增量式、可审查的任务。同时，你自己也这样做。 3. 代理往往会将这些任务设置得过于具体，完全契合它们已经解决的问题形态。你需要将其塑造成正确的通用形态。完成这一步。 4. 启动新的代理来处理那些增量任务（尽可能并行化）。应用相同的规则。 5. 在某个节点，再次使用“draw the owl”提示。最终，你会达到低于可审查阈值的状态。 这一直在生成质量稳定、可维护、可审查的代码块，并且可以很好地交接——要么直接合并，要么进行人工优化。 而借助最新的前沿模型在xhigh思考模式下，这些操作都足够慢，以至于你通常可以同时运行多个代理，同时积极审查其他代理的成果或处理自己的任务。 HITL（人在回路中）代理仍然非常重要，尤其是在功能开发中。功能开发会触及用户界面、API等人类边界。全新的东西还可能引入架构上的病态问题，破坏期望的不变量（这些不变量应该体现在规范或测试中，但我们也做不到完美！）。 我知道很多前沿的代理话语都在谈论“循环”和代理不断驱动代理。我也做了一些这方面的工作（稍后报告）。但单就日常把事干成的工作而言，这是目前我最满意的模式。