会搭几个Agent，就敢给企业做AI转型了？FDE车祸现场

作者 ｜ 松子（李博源）

有些企业 AI 项目，还没进场，事故隐患就已经写进了课程表：一个项目部才能接住的工作，被当成了一个人的结课能力。

有人说，他正在尝试绕过 IT 部门，让业务部门直接用智能体重构流程。如果做成了，再开一个分享会，请甲方客户一起讲。

我在群里提到，这几年已经陪跑了几家企业，有出海公司，也有大型国企。

然后我就去开会了，后面的话没有继续说。

回来再看群里的讨论，越看越觉得，那句没说完的话，其实比做了几家更重要。

那几年我们通常把这些工作叫顾问、数据建设或者项目陪跑。客户带着团队、报表、业务分析的问题来，做着做着，事情就越过了原来的边界：组织怎么分工，口径在哪里确认，工程怎么接，谁继续往下用。今天再看 FDE 的讨论，我认得的首先是这些工作，不是这三个字母。

大家当时聊到几个观点：不要把 AI 当成 IT，不要把 AI 落地委托给 CTO；Agent 是新的 workforce，应该用管理学看；FDE 不要等甲方说清需求，要到现场直接解决问题。

接着这几句话，我想问：业务没说清，技术可以绕过，老板已经点头，最后谁来判断做出来的东西对不对？

让一号位亲自推动，项目可能跑得很快。过去很多大型数字化项目最后搞成烂摊子，也是在一号位强力支持下完成的。

至于“不要把 AI 当 IT”，这句话更容易被讲歪。它原本是提醒业务部门不要把责任甩给技术部门，最后却可能变成另一种自信：代码我看不懂没关系，架构嘛，又不难；业务我熟，Agent 让 AI 写出来就行。

现在又多了一个 FDE 的名字。新人可以进这个岗位，是否意味着上完一门短训课，就能独自处理这些问题？

机会是真的，所以才不能把入口讲假

我做顾问，对其中一种变化尤其在意：以前写下“建议这样做”，常常还要等下一支队伍接手。现在有了 AI，查询、原型和测试更容易做出来，一些判断可以当场往下验证，不必先转述几轮。

这对做过顾问、数据、产品和实施的人，尤其值得认真看。

以前积累的东西并没有作废。你知道该找谁核对口径，知道一个流程为什么绕路，知道哪类需求其实是在掩盖另一个问题。AI 让你更容易把这些判断转成查询、原型和测试；但也会逼你面对以前可能交给下一岗的问题：东西已经做出来了，究竟对不对，下一步谁用？

对工程师也是一样。客户现场不只是一个需要忍受的沟通环境，也可能让你第一次看清：一个技术选择，为什么会让业务少等一轮、少抄一次、少做一段无用功。由此发现的产品机会，往往不会原样写在需求单里。

Yash Patil 在一则 X 帖子里，提出让技术人员靠近对结果负责的业务人员，从隐性经验中建立贴近真实失败的评测，再用运行结果改进系统。这条学习路径值得试。

新人也应该有机会进入这样的工作。跟着团队核对一条数据链、处理一组真实失败、听完一次业务与工程争论，比只学会复现一个演示更能建立判断。经验需要积累，不代表只能按年头排队；工具和好的协作，可以让学习更快、更具体。

招生页面若把这段学习过程删掉，剩下的就只是一条从工具演示直通高薪岗位的捷径。真正进场以后，缺掉的那段还得补。

FDE 不是 AI 时代才发明出来的职业。同一个名字里，现在至少塞进了五种工作。有的公开岗位要四五年经验，有的明确招应届生；有的课程面向已有经验的人补短板，也有零基础、无需代码的工作坊。问题不在这些入口能不能存在，而在它们最终向谁承诺了什么。

市场正在把五种人都叫成 FDE

我去看了一圈现在公开的岗位和培训。

OpenAI 公开的 FDE 岗位写明五年以上工程或技术部署经验，工作从原型延伸到稳定生产，要求参与代码、推动采用，把工作模式和现场反馈带回团队。光会做演示，接不住这份岗位说明。

另一边，FDE 课程把 L1 写成面向非技术人员的零基础入门，两日工作坊强调无需代码，也使用 FDE 认证名称。

一头是五年经验、生产上线和工作流影响。

另一头是零基础、无需代码和两天工作坊。

