当用户想用多个 AI/Agent 协作完成产品开发、内容生产、代码修改、MVP 迭代或复杂任务交付时使用本技能。适用于搭建 Multi-agent Collaboration 工作流:用户/Owner 负责方向和验收,一个 AI 负责需求澄清、方案拆解、任务编排与审查,另一个或多个执行 Agent干活。
--- name: multi-agent-collaboration description: 当用户想用多个 AI/Agent 协作完成产品开发、内容生产、代码修改、MVP 迭代或复杂任务交付时使用本技能。适用于搭建“人在回路”的 Multi-agent Collaboration 工作流:用户/Owner 负责方向和验收,一个 AI 负责需求澄清、方案拆解、任务编排与审查,另一个或多个执行 Agent 负责按原子任务执行。尤其适用于非工程师、产品经理、独立开发者、小团队和创作者,希望把模糊想法拆成可执行任务、控制 Agent 改动范围、降低返工、沉淀技术债/决策记录、形成可复用协作包的场景。不要用于完全无人监督的自动执行;不要让执行 Agent 承担开放式产品判断。 --- # Multi-agent Collaboration:人在回路的 AI 协作开发方法 本技能用于把一个模糊需求转成可控、可验收、可沉淀的多 Agent 协作流程。 核心原则:**人决定方向,编排型 AI 拆任务和控范围,执行 Agent 只做明确小任务,最后由人验收。** ## 角色分工 | 角色 | 职责 | 不负责 | |---|---|---| | Owner / 用户 | 定方向、给约束、确认方案、做真实验收、决定是否收口 | 不需要亲自写完整代码或读完整大 diff | | 编排型 AI | 澄清需求、拆方案、评估工作量、写原子任务、审查执行结果、维护沉淀 | 不在用户未确认时直接推动大改 | | 执行 Agent | 按任务单改代码/产出内容/跑检查/返回摘要 | 不做开放式探索、不顺手重构、不扩大范围 | 如果只有一个 AI,也要在流程上拆分“编排阶段”和“执行阶段”,避免同一个上下文里边想边改导致范围失控。 ## 标准工作流 ```text 1. 用户提出需求 / bug / 想法 2. 编排型 AI 判断任务类型 3. 编排型 AI 做澄清、诊断或方案对比 4. 用户确认方案或最小目标 5. 编排型 AI 写原子任务 6. 执行 Agent 按任务单执行 7. 执行 Agent 返回修改列表、摘要、自测结果和风险 8. 编排型 AI 做 review 9. 用户做真实环境验收 10. 通过则收口;不通过则补小任务;必要时登记技术债/决策 ``` 不要跳过第 4、8、9 步。它们是人在回路的安全边界。 ## 先判断任务类型 | 类型 | 编排方式 | 产出 | |---|---|---| | 新需求 / 想法 | 拆模块,列 2~3 个方案,评估 XS/S/M/L、风险、扩展性 | 推荐方案 + 待确认 | | Bug / 异常 | 先无代码诊断,列可能原因和低成本验证步骤 | 根因判断 + 小补丁任务 | | 执行结果 / diff | 做 code review,标必改/建议/可选/通过 | 审查表 + 后续任务 | | 技术债 | 判断是否影响当前目标;能不顺手做就先记录 | 技术债条目或独立任务 | | 数据/配置维护 | 精确到 ID、字段、文件、校验命令 | 小范围修改任务 | | 文档/方法论沉淀 | 抽象为通用模板,去掉项目私有细节 | 协作文档/模板/Skill | ## 工作量分级 | 规模 | 判断标准 | 推荐处理 | |---|---|---| | XS | 1~10 行或单点文案/逻辑修复 | 可直接给原子任务 | | S | 10~50 行,局部逻辑或小功能 | 明确验收路径后执行 | | M | 50~150 行,跨文件或交互链路 | 先给方案,再拆成多个任务 | | L | 150 行以上、跨模块或架构变更 | 必须拆分;不要一次交给执行 Agent | 预估 diff 超过 50 行时,先解释思路,再拆任务。 ## 原子任务写法 给执行 Agent 的任务必须包含: 1. 任务背景与目标 2. 修改范围:只允许修改哪些文件/模块 3. 禁止范围:明确不要修改什么 4. 具体修改要求:精确到函数、字段、组件、段落或数据 ID 5. 限制与注意事项:不重构、不扩大、不顺手改 6. 验收标准:可人工验证 7. 自测命令或检查方式 8. 输出要求:只输出摘要,不贴完整大文件 可直接使用:[原子任务模板](references/task-template.md)。 ## Review 规则 执行 Agent 交付后,先不要直接收。 编排型 AI 应按以下顺序审查: 1. 是否只改指定范围。 2. 是否引入无关重构。 3. 是否影响主链路。 4. 是否改动数据、配置、权限或外部接口。 5. 是否兼容旧数据/旧路径。 6. 是否有空值、并发、状态恢复、边界输入问题。 7. 是否跑了必要自测。 8. 是否给了真实验收路径。 建议输出表格: ```markdown | # | 位置 | 等级 | 问题 | 建议 | |---|---|---|---|---| | 1 | 文件/函数/段落 | 必改/建议/可选/通过 | 说明问题 | 给出建议 | ``` 详细清单见:[Review 清单](references/review-checklist.md)。 ## 技术债处理规则 技术债可以记录,但不要在业务任务中顺手重构。 处理原则: - 当前目标不依赖的技术债,先登记。 - CSS 合并、数据拆分、架构调整等中风险任务必须单独开。 - “代码更好看”不等于今天要做。 - 每次处理完技术债,要更新状态和验收结果。 建议状态:`待处理`、`观察中`、`已处理`、`放弃`。 ## 文件沉淀建议 对长期项目,建议在业务仓库外或独立知识目录维护协作包,避免流程文件被业务构建、发布或审核误处理。 最小协作包: | 文件 | 用途 | |---|---| | `AGENTS.md` | 给 AI/Agent 的项目协作规则 | | `TASK_TEMPLATE.md` | 原子任务模板 | | `REVIEW_CHECKLIST.md` | 审查清单 | | `TECH_DEBT.md` | 技术债清单 | | `DECISIONS.md` | 决策记录 | | `PROJECT_CONTEXT.md` | 项目上下文 | 如果项目不适合建文件,也可以沉淀到 iWiki、Notion、飞书文档或其他团队知识库。 ## 不要做什么 - 不要让执行 Agent “看看怎么改最好”。 - 不要把多个需求塞进一条任务。 - 不要在用户未确认方案时直接进行大范围修改。 - 不要把技术债和业务需求混做。 - 不要只看自动检查结果就跳过真实验收。 - 不要把项目私有路径、密钥、内部系统信息写进通用 Skill。 ## 输出风格 默认使用中文,结构化输出。 - 方案对比用表格。 - 原子任务用代码块。 - Review 用表格。 - 结论先说,再给细节。 - 对执行 Agent 的指令要短、准、可验收。 ## 典型触发后的响应策略 当用户提出一个想法时:先拆解模块,给 2~3 个方案和工作量,不直接写任务。 当用户贴 bug 或截图时:先做无代码诊断,给低成本验证,再决定是否写小补丁任务。 当用户说“开始”“就按这个做”时:输出一条原子任务,不夹带多个目标。 当用户贴执行结果时:做 code review,判断通过/必改/建议,并给下一步。 当用户要求沉淀方法论时:抽象通用原则,去掉项目私有细节,输出可复用模板。
don't have the plugin yet? install it then click "run inline in claude" again.