和AI一起搞事情#3：Claude Teammate 游戏开发翻车实录

这一章我们会解锁 Claude 的 teammate 模式 ，尝试开发一款 AI-oriented + 中医学习小游戏。

在遍地都是"成功学"的今天，第一版游戏更像是大型事故现场>_<，本文分两部分：

Teammate 模式的开发流程回顾与技术解析
Teammate 模式踩坑指南：尤其针对国内模型，部分问题未必适用于 Claude 官方模型

一句话总结：不是AI不强大而是我和AI作为两个完全不相似的灵魂，从头到尾都没有拉齐过世界观。

"AI时代每个人都是一个团队"吗？

经过这一期做游戏的尝试我的观点是"分情况，别激动", 在以下两个场景，AI能给你带来无得价值

吃过猪肉（技能增强）：我是搞算法的，所以围绕算法站的的场景，从产品到设计到算法到前后端，甚至运营和测试，有AI加持，我能全链路操作，如鱼得水。
看过猪跑（目标极度具象）：比如你没做过动画，但你对"我想要什么效果"已经能在脑海里很清楚地构建出来。目标可描述、效果可感知，差距可衡量。那跨界只会带来不被传统局限的无穷创意。

哈哈但做游戏，我纯属是脑袋一热，小时候没咋玩过游戏，那咱直接跳过玩游戏来做个游戏呗，所以我属于及没吃过猪肉也没见过猪跑，于是这里就埋下了灾难的种子。

step1. 澄清需求

说实话，一开始我也不知道我要做个啥游戏。

我给模型的需求大概是："我想做一个 AI-oriented 的中医学习游戏。"

我开启了 /plan 模式，大致提了需求，然后------完全放手让AI去做了。

事实证明，这是一切灾难的开始。这里必须敲黑板：

对于有一定复杂度的项目，写代码并不是最核心的部分，澄清需求才是。

需求要澄清到什么程度？至少要做到：

开发提不出异议
设计提不出异议
测试知道怎么验收
最关键的是：你自己知道你到底想要什么

否则后面所有"高效开发"，本质上都是：高效地朝错误方向狂奔。 事实证明，楼歪得太狠的时候，是无法扶正的。

step2. 开始组队

终于轮到"一个人拥有一个AI团队"的梦幻环节了

为了提高项目进度，我开启了 Claude 的 teammate 模式，设置了三个角色：

前端开发：负责写代码
设计师：负责页面设计和药材/饮片内容绘制
数据工程师：负责游戏药物相关的数据 schema

在我当时的想象里，这三位同事应该是：边界清晰、分工明确、各司其职、高效协同

而从结果回溯，当需求文档本身充满漏洞时，早在他们写下各自技术细分文档时，楼就已经歪了。

Teammate 适合什么场景？

我目前觉得，它的前提是：多Agent之间必须基本独立工作，边界非常清晰。

适合的情况大概有两种：

要的就是不同:在以下场景下，差异本身就是价值。

从不同角度分析同一个问题
基于不同假设同时做实验
多方案并行探索

分工真的很明确：在以下场景下，团队写作才有提效空间

采集不同类型的数据
不同工种处理完全不同模块
前后依赖少，冲突少

整体上，我现在对 teammate 的判断是：它更擅长提效，不太擅长提质。

我目前觉得，它的前提是：多Agent之间必须基本独立工作，边界非常清晰。 适合的情况有两种：

差异本身就是价值

从不同角度分析同一个问题
基于不同假设同时做实验
多方案并行探索

分工明确切边界清晰

采集不同类型的数据
不同工种处理完全不同模块
前后依赖少，冲突少

整体上，我现在对 teammate 的判断是：它更擅长提效，不太擅长提质。

Teammate 模式是怎么工作的？

Claude 的 teammate 模式目前还是 beta，需要在项目配置中增加以下变量：

json 复制代码

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

整个工作流大致是这样的：

