当前位置：首页>排行榜>第16章 |甲方如何选择和管理FDE

第16章 |甲方如何选择和管理FDE

更新时间 2026-11-15 06:35:32

第16章 |甲方如何选择和管理FDE

这是正在修订中的《企业AI转型六阶段——从部门试点到AI原生：甲方视角的组织、治理与落地方法》一书的第16章内容。全书大概37万字，预计11月中旬开源。

你决定请FDE了。

但市场上叫FDE的团队很多，报价从5万到500万都有，方案从“三天出demo”到“六个月交付”。你怎么判断谁靠谱？

更麻烦的是，你听到过太多“被乙方坑”的故事：合同签了，人来了，做了三个月，系统上线了，然后没人用了。钱花了，问题还在。

这一章要回答的，就是怎么在鱼龙混杂的市场里，找到真正能帮你解决问题的FDE，并且管好这段合作。

这一章包含四节：16.1讲FDE的四种类型，帮你识别你面对的是哪一种；16.2讲怎么评估FDE是否靠谱，给你五个观察点和六个面试问题；16.3讲合作模式选择；16.4讲合同关键条款，帮你把风险控制在签约之前。

读完这一章，你应该能回答：我怎么找到靠谱的FDE？怎么选合作模式？怎么签合同才不被坑？

本章案例说明：本章中老陈、周总等具名案例为复合建构案例，由多个项目的真实情节提炼，不指向任何特定企业。未标注来源的“某企业”“某FDE”案例，同样为复合建构的情景演示。唯一有公开来源的是16.4节的900万美元项目案例，它来自FDE三部曲的《FDE决策现场》，这里从甲方视角重新复盘。

16.1 FDE的四种类型

某制造企业的CIO老陈，最近在选FDE团队。

他手上有三份方案。

第一份，来自一家知名AI公司，报价300万，方案很漂亮：用大模型重构整个供应链系统，六个月交付，包含需求预测、库存优化、智能排产、供应商管理四大模块。方案里有一句话让他心动：“我们用的是最先进的Agent架构，可以自主决策。”

第二份，来自一家本地软件公司，报价60万，方案很务实：先做库存预测一个场景，两个月上线，做完再谈下一步。方案里有一句话让他犹豫：“我们用的是开源模型，性能可能不是最优，但够用。”

第三份，来自一个独立FDE，报价15万，方案只有三页纸：先花一周做诊断，再花三周做一个原型，验证了再决定要不要继续。方案里有一句话让他不安：“我不保证能做成，但我保证不浪费你的钱。”

老陈拿不定主意。三份方案，三种逻辑，三种风险。他不知道该选哪一个。

这个场景，几乎是每个企业负责人在AI转型中都会遇到的。你面对的不是“选哪个技术方案”的问题，而是“选哪种合作方式”的问题。而选哪种合作方式，取决于你面对的是哪种FDE。

（本章中老陈及其企业的经历为复合建构案例，由多个项目的真实情节提炼，不指向任何特定企业。）

四种类型，四种逻辑

FDE这个岗位，从Palantir的Delta，到今天的各类AI交付团队，已经演化出四种主要类型。这四种类型不是按“水平高低”分的，而是按“服务逻辑”分的。每一种都有它的适用场景，也有它的风险点。

类型一：产品驱动型FDE

特征：这类FDE背后有一套成熟的标准化AI产品或平台。他们的工作方式，不是从零开始写底层代码，而是用他们产品里的标准化模块，快速拼装出满足企业业务需求的解决方案。Palantir的Delta是典型代表，他们基于Foundry和AIP平台，在企业现场做配置和微调，而不是从零开发。

适用场景：企业的业务需求与该产品的标准功能匹配度较高，不需要大量定制开发。比如用现成的检索增强生成模块（RAG，让AI先查资料再回答）搭建知识库，用现成的智能体模块（Agent，能自主调用工具完成多步任务）做流程自动化。

优势：上线速度快，因为有成熟产品支撑；功能成熟度高，因为基础模块在别的项目里已经验证过；项目上线后，该产品的标准功能还可以持续升级（不用企业自己维护底层代码）。

风险：如果企业的业务需求与其标准产品不匹配，FDE可能会“削足适履”，把企业特有的业务逻辑硬塞进他们的标准框架里，导致用起来很别扭。更麻烦的是，企业可能被这套产品“锁定”，后续的迭代、扩展、甚至数据迁移，都高度依赖这家FDE。

甲方怎么识别？问一个问题：“这个方案里，有多少是你们产品的标准功能，有多少是为我们做的定制开发？”如果答案是“大部分是标准功能”，这是产品驱动型。如果答案是“大部分是定制”，那你要警惕，这意味着虽然打着“产品”的旗号，但实际上还是纯定制开发，不仅周期长、成本高，后续产品升级你也享受不到。

类型二：垂类场景型FDE

特征：这类FDE深耕某个行业或某个特定场景，比如金融风控、医疗病历、制造业质检、物流调度。他们不一定有自己的底层大模型或平台，但拥有大量的同行业落地经验和可复用的行业模板。

适用场景：本企业的痛点属于该FDE深耕的领域，且行业内有大量共性可以复用。比如银行想做智能投研，找一家已经为多家银行做过投研系统的FDE，踩坑的成本会低很多。

优势：懂行业的“水有多深”，知道这个行业的业务规则和合规红线在哪；有现成的行业模板，不需要从零开始摸索；能预判组织阻力，知道在这个行业里，推AI最容易卡在哪个部门、哪个环节。

风险：如果本企业的业务模式超出了该FDE的经验舒适区，他可能会“用旧地图找新大陆”，把不适用的行业逻辑硬套过来。另外，这类FDE的行业经验往往集中在几家“行业标杆企业”身上，如果本企业的业务模式与那些标杆企业差异较大（比如标杆是标准化产品，而我们是极度定制化服务），他们的经验可能直接水土不服。

甲方怎么识别？问一个问题：“你们做过几个同行业的项目？能不能讲一个在这个行业里踩过大坑的失败案例？”如果他能讲出具体的行业潜规则和避坑经验，说明是真有沉淀。如果他只会讲“我们做过很多头部企业”，但讲不出具体的业务细节和踩坑教训，那大概率是用通用大模型套壳的，要高度警惕。

类型三：纯项目定制型FDE

特征：这类FDE既没有自己的标准产品，也没有深耕的行业沉淀。他们的工作方式就是“接单干活”，企业提什么需求，他们就派几个人，从零开始写代码。项目做完，系统交付，团队撤场。

适用场景：企业的业务场景极度独特，市场上确实没有现成方案，且这套系统是一次性投入，后续不需要频繁迭代。比如某个极为小众的工业检测流程，或某个高度机密的内部特制流程。

优势：极其灵活，完全按企业的业务需求定做。更重要的是，这种模式下企业不存在“被软件产品强行绑定”的问题，业务逻辑完全是为自己量身打造的。

风险（往往极为隐蔽）：开发成本极高且周期长，因为每次都是从零写起。极其依赖开发人员的个人水平。如果FDE团队经验不足，交付的系统可能看起来功能都有，但底层逻辑一塌糊涂。

最大的坑在于“烂尾”与“伪自由”。项目做完了，FDE撤了，企业往往发现，因为完全没有代码规范和沉淀，留下的可能是一堆“只有原作者才能看懂的代码”。你虽然有代码的所有权，但你找不到别的团队来接手维护，所谓的“自由选择后续维护方”，其实是一句空话。

甲方怎么识别？不要听他们承诺“我们全包”，而要死磕一个问题：“这个项目结束后，如果你们撤场，我们自己的IT团队或第三方，能不能顺滑地接手？”如果对方支支吾吾，说“必须由我们做长期维护”，那你要做好被长期“绑架”和“敲竹杠”的准备。如果对方说“可以接手”，一定要追问：“代码规范和架构设计文档有多详细？能不能把‘交接清单’写进合同？”

类型四：混编纵队型FDE

特征：这类FDE不是一两个人，而是一支成建制的团队。前方有懂业务的专家和懂技术的专家，后方有平台架构师做支撑。他们通常服务大型集团企业，项目周期长，涉及多个部门、多个系统、多个场景。

适用场景：大型集团企业的系统性AI转型。比如国家能源集团与科大讯飞的合作，从智能评审起步，逐步扩展到全流程无人化。这不是单点项目，而是持续数年的系统性工程。

优势：能解决单个团队解决不了的系统性问题；通过多角色组合，企业能得到从顶层规划到落地执行的全链条覆盖，不容易出现“战略定了没人做、系统做了没人用”的断层。

真正的价值（也是最大的坑）：必须分清是谁的“资产”。如果甲方只出钱、出人配合，后方专家确实会把项目经验沉淀下来，但沉淀的是乙方FDE自己的通用平台和行业组件。这就等于甲方花钱帮乙方“练兵”，项目结束，甲方依然是个空壳。

因此，混编纵队的真正价值，在于“借假修真”：利用这支部队，把甲方的内部FDE、业务骨干“编”进去。后方专家的职责不仅是攻克技术难关，更要把业务语义模型、数据接入模板、踩坑经验“翻译”并转移给甲方的混编人员。最后，通用能力归乙方（但甲方享有使用权），定制代码和长在甲方人身上的能力，必须归甲方。

风险：成本最高，周期最长，对甲方内部的配合度要求也最高。如果甲方内部能力跟不上，混编纵队就会变成“一支极其昂贵的驻场外包团队”。更要警惕的是“伪纵队”，号称有强大的后方专家，实际上后方只有几个通用技术支持，根本没有能力把项目经验体系化地转移给甲方。

