这一章我们会解锁 Claude 的 teammate 模式，尝试开发一款 AI-oriented + 中医学习小游戏。
在遍地都是“成功学”的今天，第一版游戏更像是大型事故现场>_<，本文分两部分：
一句话总结：不是AI不强大而是我和AI作为两个完全不相似的灵魂，从头到尾都没有拉齐过世界观。
经过这一期做游戏的尝试我的观点是“分情况，别激动”, 在以下两个场景，AI能给你带来无得价值
哈哈但做游戏，我纯属是脑袋一热，小时候没咋玩过游戏，那咱直接跳过玩游戏来做个游戏呗，所以我属于及没吃过猪肉也没见过猪跑，于是这里就埋下了灾难的种子。
说实话，一开始我也不知道我要做个啥游戏。
我给模型的需求大概是：“我想做一个 AI-oriented 的中医学习游戏。”
我开启了 /plan 模式，大致提了需求，然后——完全放手让AI去做了。
事实证明，这是一切灾难的开始。这里必须敲黑板：
对于有一定复杂度的项目，写代码并不是最核心的部分，澄清需求才是。
需求要澄清到什么程度？至少要做到：
否则后面所有“高效开发”，本质上都是：高效地朝错误方向狂奔。 事实证明，楼歪得太狠的时候，是无法扶正的。
终于轮到“一个人拥有一个AI团队”的梦幻环节了
为了提高项目进度，我开启了 Claude 的 teammate 模式，设置了三个角色：
在我当时的想象里，这三位同事应该是：边界清晰、分工明确、各司其职、高效协同
而从结果回溯，当需求文档本身充满漏洞时，早在他们写下各自技术细分文档时，楼就已经歪了。
我目前觉得，它的前提是：多Agent之间必须基本独立工作，边界非常清晰。
适合的情况大概有两种：
整体上，我现在对 teammate 的判断是：它更擅长提效，不太擅长提质。
我目前觉得，它的前提是：多Agent之间必须基本独立工作，边界非常清晰。 适合的情况有两种：
整体上，我现在对 teammate 的判断是：它更擅长提效，不太擅长提质。
Claude 的 teammate 模式目前还是 beta，需要在项目配置中增加以下变量：
{
"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 汇报情况。
真正难的不是开发，而是测试
AI开发最核心的部分，真的不是开发，而是测试。决定一个项目短期内能不能成功的关键，是你能不能把这条链路跑通：AI写代码 → AI测试 → AI拿反馈 → AI继续优化
对于游戏这种东西，如果靠人手工验收，那简直是灾难，所以我设计了一套 AI 端到端测试流程：
并生成统一报告reports/AI端到端游戏测试报告.md
经过一夜五花八门的报错与修复，我们终于得到了近乎 100% 的测试通过报告：
看到这里，我当时心情大概是：“稳了，这波成了。”结果打开实际游戏一看，血压都飙到150。得就是下面看似花里胡哨，实际毫无策略的游戏成果
哈哈后续我尝试挽大厦于将倾，我质疑AI游戏的可玩性，学习的系统性，经过了长达一天的反反复复，AI又重构了一版加入了一堆可有可无的游戏进去，结果变成了下面这种复古拼凑游戏风。
我才终于意识到，这不是技术问题，这是产品问题，是定位问题，不是重构可以解决的，是需要重新从0开始设计才能解决的问题！
还好AI时代推到重来并不需要太大的勇气，但下周再说吧，我需要一点时间重新先想清楚，我理想中的AI-oriented的中医小游戏究竟是什么样的，从先去玩个游戏开始吧~
尤其在 teammate 模式下，这个问题会被放大。
虽然子智能体拥有整个项目文件，但它真正稳定能拿到的上文其实很有限。很多时候，它主要依赖的就是：
CLAUDE.md问题来了：你永远无法保证一条任务指令里，包含了这个子Agent所需的全部上下文。
所以在有限上下文前提下，CLAUDE.md 基本就是项目公共宪法。
中间最严重的一次雪崩，是因为我更新了 v2 设计方案，但没有同步更新 CLAUDE.md。
结果是什么？teammate 收到了新任务，但实际开发时引用的是旧设计文档，最后整个开发出现版本认知错乱。所以敲黑板
任何最新的技术细节、项目设计、交互规范，只要对子Agent重要，就必须进入
CLAUDE.md或其引用链。
看到最终那个“惊为天人”的游戏效果后，我开始复盘。
结果发现：
也就是说，这次项目并不是“代码写崩了”，而更像是：
团队非常认真地实现了一个Leader自己都没想清楚的东西。
所以我开始怀疑，需求澄清的正确方式可能根本不是“我来告诉AI我要什么”，而是：
让模型反复、结构化地向我提问。
通过一轮轮追问，把需求中的每一个模糊处抠出来，逐渐明确：
这其实比直接开始写代码重要太多。
有没有现成方案？
有。下一篇会聊 Claude 的另一套组合拳，比如：
brainstormingwriting-plansexecute-plans看起来会比我这次“边做边悟道”的方式靠谱很多。当然，那得留给这个游戏的 v2 版本了。
我用的是阿里的Claude接口，模型用的是kimi-k2.5，哈哈当然是因为国外模型用不起，才追求国内模型的性价比。
但在teammate模式上出现了很多问题，因为teammate新建的agent并不继承主智能体的模型配置，而是会默认选择Anthropic官方的opus等模型，导致teammate初始化失败。
可以通过配置以下系统变量把模型都指向国内模型
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
这个锅有一半得我自己背，因为我没认真看官方文档。
官方写得挺清楚： 在当前 teammate 模式下，如果队友任务没执行完，你退出会话后，/resume 无法恢复。
但实际体验中，问题不只是“无法恢复”这么简单，而是会出现一些非常魔幻的状态同步问题：
总之，目前看起来，子进程状态同步还是有优化空间的。
这个问题我中间遇到过很多次。表现形式是：项目看起来卡住了，没报错，没新输出，Leader也不继续推进
仔细一看才发现：子Agent做完了任务，但没向 Leader 汇报，而 Leader 也没主动 broadcast 去问进度。 于是两边就这么尬住了。
我怀疑这和上下文过长、指令注意力稀释有关。尤其任务推进到后期时，teammate 相关的协作指令更容易被冲淡。
我不太推荐让AI自己构建团队。因为它很容易一兴奋就给你造出一堆队员，仿佛下一秒就要上市敲钟。
我中间就试过一次让AI自主创建团队。结果它直接给我整了 12个人。你想想，12个Agent一起开发1000行代码，这件事本身就已经很有喜剧效果了。
结果当然是：
整体效果非常稀碎，问题修了一晚上，越修越像行为艺术。最后我直接：解散团队，回滚版本，假装这事没发生过。
所以当前阶段，我更推荐：人工决定团队规模和角色分配。 小团队、强边界、少沟通，往往比“AI自己组建复仇者联盟”靠谱得多。
虽然这次项目翻车了，但也不是完全白忙活。至少我更清楚了三件事：
复杂项目里，需求远比代码重要
代码错了还能修，方向错了只会越做越偏。
需求错了如何在最开始发现呢？这个我已经有了思路，正在尝试。
AI测试能验证“通不通”，但不一定能验证“值不值得”
功能通过 ≠ 产品成立。
测试全绿 ≠ 用户会玩。
价值层面如何提供有效的检测呢？我还没想到
多Agent协作最怕的不是能力不够，而是认知不一致
当目标模糊、文档不统一、上下文不完整时，多人协作不会加速，只会把错误放大。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。