百万年薪的FDE到底要解决什么问题？句子互动李佳芮：80%的Token都在空转，“客户提的需求都合理，但给的方案永远是错的！”

责编 | 王启隆

出品丨奇点折射（ID：rgznai100）

“客户提的需求都是合理的，但是客户提的解决方案永远是错的。”

李佳芮每天面对的，正是这样一类问题：企业已经有了模型、Agent 和 AI 项目，但 AI 还没有真正进入业务。数据是乱的，老系统没有打通，业务人员说不清自己的需求，Agent 上线后又很难保证效果。模型可以回答问题，低代码平台可以搭出 Demo，但从 Demo 到结果，中间仍然隔着一条巨大的鸿沟。

这也是 FDE（Forward Deployed Engineer）这个岗位存在的原因。

在上，句子互动创始人李佳芮分享了团队从 Prompt Engineer 走向 FDE 的三年实践：如何进入客户现场，理解客户的生意，用工程化方式交付结果，并把现场遇到的问题沉淀回自己的产品基建。

以下内容根据李佳芮在 2026 奇点智能产品大会上的演讲与现场问答整理。

客户说“改 A”，FDE 不能真的只改 A

我是句子互动的创始人。十年前我是一个程序员，做过一个开源框架，有 2 万多个 star，在 AI 到来之前就已经影响了上百万的开发者。

2023 年，也就是三年前，我们团队开始用 AI 交付结果，那个时候有了 FDE 这么一个岗位。我们的 FDE 团队到现在为止已经迭代了四个版本，就像迭代产品一样，不停地做画像，包括怎么做人才筛选、怎么做人才培养。我们的 FDE 有新兵训练营，有老带新，从新兵训练营到独当一面，再到带新人，整个过程都在迭代。

句子在做的事情，就是为企业直接交付结果，为企业部署 AI 员工。

今天我们看到，基模的确定性已经非常强了。但是，千行百业里用 AI 的方式还是打开豆包，这显然是不对的。

所以中间有一个巨大的鸿沟。前段时间很火的Harness 工程也好，FDE 也罢，说的其实都是一件事，企业还没真正用 AI 交付结果。

我们已经服务了 1,000 多家大型企业，覆盖在线教育、政务、金融、消费等行业，包括最近在制造业上的实践。我们的 AI 员工已经完成了 5,000 多万次自主决策，这是 2025 年的数据，是我们内部的数据。

今天整个分享分为四个部分：第一部分，全世界都在抢 FDE，这个岗位是什么；第二部分，从 Prompt Engineer 到 FDE，我们三年踩过的坑；第三部分，我们的产品是怎么长出来的；第四部分，我的思考：FDE 是一种能力，不是一种岗位。

为什么连 OpenAI 都需要 FDE

FDE 是硅谷今年最火的岗位，过去 12 个月里，FDE 的招聘量全行业翻了 7 倍，原来是 643 个，现在到了 5,330 个。a16z 称它为 tech 最火的岗位，YC 的创业公司里有 100 多家在招，而三年前一家都没有。

价码也在水涨船高。顶级 FDE 在 OpenAI、Anthropic 的总包是 30 万到 60 万美元。做到资深、不带团队的——我们内部现在把这种 FDE 叫作“大头兵级别”的 FDE——好的总包在硅谷能达到 100 万美元。

那巨头在做什么？自己建团队、花钱买，还得拉上咨询公司。

OpenAI 今年做了两件事。一是把 FDE 做成一家独立公司，叫 The Deployment Company，初始投资超过 40 亿美元；二是收购了英国的 TOMORO，一口气拿下 150 个现成的 FDE。OpenAI 意识到：让模型进入企业，不是基模厂商自己能做完的事，得有 FDE 带队往前落地。

Anthropic 组建了 Applied AI 团队，让 AI 工程师进入世界 500 强做落地，和 Blackstone、Hellman & Friedman、高盛合资 15 亿美元成立了一家企业 AI 服务公司，把工程师送进世界 500 强。其他的，包括 Google、Databricks、Scale AI，几乎所有 B 轮以后的公司都在大规模招聘 FDE。