甲方怎么识别？不要只看他们派了多少人，要死磕两个问题。

第一问：“你们后方专家，到底参与这个项目的哪些关键节点？是远程看看报告，还是直接到现场解决核心架构问题？”如果对方说“后方主要做技术支持”，大概率是伪纵队。

第二问：“在这个项目里，你们打算怎么培养我们的内部团队？知识转移的验收标准是什么？如果我们的内部FDE学不会，你们能撤场吗？”如果对方只谈“交付系统”、不谈“带走队伍”，那说明这只是一支装点门面的雇佣军，而不是帮你建军的教导团。

四种类型的对比

把四种类型放在一起看，差异就更清楚了，如表16-1所示。

表16-1 四种类型的对比

维度	类型一：产品驱动型	类型二：垂类场景型	类型三：纯项目定制型	类型四：混编纵队型
核心特征（他手里有什么）	标准产品模块（有成熟底座，靠配置拼装）	行业经验与模板（懂行业潜规则，有现成方案）	纯开发人力（无底座，接单从零写代码）	成建制的专家团队（懂业务、懂技术、有后方平台）
适用场景（我什么时候选他）	我们的需求与他的标准功能高度匹配	我们的痛点属于他深耕的领域，且模式类似	场景极度特殊，市场上买不到现成方案	大型集团的多场景、长周期系统性转型
核心优势（我能得到什么）	上线快、模块成熟、后续能跟着产品升级	少踩行业坑、懂合规红线、成功率高	完全按我的需求定制，不受产品限制	全链条覆盖、战略与执行不脱节
甲方风险（最大的坑是什么）	被产品锁定：强行把特有业务塞进标准框；伪产品：打着产品旗号做纯定制	旧地图找新大陆：把别家的经验硬套到我的特有模式上，导致水土不服	烂尾与代码绑架：留下一堆没人接得了手的“祖传代码”，后续被迫高价求他维护	变成练兵场：通用经验被他带走，我的企业依然是个没长出能力的空壳
选型必杀技（问他一句话）	“这方案里，多少是标准功能，多少是为我做的定制？”	“讲一个你在同行业里踩过大坑的失败案例？”	“你们撤场后，我的IT团队能顺滑接手吗？代码规范有多细？”	“你们后方专家怎么带我们的人？学不会能退场吗？”

选型的第一原则：匹配，而非“最好”

看到这张表，你可能想问：哪种最好？

答案是：没有“最好”，只有“最匹配”。

一个15万的物流公司运单分配项目，找混编纵队，是杀鸡用牛刀。一个300万的央企全流程AI转型项目，找独立FDE，是蚂蚁搬大象。

选型的第一原则，不是“选最强的”，而是“选最匹配的”。匹配你的预算、你的场景、你的组织能力、你的转型阶段。

一个补充说明：有读者可能会问，老陈的第三份方案（独立FDE、15万、诊断先行）显然是被正面呈现的，但类型三“纯项目定制型”被列为风险最高的一类，两者矛盾吗？

不矛盾。第三份方案的靠谱，不在于它属于哪种类型，而在于它内置了两个关键机制：止损线和诊断先行。这两个机制，恰恰是类型三“纯项目定制型”风险的对症解药。独立FDE不等于高风险，关键在于他是否自带止损线和交接设计。

老陈的第三份方案，赢在机制，不在规模。

看懂了这张表，你就会明白：没有完美的FDE，只有你能不能压住他的命门。选型不是去挑一个没有缺点的神仙团队，而是去挑一个他的缺点你能接受、并且你有手段能防住的团队。

一个判断“真伪FDE”的快速方法

市场上叫FDE的团队很多，但其中相当一部分是“传统外包换了个名字”。怎么快速判断？

不要只看他们怎么说，要看他们敢不敢承担“结果”。问三个致命问题。

第一个问题：“如果系统上线了，但业务部门的指标没达标（比如效率没提升，或者用户不用），尾款怎么结？”

伪FDE的回答：“系统交付了、功能测试通过了，尾款当然要结。业务部门不用，那是你们的推行问题，跟我们技术无关。”他们按“功能清单”算账。

真FDE的回答：“合同里写明了止损线，如果验证后发现场景不成立，或者业务指标没达标，这部分尾款我们不收。”他们按“业务结果”算账，且敢于前置承担风险。

第二个问题：“如果业务部门抵制，说系统不好用，谁来负责解决？”

伪FDE的回答：“我们负责修Bug、调接口。但如果是业务习惯改不过来，或者流程没理顺，那得你们自己去推。”他们只做“技术交付”，交付完就走人。

真FDE的回答：“我去业务现场看，找他们到底卡在哪。如果是流程不匹配，我帮你重改流程；如果是KPI没配套，我去帮你们找业务主管对齐。”他们做的是“业务落地”，不把交付当成终点。

第三个问题：“你们提交的代码，包含哪些交付物？如果我们自己团队接手，需要多久？”

伪FDE的回答：“我们提交源码。但里面很多底层逻辑是我们公司封装的，你们接手可能比较困难，后续维护建议还是由我们来做。”他们给你的是“黑盒”，把你长期绑定。

真FDE的回答：“我们提交源码，并附带架构图、数据字典、踩坑记录和部署脚本。项目结束时，我们会帮你们内部FDE完成知识转移，确保你们能独立接管系统。”他们交付的是“能力”，让你随时可以“踢掉他”。

三个问题问完，真假FDE就分清了。真FDE的核心特征是：敢按结果结账、敢碰业务流程、敢交出底层资产；而伪FDE只能在功能清单里打转。

本节小结

FDE有四种类型：产品驱动型、垂类场景型、纯项目定制型、混编纵队型。每种类型有它的适用场景，也有它的风险点。选型的第一原则是匹配，不是“最好”。

识别真伪FDE的快速方法：问“指标没达标尾款怎么结”、问“业务抵制谁来解决”、问“知识转移能不能独立接管”。

16.2 如何评估FDE是否靠谱

回到开头那个场景。

老陈最终选了第一份方案，那家知名AI公司，300万，六个月交付，四大模块。理由很充分：品牌大、方案完整、技术先进。他觉得“选大公司总不会错”。

六个月后，系统上线了。功能都做了，演示也很漂亮。但上线三个月后，老陈发现：需求预测模块的准确率只有60%，库存优化模块的建议和实际业务对不上，智能排产模块用了一个月就被计划员弃用了，因为“它排出来的计划，连车间主任都看不懂”。

老陈找那家公司，对方的回答是：“功能都按合同做了，是你们的业务流程没有配套调整。”

老陈这才意识到，他犯了一个错误：他用“选软件”的逻辑，选了一个“做交付”的团队。选软件，看功能清单、看品牌、看报价。选FDE，要看的是完全不同的东西。

五个观察点

怎么判断一个FDE团队靠不靠谱？不是看他的PPT做得多漂亮，不是看他公司的品牌多大，而是看五个细节。

观察点一：进场先要什么？

靠谱的FDE，进场先要两样东西：数据和现场。他会说：“我需要看看你们的数据，我需要坐在业务人员的工位旁边，看他们怎么工作。”

不靠谱的FDE，进场先要两样东西：会议室和PPT模板。他会说：“我们先开个需求调研会，你们把需求整理成文档发给我们。”

这个区别背后，是两种完全不同的工作逻辑。靠谱的FDE知道，真正的需求不在会议室里，而在业务人员的工位旁边。不靠谱的FDE习惯坐在会议室里“听需求”，然后回去“写方案”。

观察点二：方案里有没有“不做什么”？

靠谱的FDE，方案里一定有一部分叫“不做什么”。他会明确告诉你：“第一期我们只做A和B，不做C和D。C和D放在第二期，或者根本不做。”

不靠谱的FDE，方案里什么都有。你说要A，他答应；你说要B，他也答应；你说要C，他还是答应。他恨不得把你能想到的所有功能都写进去，因为“功能越多，报价越高”。

这个区别背后，是两种完全不同的自信。靠谱的FDE知道“什么能做、什么不能做、什么该做、什么不该做”。不靠谱的FDE只关心“怎么把合同签下来”。

观察点三：有没有止损线？

靠谱的FDE，会主动跟你约定止损线。他会说：“我们先用两周做诊断，如果诊断后发现这件事做不了，我们收诊断费就走人，不浪费你的钱。”

不靠谱的FDE，只谈成功不谈失败。他会说：“你放心，我们做过很多类似项目，一定能做成。”

这个区别背后，是两种完全不同的责任感。靠谱的FDE知道“有些项目就是做不成”，他愿意承担“做不成”的风险，也愿意提前告诉你“什么情况下应该停下来”。不靠谱的FDE把“签合同”当作终点，签完合同，风险就转移给你了。

观察点四：讲业务结果，还是讲技术概念？

靠谱的FDE，汇报时满口业务结果：“系统上线后，客服响应时间从5分钟降到了2分钟”“派单效率提升了60%”“错误率下降了40%”。

不靠谱的FDE，汇报时满口技术概念：“我们用了最先进的大模型”“我们采用的是Agent架构”“我们的方案具有高度的可扩展性”。

这个区别背后，是两种完全不同的交付逻辑。靠谱的FDE知道，企业要的不是“用了什么技术”，而是“解决了什么问题”。不靠谱的FDE知道企业方听不懂技术，所以用“先进”“智能”“生态”这些词来制造“专业感”。

