模块迁移可审 PR 说明
你是遗留栈迁移助手。根据模块边界与依赖图，起草一份中文「可审 PR」说明。禁止建议一次切全生产；禁止输出真实密钥或生产连接串。
输出：
## 模块范围与非目标
## 改动文件/迁移步骤摘要
## 测试计划与验收标准
## 回滚命令或特性开关
## 影响面与值班注意
## 非目标（不一次切全量、不直接点生产发布）
输入：
{{module_inventory}}场景说明
遗留产品换栈风险大：依赖缠绕、测试薄、一次切换易出事。约定用编码 Agent 按模块拆迁移：每模块独立分支、可审 PR、配套测试与回滚说明；先影子流量或特性开关验证再逐步放量。硬约束：分模块可审 PR；有回滚；不一次切全生产。密钥与生产配置不进 Agent 上下文明文；关键路径必须人审 diff 与 CI。
案例叙事
01他们做了什么
DEV.to（AWS Community Builders）作者 Karthik Subramanian 记述以 Claude Code 为主平台编排真实产品迁移：四套遗留仓收成两套、MySQL→PostgreSQL、全栈框架升级（如 Spring Boot 2→3、Java 17→21、React 17→18）、认证模型替换与配套测试。作者强调「设置即策略」：多层 CLAUDE.md、记忆规则、设计评审后再拆可审工单；执行上用 worktree 并行、MR/CI 闭环，合入前人工把关。作者自述 POC 约 15 个工作日、约 50 张工单、约 580 项测试通过，QA 交接时自称 API 覆盖约 95%+、前端约 91%，并称 API token 花费近 5000 美元量级；另称一次会话拆出约 19 张 Jira、AI 初审大约能抓住三到四成偏低层级问题。公开文未给出生产事故率或「一次切全量」对照实验。
国内落地对齐「分模块可审 PR + 回滚/特性开关 + 灰度放量」：先盘模块边界与回滚策略，低风险模块先行；密钥与生产配置不进 Agent 上下文明文。硬约束：不一次切全生产；每个 PR 写清回滚命令/开关与影响面；生产切换清单单独人工把关，Agent 不得直接按生产发布按钮；关键路径人审 diff 与 CI。
02实际效果
- 源未披露生产环境一次切全量对照下的事故率、回滚次数或业务中断时长等量化；公开文侧重「上下文与工单拆分 → 并行可审 MR → 人审放量」的编排叙事。
- 作者自述：约 15 个工作日完成规划到 QA 交接量级的迁移 POC，约 50 工单/约 580 测试，并给出覆盖率与近 5000 美元 token 成本等自述口径（文中陈述，非我方实测，不可外推为普遍工期或成本）。
- 团队可把缠绕换栈收成「模块级可审 PR + 回滚说明 + 灰度」；是否合入、是否打开生产开关仍由人依据 CI 与值班清单决定，禁止 Agent 一次切全生产。
03值得知道
- 公开源未给出可复用的生产稳定性基线，上线后用自有模块与回滚演练复盘，勿把作者个人 POC 覆盖率/花费写成承诺。
- 硬约束：分模块可审 PR；必须有回滚路径；禁止一次切全生产；禁止 Agent 直接操作生产发布；密钥/生产配置禁止进上下文明文。
- 模型可能漏改依赖或误删仍被回调引用的状态；CI 与人审不可省；大文档/工单同步工具可能截断，重要变更以仓库与人工确认为准。
04可复制提示词
灰度放量检查表（飞书）
把迁移 PR 压成飞书/企微放量检查表（≤180 字）：模块名、CI 状态、回滚入口、影子流量/开关是否就绪、是否需人工点发布。必须出现「禁止一次切全生产｜Agent 不得按发布按钮」。不要编造未提供的覆盖率数字。
PR 摘要：
{{pr_digest}}怎么做
- 盘点模块边界、依赖图与回滚策略，划定首批低风险模块
- Agent 按模块生成迁移改动与测试，开独立可审 PR
- 人审合入后灰度/特性开关放量；异常立即回滚该模块
实用提示
- 每个 PR 描述写清「回滚命令/开关」与影响面，方便值班
- 生产切换清单单独人工把关，Agent 不得直接操作生产发布按钮