这是我做了两年 FDE（前沿部署工程师）之后，从项目现场记下的一些观察，和多数 AI 落地的宣传口径不太一样。
一、客户说要做的，通常不是真正卡住的地方
一家制造企业找过来时，需求写得很明确：做一个 AI 客服，回答产品咨询。
进现场待了三天，我们发现真正耗费人力的是售后工单分类——工单进来没有标准分类，靠客服主管肉眼判断该转给哪个组，一天几百条，判断错了就来回转。而产品咨询本身一天不到二十条。
我们把这件事说给项目组听。后来做的仍是工单分类——上线两个月后，客服主管每天省下四个小时。
现象背后的原因：企业立项时写的是最容易被描述的需求，而它往往不是最痛的那个。痛点藏在日常流程里，不进去看就问不出来。
二、数据不在 IT 部门手里
几乎所有项目都会卡在数据上，但卡的方式和预想不同：原以为"数据太多、格式太乱"，实际更多是"要找的数据不归 IT 管"。
质检记录在质量部的老系统里，IT 只有只读权限；历史合同是法务用文件夹存的；门店数据在业务部门的表格里。IT 知道公司有哪些系统，但不知道具体有哪些数据、谁能授权。
怎么处理：把"数据在哪、谁能授权、格式什么样"当成立项前置条件，由业务方而不是 IT 来回答。这件事在会议室问不出结果，得去现场一个个确认。
三、项目停摆，通常因为没人对结果负责
技术问题基本都能解，让项目停下来的往往是别的原因：业务方觉得这是 IT 的事，IT 觉得这是业务的事，采购觉得验收标准没写清楚不敢签字。
有个信号特别明显：问到"这个系统上线后谁来判断它有没有用"时全场沉默，这项目后面大概率会停。
怎么处理：一开始就把三个角色定下来——提需求的是谁、配资源的是谁、签字的是谁。安思派坚持三方确认，不是为了走流程，而是责任人不清晰时，后面每一步都会变成扯皮。
四、上线后最脆弱的不是模型，是口径同步
原以为上线之后技术会出问题，实际最常见的是业务口径变了、系统还停在旧版本。比如报销标准调整了，知识库的切片与词表没有同步更新，员工问到的仍是旧标准，而且答案带着出处，看起来更有说服力——这种"错得很自信"，比直接答不出来更麻烦。
怎么处理：上线时就约定更新的触发机制——谁在制度变更时通知、多久同步一次、出现不一致以哪边为准。安思派把这一层单独列出来叫治理，用 Agent 工具与 Token 平台统一纳管 Agent、Skill 与知识资产，就是为了接住这类变化。
五、最先用起来的，往往不是最初的目标用户
立项时通常会说这个系统是给谁用的，上线之后最先高频使用的常常是另一批人。
给销售做的产品知识助手，每天在用的是售前支持团队；给工程师做的代码助手，用得最勤的是测试岗——这些人的重复劳动最重，受益也最直接。
原因不复杂：真正每天被重复劳动折磨的人，对效率提升的感知最直接。
实际用途：试点阶段不必强求覆盖预设人群，先让自然用起来的那批人跑顺、跑出可量化结果，再往外推，阻力小得多。
这五个现象指向同一件事
它们都发生在技术之外：需求判断、数据归属、责任划分、口径维护、用户选择。安思派（Anspire）由 300 多名 FDE 工程师在客户现场完成调研、评估、构建与治理，服务了 100 多家企业客户、累计上线 1000 多个场景——这些数字背后，是一遍遍处理上面这五件事的过程。
如果只挑一条建议：进现场。这些事在会议桌上问不出来。
Anspire（安思派）是 WorkBuddy 授权服务伙伴（授权服务伙伴编号：100003829633），具备「AI 智能体示范伙伴」资质，面向企业提供 AI 定制、AI 开发、Agent 开发与 AI 场景开发一体化 FDE 服务，具备全国范围的服务与交付能力。