需求变更单不是“领导说加一个功能，所以记录一下”。它的核心是让决策人看清：为什么要变、具体改变什么、会影响哪些里程碑、需要增加多少资源、怎样测试，以及失败后如何恢复。AI 可以整理影响项，但不能替业务负责人批准变更，也不能凭经验猜工期和成本。
什么情况需要正式提交变更单
如果修改会改变已确认的范围、验收标准、交付日期、预算、外部承诺或关键技术方案，就应进入正式变更流程。单纯修正文案错字或在原验收标准内调整实现细节，通常不需要完整变更单，但仍应留痕。原需求尚不清楚时，先用AI写PRD提示词补齐用户场景、业务规则和验收标准。
提交前必须提供的事实
- 原需求、原验收标准和已批准的计划。
- 变更提出人、提出时间和业务证据。
- 希望新增、删除或替换的具体内容。
- 当前项目阶段和已经完成的工作。
- 受影响的团队、系统、合同和用户。
- 可选方案，包括保持原方案。
- 需要决策的截止时间。
可直接复制的需求变更单提示词
你是一名需求变更评估助理。请根据原需求、变更提议和项目事实生成一份可评审的需求变更单。不要编造业务收益、工期、成本、资源承诺、技术实现或审批意见。
项目名称：[填写]
原需求与验收标准：[粘贴已批准内容]
原计划与里程碑：[填写日期和交付物]
变更提议：[新增、删除或替换什么]
变更原因与证据：[用户反馈、政策、数据或业务事件]
当前完成状态：[填写已完成和进行中事项]
参与团队与依赖：[填写]
已知约束：[预算、合同、合规、上线窗口等]
可选方案：[如有]
最晚决策时间：[填写]
请输出：
1. 变更摘要：原内容、拟变更内容、提出人、提出日期和决策截止时间
2. 业务价值：要解决的问题、证据、预期结果和无法确认项
3. 范围差异表：新增、删除、替换、不变内容
4. 影响评估：进度、人员、成本、测试、数据、接口、运营、合同和合规
5. 方案比较：保持原方案、接受变更、拆分到后续版本等选项及代价
6. 实施与回滚：前置条件、步骤、验证方法、暂停条件和恢复状态
7. 决策记录：批准、附条件批准、延期或拒绝，保留理由和批准人位置
8. 待确认问题：缺少证据、冲突信息和需要专业人员判断的事项
规则：
- 变更理由不等于批准理由，必须同时展示收益和代价
- 工期、成本和资源没有负责人确认时标记“待评估”
- 已完成工作可能产生返工时必须单独列出
- 测试影响要覆盖正常、异常、权限、数据和回归场景
- 涉及合同、财务、隐私、安全和法律事项时只做识别，不给专业结论
- 不删除原需求和原计划，确保评审者能看到差异
输出后自检：
- 是否能一眼看出原需求和新需求的差异
- 是否列出了对日期、人员、成本和测试的影响
- 是否提供了至少一个不实施当前变更的替代方案
- 回滚方案是否说明触发条件和恢复状态
- 决策结果是否有明确批准人和时间示例：新增短信验证码登录
原需求：本期仅支持账号密码登录，7月30日完成业务验收。
变更提议：本期增加短信验证码登录，理由是部分用户忘记密码导致客服咨询增加。
影响评估摘要：
- 业务证据：最近两周登录类工单中有38%与忘记密码有关，但尚未确认短信登录能减少多少工单。
- 范围：新增验证码发送、频率限制、过期处理、手机号校验和异常提示。
- 进度：开发和测试负责人初步评估增加4个工作日，原验收日期需重新确认。
- 成本：新增短信服务费用和供应商配置，金额待采购确认。
- 测试：增加发送成功、过期、错误次数、限流、无手机号和渠道失败场景。
- 替代方案：本期优化找回密码入口，短信验证码登录进入下一版本。
- 回滚：通过功能开关关闭短信入口，保留账号密码登录。
这个示例没有因为“用户需要”就自动批准，而是把数据、成本和日期的不确定项交给对应负责人。合同交付范围可能受影响时，可用AI合同条款对比提示词整理差异；新增风险应同步进入项目风险清单。
四种明确的决策结果
- 批准：影响已确认，按新范围执行。
- 附条件批准：满足预算、技术验证或资源条件后执行。
- 延期：价值存在，但信息或资源不足，进入指定版本再评估。
- 拒绝：收益不足、代价过高或不符合目标，并记录理由。
AI整理需求变更的失败边界
AI 不能确认估算是否真实，也不能代替产品、研发、测试、财务、法务和管理者签字。变更批准后，应把新日期和动作同步到项目周报；面向用户的操作变化可再用产品使用说明书提示词更新文档。