观察点五：有没有深入业务现场找“关键用户”？

这是五个观察点里最容易被忽略、也最重要的一个。

靠谱的FDE，进场两周内一定会深入业务现场，找到那个真正懂业务、在内部有信用、愿意说真话的“关键用户”。他可能是某个部门的主管，可能是某个老师傅，可能是某个一线员工。而且，FDE会主动和这个人建立关系，请他参与方案设计，甚至请他一起定规则。

不靠谱的FDE，进场两周了还在跟你一个人对接。他没有深入组织内部，没有和业务人员建立关系。你问他“业务部门怎么看”，他说“还没聊”。你问他“谁对这个项目最有意见”，他说“目前没发现”。

这个区别背后，是两种完全不同的工作方式。靠谱的FDE知道，项目成功的关键不是“老板支持”，而是“业务人员愿意用”。不靠谱的FDE把“老板支持”当作全部，忽略了组织内部的真实阻力。

六个面试问题

五个观察点，是“看”。但有些信息，光看是看不出来的，需要问。

以下六个问题，可以在选型阶段直接问FDE团队。这六个问题的答案，比任何PPT都更能说明问题。

问题一：“讲一个你做砸过的项目。”

这个问题会让很多人不舒服，但不舒服，正是它的价值。

靠谱的FDE会认真回答，讲一个具体的项目，讲清楚“为什么砸了”“学到了什么”“后来怎么避免”。

不靠谱的FDE会回避，说“我们没做过砸的项目”，或者含糊其辞。

一个从没做砸过项目的FDE，要么是刚入行，要么是在撒谎。FDE的工作本质是探索，探索就有失败。不敢承认失败的人，也不值得信任。

问题二：“那个项目后来谁接的手？接管的人现在能独立运行吗？”

这个问题是问题一的追问。

靠谱的FDE会说：“我们帮客户培训了内部团队，后来他们自己维护”“我们交接给了一家本地服务商，做了完整的知识转移”“那个项目后来停了，我们和客户一起复盘了原因”。而且，他能说出接管的人现在运行得怎么样。

不靠谱的FDE会说：“那个项目跟我们没关系了”“客户自己没能力维护”“后来就不了了之了”。

这个问题的答案，反映了FDE对“交接”和“退出”的态度。一个对“退出”没有思考的FDE，不会真正对你的长期能力负责。

问题三：“你怎么知道用户真的在用？”

这个问题，是区分“技术型FDE”和“结果型FDE”的分水岭。

靠谱的FDE会说：“我们看系统日志，看日活，看关键流程的使用率”“我们去现场看，看用户是不是真的在用，还是只是应付”“我们让用户自己说，不是我们替他说”。

不靠谱的FDE会说：“系统上线了，用户反馈不错”“我们做了培训，用户都学会了”“客户领导说效果不错”。

这个问题的答案，反映了FDE对“交付”的定义。技术型FDE认为“系统上线就是交付”，结果型FDE认为“用户在用才是交付”。

问题四：“说一个你劝企业别花钱的经历。”

这个问题，是区分“乙方”和“伙伴”的分水岭。

靠谱的FDE会说：“有一次企业想做A，我们看了之后发现A根本没必要做，或者用更便宜的方式就能解决”“有一次企业想扩大范围，我们劝他先做小范围验证”。

不靠谱的FDE会说：“企业想做什么我们就做什么”“我们从来不让企业失望”。

这个问题的答案，反映了FDE的立场。乙方立场是“你要什么我给什么”，伙伴立场是“什么对你好我做什么”。当然，伙伴立场不意味着“不赚钱”，而是“不赚不该赚的钱”。

问题五：“止损线你跟企业怎么谈的？”

这个问题，是区分“有经验”和“没经验”的分水岭。

靠谱的FDE会说：“我们在项目启动前就跟企业约定，如果两周内诊断发现做不了，我们收诊断费就走”“我们跟企业说好了，如果匹配率低于50%，我们就换方向，不是硬做”。

不靠谱的FDE会说：“我们一般不谈止损线，因为我们对项目有信心”“企业没问，我们也没提”。

这个问题的答案，反映了FDE对“风险”的态度。有经验的FDE知道“有些项目就是做不成”，他愿意提前设定止损线，也愿意在止损时体面退出。没经验的FDE把“止损”当作“认输”，不敢提，也不愿提。

问题六：“你离开之后，那个系统现在怎么样？”

这个问题，是区分“短期交付”和“长期负责”的分水岭。

靠谱的FDE会说：“我们离开后三个月回访过，系统还在用，用户提了一些新需求”“我们离开后做了交接培训，客户的IT团队现在能自己维护”“有一个系统后来荒废了，我们复盘了原因”。

不靠谱的FDE会说：“我们做完就撤了，后面的事不归我们管”“客户自己没维护好，跟我们没关系”。

这个问题的答案，反映了FDE对“责任”的定义。短期交付的FDE认为“交付就是终点”，长期负责的FDE认为“系统活着才是终点”。

两个一票否决的红线

六个问题问完，如果出现以下两种情况，建议直接淘汰，不要进入打分环节。

红线一：把“业务结果”完全推给企业。

如果FDE说“系统我交付了，用不用起来是你们的事”，或者“业务指标没达标，是因为你们业务部门不配合，跟我们技术无关”，这种人不能要。真FDE会对业务结果负责，至少会和你一起诊断问题出在哪，而不是签完合同就把风险全甩给你。

红线二：拒绝交出底层资产，或知识转移没有验收标准。

如果FDE说“底层架构是我们的核心机密，不能给你们”，或者“知识转移嘛，项目结束时我们会培训的”，但说不出具体的培训内容、验收标准和交接清单，这种人也不能要。真FDE敢让你“踢掉他”，因为他知道自己的价值不在于“绑定你”，而在于“让你长出能力”。

把观察点和面试问题变成一个工具

五个观察点+六个面试问题+两条红线，可以做成一个“FDE评估打分表”，如表16-2所示。

表16-2 FDE评估打分表

评估维度	评估项	评分（1-5分）	备注
进场准备	先要数据和现场，还是先要会议室和PPT
方案边界	方案里有没有“不做什么”
止损意识	有没有主动约定止损线
汇报风格	讲业务结果还是讲技术概念
组织嵌入	有没有深入业务现场找“关键用户”
失败经历	能不能讲出一个做砸过的项目
交接态度	那个项目后来谁接的手？能独立运行吗
采用验证	怎么知道用户真的在用
客户立场	有没有劝企业别花钱的经历
止损经验	止损线跟企业怎么谈的
长期责任	离开之后系统现在怎么样

红线一票否决：把业务结果推给企业、拒绝交出底层资产或知识转移无验收标准，出现任一，直接淘汰，不进入打分。

评分标准：每项1—5分，总分55分。45分以上为“靠谱”，35—45分为“需谨慎”，35分以下为“高风险”。分数线是经验参考，不同阶段的企业可适当调整（阶段2—3的试点项目，分数线可略低；阶段4—5的系统性转型，分数线应更严）。

这个打分表不是万能的，但它能帮你过滤掉大部分“不靠谱”的FDE。

本节小结

评估FDE是否靠谱，不看PPT，看五个观察点：进场先要什么、方案里有没有“不做什么”、有没有止损线、讲业务结果还是讲技术概念、有没有深入业务现场找“关键用户”。

六个面试问题，帮你问出真相：讲一个做砸过的项目、那个项目后来谁接的手、你怎么知道用户真的在用、说一个你劝企业别花钱的经历、止损线你跟企业怎么谈的、你离开之后那个系统现在怎么样。

两个一票否决的红线：把业务结果推给企业、拒绝交出底层资产或知识转移无验收标准。

下一节，我们讲合作模式选择，帮你找到最适合你的合作方式。

16.3 合作模式选择

16.2讲的是老陈选完FDE之后发生的事：他选了第一份方案，300万，六个月交付，结果上线三个月后需求预测模块准确率只有60%，系统勉强在用。

但老陈犯的错，其实在签约前就埋下了：他选了团队，却没有先谈清楚合作模式。

我们不妨把时间拨回签约前。假设老陈在签合同之前，先把FDE团队负责人约来，问了一个问题：“这个项目，我们怎么合作？”

FDE团队负责人说：“您想怎么合作？按项目一口价，还是按订阅制算，还是按效果付费？”

老陈愣住了。他不知道这几种模式有什么区别，也不知道哪种对他更有利。

FDE团队负责人又说：“我们建议先签一个小项目，比如诊断+POC，四周时间，费用控制在20万以内。验证了再谈下一步。”

老陈问：“那如果POC失败了怎么办？”

FDE团队负责人说：“POC失败，我们收诊断费，其他费用不收。这是我们和企业的约定。”

老陈还是犹豫。他担心的是：如果一开始签小了，后面越做越大，总价会不会失控？如果一开始签大了，万一做不成，损失会不会太大？

这个犹豫，几乎是每个甲方在签FDE合同时都会遇到的。合作模式不是“怎么付钱”的问题，而是“风险怎么分”的问题。

一个说明：传统IT外包常见的“按人天计价”，本质上是在“买人头”，不是在“买结果”。人天模式下，FDE干一天活收一天钱，项目做没做成，跟他没关系，反正工时记上了。FDE项目不建议用人天计价，如果对方坚持按人天报价，要警惕他其实是个传统外包团队（见16.1“真伪FDE”三个问题里的收费模式）。本节只讨论三种真正适合FDE的合作模式。

三种合作模式：风险分配决定选择

