
> 大多数企业 AI 项目不是死于模型不行，是死在验收、流程和责任上。这个系列从甲方内部视角讲三件事：路径，一个 AI 工具要爬过哪四道坎；方法，评测集、兜底层、责任链怎么建；底线，金融行业有哪四类部件只能自己攥着。三样合起来，AI 才可能在企业里活下来，不是跑通一次，而是长期活着，并且能被复制。本篇讲这套机制的路径层。

---

## 开篇：进现场的人不缺，缺的是把现场经验收回来的人

过去一年 FDE（Forward Deployed Engineer）这个词在国内热了起来。霞光智库统计过一组招聘数据：FDE 岗位数在一年之间从 643 个涨到 5330 个。

这个增速本身要打个问号。眼下不少挂着 FDE 名头的岗位，其实就是原来的实施顾问换了个名字，这一点已经有人在公开文章里提醒过。名字怎么叫不关键，关键在下面这件事：

现在所有关于 FDE 的讨论，默认都是站在乙方说的。软件厂商派工程师进客户现场，一边交付一边把共性沉淀回自己的产品。Palantir 从 2011 年就把这件事制度化了，后来 OpenAI 也专门成立部署公司来做交付。这整套叙事里，甲方是被服务的那一方。

那如果企业没有请外部顾问呢？或者请了，顾问撤了，剩下的人怎么办？

我的看法是，甲方内部同样可以有 FDE，而且在国内可能更有条件：离业务近，内部沟通成本低，可以一轮一轮小步试错，不用为每个现场单独签合同。但“有条件”不等于“更容易”。MIT NANDA 2025 年那份《The GenAI Divide》里有一组数据值得警惕：外购 AI 项目的成功率约 67%，企业内部自建的只有约 22%。

这组数字表面上打的是我的脸。但它说的“内部自建”，指的是企业从头自己造工具；我主张的内部 FDE，是让内部的人连接业务与已有的平台能力，不是关起门来造轮子。差别在哪，后面第四道坎会讲到。这里先提一句：**内部 FDE 最大的失败风险，恰恰就是变成闭门造车**。

本篇讲路径：一个内部 AI 工具从 demo 到能被复制到下一个场景，中间要过四道坎，每一道都有它自己的失败方式。

---

## 先看全景：三种“进现场”，差别在哪

FDE 这个词可以拆成一句话：**把业务现场变成产品研发的前沿**。区别不在人在哪儿办公，在于现场遇到的问题往哪儿流。

| 维度 | 乙方 FDE | 甲方内部 FDE | 传统驻场交付 |
|---|---|---|---|
| 谁派人 | 软件厂商 | 科技部门 | 任意 |
| 产品归谁 | 厂商产品 | 内部平台 / 组件 / 流程 | 没有产品概念 |
| 反馈往哪走 | 现场 → 厂商产品路线图 | 现场 → 内部平台 | 现场 → 验收单 |
| 成果沉淀成什么 | 可对外售卖的通用产品 | 横向可复用资产 | 项目文档 |
| 典型失败 | 每个客户长出一套新产品 | 退化成项目组 | 交付即终点 |

第三列是最容易被误认成 FDE 的。人也在现场，也解决具体问题，也交付了，但反馈只流到验收单为止。下一个项目从零开始，上一次踩过的坑这次照样踩。

MIT NANDA 那份报告给过一个漏斗：60% 的组织评估过 AI 工具，20% 进入试点，最后**只有 5% 真正进了生产**。这个漏斗和下面四道坎基本同构。大多数项目死在“评估到试点”和“试点到生产”这两段之间，正好对应第二道坎和第三道坎。

---

## 第一道坎：demo 跑通了，不等于需求是真的

**症状**

demo 做得漂亮，演示会上老板当场拍板。几个月后再问，项目没了。

**病根**

业务很难一次说清自己真正的问题。科技部门拿到的，往往已经是一个“预设的解决方案”：业务看到别家做了个什么，或者自己想象了一个什么样的工具，然后把它当成需求提过来。