光招聘、买团队还不够。那为什么连 OpenAI 都缺人？它不缺钱、不缺工程师，连现成的 FDE 都买得到，它缺的是另外一样东西：钻进一家企业，把生意摸透，对结果负责。

这件事情非常难。

我们在过去三年为企业部署 AI 员工的过程中，发现自己遇到了各种问题。首先，企业内部现场脏乱差，数据全是乱的；一堆老系统完全没打通。

第二个问题是，企业内部的业务人员说不明白自己的业务需求。如果他能说明白，他就能做产品了，就能做我们这家公司了。大部分人是讲不清楚自己要干什么的，这也是为什么咨询公司要下场。

第三个问题是，如果没有一个很强的产品基建，每次去企业内部搭建的成本都高得离谱。

第四个问题是 Token 成本。我经常开玩笑跟客户讲：“你自己去搞，自己搞完以后，付 Token 的钱可能比给我付 AI 员工的钱还要高。”不是所有公司都能合理利用 Token。

我前两天看到一个数据，80% 的 Token 都在空转。怎么让 Token 有效利用，也是过去三年我们踩过的很多坑。

最后就是很难保证效果。我们现在做了一个叫“句子守护”的产品，就是怎么做 Agent 的 Benchmark。Agent 需要 Evaluation，需要一套评估、测评体系。保证不了质量，就没有办法让 AI 员工真正上岗。

企业内部遇到的这么多问题，都不是基模能解决的，它需要有人下场去做，尤其做很多 dirty work。

FDE 是怎么被发明出来的

这个词从哪儿来的呢？它就是 Palantir 的第 13 号员工 Shyam Sankar 在聊的事情。

十几年前、二十年前，Palantir 遇到的情况，和今天我刚才说的情况非常相似。Palantir 的客户都是什么？美国的情报机构、五角大楼。他们说不明白需求，数据不出域，也没有需求文档，同样遇到了刚才我说的所有问题。

东西是机密的，写不进需求文档，开不起会议。所以 Shyam Sankar 直接把工程师塞进客户现场，驻扎在基地、分析员办公室等等，靠观察、实验、当场动手，最终给企业交付结果。

当时 Palantir 的竞争对手是谁呢？是 SAP，是埃森哲（Accenture）。

SAP 最大的问题是，它整个产品开发流程太长了，等开发出来以后，可能情报机构遇到的问题都变了。

埃森哲的问题是，它只会出特别牛的 PPT，但是 PPT 解决不了问题。

而 FDE 正好取了他们俩的中间：我又有 PPT，又有明确的落地；我还告诉你要解决什么问题，周期还短。代码“脏”一点没关系，我沉淀回我的 Foundry，沉淀回我的产品平台里面，下次交付成本更低。

所以，这就是我们说的 FDE，也就是 Forward Deployed Engineer。

这是当时 FDE 的发明者 Shyam Sankar 说的：

如果一个问题能用一份需求文档解决，那么这个问题早就被解决了。

所以精妙的事情不是把人派出去，而是背后那一套分工。

FDE 最核心的三项能力

我认为，FDE 最核心的有三项能力。

第一项能力，你必须有咨询能力。刚才我讲到的这些背景，都是咨询能力要解决的事情。

第二项能力，你必须能够为客户直接交付结果。FDE 的落脚点是什么？是 Engineer。所以我必须能够用工程化的方式——别管是什么方式——去解决问题。今天可能我们有了自己的产品基建以后，不需要传统意义上的 Engineer 了，但他也需要像工程师一样会拆解、有逻辑、能分析、能交付、能给结果。

第三个能力也非常重要。对我们这样的公司来讲，这是我最看重的能力：他有没有能力把当下踩过的坑回传到我们的产品里面。

以前我们说产品，说的是产品模块、产品功能、产品线；今天我们都叫它产品基建。我们的七大产品基建里，只有两个是当初在办公室里想出来的，剩下五个都是 FDE 在现场不停遇到问题、重新打磨出来的。

所以我认为，回到产品里面才是最重要的。

