AI 落地卡在「最后一公里」?不是模型不行,是缺一个 FDE (

FDE 补的是哪道缝

企业买的不是软件，是结果。

「软件已经交付」和「客户得到结果」是两件事。一套演示漂亮的 Agent，一进客户环境就会撞上现实：数据在旧系统里，流程写在人的习惯里，异常没人记录，成功标准彼此矛盾，安全团队不肯放行，业务人员也未必愿意改掉用了十年的做法。于是看似技术的问题，变成了产品、工程、组织、销售和变革管理的混合问题。

FDE 就卡在这条缝里——让同一名技术人员或小团队，穿过「发现问题 → 界定范围 → 写出第一版方案 → 跟到生产采用」，同时把现场遇到的共性问题送回产品和模型团队。书里把这套能力概括成一个五步循环：现场事实 → 问题定义 → 首个结果 → 生产部署 → 产品复利。真正可扩张的 FDE，不以「这次客户满意了」为终点，而以「下一位客户不必重新付出同样成本」为检验。

一张 2×2 图，判断你到底需不需要 FDE

Anthropic 的 Kevin Bai 给了两个维度：一是产品本身简单成品还是技术复杂的平台；二是买家和用户是否具备足够技术能力。最该要 FDE 的，是左上角——复杂产品 × 非技术用户。Palantir 就落在这：把高度可塑的平台，卖给不以软件开发见长的石油、制造、消费品企业。客户真正缺的，是把业务知识和平台能力接起来的那个人。

对照看另外三个象限：简单产品卖给技术用户，文档和开发者关系就够；简单产品卖给非技术用户，传统 SaaS 实施即可；复杂产品卖给技术用户，解决方案架构师加清晰文档也行。

但光有需求不够，还要过两道经济关：高客单价 + 共享平台。没有「原语」（身份、权限、数据连接、工具调用、评测这些可复用基础能力），FDE 每接一个客户都从空白代码库开始，公司名义上卖产品，实际经营的是项目制开发——也就是一家软件外包公司。Bai 给的示意比例是：约 60% 的能力来自共享平台，约 40% 按客户场景组合和扩展。

三个真实案例，看懂 FDE 怎么干活

案例一（Kepler）：47 页需求，最后只剩一条消息。一家运输调度客户交来 47 页需求，想要完整 BI 工具加 14 项指标。FDE 没照单全收，而是问：「周一早上你拿到这些信息之后，第一件事是什么？」答案不是分析 14 张图表，而是发现延误后通知一个人采取动作。于是团队先在 4 小时内做出一条告警消息——不完整，却直接抵达业务动作。真正值钱的不是 14 张报表，是「发现延误—通知对人—采取替代动作」这条链。

另一个细节更扎心：Parquet 迁移被一位数据质量工程师反对了近一年。FDE 到现场才发现，她每天双击 CSV 抽查几行来确认数据正常；Parquet 对机器更高效，却夺走了她最重要的质控动作。团队连夜做个简单查看器，她第二天仍能像以前一样检查数据，迁移很快获批，一条流水线从约 17 小时缩到约 2 小时。

案例二（Ramp）：周五晚上的 SAP 请求。销售说重要客户要 SAP 集成，能不能尽快做？FDE 的第一原则是「永远在界定范围」（Always be scoping）——先把请求放回完整上下文：客户为什么现在需要？真正用户有多少？今天有没有手工替代办法？其他在谈客户会不会遇到同一问题？

另一个例子更经典：给客户做移动报销，团队顺手做了 iOS 和 Android 两个版本，后来才知客户强制使用受管理的 iPhone，Android 用户根本不存在。scoping 不是把需求写得更长，而是找出能删掉大量工作的那个事实。Ramp 后来用 Agent 把 scoping 的信息往返从天级缩到秒级，省下约 20% 的界定时间。

案例三（Decagon）：把定制变成自助。公司从约 50 人长到约 500 人，把现场工作拆成两条线——在产品里配置 Agent 的 Builder，和把企业共性需求变回产品的 Software Engineer。他们反复手写 CRM 集成，做到第 25 个时才意识到继续复制没意义，于是把连接能力改造成自助方式。核心一句话：一次定制不是失败，同一类定制反复出现却始终没变成配置项、通用接口或平台能力，才是失败。这就是 custom → self-serve 漏斗。

可抄的 FDE 操作系统：九道关口

《FDE 入门到精通》最后给了一套实践手册，把一次部署拆成九道关口，每道都要有可审阅的产物和责任人。我压缩成你能直接用的清单：

1. 选值得深做的客户：价值高、愿开放真实流程与数据、需求可能代表更大市场。

2. 画利益相关者地图：谁买单、谁每天用、谁能否决、谁在失败时承担代价。尤其区分「提需求的人」和「承受工作的人」。

3. 画两张流程图：官方流程（文档怎么写）和真实流程（异常、绕行、等待、复制粘贴、个人记忆）。能现场观察就不要只访谈。

4. 把愿望改成可验证结果：对象、行为、基线、目标、时间、边界都要写清，还要写反指标——自动解决率提高但投诉也涨，就不算成功。

5. 压到最短行动闭环：找一段几天而非几个月内就能改变真实动作的范围；保留日志、权限、测试、人工接管和数据边界。

6. 设计人机控制面：每一步按错误代价和可验证性定档——自主执行 / 人在回路 / 纯人工。

7. 进生产，不停在演示：身份权限、数据来源、可观测、评测、回滚、人工接管、轨迹留存，一项都不能少。

8. 把一次性资产分类回流：客户特有配置留现场；行业模式沉淀模板；平台共性进路线图；交付系统进自己的工具和知识库。

9. 用复利指标看团队：第 10 次部署是否比第 1 次更快、更稳、更少依赖特殊人物？如果长期不是，增长只是项目数量增加，不是能力复利。

给想落地 AI 的你：3 个启发

第一，你交付的不是 AI 工具，是「把某件事可靠办成」的结果。demo 能跑不是终点，生产里真正用起来才是。客户问的从来不是「你的模型多强」，而是「我的业务结果为什么还没发生」。先想清楚要改变哪一个真实动作，再动手。

第二，范围克制比生成能力更值钱。代码越便宜，越要追问「哪一半不做」。先交付一个最小可验证闭环，比堆一堆功能更重要。Ramp 那句「Always be scoping（永远在界定范围）」，值得贴在工位上——它帮你挡掉一半白做的活。

第三，把每次交付变成产品资产。你给客户做的第 3 次同类需求，能不能变成模板或自助？复利不在接更多单，在于每一次交付都让下一次更快。这恰恰是中小团队对抗大厂最现实的打法——你比谁都靠近客户现场。

写在最后

FDE 不一定要叫 FDE。Palantir 的人叫它 Deltas，Ramp 把 FDE 放进工程组织，Decagon 说它和产品工程是同一条线。名称会变，唯一不能丢的是：有人把真实问题、可验证结果和产品学习连起来。

对中小团队和个人创业者来说，这反而是优势——你既是产品，也是 FDE，比大厂更贴近客户的真实现场。别把「靠近客户」当成负担，那是你最深的护城河。

如果你也在做 AI 落地，卡在某个客户的真实现场，欢迎在评论区聊聊——你想听哪类案例，我下篇接着拆。

—— 芊煜姐 · 芊煜姐说