上完后面这门课，离前面那个岗位还差什么？招生页得回答这个问题。

这里我得先改一下自己原来的说法。这个系列最初叫《FDE 不是 AI 时代的初级岗位》。后来继续看岗位，我发现这个标题说满了。

Palantir 确实直接招聘 New Grad FDE。应届生可以进入这个岗位，参与小团队端到端工作；同时，岗位要求编程能力，并与其他工程师共同做架构和设计。不能因为这件事责任重，就说年轻人只能在旁边打下手。

应届，不等于零基础。进入一个有工程协作的团队，也不等于拿着培训证书，独自替一家企业判断业务、架构和上线风险。

这个区别要讲清楚。否则我一边批评别人偷换概念，一边也拿资历替能力盖章。

我要追问的是课程承诺：有没有把入门能力卖成独立交付能力，有没有拿少数高薪岗位暗示普遍就业结果。仅凭课程页面，还不能认定某家机构在骗人。

AI 认知课就是 AI 认知课，Agent 实施课就是 Agent 实施课。把完整责任切掉，只留下最好教、最好展示、最好发证的部分，然后还叫 FDE，不是降低入门门槛，是把职业定义掏空。

现在一个 FDE 标签里，至少塞进了五种人：

这张表不排职业高低。同一个人可以承担几种工作，团队也需要不同深度的人；课程该说明自己训练的是哪一段。

我判断一门课是在培养 FDE，还是借 FDE 卖课，不太看它用了多少新名词，只连续问六个问题：

它是否讲清学员需要什么业务或工程基础，缺少基础的人结课后只能承担哪一段？

它是否训练学员发现“这里根本不需要 AI”？

它是否处理真实数据、接口、权限、遗留系统和生产环境？

它是否交付可运行系统，而不只是一个 Demo？

它是否训练采用、基线和业务结果验证；培训期无法完成长期验证时，是否诚实说明，而不拿结课展示代替？

项目失败、范围改变、客户冲突时，学员是否要解释为什么，还是换一个 Demo 继续讲？

如果课程承诺的是就业，还得接着问：拿哪类岗位做对照？入学前是什么基础？多少人完成课程，多少人进入相应岗位，负责哪一段工作？不能把一位原本就做了多年工程的人转型成功，算成一门零基础课程的成功。

高薪招聘最多说明某家公司愿意为什么样的人出价。它不能直接证明，一个刚付完学费的人已经拥有那种能力。

别把案例库，当成培训成绩单

某的 FDE 人才征集里有一句话：不看资历，只看案例。

它要求说明解决了谁的具体问题、结果是否可核验、方法为什么成立，以及本人承担了什么交付工作。用来找实践者，比只看头衔有用。

可拿着这份名单去证明培训效果，就还差一份记录：这些人在入学前已经会什么？

一个做过多年系统集成的人，后来把 AI 接进客户流程；一个熟悉行业的数据顾问，开始用大模型处理非结构化材料。他们在转型时带进来的工程基础、行业经验、客户信用和组织判断，不能在课程宣传里突然消失。

导师介入了什么、结课后学员独立承担了什么，也得接着看。征集名单本身回答不了这些问题。

即使只看案例，四个标准也还需要继续往下问。“结果可核验”，谁核验过，依据在哪里？“讲得清为什么这么做”，能说明方法可以理解，却未必证明换一个团队、换一家客户就能做成。

证据可以匿名、脱敏，也可以由客户内部确认，交代核验方式就好。

课程表背后，少了一整个项目部

一些 FDE 介绍，前半篇还在讲前方工程师和后方产品团队怎样配合，后半篇就开始罗列人才画像：全栈开发、业务诊断、模型应用、高层沟通、商业判断、组织变革，一个人最好全会。

再往下一翻，是课程报名。

前面靠组织解释成功，后面靠个人承诺复制成功。中间那套组织呢？

工程师到现场，背后有成熟平台、代码评审、行业同事、产品 Owner 和可以升级问题的负责人，与一个人带着 Agent 账号进企业，是两种完全不同的工作条件。把前一种条件下的产出，拿来证明后一种人上完课也能做到，这才是偷换。

