编程开发 编辑复核
代码改动影响面与执行计划
在动手之前梳理依赖、行为约束、测试缺口和回滚路径，把大改动拆成能验证的小步。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是负责上线质量的资深工程师。请根据下面的需求和代码上下文，先判断影响面，再给出最小可验证的改动计划。
原则：
- 不假设没提供的文件、接口、数据库字段或部署权限存在。
- 先区分已知事实、合理假设和待确认项；缺少关键上下文时最多提出 5 个问题。
- 保留旧接口和可观察行为，除非需求明确要求破坏兼容性。
- 每一步都要有测试、观察指标和回滚动作。
输出模块：
1. 受众与机会判断：这项改动服务谁，解决什么痛点。
2. 价值主张或内容方案：改动带来的可验证结果与证据。
3. 转化路径与执行动作：文件、接口、数据和发布顺序。
4. 指标、实验和复盘清单：测试、日志、监控和停止条件。
需求：{{requirement}}
代码上下文：{{code_context}}
不可破坏的兼容性：{{compatibility}}
发布限制：{{release_constraints}}
最后给出“现在可以做 / 需要确认 / 不建议做”的分组，不要直接编写未经确认的生产脚本。HOW TO USE
使用说明
- 只提供与当前改动直接相关的代码，先让模型找缺口，再让它生成计划。
- 在执行前把计划中的每个文件和验收项映射到真实仓库。
WHEN IT FITS
适用判断
适合这些情况
- 改动会碰到多个模块，动手前需要先摸清调用链和受影响范围。
- 你能提供相关文件或接口定义，模型的判断可以当场核对。
- 需要把改动拆成可以分批合并的小步，而不是一个大 PR。
换个做法更好
- 你要的是重构时的模块边界划分：用《重构边界与依赖地图》。
- 改动只涉及单个文件的几行：直接改比写计划快。
- 你没法提供代码上下文：模型只能给出通用流程，对你的项目没有针对性。
FAILURE MODES
常见翻车与修正
- 计划里出现项目中并不存在的文件名或函数名。
模型会按常见项目结构补全。把实际的目录树和相关文件内容粘进输入，并要求所有路径都从你提供的清单里引用。
- 拆分出的步骤互相依赖，实际上没法分批合并。
要求每一步单独说明「合并这一步后系统是否仍然可用」，答案是否的步骤必须和前后步骤合并或调整顺序。
- 只列了要改什么，没说怎么验证改对了。
补充要求：每步都要写明验证方式（哪个测试、什么手动检查），以及出问题时的回退动作。
ACCEPTANCE
怎么判断输出合格
- 涉及的文件和接口都真实存在，能在仓库里找到。
- 每一步合并后系统都保持可用，不存在中间的破损状态。
- 每步都配了验证方式和回退动作。
- 标出了模型不确定、需要你人工确认的地方。
SAFETY BOUNDARY
使用边界
- 不要把生产密钥、数据库密码、用户令牌或完整私有仓库内容粘贴给模型。
- 涉及数据库、支付、权限和生产删除动作时，必须由负责人确认。