每个新需求都不大，项目却越做越慢
最初的目标可能只是让 AI 整理客服工单。试点一周后，销售希望同步读取 CRM，负责人希望自动发日报，市场又想用同一套系统生成公众号素材。单看每个要求都不复杂，放到一起就跨了数据、权限、流程和部门。
团队如果每次都口头答应，原来的验收标准很快失效。工程师忙着接新接口，业务以为系统马上能用，最后大家都觉得进度拖延。问题不在谁提出需求，而在项目没有清楚记录变化带来的代价。
变更单只需要回答六个问题
轻量变更单不必做成复杂审批系统，只要写清：为什么要加、谁会使用、需要什么数据、会执行什么动作、影响哪些原功能、由谁验收。再补上预估工期和是否需要调整上线日期，就能让讨论回到具体事实。
尤其要写明权限变化。一个只读摘要功能变成自动写入 CRM，风险等级已经不同；一个部门使用变成全公司使用，账号、培训和支持也会变化。模型调用多一步只是小事，责任边界变化才是大事。
- 新增需求对应什么业务问题和使用人。
- 会增加哪些数据、权限、接口和错误后果。
- 原定范围、排期和验收指标需要怎样调整。
不要把所有需求都排进当前版本
变更记录完成后，可以分成必须现在做、可以下一版做、暂时不做三类。影响合规、数据准确或核心流程的问题应优先；只是让界面更方便、覆盖更多边缘场景的需求，可以留到主流程稳定以后。
拒绝当前版本不等于拒绝业务。给出原因、前提和后续时间，通常比一句“技术做不了”更容易合作。FOMO 式加功能会让试点永远没有结束，企业也无法判断最初目标是否真的有效。
需求变化后，测试和培训也要跟着变
功能增加，不是代码写完就结束。问题集、测试数据、异常处理、权限检查和员工说明都需要更新。如果 Agent 新增对外发送能力，就要重新测试错误内容、重复发送、收件人范围和人工审批，不能沿用原来的只读验收。
培训也要说明哪些能力已上线、哪些还在试点、遇到异常找谁。员工看到界面上有按钮，就会默认可以使用；范围没有同步，现场很快会出现“为什么别人能用我不能用”的问题。
变更记录最终是为了保住业务结果
项目复盘时，把变更次数、原因、影响和结果放在一起看，可以发现需求是否来自真实使用，还是来自不断扩大的想象。高频出现的合理需求可以进入产品路线，偶发且成本高的需求则应保持定制。
企业 AI 项目变化快，完全冻结需求并不现实。真正需要的是让变化可见、可讨论、可验收。变更单不是用流程拖慢业务，而是提醒所有人：每一个“顺便”，都要有人为新增复杂度负责。
要点总结
- 只要会改变数据、权限、外部动作、使用部门、验收或排期，就值得留下简洁记录。
- 简洁记录通常只需很短时间，却能减少返工、误解和无休止的范围扩大。
- 应由业务负责人和技术交付负责人共同判断，必要时让安全或法务参与。
参考来源说明
本文围绕“企业 AI 项目最怕一句“顺便再加个功能”：变更单不是形式主义”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。