第 18 章 FDE 的下一步
合昇合同结束的第二天我没飞回总部，留在苏州又住了三天。
不是项目还有事——是我自己想停一下。从 Discovery 到 Handoff 整整十一个月，每周都在往前推某件具体的事，像跑一场没有中场休息的接力。合昇 GA 那天我在 Slack 上写了一句”项目稳了”，发完就关电脑，第二天醒来才意识到一个事：这一整年我没问过自己”我下一步要去哪里”。
苏州那三天我做的事很简单：把笔记本上这一年的 200 多条复盘条目重读了一遍，挑出 30 条现在仍然觉得对的。然后把这 30 条按”工程”和”行业”分了两栏。分完之后我看见两件事——工程那一栏 22 条，行业那一栏 8 条。这一年我以为自己在做”制造业海外服务的 LLM agent”，实际上 80% 的时间花在通用的工程能力上：评估集、灰度、IaC、handoff。剩下那 8 条才是真的”我在合昇这一年里学到的、换个客户带不走的东西”。
这一章是讲 FDE 后面几年怎么走的。前面 16 章假设你正在某一个项目里，从 Discovery 走到 Handoff；这一章假设你已经做了 5 个以上的项目，开始问自己一些不那么紧迫但很重要的问题——下一步去哪、要不要带团队、这本书写到的那些东西是不是 FDE 工作的全部。
如果你是 0-12 个月的 FDE，这一章可以先跳过——这一章讲的事在你做完前 3 个项目之前都用不上，提前读了反而会让你在第一个项目里分心。第一年的关键不是规划 5 年，是把第一个项目做完整。但你可以在第一年结束、做完两个项目准备进第三个时，回头看这一章。那时候这里写的东西会开始有共鸣。
也是这本书的最后一章。所以我会顺便讲一下这本书自己的局限——它没写到的、写错的、五年后大概率要重写的部分。
18.1 第 1-3 年的成长是非线性的
新人 FDE 第一年最大的错觉是”线性成长”——以为做完第 1 个项目能力涨 1，做完第 2 个再涨 1，三年下来涨 3。我自己第一年就是这么想的，结果第三个项目结束时发现自己几乎没比第一个项目结束时更强。
我后来观察过身边十几个 FDE，三年的成长曲线大致是这个形状：
FDE 三年成长曲线 (主观)
──────────────────────────────────────
能力
▲
│ ╱─── Year 3
│ ╱
│ ╱
│ ╱
│ ╱─── Year 2 后半
│ ╱
│ ╱
│ ─────────────────╱ ← 第一次"看见模式"的拐点
│ ╱
│ ╱──── Year 1
│
└──────────────────────────────────► 时间
项目 1 项目 2 项目 3 项目 4 项目 5
第一年是平的——你在学每个项目都需要的”基础能力”，AWS 控制台怎么点、Bedrock 怎么调、客户会怎么开、SOW 怎么读。这些东西每个项目都要用，但你做完第二个项目时这些能力已经长齐，第三个项目并不会让它们再涨。第一年我自己一度焦虑”我没在变强”——后来才明白，第一年是在长肌肉，肌肉长出来之前看不出形状。
拐点通常发生在第三或第四个项目。这个拐点不是某次顿悟，是第一次”看见模式”——你在新项目里突然意识到”等等，这件事我上一个项目也遇到过，是同一类问题”。Ch17 讲的模式提取在这里第一次产生复利：你做的不再是”第 N 个独立项目”，而是”在第 N 个客户身上验证我之前那套模板”。
我自己那个拐点是在合昇之前的项目，一家保险公司的核保 RAG。那次 Discovery 阶段我用的还是合昇这次同一份问卷的雏形，跑下来发现客户内部对”prompt”的理解和合昇一模一样——他们也把 KB 文档当成 prompt。两个看起来完全不同行业的客户，运营人员的心智模型是同一个。从那一刻起我开始相信”模式”这个词。
第二年的中后段你会经历一种特殊的疲惫感——不是身体累，是”我又要做一遍 Discovery 了”的厌倦感。这是好事。这种厌倦感意味着你开始能预判很多事，预判到的事就不再新鲜。FDE 的乐趣这时候从”解决问题”开始转到”看见自己在变成什么样的工程师”。如果你第二年仍然每次 Discovery 都觉得新鲜、每次 handoff 都不知道要做什么——你不是在成长，你是在重复”做第一次”。
这件事对一个 0-12 个月的 FDE 意味着什么？意味着你前两个项目不要太焦虑成长慢。这两个项目的产出不是你的能力曲线，是你后面所有项目的训练数据。第三个项目开始你能不能从训练数据里抽出模式，决定了你接下来五年长什么样。
如果做到第 5 个项目还看不见模式——每次都觉得”这个客户太特殊了”——那不是项目特殊，是你没在做模式提取。Ch17.7 那四个问题（哪些一样 / 哪些能省 / 哪些预警 / 哪些没追究）每个项目结束都问，三个项目下来一定能抽出东西。我观察过几个”做了 5 个项目还在原地”的 FDE，他们的共同特征不是技术差，是从来没在项目结束时停下来写过一次复盘——每个项目结束直接进下一个，热度还没退就被下一份 SOW 接管。这种节奏前两年看着勤奋，第三年开始你会发现自己被”勤奋”反噬了。
18.2 5 个项目之后的三个岔路
做满 5 个项目之后——大致对应入行 2.5 到 3 年——FDE 通常要做一个职业判断：下一步走哪条路。我观察到的常见岔路有三条。
第一条是留在前线，往 Staff / Principal FDE 走。同样的工作形态——驻在客户那边、做 Discovery 到 Handoff——但客户更复杂、单子更大、被分配去救火的概率高。我第三个项目结束时见过一个 Principal FDE 进场，他做的事和我一模一样，但他在 Discovery 第一天就识别出客户合规部门是项目隐形否决方，让我们提前两周接触合规——这个判断我做不出来，他做出来是因为他踩过类似的坑。Principal FDE 的稀缺性不在技术深度，在”看坑早 4 周”。这条路的瓶颈是行业纵深：如果你 5 个项目都换行业，到第 8 个项目你还是在”踩第一次见的坑”，没有积累。Principal 这条路本质上是把”踩坑速度”拉到一个临界值——快到客户花钱请你来主要不是写代码，是请你预判他自己想不到的风险。
合昇这次合同结束前的最后两周，公司另一个项目要救火，我被叫去做一次性的”两周诊断”。客户那边一个新人 FDE 已经做了三个月、Discovery 报告很厚但项目没动起来。我去之前看了一下他写的报告——很扎实，每个用例都列了，但没有”客户内部哪个角色实际会按这个用例工作”的描述。这是 Discovery 报告最容易塌的地方。
我去客户现场两天就识别出这个洞。这种判断我做不出来，是因为我自己写过同样塌的报告——第一年那次保险项目我就交过一份”用例完整但没有人”的 Discovery 报告。Principal FDE 的”看坑早 4 周”，本质就是”我在自己身上看过这个坑”。这条路的前提是你愿意把每个项目的失败写下来——你写过的失败越多，你能预判的客户的失败就越多。
第二条是做 FDE 团队 lead。从带 1-2 个新人开始，慢慢扩到带 5-10 个 FDE 的小组。这条路最容易的误判是把 lead 当成”更资深的 FDE”——以为自己继续做项目，顺便指导新人。实际不是。FDE lead 的核心工作变了三件：客户分配（哪个客户配哪个 FDE）、项目止损（哪些项目要早点叫停）、人员成长（每个 FDE 在哪个阶段、需要什么样的项目）。这三件事都和写代码无关，和”判断人和项目的匹配”有关。
我自己见过一个 FDE 转 lead 转得最痛的人，第一年还在抢着接项目——结果带的 5 个新人没人 review、没人 mentor、自己手上的项目也做不深。第二年他终于想清楚一件事：lead 的工作是把新人的项目变成新人自己的项目，不是把新人的项目接管过来自己做。这件事说起来简单，做起来违反 5 年工程师的肌肉记忆。
第二条路还有一个隐藏的判断：你愿不愿意接受”我从此不再是项目里那个最懂的人”。IC FDE 在客户那边永远是技术深度最够的那一个；FDE lead 的小组里，会有新人在某个 feature 上比你新、比你快——你的价值不再来自”我是最懂的人”，而来自”我能帮新人成为最懂的人”。如果你做工程的快乐主要来自”我比别人懂得多”，第二条路会让你不舒服。
第三条是切到 vendor side——也就是从”在客户那边交付”切到”在 AI 平台公司里做产品”。Anthropic、OpenAI、Bedrock 团队都招”前 FDE 出身的 PM 或 SE”。理由很直接：FDE 在客户那边踩了 5 个项目的坑，知道什么 feature 真有人用、什么文档真有人读。Bob McGrew 在 YC 的访谈里讲过，Palantir 的 FDE 流向 OpenAI 早期产品团队是一条相对成熟的路径——一个做过客户落地的人转去做产品 PM，比一个纯产品背景的人快 2 年看清”什么能落地”。
我自己没走过第三条，但身边走过的人有一个共同感受：vendor side 的工作满足感和 FDE 不一样。FDE 是”这个月把这个客户的事搞定”，做完看到客户上线、用上、好用。Vendor PM 是”这个 feature 半年后会被几千个 FDE 用上”，做完不一定能看到具体哪个客户因此而成功。前者是即时反馈，后者是延迟反馈。这件事不分好坏，但要选——选 vendor side 的人需要忍受这个延迟。
第三条还有一个隐藏的代价：你失去客户现场的真实接触。在 vendor side 待两年之后，你对”客户实际怎么工作”的感觉会开始变虚——不是因为你忘了，是因为客户也在变，你不在场。AWS 在 What’s New 上每个月发的几十条产品更新，是 FDE 在客户那边一条条踩出来的反馈反向喂回去的；如果你切到 vendor side 还想保持判断力，要主动找机会回客户现场——哪怕只是陪 FDE 出差两天、听一次完整的 Discovery 访谈，比在办公室开 50 个 PRD 评审都管用。
三条路没有”对的那条”。我自己当下选的是第一条+第二条混合（继续做项目，同时带 2 个新人），但这个选择是因为我现在还没厌倦客户现场。如果哪天我对”再做一次 Discovery 访谈”开始反胃，我会切第二条；如果哪天我开始觉得”这个 feature 应该长在 Bedrock 里而不是我手写”，我会考虑第三条。职业方向的判断标准不是哪条路更高级，是你现在最讨厌的那件事，未来五年还能不能忍。
还有一条我没单列但值得提一下：回去做纯工程的 IC——也就是不做 FDE 了，回到 SaaS 公司或大厂的产品工程部门，写代码、做技术、不再面对客户。这条路在 FDE 里不算少见，尤其是工作 3-4 年觉得”我不喜欢和人打交道”的同行。这件事没什么不好——FDE 不是工程师的”高级形态”，是工程师的”另一种形态”。如果你做 5 个项目之后发现自己一周里最快乐的那两小时是关掉 Slack 写代码的时候，你大概率不适合长期做 FDE。Lawrence 在 FDE Rule Book 里有一段说得直接：”Not everyone should be an FDE, and that’s a feature, not a bug.”——FDE 这个职业的稀缺性恰恰来自不是所有工程师都适合。
18.3 从 FDE 到 FDE manager 的具体落差
第二条路（lead 到 manager）是最多 FDE 走的，也是落差最大的。这一节单独展开。
第一个落差是时间分配从”项目时间”切到”非项目时间”。一个 IC FDE 一周 80% 时间在某个具体项目上：写代码、看 trace、开客户会、跑 eval。manager 一周 80% 时间在”管理动作”上：1:1、复盘、客户分配、人员评估、向上汇报。manager 第一年最大的痛苦是”这周我没产出任何代码”——不是真的没产出，是产出的形式从 commit 变成了”5 个 FDE 的 5 个项目都按时往前推”。这个产出在年终时算得清，但在某一个周二下午算不清。
第二个落差是判断对象从”客户”切到”FDE 自己”。IC FDE 的判断主要是”这个客户该做什么”——Discovery 透不透、技术选型对不对、handoff 准没准。manager 的判断主要是”哪个 FDE 适合哪个客户”——A 适合制造业不适合金融、B 在 Discovery 阶段强但 Handoff 阶段容易拖、C 是新人不能扔到客户决策层最高的那个项目里。这种判断需要的不是工程经验，是看人。一个工程很强但不会看人的 FDE 转 manager，前两年会反复犯同一个错——把项目交给”技术最强的那个 FDE”而不是”最适合这类客户的那个 FDE”。
第三个落差是不能再当救火队员。IC FDE 看到一个项目要翻车，第一反应是”我去帮一下”——上手写 prompt、和客户开会、修 IaC。manager 看到同样的情况，第一反应应该是”哪个 FDE 现在能去支援、要不要换人”。
manager 一旦自己冲下场，剩下 4 个项目就没人看了。这件事最反 FDE 的工程师本能——你眼前明明有一个能解决的问题，你的工作却是不去解决它，让别人解决。第一次主动忍住不冲下场是 manager 这条路真正的入门考。我见过转得好的人都说，第一次忍住的那一晚他们在办公室坐到 10 点，知道自己上手能 3 小时搞定的事让新人花 3 天——但他们没冲。从那一晚开始他们才算真的是 manager。
第四个落差是判断的反馈周期变长。IC FDE 的判断（这个 prompt 改了之后准确率会不会涨）通常一两小时就有反馈——跑一次 eval 就知道。manager 的判断（把 A 配给金融客户、B 留在制造业）反馈周期是 3-6 个月——你要等项目跑出结果才知道当时分配对不对。这个周期让 manager 第一年最难——你做了 10 个判断，9 月份还看不出哪个对哪个错。习惯了即时反馈的工程师在这种周期里很容易变得自我怀疑。manager 这条路要先在心理上接受”我现在做的判断要半年后才知道对不对”。
我自己合昇这次合同结束的最后一个月，公司开始跟我谈”明年要不要带一个三人小组”。当时我有点动心，最后没接——理由不是不想带人，是我意识到自己在 IC 阶段还有一件没做完的事：行业纵深还在 Level 1 到 Level 2 之间。如果这时候切到 manager，我后面带的新人会去做制造业项目，但我自己对这个行业的判断不到 Level 3，做项目分配时会判断不准。不是不能切，是切的时机要看你自己的能力曲线，不是看公司给的 offer 时机。这件事我没和很多人讲过，写在这里给同样面临这种判断的 FDE 一个参照。
我观察过的 FDE 转 manager 转得相对顺的人，有一个共同动作：他们在 IC 阶段最后半年就开始”刻意带新人”。不是被动 mentor，是主动找一个新人 pair 一整个项目，从 Discovery 到 Handoff 全程让新人主导、自己只在新人卡住时接话。这半年下来他们已经熟悉了”看着事情可以更快但不接管”的状态。manager 第一年的痛苦因此减半。
如果你现在是 IC FDE，正在考虑明年要不要走 manager 这条路——这件事不要等公司给你 offer 才开始练。你可以从下个项目开始就主动带一个新人，给自己一个低成本的预演。如果半年后你发现”看着别人慢慢做”对你来说是难以忍受的折磨，那你可能不适合 manager；如果你发现”看着新人长出来”比自己写出一个好 prompt 还有满足感，那你大概率会享受这条路。
18.4 行业纵深的 3 个层次（合昇是怎么从 Level 1 走到 Level 2 的）
讲完职业岔路，回到能力本身。前一节说”行业纵深决定 5 年后你长什么样”——这一节具体讲行业纵深长什么样。
行业纵深我观察下来分三个层次：
Level 1: 听得懂术语
──────────────────────────────
能跟客户内部的人无障碍对话, 不被术语挡在门外
例 (制造业海外服务): "派工 / 备件 / 工单 / SLA"
时间投入: 3-6 个月, 主要靠在客户现场泡
Level 2: 看得见业务流
──────────────────────────────
能画出客户的主要业务流, 知道每一步谁负责、卡点常在哪
能预判这个流程里哪些环节做 LLM 风险大、哪些低
例: 知道"派工自动化别一上来全自动, 先做 5% 高频低风险案例"
时间投入: 1-2 年, 通常做完同行业 2-3 个项目才到
Level 3: 有判断
──────────────────────────────
能告诉客户"这件事别做" + 给出他们没想过的角度
能在客户老板面前讲行业趋势, 客户开始把你当"自己人"
时间投入: 3-5 年, 同行业 5+ 项目
合昇这次我自己处于 Level 1 到 Level 2 之间。Level 1 我做到了——海外服务的”派工 / 备件 / SLA / 跨站点协调”这些词我能在会议室直接对话，陈雪不用解释。但 Level 2 我只到了一半——合昇这一个客户的业务流我画得清楚，但”制造业海外服务”作为一个行业的业务流共性我还没看到。要看到共性，至少需要再做 1-2 个同行业客户。
Level 3 是质变点。Level 3 的 FDE 不是”做项目的人”，是”客户的行业顾问”——客户老板请你吃饭不是为了讨论这个项目，是为了听你讲行业趋势。这个层次的 FDE 不靠简历找客户，是客户找上门。我见过一个做了 6 年保险 FDE 的人，他每年的项目里有一半是老客户主动来的”我们想再做下一期”，另一半是老客户介绍的”同业某某听说你了”。这个状态不是因为他技术强，是因为他在那个行业里已经积累出”这个人懂保险”的口碑——而口碑这件事，是技术能力没法替代的。
怎么从 Level 1 加深到 Level 2？合昇这一年我做的几件事，回头看是有效的：每月看一份合昇所在行业的公开材料（行业协会报告、上市公司年报、海外类似公司财报）；和合昇业务侧的”老师傅”陈雪定期吃饭，听她讲过去 10 年制造业海外服务怎么演化；每次项目复盘单独留一节叫”这次我对这个行业新理解了什么”。这些动作单看都不起眼，加起来一年下来我能在新加坡客户的董事会上讲”东南亚制造业海外服务的三个未来趋势”——讲完之后周明远说”小张你这段比我们自己 BD 讲得清楚”。那一刻我知道，我开始有了一点点行业感觉。
Nabeel Qureshi 在 Reflections on Palantir 里有一段讲得特别准：Palantir 那些做了 5 年以上的 FDE，最值钱的不是技术，是”客户给他们看自己 board 不愿意看的数字”——也就是客户认为他们已经是”自己人”。这个状态不是通过卖技术拿到的，是通过年复一年表现出”我懂你的行业、你的处境、你的难处”拿到的。Conikeec 的 FDE Playbook 里也有类似的描述，他用的词是”earn the right to disagree”——你要在客户那边先证明你懂这个行业，客户才愿意听你说”这件事别这么做”。这两段话单看是抽象的，做满 5 个项目之后回头看就具体了：客户开始让你看那些他们以前不让你看的东西，你就到了 Level 3 的入口。
如果你现在 0-12 个月，行业是不是要”立刻定下来”？我的判断是不要急。第一个项目你大概率不知道自己喜不喜欢这个行业。让自己第一年里同时接 2 个不同行业的项目，做完之后比较哪一个让你更想多读它的资料、多和客户业务方聊——那个让你”主动想多了解”的就是值得纵深的方向。如果两个行业你都不愿意主动多了解，那就再等一年。行业选择不是入职第一周的决定，是入行第二年的决定。
行业纵深还有一个隐藏好处，是它让你免疫”AI 工具替代焦虑”。
2025-2026 这两年 FDE 圈里反复有人焦虑——Cursor / Copilot / Claude Code 一代比一代强，是不是 FDE 这个职业要被替代了。我自己的判断是反过来的：通用工程能力（写代码、调 API、搭脚手架）确实在被 AI 工具压缩，但“客户对 LLM 的不信任”和”行业的脏数据 / 合规边界”这两件事 AI 工具替代不了——前者需要在客户那边站半年才能拿到的信任，后者需要 5 年行业经验才能拿到的判断。
一个 Level 3 的金融 FDE 不会被 AI 工具替代，因为他卖的不是”能写代码”，是”金融业的判断”。一个只会通用工程的 FDE 才会焦虑——因为他能做的事 AI 工具确实越来越能做。这件事的对策不是”焦虑了就去学新工具”，是”早点选行业、早点深下去”。AI 工具变得多强，”客户老板请你吃饭听你讲行业趋势”这件事它都做不到。
18.5 5+ 项目之后一周长什么样
第三个 5 年是什么样的，我自己也没走完，没法写。但 5+ 项目之后的 FDE 一周长什么样，我可以基于自己当下的状态写一下——这给 0-12 个月的你一个”未来三年的我”的具体形状。
合昇之后我现在一周大概是这样：
当前 (5+ 项目 FDE) 一周构成
─────────────────────────────────────
- 主项目 (新签客户, 在 Discovery 阶段) : 50%
客户访谈 / 工位 shadowing / 评估集 v0
- 老客户 on-call (合昇 8 周保修期): 10%
Slack 答疑 + 一次电话答疑 + 一次小修改
- 内部 mentor (带 1 个新人 FDE): 15%
1:1, 复盘, 帮新人看 Discovery 报告
- 模式提取 + 内部 wiki 维护: 10%
把上一个项目的产物加工成下个项目能复用的模板
- 外部社区 + 行业感觉: 10%
读行业资料, 偶尔写一两篇 blog, 同行交流
- 自我学习 (新 LLM / 新 AWS feature): 5%
不是为了项目, 是为了知道下一代 FDE 该会什么
这个比例和第一年完全不同。第一年我 90% 时间在主项目上，剩下 10% 在补基础。5+ 项目之后主项目时间反而下降到 50%——不是因为不重视项目，是因为后半段时间被”老客户 + 新人 + 模式提取”挤进来。这三件事在第一年都不存在，但每一件都在 5+ 之后变成”不做不行”的工作。
老客户 on-call 的 10% 看起来不多，但它的”心智占用”比时间占比高。一个老客户 P2 故障的 Slack 消息可以打断主项目 Discovery 的连续思考。所以这 10% 的实际感受更像是”主项目里时不时被打断”。我学的方法是把 on-call 的响应窗口集中在每天上午 10-11 和下午 4-5 各一个钟头，其他时间不看 Slack——除非 P1。这件事不算完美但比一直被打断好。
新人 mentor 的 15% 是回报最非线性的——前三个月你看不出收益（新人还在学），第六个月开始你能感觉到自己的判断力被新人的提问”反刍”了一遍。新人问”为什么 Discovery 阶段必须做 shadowing”，你被迫把那个原因讲清楚——讲清楚之后你自己对这件事的理解也深了一层。带新人不是单向输出，是双向打磨。这件事是 Conikeec 在 FDE Playbook 里专门写过的——他原话是”the FDE who mentors learns more than the FDE who is mentored”。我做合昇之前不太信这句话，做完合昇之后我开始信了。
如果你现在是 0-12 个月，看到这个分布的反应应该是”哦，原来三年后的我会这样”——不是”我现在就要照这样做”。第一年还是把 90% 时间放主项目上，那是你长基础的窗口。3 年后回头看这个分布，如果你的工作时间还是 90% 在单一主项目上，那你大概率没有把 Ch17 的模式提取做实——那 30% 的”非主项目时间”消失了。
18.6 这本书没写到的 5 件事
这是这本书的最后一章，也是合适的位置讲一下它的局限。
第一，本书几乎没写多模态。我自己做的项目里多模态占比少（合昇一期二期都是纯文本），所以这本书的所有方法论——Discovery、评估集、agent 编排、Handoff——都是文本场景里跑出来的。如果你的项目是图像/视频/音频为主（医疗影像、工业质检、内容审核），这本书里的工程心法仍然适用，但具体技术选型那部分（Ch6/7/8）需要换一套。多模态的评估集怎么标、agent 怎么编排、灰度怎么做，是另一本书的内容。
第二，本书的客户都是中型企业。合昇是合成案例，但它代表的客户画像——年营收几亿到几十亿、IT 部门 50-200 人、有自己的 AWS 账号但没有专门的 AI 团队——是我做过的项目里的多数。这本书里 Ch9-Ch13 那一套（数据 / 网络 / 身份 / 审计 / 部署）默认了”客户有自己的 IT 但没有专业的 ML/AI 团队”。如果你的客户是大厂（有自己的 AI infra 团队，自己做 model serving，要求开源 + 私有化），或者是小客户（5 个人的初创，根本没有 IT），这本书里的工程动作要做相当幅度的调整。
第三，本书几乎不讲合规细节。合规这件事我在 Ch10 提了一下身份和审计，但没展开讲 GDPR、等保、HIPAA、SOC2 这些具体框架。理由是合规细节随地区和行业变化太快——新加坡 PDPA 和欧盟 GDPR 的差异、医疗 HIPAA 在 LLM 应用上的具体落法、中国等保 2.0 三级在生成式 AI 上的新解释——每一项都需要单独的章节，且半年就要重写一次。
如果你的客户在合规重的行业（金融/医疗/政企），这本书是基线，不是终点。合规这一块的最佳学习方式是和客户的法务/风控部门同事直接坐下来聊一下午，比读 100 页规范文件更有效。AWS 自己也在 What’s New 上不定期发布合规相关的能力（比如 Bedrock Guardrails、CloudTrail Lake 的合规审计场景）——这些公开材料是合规起点，但永远只是起点。
第四，本书的 AWS 是 demo 平台。这本书所有动手部分用 Bedrock + AgentCore + IAM 演示，但 FDE 工作的核心心法不绑 AWS——Discovery、评估集、handoff、模式提取这些动作在任何云、任何 LLM 平台上都成立。
如果你在 Azure 或 GCP 上做 FDE，把书里的 Bedrock 换成 Azure OpenAI 或 Vertex AI、把 IAM 换成 Entra ID 或 GCP IAM，文中的判断逻辑不变。AWS 在这本书里出现是因为我做合昇时它就是合昇的云——不代表 AWS 是 FDE 的最优选。书里没有任何”AWS 比 X 强”的对比，是因为这本书的目的是教 FDE 工作流，不是做平台选型。平台选型这件事 FDE 在客户那边自己去做，参考客户已有的云栈、合规要求、商务关系——这些都和这本书无关。
第五，本书写于 2025-2026 年的技术栈。这一点最重要也最容易被忽略。本书里的具体技术——Bedrock Agent、AgentCore、stateful MCP、Claude 4.5 / 4.6——是 2026 年初 AWS 那一代的产品形态。三年后这些产品的名字和形态都会变。但FDE 这个职业的工作形状不会变——客户会不会用 LLM、会不会接 agent、会不会做 RAG，这些细节会变；但客户内部”业务方说不清楚要什么”、”IT 不懂业务”、”上线后 3 个月没人维护”这些问题，是企业组织的固有形态，AI 技术换三代也仍然在那里。这本书里讲技术栈的章节五年后会重写，讲方法论的章节五年后大概率仍然成立。
写完这五条我自己也想了想——书的局限其实不止这五个。还有一个我犹豫要不要写：本书几乎只讲了一个文化下的 FDE 工作流——客户在中国、新加坡、东南亚的中型企业，会议讲中文 + 偶尔英文，决策风格偏共识。如果你的客户在欧美（决策偏直接，”no” 说出口比这边干脆），或者在日本（决策周期长得多，需要逐层 nemawashi），这本书里的 Discovery 时长、handoff 节奏、客户对话风格都要做相当的本地化调整。这一块我没把握写好，留给将来文化背景更不一样的 FDE 同行去补。
18.7 给现在的你
这一节本来想写”给入门 FDE 的 N 条建议”，写到一半删了——那种清单式的建议读完没用，只是看着像有用。
我把它收成一段话。
如果你现在是 0-12 个月的 FDE，这本书 16 章讲的所有方法论都是”做事的方法”，不是”做人的方法”。FDE 这份工作里”做人的方法”我没法用书写出来，但有一件事可以告诉你：你前 5 个项目最大的产出不是给客户的代码，是给自己的笔记本。每个项目结束写下”这次我学到了什么” —— 不是写给公司 wiki 看的、不是写给老板看的、是写给三年后的自己看的。三年后你回头读这些笔记，你会知道你成为了一个怎样的 FDE，比简历更准。
合昇这一整年我写了 200 多条这样的笔记。这本书 16 章是从那些笔记里挑出来重写的部分。你现在读到的所有判断、所有反模式、所有”我之前踩过这个坑”，都来自那些笔记。这本书本身就是模式提取的产物——只不过提取的对象是我自己 5 年的项目，不是某一个客户。
如果你能坚持写笔记 5 年，到时候你会有自己的那本书。它里面的判断会和我这本不一样——不一样才对，因为你做的项目和我做的不一样、客户不一样、行业不一样、那时候的 LLM 也不一样。
但写法应该是一样的：第一人称、连贯叙事、具体到客户名字和决策点、不写鸡汤、不写”我应该如何如何”——只写”这次我做了什么、对了什么、错了什么、下次怎么办”。这种写法的核心不是文学技巧，是对自己和对读者的诚实——你写的每一句都对应你真实做过的某件事、踩过的某个坑、改过的某个判断。
我自己第一年就开始写笔记，那时候写的东西现在回看大半都很尴尬——很多判断写得绝对、很多观察事后看是错的。但那些尴尬的笔记是我现在判断力的根。如果当时我没写下来，第二年第三年我就没有可以否定的对象——人不能否定自己脑子里没有具体形状的东西。把判断落到纸上，是它后面能被修正的前提。
合昇这本书写完之后，我打算继续写第二本。第二本的题目是”FDE 在客户决策层的对话”——这本书里讲的是工程动作，那本书想讲跟客户老板、跟客户合规、跟客户业务负责人怎么对话。这件事是我从合昇这一年里学到但没法塞进现在这 17 章的——它是一个独立的议题。如果你三年后愿意写自己的那本书，你会发现 FDE 这个职业里值得单独写一本的议题至少有五个：技术、对话、合规、商务、团队。这本书只覆盖了第一个。
写完合昇这一年的故事，我再翻这本书的目录，会觉得它像一份”我自己的 FDE 工作流的快照”——快照里的某些判断三年后我自己会不同意，某些反模式三年后会有更精炼的写法，某些章节五年后整章删掉重写。这是我希望的状态。一本 2026 年的 FDE 书在 2030 年还原封不动，那不是它写得好，是这个领域停滞了。我希望你三年后回来读这本书时，能在某些段落旁边批注”这一段已经过时了”——那是这本书完成它使命的方式。
到那时候这本书可以扔了。
这一年里我做的所有判断、写的所有反模式、踩过的所有坑——希望它们在你五年后那本书里被超越、被改写、被否定。
本章引用的公开资料
- A. Lawrence, Forward Deployed Engineer Rule Book (2025) — Principal FDE 的”看坑早 4 周”提法借鉴
- Conikeec, The FDE Playbook: A Practitioner’s Field Manual (2025, Substack) — 模式提取与第三个项目拐点的描述
- Bob McGrew @ Y Combinator (2025) — FDE 转 vendor side 的路径访谈
- Nabeel Qureshi, Reflections on Palantir — Palantir FDE 文化中”行业感觉”的来源
- AWS What’s New (2026) — Bedrock / AgentCore / cross-region inference profile 等本书技术栈对应的公开发布材料
完整书目和链接见全书末尾的 参考文献。