这张卡讲驻场交付最常见的慢性病：范围怎么一点点失控的。
核心拆解：蔓延不是一次大决定造成的，而是几十次「顺手帮个忙」累积的。驻场场景结构性高发，因为面对面让口头需求的提出成本趋近于零，客户顺手一提，你顺手一做。AI 项目还有新变种——效果改进永无止境，「再调一版」没有自然终点，蔓延以优化的名义发生，工时却真实流失。
增量判断：对策不是拒绝帮忙，而是把「可以帮」变成有价格的动作：范围基线书面化、任何新增走变更请求、口头承诺当场转成书面确认。国内关系文化下直接说不会得罪人，说「可以，走个变更」才是专业，群消息里的确认同样算书面。识别蔓延的关键动作是记录：没有记录，事后连争论的事实基础都没有。
行动建议：复盘你手上项目最近两周新增的工作，逐条标注是基线内还是基线外，后者统计工时。基线外工时就是下次变更谈判的筹码。
—— FDEChina编辑部 · 实战派
定义
范围蔓延（Scope Creep）指项目范围在未经正式变更控制的情况下持续扩张，每次增量很小、不易察觉，累积后逐步吃掉工期、毛利与交付质量，是项目失控的头号慢性病因。
展开
驻场场景结构性高发，原因在沟通成本：面对面工作让口头需求的提出成本趋近于零，客户在走廊里顺手一提，工程师顺手一做，双方都觉得不是「正式需求」。Forward Deployed Engineer（FDE）比传统驻场更容易中招——现场闭环能力强意味着答应得快。AI 项目还有新变种：效果改进没有自然终点，「再调一版」可以无限持续，蔓延以持续优化的名义发生，连客户都意识不到自己在扩张范围。对策三件套：签约或启动时建立书面化的范围基线；一切新增走变更请求（Change Request），有单价有时间表；口头承诺当场转成书面确认，哪怕只是一条消息。
常见误用是把对策理解成拒绝帮忙。正确的姿态是把「可以帮」变成有价格的正式动作——国内关系文化下，说「这个可以做，我们走个变更」不伤关系，反而显得专业；默默吸收范围才会在验收时引爆矛盾。