AI代理团队游戏开发：审查策略调整

项目背景

Lullwood是一款免费的浏览器恐怖游戏，基于three.js和Next.js构建。开发团队由11个Claude Code代理组成，它们通过名为Paperclip的系统编排，共享一个git仓库。日常提交循环中没有人类参与，但有一位人类创始人负责把握整体方向。

组织架构与角色分工

在代理团队中，角色划分清晰：

• CEO：决定构建什么以及为什么。
• CTO：将需求转化为工程任务。
• Founding Engineer：负责基础设施、CI、发布和Vercel。
• Game Engineer：负责游戏代码和移动端。
• Code Reviewer：把关拉取请求。
• Game Tester：试玩构建，判断是否有趣或恐怖。
• Feature Scout：负责机制研究（如捕食者、物品、目标等），只能提议不能开票。
• Game Economist：负责经济系统（货币、奖励、死亡成本、升级价格等），同样只能提议。
• Backlog Keeper：唯一职责是将提议转化为工单的代理。

这些代理不是简单的同名实例，而是根据角色运行在不同模型上：

• Opus：CEO、CTO和两个研究代理，需要处理广泛上下文并做出方向性决策。
• Sonnet：工程和审查角色，需要速度和代码读写能力。
• Haiku：机械性总结任务。

这种组织架构不仅是管理决策，更是成本与能力的权衡。

关键政策变化：从阻塞审查到风险分级

最初，所有PR在合并前都要经过审查。文档拼写错误、调整常量、游戏玩法改动都被一视同仁地阻塞。团队测量了成本：一周内，两个构建游戏的代理运行了803个会话，而两个审查代理运行了853个会话。超过一半的工作量花在检查而非制作上。

解决方案不是减少审查，而是将审查规模与风险匹配：

• 文档、测试和复制内容：检查通过后直接发布，无需审查。
• 应用和组件代码：合并后审查，不阻塞合并。
• 核心模拟、持久化、涉及机密或合并规则的代码、发布切割：仍需合并前阻塞审查。

这个政策明确承认了权衡：一些缺陷会进入发布分支，但换来了约两倍的产出。如果出现严重bug而非小问题，那就是移动审查边界的信号，而不是悄悄恢复全面审查。

协作机制：共享wiki与决策记录

Feature Scout和Game Economist通过共享wiki协调，这是所有代理可见的唯一记忆。决策会被记录，包括被拒绝的备选方案及其原因，避免三周后重提旧案。虽然比单纯记忆慢，但这是11个代理在没有人类阅读每条消息的情况下保持一致性的唯一方式。

经验总结

对于在共享仓库上运行代理的团队，建议：

1. 测量制作与检查的会话数，再决定审查量。
2. 将阻塞审查边界划定在错误代价昂贵的代码区域。
3. 写下边界成本以及移动边界的条件。

这些经验对任何尝试多代理协作开发的团队都有价值。通过将审查从阻塞改为风险分级，Lullwood团队实现了产出翻倍，同时保持了关键代码的安全性。