某 fde 案例集中里的制造业经验传承案例，就给了一个具体对照。按受访者自述，工作没有停在“把老师傅的资料放进 RAG”：先跟着员工观察日常流程，整理新人反复遇到的问题，再把这些问题变成测试集；之后接进原有培训平台，让新人学习、师傅查看进度，并继续调整使用方式。仅后面的陪跑，就接近两个月。

知识库搭出来，只走到中间。

受访者也明确说，自己更愿意把 FDE 理解成团队：有人判断业务，有人实现方案，还有专业技术人员保障架构、性能和扩展。课程表里有没有这些人？

讲台上可以由一个人讲完整个项目，项目并不因此就是一个人做成的。案例最后署一个名字，也不代表判断、授权和工程能力都装在这个人身上。

沟通、协调和工程，都需要真实投入，不能在报价时只算写代码的人，交付时再要求他顺便把所有关系处理好。有人据此提出“E 人对接、I 人构建”的双人搭档，我更愿意把它理解成两种工作重心，而不是性格分工。

能不能听出需求冲突、解释失败、推动决定，要看具体行为；能不能稳定构建，要看工程证据。性格不能替代这些检查，也不该把构建者永远挡在业务现场之外。

面向客户的角色，至少要理解方案边界，不能为了让老板安心，把尚未验证的能力先答应下来。负责构建的人，也得有机会接触真实使用者，不能永远只收到另一人翻译后的任务单。

所谓情绪价值，如果是把进度、风险和下一步说清楚，让客户不用天天猜，可以是专业服务的一部分。如果是每次都说“没问题”，让交付团队在背后补窟窿，那是在提前透支别人。

分几个人都可以。怕的是对接的人已经答应了，构建的人还不知道，等到交付时才发现双方说的不是同一个东西。

我自己做顾问，最不敢省掉的恰恰是这些接口。业务说一个指标，技术说一个字段，两边都觉得自己讲清楚了。我还得继续问：它们指的是同一件事吗？改动由谁确认？解释不一致时，先停哪一段？这个时候，多会一个工具并不能替任何一方作决定。

所谓跨行业能力，也不是一周变成半个行业专家。你可以在短时间内摸清一条具体流程，找到几个关键人，列出一组值得验证的假设。但是，能复述业务怎么运转，与有资格确认业务例外、风险边界，是两回事。学得快的人尤其要知道，哪句话还得请真正掌握业务的人来确认。

因此，一门认真培养 FDE 的课程，除了工具，还应该说明：谁带学员处理第一个例外，谁评审准备上线的东西，谁在他还判断不了的时候接住责任。先在可控范围内承担真实工作，再根据证据扩大可以独立处理的范围。

课程大纲里不能只写“独立解决企业问题”，还得交代独立以前的那段路怎么走。

把一个项目部的能力列成一个人的课程大纲，再把它卖给零基础学员，这才是我真正反对的东西。

组织催化剂、老师、产品经理、创业者，这些描述可以帮助我们看清团队需要哪些能力。但把它们全塞进一个人的培养承诺，也可能只是把原来的“全栈”换成一个更大的筐。

连接业务、工程和组织，是工作需要跨越的边界，不代表一个人因此获得了三个部门的专业能力和决定权。会带工作坊，不等于可以改绩效；能做原型，不等于能批准生产；发现产品机会，也不等于可以带走客户的规则和数据。

所谓复合能力，先要知道哪里能自己做，哪里得与别人一起做，哪里根本不归自己决定。

我也看到过“给自己半年，先补工程，再做应用，最后找真实用户”的转型建议。它可以是学习安排，不能保证半年一到，独立交付能力就随之到位。一个有多年工程基础的人，与一个刚开始接触编程的人，走过相同的六个月，不会自动抵达同一个位置。

新人可以先对一条数据接入、一个受控工作流、一组失败样本负责，再逐步承担更完整的工作。每次扩大范围，都应该知道：上一段哪些事情已经能独立完成，哪些仍然需要评审，出了例外找谁。比“半年后成为六边形战士”慢一点，但至少是一条能走的路。

新人一个月能交付，经验去了哪里

这轮写作中，我参加了一场关于新任 “C AI O”职责、团队和预算的分享。有一段内容，值得拿回来检查我自己的判断。

按会后纪要，嘉宾所在的团队让研究生实习生参与真实小项目，约一个月能够产出及格交付物。团队规模不大，借助 Agent 处理具体研发任务。

只截这一段，标题很好写：新人一个月就能干，FDE 还要什么多年经验？

