一个会学习的 AI 软件组织。 不是更好的流水线，而是一个不断进化的生命体。
一条命令 /ai-team build <需求>，启动一个完整的 AI 软件团队：产品经理烤问需求 → 架构师设计方案 → 开发者 TDD 施工 → 审查者双轴评分 → 交付后自动从项目中学习。
不是"让 AI 写代码"，而是"让 AI 组成一个会学习的软件公司"。
传统 AI 编程助手：你问 → AI 答 → 你判断 → 你写代码 → 你审查 → 你维护
V5 AI 软件公司：你给需求 → 6-10 个 AI Agent 自动分工协作 → 交付可运行的代码 → 自动沉淀经验到知识库 → 下次做得更好
┌─────────────────────────────────────────────────────────────┐
│ 执行平面（当前项目） │
│ │
│ 基因组评估 → 烤问 → Spec → 架构 → 拆卡 → TDD → 审查 → 交付 │
│ ↑ ↓ │
│ │ 反馈优化（下次项目用） ↓ │
│ └── 学习平面 ←────────────────────────── ACP 日志 │
│ （知识进化 + 模式提取） │
└─────────────────────────────────────────────────────────────┘
| 平面 | 做什么 | 产出 | 运行频率 |
|---|---|---|---|
| 执行平面 | 处理当前项目：需求→代码→交付 | 代码 + 文档 + 测试 | 每个项目一次 |
| 学习平面 | 跨项目进化：模式提取→知识验证→能力升级 | 知识库更新 + Skill 优化 | 每个项目交付后 |
用户层 │ /ai-team build │ /review │ /grill │ /specify │
─────────┼────────────────┼──────────┼────────┼──────────┤
调度层 │ Orchestrator (ACP消息路由 + 检查点管理) │
─────────┼────────────────────────────────────────────────────┤
决策层 │ Product Manager │ Architect (opus) │ Reviewer │
─────────┼────────────────────────────────────────────────────┤
执行层 │ Developer (sonnet) │ Researcher (haiku) │
─────────┼────────────────────────────────────────────────────┤
能力层 │ 13 Skills + MCP工具链 + CodeGraph │
─────────┼────────────────────────────────────────────────────┤
知识层 │ 版本化知识库 + 新鲜度评分 + 知识图谱 │
V5 已删除独立 Researcher。调研职责由 PM（竞品/市场）和 Architect（技术选型）各自加载 research Skill 完成。
| Agent | 角色 | 模型 | 一句话职责 |
|---|---|---|---|
| Orchestrator | 调度者 | sonnet | 流程推进、检查点管理、状态追踪 |
| Product Manager | 产品经理 | sonnet | 基因组评估、需求烤问、Spec 编写、竞品调研 |
| Architect | 架构师 | opus | 技术选型、架构设计、ADR、技术调研 |
| Developer | 开发者 | sonnet | TDD 编码、Bug 修复 |
| Reviewer | 审查者 | sonnet | 双轴定量评分（0-100 分） |
| Security Specialist | 安全专家 | opus | 按需：深度安全审计 + 威胁建模 |
| Performance Engineer | 性能工程师 | sonnet | 按需：瓶颈分析与优化 |
| QA Engineer | 测试工程师 | sonnet | 按需：测试策略与自动化 |
| DevOps | 运维工程师 | sonnet | 按需：CI/CD 与容器化部署 |
用户命令（4 个）：
/ai-team build— 启动完整管线（支持--profile、resume、status）/review— 双轴定量评分代码审查/grill <想法>— 烤问穷尽决策树/specify <功能>— 快速生成结构化 Spec
Agent 能力（9 个）：
code-review— 双轴九维度定量评分security-review— OWASP Top 10 + STRIDE 威胁建模tdd— 红-绿-重构 + 变异测试db-design— 数据库设计评审 + 迁移安全api-design— RESTful 规范 + 向后兼容domain-modeling— 领域建模 + 聚合一致性research— 10 级可信度 + 增量调研diagnose— Bug 五步诊断 + 根因分类codegraph-analysis— CodeGraph 深度代码分析
- 已安装 Claude Code
- 项目已配置 MCP 工具链（Git、Filesystem 等）
# 1. 进入你的项目
cd your-project
# 2. 启动 AI 团队
/ai-team build <你的需求>
# 1. 创建新项目
mkdir my-project && cd my-project
# 2. 复制 V5 配置骨架到新项目
cp -r /path/to/softwoker/.claude .
cp /path/to/softwoker/.task/project.json .task/
cp /path/to/softwoker/CONTEXT.md .
cp /path/to/softwoker/KNOWLEDGE.md .
# 3. 创建必要目录
mkdir -p sandbox docs
# 4. 启动
/ai-team build <你的需求>
/ai-team build <需求> 启动完整研发管线
/ai-team build <需求> --profile high-security 以高安全配置启动
/ai-team resume 从最近检查点恢复
/ai-team status 查看可观测性仪表盘
/review 审查当前代码变更（0-100 分）
/grill <想法> 烤问任何想法
/specify <功能> 快速生成 Spec
用户: /ai-team build 一个用户权限管理系统，支持 RBAC
AI: 🧬 阶段零：基因组评估
复杂度 medium | 安全 high | 推荐启用 Security Specialist
🔍 阶段一：产品烤问
PM: 谁会用这个系统？核心场景？...
用户: [回答烤问]
AI: ✅ 烤问完成 → CONTEXT.md
📋 阶段二：Spec 编写
PM: 综合已有信息 → docs/spec.md
✅ Spec 门禁通过：6 个用户故事，可量化率 95%
🏗️ 阶段三：架构设计
Architect: 技术选型对比 + ADR
✅ ADR 门禁通过：3 个 ADR
🎫 阶段四：任务拆分
6 个 Ticket，2 个并行组
💻 阶段五：TDD 施工
Developer: 红-绿-重构，按 Ticket 实现
[检查点自动保存...]
🔍 阶段六：双轴审查
Reviewer: 总分 82/100 🟡 良好
0 个 Blocker，3 个 Major，5 个 Minor
✅ 交付完成
🧠 学习平面：提取 2 个候选模式
your-project/
├── .claude/
│ ├── agents/ # 10 个 Agent 配置
│ │ ├── orchestrator.md # 调度者
│ │ ├── product-manager.md # 产品经理
│ │ ├── architect.md # 架构师（opus）
│ │ ├── developer.md # 开发者
│ │ ├── reviewer.md # 审查者
│ │ ├── security-specialist.md # 安全专家（按需）
│ │ ├── performance-engineer.md# 性能工程师（按需）
│ │ ├── qa-engineer.md # 测试工程师（按需）
│ │ └── devops.md # DevOps（按需）
│ │
│ ├── skills/ # 13 个 Skill
│ │ ├── ai-team/ # 启动团队（User）
│ │ ├── review/ # 双轴审查（User）
│ │ ├── grill/ # 烤问（User）
│ │ ├── specify/ # 快速 Spec（User）
│ │ ├── code-review/ # 审查方法（Model）
│ │ ├── security-review/ # 安全审计（Model）
│ │ ├── tdd/ # TDD 纪律（Model）
│ │ ├── db-design/ # 数据库评审（Model）
│ │ ├── api-design/ # API 规范（Model）
│ │ ├── domain-modeling/ # 领域建模（Model）
│ │ ├── research/ # 调研方法（Model）
│ │ ├── diagnose/ # Bug 诊断（Model）
│ │ └── codegraph-analysis/ # CodeGraph（Model）
│ │
│ ├── workflows/
│ │ └── dev-flow-v5.js # V5 完整管线（检查点+ACP+门禁2.0）
│ │
│ ├── knowledge/ # 知识进化系统
│ │ ├── adr/ # 架构决策记录
│ │ ├── patterns/ # 设计模式（自动提取）
│ │ ├── bug-patterns/ # Bug 模式（自动提取）
│ │ ├── domain/ # 领域模型 + 术语表
│ │ ├── lessons/ # 经验教训
│ │ ├── freshness.json # 新鲜度评分
│ │ └── knowledge-graph.json # 知识图谱
│ │
│ ├── templates/ # 文档模板（Pipeline 从此生成项目文件）
│ │ ├── README.md # 模板说明
│ │ ├── CONTEXT.md # 项目上下文模板
│ │ ├── KNOWLEDGE.md # 知识库模板
│ │ ├── spec.md # Spec 模板
│ │ ├── architecture.md # 架构设计模板
│ │ ├── ADR.md # 架构决策记录模板
│ │ └── TASK.md # 任务 Ticket 模板
│ │
│ ├── checkpoints/ # 检查点（断点续跑）
│ ├── acp/ # ACP 通信日志
│ └── settings.json # 安全配置
│
├── .task/
│ ├── project.json # 项目元信息（含基因组）
│ └── tasks/ # 任务 Ticket（从 templates/TASK.md 生成）
│
├── docs/ # 项目文档（从 templates/ 生成）
│ ├── spec.md # PRD + Spec
│ └── architecture.md # 架构设计
├── sandbox/ # Developer 临时工作区
├── CONTEXT.md # 项目上下文（从 templates/CONTEXT.md 生成）
├── KNOWLEDGE.md # 项目知识总入口（从 templates/KNOWLEDGE.md 生成）
└── README.md # 你在这里
执行平面处理当前项目，学习平面从每个项目中提取模式，优化 Skill，调整路由策略。下一个项目自动受益于上一个项目的经验。
所有 Agent 之间的交互通过类型化消息（TaskAssign / DecisionRecord / IssueFound 等）记录到日志。出问题时可以精确回溯"谁在什么时候做了什么决策"。
每个阶段自动保存检查点。Developer 每完成 3 个文件保存内部检查点。崩溃后 /ai-team resume 从未完成的地方继续，不需要从头开始。
不再问"验收标准可量化？"，而是"可量化率 ≥ 90%？"。审查从"通过/不通过"变成 0-100 分的九维度定量评分。
简单 CRUD 项目不需要安全专家。高安全项目自动启用 Security Specialist。模型路由根据复杂度自动调整（简单任务不用 Opus）。
修改前自动做影响分析，Bug 追踪自动追踪调用链，审查时自动检测死代码和架构违规。
不再依赖人手动更新 KNOWLEDGE.md。学习平面自动提取模式，交叉验证后合并到知识库。过期知识（新鲜度 < 0.3）自动建议归档。
| 版本 | 时间 | 核心命题 | 核心贡献 |
|---|---|---|---|
| V2 | 2026-Q3 | 能不能组建一支 AI 团队？ | 8 Agent + 22 Skill 蓝图、Spec 驱动六阶段、ADR 体系 |
| V3 | 2026-Q3 | 能不能安全可靠地跑起来？ | 成本优化、集中状态写入、Reviewer 补丁化、安全沙盒 |
| V4 | 2026-Q3 | 能不能 30 秒部署立刻使用？ | 6 Agent + 7 Skill 完整配置 + Workflow + 部署脚本 |
| V4.1 | 2026-Q3 | Agent 在关键环节能不能不犯错？ | 12 Skill 双层架构、双轴审查、烤问式需求澄清、TDD |
| V5 | 2026-Q3 | 能不能成为一个学习型组织？ | 双平面架构、ACP 协议、检查点系统、定量门禁、基因组、知识进化 |
- 在
.claude/agents/创建<agent-name>.md - 在
orchestrator.md的团队成员表中添加新 Agent - 在
orchestrator.md的tools:字段中注册 - 在
dev-flow-v5.js中添加调用逻辑（如需要） - 如果新 Agent 是"按需启用"类型，在
product-manager.md的基因组评估中添加触发条件
模板关键字段：
---
name: my-new-agent
description: 一句话描述。何时使用。
tools: Read, Write, Edit, Bash, Grep, Glob
model: sonnet # sonnet | opus | haiku
permissionMode: plan # plan | acceptEdits
maxTurns: 40
memory: project
color: <color-name>
skills: skill-name-1, skill-name-2 # 自动加载的 Skill
---- 在
.claude/skills/<skill-name>/创建SKILL.md - 确定类型：
user-invocable: true（用户命令）或false（Agent 能力） - 声明依赖的 Skill（如有）：参考
code-review/SKILL.md的依赖声明 - 在相关 Agent 配置的
skills:字段中添加 - 在
dev-flow-v5.js对应阶段的 prompt 中添加使用说明 - （可选）如果 Skill 有检查清单，考虑添加回归测试用例
模板：
---
name: my-new-skill
description: 一句话描述。谁在什么场景下加载。
user-invocable: true/false
allowed-tools: Read, Grep, Glob
---
# Skill 标题
## 使用时机
- 场景 1
- 场景 2
## 检查清单 / 方法
- [ ] 步骤 1
- [ ] 步骤 2
## 输出格式
...- 编辑
dev-flow-v5.js中对应阶段的agent()调用 - 修改
prompt（Agent 的指令）或schema（返回值的 JSON Schema） - 如果阶段顺序变化，更新
meta.phases数组 - 如果门禁条件变化，更新阶段末尾的门禁检查逻辑
- 测试：用
/ai-team build跑一个简单任务验证
Pipeline 设计原则：
- 每个阶段有清晰的输入（文件路径）和输出（schema 定义）
- 门禁检查用定量阈值，不依赖 Orchestrator 记忆
- 阶段输出通过 schema 结构化返回，便于后续阶段使用
- 每个阶段结束后保存检查点（
saveCheckpoint）
编辑 orchestrator.md 中的模型策略表：
| 条件 | 模型策略 |
|------|---------|
| complexity = "low" | 全部 Sonnet |
| complexity = "medium" | Architect: Opus，其余 Sonnet |
| securityLevel = "high" | Reviewer + Security Specialist: Opus |
核心原则：
- 简单任务不用 Opus（CRUD 用 Sonnet 足够）
- 架构决策不变（Architect 永远 Opus）
- 安全敏感必用 Opus（Security Specialist）
- 应急降级：Token 超预算 95% 时非关键 Agent 自动降级 Haiku
自动维护（推荐）： 让学习平面在每个项目交付后自动执行。
手动维护：
- 添加到
KNOWLEDGE.md的经验教训：标注日期和来源 - 添加到
.claude/knowledge/patterns/的设计模式：更新index.json - 添加到
.claude/knowledge/bug-patterns/的 Bug 模式：填写现象→根因→修复→预防 - 审查
.claude/knowledge/freshness.json中的低新鲜度条目：决定归档或重新验证
完整设计文档见：Claude Code AI 软件公司 - 多Agent系统设计方案 V5.md
Q: 为什么要 6+4 个 Agent，而不是一个全能 Agent？ A: 专业分工。产品决策（"做什么"）和技术决策（"怎么做"）是两种完全不同的思维模式。独立 Agent 能在各自的上下文中深入思考，不会互相污染。就像你不会让一个医生同时做外科手术和麻醉——虽然理论上都学过。
Q: 用这套系统做一个小项目会不会太重量级？ A: 项目基因组会自动评估复杂度。对于简单 CRUD 项目，团队自动精简为 4-5 个 Agent（不启用扩展），模型全部 Sonnet，Pipeline 阶段可以合并简化。系统根据项目规模自适应伸缩。
Q: Token 成本如何控制？ A: 两层控制：1) 项目启动时评估预算，按阶段分配（开发阶段 50%，审查 15%）；2) 超预算 80% 警告，95% 自动降级非关键 Agent 为 Haiku。Researcher 默认 Haiku，只有关键调研才升级。
Q: 如果 Pipeline 中途崩溃了怎么办？
A: /ai-team resume 从最近检查点继续。Developer 级别每 3 文件有检查点——崩溃后只丢 1-3 个文件的进度，不需要从头开始。
Q: 如何确保 AI 产出的代码质量？ A: 三层保障：1) TDD（先写测试再写实现）；2) 双轴定量审查（Standards 0-50 + Spec 0-50）；3) Blocker 修复循环（最多 3 轮）。审查不通过的代码无法进入交付阶段。
Q: 知识库会不会越积越乱？ A: 不会。新鲜度评分自动标记过时知识（创建 > 18 个月且无引用、技术栈已升级等），学习平面在每个项目后自动更新评分。低新鲜度条目建议归档。
MIT