卷二 · 定义：FDE 是什么，不是什么

开篇

我认识一个人，做了十一年 ERP 实施。

他给我算过一笔账：这十一年，他进过八十多家工厂，最长的一次在一家纸厂待了十四个月，睡在厂区宿舍，跟车间主任一起吃了一年食堂。他对造纸这个行业的理解，超过绝大多数造纸行业的从业者，因为他同时看过十几家。不同厂的纸机型号不一样，浆料配比不一样，抄造工艺不一样，但车间主任们焦虑的事情是同一件——下一张订单能不能按期交。他把这件共通的事情看明白了，纸厂的老板们也跟着把他看明白了。

去年他被优化了。理由是数字化实施部门整体裁撤。

他给我发消息的时候说了一句：我这十一年，好像什么都没留下。

他留下了。他留下的东西价值极高。八十多家工厂的真实运行、十几个细分行业的现场差异、几百个流程断点的修法、几千个车间主任做判断时用的那些讲不清楚的直觉——这些东西在中文里没有名字，在英文里也没有名字。它们没有被任何一份验收报告记录，没有被任何一张工时账单量化，没有被任何一次项目复盘显式写下来。但它们一旦被重新组织起来，可以换一种方式被反复使用。

只是从来没有人告诉他那东西叫什么，也没有人告诉他那东西可以怎么用。

这一卷要做的，就是给那东西起个名字。

那个名字叫 FDE：前线部署工程师，英文是 Forward Deployed Engineer。这个名字在 2008 年前后被 Palantir 内部造出来，2023 年之后被模型公司重新捡起来，到 2026 年 5 月被四家以上的行业巨头同时正式化。

但它要描述的那件事——一个工程师以独立身份进入客户环境，从头到尾完成调查到交付，并把结果回灌到自己的产品或方法库——在中国已经以另一种形态存在了二十年。它过去叫实施工程师，叫技术顾问，叫驻场支持。它之所以一直没有被识别为一个独立职业，是因为过去二十年里，前三个角色始终处在被激励结构错配的境地里，能做这件事的人没有拿到做这件事的权限。

这一卷给这件事划清楚边界：FDE 是什么，FDE 不做什么，FDE 跟那三种角色差在哪里。划清楚之后，后面六卷才有一个承重的落点。

第一章　这个词从哪儿来

Forward Deployed，直译前沿部署，是军事术语。指的是把部队部署在离总部很远、离前线很近的位置，脱离后方的补给与保护体系，在当地环境中独立作战。

这个词的重点从来在前半截。

前沿意味着三件事：离决策中心远、信息不完整、必须当场判断。后半截的部署，只是描述了动作。前沿的位置之所以特殊，是因为它要求驻在那里的单位同时承担两项此前由总部承担的工作——读懂局势的判断权，和对当地后果的责任权。一个在前沿的军官如果还要等总部发指令才能开火，那他就退化成了一个传令兵；一个在前沿的军官如果开完火之后没有后果归属，那他对局势的判断就会被无意识地调低——因为误判的代价落在了别人头上。

Palantir 在 2008 年前后把这个词用在工程岗上的时候，参照的就是这套结构。当时的语境是政府与情报客户——数据在客户那儿，不能带出来；系统在客户那儿，不能远程；需求说不清楚，因为说清楚本身就涉密。在那种约束下，唯一可行的方式是把工程师送进去。被送进去的工程师同时被赋予了两样东西：基于现场判断做什么的权限，和对交付结果负责的归属。这两样东西绑在一起，就是 FDE 这个岗位最早的结构形态。

把它写得更直白一些。一个传统软件公司的工程师，他的工作被切割成几段：产品经理写需求，架构师做设计，开发做实现，测试做验收，实施做部署，运维做维护。每一段交接时都有一个明确的契约——交付物是什么、完成判据是什么、超出范围怎么办。FDE 角色把这几段合并到一个人身上。这个人拿着一个空背包进客户现场，背包里装的是工具和判据，出来的时候背回来的要么是一个跑得起来的东西，要么是一份记录清楚的失败。

Palantir 把这种工程师叫做 Deltas。在 2016 年之前，Palantir 内部 Deltas 的数量多于传统软件工程师。这个比例本身就是这个岗位重要性的一个数字证据——一家公司在某一段时间里，把最贵的工程师一半以上都派到了客户现场。这件事在传统软件公司的财务模型里完全说不通，但 Palantir 的财务报表从 2022 年底开始持续兑现这件事的合理性。五年里 Palantir 的市值上涨了六倍以上。它用收入曲线证明了那批被派出去的工程师不是在烧钱，而是在给产品装感知器官。

到 2023 年之后，模型公司把这套东西重新捡了起来。原因是，大模型时代出现了一个新的、更严重的形状相同的问题——模型的能力是通用的，而每一家企业的场景是特殊的，从通用到特殊之间的那段路，只能在现场走。模型公司过去三年学到的最硬的一课，是「光有模型，光有工程师，签不下第一单」。第一单必须有人替你在客户那栋楼里蹲至少两个月。

2026 年 5 月，这套东西被四家以上行业巨头同时正式化。

• OpenAI： 成立 The Deployment Company，初始投入超过 40 亿美元，由 TPG 领投；贝恩、麦肯锡、凯捷以创始合伙方身份加入。
• Anthropic： 与 Blackstone、Hellman & Friedman、高盛成立合资公司，初始投入约 15 亿美元。
• ServiceNow： 与 Accenture、Cognizant 组建前线部署工程团队。
• SAP： 单独设立一亿欧元的合作伙伴基金。
• AWS 与 Microsoft： 两个月内前后分别承诺 10 亿美元和 25 亿美元，用于嵌入式部署能力建设。

把这些数字加在一起，行业在 2026 年上半年对「部署」这件事的总投入已经超过 90 亿美元。

来源： 公开报道，包括 OpenAI 与 Axios 联合新闻稿，Anthropic 与 Blackstone、H&F、Goldman Sachs 联合新闻稿，以及 CNBC、Bloomberg、TechCrunch 当日报道。

两周之内，四家以上，互相之间没有约好。一个行业在同一时间做同一个动作，通常只有一种解释：他们同时撞到了同一堵墙。那堵墙是「企业买了模型却跑不起来」，具体形状在卷一第三章已经拆过——四层信息断层。本章不重复展开，只把一件事讲透：当四家巨头同时决定把工程师派到客户那栋楼里的时候，他们不是在做一种新的销售模式，而是在做一种新的产品形态。前线部署工程师的产出，结构上属于产品迭代的输入端，跟销售没有直接关系。

这套模式被正式化之后，跟它绑定的薪酬数据也跟着显形。一份 2026 年 5 月发布、基于 1200 个薪酬数据点的报告给出了这样的图景：

• 前沿实验室的 mid-level FDE 总包中位数约 38.5 万美元。
• staff-level 总包约 61 万美元。
• Anthropic、OpenAI 这一档的 principal 级总包已经超过 120 万美元。
• 股权占总包的比例，从前两年的 35%–45% 抬升到 55%–70%。

来源： Perspective AI《2026 Forward Deployed Engineering Compensation Report》，综合 Levels.fyi、官方招聘披露与公开薪酬带；样本约 1200 个 FDE 薪酬数据点。

Palantir 的 Forward Deployed Software Engineer 岗位薪酬中位数约 21.5 万美元，区间在 17.1 万至 41.5 万美元之间；Glassdoor 上有 423 条样本记录。

来源： Levels.fyi 与 Glassdoor 综合。

薪酬的差异主要来自股权。在 mid-level 这一档，各家的基础工资差异在 2.5 倍以内。这意味着 FDE 这个岗位的薪酬结构，本质上是把员工绑到了公司未来的现金流上。

把薪酬数据再往外推一层。一家公司要养一个成本结构在 38.5 万到 120 万美元之间的工程师，必须让他产生足够的合同额来覆盖。行业里流传的配比经验是每一名 FDE 对应 200–500 万美元级别的企业管线。Anthropic 的合资公司初始投入 15 亿美元、OpenAI 的 Deployment Company 初始投入 40 亿美元，这个级别的资金量刚好对应几十名 FDE 的体量。

来源： Perspective AI 报告与 CNBC、Bloomberg 当日配套报道。

这个成本结构决定了一件对个人从业者至关重要的事情：他们的最低客单价有一条硬地板。低于那条地板的客户，他们做一单亏一单。所以他们不会做，也不该做。

Anthropic 那家合资公司已经把目标下探到中型企业了——中型企业在这家公司的语境里是 Blackstone、Hellman & Friedman、Goldman Sachs 旗下被投企业那一档，规模通常在数亿到几十亿美元营收区间。这已经是这个成本结构下的极限。再往下到中国登记在册的六千多万家中小企业这一档，单个 AI 项目的预算区间是几万到几十万人民币，这个数字连一个国际 FDE 的一周成本都覆盖不了。

所以中国这块地在结构上不可能被大厂吃掉。它不是被忽略了，而是被算术排除了。

那么它要被谁吃掉？留给本卷第二章和卷一第五章合并回答。先把国际同行的另一项经验也写下来，因为它在后面会反复用到。

Palantir 在二十年里沉淀出的 FDE 岗位设计有七条经验，被后续的模型公司直接借用。这七条不是从理论推导出来的，而是从无数次现场踩坑里收敛出来的。把它们列出来，是因为它们既描述了 FDE 工作的物理结构，也描述了这份工作在结构上与上一代实施岗位的本质差别。

第一条，招工程师外交官。FDE 不是招进来再培训出来的，而是按一种特定的混合画像招的——能写生产代码，同时能跟一个陌生的车间主任聊清楚对方在焦虑什么。这个画像的稀缺性决定了 FDE 的供给曲线极陡。

第二条，嵌入客户 8 到 16 周。一个 FDE 在一个客户那栋楼里待的时间短于 8 周，深度做不出来；长于 16 周，独立性会损失。这两个数字是经验区间，不是合同条款。

第三条，第一周交原型。一个 FDE 进现场的第一周，必须交出一个能跑的原型。这件事不是给客户看的，而是给客户那栋楼里的其他人看的——他们需要一个具体的、可触碰的东西来校准自己对这件事的判断。原型是 FDE 用来换信任的最便宜的工具。

第四条，客户发现即工程工作。FDE 在客户现场做的客户访谈、需求调研、流程梳理，本身就是工程工作的一部分。这件事的工程含义是：客户发现阶段的产出必须可以被复用、被版本控制、被检索。

