观望：没人对结果负责
项目挂在 IT 部门，业务方只提供数据不参加评审，模型输出与真实判断脱节。化解办法是把业务负责人写进里程碑签字人，定界会由业务方主讲场景与数据口径，否则后面必然返工，责任也落不下去。
安全：评审要前置
安全部门担心的通常不是模型本身，而是数据流向不明。提前给出字段级清单、部署位置、留存与删除策略，让评审在原型前完成，可避免上线前被整体叫停，评审意见要逐条落成待办并指定责任人。
焦虑：把岗位变化讲清
员工抵触多来自不确定。明确哪些动作由模型生成、哪些必须人工复核，配套转岗与技能培训，比反复强调工具属性有效。管理层要给出人员安排的时间表，模糊表态会让抵触转为消极配合，甚至影响数据质量。
膨胀：变更要有代价
每次追加需求都记录影响的范围、工期与验收变化，由双方负责人确认后再排期。没有代价的变更会吞掉整个周期，最后所有人都认为是对方拖延，变更登记表比口头承诺可靠，也便于事后核算成本。
适用与不适用
适合谁
- 已经立项、但推进明显变慢的陪跑项目
- 需要向管理层解释阻力的项目负责人
不适合谁
- 希望靠一次动员会解决配合问题的管理者
典型场景
某零售企业的门店补货建议项目在第三周停滞：运营不参加评审，IT 担心数据出内网，店长担心被系统考核。项目组把评审改成运营主讲，先用脱敏样本在内网跑原型，并把系统定位为建议而非考核依据，两周后恢复推进，评审也回到常态。
可执行步骤
- 逐条列出当前阻力清单，标注影响人、影响程度与首次出现的时间，并按影响排序
- 把业务负责人写进里程碑签字人名单，定界会由业务方主讲场景与痛点
- 原型开发前完成数据分级、字段清单与安全评审，把评审意见逐条落成待办
- 明确人机分工、复核责任与人员安排，并同步到班组与现行考核口径，形成书面记录
常见坑
- 用行政命令压配合，短期看似有效，项目转入常态运营后往往没人维护、也没人敢改，配合要变成岗位职责。
- 安全评审拖到上线前才做，整改范围大，进度与预算同时失控，还可能整体叫停，前置评审成本更低。
- 对人员安排含糊其辞，员工用消极配合表达不满，标注质量与数据准确性随之下降，应给出明确时间表。
自检与验收清单
- 业务负责人是否在里程碑文件上签字并参加评审
- 数据分级、字段清单与安全评审是否在原型前完成
- 人机分工、复核责任与人员安排是否已经书面化
- 是否有变更登记表，并记录每次影响评估的结论
常见问题
阻力主要来自哪一层？
多数来自中间层：业务负责人不愿承担结果，IT 担心运维与安全，一线担心考核。高层支持只能解决授权，中间层的顾虑需要具体安排来回应，否则项目会在执行层被慢慢拖住。
员工抵触算不算正常？
正常。岗位内容变化会带来不安全感，尤其在缺少沟通时。把变化讲清、给出培训与转岗路径、明确复核责任，比反复强调 AI 不会替代人更有效，也更容易被一线接受和执行，减少反复。
什么时候该暂停项目？
出现三类信号应暂停：关键数据始终拿不到、业务负责人连续缺席评审、场景验证不成立。暂停不是失败，及时止损比拖到上线后再撤更节省资源，也便于保留后续合作空间。