但把纪要往前翻，条件又回来了。负责人有二十多年半导体经历，团队中有博士成员，还要与业务部门的工程师交流，把具体流程逐步整理进 Skill。当前主要选择熟悉的研发领域，承接的也是能够切小、检查结果、较快迭代的任务。

这让我想继续往下看：新人交得更快，原来需要经验才能做的那些决定，现在是谁在做？

它有一部分在负责人脑子里，有一部分来自合作部门的工程师，有一部分被整理进工具和 Skill，还有一部分体现在先接什么活、暂时不接什么活的选择里。实习生拿到的任务，并不是未经处理的整个企业问题。

AI 可以让新人更快产出，也可以让小团队承担更多工作。但专业判断、组织协调和结果责任究竟被转移到了哪里，不能从成功故事里删掉。

只写“新人需要支持”还不够。问题由谁切成能验证的范围，已知方法由谁整理成可执行步骤，什么结果算合格，方法失效以后找谁，这些都得安排进实际工作。旁边坐着一个有经验的人，随时说一句“你再试试”，还接不住。

能够提前写清的部分，可以进入 Skill、样本和检查工具。还没有被验证的例外，不能因为文件名叫 Skill，就当成已经有了答案。新人负责操作、组织 Agent 完成任务，也不等于所有业务与生产后果都该由他一个人承担。

这份纪要没有完整展开评审、验收和事故升级机制，我不能替嘉宾补上一套已经成熟的制度。但它至少让我们看见：一个新人较快交付的结果，背后可能是一组被重新组织起来的专业能力。

接下来，还有一个没那么好听的问题。

这样的支持，能扩大吗？

假设新增任务都要同一位专家重新拆解，每份输出都要他从头核对，出一个例外又全部回来找他。表面上，执行端有更多人、更多 Agent；实际上，项目可能只是把过去分散的等待，集中到了一个人的审核队列里。这是假设的风险，不是说分享中的团队已经如此。

所以我更想看，下一位新人进来以后，哪些事情不必再由专家解释一遍；相近任务能否沿用经过验证的方法；新人能否先识别超出范围的情况，再带着证据来请教，而不是把整份结果丢回来等专家重做。

专家仍然要参与，不能把“减少专家时间”当成降低质量要求。但在相同任务范围和质量下，重复讲解、重复纠错能够减少，专家开始处理新问题，才说明支持能力也在生长。

这比数一数团队带了多少实习生，更接近这套模式能不能持续。

对培训同样如此。认真培养新人，可以教他使用现成能力，也应该让他学会解释结果、识别例外，并逐步承担判断。如果只是把专家做好的选择藏在后台，让学员跑通一次流程，再宣布学员已经拥有专家能力，证书发得越快，现场欠的课越多。

“不要把 AI 当 IT”，不等于技术可以消失

过去企业做信息化，常见的流程是：业务部门提需求，IT 部门采购或者开发，供应商实施，最后业务验收。系统做不好，业务说 IT 不懂业务；IT 说需求一直变；供应商说合同外的事情做不了。

大家都没有撒谎。

但是最后，系统也确实没人用。

用智能客服这个假设场景看，问题会更具体。一个业务部门说“我要智能客服”，这句话放到 IT 那里，可以立项、采购、接模型、做知识库、搭 Agent。三个月后 Demo 也可能很好看。直到准备上线，才发现工单系统长期缺少维护，权限散在不同部门，退款到底谁批准也没人愿意签字。

这时候再换模型，有什么用？

所以 AI 落地当然不能只委托给 CTO。因为问题首先不是“选哪个模型”，而是哪个业务动作应该改变，谁愿意改变，谁承担结果。

但是反过来，业务一号位亲自抓，也不等于技术问题自动消失。模型有没有评测，权限会不会串租户，Agent 调用工具时能不能回滚，数据冲突到底以哪张表为准，这些不会因为老板重视就自己长出来。

讨论里还有一种很自信的说法：自己已经开始学软件架构了。虽然一行代码也看不懂，但架构嘛，又不难，也不用看代码。

这句话听起来很轻松，背后的风险一点也不轻。

AI 确实把表达门槛打下来了。一个人不会写代码，也能生成架构图、接口清单和一整套“平台化演进路线”。但是图画出来，不等于架构成立。接口失败后谁重试？权限错了谁发现？数据不一致听谁的？模型给出一个看起来很合理的错误答案，谁敢让它继续往下执行？

