技能提升网距离交付只剩三个工作日，客户又提出部门权限和批量导出。项目经理现在需要作出一个具体判断：两项都接，原定日期是否还能兑现？如果只回复“应该可以”，开发、测试和客户很可能各自理解出一个不同的承诺。
有用的回复要带着依据：原先答应做什么，这次增加了什么，需要多少工作，以及哪些条件还没确认。下面的项目和工时均为演示数据，用来说明怎样把追加需求变成可讨论的交付选择。
把客户原话对回已经确认的版本
先拿到已确认的 Word 方案、验收标准、当前任务表、团队可用时间和客户本次追加需求的完整记录。方案需要有明确版本与确认依据；如果只有几份文件名都叫“最终版”，先核对采用哪一份，不能让 AI 自行挑最新修改日期。
示例的 v1 方案只包含管理员权限下的单条导出，客户现在希望按部门限制记录可见范围，并增加批量导出。交给 DOCX Skill 读取原文并整理对照，保留原条款位置、客户原话、新增行为和未决问题。涉及已有文档修订时，另存变更版本，保留批注或修订记录。
“批量导出”还需要明确选择上限、字段、空结果处理、失败提示和权限校验。部门权限则涉及跨部门查看、管理员例外及已有数据如何归属。没有确认的部分进入问题清单，不应作为确定工作量悄悄填进计划。
变更项可以编号为 CR01、CR02，并各自填写提出时间、原范围、新范围、验收差异、估算人、确认状态。这些字段让之后的费用或日期讨论能指向同一件事。
工作量由团队估，Skill 负责算清楚
XLSX Skill 适合整理任务表、可用工时和方案比较。它可以根据已提供的估算计算缺口，但“新增两个按钮需要多久”不能只靠按钮数量推测，更不能把它生成的数字当成开发承诺。
为便于解释，本例假设所有剩余开发和自测由同一负责人承担。三个工作日每天实际可投入 6 小时，剩余容量为 18 小时。原任务还需 12 小时；团队评估新增部门权限 4 小时、批量导出 5 小时、相关回归自测 3 小时，新增合计 12 小时。
原任务加新增工作共 24 小时，比 18 小时容量多 6 小时。这个结果足以说明原计划容纳不下已估算范围，但还不足以承诺“只延期一天”。新功能之间的依赖、环境准备、客户确认和独立验收可能进一步影响日期。
若由多人协作，按人、按日列容量，并注明前置任务。不能把三个人各空闲两小时简单当成某一位关键开发可用的六小时，也不能默认新同事加入就立即增加同等产能。请假、会议、其他项目已占用时间要在可用容量里扣除。
把选择写成三个可以回复的方案
保留原日期：按 v1 范围交付，新增项单独排期。需要客户确认分期是否仍满足当前使用目标，且不要把后续批量导出写进本期验收承诺。
保留新增范围：让团队根据依赖重排日期，补充测试和客户验收时间，再给出新的里程碑。先提出预计区间或待确认节点，也比直接承诺一个没有排过的日期准确。
调整本期范围：如果客户愿意换出某些原功能，需要明确删去什么、替换后哪些验收项失效。只有团队确认释放出的工作量和新增工作可替代，这个方案才成立。
三个方案各写明本期交付、延期或后置部分、待确认事项和费用影响状态。没有获得商务确认的金额标成待确认；这里处理的是范围与排期信息，不替任何一方接受新的合同义务。
变更确认单至少留住这些信息
回到 DOCX Skill，将选定方案整理成单独的变更确认单。文件中保留原方案版本、CR 编号、变更内容、验收变化、排期依据、新里程碑、负责人和确认位置。Word 文档与计算表引用同一版本，不能正文写了“仅做部门权限”，附表却仍计算两项功能。
请对照已确认方案与客户新增记录，列出原范围、新范围、未决问题和验收变化。工时仅使用团队提供的数据，未知部分单独列出。根据每位负责人的实际容量计算缺口，给出保日期、保范围和范围置换三个待确认方案，最后制作带版本与变更编号的 Word 确认单。
发出之前，让团队核对工时、依赖和测试安排，再检查文档中的功能名称、日期和数字是否与表格一致。客户回复后，把具体确认内容落回相同 CR 编号，不能只留下聊天记录中的一句“好的”。
真正需要争取的是一个可执行的决定：这次做哪些、什么时候交、按什么验收。等这些内容明确，再更新任务和对外承诺。