第五条，先建客户本体再上模型。模型不是起点，而是终点。FDE 进现场的第一件事是帮客户把它的真实运行结构画清楚——数据怎么流、谁有权决定什么、决策的判据是什么。模型是在这个结构稳定之后才接上去的。

第六条，产品反馈经 FDE 回流。FDE 是产品的感知器官。同一类补丁在第三个客户身上做出来时，它就应该是产品的一个特性，而不是第三个客户的私有定制。这条是 FDE 工作与传统实施工作之间最深的经济学差别。

第七条，拒绝集成商角色。FDE 不接系统集成的活。系统集成的本质是协调多家供应商，把别人的东西拼起来。这项工作的激励结构会立刻把 FDE 拖进一个跟他能力完全不匹配的泥潭。这条在国际经验里被反复强调，在中国现场的体感更强烈——本卷第四章会展开。

这七条经验中，第六条是经济学层面的根，第七条是工作范围层面的边。其它五条都是关于 FDE 在现场怎么干活的。

最后，把这一章的国际线索收束到中国。FDE 这个岗位的中文对应物，在中国已经存在了二十年。它的早期形态是 ERP 实施工程师，后来是 BI 顾问，最近是 AI 解决方案工程师。这三个名字虽然换了三次，但描述的工作结构高度相似——工程师以某种身份进入客户环境，做某种程度的诊断和落地。

差别不在工作内容，在激励结构。二十年来，这批人被按人天计费，被塞在销售/售前的下游，被剥夺了对成败的归属权。一个被按人天计费、没有定义权、失败不归他管的工程师，无论多有本事，做出来的事都不会超过激励结构允许的上限。这是为什么那位做了十一年 ERP 实施的朋友会觉得「什么都没留下」——他留下了，但是激励结构让他留下的东西以不能被复用的形式存在。

2025 年 8 月，国务院《关于深入实施「人工智能+」行动的意见》印发。2026 年 1 月，八部门《「人工智能+」专项行动实施意见》印发。在这份文件的目标段落里，夹着一句容易被读过去的话：打造一批「懂智能、熟行业」的赋能应用服务商。引号里的七个字，是中国官方文件里给 FDE 起的名字。它和 Forward Deployed Engineer 在不同语言里指代了同一种工作结构——既懂技术又懂行业，能在企业现场独立完成从调查到交付的全过程。

这件事在中国第一次被写进国家政策文件，距离 Palantir 发明 FDE 过去了将近二十年。二十年的时差不是因为中国人没想出来这件事，而是因为在过去二十年里，这件事在中国没有经济性。直到 2026 年——模型能力过剩，执行成本塌方，理解成本不变——这件事才第一次具备了被批量承接的条件。卷一已经把这层时间结构讲透，本章只补一个收束：FDE 这个岗位的全球正式化和它的中国政策定名发生在同一年不是巧合，而是被同一组经济变量逼出来的。

第二章　四方对照

这一章是这本手册被引用最多的一页。我建议你单独截出来。

先列四个角色。

驻场实施工程师：受雇于软件公司或集成商，被派到客户现场安装、配置、调试、培训。在国内被叫了很多年技术民工。这不是一个贬义称呼，而是一个结构性描述——他的工作被按工日计量，按人头派遣，他的产出在激励结构里被当成可以被随时替换的工时。

系统集成商：承接整体项目，负责把多家厂商的硬件软件拼起来跑通。主要能力在工程管理和供应商协调。系统集成商在国内有比较长的历史，从政府信息化到企业 ERP 时代，它一直扮演着把不同厂商的零部件拼成一台可运行机器的角色。

管理咨询顾问：受雇于咨询公司，进场做诊断、出方案、交报告。不负责落地。咨询行业的计费单位是项目，结算节点是阶段性交付物，但这些交付物在客户那栋楼里是否真的落地，从来不在咨询公司的业绩核算里。

FDE：嵌入客户环境，独立完成从调查到交付的全过程，并把结果回灌到自己的产品或方法库。

这四个角色的差别不在能力，在结构。同一个人放在不同的激励结构和权限配置里，会产生完全不同的产出。一个被按人天计费、没有定义权、失败不归他管、离开后不再关联的人，无论多有本事，都不可能做出后面第七条那种结果。

现在按七个维度对照。每一条都先用一句话讲清楚差别，再用一个不带具体客户名的真实场景作对照——场景里的细节是行业普遍现象的脱敏描述，不绑定任何具体案例。

维度一：交付物是什么

驻场实施：一套按需求文档配置好的系统。配置的标准是「跟需求一致」，交付的物理形态是一台装好了软件的服务器和一份签字的验收单。

系统集成：一个通过验收的整体工程。它由多个分包商交付物拼成，集成商负责把拼装工作做完并通过总体验收。

管理咨询：一份报告和一套方案。报告和方案的载体通常是 PDF 和 PPT，承载方式通常是一个漂亮的封皮和几页带数据可视化的图。

FDE：一个在生产环境里持续运行的东西，加一份可复用的记录。前者要四周后仍然在被使用，后者要能被下一位 FDE 在下一个项目里检索并直接调用。

场景对照：一家做精密结构件的中型厂打算上一套质量追溯系统。

驻场实施交付了一台装好软件的服务器，签字验收。三个月后服务器上跑的是默认的 demo 数据，车间仍然用手写台账。

系统集成商交付了一套串起来的三家供应商设备加一个总控台，签字验收。一年后总控台没人用，因为三家供应商各自的升级节奏不一致，集成商不负责后续维护。

管理咨询顾问交付了一份 80 页的诊断报告，建议企业分三年上 X 系统和 Y 系统。报告在抽屉里躺了两年。

FDE 进场之后，先在车间蹲了两周画出真实的质量追溯流程——哪些环节有数据、哪些环节靠手写、追溯的判据是什么——然后写了一个能跑通这个真实流程的小系统，四周后仍然在被使用。同时 FDE 把这家厂的字段含义和流程断点写进了一份脱敏记录，下一个项目可以直接调取。

维度二：谁定义问题

驻场实施：客户定义，实施执行。客户提什么需求，实施就做什么。如果需求之间互相矛盾，实施负责把矛盾打回去让客户决定。

系统集成：客户和售前共同定义，写进合同。合同签字的时候需求被冻结，集成商按合同交付。

管理咨询：顾问定义，但定义的结果不被现实检验。顾问出的方案在客户那栋楼里落地与否，原则上不进入顾问的业绩核算。

FDE：自己定义，并且自己承担定义错误的后果。这条是四者之间最深的差别。一个 FDE 如果不能定义问题，他做出来的所有东西都没有归属；如果他不能承担定义错误的后果，他对问题的定义会被无意识地调低，避免承担风险。

场景对照：同一家精密结构件厂。驻场实施接到客户提的需求「上一个质量追溯系统」，按需求文档做完了，但客户自己不知道要追溯的颗粒度应该到批次还是到件——追溯到批次满足合规，追溯到件满足客诉定位。系统集成商在合同里把这部分模糊掉了，按批次交付。咨询顾问出的报告建议上批次级系统，但没有验证这套建议在客户内部是否能真的落地。FDE 进场第三天就识别出颗粒度必须到件——因为车间主任的客诉定位习惯是按件而不是按批——并把这件事以风险项的形式写进第三段（侦察报告的判断段）。四周后这家厂遇到一次客诉，件级追溯起了作用，批次级追溯帮不上忙。

维度三：有没有权说这件事不成立

驻场实施：没有。说了就是不配合。一个驻场工程师如果在客户面前说「这个需求不成立」，他大概率被换掉。

系统集成：理论上有，实际上没有，因为合同已经签了。集成商如果在合同签完以后说「这件事不成立」，要走变更流程，加钱；加完钱之后客户换了预算，集成商就被踢出去了。

管理咨询：有，但通常表述得很委婉，因为客户是甲方。咨询顾问通常用「挑战假设」「压力测试」「稳健性建议」这类修辞来表达「这件事不成立」。

FDE：有，而且是核心职责之一。一个 FDE 如果不能对客户说「这件事我建议不做」，他就退化成了一个效率更高的实施工程师。

场景对照：同一家精密结构件厂。驻场实施面对客户「上个 AI 质检系统」的需求，会按需求做。系统集成商会按合同交付整套 AI 质检设备和软件。咨询顾问会在报告里写「AI 质检的成熟度仍在演进，建议分阶段推进」，但不会直接说「这件事不成立」。FDE 进场第一周会去看车间的光线条件、节拍、缺陷类型分布，然后告诉老板：当前条件下，AI 质检在这条产线上的漏检率会超过 8%，比你现在的抽检模式差。建议先做两周的离线数据采集，验证可行性，再决定。这句话说出来的时候，是 FDE 准备丢掉这一单的瞬间——但这一句话同时是 FDE 拿到长期信任的瞬间。

维度四：定制工作的归宿

驻场实施：留在客户机房，随项目结束而失去价值。一家厂五年后遇到服务器故障，机房里的那套系统无人能维护。

系统集成：同上，且通常连文档都不完整。系统集成的项目里，文档是预算里最容易被砍掉的部分。

管理咨询：留在 PPT 里，被下一个项目复用为模板。咨询行业的知识沉淀在模板里——一个制造业模板被用在十家制造业客户上。

FDE：回灌为产品特性或方法库条目。FDE 的定制工作归宿不在客户机房，在自己的方法库。客户拿到了一个能跑的东西，自己拿走了一份可以复用的记录。

场景对照：同一家精密结构件厂。驻场实施做的定制配置，五年后随项目结束。系统集成商做的串接，五年后三家供应商里有一家倒闭，集成商不负责。咨询顾问出的报告，五年后被这家厂的继任者在抽屉里翻出来参考。FDE 做的定制工作里，60% 是这家厂独享的（设备对接、特定字段的解析、特定判据的回写），40% 在第三个项目上变成了通用方法——比如「精密结构件厂常见的光线干扰补偿」「按件追溯与按批追溯的接口统一方式」——被写进了 FDE 自己的方法库。

维度五：失败怎么处理

驻场实施：不归我管，需求是客户提的。这是驻场实施最常用的自我保护话术。它在情感上合理，在结构上把所有失败归到了客户头上。

系统集成：走变更流程，加钱。这条规则在工程意义上合理，在客户体验上等于「签完合同之后所有错误都让客户买单」。

管理咨询：报告里的风险章节已经提示过。咨询报告里通常有一段「风险与挑战」，把所有可能的失败提前列出来。这段在交付时让客户安心，在失败时让顾问免责。