这不怪业务。人不擅长描述自己没见过的东西，只擅长评价见过的东西。所以给他一个抽象方案让他评审，他只能说“好像可以”；给他一个能点能跑的东西，他才知道自己不要什么。

**失败模式**

把 demo 当成需求验证。demo 通过 = 方向正确 = 开始正式开发。但 demo 证明的只是“这个技术能做到”，不是“业务真的需要这个”。

**怎么过**

原型的作用是让模糊的需求变得可验证，不是证明技术可行。这两句话看着像，做起来差很远。后者追求“跑通”，前者追求“跑出来之后业务说：对，我要的就是这个，但这里不对”。

**最小三步**

1. **先看一遍真实流程。** 坐在业务岗旁边看他把这件事从头做到尾，不打断。这一步省不掉，很多“需求”在看完第一遍之后就自己作废了。
2. **把问题写成一句话，写在纸上让他确认。** 不是“我们需要一个智能助手”，而是“每天花在这上面的时间，主要耗在查三四个系统然后手工比对”。后者才可能被验证。
3. **拿最粗糙的东西回去现场验证。** 一个命令行、一个表格、一段脚本都行，只要能让他用真实数据跑一遍。

**常见错**

把业务提过来的“解决方案”直接当成需求排期。业务说要一个能自动生成报告的助手，照着做出来，多半是个没人用的报告生成器。

要往下追一层：现在这份报告是怎么做出来的，最耗时间的是哪一步？答案很可能是“从三个系统里把数捞出来对上”，那真正要解决的就不是报告生成，是数据对齐。前者做出来的东西炫，后者做出来的东西有人用。

**代价**

这三步看着简单，第一步最难推。业务岗忙，让他抽半天配合看流程，需要有人能说得上话。而且看出来的结论有时候是“这事不该做”。这个结论很值钱，但说出来不讨喜。

**判据**

怎么判断这一关过了？业务能自己说清楚“这个东西做出来，我哪一步会变”。如果回答还是“应该会快一点”“感觉有帮助”，那需求还是模糊的，别急着往下走。

---

## 第二道坎：要上线了，撞上验收标准

**症状**

工具跑给业务看，几十条数据里有几条不对，当场就有人说“这玩意不行啊”。

**病根**

企业拿确定性的验收标准，去要求一个概率系统。做惯了确定性系统的人对“验收”两个字有肌肉记忆：输入 A 永远输出 B，几百个用例跑过才敢发生产。Agent 不是这类东西。同样的输入，它大多数时候对，少数时候跑偏，而且不会主动告诉你这次跑偏了。

按“全对”这个标准验收，AI 永远上不了线，因为模型再进化三代也不是 100%。

**失败模式**

承诺“全对”。为了过验收，把话说满。说满的那一刻，就把自己放在了必输的位置：只要有一条错，承诺就破了。

**怎么过**

不承诺全对，承诺**错了能被抓住**。这五个字是企业级 AI 和玩具 demo 的分水岭。

具体要补三样东西，我把它单开成系列第二篇讲：评测集、兜底层、责任链，分别回答“有没有变差”“不确定的怎么处置”“出错算谁的”。这里只给骨架：

> 评测集的最小结构，是**每条样本都要能指出它来自哪条真实请求**。凭想象手写的用例接进 CI，跑出来全绿，只说明你越来越擅长通过一场自己出的考试。

**代价**

这一关的代价不在技术，在说服。要让业务接受“不是全对但错了能抓住”，得先把“抓住”这件事演示给他看：拿一批数据跑一遍，把被兜底层拦下来的那几条翻出来给他看。他看到错的确实被挑出来了，才会接受这个前提。

**判据**

业务问的第一个问题如果从“能保证全对吗”变成“错了会被拦住吗”，这一关就过了。

---

## 第三道坎：要被真正使用，得动流程

**症状**

工具能用，效率也确实提了，但没人真的天天用。问起来都说“挺好”，一查使用记录，零星几次。

**病根**

责任真空。

工具把一段活压到原来的零头，省下来的时间去哪了？不是省掉了，是转移到了别的地方：谁来确认、出错了算谁的、这件事在 KPI 里怎么算。业务岗不是不想用，是不敢签那个字。