我经常会被问：“那你这不就是外包吗？”这就是外包和 FDE 的区别。如果你不沉淀回自己的产品里，下次交付不能做得更快、更好、质量更强，那么你就是一家外包公司。

所以今天我还是有底气说，我们能够用同行 1/10 的时间、1/10 的成本，交付两倍好的效果。背后是我们的产品基建，以及我们磨了四代、磨了三年的 FDE 团队。

第一个坑：摸不懂客户的生意

跑了一年半，大概这个事情干了一年半，我一直都在救火。救了两类火，这两类火都让我非常痛苦。

第一类火就是摸不懂客户的生意。尤其我们最开始做在线教育的时候，客户直接找我投诉，说：“你们能不能不要老出单点故障？你们能不能以点带面？”

我也听不懂他在说什么。拆了半天我听懂了，他的意思是：“我不能说改 A，你就直接给我改 A。”

我们的 FDE 心里想：“你都让我改 A 了，我为什么不改 A？”但实际上，客户说 A，背后代表的是 XYZ。你的 FDE 必须有能力知道，他的 A 代表的是 XYZ，并且把它改好，还能够提升他的业务。这才是客户需要的。

但这件事对于我们的 FDE 来讲很难。他们都是 00 后，刚毕业一两年，不会沟通，没有做过项目管理，更没有业务经验，他怎么可能知道呢？

所以后来我的解法就是找行业专家，和咨询公司合作，现在他们陆续已经成为我们团队里的人。他们带着自己的解法去现场，一上来就像刚才我讲的那样，比客户还懂他的业务。

我们直接让咨询师上场，帮客户拆业务、理 SOP、理所有的东西。这个时候 FDE 再去跟他搭配，效果就非常好。

这个解法，其实让我们的在线教育行业的客户，基本上从最早一年半以前只能做到人效翻倍、转化不掉，到现在已经能做到 4 到 5 倍的人效提升。这个结果比我想的还要好。

我们知道怎么拆业务数据、怎么拆过程数据、怎么拆结果数据、怎么帮助客户复盘。

所以，这是第一个坑：让 FDE 搞不懂客户的生意，解法就是让有咨询能力的人下场。

第二个坑：上线以后质量兜不住

第二个坑是上线以后质量兜不住。其实兜不住的原因在于，真正生产级的产品都非常复杂，一个 Agent 的 workflow 500 个节点 甚至800个节点，把 A 改对了，就把 B 改错了；把 B 改对了，又把 C 改错了。

这么多节点让客户去测，完全测到是不现实的。问客户要测试用例，客户最多给 30 个测试用例、50 个测试用例。但我有 500 个节点、800 个节点，需要的测试用例至少得有 500 个。

人写测试用例是完全不靠谱的，一方面不全，另外一方面也不够准确。

所以后来我们的解法是，干脆新推出一个产品叫"句子守护"，包括 AI 生成测试用例、灰度发布、版本管理、批量测试、回归测试、AI 测试、AI 出测试报告、AI 工单、AI 质检等一系列的能力事情。

只有把这些东西交给 AI，充分发挥模型的能动性，用 Harness 工程，类似 Claude Code 的工程手段，才能最终解决问题。

这个坑当时踩得非常痛苦，就是如果做好测试。包括我们公司的研发在推动系统化的测试，我们内部是 TDD 的模式（Test-Driven Development）即使是在工程领域，我们认为测试驱动也是很重要的。

今天来看Agent 开发和软件工程也是一样的，要用测试驱动。你的测试用例是不是足够多？是不是足够全？以及怎么批量测试，怎么回归测试？是不是有能系统化、工程化的测试？这是非常重要的。

这就是为什么我们说今天我们能做 Agent 的 Benchmark，能做好 Agent 的评估体系。背后就是这样的背景。

最开始我们的 FDE 不愿意用句子守护，因为他觉得浪费时间；销售为了保证客户的结果肯定希望 FDE 用，但销售又无法评估 FDE 是否真的使用了句子守护。