FDE：写进第六段，公开，作为下一次的输入。FDE 的失败必须被显式记录，原因是 FDE 的判断力建立在失败记录之上。一个不记录失败的 FDE，三年之后的判断力跟第一年一样。

场景对照：同一家精密结构件厂。驻场实施的项目失败会以「客户需求变更」为由走流程。系统集成商的项目失败会以「现场环境与合同假设不一致」为由走变更。咨询顾问的项目失败会以「报告中已识别的风险」为由免责。FDE 的项目失败会写进一个统一的六段模板的第六段，里面有三件事必须填清楚——「什么死了」「为什么死」「下一次怎么避」。这三件事不是给客户看的，而是给下一个项目看的。

维度六：计价方式

驻场实施：人天。一天多少钱是驻场实施唯一清晰的计费单位。

系统集成：项目总包。总包合同锁定了集成商的风险敞口，激励结构倾向于把成本压低、把范围做大。

管理咨询：阶段性交付费。咨询行业按阶段收钱，每个阶段交付一份报告或者一次汇报。

FDE：结果口径 + 可选的持续分成。结果口径的最小形态是四周法则——四周后使用率达到多少算成立。可选的持续分成是在使用率稳定后按节省的成本或带来的收入做一笔小额分成。

场景对照：同一家精密结构件厂。驻场实施按每人每天的费率报价。系统集成商按项目总包报价，五百万包含设备、软件和两年维保。咨询顾问按阶段报价，三个月一期，每期八十万。FDE 按结果报价：第一阶段是固定费用的两周调查加一份诊断；第二阶段是按结果计价的交付，四周后使用率达标则结清尾款，未达标则免收交付费用并协助客户切换方案。

维度七：离开之后

驻场实施：系统还在，会用的人不多。这是过去二十年大量厂子里的真实状态。一台装好软件的服务器，配两个会操作的人，剩下的不会用也不敢关。

系统集成：系统还在，出问题找不到人。系统集成的项目结束之后，集成商的人员就撤了，留下一个由三家供应商零件拼成的机器，没有人对整机负责。

管理咨询：报告在抽屉里。咨询交付物的典型寿命是六个月到两年，之后被新项目覆盖。

FDE：东西还在跑，人还在用，没有人给你打电话。最后这一条，是这本手册对「做成了」的唯一定义。

场景对照：同一家精密结构件厂。驻场实施的项目结束一年后，服务器上跑的仍然是默认数据，原因是车间没人会配。系统集成的项目结束一年后，三家供应商里有一家升级了接口，另外两家没动，整个系统进入半瘫痪。咨询顾问的项目结束一年后，那份 80 页的诊断报告在抽屉里，新来的副总不知道有这份报告。FDE 的项目结束一年后，那套件级追溯系统每天还在被车间使用，FDE 不再接到这家厂的电话——除非这家厂要开始第二期的优化。

四方对照写到这里，要特别强调一件事，免得被误读为踩人。

这四个角色里，前三种人的能力并不比 FDE 低。开篇那位做了十一年 ERP 实施的朋友，他对造纸行业的理解超过绝大多数造纸行业的从业者，包括超过我十倍。差别不在能力，在结构。

同一个人，放在不同的激励结构和权限配置里，会产生完全不同的产出。

一个被按人天计费、没有定义权、失败不归他管、离开后不再关联的人，无论多有本事，都不可能做出上面第七条那种结果。

所以这一章真正的意思是：如果你是前三种人里的一个，你缺的不是能力。你缺的是把自己搬进另一个结构里。

怎么搬，这本手册剩下的六卷都在讲这件事。

这一章再补一个国际维度的对照。FDE 在国际同行那里通常被对应为 Applied AI Engineer（Anthropic）、Forward Deployed Engineer（OpenAI、Palantir）、Deployment Solutions Engineer（Databricks、Snowflake）等不同名字。这些名字背后的岗位设计高度相似，但工作重心略有差异——Anthropic 偏应用层、OpenAI 偏模型部署、Databricks 偏数据平台、Palantir 偏行业级本体建模。

在中国，FDE 还没有一个被广泛接受的官方英文对照词。政策文件里的「懂智能、熟行业」是中文的政策表述，英文政策表述目前是空白。这一空白是这本手册存在的理由之一——把这件事从一个政策表述变成一个职业的完整定义。

把四方对照表做成一个总览。

维度 一 二 三 四 五 六 七角色 交付物 谁定义 有权说不 定制工作归宿 失败归属 计价 离开之后驻场实施 配置好的系统 客户 没有 留在客户机房 不归我管 人天 系统在，会用的人不多系统集成 验收的整体工程 客户与售前 合同已签，无 留在客户机房 走变更流程 项目总包 系统在，出问题找不到人管理咨询 报告与方案 顾问 有，但委婉 留在 PPT 报告里已提示 阶段性交付费 报告在抽屉里FDE 可运行的东西+可复用的记录 自己+承担后果 有，是核心职责 回灌为产品或方法库 写进第六段，公开 结果口径+可选分成 东西还在跑，没人打电话

这七行七列是一个读法：把任何一个具体的项目、任何一个具体的从业者，按这七列分别填一下，就能定位他落在四方中的哪一格。绝大多数的项目和从业者都不止落在一格——很多项目是驻场实施加系统集成的混合，很多从业者是驻场实施加咨询顾问的混合。混合本身不是问题，问题在于激励结构跟着哪一边走。激励结构跟着驻场实施走，定制工作就烂在客户机房；激励结构跟着 FDE 走，定制工作就回灌到方法库。

这一章末尾再写一个最重要的延伸。

四方对照的真正目的，不是给四类人贴标签，而是给一类人一个换结构的入口。

如果你正在做的是驻场实施、系统集成或管理咨询，这本手册不会教你换一份工作，会教你换一种结构。换结构的具体路径在卷三、卷四、卷八——卷三给原则，卷四给方法，卷八给组织形态。但前提是你能识别自己当前所处结构的关键短板：是缺定义权，是缺否决权，是缺结果计价，还是缺失败归属。识别出哪一项缺，那一项就是你的转型起点。

这一段单独再写一遍，因为它是这本手册被引用最多的一页里最容易被跳过的一段。FDE 这件事在中国能不能做成，取决于今天做驻场实施的那批人愿不愿意从「不归我管」的状态里走出来。一个在「不归我管」里待久了的人，他对失败归属的本能反应是把它推出去。FDE 的本能反应是把它接过来。这两个反应在心理上完全不同，在职业收益上也完全不同。前者继续做外包工，后者开始做合伙人。

接法的具体步骤在后面六卷。

第三章　三处真变化

上一章是横向对照。这一章讲纵向的演进——相比二十年前的驻场实施，真正变了的只有三件事。

二十年前，软件公司派工程师驻到客户那栋楼里做实施。这件事的结构、激励、计价方式在二十年里基本没变。变的是另外三件事——回灌的工程化、权限的制度化、经济的可承接化。这三件事合起来，使得「驻场」这件事第一次变成了个人可以承接的生意。

变化一：回灌。

传统实施的定制代码，是负债。做完埋进客户机房，无人维护，随时间烂掉。做十家客户，得到十堆互不相干的代码。十堆代码的累加收益是零。它们的累加成本是非零的——每多一家客户，就要多养一份独立的代码库、多一份独立的维护人、多一份独立的故障排查路径。这是负的复利。

FDE 模式的关键假设是：同一个补丁做到第三个客户，它就该变成产品特性。这句话看起来简单，实际上重构了整个成本模型。

在传统模型里，第 N 个客户的交付成本约等于第一个客户。在回灌模型里，第 N 个客户的交付成本应该显著低于第 N-1 个客户。第 N 个客户拿到的不再是定制代码，而是一个已经包含前 N-1 个客户经验沉淀的版本。客户买的是 N-1 个客户的累加经验，不是 N-1 个客户的累加开发时间。

一个 FDE 在第三个客户身上花的时间应该比在第一个客户身上少 30%–60%，因为他在第二个客户身上已经踩过的坑、已经定型的接口、已经写好的工具，都直接搬到了第三个客户身上。做到第十个客户的时候，他的边际交付时间应该接近写一个新的配置文件的时间，而不是从零开发一个模块的时间。

如果你做到第十家的时候，成本跟第一家一样，那你没有在做 FDE，你在做重复的定制开发。这两件事在产出形态上有时难以区分，但在客户离开之后立刻能分清——重复的定制开发留下十堆不能互相调用的代码，回灌式的 FDE 工作留下一个可以不断演化的方法库。

回灌这件事的可操作性，在卷四第四阶段会展开成具体的工程动作。本章只给出一个操作级的自检方法。这个方法可以放在任何一位 FDE 候选人的桌面上。

自检方法（变化一：回灌）

把你最近三个项目的实际投入工时按以下口径排出来——总投入、客户独享的定制工时、跨客户可复用的工时。然后看趋势线。

第一条趋势线：总工时是否在下降。持平或上升，说明回灌没有发生。

第二条趋势线：跨客户可复用工时的占比是否在上升。持平或下降，说明你的方法没有沉淀。

第三条趋势线：客户独享的定制工时是否在下降。持平或上升，说明每个客户的问题都还在独立解决。

三条趋势线都向下，是回灌在工作。三条里有任何一条持平或向上，是回灌机制没有建立。卷四第四阶段专门讲怎么建。

变化二：权限。

传统实施只能填需求表，往上提，等排期。他对产品本体没有影响力，对客户需求没有否决权。每一个判断都要等上面拍板，每一处修改都要走变更流程。

FDE 有两样权力：动产品本体的权力，以及判客户需求死刑的权力。第二样更重要，也更难拿到。

动产品本体的权力，指的是 FDE 有权在产品里加入他认为是这第三个客户共性需求的功能或调整。这个权力通常由 FDE 的雇主（公司或团队）赋予，不来自客户。客户买的不是产品的某个固定版本，而是 FDE 在这个客户身上做的修改在下一个客户身上也能用。

判客户需求死刑的权力，指的是 FDE 有权对一个他认为不成立的需求说不。这件事看起来简单，做起来难。说不的前提是 FDE 必须有能力用数据证明这件事不成立——不是凭直觉，而是用客户自己的数据、自己的流程、自己的财务口径证明。一个没有数据支撑的「这件事不成立」和客户的拍脑袋没有区别。