这些才是架构。

有些 FDE 培训也在重复同一个错误：把表达门槛误认成判断门槛，把做出 Demo 误认成承担结果。

先问事情为什么值得做，再问 Agent 怎么搭

进入企业以后，我首先看一个人拿到需求后的第一个动作。

客户说要报表，他是立刻选图表组件，还是先问谁看、看完要决定什么、现在为什么作不了决定？两个部门给出不同口径，他是挑一份更完整的文档交给模型，还是先确认两边描述的究竟是不是同一个业务事件？

我说业务优先，指的是这个判断顺序。谁现在被什么事情卡住，原来的办法为什么还在用，做成以后谁会改变动作，做错了谁承担后果，先弄清这些，再决定怎样实现。这个起点是一件值得解决的事，不是哪一种工牌。

业务专家也要接受同样的检查。熟悉旧流程，不代表能判断它该不该保留；维护本部门的指标，也不等于理解整条业务链。资历和头衔不能替一个解释提供证据。

工程师不必进场第一天就成为行业专家。但他要知道自己缺什么：业务对象怎么定义，正常流程如何运转，例外怎样处理，哪条规则不能改，谁能确认结果。还要知道这些答案该向谁要，用哪份记录、哪次实际操作来核对。不能访谈一个人，就把他的说法直接写成全公司的规则。

可以暂时不懂这个行业，不能不知道该向业务求证什么。

我做数据顾问时，把一个业务词追到系统、表和字段，并不是为了证明自己也懂技术。是因为只停在业务语言里，大家很容易各自点头；真要取数、加工、比较，才会发现我们说的可能根本不是同一件事。第三篇会打开其中三段工作记录，不把所有陪跑经历都写成成功案例。

我熟悉的业务判断，要往工程里落，还得补实现、评测和运行，或者找到能接住这些工作的同事。工程师进来，也不能一直等别人把业务事实整理好。最后都得做出能核对的东西，知道哪些判断要请谁确认。

交接变短以后，原来的工作交给了谁

外部讨论里还有一句话，大意是：既然程序员可以直接到现场理解业务、当场把东西做出来，为什么还需要产品经理在中间传话？

如果中间那一层真的只是在转述，它当然值得被压缩。业务说一次，产品翻译一次，研发再猜一次，最后大家各自写下一份不一样的理解，这种成本没有必要被保护。

但产品经理这个岗位，与需求判断这项工作，不是一回事。

两名业务负责人提出相反要求，先做谁的？用户提出的功能，是否真的解决了原来的问题？新流程照顾了正常情况，异常由谁处理？为了赶上演示临时绕过的约束，上线前谁补回来？

这些工作可以由工程师、业务 Owner 和 FDE 共同承担，也可以继续由产品经理承担。岗位可以合并，职责却不会因为组织图少了一个方框就自动完成。

同样，一份说明可以让 AI 读得更完整，但不能因此让人失去复核能力。业务负责人要看得懂决策和验收，工程师要看得懂接口与约束，模型需要足够的上下文。这几种阅读需求可以由同一套事实生成不同视图，不应该长出几份互相矛盾的“真相”。

如果一份 PRD 只能让 AI 往下生成，接手的人却无法确认它为什么这样设计，那么它提高的可能只是生成速度，未必是交付速度。

这个能力，三十年前就有人在干

FDE 这个名字有它自己的公司历史，但是它需要的那些能力，并不是大模型出来以后才出现的。

三十年前，ERP 实施顾问、BPR 顾问和系统集成项目经理就在企业里梳理流程、改组织、做配置、推上线。

二十年前，数据仓库、BI 和行业解决方案顾问开始把经营问题翻译成指标、数据模型和 ETL。

十年前，SaaS 解决方案架构师、FAE、行业产品经理、客户成功越来越强调采用和持续运营。

名字一直在变，现场诊断、跨界翻译、工程落地、组织采用、结果验证没有消失。区别还得看这些工作怎样交接。

但不能为了突出 FDE，把以前的人都写矮一截：咨询只会 PPT，实施只会照单开发，SaaS 装上就不用管。下面比较的是几种常见责任安排，不是给整个行业判定能力上限。