后来为了解决这个问题，我要求 FDE 必须给测试报告。测试报告怎么给？他自己写。AI 时代肯定不应该这么做，所以我们就做 AI 生成的测试报告，所以句子守护支持了自动生成测试报告。今天来看，句子守护不只守护了 Agent 的健康，它还守护了 FDE 的工作流程。

没有经过回归测试的东西是一定不能上线的。一份销售也能看懂的测试报告是非常重要的。

产品不是在办公室里想出来的

第三部分，我们的产品是从现场长出来的。

刚才讲到我们的七大产品基建，只有两个是坐在办公室里想出来的。一个是 2019 年公司刚成立时做的产品，叫“句子秒回”，它是一个 AI 和人协作的工作台，是 SCRM 时代的东西。

一个是“句子秒懂”，就是刚才我讲到的那套低代码平台。

后面这五个，是 FDE 在现场不停遇到问题、重新打磨出来的。

“句子懂行”：客户的知识库先要做知识工程

客户提的需求都是合理的，但是客户提的解决方案永远是错的。

作为 FDE，你能不能识别到客户真正想解决的问题？以及 FDE 遇到这个问题的时候，能不能知道怎么回流到自己的产品基建里面，把它做得更好？客户经常觉得：“我的数据特别值钱。”我经常有个暴论：95% 的客户的数据根本不值钱，他的数据就是垃圾。

什么数据是好数据？经过处理、清洗的数据才叫好数据。为什么 Scale AI 能那么值钱？虽然最后被 Meta 收了，但它还是很值钱，是因为从数据到有效数据之间有一个巨大的鸿沟。

客户给我的东西经常是一堆文件。这个文件说报价 3,000 块，那个文件说报价 6,000 块，你让 AI 去做，它哪知道哪个是对的？

客户的数据需要做知识工程。

我们的“句子懂行”后来就是帮助客户做更好的知识工程。它不是做更好的 RAG，不是做一系列 Agentic Search，也不是做一系列 Agentic RAG，不是什么 Chunking，这些都不是。

真正的事情，是在前面给客户做知识工程。我们有一套标准，也有一套 Harness ，类似 Claude Code 的这种方式，做出了一整套产品，叫句子懂行，帮助客户做知识工程。

当时也是一个 FDE从客户现场“哭”出来的。他到客户现场非常痛苦，因为客户的各种系统他也搞不明白，客户也分不清；他找我开会，也说不明白到底要什么。句子懂行就是这么长出来的。

“句子 CLI”、“句子制造”和“句子问数”

我们的“句子 CLI”，是从对接客户老旧系统的自动化模块里长出来的。后来我们发现，客户那些跑了很多年、动不了也换不掉的老系统，同样可以封装成一个 adapter 接进来，被 AI 调用。

“句子制造”为什么会长出来？因为我们在为客户交付的过程中经常遇到这样的事情：客户找的定制开发交付的软件质量非常差，差到没有办法给 AI 用；客户上一代的系统也经常非常复杂，其实都不是最佳实践。

后来索性说，那这件事我们自己干吧。我们自己做 Coding Agent，让 FDE 用我们的 Coding Agent 交付结果，并且和我们所有系统的数据都打通。

“句子问数”产生的背景是，客户最后还是需要 BI。2B 软件一定是给老板看的；老板看的一定是数据，老板看的一定是归因。

这个时候他就需要 BI。每次给客户搭 BI 都很难受，所以我们又做了一套 Harness：要什么数据出什么数据，随时计算，保证 100% 准确，而且所有归因都有，所以有了句子问数。

这些产品其实都是从现场长出来的。我们一直想给企业交付 Agent、交付 AI 员工，后来就长出了这样的七大产品基建。

我们分三层：上面一层是给客户用的，句子秒回和句子问数；中间一层是搭建 Agent 的，有句子秒懂、句子守护、句子懂行；下面一层是补齐其他数字化底座的，有句子 CLI 和句子制造。

通过这种方式，基本上我们能用 1/10 的时间、1/10 的成本，交付两倍好的效果。

FDE 不是岗位，而是一个客户、很多能力

