设计项目变更与交付范围核对

01 / 业务问题

教学模拟情境：客户在评审中提出新的页面、素材和修改意见，项目经理需要分清原约定内修订、新增需求与尚未达成一致的建议。

02 / 改造前流程

设计师从会议纪要和聊天截图接收反馈，直接开始修改；口头建议与正式批准混在一起，交付范围、工时和验收版本难以追踪。

03 / 明确任务范围

整理反馈、映射交付项并起草变更申请；不自动接受客户新增承诺、不调整合同金额、不指派超预算工作或发布设计。

04 / 资料输入

1. 批准的工作说明书、交付清单和验收条件
2. 授权会议纪要、评审批注及设计版本索引
3. 团队工作量估计、项目排期和变更批准权限

05 / AI 接入与工作流

1. 模型拆分评审反馈并关联设计版本，保留提出者、原话和确认状态。
2. 规则核对每条反馈是否对应原交付项，模型提出范围归类建议，边界模糊时交项目经理判断。
3. 确定性比较受影响任务和排期依赖，工作量只使用团队给出的估计，不由模型伪造精确工时。
4. 项目经理审核范围与影响，设计负责人确认可行性，商务负责人决定是否需要客户批准变更。
5. 输出变更申请与修订任务草稿，只有获得相应审批的事项进入执行清单。

06 / 人工复核节点

项目经理负责范围判断，设计负责人核对工作影响，商务负责人批准价格和承诺；客户随口建议不能自动被记录为确认需求。

07 / 交付物

1. 反馈到交付项的映射表
2. 范围、排期和依赖影响说明
3. 待审变更申请及修订任务草稿

08 / 验收口径（目标）

验收目标：每条执行任务对应已批准需求及设计版本；新增范围有明确待审状态；原计划与估计影响分开，未经确认不得改写对客承诺。

09 / 测试方法（假设测试集）

假设测试集包含同一反馈的不同表述、撤回建议、跨版本批注和新增交付格式；核对去重及审批状态，验证未批变更不会进入执行清单。

10 / 数据权限与风险边界

客户材料和未发布设计按项目隔离；模型不得复制其他客户方案作为交付，也不能自行接受知识产权或保密条款变更。

11 / 实训任务

让客户批准视觉修改但拒绝新增交互，要求学员将混合请求拆分，并演示部分批准如何影响任务、范围和验收记录。