FDE 没有发明这些能力。它强化的是交接方式和责任归属：问题还没有被说清时就要进入，工程做完以后仍有角色继续跟踪采用和结果，现场差异也不能随着项目结束全部丢掉。走向产品化时，还要接受能不能进入产品的检验。

从这个角度看，我以前做的一部分顾问陪跑，就是 FDE 式现场工作的前身或具体形态。变化在于今天有了更强的工程工具，也更有条件把过去分散在几个人手里的判断与实施接得更紧。不能反过来说，只有用上 Agent 以后，那些能力才开始存在。

这也让 FDE 长期夹在几组不会自动消失的冲突里：

客户希望为自己深度定制，产品公司希望尽量标准化；

销售希望尽快承诺价值，工程希望控制边界和失败风险；

当前项目希望先解决眼前问题，产品路线希望积累长期能力；

现场希望灵活调整，采购和法务希望需求、报价与验收保持稳定；

FDE 需要对结果负责，却未必拥有决定客户是否采用的权力。

FDE 可以是一个人，也可以是一支小队；新人当然可以在成熟团队里承担其中一段。关键是必须有一个清楚的责任主体，不能在问题、工程、采用和产品回流之间提前下车，不能每到下一环就把上下文和责任重新甩给另一支队伍。

看职位名称，不如看工作怎么接下去

现在还有另一类“真假 FDE 鉴别法”：代码不进主仓库就是外包，归交付部门就不是真 FDE，有销售提成就是售前，没有产品复用就不配叫 FDE。

听起来很痛快，实际不够用。

客户的安全和知识产权要求，可能决定代码只能留在客户环境。项目属于交付部门，也不代表它不能修改产品。有奖金或销售关联指标，需要警惕激励是否挤压真实交付，但不能凭这一项给岗位验明正身。

更重要的是，现场价值与供应商商业价值不能混成一个词。客户希望少做无效工作，供应商可能希望增加产品采用和使用量。两者可以一致，也可能发生冲突。岗位说明写“对结果负责”，先问清楚是哪一方的什么结果。

如果要看一个岗位，我会把那些标签题换成四个工作问题：

原需求被证据推翻后，谁可以调整范围？有没有实际处理过这样的事？

从原型走到生产，由谁评审、谁运行、谁在人员离开后维护？

验收是否区分功能、采用和业务结果？还是无论发生什么都叫“上线成功”？

现场发现交给谁，沉淀到哪里，下一个场景有没有真的用过？没有复用时，是否承认还在探索？

问完，再对照公司准备给你的资源，看这份工作接不接得住。

人到了现场，公司的判断跟着过去了吗

一个优秀工程师，如果始终只能根据报告猜客户，工程能力也可能被用来把错误需求做得更完整。所以到现场很重要。但人去了客户那里，公司准备允许他带回来什么？

一张新的需求单？还是一份足以推翻原产品假设的证据？

Palantir 自己的架构文档把 Forward Deployed Engineering 写成一种产品开发方式，并用“人的反向传播”来比喻它。它同时介绍了数据与工作流、AI 应用与评测、持续部署等平台能力。前线有人，后方也有东西接住。

在 Palantir 开发者社区的一则亲历者回复里，作者自述做了十四年 FDE。他强调的甚至不是 Engineer 这个岗位名，而是 Engineering 这项活动：现场、核心产品研发和内部运营共同参与，把客户那里反复碰到的问题带回平台。这是从业者对自家实践的说明，不是第三方效果审计，但它把一个经常被省略的前提讲明白了。

我想看的是，现场人员把坏消息带回来以后，公司怎么处理。

比如，客户现场发现原来的业务对象定义错了。如果总部只允许调参数，不允许讨论对象模型，那么现场工程师再懂业务，也只能继续补丁。客户用了以后发现一个关键动作没人敢批准，如果公司只问本月又增加了多少调用量，那条反馈链在进入产品之前就断了。这两个例子是我对机制的推演，不是对 Palantir 项目的描述。

所以，驻场的价值不能按出差天数计算。住三个月，每天照着总部想象的需求写代码，也可能只是把远程猜测搬到了客户办公室。反过来，有机会看真实操作、核对业务记录、复盘失败，并让这些证据改变设计，才是在积累现场知识。

这也是我做顾问时越来越在意的事情：最后多了一份材料，不等于原来的判断被修正了。能不能把材料里的矛盾带回业务和工程，让下一步换一种做法，工作才接上了。