**失败模式**

只改工具，不改流程。这是最隐蔽的一种。工具上线了，流程文件一字未改，AI 的产出和人工确认的结果在流程里还是同一个东西。出了问题，谁也说不清责任在谁。

**怎么过**

把责任链白纸黑字写进流程文件。三层就够：AI 输出是建议层，不签字；人工确认后是定稿层，业务岗签字；出错时的归属规则事先约定，不事后议。

第二层是关键。AI 输出只是建议、人工确认才算定稿。这行字写进流程，比任何技术方案都管用。业务部门一看，这东西不让我背锅还能提效，才真的会用。

流程重构长什么样？举个我做过的例子。把研发交付拆成七个角色之后（PM、业务分析师、方案设计师、方案评审员、开发工程师、代码审查员、测试工程师），有三个角色专门干一件事：**检查别人的产出**。方案评审员审方案，代码审查员审代码，测试工程师独立验证，谁都不审自己。

这不是给旧流程贴了一块 AI 功能，是重新定义了研发交付该怎么分工。旧流程里这些检查是同一个人顺手做的，拆开之后它们变成了必须有人负责的独立环节。**这就是流程重构的实物**。判断你是不是真动了流程，看这一步有没有发生。

**代价**

三道坎里这一关最难。改流程就要改 KPI、改汇报关系，会得罪人。这是组织成本，不是技术成本，也没有技术解法。

广发证券副总经理兼 CIO 辛治运 2026 年 9 月在公开访谈里讲过一句我印象很深的话：转型最根本的挑战不是技术，是组织认知和协同模式的转变。他给的做法是组建业务与技术深度融合的虚拟团队，让双方从一开始就坐在一起定义问题，并且让 AI 人才深入业务一线轮岗。他的原话是：“让 AI 人才听得懂业务语言，让业务骨干看得懂 Token 和 RAG 的逻辑”。

这段话我引在这里，是因为它几乎就是甲方内部 FDE 的官方定义，而且是券商的 CIO 说的，比我自己的说法有分量。

**判据**

AI 的产出和人工确认的结果，在流程文件里有没有分成两行写？没有的话，流程就没动。

---

## 第四道坎：要复制到下一个场景，才算数

**症状**

上一个项目做完了，验收通过。下一个场景来了，从零开始，重新调研、重新设计、重新踩一遍坑。

**病根**

没有把“这次交付”当成“下一次的输入”。

**判据只有一条**

这次交付，有没有让下一次更快、更好、更便宜？三样占一样就行，一样都不占，那它就是一个项目，不是 FDE。

**四个退化信号**，出现任何一个都要警惕：

1. 交付结束后留下一套独立分支，和主平台没法合并
2. 下一个场景启动时，没有任何东西可以直接复用
3. 平台没有因为这次交付发生任何变化
4. 团队里只有做这个项目的人知道它是怎么跑起来的

**失败模式**

每完成一个项目，就多一套新产品。做得越多，摊子越大，维护成本越高。这恰恰是前面提到的换名字问题：如果只是把实施顾问改名 FDE，交付模式没变，最后就是这种结局。

**怎么过**

产品化的项目制。原则一句话：**场景特有的留在项目层，可复用的必须回到平台层**。

判断什么该回平台，有三个问题：

1. 另一个场景会不会遇到同样的问题？
2. 解决它的方式，和具体业务规则绑得有多紧？绑得紧就留在项目层
3. 回到平台之后，谁维护？没人维护的东西不要往上放，那只是换个地方腐烂

**这一关真正的难点，是“收得住”。** AI 把写代码、写工具的成本压下去了，人人都能做点东西出来。恒生电子首席科学家白硕 2026 年 7 月在世界人工智能大会上讲过这个副作用：人人都可定义 Skill，也导致了 Skill 野蛮生长，带来治理挑战。他的建议是从业务视角打造统一中台，沉淀通用技术打不穿的核心能力。

