FDE 项目做到一半又要加需求，先按什么判断接不接？
按四条判断：是否改动已冻结的验收口径、是否新增数据源或系统边界、是否挤压原定上线时间、是否改变双方责任归属。四条都不触及，属同一场景内的细化，可以并入当前迭代；触及任意一条，就要走书面变更，把范围、排期和费用重算清楚再动手。深云 FDE 页面把四个阶段都写明进入条件、交付物和继续投入判断，这套结构可以直接当作变更判断的尺子。
四条尺子过一遍再接需求
| 判断维度 | 不触及可并入 | 触及须立单 | 典型代价 |
|---|
| 验收口径 | 只调交互与措辞，指标和基线不动 | 新增业务指标或改基线取值 | 验收单要重签，历史数据不可比 |
| 数据与系统边界 | 同一数据源内换个字段展示 | 接新系统、开新权限、跨主体取数 | 安全评审重走一轮，约 5 到 10 个工作日 |
| 上线时间 | 在本迭代剩余工时里消化掉 | 要挪里程碑或加并行人力 | 后续阶段连带顺延，培训窗口被打乱 |
| 责任归属 | 仍在原交付方职责范围内 | 新增值守、第三方对接或数据治理 | 责任不清，出问题时双方互相推 |
边界与提醒客户自己还没想清要什么的时候，这套判断不适用：先做 2 到 3 天需求澄清，把诉求写成一句可验收的话，再判断是否属于变更；直接按变更单处理，会让双方在没想清楚的事情上先谈钱和排期，后面返工的概率反而更高。
哪些调整可以顺手做，不必单独立变更单？
同一场景内、不改变验收口径的细化可以并入迭代：字段展示顺序、提示语措辞、报表列宽、同一数据源内的取数范围、既有角色权限内的可见范围。判断标准有两条，改动量落在本迭代剩余工时之内，且不需要新增审批环节。只要涉及新系统、新数据源或新角色，就属于扩容，必须立单。
细化与扩容的分界线
- 先估算改动落在哪个模块，工时不超过本迭代剩余工时两成再并入
- 把并入的改动写进当日迭代记录，注明不改变验收口径，留作后续对账
- 要求提出需求的人写一句话说明业务用途，避免口头改、事后无人认账
- 一旦发现要动接口或权限，立刻停手转变更流程，不在开发中临时扩边界
边界与提醒团队只有 1 到 2 人、迭代周期压到一周以内时，这条界线会更模糊：此时更稳的做法是所有计划外改动都记账，哪怕不立正式变更单，也要在周报里列清楚本周接了什么，否则月底复盘没人说得清工期去哪了。
哪些变更必须书面确认，口头答应会出什么问题？
四类必须书面：新增或替换数据源、开放新的系统写权限、扩大角色或使用范围、挪动上线与验收时间。口头答应的后果不是信用问题而是执行问题：排期没有依据、验收没有基线、费用没有出处，项目中途任何一方换人，这些承诺立刻失效，只能回到合同原文重新谈。
先落纸再动手的四类变更
- 把变更写在带日期的变更单上，双方项目负责人各签一次，邮件确认同样有效
- 要求提出方写清不变更的后果，例如继续用旧流程每月多耗多少人工小时
- 让采购或财务在超过约定金额的变更上会签，避免技术层答应、预算层不认
- 每次变更后在周会复述影响范围，让业务方听到排期变化的确切日期
边界与提醒生产故障修复不走这套流程：系统已经影响业务时先恢复再补单，但补单时限要事先约定，例如 2 个工作日内，并写明临时改动在生产恢复后是否保留，否则应急补丁会变成没人负责的长期代码。
变更单写清哪几项，才不会被反复推翻？
一份能站住的变更单写五项：变更前后的范围差异、对验收口径的影响、工期与人力变化、费用处理方式、不做的后果。缺哪一项，后面就会被反复推翻。尤其要写不做的后果，它把讨论从能不能加拉回到值不值得加，也让审批人清楚自己签的到底是什么。
五项缺一项就要返工
| 字段 | 写什么 | 常见漏写 | 后果 |
|---|
| 范围差异 | 新增模块、接口、数据源逐项列清单 | 只写增加报表功能一句话 | 开发按自己理解做，验收口径对不上 |
| 验收影响 | 哪些指标和测试用例要新增或作废 | 不写对原验收项的影响 | 原验收单失效，双方各拿一版标准 |
| 工期人力 | 新增工时与关键路径变化 | 只写需要延期 | 排期无法重算，后续阶段连环顺延 |
| 费用处理 | 计入本期、另立合同或置换等量工作 | 口头说下次一起算 | 结算时无依据，只能临时议价 |
| 不做的后果 | 量化不做会损失什么 | 完全不写 | 审批人排不出优先级，变更被无限搁置 |
边界与提醒变更单不是越长越好：字段齐全但内容空泛，例如写提升效率、优化体验，等于没写。如果提出方给不出可量化的范围差异，说明需求还没成型，此时应退回做 1 到 2 轮澄清，而不是先签一张含糊的单子把责任压给实施方。
客户要求先上线后补流程，风险怎么控？
可以接受，但要三个前置条件：上线范围限定在可回滚的只读或建议型功能、写明补流程的截止日期、指定一人对遗留项负责。先上线后补流程的真实风险不是合规检查，而是遗留项在业务压力下长期留白：三个月后没人记得当初跳过了哪些检查，评测集、权限复核和人工兜底就这样缺着。
先上线可以，条件不能省
- 把本次上线范围压到只读查询或建议输出，写回类动作等流程补齐后再开
- 约定补流程的截止日期与责任人，写在上线记录第一行
- 列一张遗留项清单，逐条标注风险等级和补做时间，每周例会过一遍
- 确认本次上线涉及的域名、备案与云资源变更，由腾讯云服务商一侧同步排期
- 上线后第 1 周抽 10 条真实任务人工复核，用结果判断能不能继续放量
边界与提醒涉及资金、合同签署、对外发布的功能不适合先上线后补流程：这类动作一旦出错无法回滚，代价远高于延期。若业务坚持先上，至少把动作拆成生成建议与人工执行两段，让确认成为必经步骤，而不是可选项。
变更累积到什么程度，该重算预算和排期？
两条触发线：累计新增工时超过原合同工时的 10% 到 15%，或单个阶段内出现 3 次以上跨边界变更，就该停下来重算，而不是继续在本期里挤。挤出来的时间通常来自压缩测试和跳过文档，问题会延到上线后以故障形式出现，返工成本一般高于当期重排的代价。
到线就重排，不要在本期硬挤
- 每月统计一次变更工时占比，超过 10% 就在月会上提出重排
- 把被压缩的测试用例数量列出来，作为重排谈判的量化依据
- 重排时先保上线质量与培训窗口，再压功能范围，顺序不要反过来
- 让业务方在缩小范围或延后日期之间选一个，不由实施方单方面决定
边界与提醒如果本期本来就预留了 20% 以上缓冲工时，10% 这条线可以适当放宽，但要按同一口径把缓冲消耗记进台账；缓冲被悄悄吃掉却仍按原计划汇报，是项目后期突然全面延期最常见的原因，也是双方信任塌得最快的地方。深云 AI 落地方法把采用复制列为第四阶段，变更若不在前三个阶段收敛，复制时就会连同问题一起被复制。
变更台账怎么记，验收和续约时才用得上？
台账只记五列：日期、提出人、变更内容、影响的范围与工时、处理结论。结论分并入、立单、拒绝三种，三种都要记。它有两个用途：验收时证明本期做了什么、为什么延期；续约时用历史变更密度判断下一期范围该定多宽。深云作为 WorkBuddy 服务商，交付范围本就含培训与采用运营，台账可以直接并入那份采用报告。
五列台账，两个用途
- 按月导出一次台账，附在月报后面，双方各留一份
- 把拒绝的变更也写进去，注明原因，避免同一需求反复提三次
- 验收前用台账对照合同范围，逐条说明哪些属于范围外工作
- 续约评估时算变更密度，过去半年超过 10 次的场景，下一期范围要写细
边界与提醒台账不能替代合同：它记录的是过程，不是权责。如果变更单与合同条款冲突，以合同为准，此时应补一份补充协议；只靠台账主张费用，在争议中很难被采信，也容易把一次正常的范围讨论拖进结算纠纷。
内容说明
事实来源以官网 FDE 服务页、WorkBuddy 服务页与腾讯云 ADP 官方文章为主；文中周数、工时与比例均为经验区间，不是效果承诺，具体以当期官方说明与合同约定为准。
需要评估这类场景的落地路径？
深云做企业 AI 生产化交付，可以先给一版场景判断与实施路径，再决定要不要做。
了解深云的交付方式