要点： 大多数企业 AI 项目失败，并不是因为模型不够好，而是败在最后一公里：与真实的系统、数据、权限和人员的连接。这项工作无法远程完成。它需要工程师进入您的组织，一直工作到系统在日常运营中跑起来，同时要有让他们撤出的计划。
1. CEO 应该问的问题
我看待 AI，和看待任何一项投资一样。能回本吗？什么时候？供应商走了以后，成果归谁？
大多数 AI 试点过不了这一关。不是因为演示做得差，演示通常是最容易的部分。它们失败，是因为没有人为「在笔记本上能跑」到「大家每天早上都在用」之间的工作做预算。
这道鸿沟在业内有一个名字。Palantir 多年前就围绕它建立了自己的模式：工程师进驻每一位客户，部署并调整其平台。如今，OpenAI、Anthropic 等 AI 实验室也在招聘同样的角色：前置部署工程师（FDE）。
2. 钱损失在哪里
最后一公里并不光鲜。它是没人记录过的权限，是一个在 CRM 里有三种含义的字段，是必须审批提示词的法务团队，是一个只因为某个人知道所有例外才能运转的流程。
这些都不在试点范围之内。于是试点结束，幻灯片上写着「成功」，而投产预算变成了一轮新的谈判。几个月过去，发起人的关注点也变了。
| 项目计划的假设 | 最后一公里的真实情况 | 谁来买单 |
|---|---|---|
| 数据抽取出来就能用 | 访问、质量和含义要逐个系统去协商 | 您的团队，以延期的形式 |
| 集成是技术任务 | 集成是组织问题：责任人、审批、安全 | 发起人，以信誉的形式 |
| 好工具自然会被采用 | 用户只会采用契合其现有工作方式的工具 | 商业论证 |
| 交接是一份文档 | 交接是亲手搭建过系统的人 | 您自己，每次有变动时 |
3. 工程师进驻后有什么不同
前置部署工程师在问题所在的地方工作：在您的系统里，和您的人一起，直到它跑起来。
这改变了我关心的三件事。
- 见效时间。 解决方案直接在它将要运行的环境中构建，无需再做一个项目去「工业化」。
- 风险。 集成、权限和控制在最初几周就解决，而不是在合同验收后才发现。
- 所有权。 您的团队一起搭建。项目结束时，他们能够运维并修改已经建成的系统。
按周计算并不便宜，因为这是资深的实操工作。但真正该比较的不是周费率，而是到系统投入日常使用为止的总成本。一个更便宜却永远进不了生产的项目，才是最贵的选择。我们在 决策指南（英文） 中比较了这两种模式。
4. 如何引入而不形成依赖
嵌入式团队有自己的陷阱：它可能变成永久性的。签约前，请要求四件事。
- 您方有一位具名的负责人，将来接手这个系统。
- 从第一天起所有内容都放在您的代码仓库里：代码、提示词、评估集和文档。
- 以使用情况衡量成功，而不是以交付物衡量：谁在用、多久用一次、产生了什么结果。
- 有日期的退出安排，配有运维手册，以及由您自己的团队演练过的交接。
如果供应商对其中任何一点有抵触，请把它当作一个信号。
5. 常见问题
问：什么是前置部署工程师（FDE）？
答： 一种在客户组织内部、基于其系统和数据工作的软件工程师，直到解决方案在生产环境中运行为止。这一模式由 Palantir 推广，如今在 AI 公司中很常见。
问：这和聘请咨询公司一样吗？
答： 不完全一样。传统项目通常由咨询公司的团队设计和构建，最后交付。前置部署工程师在您的环境中、与您的人员一起构建，并一直留到系统跑起来。
问：这样的项目应该持续多久？
答： 直到第一个用例在日常运营中跑起来、您的团队能够自行运维为止，并有明确日期的交接。如果没有计划中的结束时间，就是一个警示信号。
问：什么时候按项目交付更合适？
答： 当范围清晰且相对独立、集成较轻、并且您需要固定价格时。并不是所有 AI 需求都需要工程师进驻。
6. 结论
AI 不会在演示中创造价值。只有当它在业务中每天运行、由使用它的人掌握时，才会创造价值。
这就是 Thinkia 的工作方式：与您的团队组成一个团队，在您的系统中工作，并从一开始就规划好退出。如果您有从未进入生产的试点，这是我们的做法（英文）。