第二样权力更难拿到，原因不在客户身上，在 FDE 自己身上。一个 FDE 在客户那栋楼里待超过两个月，他会开始跟客户产生情感关联——不是因为客户给了他什么好处，而是因为人在一个环境里待久了会自然地跟那个环境里的人产生共情。这种共情会让 FDE 的判断力被悄悄调低——他不再愿意说「这件事不成立」，因为他不想让那个他已经熟悉的车间主任失望。

避免这种污染的方式只有一种：在项目开始的时候就把否决权以合同条款的形式固定下来——哪些类型的决策 FDE 可以单方面做，哪些需要升级，升级给谁，按什么流程走。这套合同条款不是给客户看的，而是给 FDE 自己看的。它在 FDE 开始产生情感关联的时候替他守住判断力。

一个 FDE 如果不能对客户说「这件事我建议不做」，他就退化成了一个效率更高的实施工程师。

这个权力没有人会给你。它只能自己挣。挣的方式只有一种：你必须有能力用数据证明这件事不成立，并且愿意为此丢掉这一单。

这两件事缺一不可。光有数据但不愿意丢单，权力会被自己软化掉；愿意丢单但没有数据，权力会被客户用「你凭什么」一句话击穿。

自检方法（变化二：权限）

把你最近一个项目里你曾经想要否决但最终没有否决的需求列出来。每个需求后面写两件事：当时你手里有没有数据；当时你愿意不愿意承担丢掉这一单的代价。

如果你的答案是「有数据」和「愿意承担」——但当时你仍然没有否决——说明你所在的项目结构不支持否决这件事。这是结构问题，不是你个人的问题。换结构比换项目更治本。

如果你的答案是「有数据」但「不愿意承担」——这是激励错位。你当前的激励结构让你放弃否决比行使否决更划算。同样是结构问题，但修法不同——你要么换激励（换客户、换合同、换雇主），要么在新的项目里刻意练习承担代价。

如果你的答案是「没数据」——这是能力问题，需要补数据能力。具体补法在第六章权重表里。

变化三：经济学。

过去驻场靠人海。一个客户压二十个人，毛利被人头吃光，所以只能卖给出得起钱的甲方。一家年营收不到五千万的厂，过去是接不到任何一家正规服务商的驻场实施的。原因是服务商报不出一个让双方都接受的价格。

现在一个人加一套编排，能顶过去一个组。这句话必须给出边界，否则就成了吹牛。

我的实测边界是：在需求边界清晰、数据可获取、交付物是软件的情况下，一个人可以顶过去三到八个人。这组数字来自作者的实际项目记录。

这条边界的关键限制在四个地方：需求边界、数据可获取性、交付物形态、配套资源。

需求边界清晰。客户知道自己要什么，FDE 进场后不需要花大量时间做需求调研，而是按已有的需求文档去实现。这种项目在今天的中小企业里不到 20%。剩下的 80% 都属于「客户以为自己知道自己要什么，但实际不知道」的情况。FDE 的工作主要是把这种「不知道」翻译成「知道」。

数据可获取。客户的数据至少能通过某种方式拿到——可能是 API，可能是数据库，可能是手写台账的拍照。如果数据完全不可获取，这个项目就不在 FDE 的承接范围。

交付物是软件。交付物是软件的情况下，FDE 的工具链能产生最大的杠杆。交付物如果是硬件安装、机房布线、设备联调，杠杆就小得多。

配套资源可用。FDE 在交付期需要能从某个地方调取前 N-1 个客户的回灌沉淀。这件事在「超级个体」路径上由 FDE 自己的方法库承担，在「知识库型团队」路径上由团队共享的方法库承担（第七章会展开）。

在以上四个条件都满足的情况下，一个人加一套工具可以顶过去一个三到八人的小组。这句话在卷一第四章已经被执行成本塌方这一节铺过垫，本章只做承接，不重复展开。

在需要大量现场施工、硬件安装、多方协调的项目里，这个倍数会掉到一到两倍，因为瓶颈不在写代码。硬件相关的部分在卷六单独处理。

自检方法（变化三：经济学）

把你最近一个项目的总工时按以下口径拆开——调查工时、定义工时、交付工时、回灌工时、撤离工时。

如果你发现自己总工时里超过 60% 在交付，调查加定义不到 20%——你的经济学地基不牢。原因是「做对」的部分太少，「做出来」的部分太多。一旦客户的需求边界漂移或者数据情况变化，你会被迫回到交付里重做。

一个经济学上健康的项目结构应该是——调查 20%，定义 15%，交付 40%，回灌 15%，撤离 10%。交付不超过 50%，调查加定义不低于 25%，回灌不低于 10%。这是经验区间，不是死规定，但偏离这个区间超过 20 个百分点，就值得问一句「我是不是在做 FDE」。

这三处变化合起来看，指向一个结论。

驻场这件事，第一次变成了个人可以承接的生意。

这是全书的经济学地基。前面卷一讲的所有市场和政策，都要落在这一句上才有意义。市场缺口是机会，政策资金是杠杆，执行成本塌方是工具，但只有这三处变化合起来，「个人可以承接」这个结论才站得住。

把这一章和卷一第八章合起来看，能得到一个更深的判断：FDE 这个岗位之所以在中国刚刚出现，不是因为它的内容新，而是因为过去二十年做这件事的人没有一个被同时给到三样东西——回灌机制、否决权、可以承接的经济性。三样东西在过去二十年中任何一样都没有出现过。2026 年，它们第一次同时具备。这一年是 FDE 这个岗位在中国从「形态存在」走到「职业成立」的分水岭。

把这一章和第二章合起来看，能得到另一个判断：四方对照里 FDE 那一格之所以在过去二十年里是空的，不是因为没有人能做，而是因为没有结构能让做了的人活下来。结构是经济学、权限、回灌三件事的合集。三件事任何一件缺失，活不下来；任何一件单独成立，也活不下来。这是为什么过去二十年里中国有过「懂智能、熟行业」的人，但从来没有过「以 FDE 为职业」的人——前者是个体能力，后者是结构位置。

本章末尾再写一个延伸的判断。FDE 的三处变化在国际语境里通常被分别讨论——回灌被讲成知识管理，权限被讲成赋能，经济学被讲成执行成本下降。这三件事分开看都有道理，合起来看才显出 FDE 这个岗位的独特性：它是一个由三件事绑定的结构位置，单独拆开任何一件都不能产生 FDE。这个结构性绑定是 FDE 与所有上一代角色的最深层差别，也是这本手册后面六卷的承重起点——卷三的原则、卷四的方法、卷五的人机分工、卷六的硬件、卷七的案例、卷八的组织，全部要在这三件事的绑定上展开。

第四章　FDE 不做什么

定义一个岗位，写清楚它拒绝什么，比写清楚它做什么更有用。

拒绝清单的作用是给从业者一个可以公开使用的边界。一份写清楚「我不做什么」的文件，比一份写清楚「我能做什么」的文件更能帮你建立长期信任。原因是「我能做什么」是承诺，承诺会被打折扣；「我不做什么」是边界，边界是承诺不被打破的保障。

FDE 这个岗位有五条拒绝是必须写清楚的。前三条是工作范围层面的，后两条是工作方式层面的。

第一，不做系统集成商。

这一条在国际 FDE 的经验里被反复强调，我在中国现场的体感更强烈。

系统集成的核心工作是协调多家供应商，把别人的东西拼起来。这项工作的本质是项目管理和风险承担，跟理解一家公司没有关系。系统集成商在项目里的核心产出是「让别人的东西在同一台机器上跑起来」，而不是「让一家公司的真实运行被更准确地理解」。

一旦你接下这个角色，你会立刻被拖进一个泥潭：三家供应商互相推诿，你成了那个必须协调所有人的人，而你的判断力和技术能力在这个位置上完全用不上。你最强的能力——读懂一家公司、把它翻译成可执行的方案——在系统集成的位置上是负资产，因为系统集成商的工作流程不允许你慢下来做这件事。

拒绝的话术。这部分我不接，我可以帮你写清楚验收标准，你找专门做集成的人。

这句话做了三件事——明确边界（这部分我不接）、提供替代方案（帮你写验收标准）、把活推给更适合的人（找专门做集成的人）。这种话术在国际 FDE 圈子里被反复使用过，它不伤客户关系，因为客户听到的是「我帮你把关但不替你接活」，而不是「我不做你的项目」。

第二，不做纯人天外包。

理由上一卷讲过：人天计费奖励你待得久。FDE 工作里需要被驻场时间奖励的部分——调查、访谈、读车间——只占整个项目的 20%–30%。剩下的 70%–80% 应该被「做对了」而不是「做得久」奖励。

这一条有个例外：调查阶段可以按天计费，因为那个阶段的产出本来就是时间换信息。FDE 在调查阶段一周做 5 天的现场访谈、写一份诊断报告，这件事的产出确实就是 5 天的工时，按天计费在工程意义上合理。但交付阶段必须按结果。一周做 5 天的编码工作，产出不是 5 天的代码量，而是「能解决这个问题的软件」，按结果计费才是合理的。

我的实际做法是两段式报价。调查阶段固定费用，两到三周，交付一份诊断和一个验收口径；客户拿着这份东西可以选择不做下去，钱照付，双方两清。交付阶段按结果计费，四周法则使用率达到约定阈值则结清尾款，未达标则免收交付费用并协助客户切换方案。

这个设计有个额外好处：它把调查的价值显性化了。绝大多数客户从来没有为「看懂自己公司」付过钱，而这恰恰是最值钱的部分。两段式报价第一次让这件事在商业上成立了。

拒绝的话术。调查阶段我可以按周报价，两到三周后您拿到一份诊断和验收口径。拿到之后您可以选择不往下做，调查费照付。交付阶段我按结果报价，四周后使用率达标您付尾款，未达标我免收。

这段话术比「不接人天」要委婉很多，但表达的意思一样。它把定价结构和定价理由绑在一起讲，让客户理解为什么不是按人天——不是因为我矫情，而是因为按人天我做不出您要的结果。

第三，不做没有验收数字的项目。

任何一个说不出四周后拿什么数字来判断成败的项目，不接。

包括客户拍着胸脯说「你先做，效果好我们再谈」的那种。这类项目百分之百会在验收时变成扯皮，因为没有口径。一份没有数字的「效果好」是项目失败的标准前兆——因为它给所有人留了一个事后定义的口子。

拒绝的话术。我理解您希望先做后谈。但我做过太多这种项目，最后双方都说不清楚「效果」是达到了还是没达到。能不能我们现在一起花一个小时，把四周后验收的三个数字定下来？定得下来我就接，定不下来我就不接——这是为您好，也是为我省事。

