# 两句话，让 FDE 招聘方相信你真正交付过

> 招聘方要看部署在别人基础设施上的代码，罗列工具说明不了，系统、约束和实测结果才能。

原文: https://fdetimes.net/zh/guides/fde-project-description-production-not-demo/

申请表上有个小框，写着“描述一个有代表性的项目”。你填上“使用 Python 和 React 开发了一个应用”，觉得太单薄，又加了几个技术名词，然后点了提交。对于前线部署工程师（FDE）岗位，这句话几乎没有告诉招聘方任何他们想看的东西。

你的项目也许很出色，但这句话体现不出来。FDE Academy 在面向 FDE 的简历指南中指出，审阅者要找的是你负责过部署、习惯从业务结果出发思考的证据，而不只是技术广度。

它给出的“优秀”例句，开头就是把一个分类模型接入客户的生产工作流。

对 FDE 来说，含糊的代价更高。Paraform 在招聘首位 FDE 的指南中建议雇主直接问候选人：你在客户的基础设施上部署过哪些代码？你的两句话要在对方开口之前回答这个问题。

这项技能用途很广：简历里、申请表的描述框里、发给招聘方的消息里，还有面试官说“讲讲你做过的一个项目”时你说出的第一句话。

## 同一个项目，三种写法

设想一个虚构项目，数字也是虚构的。你在一家物流公司工作，仓储团队依赖另一家供应商开发的老旧企业资源计划（ERP）系统，没有任何 API 文档。

你写了一个服务，从数据库副本读取库存数据，加上 API 和看板，在 IT 团队完成安全审批后，部署到公司的本地服务器上。

版本 0，很多人至今还这么写：“使用 Python 和 React 开发了一个库存应用。”有工具，没有用户、没有约束、没有结果。

版本 1 套用 Careerflow 推荐的公式：动作 + 任务 + 工具/方法 + 指标 + 结果/范围。新句子是：“使用 Python 和 React 开发库存看板，报表准备时间从 2 天缩短到 15 分钟。”

应聘软件工程师（SWE）岗位，这样已经够好。但对 FDE 岗位，它恰恰缺了读者最想知道的：谁的系统、难在哪里、谁在用。

版本 2，为 FDE 岗位而写：

“构建库存服务和看板，直接读取供应商的老旧 ERP（没有 API 文档，只有一个数据库副本），通过 IT 团队安全审查后部署到本地服务器。6 个仓库的 40 名主管每天使用；库存报表时间从 2 天缩短到 15 分钟。”

简历上可以用更紧凑的版本：“基于供应商无文档的老旧 ERP，通过只读副本构建库存服务和看板；通过 IT 安全审查后本地部署。6 个仓库的 40 名主管每天使用；报表时间从 2 天缩短到 15 分钟。”

**要点:** 好的两句话，要证明你做的东西已经在别人的系统里跑起来了。

## 版本 2 的每个短语都对应职位描述里的一行

“供应商的老旧 ERP，没有文档”对应 Valletta Software 的 FDE 职位描述样例中的一项要求：候选人曾在一个自己没有设计、也无法完全看清的系统里做出有用的东西。

“本地部署，通过安全审查”对应这份职位描述对工作的定位：部署进客户的基础设施，满足对方的安全要求，而不是在自己掌控的沙箱里运行。

“服务、API、看板、部署”说明你跨越了多个层次。Aced 的 Palantir FDE 面试指南把这个岗位描述为端到端负责产品，从界定问题、处理数据一直到前端。

“6 个仓库的 40 名主管每天使用”一举两得。它填上了 Careerflow 公式里的“范围”一项，也证明项目运行在生产环境中，而这正是 Valletta 职位描述样例明确写出的：你要对生产环境负责，而不是对演示负责。

“从 2 天到 15 分钟”沿用自版本 1。这是最容易读懂的一类影响：UT Austin Career Services 举过一个例子，一句话写明为 10 多个团队把数据管道构建时间从数周缩短到数天，既体现节省的时间，也体现规模。

## 五步改写你自己的项目

第一步：写出真实用户。不是笼统的“用户”，而是具体角色，比如仓库主管、运营团队或客服人员。如果除了你自己没人用这个项目，就坦白说明这是个人项目，另选一个作为主要故事。

