通过加入真实用户、约束条件、度量指标、运维责任以及经得起推敲的工程权衡，把真实工作转化为可信的 FDE 证据。
由 The Forward Deployed 编辑团队撰写并审校
本站的其他页面让你做好面试准备。而这一页讲的是真正能让你拿到 offer 的东西，也是唯一一页必须坦诚说明自身局限的页面。
The Forward Deployed 的招聘标准是经过验证的生产环境执行能力。一份罗列 AI 关键词的简历，会输给一个能说出“我上线了这个系统，真实用户依赖它，这是出过的问题以及我是如何发现的”的候选人。个人效率类的 AI 使用——你用 Copilot，你做了一个周末聊天机器人——达不到这个标准，因为这些东西从未在真实约束下接受过真实客户的检验。
标准：生产级 AI vs. 业余级 AI
这就是面试官正在使用的评分标准，无论他们是否明说。每一行都是他们可以提出的问题，而大多数行答“否”就意味着这项工作只是业余项目。
| 生产级 AI ✓ | 业余级 AI ✗ |
|---|---|
| 集成了真实数据 | 合成或示例数据 |
| 在真实约束下运行 | 没有真实约束 |
| 拥有真实用户 | 除了你没有其他用户 |
| 受 SLA 或质量标准约束 | 只在演示中成功过一次 |
| 能说出并捍卫的权衡取舍 | 没有任何需要捍卫的利害关系 |
两栏之间的差距不在于模型 sophistication。一个有真实用户和真实约束的简单系统，胜过一个从未离开你笔记本电脑的精巧系统。面试官购买的是证据：证明你运营过某个别人赖以使用的东西。
在继续阅读之前： 想一想你构建过的最令人印象深刻的 AI 项目。用这五行给它打分。如果它大多落在右栏，问题不在于你的技能——而在于还没有任何东西迫使你的工作进入左栏。本页接下来的内容就是关于如何促成这一点。
如何把你的工作移入左栏
你有一份工作，或者能接触到一个副业项目。关键动作不是“在业余时间构建新东西”——而是重塑某个真实的东西，让它一次达标一行。
从已经有用户的工作入手。 进入左栏最快的路径，是在人们已经在使用的东西里加入一个 AI 功能——在你的工作中、在一个开源项目中、在你所属的社区里。一个不是你凭空造出来的用户是最难伪造的一栏，所以从这里开始，让它把其余各栏也一并带过去。
有意识地加入一个真实约束。 选择那个能让它成为生产级的约束：延迟预算、成本上限、合规规则，或者用杂乱的真实数据代替干净的示例数据。一个被认真对待的真实约束，比三个功能更能让你学到东西。它还会给你那个面试官会要求你捍卫的权衡取舍。
做好监控，让你能回答“你怎么知道它有效？” 业余项目最普遍缺少的就是一种确认自己是否正确的方法。加一个评测——哪怕是一个只算出一个数字的小型留出集——以及一种在生产环境中观察它的方式。当你能说出“我是这样测量的，出现漂移时我会这样做”时，你听起来就像一个真正交付过产品的人。
写下你做出的权衡及其原因。 证据不是产物本身，而是你为决策辩护的能力。保持一份简短的记录：约束条件、你否决的方案、你优化的指标、出了什么问题、你会如何改进。这份记录就是你在每一轮面试中都会用到的素材。
工作中没有 AI？自己创造切入点
上一节假设你有与 AI 相关的工作可以重塑。很多优秀的工程师并没有——你在一家没有 AI 计划的公司，做着从不接触模型扎实工作。这并不意味着你不够格；它意味着你的第一步是创造切入点。三种方法，按推荐顺序排列。
在公司内部提议一个试点。 把公司里一个真实、棘手的问题，作为一个范围明确的小型 AI 试点提交给你的经理——有明确的指标、固定的预算和终止日期。这是最快的路径，因为真实公司的真实问题自带左栏的全部要素：真实用户、真实数据、真实约束。一个交付上线的试点是最有力的证据。即使提案被拒绝，只要论证充分，依然是面试素材——你界定了一个模糊的问题，指出了风险，并将其转化为业务指标，而这正是 FDE 工作的大部分内容。就算永远不发送，也要把那一页提案写出来。
加入已经存在的努力。 大多数公司都有一个半死不活的 AI 项目——一个停滞的概念验证、一个在业余时间做实验的团队、一个无人负责的“我们应该用 AI 做 X”。加入进去。这比从零开始更快，因为用户和问题已经存在；而这些努力几乎总是缺少的，恰恰是你能带来的东西——把演示变成可交付产品所需的生产纪律（评测、防护栏、确认它有效的方法）。
交付一个真正达到标准的副业项目。 这是诚实的难题。业余项目不算数——所以副业项目只有具备业余项目所缺少的东西时才能成为证据：真实用户和真实约束。 你为自己搭建的聊天机器人仍然是业余 AI。而一个你未曾招募的人真正依赖的工具——一个有真实采用者的开源项目、你为本地非营利组织或社区运行的一个部署——并且当负载或混乱的数据把它搞坏时你能持续维护它，这就是你主动做出来的生产级 AI。它比前两种更慢，但这是一条不需要任何人许可的路。
工作中没有 AI 的读者并没有陷入困境。标准是一样的；只是你的起跑线靠后了一步。从三者中选一个，你就踏上了切入点。
三种形态，雄心递增
这些是用来指向你真实工作的形状，而不是供你克隆的入门套件。每一个都刻意保持通用；价值来自于把它指向你实际拥有的数据和用户。
- 带监测的功能。 在一个已有用户的系统中，选一个 AI 功能，为它建立评测和仪表盘。范围不大；它能同时验证用户、真实数据和质量标准。对于有本职工作的人来说，这是每小时产出证据最多的做法。
- 受约束的部署。 拿一个可运行的原型，让它经受住一个硬约束——在成本上限下运行、在混乱的生产数据上运行，或遵守某条合规规则——并记录下改变了什么。这能验证约束应对能力，并给你一个可辩护的权衡。
- 被拥有的成果。 找一个别人真实存在的问题，用 discovery 步骤找到真正的问题，交付他们愿意采用的方案，并衡量是否提升了他们的关键指标。这是完整 FDE 闭环的缩影，也是最有力的证据——它能验证所有条目。
如何在面试中谈论它
无法清晰表达的证据不算证据。在面试中，先讲约束和利害关系，而不是技术栈：
- 说清楚谁依赖它、风险是什么。 “支持工程师每天使用它；一个错误的答案会把客户引向错误的方向。”这一句话能同时验证三个条目。
- 先讲衡量方式。 “我知道它在起作用，因为我每天用一个留出集给它打分，并观察生产环境中的纠正率。”这正是 system-design round 所奖励的习惯，应用到你自己的工作上。
- 主动说出权衡。 在被问到之前，主动说明你放弃了什么、为什么。这表明你是一个能做决策并能为之辩护的工程师。
- 坦诚说明局限。 如果用户是内部的且数量很少，就直说。面试官更相信“三位工程师依赖它”，而不是一个他们用一个提问就能戳穿的夸大说法。
局限，重申一遍
这个页面负责定位和框定证据；它无法凭空制造证据。录用来自于交付真实的东西。你今天能做的，是把现有工作对准标准、坚持记录，并学会用 customer's terms 来谈论它。
下一步： Interview Practice — Overview —— 证据已经定位好了；接下来是让你在面试现场反应迅速的练习。