多 Agent 并行开发前先统一接口与分工
作者用一个协调者和四个 Agent 并行开发应用,先提交业务规则、共享 TypeScript 接口、设计系统及页面骨架。各 Agent 拥有明确的文件范围,前后端共同引用同一份请求响应类型。
完整中文译文
上一篇文章里,我写了为什么给一位健身教练做的考勤应用不接入 Messenger。这篇聊聊它是怎么做出来的:用 Claude,由一个统筹者协调四个 Agent,同时开发应用的不同部分。
有意思的不是 Agent 写了代码,而是在它们动手之前,哪些东西必须先准备好。
先打好基础
第一次提交没有任何功能,只有这些内容:
一份计划。写清楚要解决的问题、被否决的方案,以及业务规则,细到密码如何比较、电话号码如何规范化,还明确了各个 Agent 之间的分工。
一份 API 契约。把 28 个 TypeScript 类型放在同一个共享文件里,作为请求和响应的唯一事实来源。后端和前端都从这个文件导入类型。
一套设计系统。配色 token 与教练的网站保持一致,按钮、卡片、表单字段、底部弹出面板和 toast 都已准备好,可以直接使用。
明确了负责人的空页面。每个页面都已经有了占位实现,里面只有一行指向计划的说明:实现这个页面,详见计划。
一条规则:每个文件只有一个负责人
一共有四个 Agent,分别负责后端、公开签到页面、教练的训练管理面板,以及学员管理和统计。每个 Agent 都负责一组文件,不允许修改范围之外的任何文件。如果某个 Agent 需要修改共享文件,它会在最终报告中描述所需的改动,而不是直接动手。
这消除了最容易破坏并行开发的问题:两个 Agent 带着不同的假设修改同一个文件。没有需要合并的内容。冲突会以备注的形式出现在报告里,再由统筹者有意识地做出决定。
第一轮交付了什么
基础提交之后仅过了 16 分钟,第一个完整版本就提交了,包含后端、签到、训练管理面板、学员管理和统计:共 53 个文件,约 8,900 行代码。后端还附带了测试,通过内存数据库调用 API 来验证功能。
第一轮交付不了什么
紧接着的下一次提交,删除了 59 个文件中的注释,并把端点列表集中到一份 API 文档里。之后,才是那些让一个能运行的版本变成真人可以放心使用的产品所需的工作:
- 部署到 Vercel,并接入云端 SQLite 数据库。
- 做一轮安全与 GDPR 检查:加入 CSRF 防护、请求限流、安全响应头,以及旧数据自动删除机制。
- 加入账号功能,支持修改密码。
- 支持通过观看录像补上缺席的训练。
- 提供个人面板,让每位学员都能查看自己的出勤记录。
Agent 很擅长快速填充一个定义清楚的框架。但决定框架是什么、规则是什么,以及怎样才算“完成”,仍然需要人来做。
契约先行。共享类型,是让四个 Agent 不必互相交谈就能达成一致的最低成本方式。
用所有权代替合并。按文件划分工作,而不是把会修改同一批文件的任务分给不同 Agent。
把业务规则写下来。计划里每写清楚一条规则,Agent 就少一个需要猜测的问题。
用占位页面充当地图。一个明确了负责人的空页面,能准确告诉 Agent 应该在哪里工作,又该在哪里停下。
本文最初发表于 kamilkolodziejczyk.dev。
如需进一步处理,你可以考虑屏蔽此人和/或举报滥用行为。