让 AI 组队开发一个 App，听起来有点科幻？我实际试了一把：用 WorkSwarm 组了个 3 人最小产品小组，任务就叫「开发鸿蒙应用」。跑完最大感受不是「AI 多能干」，而是——AI 做需求探索的时候，居然会顺着你说。这坑怎么踩的、又怎么填的，下面完整复盘。当前版本 0.2.6（以实际发布为准）。

一、为什么让 AI 组队

一个人开发一个 App 是什么体验？需求自己理、代码自己写、测试自己跑，光是把「要做什么」想明白就能耗掉一半时间。

换个思路：让几个 AI 角色组成一个小团队。产品负责人想清楚做什么、开发写代码、测试挑毛病，各管一摊，Leader 负责把任务拆开、把结果汇总。你不再是「跟一个聊天框对话」，是「带着一个小队干活」。

单聊和组队是两回事。单聊是你问一句它答一句；组队是你扔一个「开发鸿蒙应用」进去，它自己拆成需求、开发、测试几步，分给不同角色并行干。

做产品有个概念叫「最小可行团队」：用最少的角色把一件事跑通。我组的就是个 3 人最小产品小组，任务就叫「开发鸿蒙应用」。

这篇把从组队到跑完的完整过程复盘一遍：团队怎么搭、角色怎么分、跑需求探索时踩了哪个坑、最后怎么填的。想自己试的，直接照着步骤来。

二、组队：3 个角色搭起最小产品小组

先建团队，再定角色。我搭的小组就 3 个角色：

角色	干什么
产品负责人	需求探索、架构设计
鸿蒙应用开发	编码实现，配了 deveco cli 工具
应用测试人员	测试验证

【图：d8-初始团队确定.png】

创建时能看到成员面板，3 个角色各就各位。这一步本身不复杂，值得留意的是两个细节：

一个是工具授权到角色粒度。鸿蒙开发那个角色，我给它配了 deveco cli（鸿蒙的命令行开发工具）——谁负责开发，谁才有对应的工具，不是所有角色共用一套。这样开发角色才能真的动手写，而不只是嘴上说说。

另一个是角色分工要写清楚。谁管需求、谁管代码、谁管验收，一开始就定明白，后面跑流程才不乱。我当时就是把「产品负责人 → 鸿蒙开发 → 应用测试」这条链理顺了才开跑。顺序很重要：需求没摸清，开发写了也是白写；开发没写完，测试测的就是空气。

三、跑需求探索：AI 团队的第一个坑——没人唱反调

团队搭好了，流程按「产品负责人做需求探索 → 鸿蒙开发写代码 → 应用测试跑测试」走。前面几步看着挺顺，但跑到需求探索环节，问题出来了：

3 个角色都在顺着我说。

我说「这个功能很重要，优先做」，它就当真了：产品负责人记进需求、开发准备写代码、测试准备测。没人问「优先级依据是什么」「资源够不够」「用户真的需要吗」。整个团队像是来鼓掌的，不是来干活的。

这就是我踩的第一个坑：AI 组队，不等于自动靠谱。它只是把「一个顺着你的 AI」变成了「三个顺着你的 AI」。

四、决策：加角色，而不是改角色

发现问题之后，我第一反应是「改角色」——把产品负责人的人设调一调，让它别那么顺着我。

后来想明白了：改角色，改的还是同一个视角。缺的不是某个角色的态度，是团队里压根没有「唱反调」的人。

所以我做了个决定：不动已有的 3 个角色，新增两个对抗审查角色——「毒舌PM」和「挑刺用户」。

【图：d8-新增流程门禁角色2.png】

毒舌PM负责从商业和资源角度泼冷水：这个功能值不值得做、预算扛不扛得住。挑刺用户负责从真实用户角度挑毛病：这个设计用户会不会用、流程顺不顺。它俩一进团队，需求探索就不再是「你说我记」，而是有人真跟你对着干。

【图：d8-调整角色 相关描述文档3.png】

角色加完之后，要把人设写成描述文件——每个角色的职责、边界都写清楚，团队按文件执行。这步很关键：光加名字不写描述，等于没加，新角色还是会跟风。

【图：SVG-团队角色结构图】

五、新流程：加完红队后的效果

把新角色写进流程，重新跑一遍需求探索。

这一次，输出明显不一样了。需求文档里开始出现「这个功能现阶段值不值得做」「目标用户到底是谁」「资源够不够」这类追问和约束——都是第一版文档里没有的。

【图：d8-多轮调整之后输出 文档.png】

说实话，加两个唱反调的角色，不是为了把文档写得更长，是让需求变得能落地。多轮调整之后输出的需求，比第一版经得起推敲得多——后面开发、测试再接手，心里也踏实。

六、复盘：AI 团队的分工逻辑

跑完这一趟，把里面的逻辑理一理，就两条。

第一，拆任务。 团队模式里，Leader 先把任务拆开，分给不同角色并行干：产品负责人管需求、开发管代码、测试管验收。单 Agent 是串行，做完一步再做下一步，上下文越长越容易乱；团队模式是并行，各跑各的，最后 Leader 汇总。为什么拆？三个原因：链路长、步骤多、要迭代的任务，单 Agent 串行容易在上下文里迷失；拆开后每个环节能并行、能独立盯；出了问题也定位得到是哪一环。这次鸿蒙开发的流水线就是例子：产品负责人先摸清需求，开发才有得写，测试才有得测——每一步都有人盯着。

【图：SVG-多智能体协作链路图】

第二，对抗审查。 这是我这次最值钱的发现。AI 团队有个天然毛病：多角色容易收敛成同一种声音——都顺着你、都往好了说。要打破它，就得在团队里放一个「红队」：专门负责唱反调、挑毛病、从反面看问题。毒舌PM和挑刺用户干的就是这个活。

其实这个思路不新鲜，工程里早就有——红队、对抗测试，都是专门安排一拨人从反面找问题。AI 团队也一样：你让它自己既当运动员又当裁判，它大概率给自己打高分；把它俩拆开，让唱反调的独立成角色，问题就藏不住了。

七、什么时候该让 AI 组队（诚实边界）

说句实话，不是所有任务都适合组队。

我之前试过一个用户订单管理系统——项目简单、流程短，单 Agent 直接做完更省事，最后就没上团队。那次也观察到一个现象：集群模式里 Leader 会先跟你确认技术方案和需求，界面上会多出成员信息——但那个项目真用不上这套。

【图：d3-集群模式体验.png】

我的判断标准就两条：任务拆不拆得开，拆开之后每个环节需不需要人盯着。都满足，就上团队；不满足，单干更快。团队模式不是万能的，这句话得敢说。

八、下一步：把这次流程沉淀成技能

这次「组队 + 加红队」的流程，其实可以沉淀下来——做成一个可复用的技能包，下次做同类项目直接调用，不用重新搭团队、重新想角色。一次跑通的协作，不该浪费。

进阶玩法：真人也能进团队当成员，跟 AI 角色一起干活。这个以后可以单独写一篇。

你让 AI 组队跑过什么任务？有没有遇到过「它顺着你说」的情况？评论区聊聊。