TeamCreate：创建团队，其实就是同时创建多个subagent，并为每个智能体设定角色，职责，任务命令（必要上下文）

创建后，你可以在：./claude/teams/团队名称/config.json里看到所有队员的配置和指令。

TaskCreate：拆任务

这一步就是plan的具象化升级版工具，但更进一步：它会把任务拆成任务列表。这里面既包含：

可以并行执行的任务
也包含必须串行推进的任务

而具体任务之间有没有依赖、谁先做谁后做，主要由 Team Leader 来判断和分配。

Task：启动任务，其实是subagent的启动工具，用于告知某个子智能体开始执行对应任务。

看Claude刚开源的代码，Task其实是todo系列的一整个套件，整个触发链路如下

Message & MailBox：多个独立智能体通过信箱互相通信，和 Team Leader 汇报情况。

子Agent可以互相发消息
子Agent可以向Leader汇报
Leader也可以广播状态检查或任务通知

step3. AI端到端测试

真正难的不是开发，而是测试

AI开发最核心的部分，真的不是开发，而是测试。决定一个项目短期内能不能成功的关键，是你能不能把这条链路跑通：

AI写代码 → AI测试 → AI拿反馈 → AI继续优化
真正难的不是开发，而是测试

AI开发最核心的部分，真的不是开发，而是测试。决定一个项目短期内能不能成功的关键，是你能不能把这条链路跑通：AI写代码 → AI测试 → AI拿反馈 → AI继续优化

对于游戏这种东西，如果靠人手工验收，那简直是灾难，所以我设计了一套 AI 端到端测试流程：

前后端基础回归测试
Playwright 功能测试
AI 多模态模型视觉测试

并生成统一报告reports/AI端到端游戏测试报告.md

经过一夜五花八门的报错与修复，我们终于得到了近乎 100% 的测试通过报告：

看到这里，我当时心情大概是："稳了，这波成了。"结果打开实际游戏一看，血压都飙到150。得就是下面看似花里胡哨，实际毫无策略的游戏成果

哈哈后续我尝试挽大厦于将倾，我质疑AI游戏的可玩性，学习的系统性，经过了长达一天的反反复复，AI又重构了一版加入了一堆可有可无的游戏进去，结果变成了下面这种复古拼凑游戏风。

我才终于意识到，这不是技术问题，这是产品问题，是定位问题，不是重构可以解决的，是需要重新从0开始设计才能解决的问题！

还好AI时代推到重来并不需要太大的勇气，但下周再说吧，我需要一点时间重新先想清楚，我理想中的AI-oriented的中医小游戏究竟是什么样的，从先去玩个游戏开始吧~

Claude Code经验获取

CLAUDE.md很重要请及时更新

尤其在 teammate 模式下，这个问题会被放大。

虽然子智能体拥有整个项目文件，但它真正稳定能拿到的上文其实很有限。很多时候，它主要依赖的就是：

主Agent分配给它的那一条任务指令
项目级别的 CLAUDE.md

问题来了：你永远无法保证一条任务指令里，包含了这个子Agent所需的全部上下文。

所以在有限上下文前提下，CLAUDE.md 基本就是项目公共宪法。

中间最严重的一次雪崩，是因为我更新了 v2 设计方案，但没有同步更新 CLAUDE.md。

结果是什么？teammate 收到了新任务，但实际开发时引用的是旧设计文档，最后整个开发出现版本认知错乱。所以敲黑板

任何最新的技术细节、项目设计、交互规范，只要对子Agent重要，就必须进入 CLAUDE.md 或其引用链。

需求再怎么讨论都不为过

看到最终那个"惊为天人"的游戏效果后，我开始复盘。

结果发现：

开发本身其实未必有大问题
测试链路也跑起来了
真正从源头就呵呵的，是需求文档

也就是说，这次项目并不是"代码写崩了"，而更像是：

团队非常认真地实现了一个Leader自己都没想清楚的东西。

所以我开始怀疑，需求澄清的正确方式可能根本不是"我来告诉AI我要什么"，而是：