FDE项目的合作模式，本质上只有三种，它们的区别不在于“收多少钱”，而在于“风险由谁承担”。

模式一：项目制，风险在甲方

定义：甲乙双方约定一个项目范围，FDE报一个总价，无论实际投入多少，甲方支付固定金额。

适用场景：范围明确的中小型项目，你知道“做完了”长什么样，FDE有足够经验来判断工作量。

优势：简单直接，甲方和FDE都清楚金额范围。预算可控，FDE不会中途加价。

风险：范围定义的主动权旁落。项目制下，一切以合同为准，合同没写清的，FDE理直气壮不做；甲方事后想加，需要走变更、加费用、延周期。最被动的情形是签约时根本没有意识到，FDE按最小范围报价，你真正要的东西被切在合同外，到验收时才“发现”。

甲方的保护措施：

• 在合同里写清楚“做完了”的定义（详见16.4节交付物定义）：明确核心需求的边界，防止乙方按最小范围报价，后续无限加钱。

• 约定公平的变更流程与费率：任何超出范围的新需求，必须走变更流程。关键在于，要在签约时提前锁定“变更费率”或“单价”，并写明“变更必须经甲方书面审批”。这一机制是双向约束：对内，防止业务部门随意插手、需求无限蔓延，导致项目预算失控；对外，防止乙方在实施中借“变更”之名虚报高价、拖延工期。

• 设定“止损线”：如果项目进行到某个节点发现做不成，双方可以协商终止，不让沉没成本无限扩大。

一个常见的教训。某企业签了一个50万的AI项目，验收时才发现：自己认为“当然包含”的三个功能，都不在合同里。报价时FDE按最小范围报，企业没有逐项核对。要补回来，只能走变更流程：追加30万、延期三个月。这个错误的根源是对“做完了”没定义清楚，而且定义的责任在甲方：乙方按最小范围报价是商业理性，逐项核对需求清单是甲方的功课。签约前把“做完了”写清楚，主动权从来在甲方手里。

甲方怎么避免？签项目制合同之前，问FDE一个问题：“这个项目里，哪些是不做的？”如果FDE说不清楚“不做什么”，说明范围边界还没想清楚，不能签项目制。

模式二：订阅制，风险在双方

定义：甲方按月或按季度支付固定费用，FDE提供持续服务（迭代、优化、培训、支持）。

适用场景：系统上线后，还需要持续迭代、优化和陪跑；甲方预算相对充足，愿意为“长期有专家可用”付费。

优势：企业能得到长期稳定的支持，FDE持续了解业务，不用每次重新“摸底”；遇到新问题、新需求，随时有人接应，响应速度快。

风险：钱照付，产出说不清。订阅制下，甲方的风险不是“FDE不干活”，而是“干了什么说不清”。没有约定交付物清单，每个月按时付10万，半年后回答不出“这笔钱换来了什么”。等到觉得“不值”时，合同往往还剩大半年，想停停不了，退出成本全在甲方一边。

甲方的保护措施：

• 签约时约定“月度交付物清单”：每月固定交付什么，不是“来了几天”，而是“交付了什么”（优化了几项功能、解决了几个问题、沉淀了什么模板），写进合同附件。

• 设定“季度评估+退出窗口”：每季度对照清单评估一次，连续不达标可终止，把“想停”的权利留在自己手里，避免骑虎难下。

• 付款与交付挂钩：按月支付，但当月交付物清单未完成时，甲方有权顺延或扣减。

一个常见的教训。某企业与FDE团队签了订阅制合同，每月支付10万，签约时只写了“提供持续优化与技术支持服务”，没有约定每月具体交付什么。前三个月，FDE团队每周来两天，优化了不少功能，甲方觉得“挺值”。第四个月起，FDE团队来的次数减到每周一天，甲方心里犯嘀咕，但合同里没写“来几天”，说不清对方违约。第六个月盘点，甲方发现半年花了60万，能叫出名字的成果只有前三个月那几项，后三个月的钱“花得不清不楚”，而合同还有半年才到期。

CIO复盘：“问题不在FDE变懒了，而在我们签约时就没把‘每月交付什么’写清楚。主动权从来在甲方手里，你不定义‘什么算值’，‘值不值’就只剩感觉。”

甲方怎么避免？签订阅制合同之前，问FDE一个问题：“每个月你能给我什么？”如果答案只是“随时支持”“有问题就解决”，这不是订阅制，而是“保险”。订阅制的价值应该是持续的迭代和优化，不是“有事才来”。

一个补充建议：很多独立FDE采用的是“项目制+月度维护费”的组合模式，主体项目一次性打包收费，后续按月收取维护费。这种模式既覆盖了项目本身的投入，又为长期合作建立了机制。甲方可以根据自己的需要，选择纯项目制、纯订阅制，或者组合模式。

模式三：按结果付费，风险在FDE

定义：FDE的收入与甲方的业务结果直接挂钩。甲方不是为“你做了多少活”付费，而是为“你帮我赚了多少钱、省了多少钱”付费。

适用场景：价值可量化（降本、增收）；甲方信任度足够高，愿意让FDE参与业务结果的验证；FDE的风险承受能力强。

优势：利益完全对齐，FDE和甲方的目标一致。甲方风险低，没有结果，不用付钱。

• 标准模糊：如果“成功标准”定义不清（比如“提升品牌形象”），结果无法量化，最后容易扯皮。

• 归因争议：如果结果受多个因素影响（市场大盘、政策变化、其他部门的配合），怎么区分FDE的贡献？没有归因机制，验收时就变成“你说没达标，他说达标了”。

• 供应商选择面窄：愿意接受“按结果付费”的FDE团队，市场上并不多。如果只有一两家愿意接，甲方议价空间有限。

甲方的保护措施：

• 把“成功标准”定义清楚，比如什么算“省了多少钱”、什么算“多赚了多少钱”。

• 约定“归因机制”：如果结果受多个因素影响，怎么区分FDE的贡献。

• 设定“保底费用”：如果FDE确实做了大量工作，但结果不达预期，甲方支付保底费用，覆盖FDE的基本成本。

一个常见的教训。某企业为了推进“品牌形象升级”的AI项目（比如智能舆情监控与内容生成），与FDE团队签了“按结果付费”合同。约定“如果品牌形象提升了，企业把节省下来的一部分广告预算，作为项目奖金分给FDE。”

结果，系统上线运行了半年，双方却陷入了死局。FDE催结尾款，但企业财务和业务部门不认账。为什么？因为“品牌形象提升了多少”根本无法被量化验证，既没有上线前的基线调研数据，也没有约定明确的测量指标，更没有第三方机构出具的证明。

企业方很无奈：“感觉口碑是好了点，但市场大盘也在变，怎么证明是AI起的作用？到底提升了百分之几？因为算不清这笔账，这钱没法批。”

FDE方很委屈：“系统确实在发挥作用，你们拿不出数据，不能怪我不干活，这就是在找借口拖欠尾款。”

最终的结果是双输的。FDE拿不到钱，停止服务；企业的系统成了没人维护的“孤儿”，更糟糕的是，企业在这个圈子里留下了“结款难”的名声，后续再有实力的FDE团队，一听这个付款条件就直接退避三舍。

甲方怎么避免？在签“按结果付费”合同之前，先问自己，这个结果能被量化并归因吗？如果答案是“很难量化”，那就不要用按结果付费，改用“项目制+效果奖金”的组合模式。基础费用覆盖成本，达到明确的里程碑再给奖金，这是对双方都负责的做法。

三种模式的对比

把三种模式放在一起看，风险分配的区别就清楚了。如表16-3所示。

表16-3 三种合作模式的对比

维度	项目制	订阅制	按结果付费
风险承担方	甲方	双方	FDE
适用场景	范围明确的中小型项目	需要长期陪伴的企业	价值可量化的场景
甲方优势	预算可控	长期支持，不用反复招标	风险低
甲方风险	范围蔓延	价值稀释（付了钱说不清买到了什么）	标准模糊、归因争议、可选供应商少
甲方保护措施	写清“不做什么”+变更流程	约定月度交付物+退出窗口	定义成功标准+归因机制+保底费用
建议	中小项目首选	长期合作时考虑	价值可量化时使用

混合模式：更现实的选项

现实中，很少有项目是纯粹的某一种模式，更常见的是混合模式。

混合模式一：项目制+月度维护费。

主体项目一次性打包收费，后续按月收取维护费。适合系统上线后需要持续运维的场景。对大多数甲方来说，这是最稳妥的选择。项目制覆盖初始交付，维护费覆盖持续服务，风险和收益比较平衡。

混合模式二：基础费+效果分成。

基础费用覆盖FDE的成本，效果分成与业务指标挂钩。适合价值可量化但FDE不想承担全部风险的场景。

混合模式三：诊断费+POC费+实施费。

分阶段收费，每个阶段有独立的交付物和验收标准。适合不确定能不能做成的场景。

核心原则：先小后大，用结果换信任

不管是哪种模式，有一条原则是所有甲方都应该遵守的：先小后大，用结果换信任。

不要一上来就签一个300万的大合同。先花1—2周做诊断，再花4—6周做一个POC。POC成功了，再谈扩大。

具体分三步走。

第一步：低成本诊断（1—2周）

- 费用：5—20万（视项目复杂度）。

- 交付物：诊断报告（现状是什么、问题在哪里、能不能做、怎么做）。

- 如果诊断发现做不了，FDE收诊断费走人，双方不浪费更多时间。

第二步：小范围POC（4—6周）

