AI 不需要专家团

要解决的具体问题

不少 AI 工作流直接照搬人类团队：让模型分别扮演 产品经理、架构师、开发工程师、测试工程师，再配上角色提示词、职责边界、协作接口和冲突解决机制。这套设计源于人类协作的真实约束——人脑容量有限所以要分工，沟通有成本所以要协调，协作有损耗所以要管理。但大模型并不具备这些约束。

技能如何工作

@user_15292d5a/yjkj-auto-expert-team 是一份系统性的反面教材，它把「专家团」流程逐层摆出来，并逐条标注问题所在：

• 专家团组建三步法：任务分析 → 专家设计 → 协作编排。每一步对人类团队都是必要的，对模型却是冗余开销。
• 身份叠加的本质：身份只是呈现层字段、注意力偏置信号和「人话翻译器」，不是能力切换机制。模型不需要靠扮演角色来获得能力。
• 静态专家清单：references/expert-catalog.md 枚举了 WorkBuddy 的 39 个专家团及成员，作为反面典型说明静态枚举的局限——数量有限、能力固定、关系静态、维护成本高。
• 协作机制全套组件：任务复杂度分类、专家角色分类、七项验证清单、协作基元（I/P/O）、自治度标注（⭐🤝💡🎯）、任务依赖链路 R0-01 → R0-06、各领域要求清单和范本 ET-01，每部分都附带「AI 不需要」的说明。

它给出的正确做法很直接：AI 只认事不认人——直接面对任务，按需求调用相应能力，端到端完成。打个比方，不是让模型扮演「厨师」去做饭，而是照着菜谱和食材直接做出来。

适用边界

• 这个技能本身不产出可执行的团队方案，它是反面参考，用途是学习、反思和对照，不应当作真实的协作编排器来用。
• 材料并未否定身份的全部价值：作为呈现层字段和注意力偏置信号，它仍然有用，只是不该被当成能力切换机制。
• 判断标准在于任务由谁来执行。分工、协调、管理是针对「人」的流程才有意义的机制；直接交给模型的任务，套上人类团队结构只会增加噪声。