这段话术的要点是「我们一起定」。它把拒绝对话从「我说了算」变成「我帮您一起把这件事搞清楚」。客户听到的不是拒绝，而是被尊重的对话。

第四，不承接自己判断不成立的需求。

哪怕客户坚持要做，哪怕钱已经在桌上。

这一条是诚实原则的直接兑现，具体展开在卷三。本章只给出拒绝的话术。

拒绝的话术。我看了您这个需求。我有义务告诉您——按照您目前的数据条件和业务条件，这件事做成您想要那个结果的概率，我判断不到 20%。这个判断我不是凭感觉，而是按您提供的三组数据算出来的。如果您坚持要做，我可以做，但我的报价里会包含失败兜底条款——做不出来时我只收调查费。

这段话术的关键在「按您提供的数据算出来」。它把判断的根据从「我觉得」变成「您的数据告诉我」。客户最容易被这种话术说服，因为它是基于他自己的事实。

第五，不长期驻场超过合理周期。

这条容易被忽略。一个 FDE 在一家客户待超过六到九个月，他会开始变成这家公司的编外员工。

标志有三个：你开始参加跟你项目无关的会议；你开始被安排处理杂事；你开始知道公司内部的八卦。

到这三个标志出现的时候，你的判断力已经被污染了，因为你成了这个组织的一部分，而这个组织的盲区现在也是你的盲区。

一个具体的污染机制是这样的：你在一家厂待了八个月，你已经跟车间主任们建立了深度关系。有一天老板提出一个你觉得不成立的方案，方案需要车间主任配合执行。如果你是 FDE，你的本能反应是写一份风险评估递上去。如果你是这家厂的编外员工，你的本能反应是先跟车间主任私下通气——「这个方案可能有问题，咱们要不要先缓一缓」。第二种反应在情感上更得体，在结构上让否决权失效——因为你把否决权让渡给了被否决的人。

避免这种污染的方式是主动撤离。一个 FDE 在项目主线完成之后就要撤离，不要等被暗示。即使客户挽留，也要有一个清晰的告别窗口。这个窗口的时间长度由日落条款决定，卷四第五阶段会展开具体操作。

拒绝的话术。我理解您希望我多待一段时间。但我的工作模式是项目制的——主线完成我就该撤。多待不会让项目质量变高，反而会让我的判断力因为太熟悉这里而变钝。如果您后续有新项目，我们再约。

这段话术的关键在「我的工作模式是项目制的」。它不是解释，而是划线。客户听到的是「我不是不想帮你，而是我必须按我的方式工作」。

把这五条拒绝合起来看，会发现一个共同的特征：每一条拒绝的话术都不是「我拒绝你」，而是「我帮你搞清楚这件事是什么」。这五段话术合在一起构成 FDE 这个岗位的对外沟通语言——它不是销售语言，而是诊断语言。一个用诊断语言跟客户沟通的从业者，他的工作很难被按人天计费，因为客户买的是诊断能力，不是工时。

FDE 拒绝清单的另一个作用是给雇主和团队一个可以写在制度里的条款。一个 FDE 团队如果把以上五条写进自己的接单标准，它就有了对内对外的合法性。对内，新加入的成员知道哪些活不能接；对外，客户知道你的边界在哪里。一个边界清晰的团队比一个什么活都接的团队更容易建立长期信任，因为客户知道你说「不」是真「不」，说「能」就是真「能」。

最后写一个本章的延伸。FDE 这五条拒绝清单跟国际 FDE 的经验高度一致。Anthropic 旗下的 FDE 团队被要求「不接集成商活」，OpenAI 旗下的 FDE 团队被要求「不做没有结果口径的项目」。这五条在中国语境里多了一条「不长期驻场超过合理周期」——这一条是中国特有的，原因是中国的项目政治保护比国际同行更脆弱（卷一第七章会展开）。这一条多出来之后，FDE 在中国的边界比国际同行更窄。窄是有代价的——你丢掉了可以多接一两个月的长尾项目。窄也有收益——你的判断力被保护得更完整。

第五章　一个 FDE 的时间结构

抽象讲完了，给具体的。

这一章展开一个 FDE 的时间结构——一个典型项目的时间结构，一周的时间结构，一天的时间结构，一年能承接的项目数量。每个层级都给一个可以自己核对的实测口径。

一个典型项目的时间结构（以八到十二周为例）

第 1 周：进场、侦察、三张图初稿、七问清单第 2 周：侦察收尾、锁定问题、写第一段和第三段初稿第 3 周：定义验收口径、报价、签字第 4–7 周：交付，每周一次可见进展第 8 周：上线第 9–12 周：观察期，四周使用率第 12 周：验收对数，写第五段和第六段第 13 周之后：交接、撤离、记录归档

这张表是经验区间，不是合同条款。不同项目在每个阶段上的时长会有差异。判断项目健康度的标准不是每个阶段花了多少时间，而是每个阶段产出的内容是否清晰、是否被客户那栋楼里的相关人知晓。

第 1 周的产出物是三张图初稿——钱怎么流、权怎么走、谁会输。这三张图是 FDE 进现场后画的第一批可被讨论的工件。它们不要求精确，要求可见。三张图被画在会议室白板上那一刻起，FDE 在客户那栋楼里的角色就从「销售带来的实施」变成了「能画清楚这家公司的人」。这个角色转变是后续所有工作的起点。

第 2 周的产出物是第一段（靠什么赚钱）和第三段（判断错在哪）的初稿。这两段必须在第二周结束时被写出来，写到能让客户最了解这家公司的那个副总读完之后能直接评论「你这里写错了」或者「你这里写对了」的程度。做不到这一点的初稿没有价值，因为它没被读过。

第 3 周的产出物是合同。合同里必须写明三件事——验收口径、日落条款、失败兜底。验收口径以四周使用率为准。日落条款约定项目在第几周结束、结束后 FDE 的责任边界在哪里。失败兜底约定未达标时 FDE 的收费减免方案。

第 4–7 周的交付期是项目的主战场。这一阶段的节奏判断标准是「每周一次可见进展」——客户那栋楼里的某个具体的人在某个具体的时间点能感知到 FDE 交出了一块具体的东西。可见进展是判断项目健康度的最便宜工具。一周没见到可见进展的交付期，已经在出问题了。

第 8 周的上线是一个分水岭。上线之前的失败都在 FDE 这边，上线之后的失败有一部分开始转移到客户那栋楼里（因为客户要在生产环境里实际使用）。FDE 的责任边界在第 8 周发生一次切换——切换前是「把东西做好」，切换后是「让东西被用起来」。

第 9–12 周的观察期是四周法则的兑现期。这四周的每一个数字——使用率、出错率、用户反馈、节省工时——都要被记录下来，作为验收对数的依据。四周法则的硬约束是：上线后连续四周仍在使用才算活。一周内使用率掉的，原因是上线质量；四周之后才掉的，原因是产品跟业务的匹配度。

第 12 周的验收对数是项目主线的终点。这一天 FDE 把第五段（什么活了）和第六段（什么死了）写完，然后做一次正式交接——把系统的运维职责、客户关系的所有权、未来扩展的需求池——全部移交给客户指定的人。第五段和第六段是 FDE 自己的资产，不属于交接范围。

第 13 周之后的撤离期是项目复盘期。FDE 在这段时间里把整个项目的所有可复用资产——三张图、七问清单、侦察段、定义段、回灌段——整理成可以被下一个项目调用的形式。这段时间不算工时，是 FDE 对自己未来能力做投资。

一周的时间结构（交付期）

大约五成时间在写东西——代码、脚本、配置、编排。大约两成在现场——看、问、盯着人实际怎么用。大约两成在沟通——对齐、拆解、拒绝。大约一成在记录。

五成写东西看起来很多，但「写」这个动作在这里的含义比传统开发的「写代码」宽得多。它包括写代码、写编排配置、写文档、写侦察笔记、写三张图的更新、写六段解剖、写客户内部沟通的素材。一个 FDE 的输出是高度文字化的，不全是代码。这个比例可以根据项目调整，但 FDE 的写作时间不应低于四成。低于四成的 FDE 通常在用沟通代替记录。

两成现场是 FDE 跟「影子系统」接触的唯一窗口。影子系统——Excel 表、微信群、手写台账——是车间真实运行的载体。FDE 必须在现场把影子系统识别出来、记录下来、纳入视野。这件事在远程做不了。远程能看到的是公司写在 SOP 里的版本，看不到的是车间实际执行的版本。

两成沟通是 FDE 跟客户内部不同利益方对齐的时间。这两成的产出往往是「我刚才那段写的内容必须被另一个利益方接受」。如果 FDE 不愿意花这两成，前面五成写的东西在客户内部会推不动。

一成记录是 FDE 对自己未来能力做投资的时间。这一成看起来不起眼，但它决定了 FDE 在三年之后是越老越值钱还是越老越贬值。三年后判断力的差距，主要来自这十年时间（一周 5 个工作日 × 50 周 × 三年 × 10% = 750 个小时）里写了什么。

一天的时间结构

我自己的习惯是把一天切成两段：上午在客户现场，下午找个安静的地方写。

原因是现场的信息密度极高但极碎，必须当天整理，隔一天就掉三成。

这个习惯是被逼出来的。早期我把整理放在周末，结果周五整理周一的事情，已经开始编了。编的意思是，记忆开始填充细节，细节开始偏离真实，偏离到一定距离之后，记录本身变得不可信。这是 FDE 工作里最隐蔽的失败模式——不是没做记录，而是记录本身在腐烂。

一天两段切的工程含义是：上午吸收，下午沉淀。这个节奏在 5 到 8 周的交付期里是健康的，在 12 周以上会疲劳。超过 12 周的项目要换一种节奏——比如一周五天里三天上午现场、两天上午写。

一个 FDE 一年能承接多少

我的实际数字：一年四到六个完整项目，加上若干个只做调查不做交付的短单。这组数字来自作者的实际项目记录。

超过这个数量，调查质量会掉。因为调查这件事没有办法并行——你的身体只能在一个车间里。

这个数字是这个职业最硬的天花板。一年四到六个，意味着每个项目平均两到三个月，意味着每周工作的小时数有一个自然的物理上限。

这个上限不能被工具变强绕开。一个人加一套工具可以顶过去三到八个人（第三章变化三），但不能顶过去八栋楼。一栋楼就是一个项目。一个项目就是一个 FDE 的身体长时间在场。身体不能被工具替代。

