为什么你的AI编程代理需要的不仅仅是计划：实战经验分享

转向AI优先开发是一段旅程，我们都在共同学习。我想分享最近经历中获得的苦乐参半的经验，这些经验可能会帮助你避免重蹈我的覆辙。

众所周知的"秘密"

让我们直面房间里的大象。到现在为止，可能有数百万个YouTube视频标题为"让你的编码代理性能提升20倍的超级秘密技巧"。你知道这个技巧，我也知道这个技巧：在markdown文件中创建详细计划，并指导代理逐步执行。

掌握了这些知识后，我和我信赖的代理大军度过了几天不间断的AI编码快乐时光。用AI术语来说，这很了不起——无数的token、千瓦的电力，以及越来越强大的代理和谐工作。这是一段田园诗般的时光，我就像是代理管弦乐团的指挥，或者用一个更温暖的比喻，我的代理就像快乐的金毛寻回犬，一次又一次地把球带回来。

项目增长到了158个源代码文件（不包括测试、文档或构建脚本）。虽然有些文件是从宽松许可证的开源SDK改编而来，但大多数是新的或进行了大量重写。对于一个原型来说，这是一个相当大的代码库。

当事情变糟时

当代码库保持较小时，一切都很顺利。我没有仔细检查每一行代码（“我是训练有素的专业人士——不要在家里这样做”，或者更恰当地说，“不要在工作中这样做”），但计划很可靠，应用程序也完成了它需要做的事情。

但随着代码库的增长，我的代理就像碰撞测试中的测试车一样撞墙了。嗯，至少当代理尽管多次尝试重新提示绕过或穿过那堵墙却毫无进展时，感觉就是这样。当然，我本可以自己深入研究代码，但我懒得阅读和调试一堆"不属于我"的代码，这些代码是用我从未使用过的框架编写的，尤其是在代理多次"偏离计划"修改试图解决问题之后。

来之不易的经验教训

从这次失败（以及我过去的成功）中，我提取了宝贵的见解，这些见解将从根本上改变我处理AI驱动开发的方式。“全力以赴。”

1. 架构优先方法

旧方式：计划 → 执行
新方式：高层计划 → 对于每个模块：

• 开发 module_architecture.md（定义关键数据结构、接口、控制流和设计模式）
• 创建 module_execution_plan.md
• 逐步执行模块计划
• 转到下一个模块

关键见解？我从未真正与我的代理"讨论"过架构。没有这种共同的理解，我无法完全信任基础——这比怀疑单个函数要严重得多。下次，我将共同拥有计划和架构文档，这样即使很多代码不是我写的，我也会觉得这是我的应用程序。

2. 从一开始就制定测试标准

我会提前定义测试标准，并强制代理遵循它们。每一步都需要构建新的回归测试并执行完整的回归测试集。没有这个，代理就会创建随机测试来调试随机问题，要么自动清理这些测试，要么将它们留在不一致的位置。

3. 全面的日志记录策略

我会提前定义日志记录标准，包括详细级别和一些装饰器，以自动记录大量内容，而不会用调试消息使代码膨胀。这将保持代码的可读性和日志的详细性。

回报

采用这种方法，我相信几件好事会发生：

• 更高的能力上限：我的代理将能够解决让它原地打转的棘手问题。通过良好组织的测试和日志，识别和解决复杂问题要容易得多。
• 更好的人工干预点：当我需要介入时，我会确切知道该看哪里。
• 更少的架构问题：拥有良好的架构有助于避免最严重的问题。小问题本来就是小的。

当然，当涉及到生产时，还会有安全审查、代码审查和更彻底的测试。

投入

这不是轻松的工作；需要付出努力。在传统开发中，关键组件的适当架构很容易占用项目时间线的三分之一。这是高技能、高价值的工作——你的首席架构师可能赚得（并且值得）至少五个初级工程师的薪水（这还不包括股权……）。所以这不是免费的奶酪。

但关键是：这种方法将战略工作前置，由你和AI协作完成，将更平凡的积压工作留给AI单独处理。

重新定义协作

当我说"共同拥有架构"时，我并不是说你需要有十年的"架构"经验。我是一名受过培训的工程师，内心是产品人，职业是商人。在编码方面我相当生疏，但我有敏锐的头脑和无尽的好奇心。

在架构方面工作时，我并不孤单。每当我有问题时，无论是关于解决问题的某些选项，还是我们的代码库，或者是开源可比物，我信赖的代理都会在那里为我运行一些背景研究和查询。这是最容易并行化和多任务处理的事情之一，这意味着你从AI中获得最大的杠杆作用。

我们基本上在重新定义劳动分工：人类专注于架构、标准和战略决策，而AI在那些明确定义的边界内处理实现细节。这就是我们设想AI和人类未来的样子——我们希望AI创造工作，帮助倍增人类的能力/速度/生产力。

下一步

在第二部分（当我的繁忙工作允许另一次深度潜水会议时），我将分享这种架构优先方法如何解决实际问题的具体例子，包括产生差异的确切模板和提示。敬请期待。