第一个项目的常见坑：范围蔓延、期望管理、效果量化
第一个项目的常见坑，90%的FDE都踩过。了解这些坑，不是为了避免所有坑（不可能），而是为了踩坑后能快速识别、快速调整，不要在一个坑里陷太久。
坑一：范围蔓延
范围蔓延是第一个项目最常见的坑，没有之一。项目开始时说好了只做A，做着做着客户说"顺便把B也做了吧"，然后又加C、加D……最后项目范围翻了一倍，时间翻了一倍，成本也翻了一倍，客户还觉得"就加了一点点，你怎么这么慢"。
范围蔓延的原因：① MVD范围定义不清晰，"做什么不做什么"没有明确写下来；② 客户提需求时，FDE不好意思拒绝，觉得"就一个小功能，加吧"；③ 没有变更管理流程，客户随口一说就加了，没有评估影响、没有确认时间和成本变化。
怎么应对：① 项目开始时，用MVD画布（F3-2）明确"做什么、不做什么"，写进SOW，客户签字确认；② 客户提新需求时，不要立刻答应，也不要立刻拒绝，而是说"这个需求很好，我评估一下对时间和成本的影响，然后给您一个方案"；③ 建立变更管理流程：所有范围变更都要走正式流程——评估影响（时间+成本）→客户确认→更新SOW→执行。小变更可以简化，但必须有记录；④ 把"不做的功能"列出来，比"做的功能"还详细——这样客户提新需求时，你可以说"这个我们当时明确说不做的，放到二期好吗？"
记住：范围蔓延是渐进式的，每次只加一点点，但加着加着就失控了。要从一开始就建立边界，不要等蔓延了再收。
坑二：期望管理失败
期望管理失败是第二个常见坑。项目开始时，为了签单，FDE把效果说得很好——"AI能处理90%的问题""准确率95%以上""上线后能省一半人力"。结果上线后效果没达到，客户觉得"你骗了我"，项目验收困难，尾款收不回来，口碑也毁了。
期望管理失败的原因：① 签单时过度承诺，为了拿下项目什么都答应；② 没有量化的成功指标，"效果好""提效"这种模糊的说法，客户和FDE理解不一样；③ 项目过程中没有及时同步进度和问题，客户以为一切顺利，最后才发现效果没达到；④ 没有管理客户对AI的认知——客户以为AI是万能的，实际上AI有很多边界和限制。
怎么应对：① 签单时不要过度承诺，宁可保守一点，也不要说满。"AI能处理70-80%的常见问题"比"AI能处理90%的问题"更安全——达到70%是预期内，达到85%是超预期，客户会很高兴；② 用MVD画布定义量化的成功指标（F3-2格子三），写进SOW，双方确认。有了量化指标，验收时就不会扯皮——达到了就是成功，没达到就分析原因；③ 项目过程中定期跟客户同步进度，有问题及时说，不要藏着掖着。"这个模块比预期难，可能要多花3天"比"到了交付日才说做不完"好得多；④ 项目开始时就跟客户讲清楚AI的能力边界——AI能做什么、不能做什么、准确率大概在什么范围、需要人工兜底的地方。管理客户的认知，就是管理客户的期望。
记住：期望管理的核心是"under-promise, over-deliver"（低承诺，高交付）。承诺70分，做到85分，客户会惊喜；承诺95分，做到85分，客户会失望。同样的结果，不同的承诺，客户感受完全不同。
坑三：效果无法量化
效果无法量化是第三个常见坑。项目做完了，客户问"效果怎么样？"，FDE说"效果挺好的，客户反馈不错"。客户说"挺好是多好？能省多少钱？准确率多少？"，FDE答不上来。最后项目验收困难，客户觉得"花了钱但看不到效果"，二期也不会续了。
效果无法量化的原因：① 项目开始时没有定义成功指标，"提升效率""改善体验"这种模糊的目标没法量化；② 没有before基线——项目开始前没有记录"原来的情况是什么样"，项目结束后就没法对比"改善了多少"；③ 没有数据采集机制——上线后没有监控效果数据，凭感觉判断"效果挺好"；④ 效果指标选得不对——选了容易量化但没价值的指标（比如"AI回答了多少个问题"），而不是有业务价值的指标（比如"人工节省了多少时间""客户满意度提升了多少"）。
怎么应对：① 项目开始时，用MVD画布定义3-5个可量化的成功指标（F3-2格子三），每个指标有明确的before基线和after目标；② 项目开始前，花时间采集before基线数据——原来的响应时间是多少？错误率是多少？人工成本是多少？客户满意度是多少？没有基线，就没有对比，就没法证明效果；③ 上线后建立效果监控机制——每天/每周采集效果数据，做成简单的报表，定期跟客户同步。数据是最好的证明——"上线后响应时间从32小时降到5分钟，人工成本降低40%"比"效果挺好的"有说服力100倍；④ 选有业务价值的指标——不要选"AI处理了多少个问题"，要选"人工节省了多少时间""客户等待时间缩短了多少""错误率降低了多少""成本降低了多少"。业务价值指标才是客户真正关心的。
记住：效果量化不是项目结束时才做的事，是项目开始时就要规划的事。从定义指标、采集基线，到上线监控、定期汇报，效果量化贯穿项目全过程。效果量化做好了，项目验收就容易，客户续费就顺理成章。
坑四：数据质量问题
数据质量问题是第四个常见坑，也是技术出身的FDE最容易低估的坑。项目开始时，客户说"我们数据都有，质量也不错"。结果做的时候发现：数据散落在各个系统里、格式不统一、大量缺失和错误、没有标注、更新不及时……数据清洗花了项目一半的时间，效果还不好。
数据质量问题的原因：① 客户对自己的数据质量没有清晰认知——"我们有数据"不等于"数据能用"；② FDE在POC和需求调研阶段，没有深入检查数据质量，想当然地以为"数据应该没问题"；③ 项目计划中没有给数据清洗留足够的时间，以为"数据准备很快"；④ 没有建立数据质量持续维护机制——上线时数据清洗好了，但后续没人维护，数据质量慢慢下降，效果也跟着下降。
怎么应对：① 项目开始时（最好在POC阶段），就深入检查客户的数据质量——数据在哪里？格式是什么？完整度怎么样？有没有标注？更新频率怎么样？不要听客户说"数据没问题"，要自己亲眼看到、亲手检查；② 把数据质量评估作为POC的重要内容——POC不只是验证模型效果，也要验证数据质量。如果数据质量差，POC时就会暴露出来，提前跟客户沟通数据清洗的工作量和成本；③ 项目计划中给数据清洗留足够的时间——一般来说，AI项目中数据准备的时间占30-50%，不要低估；④ 跟客户明确数据质量的责任——数据是客户的，数据清洗和维护主要是客户的责任，FDE可以提供工具和方法，但不能替客户做所有数据工作。在SOW中明确写清楚"客户负责提供符合质量要求的数据"，避免后期扯皮；⑤ 上线后建立数据质量持续维护机制——谁负责更新数据？多久更新一次？数据质量怎么监控？bad case怎么处理？没有持续维护，数据质量会慢慢下降，效果也会跟着下降。
记住：AI项目有一句话——"Garbage in, garbage out"（垃圾进，垃圾出）。数据质量决定了AI效果的上限。不要低估数据质量问题，也不要替客户承担数据质量的责任。从项目一开始就重视数据，后面会少踩很多坑。
坑五：用户接受度低
用户接受度低是第五个常见坑，也是最容易被忽视的坑。技术方案没问题、效果也达标，但客户的用户就是不愿意用——觉得"AI不好用""改变了我的工作习惯""AI会抢我的饭碗"。最后系统上线了但没人用，项目等于失败。
用户接受度低的原因：① 没有让用户参与项目过程——系统是FDE和客户的管理层定的，一线用户根本没参与，上线后才告诉他们"以后用这个系统"，用户自然抵触；② 没有充分的培训——用户不知道怎么用、用了有什么好处、遇到问题找谁，自然不愿意用；③ 改变了用户的工作习惯——原来的工作方式虽然效率低，但用户已经习惯了；新系统虽然效率高，但需要学习和适应，用户觉得"麻烦"；④ 用户担心AI抢饭碗——"AI做了我的工作，我是不是要失业了？"有了这个担心，用户不仅不愿意用，还可能故意说AI不好用。
怎么应对：① 项目开始时就让用户参与——找几个一线用户代表，参与需求调研、方案讨论、测试反馈。让用户有"参与感"和" ownership"，他们会更愿意接受最终的系统；② 设计系统时考虑用户体验——不要只考虑技术实现，要考虑用户用起来方不方便、流不流畅。好的用户体验是接受度的基础；③ 充分的培训——上线前组织培训，不只讲"怎么操作"，还要讲"为什么用这个系统""用了对你有什么好处""遇到问题找谁"。培训后要有实操练习，让用户亲手用一遍；④ 找到"种子用户"——先找几个开放、愿意尝试新事物的用户，让他们先用，用出效果后，让他们去影响其他用户。口碑传播比官方培训有效得多；⑤ 跟用户沟通清楚AI的定位——"AI是帮你干活的助手，不是替代你的对手。AI做了重复的工作，你可以做更有价值的事。"消除用户的恐惧，争取用户的支持。
记住：AI项目的成功，不只是技术的成功，更是人的成功。技术再强，用户不愿意用，项目就是失败的。从项目一开始就关注用户接受度，把"人"的因素跟"技术"的因素同等重视，项目成功率会大幅提升。
本节关键要点
- 1 第一个项目五个常见坑：范围蔓延、期望管理失败、效果无法量化、数据质量问题、用户接受度低
- 2 范围蔓延：用MVD画布明确边界，建立变更管理流程，"不做的功能"比"做的"还详细
- 3 期望管理：under-promise over-deliver（低承诺高交付），量化成功指标，过程中及时同步问题，管理客户对AI的认知
- 4 效果量化：项目开始时定义指标+采集基线，上线后监控+定期汇报，选有业务价值的指标（不是技术指标）
- 5 数据质量：Garbage in garbage out，POC时就检查数据质量，给数据清洗留足时间，明确客户的数据责任，建立持续维护机制
- 6 用户接受度：让用户参与项目过程，设计时考虑用户体验，充分培训，找种子用户，消除用户"AI抢饭碗"的恐惧
- 7 了解坑不是为了避免所有坑（不可能），而是为了踩坑后能快速识别快速调整
你现在能做什么
他们会这样考你
FDE和传统IT交付的本质差异是什么？
为什么说"需求背后是人"？举一个你工作中的例子。
更多题目：进入在线考试，七套篇章卷350+题等你挑战。