让模型反复、结构化地向我提问。

通过一轮轮追问，把需求中的每一个模糊处抠出来，逐渐明确：

用户是谁
核心玩法是什么
学习目标是什么
反馈机制是什么
什么叫"好玩"
什么叫"有效学习"

这其实比直接开始写代码重要太多。

有没有现成方案？

有。下一篇会聊 Claude 的另一套组合拳，比如：

brainstorming
writing-plans
execute-plans

看起来会比我这次"边做边悟道"的方式靠谱很多。当然，那得留给这个游戏的 v2 版本了。

Claude Teammate踩坑

如何使用国内模型

我用的是阿里的Claude接口，模型用的是kimi-k2.5，哈哈当然是因为国外模型用不起，才追求国内模型的性价比。

但在teammate模式上出现了很多问题，因为teammate新建的agent并不继承主智能体的模型配置，而是会默认选择Anthropic官方的opus等模型，导致teammate初始化失败。

可以通过配置以下系统变量把模型都指向国内模型

ini 复制代码

export ANTHROPIC_MODEL=glm-5
export ANTHROPIC_DEFAULT_OPUS_MODEL=glm-5
export ANTHROPIC_DEFAULT_SONNET_MODEL=glm-5
export ANTHROPIC_DEFAULT_HAIKU_MODEL=glm-5
export CLAUDE_CODE_SUBAGENT_MODEL=glm-5

/resume无法恢复对话

这个锅有一半得我自己背，因为我没认真看官方文档。

官方写得挺清楚：在当前 teammate 模式下，如果队友任务没执行完，你退出会话后，/resume 无法恢复。

但实际体验中，问题不只是"无法恢复"这么简单，而是会出现一些非常魔幻的状态同步问题：

队友配置还在，但 Team Leader 无法继续指派任务
队友配置已经删了，但 Team Leader 还在给一个不存在的人派活
有时候像恢复了一半，有时候像根本没恢复，有时候像在闹鬼

总之，目前看起来，子进程状态同步还是有优化空间的。

队员可能忘记汇报任务已完成

这个问题我中间遇到过很多次。表现形式是：项目看起来卡住了，没报错，没新输出，Leader也不继续推进

仔细一看才发现：子Agent做完了任务，但没向 Leader 汇报，而 Leader 也没主动 broadcast 去问进度。于是两边就这么尬住了。

我怀疑这和上下文过长、指令注意力稀释有关。尤其任务推进到后期时，teammate 相关的协作指令更容易被冲淡。

teammate贵精不贵多

我不太推荐让AI自己构建团队。因为它很容易一兴奋就给你造出一堆队员，仿佛下一秒就要上市敲钟。

我中间就试过一次让AI自主创建团队。结果它直接给我整了 12个人 。你想想，12个Agent一起开发1000行代码，这件事本身就已经很有喜剧效果了。

结果当然是：

任务拆得过细
每个Agent上下文都不充分
沟通链路又长又脆
最后代码到处冲突

整体效果非常稀碎，问题修了一晚上，越修越像行为艺术。最后我直接：解散团队，回滚版本，假装这事没发生过。

所以当前阶段，我更推荐：人工决定团队规模和角色分配。 小团队、强边界、少沟通，往往比"AI自己组建复仇者联盟"靠谱得多。

写在最后

虽然这次项目翻车了，但也不是完全白忙活。至少我更清楚了三件事：

复杂项目里，需求远比代码重要

代码错了还能修，方向错了只会越做越偏。需求错了如何在最开始发现呢？这个我已经有了思路，正在尝试。

AI测试能验证"通不通"，但不一定能验证"值不值得"

功能通过 ≠ 产品成立。

测试全绿 ≠ 用户会玩。价值层面如何提供有效的检测呢？我还没想到

多Agent协作最怕的不是能力不够，而是认知不一致

当目标模糊、文档不统一、上下文不完整时，多人协作不会加速，只会把错误放大。