至于“模型会成为谁都有的东西”，我更愿意把它当成趋势判断。即便大家都能调用同一款模型，也不等于大家都知道这家企业的哪份记录可信、哪条例外有效、谁允许系统采取行动。通用能力的可获得性，与一家企业的可执行知识，是两回事。

为什么偏偏到了 AI 时代，FDE 又热了

如果这些能力一直存在，为什么偏偏是现在，FDE 重新变热？

我现在的判断是：原有的不确定性没有消失，新的不确定性又叠了上来。

相对而言，传统软件的一段规则在版本和输入等条件固定时，行为通常更容易明确描述和测试。引入大模型以后，除了业务与组织的不确定性，还要处理生成输出的波动，以及模型、Prompt、工具和工作流共同变化带来的影响。

模型可以读文档、写代码、调用工具、给出判断，但在具体业务里“什么叫答对”，仍然需要确认；确认过一次，也不意味着换了模型和流程以后还能直接沿用。

同一句“识别高风险客户”，换一家企业，业务对象、损失定义、证据要求、人工复核和责任边界可能全部不同。同一个客服 Agent，在一家企业可以自动退款，到了另一家只能给人建议。差异不是配置几个参数，而是谁允许它做什么，什么错误绝不能发生，出了错怎么停，谁来接管。

因此，进入客户现场以后，需要重新定义的至少包括：

哪个业务对象才是模型真正作用的对象；

哪些数据可以作为事实，哪些只是辅助线索；

什么输出可以接受，什么错误绝不能发生；

哪些动作可以自动执行，哪些必须人工确认；

出错以后如何停止、回滚、追责和恢复；

业务价值如何回标，由谁确认它真的发生了。

大模型提供通用能力，企业价值却要在客户自己的数据、权限、流程、例外和责任体系里实现。对复杂企业 Agent 来说，一部分产品定义必须通过真实使用逐步完成，产品开发因此延伸到客户现场。

但不要顺手把它写成“模型已经不重要，以后只比部署”。模型能力决定有些任务能不能做，部署能力决定它在具体企业里能不能可靠地做。模型升级还会改变原有的成本、错误方式和可自动化范围，两边会反复影响。

变化也不只有风险。以前只能抽查的材料，有机会扩大检查范围；以前值得做但排不上开发期的辅助功能，有机会用更低成本验证；原来需要人工逐项整理的输入，有机会直接进入后续流程。这里说的是值得测试的机会，不是默认新增能力一定变成收入。

Aaron Levie 看好 FDE 的一个理由，是供应商可以从多家客户的部署中学习，把新方法带给其他客户，再反馈给核心产品。我理解其中的价值，是让相似问题不必由每家公司独自摸索一次。前提当然是经验确实适用、使用获得授权，而不是客户数据可以随便互通。

把这件事叫“最后一公里”很形象。不过真进现场，有时才发现最前面的路就画错了。不是缺一个接口，而是业务对象不对；不是缺一个 Agent，而是没有人能说清这个动作由谁决定。FDE 既要补产品与客户之间的缝，也要判断这条缝值不值得补。

AI 同时压缩了过去顾问、产品、架构、研发、测试、交付之间的交接链。一个成熟人员或一支小队，可以更快完成调研整理、数据分析、原型、代码、测试和验收材料。上午发现口径冲突，下午就能做出对照查询和下一轮证据清单。

AI 可以降低生成、整理和验证准备的成本，也可以帮助我们比较方案、寻找反例，更快形成判断。我原来把它概括成“没有降低判断成本”，说得太满了。

多做几次测试的门槛低了，值得用它把问题查得更扎实；不能因为答案来得快，就把查证也一起省掉。生产越快，未经确认的错误也越容易被放大；交接越少，责任越密集地压回同一主体。

把 Agent 当成人，可以帮助我们摆脱表单式产品想象，把它看作一个能值班、能读材料、能调用工具的“同事”。但不能假定它具备与人相同的常识判断，更不能把人的责任和组织身份一并转交给它。它却可以高速、批量执行：一次权限配错，人可能只误操作少量记录；Agent 可能在人工发现前已经完成整批处理。

所以 FDE 多出来的，不是一层“会用大模型”的装饰，而是一层生产治理：权限、评测、监控、审计、异常处理、人工接管和责任追踪。