做得多和收得住是两回事。FDE 的门槛从来不是能不能做出来，是能不能收得住。收得住的标准是：**每一次现场交付，都要变成平台的一次进化**。

华泰证券那边的做法可以作为正面参照：把研究方法沉淀成 AI 可执行、结果可校验的能力模块，做成集团内共享的 Skill 生态，而不是每个团队各做一套。

**代价**

回平台这件事永远排在交付之后，因为交付有 deadline，沉淀没有。要有人专门盯着这件事，否则它永远被推迟。

三件事能让它真的发生，都不是技术问题：

1. **平台要有 owner，且 owner 的考核里有“被复用了几次”。** 没有这条，回平台的东西没人接，接了也没人维护。
2. **项目立项时就写明这次要沉淀什么，验收时一并验。** 等到交付结束再讨论，答案是“下次再说”。
3. **沉淀下来的东西要有文档和示例。** 别人看懂才会用，看不懂的东西等于没有。我见过回平台的组件写得很好，但只有作者自己知道怎么调，最后还是被各团队重新实现了一遍。

---

## 五问自检，与下一篇

判断你做的是不是真 FDE，问自己五个问题：

1. 最近一次项目，有没有一个东西回到了平台，被别的场景直接用上？
2. 上一个场景踩过的坑，下一个场景有没有绕过去？
3. 现场发现的问题，有没有一条能追溯到它改变了平台上的哪一行？
4. 做这个项目的人调走了，下一个接手的人能不能直接看懂？
5. 业务岗现在说起这个工具，用的是“你们的系统”还是“我们的工具”？

前四问答不上来，说明还停在第三道坎或者更早。第五问是个侧面指标。业务开始把它当成自己的东西，才说明它真的被使用了。

还有一点要说明：内部 FDE 的“产品”不一定要对外售卖。它可以是一套平台、一组组件、一条标准流程，甚至只是一份被多个部门共同遵守的约定。判断标准只有一个：**别的部门能不能直接拿来用**。能，它就是资产；不能，它就还是项目。

内部 FDE 最大的风险，前面提到过，是变成闭门造车，不接触外部，自己的做法越走越窄。判据也很直接：如果连续几个项目里，你没有遇到过任何一件“别人已经解决过、我们还在自己摸索”的事，多半已经封闭了。这时候该引入外部视角，或者组一个内外部混编的小队。

本篇讲的是路径：一个 AI 工具要爬过哪四道坎。下一篇讲方法：第二道坎那三样东西（评测集、兜底层、责任链）具体怎么建，最小可交付物长什么样。

---


大多数企业 AI 项目不是死于模型不行，是死在验收、流程和责任上。这个系列从甲方内部视角讲三件事：路径，一个 AI 工具要爬过哪四道坎；方法，评测集、兜底层、责任链怎么建；底线，金融行业有哪四类部件只能自己攥着。三样合起来，AI 才可能在企业里活下来，不是跑通一次，而是长期活着，并且能被复制。本篇讲这套机制的路径层。

甲方内部 FDE（一）：AI 落地要过的四道坎

FDE 能拆成一句话：把业务现场变成产品研发的前沿。区别不在人在哪儿办公，在现场遇到的问题往哪儿流。这篇讲甲方内部 FDE 要爬的四道坎：demo 跑通不等于需求是真的；要上线会撞上确定性的验收标准；要被真正使用得先动流程；能复制到下一个场景才算数。MIT NANDA 的报告给过一个漏斗，60% 的组织评估过 AI 工具，20% 进试点，只有 5% 进了生产。文末五问自检，判断你做的是不是真 FD

人工智能

职业发展

甲方内部FDE是AI落地的关键路径，需跨越四道坎：需求验证、验收标准、流程重构、场景复制。通过原型验证真实需求，建立评测集与责任链，将AI产出与人工确认分层，沉淀可复用资产至平台。确保每次交付成为平台进化，而非独立项目。

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

甲方内部 FDE（一）：AI 落地要过的四道坎-腾讯云开发者社区-腾讯云

甲方内部 FDE（一）：AI 落地要过的四道坎

甲方内部 FDE（一）：AI 落地要过的四道坎

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