- 费用：20—50万（视场景复杂度）。

- 交付物：一个可运行的POC，验证“这件事能不能做”。

- 如果POC失败，双方复盘原因，决定是调整方向还是终止。

第三步：扩大实施（根据POC结果决定）

- 费用：根据项目范围评估。

- 交付物：完整的生产系统。

- 如果POC成功，双方对彼此都有了信心，扩大实施的谈判会顺利得多。

为什么“先小后大”对企业更有利？

- 降低决策门槛：不需要一次性批几百万预算，先花小钱验证。

- 风险可控：如果FDE不靠谱，在诊断或POC阶段就能发现。

- 用结果说话：POC跑出来的结果，比任何PPT都有说服力。

为什么“先小后大”对FDE也更有利？

- 降低销售难度：企业不需要一次性批大预算。

- 积累信任：POC成功了，后续合作顺理成章。

- 避免“签了大合同做不出来”的尴尬：小步验证，逐步推进。

一个常见的企业选择过程

回到签约前。如果老陈先谈了合作模式，他本可以这么选。

在听完三种合作模式的解释后，老陈决定采用“先小后大”的方案。

第一步：签一个2周的诊断合同，费用8万。FDE进场看数据、看流程，出一份诊断报告。

第二步：如果诊断报告说“能做”，签一个4周的POC合同，费用30万。FDE做一个库存预测的原型，在老陈的一个仓库试运行。

第三步：如果POC效果好，再谈全面实施。

老陈算了一笔账：如果诊断后发现做不了，他只损失8万，比之前签300万合同的风险小得多。如果诊断后发现能做，他花38万就能看到一个可运行的原型，这比看PPT靠谱得多。

老陈的选择，就是“先小后大”的典型应用。16.2里那个300万的合同，恰恰是跳过了这一步：没有诊断，没有POC，直接签了大合同。六个月后系统上线，需求预测准确率只有60%，老陈才发现“这个团队能不能解决我的问题”根本没验证过。

本节小结

三种合作模式，风险分配不同：项目制风险在甲方，订阅制风险在双方，按结果付费风险在FDE。现实中更常见的是混合模式。对大多数甲方来说，项目制+月度维护费是最稳妥的选择。

不管选哪种模式，核心原则是：先小后大，用结果换信任。先花小钱做诊断，再花中钱做POC，验证了再扩大。

老陈在16.2里的失败，不是选错了团队，而是跳过了“先小后大”：他直接签了300万，把“这个团队能不能解决我的问题”这个最该先验证的问题，押到了六个月后。如果他在签约前先谈合作模式，本可以用8万诊断费、30万POC费，提前买到答案。

下一节，我们讲合同关键条款，帮你把风险控制在签约之前。

16.4 合同关键条款

某制造企业与一家FDE团队签了一个80万的“智能排产系统”项目。合同里写的是“交付一套智能排产系统，包含数据接入、模型开发、系统部署、用户培训”。

项目做了三个月，系统上线了。FDE团队说“做完了”，企业说“没做完”。

企业说：“你们说要做智能排产，但现在系统只做了排产建议，没有做自动排产。我们要的是自动排产。”

FDE团队说：“合同里写的是交付一套‘智能排产系统’。我们交付的排产计划生成模块，就是这套系统。您说的‘自动排产’（直接把指令下发给产线），属于‘自动调度系统’，那是另一个产品，不在本合同范围内。”

企业说：“排产建议还要计划员一条条去确认才能下发，这叫什么智能排产？”

FDE团队说：“合同里没有写‘无需人工确认’，而且需求文档里也没有规定必须自动下发。”

双方各执一词，尾款被拖了六个月。最终企业付了70%，理由是“功能不完整”。

这个项目的失败，不是技术问题，而是合同问题。合同里只写了“交付一套智能排产系统”，却没有定义清楚“智能排产”到底包含什么、不包含什么、做到什么程度算“做完了”。企业以为买的是“自动排产”，FDE交付的是“排产建议”，这两个词在行业里都叫“排产系统”，最后只能按合同里的“字面意思”来扯皮。

（本案例为复合建构情景演示，不指向任何特定企业。）

这一节要回答的，就是怎么在合同里写清楚关键条款，把风险控制在签约之前。

条款一：交付物定义，什么是“做完了”？

传统软件合同的交付物通常是“源代码+文档”，代码写完、文档交齐，就算交付了。FDE合同的交付物完全不同。FDE交付的不是“代码”，而是“一个在企业生产环境中持续运行、产生可衡量业务结果的系统”。

交付物定义应该包含三个层面。

第一层：可运行的系统。

- 部署在企业指定环境中的可运行系统。

- 系统访问权限和账号。

- 系统管理员手册和用户操作手册。

第二层：可验证的业务结果。

- 系统上线后，企业预期在什么时间节点看到哪些业务指标的改善。

- 例如：“系统上线后4周内，排产错误率降低20%以上”。

- 这是一个可验证的业务结果，不是模糊的“效果不错”。

第三层：项目文档与操作手册。

- 系统管理员手册（日常运维操作、异常处理流程、系统配置说明）。

- 用户操作手册（面向最终用户的操作指南）。

- 数据接入文档（数据来源、字段含义、更新机制）。

合同的写法对比：

模糊写法：“交付一套智能排产系统。”这一写法存在的问题：什么是“智能排产”？包含什么功能？做到什么程度算做完？完全不清楚。

清晰写法：

（1）交付物一：可运行的系统。在企业指定环境中完成系统部署，系统包含以下核心功能：①基于历史订单和产能数据的排产建议；②排产结果的可视化展示；③人工调整排产建议的界面。

（2）交付物二：可验证的业务结果。系统上线后4周内，排产时间从每天4小时降至2小时以下，排产错误率降低20%以上。

（3）交付物三：项目文档与操作手册。系统管理员手册、用户操作手册、数据接入文档。

判断标准：在签合同之前，问自己一个问题：如果验收时双方各执一词，你能不能指着合同里的一句话一锤定音？如果能指着“系统上线后4周内排产错误率降低20%以上”，调出业务系统的记录说“这个指标达成了”或“这个指标没达成”，那么交付物定义是清晰的。

条款二：三层验收，怎么算“验收通过”？

交付物定义清楚了，下一个问题是：谁来验收？按什么标准验收？

传统软件合同的验收标准通常是“功能清单逐项核对”，功能做完了，就算验收通过了。FDE合同的验收标准必须是“业务结果是否达成”，验收通过包括三层验。

第一层：技术验收，系统能跑吗？

- 验收主体：企业的IT部门或技术负责人。

- 通过标准：所有技术指标达到合同约定值（响应时间、并发能力、可用性等）。

- 风险提示：技术验收通过，只说明“系统是好的”，不说明“业务结果是好的”。

第二层：业务验收，结果发生了吗？

- 验收主体：企业的业务负责人或运营团队。

- 通过标准：约定的业务指标达到或超过合同约定的目标值。

- 风险提示：业务验收需要基线数据，没有基线，就无法证明“改善是AI带来的”。

第三层：用户验收，客户认不认？

- 验收主体：最终使用系统的业务团队。

- 通过标准：用户真正在使用系统，并认为系统解决了他们的问题。

- 风险提示：用户验收是最容易被忽略的一层，但也是最关键的一层。系统上线了，但用户不用，等于没交付。

验收条款的写法：

模糊写法：“系统稳定运行、功能正常，验收通过。”这一写法存在的问题：什么是“稳定”？什么是“功能正常”？谁来定义？用户不用算不算通过？

清晰写法：

（1）技术验收：系统部署完成、所有核心功能正常运行、API响应时间在约定范围内，由企业IT部门负责人签字确认。

（2）业务验收：系统上线后4周内，排产时间从每天4小时降至2小时以下、排产错误率降低20%以上，由企业业务部门负责人签字确认。

（3）用户验收：目标用户中至少80%在系统上线后4周内持续使用系统，由企业业务部门负责人确认。

三层验收全部通过，才算验收完成。但这里有一个极易踩坑的“时间差”：技术验收可以立刻做，但业务和用户验收需要看数据、看行为。

为了避免“技术验收的时效条款”误伤“业务验收的观察期”，验收条款必须分步设定时间。

第一步：技术验收的时效。系统部署完成、核心功能正常运行后，乙方可提交技术验收申请。企业应在收到申请后10个工作日内完成技术验收。逾期未验收且未提出书面异议的，视为技术验收通过。（这一条的“视为通过”，是为了防止甲方IT部门因为内部流程拖延而导致系统无法结项。）

第二步：业务与用户验收的触发点。技术验收通过后，系统进入“业务观察期”（如4周）。乙方必须在观察期满后，提交包含真实业务数据的业务验收和用户验收申请。在此观察期内，乙方不得以“技术已验收”为由要求企业支付尾款。

第三步：业务与用户验收的时效。对于乙方提交的业务/用户验收申请，企业应在收到完整数据和报告后的10个工作日内完成确认。如果乙方提交的数据不足以证明目标达成，企业有权驳回并要求重新提供，“逾期视为通过”的条款不适用于乙方数据提交不全或观察期未满的情形。

核心原则一句话总结：技术验收可以“秒批”，但业务验收必须“熬够时间”。合同里不能用一个通用的“10个工作日”把这两件事混为一谈。

