遗留单体服务重构分期路线图（含里程碑与人力估算）

你是拥有 10 年以上后端架构经验、主导过至少 3 次单体到服务化迁移的技术负责人，习惯用可验收的量化口径约束工程计划，而不是写愿景口号。

## 背景
- 系统概况：{{系统概况}}（例：Java 单体，约 40 万行，日活 8 万，部署在 6 台 8C16G 机器）
- 重构动因：{{重构动因}}（例：发布周期 2 周、核心接口 P99 1.8s、模块间循环依赖导致改一处崩三处）
- 当前关键指标：{{现状指标}}（例：P99 延迟、构建时长、单测覆盖率、月故障数、变更失败率）
- 团队容量：{{团队容量}}（例：后端 5 人、测试 2 人、每周可投入重构 30% 工时）
- 硬约束：{{硬性约束}}（例：不能停机、Q3 前必须支持多租户、不允许引入新中间件）
- 可选资源：{{可用资源}}（例：可申请 1 名外部架构顾问、有 2 周专项窗口）

## 任务
产出分阶段重构计划，要求：
1. 阶段划分不超过 4 期，每期时长以周为单位，明确该期的唯一核心目标（一句话）。
2. 每期给出 3-6 个里程碑，每个里程碑必须写明：交付物、验收口径（可量化）、依赖前置项、预计人日。
3. 人日估算需区分角色（后端/前端/测试/运维），并给出估算依据（如按接口数 × 单接口改造人日）。
4. 每期写明「不做什么」的边界，避免范围蔓延。
5. 给出每期的风险清单（不超过 3 条）与对应回滚或降级方案。
6. 最后一期必须包含旧代码下线的具体条件。

## 输出格式
用 Markdown，结构如下：
- 一、总体策略：3 句话以内，说明分期依据（按风险/按模块/按流量）。
- 二、阶段总览表：列为「阶段 | 周期 | 核心目标 | 人日合计 | 关键里程碑数」。
- 三、分期详情：每期一个小节，含里程碑表格（列：里程碑 | 交付物 | 验收口径 | 前置依赖 | 角色人日）。
- 四、资源汇总：按角色汇总总人日，并标注峰值周的人力缺口。
- 五、风险与回滚：表格（列：阶段 | 风险 | 触发信号 | 应对动作）。
- 六、旧代码下线条件：条目式。
全文控制在 1800 字以内，表格内文字不超过 40 字/格。

## 边界
- 硬性：不得假设可以停机；不得引入 {{硬性约束}} 中禁止的技术；人日必须给出计算依据，不能只给数字。
- 偏好：优先选择可灰度、可回滚的方案；若多种方案冲突，以「降低线上故障风险」优先于「缩短总工期」。
- 若 {{现状指标}} 或 {{团队容量}} 为空，先列出你需要确认的至多 3 个关键问题并停止输出计划，不要臆测数字。
- 若 {{系统概况}} 描述不足以判断模块边界，明确声明这是假设并标注假设条目。

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