我前面说“把 Agent 当成人，是产品认知；理解 Agent 不是人，才是落地能力”，落到项目里，指的就是这些检查和接管工作。

Surge AI 让模型在模拟的电脑配件零售企业中处理客服任务，讨论的不是“能不能聊天”，而是能不能正确用工具、持续完成目标、应对意外结果、守住事实，以及理解业务语境。

这类测试对 FDE 最有用的地方，不是截一张旧榜单证明 AI 永远不行，而是提醒我们：一个任务的失败，可以发生在很多不同位置。接口返回成功，业务动作也可能做错；最后一段话很流畅，前面的查询也可能漏掉条件。

模型能力会变化，现场的验收不能停在那张榜单上。第三篇会用项目说明哪些条件才允许继续；具体失败分类与生产检查放在系列补充材料中。

FDE 也不是工程师的“永久避风港”

还有一种与高薪宣传正好相反的说法：模型会越来越强，懂 AI 的工程师靠 FDE 也只是多撑一阵。

我不想用“这个岗位永远不会消失”来安慰谁。

如果一个人的优势只是熟悉某个平台、记得几个 API、能比客户更快搓出一个演示，工具继续进步以后，这种优势确实可能缩短。把工作名称从开发改成 FDE，并不会自动改变它依赖的能力。

判断一个人能不能转型，也别拿离职经历代替能力检查。被裁撤不能证明综合能力差，大厂履历同样不能证明他已经能独立承担客户项目。

更值得检查的是，一个人以前完成工作时，哪些能力来自自己，哪些由所在组织提供。需求有人收敛，环境有人维护，架构有人评审，客户关系也有人承接；离开这套协作条件，以个人或小团队接项目，原来由别人承担的工作并不会自动消失。

这是工作范围和支撑条件的变化，不能简单解释成某类人不行。

如果进场以后只不断增加 Agent，却没人确认问题、采用和维护，即便工程师从未被裁撤，项目也一样接不住。需要检验的是这支团队能否补齐责任，而不是它的成员曾经在哪里上班、怎样离开。

但反过来，也不能从“代码更容易生成”直接推到“企业项目更容易承担”。需求判断、工程审查、异常处理、组织采用，都可能被 AI 辅助，也都需要根据具体任务重新检验。哪一部分可以自动化，哪一部分必须由人确认，不会永远停在今天的边界。

对个人更有用的问题，是自己已经在哪类真实工作上留下了别人能检查的证据。能不能接住需求冲突，说明数据来路，完成一个可维护的交付；遇到不熟悉的行业，能不能找到正确的人确认，而不是假装已经懂了。

这些能力也不是永久护城河。它们至少让转型不只押注在一个名字上。

还有一种值得认真对待的可能：旧场景被产品吸收以后，企业又愿意尝试原来做不了的新场景。某大佬在 8 月的一则帖子里，就把持续变化与更复杂的业务需求视为 FDE 仍有空间的原因。这是他的趋势判断，不是岗位数量的保证。

我更愿意据此理解个人的成长方向：不要把自己绑在重复部署一个旧方案上，逐渐学会接更难的问题，并把已经走通的部分留下来，让别人也能做。某项旧工作不再需要你，可能恰好说明那一段做成了。

回到招生这件事，课程到底帮学员完成了哪一步，就说哪一步。高薪岗位、未来机会，都不能拿来替结课后的能力交差。

下一篇，我会继续往水下走。（三篇都写完了，接近 4 万多字）

作者简介

松子（李博源），一枚做了二十多年数据的老兵。做过数据中台建设和企业顾问，现任 AI 产品 VP，正在一线实践 FDE 式项目。

发布于：北京

相关推荐

会搭几个Agent，就敢给企业做AI转型了？FDE车祸现场
让企业客户愿意掏钱的 AI 到底长什么样？
中美AI Agent争霸战：谁将主导下一代智能服务？
我不给人做产品，给Agent做
谁在钉钉上做AI Agent？
百度搭子，开始“搭班子”
李开复的AI公司怎么样了？
歌手“车祸现场”，全是耳返的锅？
AI让企业降本增效？我们发现了一个不一样的答案
押注 Agent，钉钉想做 AI 创业平台

网址: 会搭几个Agent，就敢给企业做AI转型了？FDE车祸现场 https://www.xishuta.cn/newsview153778.html