刚才讲了这么多，其实是在说，FDE 和大家熟悉的所有 2B 岗位都不一样。我经常说，这些岗位的终点，是 FDE 的起点。

产品经理做的事情，是做一个功能卖给所有客户，他的成败看这个功能有没有上线。售前做的事情，是签单前做演示，成败看有没有签下来。交付看的是按合同交付完，交完就走，成败看有没有验收。客户成功看的是客户能不能长期用起来。

但 FDE 不是。FDE 是扎进一个客户的生意里，能力不设限，把 AI 真的装进他的业务。他最后看的是客户的转化、客户的人效有没有真的提升。

所以，他看的不是这些过程，而是最终的结果。前面这些能力要融合在 FDE 里面，当然公司还得给他配其他能力。

用我自己的话定义 FDE，就是：

一个客户、很多能力，对客户身上的真实成果负责。

他既能读懂客户的生意，还能够把成果设计出来，还能用工程手段兜住质量。写代码只是其中的一道工序而已，他更多要做的是，怎么让 AI 真正变成生产力。

所以，第一个该招的不是工程师。我们第一天就没有招工程师。

我们之前最好的 FDE，是一个 00 后、学法语的女生。她没有任何技术背景，但是有非常强的好奇心、非常强的动手能力，并且有特别强的责任心。

Palantir 最成功的几位 FDE，背景是物理和数学，也不是计算机；有些人加入前根本没写过软件。Palantir 的 CEO Alex Karp 本人也是哲学博士。

真正稀缺的是什么样的人？好奇心和执行力，这其实也是我招人最看重的事情。

好奇心，就是他愿不愿意钻进一个和他八竿子打不着的生意里面，把它搞懂、搞透；执行力，就是他愿不愿意立刻把事情干起来，而不是永远都在想、永远都在提问题。

从诊断，到共建，再到落地

一个项目怎么做？分三个阶段：从诊断，到共建，再到落地。

诊断就是咨询团队，包括懂这个行业的专家入场。甚至专家入场不一定非要线下面对面，其实现在我们 FDE 的线下驻场只有 20%，有 80% 都是远程交付的。

然后是共建，把东西搭起来；再到落地。尤其重要的是，怎么量化交付结果。我们带大家做 A/B Test，包括怎么按结果付费，这里面也踩过一堆坑。

最简单的是，大家一定以为按 GMV 分成是最好的结果，但其实不是。按 GMV 分成最大的问题是变量太多：流量质量、流量价格、毛利水平、优惠策略、渠道分布，以及销售转化的人等一系列事情。

所以，在不同的行业、不同的岗位，怎么定义好 AI 真正交付的结果，我觉得这很考验创始人，也很考验业务负责人的水平。

怎么证明这个结果是真的？刚才讲到的 A/B Test，有 AI 组和对照组，怎么做这件事？时间关系我就不详细展开了。

这里有一个数据，当时我们做在线教育客户的实测，人效帮他翻了 4.5 倍；另外一家公司翻了 3 倍。

有一个客户，转人工率从 27% 降到了 2.73%，故障率从 16.26% 降到了 0.13%，线索量 6 个月翻了 11 倍，客户付费随结果而增长。

有一个点我觉得是反常识的。以前我们经常追求转人工率要低，但现在我反而不会跟客户讲转人工率到底要高还是低。很多时候，转人工的质量比数量更重要。有些时候真的就应该人去做；有些事情，给 AI 是不是真的能做，这也是很重要的一件事。

按结果收费，也会失败

按结果收费，我们也踩了一年的坑。刚才讲到按 GMV 分成、按线索量分成，其实也讲了一些，包括过程指标的数据。

核心是，如果你不懂他的业务，就不敢按结果付费。尤其是按 GMV 收费、按结果付费，用 GMV 付费一定是一个天坑，因为你永远不可能知道他的真实 GMV。

所以，怎么定义好你要量化的结果，背后其实取决于你有没有真正懂他的生意。

还有一个反直觉的坑，这是我们后来跑了很久才发现的。当时我们想赶快把市场铺大，我和咨询团队一起说：“不收咨询费，我就敢对赌，按结果付费。”结果反而不好。