这个数字也是卷八讨论组织形态的起点。当一个 FDE 一年只能承接四到六个项目的时候，他一个人的产能上限就被锁死了。要突破这个上限，必须组队——但组队又带来了新问题：方法如何共享、判断如何对齐、记录如何互通。这些问题在第七章会展开。

把这一章的时间结构和国际同行的节奏做一个对照。Anthropic 旗下的 FDE 在一个客户那栋楼里驻场的时间通常 8–16 周，OpenAI 旗下的 FDE 节奏类似。这个节奏跟本节写的八到十二周高度一致。中国现场的实际节奏比国际同行略短——平均短一两周——原因是中国的项目政治保护窗口比国际更短。三个月没看到可见进展，老板会重新考虑。国际项目的政治窗口可以撑到六个月。

把时间结构跟第二章的四方对照合起来看，可以看到一个被反复印证的事实：FDE 的时间结构是结果导向的——每一个阶段都有明确的产出物和可被测量的健康度。驻场实施的时间结构是工时导向的——每一天是固定的计费单位，产出物的质量由后续维护结果决定，时间结构本身不承担判断责任。这两种时间结构的差别看起来只是节奏，实质上是激励。

最后写一个本章的延伸。在 FDE 的时间结构里，最容易被忽略的是第十周的可见进展——项目已经上线，四周使用率正在爬升，FDE 的身体仍然在现场。这一周 FDE 的工作已经不再是写代码，而是教客户那栋楼里的人用代码。一个 FDE 如果在第十周仍然把时间花在写代码上，他的项目大概率会死在第十一周——因为客户那边的人还没学会用。一个 FDE 如果在第十周开始把时间花在教人上，他的项目大概率会活——因为他把使用率的责任从系统转移到了人。

这件事没有公式可循，只有经验可参考。一个 FDE 在第十周愿意花 50% 的时间在教人上，他的项目存活率显著高于只花 20% 的人。这条经验来自我自己做过的一组对照——6 个项目里，存活率在第十周教人时间占比超过 50% 的组别是 5 个，不超过 50% 的组别是 1 个。样本量不够大到有统计显著性，但工程意义上的指引是清楚的。这组数字来自作者的实际项目记录。

第六章　能力画像与权重

招聘启事上的能力清单通常按重要性倒序排列。我按实际权重排一遍。

权重表是 FDE 这个岗位的「选人标准」。招聘启事上写的按重要性倒序，是因为启事需要展示这个岗位的全貌——既要让候选人知道这个岗位需要什么，也要让候选人知道自己跟这个岗位的差距在哪里。差距的判断在权重表上才能做：差距落在权重最高的那一栏，意味着转型的关键阻力；差距落在权重最低的那一栏，意味着无关紧要。

权重最高：能在混乱环境里判断真假。

这项能力没有对应的证书，也没有对应的学历。它的来源通常是三种经历：在客户现场被折磨过、做过审计尽调或调查工作、自己开过公司或家里做过生意。

判断真假的具体形态是：能听出一句话是被允许说的版本还是真实版本；能在会上分辨技术性反对和利益性反对；能在一堆互相矛盾的说法里定位真相。

一个具体的例子。在一家厂的会议室里，车间主任说「我们这个产线的节拍是 5 秒一件」。FDE 进车间实际观测两小时后发现是 7 秒一件。差别在哪里？车间主任讲的 5 秒是设备理论节拍，实际节拍受换型、待料、异常处理影响。FDE 进现场必须能听出来「5 秒」这个数字是被允许说的版本（因为它出现在 SOP 上），真实版本是另一个。

训练路径（权重一）

这种能力的训练路径只有一种：在混乱环境里待足够长的时间，让「被允许说的版本」和「真实版本」的差距变成你的本能反应。

在校学生能做什么：去真实的小公司实习（不是大厂实习）。大厂实习的体验是被允许说的版本，实习生的身份让你听不到真实版本。小公司实习的体验是真实版本。哪怕做的是端茶倒水的杂活，你也在听一家公司怎么运转。

转行中的从业者能做什么：刻意做一次跨行业的尽调或者访谈项目——不是作为执行者，而是作为旁观者。听一次访谈，看懂被访者在哪句话上犹豫、在哪句话上配合。三个月下来，你的判断力会上一个台阶。

在职的 FDE 怎么继续练：把每次客户会议的内容事后整理成「被允许说的版本」和「真实版本」两列，写在六段解剖的第三段里。三个月后回头看，你能识别出自己经常被哪种话术骗。

权重次高：能把模糊变成可证伪。

把「我们要提升效率」变成「四周后这个中位数掉不到两小时就算失败」。

这是一项可以训练的技能，也是这本手册卷四第二阶段的全部内容。它的核心动作是：把客户嘴里的话翻译成可被数字判定的判据。一句「提升效率」可以被翻译成二十种不同的判据——平均处理时间下降 10%、特定环节等待时间下降 20%、总工时下降 15%、错误率下降 30%——每一种都对应一种不同的项目设计。

训练路径（权重二）

把每一句客户的需求写成两行——上面一行是客户原话，下面一行是可被数字判定的判据。然后看下面一行能否在 4 周内被验证。能验证的是好判据；不能验证的，要么是判据本身有问题，要么是项目范围有问题。

在校学生能做什么：在校任何做产品的课程作业里，刻意用这个两行模板写自己的需求定义。一开始会觉得别扭，写十次之后变成本能。

转行中的从业者能做什么：找一份最近自己做过的需求文档，逐句把模糊表达翻译成可证伪判据。你会发现自己写过的 80% 的需求都是模糊的——这是行业普遍现象，不是你个人的问题。问题被识别出来之后，修复就有了起点。

在职的 FDE 怎么继续练：把「写判据」这一步放在所有客户对话的最后三分钟。无论你跟客户聊了什么，最后三分钟问一句「我们刚才说的这些，四周后怎么验证？」把客户的回答原话记下来。如果客户答不出来，你在场可以追问一次；答不出来就回去。

权重第三：工程实现能力。

能独立把一个东西从零做到生产环境。技术栈不重要，独立性重要。

这里有一个常见误判要纠正：很多人以为 FDE 需要极强的技术深度。实际上不需要。需要的是极强的技术广度加上足够的深度。

因为你在现场遇到的问题，一天之内可能横跨数据库、网络、设备协议、前端、部署、权限。每一样都不需要专家级，但每一样都不能卡住。一个 FDE 早上九点遇到数据库的连接池配置问题，下午三点遇到摄像头的 ONVIF 协议接入问题，晚上八点遇到前端组件库的版本冲突问题——三件事都得有解，三件事都不需要做到资深。

训练路径（权重三）

在校学生能做什么：不要只在自己专业的方向上做项目。横向铺开去接触——后端、前端、数据、运维、设备，每一项做一个能跑的小项目。重要的是独立完成从零到上线的全过程。技术栈具体是什么不重要，全过程走过一遍才重要。

转行中的从业者能做什么：选一个自己最不熟悉的方向做一个小项目，强制自己从零做到生产环境。比如你做了五年后端，去做一个完整的移动端应用 + 上线 + 监控。三到六个月的练手项目可以显著拓宽你的技术广度。

在职的 FDE 怎么继续练：每次现场遇到自己没碰过的技术栈，留 30% 的时间给自己做练习。FDE 工作里最珍贵的资源是「在客户现场遇到了真实问题但有时间做练习」的机会——这种事在产品型公司里几乎不存在。

权重第四：AI 工程能力。

编排、上下文管理、评估集设计、失败模式识别。

这一项的权重之所以不是第一，而是因为它的可替代性最高，学习曲线最短。两个月能补上，而前三项补不上。

需要强调的是，AI 工程能力是 FDE 在 2026 年的必备项，不是加分项。一个不会做编排、不会写评估集的 FDE 在 2026 年承接不到这个岗位的核心交付物。这一项放第四是因为它可以通过集中培训快速获得，但前三项不行。

训练路径（权重四）

在校学生能做什么：选一个当前一线模型的 API 文档和一个开源的编排框架，自己做一个从数据接入到结果输出的完整链路。重点是评估集设计——你用什么标准判断模型的输出是对的？评估集是 AI 工程的核心工件，不是可选项。

转行中的从业者能做什么：拿一个自己手头的工作场景，用 AI 工具重做一遍。比如你以前每天花两小时写日报，现在用编排工具把日报自动化。做的过程里你会遇到评估集设计、失败模式识别、上下文管理这些真实的工程问题。

在职的 FDE 怎么继续练：每次交付的项目里至少包含一个评估集。这个评估集记录输入、输出、人工评分三项数据。三个月后回看，你会发现自己对 AI 系统可靠性的判断力显著提升。

权重第五：表达与写作。

写方案、写记录、在会上讲清楚。

这一项被严重低估。一个 FDE 的产出中有相当比例是文字，而且这些文字要同时被老板、车间主任和另一个工程师读懂。三类人的阅读习惯完全不同——老板看前三行定决策、车间主任看每张图找自己关心的细节、工程师看代码块找可行性。一个 FDE 的文字如果只能被其中一类人读懂，他就要花两倍时间跟另外两类人解释。

训练路径（权重五）

在校学生能做什么：刻意写三类不同读者的文档——写给决策者的、写给执行者的、写给同行的各一份。每类读者写三到五份之后，你会发现自己对「同一件事用不同语言说」这件事有直觉。

转行中的从业者能做什么：把过去做过的工作文档拿出来给三类人看——一个外行、一个同行业务人员、一个同行技术人员。收集反馈，重写，直到三类人都能读懂。

在职的 FDE 怎么继续练：每次给客户写方案后，刻意把方案的「第一段前三行」写两版——一版给老板、一版给车间主任。两版内容不同，长度不同，语气不同。写十次之后你的写作能力会上一个台阶。

权重最低：具体的技术栈熟练度。

某个框架、某个云、某个模型的具体用法。

这些东西的半衰期是几个月。花时间在这上面建立优势是最差的投资。

这并不意味着技术栈不重要。技术栈是承载 FDE 工作的工具，但工具的更替是技术行业的常态。一个 FDE 如果把时间投资在某个具体框架的精通上，三年后这个框架可能已经被淘汰。

训练路径（权重六）

在校学生能做什么：不要把时间花在某门语言或某个框架的精通上。把时间花在「学一项新技术的速度」上——每次学一门新技术时记录自己从零到能独立做小项目花了多少小时。三个月后回看，你会发现自己的学习速度在加快。