第二步：写出系统中不属于你的部分。可能是第三方 API、接手的旧数据库、另一个团队的审批流程。很多工程师会隐去这个细节，因为它让项目显得“乱”，但对 FDE 岗位来说，这恰恰是最有价值的部分。

第三步：写出一个真实的部署约束。本地环境、客户的云、安全审查、受限的数据访问：一个这样的细节，抵得上一整行技术名词。

第四步：选两个数字，一个表示范围，一个表示影响。FDE Academy 认为，哪怕只是对变化方向的诚实估计，也胜过没有数字。

如果没有精确测量，就保守估计，或者写可以核实的内容，比如“取代了每周一次的人工录入流程”，而不是编造一个百分比。

第五步：压缩到两句话，再以面试官的视角重读。对每个短语问自己：如果被追问，能讲上五分钟吗？讲不展开的就删掉。

这个检验和真实面试的流程一致。根据 Aced 的指南，Palantir 寻找的是能把客户模糊需求变成边界清晰、可部署软件的人，还会考察你在规格不完整时如何扩展或修复代码。

Paraform 说得更直接：开工前需要详细规格说明的候选人，很难胜任这个岗位。

所以，“无文档的 ERP”这个短语，必须能引出你如何摸清数据库结构、找谁申请访问权限的故事。

## 让两句话等于什么都没说的错误

最常见的错误是用技术清单代替故事。“Python、React、Docker、Kubernetes”谁都能写。FDE 招聘方需要知道你用它们解决了什么问题、为谁解决。

第二个错误是把演示或黑客松项目包装成生产产品。一句“现在谁在用？”就能问出真相。演示就说是演示，把真正上了生产环境的项目作为主要故事。

第三个错误是动词含糊，比如“参与”“支持”“提升了性能”。如果你做的是大项目的一部分，就写明是哪一部分：“独立编写了数据接入层”比“协助搭建数据管道”清楚得多。

第四个错误是只写后端。如果你也碰过数据、界面或部署，就让句子体现出来，哪怕只用一个短语。

最后一个是篇幅。两句话就是两句话。想塞进更多细节的冲动，通常说明你还没选出最重要的那个约束。

## 同一个项目，面对不同职位描述换个开头

如果职位描述强调部署到客户环境，就以本地部署和安全审查开头；如果主要谈数据，就从数据库副本说起。这不是美化，而是 FDE 每天都在做的事：仔细听清对方需要什么，再用对方的语言描述自己的真实工作。

在所有信号背后，读简历的人始终在问一个问题：把这个人放进客户的系统里，他能做出能用的东西吗？你的两句话，是回答这个问题的第一次机会。

**本周动手试试:**

- 拿出简历上最强的项目，用三种方式改写：原版、套用“动作 + 任务 + 工具 + 指标 + 结果”公式的版本，以及补上别人的系统和约束的 FDE 版本。
- 找一份正在招聘的 FDE 职位描述，标出所有关于生产环境、客户基础设施和真实用户的短语，再看你的两句话命中了几个。
- 把这两句话念给朋友听，请对方连追问三次“然后呢？”。答不上来的短语就删掉。

## 信源

- [Forward Deployed Engineer Job Description (2026 Template)](https://vallettasoftware.com/blog/post/forward-deployed-engineer-job-description)

- [Palantir Forward Deployed Engineer (FDE) Interview Guide | Sample Questions (2026) - Aced (formerly Exponent)](https://www.aced.io/guides/palantir-forward-deployed-engineer-interview)

- [How to hire a forward deployed engineer: first hire guide](https://www.paraform.com/insights/how-to-hire-your-first-forward-deployed-engineer)

- [Forward Deployed Engineer Resume: How to Write One That Gets Interviews](https://fde.academy/blog/forward-deployed-engineer-resume-how-to-write-one-that-gets-interviews)

- [Resume Bullet Points: An Actionable Guide With Examples](https://www.careerflow.ai/blog/resume-bullet-points)

- [Strong Bullets for Technical Resumes | Career Services, UT Austin College of Natural Sciences](https://careerservices.cns.utexas.edu/resources/resumes/strong-bullets-technical-resumes)