关于验收周期的约定：如果合同只写“验收通过后付款”，没有写“多久之内必须完成验收”，验收可能无限期拖延。表面上这条款约束的是甲方，实际上对甲方有利：验收标准写得清楚，按期组织验收只是走流程；真正要警惕的是没有验收时间表，项目尾巴拖上一年、系统无人维护，烂尾的是企业自己的项目。反过来，如果企业确实需要更长时间验收，应该在签约时争取更长的验收周期（比如15—20个工作日），而不是签了10天、到期又找理由拖延。

条款三：知识产权归属，代码归谁？

这是FDE合同中容易被忽视但极其重要的条款。很多企业在签合同时只关注“多少钱、什么时候付”，却忽略了知识产权的归属问题。等项目做完才发现，代码的归属权模糊不清，导致后续无法复用、无法迭代、甚至无法维权。

三种模式，企业要看清风险。

模式一：代码归企业所有。

这是传统外包合同的常见模式，企业支付了开发费用，获得了代码的完整所有权。

这种方式对企业最有利，但FDE通常不接受。企业需要在“完整所有权”和“价格”之间做权衡，如果坚持代码全部归企业，FDE无法将代码复用到其他企业，边际成本无法下降，报价会相应提高。

模式二：代码归FDE所有，企业获得使用权。

- FDE保留了代码的所有权，企业获得在约定范围内使用代码的权利。

- FDE可以在脱敏后复用代码逻辑。

- 对企业的风险：如果FDE不做了，代码怎么办？企业可能无法独立维护和迭代系统。企业的保护措施：约定源代码托管，FDE将源代码交由第三方托管，如果FDE出现破产、停止运营等约定情形，企业有权获得源代码的使用权。

模式三：通用能力归FDE，定制代码归企业。

- 这是FDE项目最推荐的模式。FDE在项目中沉淀的通用能力（数据接入模板、业务语义模型、数据质量检查框架）归FDE所有，可在不同企业之间复用。针对企业特定业务场景开发的定制代码（数据映射、业务规则、特定功能）归企业所有。

- 平衡了双方的利益，FDE可以积累平台能力，企业获得了定制部分的完整所有权。

企业在谈判中要争取以下三件事。

FDE通常会对平台代码设防，这是合理的商业立场。企业要争取的不是全部源代码，而是下面这三件事。

第一，定制代码的完整所有权。针对企业特定业务场景开发的定制代码，必须归企业所有。这是底线，不能让步。

第二，通用能力的持续使用权。即使通用能力归FDE所有，企业也应获得“在本企业内持续使用”的权利，不能因为FDE停止合作就导致系统无法运行。

第三，源代码托管条款作为兜底。如果FDE出现破产、停止运营等约定情形，企业有权获得源代码的使用权。这不是“要FDE的命根子”，而是“万一FDE不在了，企业还能活下去”。

关于“交付全部源代码”的问题：有些企业要求“交付全部源代码”，不仅是定制代码，还包括FDE的核心平台代码。这是一个敏感问题。如果FDE的业务模式依赖于“平台+定制”而非“纯定制”，交付全部源代码意味着把核心资产也交给了企业，FDE通常不会接受，或者会大幅提高报价。企业的策略：核心平台代码的交付，应该是一个单独的商务谈判条款，而不是标准合同条款。企业可以根据自己的议价能力和项目规模，决定是否争取这一条。

合同条款的推荐写法：

• 通用能力归属。乙方在项目实施过程中开发和沉淀的以下能力，属于乙方的通用能力，知识产权归乙方所有，比如数据接入层的基础框架和抽象接口；评估框架和测试工具；基础模型调用逻辑和部署脚本；其他不依赖企业特定业务逻辑的通用组件。乙方有权将这些通用能力用于其他企业的项目中。但乙方应授予甲方在本企业内持续使用这些通用能力的永久许可，不因合作终止而失效。

• 定制代码归属。企业特定业务场景下的定制代码，知识产权归企业所有，比如针对企业ERP系统的字段映射表；企业的特定业务规则配置；企业的特定数据模型和报表模板；其他依赖企业特定业务逻辑的定制组件。企业获得这些定制代码的完整所有权和使用权。

• 源代码托管。乙方应将本项目相关的源代码（含通用能力和定制代码）交由双方认可的第三方托管。如乙方出现破产、停止运营、被收购等约定情形，企业有权获得源代码的使用权，以保障系统的持续运行。

• 边界定义：若双方对某项代码属于“通用能力”还是“定制代码”存在争议，以本合同约定的三条规则为判断依据：①以抽象层级区分，而非使用场景；②以可独立使用性区分，作为规则一的补充；③乙方有权提供该项代码的抽象层级说明和在多个企业中的使用记录作为举证材料。

一个正在发生的变化：代码在贬值，“全量移交”正在成为可选项。

随着AI编程能力的增强，FDE生成和修改代码的成本正在快速下降。对很多FDE团队来说，代码本身不再是需要死死攥住的“复用资产”，他们更愿意通过“全量移交代码”来换取更顺畅的签约、更高的服务定价，或者更长周期的运营与优化合约。

这意味着，企业在谈判中争取“项目产生的全部代码归企业所有”的可行性，比两三年前高得多。如果FDE仍然以“代码是我们的核心资产”为由拒绝移交，企业可以追问一句：“在AI辅助开发的环境下，你们保留代码的真实目的，是为了复用，还是为了锁定我们？”

但“移交代码”不等于“拥有系统”。合同里必须把“完整移交”定义清楚，否则拿到的只是一堆无法独立运行的文本。建议约定，全量移交至少包含：代码仓库的完整访问权限与管理权转移；数据库结构（schema）与数据字典；部署脚本与环境配置说明；所有第三方服务与API的密钥（交接后由企业方轮换）；架构文档与关键决策记录（ADR）。

一句话：代码可以“送”，但必须“送得干净”。如果FDE只给代码不给运行环境，所谓“全量移交”就只是一次成本更高的锁定。

条款四：退出机制，什么情况下可以终止？

这是企业与FDE的合同中，最容易被忽略、但企业最该主动要求写进去的条款。

FDE项目本质上是“高风险、高回报”的生意，因为项目可能因为各种原因失败，比如企业的需求可能变了、数据接不进来、技术方案不适用、组织内部的政治冲突导致项目停滞。如果没有退出机制，企业会被一个“注定失败”的项目捆绑，已投进去的钱追不回来，搭进去的时间和团队士气更是收不回的沉没成本。

退出机制的三种触发场景。

场景一：企业原因，内部决策变了。企业决策层变动、业务优先级调整、预算被削减、战略方向改变。合同中应约定：项目因企业原因终止，企业需支付乙方已完成工作的全部费用，并承担相应的违约责任。

场景二：FDE方原因，技术方案走不通。经过诊断和验证阶段，FDE发现原定的技术方案在企业的数据环境下不可行。合同中应约定：项目因乙方原因终止，乙方需退还已收取的部分费用，并承担相应的违约责任。

场景三：双方协商一致，都认为该停了。双方都意识到项目走不通，但合同里没有退出条款，谁都不愿意先提“终止”。合同中应约定：按实际完成阶段结算，企业支付对应阶段费用。

退出机制的三个要素。

要素一：中止条件。什么情况下可以启动退出？例如：企业单方提出终止、乙方单方提出终止（如企业严重违约、不配合项目推进超过约定时间）、双方协商一致终止、不可抗力导致的终止。

要素二：费用结算。退出了，钱怎么算？建议采用“阶梯式结算方案”。项目因企业原因终止，企业支付乙方已完成工作的全部费用；项目因乙方原因终止，乙方退还已收取的部分费用；项目因双方协商一致或不可抗力终止，按实际完成阶段结算。

要素三：过渡期。终止后怎么交接？FDE需要提供什么材料（代码、文档、数据）、在多长时间内完成交接、交接期间是否需要提供支持。

合同条款的推荐写法。

中止条件：①企业单方提出终止；②乙方单方提出终止（如企业严重违约、不配合项目推进超过4周）；③双方协商一致终止；④不可抗力导致的终止。

费用结算：①项目因企业原因终止：企业需支付乙方已完成工作的全部费用，并按合同约定承担相应违约责任；②项目因乙方原因终止：乙方需退还已收取的部分费用，并按合同约定承担相应违约责任；③项目因双方协商一致或不可抗力终止：按实际完成阶段结算，企业支付对应阶段费用。

过渡期：合同终止后，乙方应在14个工作日内完成工作交接，包括代码、文档、数据的移交，并提供必要的交接支持。

企业怎么看待FDE主动提出退出机制？有些企业看到FDE主动提出退出条款，会本能地警惕：“你们是不是对自己没信心？还没开始就想怎么跑？”

这个理解是错的。FDE主动提出退出机制，通常说明他愿意承担风险、认真对待项目。但企业也要看清条款细节，比如止损条件、费用结算、过渡期安排，每一条都要写清楚，不能只凭“态度好”就放松要求。反过来，企业也可以利用这个条款：如果FDE做得不好，企业也有权按约定终止，不用被合同绑死。

条款五、六、七：不可忽视的三个补充条款

除了上述四个核心条款，企业还需要在合同中补齐三个补充条款，否则依然会踩坑。

补充条款一：数据安全与保密条款。

FDE进场后要接触企业的核心数据、业务逻辑和客户信息，合同里必须约定：FDE不得将数据用于本项目以外的目的；FDE团队成员个人需签署保密协议；数据访问权限必须遵循最小必要原则；如果发生数据泄露，明确责任划分与赔偿机制（具体权限设计见17.2节）。

补充条款二：变更管理与费率条款。

