AI Agent 设计改进：先跑原型再定边界

用 AI 编程确实暴露出了手工编码时从未遇到过的大量问题和挑战。AI Agent 的工作速度远超你的预期——这是优势，但也是隐患。

我们习惯了在实现任何功能之前先和 AI 讨论方案。但我注意到，由于 AI 实际上还没有真正构建这个东西，它在设计阶段和你讨论的边界都是想象中的。你最终会在想象的边界上来回争论，浪费大量时间。更快的方法是让 AI 先实现一个粗糙的初版设计，然后让人类在开发或 QA 环境中实际体验一下，找到感觉，再从那里修订设计。

但这就带来了新问题。AI 可以非常快速地生成一个功能，它会大致告诉你设计是什么样的。但在实践中，你很难真正理解它所描述的细节。有时候我花大量时间追问 AI 设计细节，结果还是不太懂。我甚至不知道该从哪里开始问。

所以我们现在需要思考的问题不仅仅是如 AI 沟通——而是如何让人类大脑快速理解 AI 的设计。简言之：我们需要把 AI 的设计同步到自己的脑子里。

为什么需要同步 AI 的系统设计

在"架构、AI Agent 与产品共情——Robert C. Martin 访谈"中，Bob 大叔指出，AI Agent 写代码缺乏设计感和危机感。我完全赞同。先从设计感说起。

缺乏设计感

AI 产生的系统设计就像是有人不断在同一个设计上打补丁。AI Agent 会先设计出最简单的解决方案，然后一次又一次地往上面打补丁，补上缺失的部分。所以最终设计感觉非常曲折。由于 Agent 也是维护代码的一方，而且未来的 Agent 会获得大量的上下文来工作，这种方式在大多数时候确实不是什么大问题。但问题在于担不起生产环境出问题时的后果——AI 陷入无限循环、就是解决不了，或者耗费大量时间和 token 在那里硬撑。这时候人类就不得不直接去读代码，找出根本原因。但到那时候系统已经有相当程度的复杂性了，人类已经无法理解那些代码了。这就让你陷入两难：

不重构系统——硬着头皮尝试理解 AI 的设计，这会消耗大量时间。

立即重构——这又带着严重破坏系统的风险，而且没有明确的修复方法。

如果这恰好发生在发布前夕，或者客户正在actively运行系统、焦急等待修复的时候，那就令人抓狂了。

缺乏危机感

AI Agent 不领工资、不会被开除、从来不担心系统会不会坏掉。当 AI 做一个设计决策时，唯一的标准就是设计看起来好不好。但我们知道，"好"永远是相对的——每种设计都涉及权衡。AI Agent 似乎看过太多系统设计面试题，以至于它们总是坚持最小化设计，极力避免过度设计。这一点是好的。但然后它们就把设计简化过头了，有时候甚至没注意到其中埋藏的风险。当你提出质疑时，它们会说这只是早期设计，未来问题和如何优化都已经记下来了。

问题就在这里。AI 假设你和它对系统的未来有一份同步的计划。但你没有。它自己其实也没有——因为对 LLM 来说，每一轮对话本质上都是一次新的对话；它下一轮的思考来自会话上下文，而不是来自之前想出这个方案的那个连续思维。所以计划从一开始就发生了漂移。

而且 AI Agent 不会担心那些显而易见的问题——比如过度频繁的 I/O 读写。你指出来，它会说："我知道这个问题，只是不想让设计变复杂"，或者"不，我们不动现有设计——直接在上面打补丁"。

假设驱动设计

有一个方法在这里很有效：假设驱动设计。它分为三轮：

第一轮：与 AI 进行简短、浅层的讨论，然后让它快速实现一个初版设计。

第二轮：告诉 AI 你自己的假设设计。然后问它："通过类比我们两个设计中相似的元素，告诉我我的设计与你的设计有何不同。"对人类大脑来说，"做类比"是我们学习东西最快的方式。

第三轮：一旦你和 AI 在设计上达成同步，并且你完善了自己的版本，让 AI 将系统重构向你的设计方向。

这样做，AI 会列出你设计中的权衡和不足。通过比较你的设计和它的设计之间的差异，你能很快地自己理解系统的设计——同时 AI 也能理解你的想法。

最后那一步也很重要。融入它的反馈，完善你的设计，理想情况下让它将系统重构得更偏向你的实现。因为你的实现才是人类大脑更容易理解的那一个——无论是对未来的你还是对你的队友，这都帮助巨大。

真实案例

下面是我在构建 AI 语音翻译机器人时遇到的一个真实案例。

我最近在做一个 AI 语音翻译机器人。但每个人说的话经过识别 + 翻译 + 语音生成的总时间是各不相同的。完全有可能后说话的人的翻译音频比先说话的人的音频更早完成生成。

所以我需要保证翻译音频的播放顺序。显而易见的答案是：需要一个队列，让后说话的人的翻译音频等待先说话的人的音频。

第一轮：让 AI 快速构建这个功能。它也向我大致解释了设计——说核心是一个 playback-queue。但当我真正打开 playback-queue 之后，我完全无法理解它。设计不必要地复杂。它先建了一个没有等待逻辑的队列，然后在上面打了个等待队列的补丁。接着意识到有些任务可能失败，又打了一个独立的失败处理路径的补丁——完全没有复用之前设计的任何东西。然后它引入了一个指针，不断调整那个指针的位置。一堆补丁之后，系统技术上能跑而且内部一致了——但代码几乎无法阅读。这是 AI Agent 缺乏设计感的教科书案例。

第二轮：没关系。我向它描述了我的假设设计：一个简单的队列，元素携带不同状态，通过这些状态管理等待、跳过和完成。它说它也构建了同样的东西，然后比较了它设计中和我设计中各自的元素。通过这个比较，我也发现了自己设计中的不足。然后让它完善了设计。整个过程大约花了一小时。用老办法，我得一直追问它问题，而且可能还是无法理解它的设计。

第三轮：让它按照我们之前的讨论再构建一版。这次，我真正能跟上它说的每一步了。

同一个人工智能语音翻译机器人。我需要一个计费功能。需求很简单：计量用量，当用户余额用完时，拒绝服务并通知用户。

第一轮：让 AI 快速实现了这个功能。它很快让功能跑起来了，但当它向我解释设计时，我感到有些不对劲。它一直在强调能多快地拒绝服务来控制损失，以及多快地能将账户余额同步回数据库。然后我意识到了：它在对管道中每一步的代价进行微观管理！几秒钟的音频需要 5 次数据库往返！当我提出质疑时，它承认确实有隐藏的风险，但说已经记下来了，以后再优化。这是 AI Agent 缺乏对未来危机感的教科书案例。

第二轮：我提出了我的假设设计——粗化记录粒度、引入缓存、允许用户余额为负。然后我和它讨论了我的设计和它的设计之间的异同。在这个过程中，我也发现自己设计中的不足。

第三轮：让它按照改进后的方案重构代码。整个过程大约花了两小时。

结语

一旦你开始用 AI Agent 写代码，唯一真正的瓶颈就只剩下人类工程师的时间和注意力。如果你想快速交付产品，那么弄清楚如何在保持可控、避免日后严重后果的前提下快速高效地进行系统级变更，就变得至关重要——因为你所在赛道的其他公司工程师可能比你更快、更稳。

我相信人类创造力才是 AI 编程的真正根基。代码和模型只是投射在洞穴墙壁上的影子。

X: @codeplato2026 https://x.com/codeplato2026