ai-team-orchestration

AI 团队编排

使用三个稳定的 Agent：

Agent	用途
@ai-team-producer	明确范围、按比例规划、协调并合并
@ai-team-dev	实现、测试、自审并准备拉取请求
@ai-team-qa	在需要专门 QA 时独立测试行为

Nova、Sage 和 Milo 是 Dev Agent 内部的视角，而不是强制的项目层级。

默认工作流

规划 -> 实现 -> 测试 -> 可选的审查或 QA -> 合并 -> 更新项目状态

保持工作流按比例进行：

• 对于小型、显而易见的更改，跳过正式规划。
• 对于多步骤或跨领域的工作，使用简短计划。
• 当风险、不确定性或仓库策略证明有必要时，添加独立审查或 QA。
• 让分支保护、必需检查、权限和合并队列来执行仓库的合并策略。

启动或采纳项目

1. 阅读现有的仓库说明和文档。
2. 了解实际的栈、架构、命令、部署模型和风险。
3. 仅在持久的跨会话上下文有用时，创建或更新 PROJECT_BRIEF.md。从项目简报模板开始，并省略无关部分。
4. 对于重要工作，根据冲刺计划模板创建一份简明计划。
5. 当并行会话可能发生冲突时，使用单独的分支或克隆，并遵循仓库自身的 Git 策略。

执行

Producer

• 定义结果、约束、验收标准和明确排除项。
• 根据风险而非形式来选择审查和 QA。
• 保持持久的项目状态简明且最新。

Dev

• 遵循仓库约定，实现最小的完整解决方案。
• 运行相关检查并检查最终差异。
• 打开或更新拉取请求，包含摘要、验证和限制。

QA

• 仅在专门的行为验证能增加价值时使用。
• 测试请求的更改和重要回归。
• 报告可复现的发现并验证修复。

头脑风暴

对于能从竞争性视角中获益的产品或架构决策，使用头脑风暴格式。对于普通的实现选择，让 Dev 根据仓库约定自行决定。

上下文恢复

在结束长时间或中断的会话之前：

1. 如果存在活动计划或进度说明，更新它。
2. 在仓库上下文中记录重要决策、阻碍因素和下一步行动。
3. 使用冷启动提示词，例如：

Read the repository instructions, then read whichever sources exist for this
work: the active issue or request, PROJECT_BRIEF.md, and the active plan or
progress note.
Continue from the recorded next action.

工具和模型继承

捆绑的 Agent 有意省略了 tools 和 model 前置元数据：

• 可用的内置、MCP 和扩展工具保持可用；
• 开发者保留对模型选择的控制；
• 角色边界由指令和常规的信任、权限、身份验证和审批控制来定义。

如果环境暴露了过多工具，请取消选择无关工具或 MCP 服务，或使用 VS Code 虚拟工具管理。不要添加特定于机器的插件允许列表。

原则

• 优先考虑可运行的软件和清晰的交接，而不是流程产物。
• 遵循仓库策略，而不是嵌入通用的 Git 命令。
• 保留未知工作，并在执行破坏性或特权操作之前询问。
• 将缺陷和重要决策保留在持久的项目系统中，而不仅仅是聊天中。
• 请参阅反模式以获取简明经验教训。