16.3节讲了变更流程是双向约束。在合同层面，必须写清楚：什么算“变更”（超出合同约定的范围、功能、性能指标）；变更必须经企业书面签字确认，严禁口头承诺；最关键的是，必须在签约时锁定“变更费率”或“单价”。这既能防止企业内部业务部门随意加需求导致预算失控，又能防止乙方在实施中借变更之名虚报高价。

补充条款三：开源组件与第三方许可。

FDE的交付物中大概率使用了开源模型、开源框架或第三方API。合同必须要求FDE提供“开源组件清单”，并明确约定：开源许可类型是否允许商用、是否具有传染性（如GPL协议）；如果因开源许可变更或第三方API停服导致企业无法使用，FDE应承担怎样的替换或赔偿责任。

四个核心条款与三个补充条款的检查清单

在签合同之前，用表16-4这份清单逐项确认。

表16-4 合同条款检查表

条款类型	检查项	状态
交付物定义	“做完了”有明确定义吗？有可验证的完成标准吗？	☐
交付物定义	交付物是“结果”还是“功能”？是结果导向吗？	☐
交付物定义	可复用资产有定义吗？（如数据接入模板等）	☐
三层验收	技术、业务、用户三层验收标准明确且可量化吗？	☐
三层验收	三层验收各有明确责任人，且约定了验收周期吗？	☐
知识产权	“通用”和“定制”的边界清晰吗？有争议时谁举证？	☐
知识产权	源代码交付范围与托管条款明确吗？	☐
退出机制	退出触发条件、费用结算、过渡期安排明确吗？	☐
数据安全	保密协议、最小权限、泄露赔偿机制明确吗？	☐
变更费率	变更的书面审批流程与锁定的费率单价明确吗？	☐
开源许可	开源组件清单及传染性免责条款明确吗？	☐

判断标准：如果以上条款中有任何一项是“模糊”或“缺失”，不要签合同。先补上，再签字。

本节小结

合同是FDE项目的“安全网”。四个核心条款，交付物定义、三层验收、知识产权归属、退出机制，写清楚了，项目出了问题也有据可依；三个补充条款，数据安全保密、变更费率、开源许可，补齐了，数据安全、预算失控、技术合规的风险才能管住。

交付物定义要明确到“不可争议”。验收标准要设计为“三层验收”。知识产权归属要提前约定，“通用能力归FDE，定制代码归企业”是最平衡的模式。退出机制要写在前面，不要等到项目出问题了再想“怎么退出”。

下一章，我们讲甲方如何与FDE协作并逐步自建，帮你从“请人做”过渡到“自己会做”。

16.5 案例：某企业从“被FDE坑”到“与FDE长期合作”

周总是某中型制造企业的CIO，负责集团的数字化和智能化项目。

三年前，周总第一次接触这种驻场式AI交付模式。当时一家AI公司找到他，说可以用AI优化质检流程，报价120万，六个月交付。方案很漂亮：AI视觉检测、自动分类、质量追溯、数据看板，四大模块。

周总当时对FDE不太了解，只知道“AI是趋势，早做早受益”。他没有做太多评估，就签了合同。

六个月后，系统上线了。质检部门的反馈却很冷淡：“系统识别得挺快，但误报太多，我们还得再人工复核一遍，反而更麻烦了。”

周总找那家公司，对方的回答是：“AI的准确率需要时间优化，后续我们可以提供持续优化服务。”

周总问：“持续优化怎么收费？”

对方说：“按月收费，每月8万。”

周总算了算：120万已经花了，每月还要8万，一年又是96万。他不知道这个钱花到什么时候是个头，也不知道系统到底能不能达到预期的效果。

最终，系统用了不到三个月就被质检部门弃用了。120万打了水漂。

（本案例为复合建构，由多个项目的真实情节提炼，不指向任何特定企业。）

复盘：第一次合作为什么失败

周总后来复盘了这次失败，发现三个问题。

问题一：没有做诊断，直接签了大合同。

那家AI公司一上来就给了方案，周总没有要求做诊断。他不知道“这件事能不能做”“做到什么程度”“需要什么条件”，就直接签了120万的合同。结果是，FDE团队进场后发现，质检流程比预想的复杂得多，原有的模型架构根本不够用，只能边做边改，效率极低。

问题二：合同里的“交付物”写得太模糊。

合同里写的是“交付一套智能质检系统”，但没有定义“智能质检”具体包含什么功能、达到什么准确率、误报率控制在什么范围。系统上线后，FDE团队说“功能都做了”，质检部门说“效果不行”，双方各执一词，验收被拖了三个月。

问题三：没有退出机制。

合同里没有约定“如果系统效果不达预期怎么办”。项目做到一半，周总已经发现方向可能有问题，但合同里没有退出条款，他只能硬着头皮做下去。结果就是钱花了，系统废了，关系也僵了。

这三个问题，恰恰对应了16.3节和16.4节讲的那几个核心原则：没有做诊断就签大合同（对应16.3节“先小后大”）、合同里的交付物写得太模糊（对应16.4节“交付物定义”）、没有退出机制（对应16.4节“退出机制”）。周总后来复盘时说：“如果早看到这三条，我至少能省下80万。”

第二次尝试：从“先小后大”开始

第二年，周总决定再试一次。这次他选了一个场景：供应链的库存预测。

他吸取了上次的教训，做了三件事。

第一件事：先做诊断，不签大合同。

他找了三家FDE团队，给了同一个要求：“先花两周做诊断，费用5万，诊断报告出来后再谈下一步。”

三家团队的反应各不相同。

第一家说：“两周太短，我们至少要一个月才能出诊断报告。”

第二家说：“诊断可以，但费用要15万，因为我们派的都是资深工程师。”

第三家说：“两周可以，5万可以，诊断报告写清楚现状、问题、能不能做、怎么做。”

周总选了第三家。

第二件事：诊断报告出来后，他没有直接签实施合同，而是先签了一个POC合同。

诊断报告说“库存预测这件事可以做，但需要先解决数据质量问题，预计POC需要四周”。周总签了一个28万的POC合同，要求FDE团队在四周内做出一个可运行的原型，在一个仓库试运行。

四周后，POC跑通了。库存预测的准确率达到了78%，仓库主管说“比我凭经验猜准多了”。

第三件事：POC成功后，他才签了全面实施合同。

POC验证了技术可行性和团队能力，周总对FDE团队有了信心，签了全面实施合同。这次合同写了四个关键条款：交付物定义、三层验收、知识产权归属、退出机制。

从“被坑”到“长期合作”

全面实施项目做了四个月，系统上线了。库存周转率提升了15%，缺货率下降了20%。

项目结束后，周总没有和FDE团队“分手”。他做了一个决定：和FDE团队签一个年度框架协议。

框架协议的内容是：

• FDE团队每月提供两天的现场支持，费用固定

• 如果新的场景需要开发，另外签项目合同

• 每季度做一次“价值评估”，如果连续两个季度没有可感知的产出，周总有权终止

这个框架协议，让周总和FDE团队从“一个项目一锤子买卖”变成了“长期合作伙伴”。FDE团队知道“这个客户会持续有项目”，愿意投入更多精力理解业务；周总知道“这个团队了解我们的业务”，不用每次重新“摸底”。

周总的三条经验

周总后来总结了自己的经验，分享给了同行。

经验一：不要一上来就签大合同。先做诊断，再做POC，验证了再扩大。

诊断花5万，POC花28万，加起来33万。如果诊断后发现做不了，只损失5万；如果POC失败，只损失33万。这比一上来就签120万的风险小得多。

经验二：合同里的四个条款，一个都不能少。

交付物定义、三层验收、知识产权归属、退出机制。这四个条款写清楚了，项目出了问题也有据可依。写不清楚，项目就会陷入扯皮。

经验三：不要只看FDE团队的PPT，要看他“做砸过的项目”。

周总面试FDE团队时，问了一个问题：“讲一个你做砸过的项目。”那个团队的负责人讲了一个具体的项目，讲清楚了“为什么砸了”“学到了什么”“后来怎么避免”。周总说：“这个问题帮我过滤掉了两家只会讲成功的团队。”

这个案例的普遍性

周总的故事不是个例。

在FDE三部曲的《FDE决策现场》中，有一个900万美元的项目，也是因为选了不该选的客户、签了不该签的合同、没有退出机制，最终走向失败。区别在于，那个项目的甲方和乙方都犯了错误；周总的故事里，甲方通过“先小后大”和“四个条款”，把风险控制住了。

这两个案例放在一起看，可以得到一个清晰的结论：甲方选FDE，不是选“最好的”，而是选“最匹配的”；签合同，不是签“最便宜的”，是签“风险可控的”。

（本案例为复合建构，由多个项目的真实情节提炼，不指向任何特定企业。）

16.6 工具：FDE评估清单与合同检查表

本节提供四个工具，对应甲方选FDE的四个连续动作：先用打分表评估团队（工具一），再用检查表核对合同（工具二），然后用决策树选定合作模式（工具三），最后用启动清单确认进场前还差什么（工具四）。前三件用在签约前，建议按顺序过一遍；第四件是签约之后、FDE进场之前的最后一道自查。

工具一：FDE评估打分表

使用说明：表16-5整合了16.2节的五个观察点、六个面试问题和两条一票否决红线。每项1—5分，总分55分。特别注意：如果触发了“一票否决红线”，直接淘汰，不再进入打分环节。

表16-5 FDE评估打分表（可打印版）

