一份优秀的前沿部署工程师作品集应包含两到三个项目，每个项目都基于杂乱、真实的数据构建，并附带一份决策日志：你选择了什么、拒绝了什么、谁接受了风险、以及你交还了什么。一个演示只能证明代码运行过一次。而决策日志展示的是当客户的约束条件与你相冲突时你如何推理——而这正是这份工作的大部分内容。
核心要点
- 哪三个前沿部署工程师作品集项目能体现部署判断力，而非模型调优。
- 如何撰写简短的决策记录，让招聘工程师几分钟内就能读完。
- 如何证明交还环节，让每个项目都能证明没有你也能运行。
为什么决策日志胜过演示
演示只回答一个问题：你能把东西做出来吗？而这个岗位问的是另一个问题。根据 Pragmatic Engineer，Palantir 将其前沿部署工程师描述为肩负为客户实现技术成果的使命，并以对客户目标的影响来衡量成功。成果取决于在约束条件下做出的选择，而一个可运行原型的录像恰恰掩盖了这些选择。
First Round Review 强调，与解决方案顾问或售前工程师不同，FDE 仍然是一名编写和调试生产代码的工程师。因此作品集需要真实的代码。但同一篇文章引用了一位 Palantir 前员工的话，她说这个角色已经偏向实现工作，偏离了其初衷。仅靠配置并不能造就一名前沿部署工程师。对做什么、不做什么的判断才能。
需求使这一点变得重要。根据 Deep Engineering，在 Business Insider 报道的 Indeed 指数上，2026 年 4 月前沿部署工程师的职位发布数量比一年前高出约 729%，尽管这只涵盖了一个招聘网站而非整个市场。需求上升带来申请增多，审阅者很可能会多次看到同样的检索演示。而一份带有日期的艰难权衡记录则很难造假。
Perspective AI 对约 1000 个职位发布的分析发现，超过 70% 的职位列出了需求挖掘技能，如需求发现和干系人管理。决策记录正是这些技能在纸面上变得可见的地方。
值得构建的三个项目
选择覆盖部署不同阶段的项目，而不是同一个聊天机器人的三个变体。以下每个项目都可以基于公开数据、合成数据，或在获得书面许可后，为一家愿意配合的小型组织的真实工作流构建。
- 一份需求发现与范围界定文档包。 选择一个模糊的业务问题，例如发票分类或支持工单路由，并访谈负责该问题的人。产出访谈笔记、一份带有明确排除项的范围声明，以及针对每个范围界定选择的决策记录。这里的代码可以很薄。推理过程才是核心产出。
- 一个带评测集的已部署系统。 构建一个能针对真实输入运行的东西，评测集取自真实案例，并附有书面记录说明它在哪些地方失败了，以及一份系统不会做的事情清单。把它部署到陌生人也能访问的地方，而不只是你自己的笔记本电脑上。
- 一套交接包。 把第二个项目做成别人可以接手运营的东西：运行手册、监控、访问安排，以及一份没有你在场时由谁运行它的记录。Betts Recruiting 报告称，AWS 的前沿部署组织围绕派驻工程师来部署 Agent 并让客户能够独立运行而构建。这就是需要证明的行为。
两个认真完成的项目胜过五个半途而废的项目。如果时间不够，可以把第二和第三个合并。
如何撰写决策日志
借用架构决策记录，这是软件团队已经在使用的一种格式。Martin Fowler 的 bliki 将其描述为一份简短的文档，用于记录单个决策，最多几页，包含决策本身、其背景及其重大影响。它还建议列出曾认真考虑过的备选方案及其优缺点。
并非每个选择都值得记录。Safeguard 建议在决策难以逆转、影响多个团队或决定风险形态时才撰写记录，并警告说，充满琐碎内容的日志没人会读。对于一次部署，值得记录的内容包括：摄取哪些数据、如何评测、系统拒绝做什么、如何处理个人数据，以及在哪些环节保留人工介入。
一个可用的模板，用纯 Markdown 存放在代码旁边：
- 标题、日期和状态（提议、已接受、已被取代）。
- 背景：迫使做出这一选择的客户约束。
- 考虑过的选项，以及每个选项被否决的原因。
- 决策以及你接受的权衡。
- 置信度，以及什么会改变你的想法。
- 复审触发条件，以及接受该风险的人。
Microsoft Learn 建议记录决策的置信度，因为低置信度的判断值得标记出来以便日后重新考虑。一位写下“中等置信度，样本来自单一供应商”的候选人，听起来像是曾经吃过亏的人。
永远不要改写历史。Fowler 建议将已接受的记录链接到取代它的决策，而不是直接编辑它，这样能留下清晰的日志，显示每个决策在多长时间内指导着工作。被取代的条目正是项目与现实相遇的证据。Safeguard 还建议在工作之前或期间撰写记录，而不是事后。事后补写的日志读起来就像事后补写的。
对于任何涉及风险责任归属的记录，请应用签名测试：
上线之前，谁在风险声明上签字？
如果答案是“没有人”，那么这份记录就发现了一个值得在读者看到之前修复的缺口。
展示交接与衡量指标
许多作品集止步于构建。而部署不止于此。每个项目还应留下构建前后各阶段的痕迹。
AIU 将部署生命周期分为七个阶段进行教学：售后交接、需求探索、范围界定、构建、部署、迭代和交还。
最后一个阶段正是作品集常常跳过的。交还意味着客户的团队拥有该系统：他们能够运行它、修改它并解释它。一项检验方式是交接演练：
由客户团队执行五项任务，部署工程师在旁观察。
将结果记录在日志中，包括客户团队做错的地方。一次完美无缺的演练，反而不如一次暴露出缺失运维手册步骤的演练更可信。
当每个项目都能对应到岗位的考核指标时，作品集也更容易被读懂。
AIU 教授的内容是：前沿部署工程师的考核基于三个方面：部署速度、客户成功和产品反馈质量。
带日期的记录能让评审者看到你从范围界定到首次部署花了多长时间。一条简短的“产品反馈”记录，写明你会对底层工具做出哪些改进，即可覆盖第三项考核指标。The Pragmatic Engineer 指出，FDE 也会为核心产品做出贡献，在客户需要某项缺失功能时为其添加特性。把反馈连同证据写下来，正是这一习惯的小型版本。
打包呈现，让评审者愿意读
将每个项目放入独立的代码仓库，README 开头写明问题、结果以及指向决策日志的链接。把日志保存在仓库中，使其像代码一样经过评审。附上简短的架构图、评测结果和交还材料包。评审者不会翻看十页内容，所以要让第一屏就承载你的核心论点。
不要包含任何机密内容。在复用雇主的工作成果之前先检查你的合同，有疑虑时使用合成数据或公开数据。针对以上所有内容的结构化训练，正是 Certified Forward Deployed Engineer (CFDE)™ 的用武之地。
如果你想在一条有引导的路径上完成这些项目，AIU 在下方说明了如何开始。
常见问题
前沿部署工程师的作品集应包含多少个项目？+
两到三个就足够了。覆盖不同阶段：一份需求探索与范围界定材料包、一个带评测集的已部署系统，以及一份证明他人能够运行该系统的交还材料包。深度和真实的记录比数量更重要。
前沿部署工程师作品集中的决策日志是什么？+
决策日志是一组带编号的简短记录，每条记录捕捉一个决策及其背景、被否决的选项、所接受的权衡、你的置信度以及接受风险的人。当某个决策发生变更时，新记录会取代旧记录，从而让历史保持可见。
我可以把客户的工作放进作品集吗？+
仅在获得书面许可且删除机密数据、姓名和凭证之后。请先查看你的雇佣合同。如果无法获得许可，就用公开数据或合成数据重建该问题，并记录相同的决策过程。