这篇解决 FDE 从业者最实际的困境：最能证明能力的工作被保密覆盖，怎么向陌生人证明自己交付过。
最值得拿走的是三层结构与五步脱敏框架的组合：案例叙事回答做成过什么、可验证工件回答是不是真的、复盘沉淀回答提炼出了什么；脱敏框架用换行业、变形数值、抽象技术栈、剥离细节、双人自检五步，把案例写到合规且可信。最容易误用的地方是把作品集写成职责描述，或放一个经不起两轮追问的大案例。
相比面向软件工程师的作品集经验，这篇的增量在于承认 FDE 的作品天然是过程与判断而非代码，并区分了求职版与晋升版的叙述重心——前者讲我怎么解决，后者讲方法被谁复用、改变了团队的什么默认做法。
读完先做一件事：挑一个记忆最清晰的项目，按三层结构和五步脱敏框架写出第一个案例，并顺手标注它未来在求职与晋升两个场景里各自的用法。
—— FDEChina编辑部 · 实战派
FDE（Forward Deployed Engineer，前置部署工程师/前向部署工程师）的求职者和晋升答辩人面对同一个尴尬：最能证明你能力的东西——客户现场的问题、方案、代价与结果——恰恰是被保密协议覆盖最严的部分。代码不能公开、数据不能外带、客户名字不能提，于是很多人干脆交白卷，只留简历上一段职责描述。这篇给出一个在保密约束下依然可执行的方法：用案例叙事、可验证工件、复盘沉淀的三层结构搭作品集，用脱敏框架改写案例，用开源与 side project 补齐证据链，并把同一份作品集用透在求职与晋升两个场景。正在准备面试的读者，可配合FDE 面试完全准备一起使用。
为什么 FDE 不能只靠 GitHub 证明自己
开源贡献和代码主页能证明工程能力，证明不了交付能力。FDE 的核心价值发生在客户环境里：在没有完整信息的情况下澄清需求、在硬约束下取舍方案、在资源不足时把项目推过终点。这些过程几乎没有一行代码能直接展示——决定性的工作可能是三场需求访谈、一次范围收缩的谈判、一份把风险讲清楚的周报。换句话说，FDE 的作品天然是「过程与判断」，而不是「可运行的产物」，这决定了它的作品集必须用与工程师不同的结构来组织。
另一个现实约束是保密。国内 toB 项目里，保密协议、数据合规与行业监管几乎必然覆盖你的日常工作。但这不意味着无解——保密限制的是客户可识别信息与具体数据，并不限制你处理问题的方法、决策的框架和可复用的工件。作品集的全部技巧，就在于把「发生了什么」改写成「这类问题怎么解」，后者既是合规的，也是面试官和晋升评委真正想看的。
作品集的三层结构：案例叙事、可验证工件、复盘沉淀
第一层是案例叙事，回答「你做成过什么」。每个案例是一篇叙事文，按固定骨架写：背景与约束、你的角色、关键决策点、结果与代价。关键决策点是灵魂——面试官想看的是你在信息不全时怎么权衡，而不是最终方案长什么样。一个案例至少要有一段「当时有两个选项、你选了其中一个并说清理由」的决策描述，否则它只是一份项目说明书。一个可用的叙事骨架是：两句话交代客户背景与约束；两三句话交代你的角色与目标；两到三段写关键决策点，每段按「当时面对什么、有哪些选项、我基于什么判断选了哪个、事后看对不对」展开；最后一段写结果与代价，包括你没能解决的问题。案例数量不必多，三个讲透的胜过十个带过的。
第二层是可验证工件，回答「你说的是真的」。工件是案例的物证，也是脱敏最考验技巧的部分：评测集的结构与样例（用合成数据替换真实数据）、周报与问题清单的模板加一页脱敏样例、架构图的骨架版（隐去客户业务模块，保留结构关系）、你写的排障手册或上手文档的目录与选段。工件不必多，每个案例配一到两件即可，但件件要经得起追问——放进去的每样东西，你都要能在五分钟内讲清它为什么长这样。
第三层是复盘沉淀，回答「你从经验里提炼出了什么可复用的东西」。这一层最容易被忽略，却最能区分资深与初级：初级 FDE 的作品集止于案例，资深 FDE 会把多个案例里的共性提炼成方法——一套评测集的建设流程、一类问题的排查清单、一种需求澄清的提问框架。复盘沉淀同时是你的面试弹药库：面试官问「如果重来一次」，你的答案应该早已写在第三层里，而不是现场现编。
三层之间还要有明确的对应关系：每个案例至少挂一件工件，每件工件至少支撑一个决策点，复盘沉淀至少引用两个案例作为证据。这样组织之后，作品集会形成一个闭环——评审者从任何一个点进去，都能顺着链条看到完整的证据，而不是三份互相孤立的清单。检查闭环的方法很简单：随机挑一个结论，看你能不能在三步之内走到支撑它的原始记录；走不到，说明链条断了。
保密约束下的案例写法：一个脱敏框架
给一个可以直接套用的五步脱敏框架。第一步，换行业不改结构：把客户写成「某华南区域的连锁零售企业」「一家股份制银行的数据部门」，行业粒度足以让叙事可信，又不指向具体主体。第二步，变形数值：所有性能数字、规模数字按比例缩放或改写为区间，保留量级关系——数字的意义在于展示你处理问题的尺度感，精确值没有价值。第三步，抽象技术栈：把专有组件替换为通用描述，例如「自研网关」可以写成「客户侧统一接入层」，结构关系不变。第四步，剥离可识别细节：去掉人名、时间线里的敏感节点、独有的业务规则。第五步，自检：把改写后的案例交给一个不在该项目上的同行，问两个问题——能不能看懂、能不能猜到客户是谁。第一个答案必须是能，第二个必须是不能。
两条纪律要提前说清。第一，动手改写前先回看保密协议的条款范围，有疑义时问公司法务或合规，不要自己裁量；入职前作品集里来自前雇主的素材，同样适用这条。第二，脱敏的底线是「不损害、不猜测」：不写任何可能让内行人推断出客户并对其造成影响的内容，不写你没有把握的事实。宁可写得抽象一点，也不要为了故事性冒险——案例少一个没关系，职业信用受损没有第二次机会。
用开源与 side project 补充证据链
案例叙事证明你「做成过事」，开源与 side project 证明你「持续在做」。对保密约束重、可写案例少的人，这一层尤其重要。方向选择要有针对性：不是再做一个练手应用，而是补你案例里缺的证据。案例展示了集成能力，side project 可以做一套连接器或开发工具包；案例展示了评测方法，可以开源一个轻量的评测脚手架；案例展示了对某类场景的理解，可以写系列拆解文章。核心原则是让公开物与你的 FDE 定位互相印证，而不是各说各话。
质量与维护比数量重要。一个有文档、有评测、有迭代记录的项目，胜过五个半成品；持续的提交记录和版本演进，本身就是「交付纪律」的公开证据。如果时间有限，优先做两件事：把项目的自述文档写到「陌生人十五分钟能跑起来」的标准——这恰恰是 FDE 交付文档能力的直接展示；再补一份设计取舍说明，讲清你为什么这么做、放弃了什么，这与案例叙事的写法一脉相承。
如果没有合适的 side project 方向，可以从「把自己项目里被反复问过的问题」入手：把交付中回答过多次的使用问题、部署问题整理成一篇公开的问答或入门指引。这既不涉及客户信息，又直接体现你把隐性知识写成可传播文档的能力——这项能力在 FDE 日常里占的比重，比很多求职者以为的要大。先用这类轻量公开物起步，再逐步演进成有维护节奏的项目，比一上来就规划大工程更容易坚持。
同一份作品集的两个场景：求职与晋升
求职场景里，作品集的用法是「主动展示而非被动提交」。简历上放一行指引，面试中按环节调用：系统设计环节遇到类似约束，直接引用案例里你做过的取舍；行为面试讲冲突故事，案例就是故事的详版。面试后附上脱敏作品集，给未参与面试的决策者补证据。一个实用技巧是按目标岗位定制重点：面向 AI 应用类岗位，把评测与效果调优的案例放前面；面向传统 toB 岗位，把集成与落地案例放前面。岗位考察方向的差异，见FDE 面试完全准备一文。
晋升场景里，作品集的价值换了坐标：评委不看你的讲故事能力，看你的影响半径。同样的案例，求职版强调「我怎么解决的」，晋升版要强调「这套方法被谁复用了、减少了多少返工、改变了团队的什么默认做法」。所以作品集要为两个场景各留一个版本：案例叙事层基本共用，复盘沉淀层的写法完全不同。晋升答辩前，建议把第三层重新整理一遍，把「个人经验」改写成「团队资产」的叙述。
两个场景还有材料形态的区别。求职版要控制篇幅，最好是一份十到十五分钟能读完的文档或页面，重点前置——面试官停留在每份材料上的时间很短，结论必须第一屏可见；晋升版可以更完整，附上方法沉淀的全文与复用记录，因为评委有正式的审阅流程，深度直接影响评级。两版共用同一个素材库，各自组装，维护成本才可控。
维护节奏上，建议每季度花半天做一次增量：把本季度值得写的案例按脱敏框架过一遍、更新工件、补充复盘。平时则依赖最朴素的积累习惯——交付过程中随手留下记录，这恰好是FDE 职业路径地图里入门段就该养成的习惯。等到要用时再回溯半年前的细节，几乎必然失真。
常见误区与自查清单
收尾前列几个高频误区。一是写成职责描述：「负责客户需求对接与系统交付」这类句子没有信息量，作品集的每个句子都应该带判断或结果。二是案例切得太大：用一篇叙事覆盖一年的项目，注定讲不透；切决策点最密集的三个月，比覆盖全年更有力。三是只放成功：一次严重的返工配上有质量的复盘，常常比顺利案例更能建立信任，因为评审者都清楚现场不会一帆风顺。四是工件喧宾夺主：几十页的文档截图，不如一页讲清取舍的摘录。
- 每个案例是否都有至少一个两难决策点，并写清取舍理由？
- 是否按五步脱敏框架自检过，外人能否猜到客户？
- 每件工件是否经得起五分钟追问？
- 复盘沉淀里有没有至少一项被他人复用过的方法？
- 求职版与晋升版是否分开维护，叙述重心是否不同？
- side project 是否与你的 FDE 定位互相印证，而非孤立存在？
六个问题里有三个答不上，说明作品集还没到能用的状态，先补齐再谈展示。
小结与下一步
这篇的方法可以收拢为一句话：作品集的目标不是晒代码，是让陌生人相信你能在约束下把客户的难题推进到结果。三层结构解决「写什么」，脱敏框架解决「能不能写」，开源与 side project 解决「证据不够怎么办」，求职与晋升双版本解决「给谁看」。
下一步建议：先挑一个你记忆最清晰的项目，按三层结构和脱敏框架写出第一个案例，完成比完美重要；然后规划一个与定位互补的 side project 或开源贡献；求职者把作品集嵌入面试准备流程，见FDE 面试完全准备；在职者把季度维护写进日程；更系统的能力与路径讨论，见FDE 能力模型与工程师转型 FDE 的四条路径，也可以从FDE 知识指南进入站内导航。