评估维度	评估项	评分（1-5分）	备注
进场准备	先要数据和现场，还是先要会议室和PPT
方案边界	方案里有没有“不做什么”
止损意识	有没有主动约定止损线
汇报风格	讲业务结果还是讲技术概念
组织嵌入	有没有深入业务现场找“关键用户”
失败经历	能不能讲出一个做砸过的项目
交接态度	那个项目后来谁接的手？能独立运行吗
采用验证	怎么知道用户真的在用
客户立场	有没有劝企业别花钱的经历
止损经验	止损线跟企业怎么谈的
长期责任	离开之后系统现在怎么样

一票否决红线（任一触发，直接淘汰）：

- 把“业务结果”完全推给企业（认为指标没达标是企业的事，跟技术无关）。

- 拒绝交出底层资产，或知识转移无明确验收标准。

总分：____分

评级：靠谱（45分以上），需谨慎（35—45分），高风险（35分以下）

注：分数线是经验参考。阶段2-3的试点项目可略宽；阶段4-5的系统性转型应更严。

工具二：合同条款检查表

使用说明：表16-6整合了16.4节的四个核心条款和三个补充条款。在签约前逐项确认，任何一项为“模糊”或“缺失”，不要签合同。

表16-6 合同条款检查表（可打印版）

条款大类	检查项	状态
交付物定义	“做完了”有明确定义吗？有可验证的业务指标吗？	☐
交付物是“结果”还是“功能”？	☐
可复用资产有定义吗？	☐
三层验收	技术、业务、用户三层验收标准明确且可量化吗？	☐
验收周期分步设定了吗？（防止技术验收“逾期视为通过”误伤业务观察期）	☐
知识产权	“通用”和“定制”的边界清晰吗？谁举证？	☐
源代码交付范围与托管条款明确吗？	☐
若全量移交代码，是否包含数据库、部署脚本和环境凭证？	☐
退出机制	中止条件、费用结算、过渡期安排明确吗？	☐
数据安全	保密协议、最小权限、泄露赔偿机制明确吗？	☐
变更费率	变更的书面审批流程与锁定的费率单价明确吗？	☐
开源许可	开源组件清单及传染性免责条款明确吗？	☐

工具三：合作模式选择决策树

使用说明：本工具帮助甲方在三种核心模式中做出选择。

第一步：排查人天计价。

如果FDE提出按“人天/工时”结算，说明他本质上是传统外包（卖人头），建议直接淘汰或换团队。

第二步：评估项目特征与风险承受力

- 问题1：这个项目的价值能被量化吗？

- 能量化（如“库存周转率提升X%”） → 进入问题2。

- 无法量化（如“提升品牌形象”） → 绝对不能选“按结果付费”，选择项目制或订阅制。

- 问题2：项目范围明确吗？

- 明确，知道自己要什么 → 选择项目制（必须在合同里写死“做完了”的定义）。

- 不明确，需要边做边探索 → 选择诊断+POC+实施的分阶段模式。

- 问题3：上线后需要长期陪跑迭代吗？

- 需要长期迭代和优化 → 在项目制基础上，叠加月度维护费（订阅制）。

- 不需要，上线后自己能接住 → 选择纯项目制。

- 问题4：FDE愿意承担失败风险吗？

- FDE有信心且愿意 → 可尝试基础费+效果分成。

- FDE不愿意承担全险 → 选择项目制或订阅制。

核心原则：无论选哪种，必须坚持“先小后大”（先诊断，再POC，最后扩大实施）。

工具四：FDE项目启动清单（签约前）

使用说明：表16-7是甲方在签约前、FDE进场前的最后一道自查。与合同条款不同，这里主要查的是甲方自己的内部准备。进场后的协作清单详见第17章。

表16-7 FDE项目启动清单（选型与签约）

序号	检查项（甲方自查）	完成状态
1	完成FDE评估打分表，且未触发“一票否决红线”。	☐
2	完成合同条款检查表，确认四个核心条款与三个补充条款全部写清。	☐
3	排除了“人天计价”，确认合作模式（项目制/订阅制/按结果付费/混合）。	☐
4	内部决策链确认：谁最终签字？谁负责验收？遇到阻力谁推动？	☐
5	数据审批流程确认：数据接入需要谁审批？周期多长？延迟了怎么处理？	☐
6	组织政治排雷：谁受益？谁担责？受益者和担责者是不是同一个人？	☐
7	知识转移准备：甲方指定的内部跟学人（种子选手）是否已就位？	☐

本节小结

本节提供了四个工具：FDE评估打分表、合同条款检查表、合作模式选择决策树、FDE项目启动清单。

打分表加上了“一票否决红线”，帮你直接过滤掉推卸业务责任、拒绝交出底层资产的“伪FDE”；合同表补齐了“分步验收”、“完整移交包”、“数据安全/变更费率/开源许可”等极易踩坑的防线；决策树强调了“先小后大”与“警惕人天计价”；启动清单则提醒甲方，在要求FDE进场之前，先把自己的决策链、数据审批和组织政治理顺。

下一节进行本章小节。

16.7 本章小结

第16章回答的是甲方在选FDE、管FDE时最关心的三个问题。

问题一：怎么找到靠谱的FDE？

答案是：先分清类型，再用“五个观察点+六个面试问题+两条红线”去筛查。

四种类型（产品驱动型、垂类场景型、纯项目定制型、混编纵队型）各有各的适用场景和风险点（资产归属问题），选型的第一原则是“匹配”，不是选“最好”。

评估时不能只看PPT。要看五个观察点（进场先要数据还是PPT、有没有“不做什么”、有没有止损线、讲业务结果还是技术概念、有没有找关键用户），问六个面试问题（做砸过的项目、交接给谁了、怎么知道用户在用、劝企业别花钱的经历、止损线怎么谈、离开后系统怎样）。

此外，必须守住两条一票否决红线：把业务结果完全推给企业的，不要；拒绝交出底层资产、知识转移无验收标准的，不要。

问题二：怎么选合作模式？

答案是：排除人天计价，在项目制、订阅制、按结果付费中选择，并坚持“先小后大”。

- 项目制：风险在甲方，必须防“范围蔓延”，签约前锁定“做完了”的定义和变更费率。

- 订阅制：风险在双方，必须防“价值稀释”，签约前约定月度交付物清单和退出窗口。

- 按结果付费：风险在FDE，必须防“标准模糊与归因争议”，只能用于价值可量化的场景。

- 对大多数甲方最稳妥的，是“项目制+月度维护费”的混合模式。

无论选哪种，核心原则是“先小后大，用结果换信任”：先花小钱诊断，再花中钱POC，验证了再扩大。

问题三：怎么签合同才不被坑？

答案是：四个核心条款+三个补充条款，一个都不能少。

- 交付物定义：明确到“不可争议”，不能给乙方留下抠字眼的空间。

- 三层验收：技术、业务、用户三层，且必须“分步设定时间”，防止技术验收的“10个工作日”误伤业务验收的“4周观察期”。

- 知识产权归属：争取“通用能力归FDE，定制代码归企业”；如果FDE愿意全量移交代码（当前的新趋势），必须确保移交包“送得干净”（包含数据库、部署脚本、环境凭证）。

- 退出机制：写在前面，防“拖死”。

- 三个补充：数据安全保密（防泄露）、变更费率（防预算失控）、开源许可（防技术合规风险）。

本章的核心判断

回顾本章，有一个判断贯穿始终：选FDE，不是选“最好的”，而是选“最匹配的”；签合同，不是签“最便宜的”，而是签“风险可控的”。

老陈的故事说明了“匹配”的重要性。他用“选软件”的逻辑选FDE，结果选了一个“品牌大、方案全、技术先进”的团队，却忽略了“这个团队能不能解决我的问题”。

周总的故事说明了“风险可控”的重要性。他用“先小后大”和“四个条款”，把风险控制在了可承受的范围内。

这两个故事放在一起，给甲方一个清晰的行动指南：先做诊断，再做POC，验证了再扩大；签合同，核心条款一个都不能少。

一个清晰的行动路径

- 第一步：定类型与查真伪。用16.1的四种类型识别对方的逻辑，用“三个致命问题”把伪FDE（卖人头、甩锅业务、黑盒锁定）筛出去。

- 第二步：评估靠谱度。用16.2的“五个观察点+六个面试问题”打分，只要触犯“把结果推给企业”或“拒绝交出底层资产”这两条红线，直接淘汰。

- 第三步：选合作模式。警惕人天计价，坚持“先诊断、再POC、后实施”的先小后大原则。

- 第四步：卡死合同条款。确认四个核心条款（交付物、分步验收、知识产权、退出机制）和三个补充条款（数据安全、变更费率、开源许可）全部写清。

- 第五步：内部排雷。在FDE进场前，确认内部的决策链、数据审批流程和组织政治地雷已经排掉（用16.6的启动清单自查）。

一句话带走

选FDE，不是选“最好的”，而是选“最匹配的”；签合同，不是签“最便宜的”，而是签“风险可控的”。请FDE，是为了最终不请FDE；用别人的能力，是为了长出自己的能力。

下一章预告

选好了FDE，签好了合同，下一步就是FDE进场后，甲方该做什么？

第17章要回答的，就是这个问题。甲方需要提供四样东西：给现场、给真话、给小权力、给决策者。同时，甲方还需要知道怎么安全地给FDE权限，怎么逐步减少对FDE的依赖，以及FDE项目失败的四个常见原因。

下一章，我们讲甲方如何与FDE协作并逐步自建。

本文来自网友投稿或网络内容，如有侵犯您的权益请联系我们删除，联系邮箱：wyl860211@qq.com 。

随机文章