对照需求基准整理变更内容

这个场景能帮你做什么

“只是改一点”必须先说明相对哪份已确认需求改变了什么。WorkBuddy 可以对照需求基准与新增申请，整理增删改、理由和需要评估的下游对象。

开始前需要准备什么

提供已经批准的需求版本、变更申请或确认记录、当前实现进度和相关设计测试资料。明确本次对象与确认人，口头讨论和正式批准分别标明。

具体怎么做

第一步：确定基准

核对原需求的版本、范围和批准状态，没有共同基准时先整理差异供双方确认，不能直接计算变更量。

第二步：逐条比对新旧要求

保留原编号、旧描述、新描述、增删改类型与理由。把表述澄清与真实范围变化区分，编号改名不自动算新增功能。

第三步：标出受影响工作

关联已经开始的设计、实现、测试、采购或交付准备，列可能返工与需要重新估算的事项。AI 只根据资料提示，不凭一段需求估计所有工时。

第四步：形成批准材料

输出变更内容、待补信息、评估责任与决定项。未批准申请保留为候选，不直接回写正式需求或通知执行。

可以直接交给 WorkBuddy 的完整要求

以附件已批准需求版本为基准，整理变更申请的逐条增删改与原文出处。
区分澄清、改名与真实范围变化，保留旧值、新值、原因及状态。
关联当前已开展工作，列需评估的设计/实现/测试/交付影响和责任人，不编工期成本。
输出变更评审表，不批准、不替双方更新正式约定。

完成后会得到什么

一份能让双方确认“到底改了什么”的差异表，以及后续影响评估任务。

结果应该怎么检查

逐项核对基准与确认记录，检查隐含范围、接口和验收是否随功能一起变化，已经执行的旧工作是否遗漏。

遇到这些情况怎么处理

原需求版本不清时先确认基准。不同人同时提变更时分申请记录，再检查相互冲突。口头修改缺确认时先补记录，不事后伪造批准。

哪些必须人工决定

项目、产品与研发负责人确认范围、代价和批准状态。AI 整理差异，不使申请自动生效。