01｜企业买了模型、做了 Agent，为什么 AI 仍然难以落地？

这三个问题把项目从演示带回了业务。计算租金只是报价工作的一部分。接待需要知道客户要做什么，设备是否适合现场，操作员和运输是否能配合；调度还要拿到明确的日期、地点和最新需求，才能继续安排。一个看起来完整的回答，可能尚未成为一份能够继续处理的业务结果。

企业 AI 的落地困难，经常发生在这里：模型能够完成某个动作，但原来的工作并没有因此顺畅地往下走。理解这段距离，才能理解 FDE 为什么会进入企业项目。

讨论 AI 项目时，人们容易用功能命名目标，例如“做知识库”“做报价助手”“做订单预警”。这些名称有助于沟通方向，却省略了最关键的内容：谁要完成什么工作，当前困难发生在哪里，系统产生的结果下一步交给谁。

以知识问答为例，“能回答产品问题”是功能描述。真正的工作可能是销售收到一位客户的连续咨询，需要及时获得有依据、容易转述的说明，同时将价格优惠和授权承诺交给有权限的人确认。即使模型第一轮回答准确，后续串了客户背景、引用了旧产品信息，或者销售无法在日常聊天入口使用，整个任务仍然可能失败。

所以，判断系统是否有用，需要沿着任务继续追问。输入从哪里来？回答依据哪份有效资料？谁检查结果？出现不确定信息怎样处理？完成之后，原业务记录是否更新？这些问题共同决定系统能否承担实际工作。

本文使用模拟业务情境来解释方法，不把演示中的企业、交易和数字视为已经发生的实施成果。案例的价值在于帮助我们看见工作结构，而项目效果必须由对应企业的真实记录证明。

企业说“报价太慢”，至少可能包含几种不同情况。接待反复补问客户，说明需求收集不完整；设备管理员迟迟不回复，说明资源信息或协作方式有问题；销售重新计算多项费用，可能适合规则程序；客户修改日期后各岗位还看旧版本，则涉及状态与交接。

如果把这些情况统一理解为“需要一个更聪明的模型”，方案就会失去方向。模型即使更快生成报价文本，也无法自动让失真的排班表变得准确，更不能替负责人确认尚未协调好的资源。

业务转译需要把抽象诉求改写成可以检查的陈述。例如：“接待人员处理普通短租询价时，需要在多个表格和聊天中查找条件，调度又经常退回缺失的信息，因此产生重复补问与返工。”这段描述指出了角色、任务、困难和影响，已经能够指导下一步调查。

接下来还要建立基线。处理一笔询价花多少人工时间？从收到消息到可交接结果经过多久？退回补问的比例是多少？人工投入与自然等待要分别记录，否则系统缩短了计算时间，可能仍没有改变客户等待。

能否用 AI，应该在问题被看清之后判断。有些障碍通过统一表单、调整责任或更新数据就能显著改善；有些任务才需要理解自然语言、检索经验或处理复杂材料。FDE 的业务价值首先体现在选对值得做的事。

一旦进入企业环境，系统面对的条件会发生变化。演示数据可以提前整理，实际数据却会过期、缺失或互相冲突；开发者知道怎样提问，真实用户会使用简称、修改要求，也可能连续点击同一个按钮。

这些变化要求工程方案明确处理责任。报价规则应由可检查的程序计算；设备可用性应来自有时间含义的资源记录；权限应由系统执行控制；模型可以协助理解需求、组织解释，却不能仅凭语言上的肯定生成资源承诺。

可靠性也包括失败之后的行为。查不到档期时，系统应该呈现待核实事项；工具请求超时，要知道是否已经产生写入；一次任务重复提交，需要避免重复创建业务记录。缺少这些设计时，一条成功路径越流畅，越可能让人忽略失败路径上的后果。

工程团队还需要能够定位错误。同样是“报价不对”，原因可能是需求字段没有补全、价目版本过期、计价程序错误或输出解释遗漏。保存输入、依据、工具结果与版本，才能把问题交给正确的人修复，并用同样条件重新检查。

因此，工程交付关注的不只是模型效果，还包括数据、接口、身份、状态、观测和恢复。企业中的 AI 能力通常运行在这些基础条件之上。

技术团队宣布上线，业务人员仍然沿用旧流程，并不一定是他们排斥新技术。新系统可能要求重复录入，结果不能回到原工作台；一线用户也可能不知道哪些建议可以采用，出了问题应该联系谁。

组织采用需要完成具体安排。谁参与试用？哪些任务先进入系统？谁有权批准数据接入与业务动作？业务代表按什么标准验收？规则变更由谁维护？服务异常时，用户怎样回到原流程？这些安排决定系统能否从“有人试过”变成日常工作的一部分。

不同角色关心的成功也可能不同。管理者希望缩短整体周期，接待希望少填表，调度希望信息完整，技术团队关注故障率。若没有共同定义结果，某个岗位省下的工作可能转移到了另一个岗位，项目整体并未改善。

所以，观察采用不能只看登录数。应看目标任务是否在系统中完成，结果是否被实际使用，人工修正发生在哪里，以及相对于原流程，时间、质量或风险有没有变化。持续使用是重要证据，但它仍需要与业务结果一起解释。

FDE 是 Forward Deployed Engineer 的缩写，通常译为前沿部署工程师。这里的“前沿”强调靠近客户现场、用户任务与真实约束；“部署”延伸到方案进入实际工作后的使用和反馈。

这种工作方式的历史可以追溯到 Palantir 等企业软件实践，早于当前生成式 AI 热潮。对入门者更有用的并不是记住某个年份，而是理解它应对的问题：复杂业务难以通过一份固定需求说明完全传递，工程判断需要持续吸收现场事实。

FDE 通常会参与问题发现、技术范围界定、关键实现、企业集成、验证与采用反馈。不同组织的分工会有差异，端到端关注也不意味着一个人包办所有工作。业务专家决定专业边界，数据负责人确认来源，工程人员完成系统建设，管理者承担相应审批与资源责任。

可以用下面这张表判断一项 AI 工作目前卡在哪里：

回到最初那句“两天多少钱”。一份有业务价值的结果，需要说明费用依据、适用条件、资源状态和下一步处理方式。当接待可以解释，调度可以接手，异常可以交给相应负责人，技术才真正进入了业务。

接下来要进一步拆开这条责任链：完成这些工作的人，需要具备哪些能力，又怎样与已有岗位共同推进项目？

AI随心创提供 AI 场景诊断、工具与模型选型、工作流设计及小范围试点支持。如果团队已经有工具，却还没有清楚的应用方向，可以带着现有流程和两三个任务样例，了解企业 AI 咨询服务。