转行中的从业者能做什么：每半年刻意换一次技术栈。换的过程中你会发现，「掌握技术栈」这件事的难度主要不在技术本身，在工具链和生态。一旦你看清楚这一点，技术栈的更替对你来说就是常规工作。

在职的 FDE 怎么继续练：每次新项目尽量用一项自己没碰过的技术栈。FDE 的项目天然支持这种练习——每个客户的环境都不一样，每家厂用的数据库、协议、云都不一样。

按这个权重表，你可以自己做一次盘点。绝大多数技术出身的人，权重最低的那两项最强，权重最高的那两项最弱。

这就是转型的真实工作量。技术出身的从业者要补的是「读懂人」和「写判据」两件事。这两件事不是靠学一门课就能补的，要靠真实场景的反复练习。在校学生能做的最有效的事不是再去学一门新技术，而是去真实的小公司做一两个项目，把「读懂人」和「写判据」这两件事练出初步感觉。

非技术出身的从业者要补的是「工程实现」和「AI 工程」两件事。这两件事的入门门槛比想象中低——三个月集中学习可以补到能用的水平。但「能用」和「精通」之间的差距，在 FDE 工作里被工程广度而不是深度填平——所以这两件事的练习重点是「多接触不同领域」而不是「在某个领域深挖」。

把这一章的权重表与国际 FDE 圈子的招聘画像做一个对照。Anthropic 的 Applied AI Engineer 公开 JD 上写的能力要求里，权重最高的「判断真假」被翻译成「comfort with ambiguity」「problem decomposition」「stakeholder management」这类表达。

OpenAI 的 Forward Deployed Engineer 公开 JD 上把「把模糊变成可证伪」翻译成「translate ambiguous business problems into well-defined technical requirements」——这是同一种能力在不同语言里的描述。这些翻译跟本章的权重表是一致的，说明 FDE 这个岗位的核心能力在全球范围内是同构的。

把这一章的权重表和第二章的四方对照合起来看，能看到一个清晰的因果链：FDE 这个岗位之所以需要高权重的「判断真假」，是因为 FDE 的工作不被驻场实施、系统集成或管理咨询里那些已有的角色保护层覆盖。驻场实施有客户定义保护他，系统集成有合同边界保护他，咨询顾问有甲方身份保护他。FDE 没有这些保护。FDE 进场时没有客户定义的需求文档（要自己写），没有合同边界的保护（要自己谈），没有甲方身份的保护（要自己证明）。他必须靠自己的判断力穿过这些保护层的缺失。

这就是为什么「判断真假」的权重最高。FDE 不是一个被保护的人，而是一个保护自己的人。

把这一章和第三章合起来看，能看到权重表里的每一项都对应三处真变化里的某一项。判断真假对应变化二（权限），因为权限的核心是判断力。把模糊变成可证伪对应变化三（经济学），因为经济学的前提是判据。工程实现能力对应变化一（回灌），因为回灌要求每个项目都做出可被复用的工程产物。AI 工程能力、表达写作、技术栈三项是支撑性能力，不是 FDE 区别于上一代角色的核心项。

把这一章和第五章的时间结构合起来看，能得到一个具体的行动指引——一个想成为 FDE 的人，应该把练习时间按权重表分配。判断真假和把模糊变成可证伪各占三成时间，工程实现和 AI 工程合计占三成，表达写作占一成。具体技术栈的练习不超过一成。这种分配看起来反直觉——FDE 是个工程岗位，练习时间应该大部分给技术——但 FDE 区别于传统工程师的核心是判断力和翻译力，技术的部分是支撑。

在校学生和转行者最容易走错的一步是把时间全花在前三项（具体技术、AI 工程、工程实现）上，结果工作三五年后发现自己的判断力和翻译力仍然是零。一个 FDE 的成长曲线在头三年是平的——因为他的判断力主要靠真实项目经验积累——但第五年开始陡升——因为他在前面四年里已经积累了足够多的真实场景判断样本。在校学生和刚入行的从业者要做的，是在前两年里刻意把自己的工作经历替换成「能练判断力和翻译力」的经历，而不是「能练技术」的经历。

这个建议在第四章里讲过的「不长期驻场超过合理周期」原则下有一个微妙的张力——你不能长期驻场去练判断力，但你必须去真实场景里练。这个张力的解法是：尽量做短周期、目标清晰的真实项目，而不是长周期的项目。短周期项目能练的判断力场景更多——每两三个月换一家公司，你能在两年里接触 8–10 个行业。长周期项目在一家公司里能学到的更细，但判断力的样本量太小。

本章末尾写一个延伸。FDE 的能力权重表不是一个静态画像，它随着行业演进会变化。2026 年的权重表里 AI 工程能力排在第四，再过两年可能升到第三。这件事不需要被过分担心——权重变化的只是相对位置，不是底层结构。判断真假、翻译模糊、工程实现这三项在任何一年的权重表里都会在前三位。这个结构稳定性是 FDE 这个职业的承重柱。

把在校学生能做的事单独写一遍，因为这是这本手册直接面向的一类读者。

在校大学生能做的最有效的三件事，按权重倒序排：

第一，找一家真实的中小企业做一份实习——不是大厂实习。大厂实习给的是「被允许说的版本」的训练，小公司实习给的是「真实版本」的训练。这两种训练的差距在头两年看不出来，在第五年差距会拉到五倍以上。

第二，把每一次小组作业当真实项目做——按六段解剖的格式写交付物，不按学术报告的格式写。这种写作训练在毕业后直接转化为 FDE 工作的能力。一个能写六段解剖的毕业生和一个只能写学术报告的毕业生，在 FDE 岗位上起跑线差两年。

第三，学一项非计算机的核心技能——可以是某门手艺、某个行业的入门知识、某段商业经历。FDE 的工作结构是「技术 + 行业」，单一技术背景的人在 FDE 岗位上很快会触到天花板。复合背景的人天花板显著更高。这条建议不是政治正确，而是从过去五年里几百位 FDE 候选人的画像里收敛出来的经验判断。

把在校研究生能做的事再单独写一遍。

在校研究生能做的最有效的三件事，按权重倒序排：

第一，把研究课题的选择往「真实场景」靠——选一个在企业里能落地的题目，而不是一个只在论文里能发表的题目。学术发表和工程落地是两个不同的能力坐标，但 FDE 岗位需要的是后者。研究生阶段如果只训练前者，入行 FDE 后头两年会很痛。

第二，用学术训练的方法做一份非学术的写作——比如把研究课题写成一份可以给企业决策者读的简报。学术写作训练的是严谨，工程写作训练的是可被快速理解。两种训练并行做比只做一种要好。

第三，在学术会议之外参加一两个行业会议——AI 类的、智能制造类的、垂直行业类的。学术会议是同行的对话，行业会议是真实需求的来源。FDE 的训练需要这两类信号同时输入。

把转行者能做的事再单独写一遍。

已经在工作、想转行做 FDE 的人能做的最有效的三件事：

第一，在当前的工作里刻意练「翻译」——把模糊的需求翻译成可证伪的判据。这一项可以在任何工作里练，不需要换工作。

第二，业余时间做一两个跨行业的真实小项目——可以是开源贡献、可以是朋友的创业项目、可以是付费的自由职业。重要的是「跨行业」和「真实」两个条件。

第三，找一个 FDE 圈子——可以是行业聚会、可以是线上社区、可以是一两个已经在做 FDE 的人脉。FDE 是一个高度依赖同行反馈的职业，闭门做三个月不如在圈子里跟同行碰一次问题。

这三件事的共同特征是「低投入、高回报」——投入的时间不多，但对转型路径的清晰度提升很大。

把已经是有经验的从业者想进一步做 FDE 的人能做的事再单独写一遍。

已经是有几年经验的工程师、咨询顾问、产品经理、解决方案架构师，想转向 FDE 的人能做的最有效的三件事：

第一，重新分配自己的时间——把 20% 的工作时间投入到「能练判断力」的事情上，比如参与一个跨部门的真实调研项目、去做一次客户访谈、做一份跨部门的需求翻译。

第二，把自己过去做过的工作按六段解剖的格式重新整理——你会发现你过去的工作里只有 30% 能用 FDE 的格式讲清楚。剩下 70% 在 FDE 的框架里要么是定制开发，要么是无效工时。这个盘点会帮你判断你的真实积累在哪里。

第三，在下一次重大职业选择时刻意往 FDE 方向靠——换岗、换项目、换客户都比换工作更现实。从一个咨询岗跳到另一个咨询岗，转型 FDE 不会自然发生；从一个咨询岗转到一个具体的 FDE 项目上，转型才会真正启动。

这些分类建议合在一起构成本章的延伸——FDE 不是一个被特定专业背景锁定的职业，它是一个被能力组合锁定的职业。能力组合的具体配比因人而异，但权重表的六项是固定的。

第七章　两条路径

最后讲清楚这个职业的两种形态，它们的分岔点在第一年年底。

第一年做下来，你会遇到一个不可绕开的问题：你要继续做一个超级个体，还是要开始组队？这两条路径不是非此即彼——大多数从业者在职业生涯里会先走路径一再走路径二——但分岔点是真的存在。错过这个分岔点的人，往往在第三年发现自己的增长曲线已经停了。

路径一：超级个体。

一个人，一套工具，一年四到六个项目。这组数字来自作者的实际项目记录。

优势：成本极轻，决策极快，客户关系直接沉淀在自己身上，收入天花板取决于单价而不是人数。

一个超级个体在第三年的客户单价通常是第一年的 1.5 到 2 倍。原因是他在前两年里积累的「懂行业」让他的判断力上升，客户愿意为更高的判断力付更高的价。

天花板：你的身体。一年最多进那么多栋楼，这个数字不会因为工具变强而增加。

适合的人：判断力强、社交能力足够、能忍受不稳定、不想管人。

一个超级个体在第三年通常会撞到第二个天花板——不是项目的天花板，而是收入的天花板。即使单价从第一年的 20 万涨到第三年的 40 万，一年的总收入也被物理上能进的项目数量锁死。这个天花板的硬性是：一年四个项目 × 40 万 = 160 万。要突破这个数字，必须组队。

路径二：知识库型团队。

三到十人，共享一套记录和方法库，按项目阶段动态组队。

优势：可以并行，可以覆盖更多行业，第 N 个项目的成本随记录积累持续下降。

