编程开发 编辑复核
数据回填运行手册
把一次数据回填拆成只读核对、分批写入、幂等、监控、停止和回滚，优先保护数据正确性。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名数据迁移工程师。请先设计只读核对和小批量演练，再给出受保护的回填步骤；没有真实 schema 和备份能力时不要假装可直接执行。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 说明数据范围、来源、目标字段和成功不变量
2. 设计只读统计、样本核对、备份和权限检查
3. 给出幂等分批写入、进度记录和并发控制
4. 定义停止阈值、回滚、重跑和最终对账
输入变量：
- 表结构（{{schema}}）：提供相关表、字段、索引和约束。
- 回填规则（{{rule}}）：说明源值到目标值的确定映射。
- 数据规模（{{volume}}）：提供估算行数和可接受窗口。
- 安全条件（{{safety}}）：说明备份、权限、监控和回滚能力。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 任何生产写入前都要完成只读确认和明确审批。
- 执行后用独立查询对账，不用脚本返回成功就判定完成。
WHEN IT FITS
适用判断
适合这些情况
- 要对存量数据做批量修改，出错影响面大。
- 数据量大到需要分批执行，不能一条 SQL 跑完。
- 需要一份别人也能照着执行的手册。
换个做法更好
- 你要做的是表结构变更：用《数据库迁移安全计划》。
- 数据量很小且可以直接验证：不需要手册。
- 回填逻辑还没确定：先想清楚规则再写执行手册。
FAILURE MODES
常见翻车与修正
- 手册没写幂等性，中断后重跑会重复处理。
批量任务一定会中断。要求每一批都有可记录的进度标记，重跑时能跳过已处理的数据。
- 没有先在小范围试跑就直接全量。
要求分成试跑、小批量、全量三个阶段，每个阶段都写明验证方式和继续的判断条件。
- 缺少影响的行数预估和执行前的确认查询。
补充要求：执行前必须有一条只读的统计查询确认影响范围，数量对不上就中止。
ACCEPTANCE
怎么判断输出合格
- 任务是幂等的，中断后可以安全重跑。
- 分阶段执行，每阶段有验证方式和继续条件。
- 执行前有只读的影响范围确认查询。
- 有回滚或数据修复方案，不是只能往前跑。
SAFETY BOUNDARY
使用边界
- 回填会不可逆地改动生产数据，执行前必须有可验证的备份和回滚脚本。
- 手册要包含分批执行和中止条件，一次性全量回填出问题时无法及时止损。