你不需要十个智能体，两条轨道就够了

近年来，AI编码代理的流行让许多开发者开始尝试同时运行多个智能体以提升效率。然而，Hugo Baraúna在本文中提出了一种截然不同的观点：你不需要十个智能体，只需要两条轨道。

他分享了自己构建Elixir Radar通讯后台系统的实际工作流程。该系统用于策划和组装每期通讯、通过邮件平台发送，并允许客户管理自己的赞助。在这个流程中，他只使用两个智能体，分别承担规格定义和代码实现的任务。

第一条轨道是规格轨道。从模糊的功能想法开始，开发者与智能体反复讨论。智能体会阅读代码库以了解现有结构，并一步步引导开发者理清思路。最终产出一份完整的功能规格说明书（PRD）和技术设计方案。这个过程需要开发者全程参与，但产出物为第二条轨道提供了清晰的指导。

第二条轨道是实现轨道。智能体根据规格文档自主编写代码，开发者可以同时开始下一个功能的规格制定。当实现需要反馈时，开发者介入调整，然后继续推进规格工作。这种交替循环避免了多智能体并行带来的管理复杂性。

Baraúna解释了为什么只使用两个智能体。他指出，多智能体并行的核心瓶颈在于人的注意力。规格轨道需要持续的关注，而实现轨道相对自主。即使有十个实现智能体，也只能一个一个地提交规格任务。此外，代码编写完成后，还要进行人工代码审查、功能测试和UI迭代。这些环节无法完全自动化，因此并行化瓶颈环节以外的阶段并不能提升整体速度。

他还强调，用户体验设计不能委托给智能体。智能体可以实现前端代码并连接到全栈，但构建优秀产品的主观判断和品味来自开发者自身，而非智能体。

该工作流最适合“建造者型”开发者——那些同时掌握产品决策和编码能力的人，如独立开发者、技术创始人。对于开发团队成员，即使有产品经理提供需求规格，仍需将规格转化为技术设计，可能最多处理两条以上轨道，但远达不到十个。

Baraúna也指出，这种严谨的工作流适用于长期维护的代码；对于一次性实验性项目，随意编码（vibe coding）就足够了。为了验证方法的实用性，他录制了完整的工作流程视频，并展示了他使用的工具：Tidewave（Phoenix和Rails的智能体开发环境）和Superpowers（用于创建规格和实现计划的智能体技能）。

最后，他反思了该方法的理论基础：约束理论、排队理论、看板方法中的“停止开始，开始完成”原则，以及产品管理领域的“双轨开发”理念。他强调，新工具虽然强大，但已有的工程原理仍然适用，关键在于将其适应到智能体开发的新环境中。