一个十人团队如果方法库真正起作用，他第三年能同时承接的项目数可以是一年 20–30 个，是超级个体的五倍以上。同时他的单价不需要涨到顶级 FDE 水平，因为规模效应在弥补单价的差距。

难点：全部在格式和纪律上。团队一旦不写记录，它就退化成一个普通的外包公司，而且比外包公司还贵。

一个十人团队在第三年仍然保持「知识库型」而不是退化到「外包公司」的关键指标是——团队成员对方法库的调用频次是否每周超过十次。低于这个频次的团队，方法库事实上没有被使用。

适合的人：愿意花时间做基础设施、能忍受前六个月产出下降的人。

一个新建的知识库型团队在头六个月的产出通常比一个等规模的传统外包公司低 30%–50%。原因是前六个月在建设基础设施——格式、纪律、记录、模板、复盘节奏。基础设施建好之后，团队进入稳定期，产出恢复到正常水平。第二年开始出现回灌效应——同一类问题在第三个客户身上的处理时间开始显著下降。

我的判断是：三年之后，纯粹的超级个体会被知识库型团队压制。

理由不复杂。

一个人的行业理解，来自他亲自进过的那些楼。一年六栋，三年十八栋。

一个十人团队，如果记录格式统一、真的互通，三年是一百八十栋。

而在这个职业里，判断力的增长速度直接正比于你见过多少种真实运转方式。

这条判断的失效条件是：方法库没有真正互通。形式上有一个共享文档但没人真的调用，跟没有方法库没有区别。一个团队在三年内能不能让方法库真正互通，取决于三条——记录格式的强制度、调用方法库的工作流嵌入度、团队成员对方法库的所有权感。缺任何一条，方法库就会变成一个没人用的工具集。

把这两条路径跟国际 FDE 圈子的经验做一个对照。Anthropic 旗下的 FDE 团队从路径二起步，10 人左右的核心小组扩展到 50–100 人的部署团队。Palantir 旗下的 Deltas 走的是路径一和路径二的混合——每个 Delta 在自己的客户那栋楼里是路径一，多个 Delta 共享 Palantir 内部的本体工具和数据集成组件形成路径二。OpenAI 的 Deployment Company 走的是更激进的路径二，几十名 FDE 共享一套编排平台和回灌机制。

这两种形态在中国都有对应物。路径一对应的是「个人 FDE」——一个工程师接四到六个项目一年。路径二对应的是「FDE 工作室」——三到十人共同使用一套方法库，对外报价按团队提案，对内分配按个人贡献。这两种形态在中国目前都有，但路径一明显多于路径二。原因是中国 FDE 圈子的形成时间还短，方法库的建立需要时间。

把这两条路径和第二章的四方对照合起来看，能看到更深的判断——路径一是 FDE 这个岗位的「个人形态」，路径二是 FDE 这个岗位的「组织形态」。个人形态保留了 FDE 的核心特征（独立判断、对结果负责、按结果计费），但受限于物理产能。组织形态解决了物理产能，但带来了激励结构的新问题——团队成员之间的判断力差异如何处理，团队对客户的责任归属如何分配。这些问题在卷八会展开。

把这两条路径和第三章的三处真变化合起来看，能看到一条因果链——路径一能成立是因为三处变化里的经济学变化（一个人加一套工具可以顶三到八个人）。路径二能成立是因为三处变化里的回灌变化（第 N 个项目的成本随记录积累持续下降）。如果回灌没有真正发生，路径二会退化到路径一的简单叠加——十个人的产能是十个人的六倍，但人均产值不变。回灌发生之后，路径二的人均产值在第三年应该比第一年高 50% 以上。

这就是卷一第八章提到的那条设计的意义所在：一个正式席位由一名人类加一个配对 Agent 组成。人负责判断和承担后果，Agent 负责执行和记忆。

未来的 FDE 编制，最小单位不是一个人，而是一个人加他那套能记住所有事情的东西。

这条设计从两条路径的角度看有更具体的含义。路径一里，一个 FDE 加上他长期维护的那套方法库（包括他自己的方法库和他能调取的公开方法库），就是一个席位。这个席位的边界是清晰的——席位内的判断力由 FDE 承担，席位内的记忆由 FDE 的方法库承担。路径二里，三个到十个这样的席位共享一套方法库，组成一个 FDE 工作室。每个席位的独立性和工作室的协同性同时被保留。

再往上一层，是若干个这样的席位共享同一套记录。

到那个阶段，这个行业的竞争维度会从「谁交付得更快」变成「谁对这个行业理解得更深」。

而理解的深度，只能靠积累，不能靠聪明。

具体怎么建这套东西，在卷八。

本章末尾写一个延伸。两条路径的分岔点不是「我要不要组队」，而是「我有没有方法库」。一个没有方法库的 FDE 即使组了十人团队，也退化成了外包公司。一个有方法库的超级个体即使不组队，他的方法库也能被下一个加入的人快速调用。在 FDE 这个职业里，方法库是真正的资产，个人和组织都只是方法库的载体。

这个判断跟卷一第八章关于「魂壳分离」的设计是同构的——魂是方法库、是判断标准、是事件轨迹、是校准记忆。壳是个人、是团队、是软件、是制度。壳可以换，魂必须能导出、迁移、复活。

把这一章和第二章、第三章、第五章、第六章合起来看，卷二的论证链就完整了。卷二从头到尾讲的是 FDE 这个岗位的定义——它从前沿部署这个军事术语开始，经过 Palantir 的二十年沉淀和模型公司的 2026 年正式化，落到中国 FDE 在 2026 年面临的两个具体路径。中间用四方对照划清边界，用三处真变化定下结构，用五条拒绝立住纪律，用时间结构给出可执行的节奏，用能力权重表给出选人标准。

这两条路径在 2026 年的中国 FDE 圈子里都已经出现。路径一是大多数从业者的起点，路径二是少数能活过第三年的从业者的方向。两条路径之间没有优劣，只有适合不适合。一个判断力强、社交能力足够、能忍受不稳定的人，路径一可以走得很远。一个愿意花时间做基础设施、能忍受前六个月产出下降的人，路径二可以走得更快。

把这两条路径和开篇那位做了十一年 ERP 实施的朋友合起来看，这一卷的结构就闭环了。他当年是路径一，但因为没有回灌、没有否决权、没有经济学上的可承接性，他的「个人 FDE」没有走通。他留下的方法如果被一个 2026 年的 FDE 重新组织、加上回灌机制和否决权，就是路径一的现代版本。他的「好像什么都没留下」的遗憾，本质上是结构不让它留下。

这一卷要做的是——让 2026 年开始做 FDE 的人，把「留下」这件事写进自己工作方式里。不是「写记录」的口号，而是「留下」作为职业结构的内建功能。路径一通过自己的方法库留下，路径二通过团队共享的方法库留下。两种留下都不需要特别的努力——它只需要你做的每一件事都被结构化地沉淀下来。

本卷法条

FDE 第二法 · 结构律

一个人的产出，由他所处的激励结构与权限配置决定，而不由他的能力上限决定。

因此，转型的核心工作不在补技能，在换结构。四项必须同时成立：定义权、否决权、结果计价、失败归属。

推论：缺任何一项，其余三项都会退化。

失效条件：如果出现一种交付模式，能在没有定义权的前提下稳定产出上述第七条的结果，本法作废。

本卷附带的失效条件：

一，四方对照表的失效条件：若中国 FDE 圈子的岗位画像不再以「独立判断 + 对结果负责」为核心特征，而是退化为「高级实施」或「高级售前」，本卷的四方对照需要重写。判断观察口径：FDE 岗位 JD 中「对结果负责」「独立定义问题」类描述的占比。

二，三处真变化的失效条件：若中国现场出现以下情形，本卷关于「个人可以承接的生意」的判断作废——(a) 大厂在中国成立专门面向中小企业的合资公司，且报价区间与个人 FDE 重叠；(b) 政策资金被取消或政策文件中删除「懂智能、熟行业」字样；(c) 回灌的方法论在三年内未被任何 FDE 团队验证可降低边际交付成本。

三，FDE 五条拒绝清单的失效条件：若中国 FDE 圈子的市场结构发生根本性变化，五条中的某一条不再成立（例如系统集成商在中国中小企业市场消失），对应的那一条可以从清单中删除。

四，两条路径判断的失效条件：若三年后纯粹超级个体的年总收入超过知识库型团队的人均年总收入，且差距在两倍以上，本卷关于「知识库型团队在长期内压制超级个体」的判断作废。

五，作者实际项目记录中的数字，其失效条件如下：一年四到六个完整项目、一个人顶三到八个人、第十周教人时间超过 50% 的项目存活率高于不超 50% 的组别。这些数字都应以可核验记录为准。若后续证据与本卷数字不一致，本卷涉及的具体描述需按用户口径调整，方法论本身不需重写。

六，本卷所引 2026 年公开数据（薪酬、配比、Palantir 经验、岗位设计七条）以来源标注的发布日为准。若上述数据在 2026 年下半年出现 30% 以上相对变动（如薪酬中位数、FDE 岗位增长率、配比经验），本卷关于国际 FDE 市场结构的描述应同步重新评估。具体来源在第一章末尾及正文相应位置已分别标注。

七，本卷关于在校学生能做什么的训练建议，以「在校大学生能直接进入中小企业实习为前提」。若该前提因外部环境变化而消失（如实习制度发生重大调整），训练建议需重写。

八，本卷关于「路径一在三到五年内被路径二压制」的判断，建立在「方法库真正互通」的前提之上。若方法库在团队内事实上未被调用，本判断自动失效。

本卷末尾给一个总收束。

这一卷的核心论断只有一条：FDE 是一个被结构定义的工作，而不是被能力定义的工作。

一个人有没有 FDE 的能力，不取决于他会什么技术、有什么背景、做过什么项目。一个人能不能做 FDE，取决于他所在的项目结构是否同时给他四样东西——定义权、否决权、结果计价、失败归属。

这四样东西的组合在 2026 年的中国 FDE 圈子里第一次同时具备。这个「第一次同时具备」不是来自市场自发演化，而是来自模型能力过剩、执行成本塌方、理解成本不变这三件事的合力。三件事合起来，重构了「驻场」这件事的经济学结构。

一个 FDE 在 2026 年的中国市场里的工作，是把这个结构里的判断力、这种判断力带来的产品价值，留给客户、留在方法库里。它跟上一代实施岗位的差别，不在能力，在结构。

下一卷讲原则——把这种结构里的判断力边界、判断力归属、判断力代价写清楚，落到操作层面。