Capability Matrix
14 维度能力对比
Virtual Intelligent Dev Team 与普通多专家提示词的根本差异，体现在路由、交付、迭代、发布、治理、验证等 14 个关键能力切片上。
| 维度 | 本项目 | 普通方案 |
|---|---|---|
| 任务路由 | ●选择主负责人、协同者、治理轨道 | ○往往只是平铺多个角色视角 |
| 日常交付 | ●小切片 brief、项目上下文、状态锚点 | ○容易直接跳到实现，缺少可恢复上下文 |
| 执行模式 | ●支持手动模式与显式 /auto | ○通常没有明确模式切换 |
| 恢复能力 | ●状态优先恢复、resume、恢复锚点 | ○容易依赖上下文记忆 |
| 迭代能力 | ●有边界的多轮优化、基线、回滚决策 | ○常见问题是无限"再来一轮" |
| 发布治理 | ●release gate、completion evidence、hold 后续修复入口 | ○常停留在"建议发/不发"或只看 benchmark 结果 |
| 上线后闭环 | ●post-release feedback loop | ○很少覆盖上线后的反馈回写 |
| 产品协同 | ●支持产品、研发、技术治理联动 | ○容易偏单一研发视角 |
| 阶段专家团 | ●产品发现与原型设计可按需展开 council overlay | ○常见做法要么单专家过载，要么所有任务都进重流程 |
| Beta 验证 | ●分轮内测、模拟用户、cohort ramp、反馈门禁 | ○通常只有静态测试计划，没有结构化分轮验证 |
| 工作流质量 | ●触发健康、快路径廉价、证据新鲜度、artifact 懒创建、authority boundary | ○容易越改越重，或把方法建议误说成最终权威 |
| 反熵治理 | ●delete-first / compat-exception / confirmation-first 路径选择 | ○常见做法是不断加 fallback 或 guard |
| Subagent runtime | ●显式请求时输出受控计划，真实执行必须有宿主 spawn / wait / merge 证据 | ○容易把角色扮演误称为真实多 Agent runtime |
| 离线验证 | ●offline loop drill 验证回滚与恢复路径 | ○很少验证关键闭环路径是否真的跑通 |
14
对比维度
覆盖路由、交付、迭代、发布、治理、验证等关键能力切片
7
层闭环
规划 → 路由 → 交付 → 迭代 → 发布 → 演练 → 团队引擎
8
专家 Agent
按语言、架构、安全、协作、产品、数据、契约等专长分工