因为客户如果不付一份咨询师的钱，他就不认真，一直是玩玩的心态。最后 CEO 调度不了所有的事情，大家都觉得没事，觉得这件事优先级不高。

但当我要求客户一定要付一笔咨询费的时候，哪怕只有 30 万，哪怕只有 10 万块，大家就会意识到：“我付了咨询费，这个咨询周期只有 6 个月；这 6 个月不干，过了这个村就没这个店了。”

所以后来我们开始收咨询费了——这本身是在筛选客户。选择那些严肃认真对待 AI 转型的客户。很多时候，收费是一个很好的筛选标准。

FDE 是能力，不是一种岗位

我认为，真正的 AI Native 公司应该人均 FDE，或者人均 OPC（One Person Company, 一人公司）。今天句子还没达到这样的水平，这也是我努力的方向。

本身一个事情就不应该要一连串的人分工去做，我们知道在 AI 里面，上下文是最重要的。团队协作也是如此，每一次人和人协作传话的过程中都会丢失上下文，每一次沟通都会产生信息熵。最好的方式，就是不要有传话，最好的方式就是一个人完成一个事情。

而在 AI 时代，这件事变得可行，每个人都可以向前一步，可以做更多事情。所以每个人都可以是 OPC。

包括我们公司。我们公司官网“加入我们”页面，里面有公司介绍和招聘信息，全部都是是 HR 写的。写完以后，他自己提交代码、合并上线了。他是一个完全没有技术背景的人，但他能一个人完整地做成这件事。

所以今天我们说，一个人加一支 Agent 队伍，才是 AI Native 组织的样子。每个人都要能管理一堆 Agent。我认为的组织最小单元已经从一支团队变成了一个人加一支 Agent 队伍。

刚才我在开头也讲了，我们对外叫 FDE，对内这个岗位叫 AI 管培生。

一家 AI Native 的公司一定需要氛围感。HR 也用，销售也用，财务也用。这里说的是真的在 vibe coding，而不是打开豆包问一问。我一直认为，如果只有研发在 vibe coding，那么这家公司绝对不是一个 AI Native 的组织。

今天来这场分享同时，我们公司内部也在进行着 AI Workshop。我们每两周有一次 AI Workshop，每个季度有一次 AI 员工 Hackathon。

我们的工具给到顶，Token 不限量，给大家 Mac，包括给大家所有使用的 AI 基础设施，解决所有人在使用 AI 路上遇到的卡点。这就是我说的 AI Native 的氛围感。

组织正在从流程变成并行网络

第一代最牛的组织是华为，它叫“Run a company as a process”，把公司做成一套流程，所有东西都是标准化的。

第二代最牛的组织是字节，它叫“Develop a company as a product”，不停迭代，把公司当作产品去做。

而我认为，接下来 AI Native 的组织应该是 Anthropic，叫“Design a company as a parallel network”。你能不能把公司做成一个并行的网络？

我现在个人效能已经翻了 4 到 5 倍，还没做到 100 倍，我基本上开会一定会让 AI 并行工作。哪怕是我自己主持的会，除非是这种可能没法并行的场景，只要有电脑，我一定一边开会，一边让 Claude Code 干活；我再去扫一眼有什么问题，它还能发到飞书里面。

我觉得，这是第三代组织。

最后，大模型不会自己变成客户的转化、人效和营收。得有人扎进去，一寸一寸地把它落下来，这就是 FDE。

这也是句子互动一直在做的事情：如何让 AI 真正成为生产力，如何让 AI 员工在企业真正上岗。这也是过去我们三年的实践。

Q&A：FDE 如何交付结果，又如何避免变成外包 提问 | FDE 如何解决不懂业务的问题？

现场观众：句子这边在做 FDE 的时候，有没有失败的案例？为什么会失败？在回到标准产品的过程中，FDE 和产品团队的合作机制可以分享一下吗？

