阶段 5 · 推广与度量

把试点成果放大到全团队，并用数据证明"真的提效了"——不可度量 = 不可管理。

1. 为什么：试点成功后，要规模化 + 可衡量

阶段4 在试点团队跑通了闭环，阶段5 要解决两件事：①放大——从试点到全员、从单任务到大规模重构；②证伪——用数据回答"到底提效了多少、质量降没降"。最危险的状态是"大家觉得有用但说不清提升了多少"，这会让投入无法持续。

2. 多 Agent 并行编排（规模放大器）

• face-agent-teams（前端组-韩炎军，基于 tbc-lcp）：多 Agent 团队编排框架——6 步流程 + 4 种策略 + 项目注册表跨项目复用 + 5 个人机确认点 + 质量验收打回闭环。
• psmux 多端并行：一个终端驱动多个 Agent 并行开发不同端（曾梳理 mina-face 小程序项目，发现端点冗余并合并）。
• code-review 多 Agent（学习研发组-李胜男）：Haiku 资格检查 + 5 个 Sonnet 并行专项审查 + 独立 Haiku 打置信度分（阈值 80 才发评论）。

2.1 远期演进：全流程 Agent 微服务闭环（成熟期目标）

多 Agent 并行是"横向放大"（同时干多个任务）；更远的终局是"纵向贯通"——把"非技术人员提需求 → AI 全流程执行 → 部署上线"串成一条 Agent 微服务流水线。这是成熟期愿景，不是起步就建：

• 顶级 Agent：接收（语音）需求、语义解析、任务分发、异常兜底。
• 6 个专项 Agent（各管一段，接口标准、按项目隔离权限）：
  1. 需求定位——调 RAG / 代码图谱，定位需求对应的项目与功能模块。
  2. 接口规划——按接口规范规划，优先复用已有接口，避免重复开发。
  3. 代码生成——调公共 + 项目级 Skill 及 RAG 业务数据，生成 Controller / Service / Mapper 等。
  4. 自检查——对照开发规范校验生成代码，输出报告 + 修改建议，直至合规。
  5. 测试——生成自动化测试用例并执行，不过则回传代码生成 Agent 优化。
  6. 部署——测试通过后自动提交代码、部署到对应环境。
• 数据底座：RAG 向量库（业务数据）+ 代码知识图谱（代码结构），见阶段3。

3. 效果度量：AI 代码占比

自研 Go CLI ai-code-ratio，通过 Git 提交元数据识别 AI 代码。最可靠信号是 Co-authored-by trailer（AI 工具默认埋点），再加风格学第二道防线防伪造：

// coauthored.go · Co-authored-by 检测
var coAuthoredByLineRe = regexp.MustCompile(`(?i)co-authored-by:\s*([^\n]+)`)
var defaultAINames = []string{"claude", "copilot", "cursor", "chatgpt", "codeium", "gemini"}
// 解析 commit message 的 trailer，按工具名优先级匹配，命中即置信度 1.0

// 风格学反伪造：作者历史 n-gram TF-IDF 余弦相似度复核
// 越像本人手写 → AI 署名可信度越低（应对 VS Code Copilot 误标 bug）
func ConfidenceFromSimilarity(s float64) float64 {
    if c := 1.0 - s; c < 0.1 { return 0.1 } else { return c }
}

双口径：提交占比 + 行数占比（后者更真实）。支持按作者/模块/周下钻趋势。

估算目标约 75%（视业务结构在 70-80% 浮动）；下方 §4 实测 AI 代码占比落在 20-40% 区间，与估算口径不同（估算含"AI 辅助优化"，ai-code-ratio 实测只认 Co-authored-by + 风格学可证伪的部分）——估算给方向，统计给真相，两者独立。

4. 各组推广 + 量化效果

14 个组各自落地真实场景，量化效果如下（同比窗口 2026年3-5月 vs 2025年3-5月）：

注：「Git/上线记录统计」是转型跑完后用度量工具算出来的，推进过程中看不到——别拿它当中间指标卡进度；「案例」是各组真实分享的场景。所有数字都是 2026年3-5月 vs 2025年同期的对比，提效和 AI 转型同期发生，但不能 100% 都归功于 AI（需求、人员变动也有影响）——量级足以说明 AI 转型和显著提效强相关。

5. 角色视角 + 常见坑 + 清单