代码评审体系分阶段落地路线图（含里程碑与人力估算）

你是{{角色设定}}，曾主导过 200 人以上研发团队的代码评审制度落地，熟悉 Gerrit/GitLab MR/PR 流程、评审 SLA 与质量度量。现在请你为下述团队产出评审体系落地的分阶段计划。

【背景材料】
- 团队规模与结构：{{团队规模与结构}}
- 当前评审现状：{{评审现状}}
- 主要痛点：{{核心痛点}}
- 技术栈与代码托管平台：{{技术栈与平台}}
- 计划总周期：{{计划周期}}（如 3 个月 / 2 个季度）
- 可用资源上限：{{资源约束}}
- 组织硬性约束：{{组织约束}}

【产出要求】
输出一份 Markdown 计划书，且必须包含以下五个部分，顺序固定：
1. 现状诊断：用不超过 5 条要点概括问题，每条标注严重度（高/中/低）。
2. 阶段划分：固定拆为 3 个阶段（试点期 / 推广期 / 固化期），每阶段给出：阶段目标（1 句）、起止周次、关键动作（3-5 条，动词开头）、里程碑（含可验证的验收标准）、负责人角色、人力投入（人日，给出区间）、工具/平台成本（如有）。用表格呈现，列为：阶段 | 周次 | 目标 | 关键动作 | 里程碑与验收标准 | 负责角色 | 人日估算。
3. 度量指标：给出 5-7 个可量化指标，含指标名、定义、目标值、采集方式、采集频率。至少覆盖评审覆盖率、首次响应时长、单 MR 评审时长、缺陷逃逸率。
4. 资源与成本汇总：按阶段汇总人日，并给出总计。若 {{资源约束}} 为空，按「1 名兼职负责人 + 每 10 名开发配 1 名评审骨干」估算并明确标注为假设。
5. 风险与应对：3-5 条风险，每条含触发信号、影响、应对动作。

【约束】
- 硬性：所有里程碑必须可验证（有数字或明确产出物），禁止出现「持续优化」「加强意识」这类不可验收表述。
- 硬性：不得假设引入需要采购的新平台，除非 {{技术栈与平台}} 中已包含。
- 偏好：优先复用现有工具链；若必须新增，须注明最小可行替代方案。
- 冲突优先级：资源约束 > 周期约束 > 指标完备性。若三者不可兼得，先压缩指标数量，再延长周期，不削减里程碑可验证性。
- 全文控制在 1200 字以内，表格不计入字数。

【信息不足处理】
若 {{评审现状}} 或 {{核心痛点}} 为空，不要臆测，先在开头列出你需要确认的 3 个最关键问题，并基于「团队尚无正式评审流程」这一默认假设给出计划，同时标注哪些结论依赖该假设。

还有 4 个必填变量未填，补齐后才能复制