李佳芮：第一个很重要的坑，就是刚才讲到的不懂咨询。FDE 会被客户带着跑，客户说 A，我就改 A，但其实客户想要的是 XYZ。怎么解决这个问题？我们配了咨询团队。

现在我们确实到了一定体量，能请得起麦肯锡的合伙人、科尔尼的合伙人。但早期的时候，如果实在找不到咨询师，那就只能 CEO 自己上，或者创始人自己上。你必须把那门业务弄清楚，不然 FDE 是不成立的。

第二个，FDE 一定要做高客单价。如果客单价只有一两万，那肯定是做不起来的。

第三个，就是刚才讲的，FDE 一定要回到产品基建。

第四个，FDE 最大的问题，其实是怎么验收他的结果。

今天 AI Native 的人，这种 AI 原生的人，最大的毛病就是他不好好检查 AI 产出的结果，或者有的时候可能也检查不过来。

拿出来一个东西给我看，那玩意儿一看就是 AI 写的。我说：“如果都是 AI 的东西，我用你干什么？”

FDE 如果这样会非常可怕，因为他直接面向客户，而你又不能跟上所有项目，于是他直接把一个 AI 的东西扔给客户。客户就会觉得：“这家公司，你和智谱有什么区别？你和豆包有什么区别？”

这其实是需要回答的问题。

提问 | 企业老板如何做 AI 转型？

现场观众：一个将近 2,000 人的团队做 AI 转型，怎么说服老板？

李佳芮：首先，我认为老板一定不是你说服的。你要找到真正有 AI 转型痛点的公司，不要试图叫醒一个装睡的人。

现在中国有大量真正有 AI 转型痛点的公司，但我认为也就 20%，绝对没过半。80% 的人还是口头 AI 焦虑、口头 AI 转型，还是在说自媒体意义上的 AI 时代。

你要找到那 20%，帮他解决问题，这是第一步。

第二步，找到那 20% 以后，至少我们公司的 FDE 还没有能力直接跟老板讲怎么做转型。我们的解法就是请咨询师。

提问 | 咨询加 AI，和咨询加软件有什么区别？

现场观众：过去给企业做管理咨询，通常是咨询公司加软件厂商。现在是咨询加 AI，怎么看两者的区别？

李佳芮：如果是咨询加软件公司，最大的问题是大家不停地出需求，软件迭代速度非常非常慢。哪怕你 vibe coding，软件开发的质量也很难搞定，包括 Code Review 也非常痛苦。

所以一定要有咨询，再加上软件产品的基建。我能够用最快的方式把事情弄好，真正交付结果，并且量化结果。

FDE 交付的 Agent，是不是一定要成为我们内部所说的 Agent 最佳实践？我们经常说，可能凑凑合合能用就行，就是一坨“屎山”，一碰就废，没问题。只要外面有一层好的兜底机制，能保证解决客户的问题就可以，因为这些都是一次性的东西。

我们真正反复复用的，是产品基建。我们的产品一定要做得非常强，但每次给客户交付的时候，核心是快速解决他的问题。Dirty code 没有任何问题。

所以 FDE 的核心是以解决问题为目标。包括 Palantir 的所有 FDE，交付的都是 dirty code，里面都有很多问题，但不重要，他回流给产品基建，下次就会更好。

这也是它和传统软件公司的不同之处。

结语

李佳芮这三年的实践，指向的并不是一个新的岗位名称，而是一种新的交付方式：有人进入客户的业务现场，理解客户真正的问题；有人用工程手段把结果做出来；现场遇到的问题再回到产品基建，变成下一次交付的能力。

大模型不会自己变成客户的转化、人效和营收。

得有人扎进去，一寸一寸地把它落下来，这就是 FDE。

2026 奇点智能产品大会汇聚 40+ 位一线产品技术专家与行业实践者围绕 Agent、企业级 AI、AI Coding、具身智能、AI 原生组织、行业应用落地等方向，分享了大量 AI 产品实践与落地思考。

我们将陆续整理嘉宾演讲内容，帮助大家复盘现场精彩观点。欢迎读者朋友们扫码领取大会 PPT 合集，获取一线专家的实践经验与深度洞察。