# How to become a Forward Deployed Engineer in 10 Steps: $785K / year (full-course)
**作者**: Codez
**日期**: 2026-07-29T14:07:56.000Z
**来源**: [https://x.com/0xCodez/status/2082468167935308098](https://x.com/0xCodez/status/2082468167935308098)
---
Forward Deployed Engineer went from a Palantir curiosity to the most-recruited role in AI in twelve months - postings up 729%.
This is the 10-step roadmap into it: what the job actually is, the stack that gets you in, and the interview round that eliminates 60% of people who pass the coding.
> Follow my Substack to get fresh AI alpha: movez.substack.com
That is not a research scientist’s package. It is not a staff engineer at a big tech company.
It is the going rate for an engineer who does something almost nobody optimizes their career for: getting AI to actually work inside a real company.
Nobody is asking this person to train a model. They don’t need a PhD, and they don’t need to beat anyone at algorithm puzzles.
They need to walk into a business with legacy systems, a compliance department and a skeptical ops team - and come out six weeks later with something that runs.
The reason it pays that much is one statistic. An MIT NANDA study of 300 enterprise AI projects found 95% produced little or no measurable impact on profit and loss.
The models worked fine. The deployments died - because nobody could make them talk to a legacy database, pass a compliance review, or survive being handed to the team that inherited them.
The name is borrowed from the military: forward deployed means stationing specialized units close to the operational theater rather than back at headquarters.
Palantir built the modern version in the early 2010s and called them Deltas - and until 2016, the company had more Deltas than it had software engineers.
The premise was that customers didn’t need more product features. They needed engineers who could make the product work inside their fragmented, legacy, regulated, politically complicated environments.
That premise was niche for a decade. Then AI broke generic SaaS, and it became the whole game.
This is not a job description. It’s a go-to-market strategy - and the people executing it are the best-paid non-research engineers in the industry.
## 01. Learn what the job actually is
An FDE is the engineer the company sends to the customer. Not for a sales call, not for a kickoff meeting - for weeks at a time, sitting next to the people who will actually use the product, learning their workflow in painful detail, and shipping custom code that makes their version of it work.
The best mental model isn’t consultant and it isn’t solutions engineer. It’s founding engineer, working on someone else’s product.
There is no PM in the room to decide scope, no staff engineer to escalate the architecture to, and no backlog telling you what matters - you decide what to build, what to fake, and what to push back on, in the room, that week.
The typical rhythm across top AI companies is remarkably consistent: an FDE sits with a customer for four to eight weeks, ships something that works, and then the core engineering org slowly productizes whatever turned out to be general.
That loop is the entire strategic point of the role. You are simultaneously delivering revenue and doing the company’s highest-fidelity product research.
## 02. Understand why the role exploded
That 95% number from the lede is the foundation of this entire career path, so it’s worth understanding precisely.
- Those enterprise AI projects didn’t fail because the models were bad.
- They failed on integration: systems that couldn’t talk to legacy SQL databases, couldn’t handle the customer’s SAML authentication, couldn’t meet data residency requirements, and couldn’t be maintained by the operations team that inherited them.
Three forces then pointed the same direction at once.
- AI broke generic SaaS - the horizontal promise of buy-it-and-plug-it-in survives in mature categories but not in AI, where every enterprise has unique data, unique workflows, unique compliance constraints, and its own definition of good enough. Selling AI to a Fortune 500 is now always also selling an integration project.
- Labs need to deploy at the speed the technology moves - a six-month integration kills a pilot before it lands.
- And AI tools made the economics close: with Claude Code and the modern stack, one strong FDE does what took a team of three a few years ago, which is the only reason sending a human onsite for six weeks pencils out.
Notice what that means for you. The bottleneck in AI is no longer capability. It’s deployment - and the market is repricing accordingly.
## 03. Map the market and pick targets
The title is unstable, and that’s the first practical thing to know - searching only for “Forward Deployed Engineer” will hide most of the market from you.
The same job ships as Applied AI Engineer (Anthropic’s name for it), Forward Deployed Software Engineer or FDSE (Palantir’s), Solutions Engineer, Deployment Engineer, and Founding Engineer (Customer Facing) at smaller startups. Search all of them.
The growth is not subtle. FDE postings on Indeed went from 643 in April 2025 to 5,330 in April 2026 - a 729% increase in twelve months.
By mid-2026 there were 224 open FDE roles across 39 AI companies, and that counts only what was publicly posted. Salesforce committed to hiring a thousand. EY launched a dedicated FDE practice in the UK and Ireland in April 2026 - the first major consultancy to formally adopt the model.
Compensation reflects the scarcity, and it splits sharply by tier. Levels fyi data puts average US total comp around $238,000, with a typical range of $205,000–$486,000 and staff-level FDEs clearing $630,000. Palantir’s median sits near $215,000.
At the frontier labs it’s a different market entirely: senior FDEs at Anthropic and OpenAI clear $785,000, with Anthropic’s Applied AI Engineers above $300,000 base at senior levels and total comp regularly crossing $500,000.
One planning note worth having early: Anthropic typically does not negotiate offers.
## 04. Build engineering breadth
This is the counterintuitive part, and it’s where engineers coming from a specialist track get it wrong.
The strongest FDEs are not the deepest engineers their company has.
They’re the ones who can hold six domains in their head at once and switch between them cheaply. Depth in one area is worth less here than being genuinely solid across all of it.
Concretely, the floor looks like this. Python and TypeScript cover most of the ground you’ll touch. One cloud - AWS, GCP, or Azure, pick whichever your target customers actually run.
One database you know well and can debug under pressure, and one frontend framework you can throw a working interface together in.
That’s enough to start. You do not need to be the best engineer in the room; you need to be the only person in the room who can do all of it.
Two softer layers matter as much as the technical ones, and they’re what the interview will actually probe.
Product judgment, because you are the PM in the room and nobody else will decide what to build versus what to fake.
And business acumen - someone will ask what the ROI of this is, and they’ll need the answer to defend the project to their own leadership.
Framing your work in dollars and hours saved is a real, learnable skill that most engineers never practice.
## 05. Learn to ship AI, not train it
Here is the single most common misconception standing between engineers and this job: they assume they need to be able to train models.
You do not. Nobody is asking an FDE to fine-tune anything. You absolutely do need to ship them - which is a completely different and far more learnable skill set.
The AI-native layer is well defined at this point. Strong prompt engineering. Fluency with the major model APIs.
- RAG patterns - and specifically, knowing when retrieval is the wrong answer.
- Structured outputs, because production systems need validated shapes, not prose.
- Basic eval discipline, which is the layer that separates people who demo from people who ship.
And at least one agent framework you’ve actually built something in.
Weight your preparation toward evals and failure modes, because that’s what enterprise deployment is actually made of. Debugging hallucinations, retrieval failures, bad tool calls, brittle multi-step workflows.
Knowing how to reason about latency, cost, reliability, and security as tradeoffs rather than checkboxes.
```
# Rate 1-5. Anything below 3 is your next month of work.
## Engineering breadth # solid, not elite
[ ] Python // backend, scripts, data
[ ] TypeScript // integrations + a usable frontend
[ ] One cloud, deployed something real to it
[ ] One database, can debug it under pressure
[ ] Can stand up a working UI in a day
## AI native # ship, don't train
[ ] Prompt engineering beyond trial and error
[ ] Model APIs: streaming, tool use, token budgets
[ ] RAG // and knowing when retrieval is the WRONG answer
[ ] Structured outputs + schema validation
[ ] Evals // the layer that separates demo from production
[ ] One agent framework, something actually built
## The half nobody practices
[ ] Ran a workshop with a non-technical stakeholder
[ ] Said "we should not build that" to a paying customer
[ ] Expressed your work in dollars or hours saved
[ ] Learned an unfamiliar industry well enough to ship in it
6
Build the stack
```
Anyone can get a demo working; the entire value of an FDE is being the person who knows why the demo won’t survive contact with a real company, and what to do about it.
## 06. Build the three artifacts enterprises buy
This is where a generic “learn AI” roadmap stops being useful and specifics start to matter.
Anthropic’s own FDE postings describe the deliverables plainly: you embed with strategic customers to build production applications with Claude, and you ship MCP servers, subagents, and agent skills.
Those three artifacts are the concrete unit of work.
- MCP servers are the integration layer - the thing that connects Claude to the customer’s actual systems: their ticketing, their warehouse, their internal API that has no documentation and one person who understands it.
- Agent skills encode the customer’s specific workflow and institutional knowledge so Claude follows their process rather than a generic one.
- Subagents handle the work that would otherwise blow out a context window on a long-running task.
Build one of each, against a real system, and you have something almost no candidate has: a portfolio of exactly the artifacts the job produces.
```
# The artifact an FDE actually ships: Claude, wired into a system
# nobody designed for it. Legacy API, no docs, one guy who knows it.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("warehouse-ops")
@mcp.tool()
def find_stalled_shipments(hours_stalled: int = 24) -> list[dict]:
"""Shipments with no scan event in N hours. Use when ops asks
what is stuck, or before a customer escalation review."""
# The real work: their legacy schema, their timezone quirk,
# their soft-delete column that nobody documented.
return query(STALLED_SQL, hours_stalled)
@mcp.tool()
def reroute(shipment_id: str, hub: str, reason: str) -> dict:
"""Reroute a shipment. Writes an audit row — compliance
requires a reason string on every manual intervention."""
return post_with_audit(shipment_id, hub, reason)
# Note what makes this an FDE artifact and not a demo:
# - docstrings say WHEN to use the tool, not just what it does
# - the audit row exists because their compliance team requires it
# - the schema quirks are handled here, not left for the model
```
An MCP server that wraps a genuinely messy API is a stronger hiring signal than any certificate, because it proves the thing they can’t otherwise test for - that you can make a frontier model useful inside a system nobody designed for it.
## 07. Master Claude Code as your multiplier
Remember the third force from Step 2 - the underrated one. AI tools made FDEs dramatically more productive, and that is what made the role economically viable at scale.
One strong FDE now does work that took a team of three a few years ago. Sending a single human onsite for six weeks only pencils out because of that multiplier.
So the tooling isn’t a nice-to-have on top of the job; it’s load-bearing to the business case for your seat.
Practically, that means fluency with Claude Code is part of the skill stack, not adjacent to it.
The specific leverage points map directly onto FDE work: ramping into an unfamiliar codebase fast when you land at a new customer, writing the integration glue that makes up most of your output, and delegating research to subagents so a long deployment task doesn’t collapse under its own context.
There’s a hiring-signal reason to get good at this too, and it’s unusually direct. In Anthropic’s technical use-case screen, you may be given access to Claude and asked to work through the problem with it - deliberately, because it mirrors the actual job.
How you drive the model is part of what’s being evaluated. Practicing that is preparing for the interview and doing the work at the same time.
```
› Use a subagent to map how orders flow from intake to fulfillment in
this repo. I need the data model, the integration points, and anywhere
state can be written twice. Write it to notes/orders.md.
● Spawning research subagent · separate context window
● Read 23 files · 41.2k tokens — none of it in your window
✓ Returned 680-token summary → notes/orders.md Found: intake writes to `orders` AND `legacy_orders`. Reconciliation job runs
nightly. Anything failing between 18:00 and the 02:00 job is invisible to ops.
› That gap is the customer's actual complaint. Draft the MCP tool
that surfaces those in-flight orders, then we walk ops through it.
day 2. the previous vendor took six weeks to find this.
```
## 08. Ship one real deployment for a real user
Every FDE job posting screens for the same phrase in some form: shipped production AI systems. Not studied, not prototyped - shipped, to someone who depended on it.
That’s the wall most candidates hit, and it’s the one thing on this list you cannot read your way past.
So manufacture the experience deliberately. Find one real workflow belonging to someone who is not you - a small business, a nonprofit, a team inside your current company, a friend’s ops process.
Sit with them. Watch them work. Build the thing that removes the worst part of their week, deploy it where they actually use it, and then stay long enough to fix what breaks.
That last part is not optional the whole job is what happens after the demo.
Then write it up the way an FDE reports, because the write-up is half the artifact. Not “built a RAG chatbot with LangChain.”
Instead: what their workflow cost before in hours, what constraints you couldn’t change, what you deliberately chose not to build, what broke in week two, and what it costs them now.
```
# Dispatch triage for a 14-van plumbing company
// Structure this like an FDE post-mortem, not a project README.
## The workflow before
Dispatcher spent ~2.5h/day reading job notes and reassigning vans.
Two people quit over it in a year. Nobody had ever timed it.
## Constraints I could not change
- Scheduling data lives in a hosted tool with a read-only API.
- Dispatcher will not use a new app. It had to live in SMS.
- Owner would not approve anything touching customer payment data.
## What I deliberately did NOT build
Auto-reassignment. They didn't trust it and would have turned it
off in week one. Suggestion + one-tap approve instead.
// Being right about this mattered more than the model choice.
## What broke in week two
Job notes had inconsistent van nicknames ("big blue" vs "V-3").
Fixed with an alias table the dispatcher edits herself.
// This is the part that separates shipped from demoed.
## After
~40 min/day. Ran 5 months. She still uses it. Owner added 2 vans.
```
That document is your interview. Every hiring manager reading it learns more about you than any résumé line could tell them.
# 09. Learn customer discovery
This is the step to read twice. Anthropic’s Applied AI Engineer loop includes a customer-conversation round, and it carries a hidden weight: it filters out roughly 60% of candidates who already passed the coding stages.
Strong engineers, eliminated at the round they didn’t prepare for. Meanwhile 73% of frontier-lab FDEs report that running discovery conversations was the skill they were least prepared for coming from a traditional software background.
The failure mode is predictable and almost universal: the candidate hears a customer problem and starts solving it. They propose an architecture. Some open an editor.
- The candidates who advance do the opposite - they run the round like a research interview. They ask about the buyer’s current evaluation criteria.
- They ask about previous failed AI deployments, which is where all the real constraints are buried. They ask what genuinely cannot change: compliance, latency, data residency.
- They ask which specific workflow this would replace and who loses work if it succeeds. They take notes. They reflect back what they heard. They do not write code.
Anthropic screens for this explicitly because enterprise Claude deals don’t close on technical depth alone. It’s a learnable skill - and you can practice it in the exact same sessions from Step 8.
```
# Run the round like a researcher. Solving too early is the tell.
## Surface the real constraints
- What have you already tried here, and why did it stop?
// failed deployments hide every constraint that matters
- What can't change no matter what we build?
// compliance, latency, data residency, the union contract
- Who has to approve this, and what will they object to?
## Find the actual workflow
- Walk me through the last time this went wrong.
- Who does this today, and what does it cost them per week?
- What happens downstream if we get it wrong at 3am?
## Define "good enough" — theirs, not yours
- What accuracy would make you turn this off?
- How will you know in 90 days whether this worked?
- What does the person doing this today do instead, after?
## Close the loop
- Reflect back what you heard. Get it corrected.
- Name what you would NOT build, and why.
// Saying "we shouldn't build that" is a senior signal, not a dodge.
```
Every time you sit with the person whose workflow you’re fixing, you’re rehearsing this round.
# 10. Run the interview loop
The loop is unusually consistent across the top companies, and it’s built to filter in both directions at once - against pure algorithmic engineers who can’t communicate, and against smooth consultants who can’t code.
Expect roughly five stages:
- A recruiter screen on motivation, background, and level fit.
- A technical use-case screen - at Anthropic, a practical scenario around deploying Claude with MCP tooling, where you plan and execute a long-running task and reason about reliability, context-window management, and consistency in production.
- A coding round that is practical rather than LeetCode: a rate limiter, streaming data processing, a distributed job queue, a token-budget allocator, a structured tool-use orchestrator - often with new customer constraints layered in mid-exercise to see whether you refactor cleanly.
- A hiring manager round on past projects and customer reasoning. Then a final panel on solution design and values.Two preparation notes that people skip.
- Mission alignment is screened seriously at Anthropic - read the Core Views on AI Safety, the Responsible Scaling Policy, and recent interpretability work before you apply; generic enthusiasm does not pass.
And their postings ask for “calibrated judgment about model risks,” which is the bullet that quietly eliminates otherwise strong candidates. Being able to say clearly where you would not deploy a model, and why, is part of the bar.
## Six starting points - find yours
- Add the AI layer, keep the rigor. Your production instincts are the scarce half - most AI-native candidates have never run anything real. Add prompting, model APIs, structured outputs and evals, then ship one MCP server against a messy internal system.
- Stop training, start landing. You’re overqualified on modeling and underqualified on everything else. The job is integration, constraints and stakeholders. Deliberately build something boring that survives a compliance review and an ops handoff.
- Go where the deployments are. Frontier-lab FDE roles are rarely entry level. Aim one ring out - the startups and consultancies deploying AI into enterprises - where you’ll do the same work with less gatekeeping, then move up in two years.
- Close the coding gap, fast. You already have the half that eliminates 60% of applicants. Now get past the coding round: practical exercises, not LeetCode - rate limiters, streaming, job queues, tool-use orchestrators, written cleanly under changing constraints.
- Prove you can actually build. Discovery and stakeholder management are already yours. The loop is explicitly designed to filter out smooth talkers who cannot code - so your entire preparation is one shipped, maintained, publicly documented system.
- You may be doing this job already. Internal platform engineers who sit with business units are running the FDE motion under a different title. Rewrite your experience in the role’s language - workflows changed, hours saved, constraints navigated - and you’re a live candidate today.
# Conclusion:
The scarce thing was never the model. It’s the person who can land it.
Capability stopped being the bottleneck somewhere in the last two years.
What’s scarce now is the engineer who can walk into a company with legacy systems, a compliance department, and a skeptical ops team -and come out six weeks later with something that actually runs.
That’s a strange combination of skills, which is exactly why it pays like it does. Engineering breadth over depth. J
udgment with no PM to lean on. The patience to sit in someone else’s messy reality long enough to understand it before writing a line.
Most engineers will keep optimizing for the roles that existed in 2020. The ones who learn to deploy will own the decade - because every model that ships from here still has to survive contact with a real company.
## 相关链接
- [Codez](https://x.com/0xCodez)
- [@0xCodez](https://x.com/0xCodez)
- [67K](https://x.com/0xCodez/status/2082468167935308098/analytics)
- [movez.substack.com](https://movez.substack.com/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:07 PM · Jul 29, 2026](https://x.com/0xCodez/status/2082468167935308098)
- [67.8K Views](https://x.com/0xCodez/status/2082468167935308098/analytics)
- [View quotes](https://x.com/0xCodez/status/2082468167935308098/quotes)
---
*导出时间: 2026/7/30 10:05:17*
---
## 中文翻译
# 如何在 10 步内成为 Forward Deployed Engineer：年薪 78.5 万美元（完整指南）
**作者**: Codez
**日期**: 2026-07-29T14:07:56.000Z
**来源**: [https://x.com/0xCodez/status/2082468167935308098](https://x.com/0xCodez/status/2082468167935308098)
---
Forward Deployed Engineer（前线部署工程师）在十二个月内从 Palantir 的一个新奇角色变成了 AI 领域最抢手的职位——招聘职位增长了 729%。
这就是通往该职位的 10 步路线图：这份工作实际上是做什么的，能让你入职的技术栈，以及那个淘汰了 60% 通过了编码环节的人的面试轮次。
> 关注我的 Substack 获取最新的 AI 独家资讯：movez.substack.com
这不是研究科学家的薪资包。这不是大厂的高级 Staff 工程师的薪资。
这是一个工程师的现行市价，他所做的事情几乎没有人会在职业生涯中以此为目标：让 AI 在一家真实的公司里真正运转起来。
没有人会要求这个人去训练模型。他们不需要博士学位，也不需要在算法谜题上击败任何人。
他们需要走进一家拥有遗留系统、合规部门以及对 AI 持怀疑态度的运维团队的企业——并在六周后拿出一个能实际运行的东西出来。
之所以薪水这么高，是因为一个统计数据。麻省理工学院 NANDA 对 300 个企业 AI 项目的研究发现，95% 的项目对损益表几乎没有产生任何可衡量的影响。
模型运行得很好。部署却失败了——因为没人能让它们与遗留数据库对话，无法通过合规审查，或者在移交给接手团队后存活下来。
这个名字借用于军事术语：forward部署意味着将特种部队部署在靠近作战区域的地方，而不是留守在后方指挥部。
Palantir 在 2010 年代初构建了现代版本，并称他们为 Deltas——直到 2016 年，该公司拥有的 Deltas 数量比软件工程师还多。
其前提是客户不需要更多的产品功能。他们需要的是能让产品在他们碎片化、遗留、受监管且政治环境复杂的内部运转起来的工程师。
这一前提在过去十年里一直是个小众领域。随后 AI 打破了通用 SaaS 的模式，这便成了整个游戏的全部。
这不是一份职位描述。这是一项进入市场的战略——而执行这一战略的人是行业内薪资最高的非研究型工程师。
## 01. 了解这份工作实际上是做什么的
FDE 是公司派驻到客户现场的工程师。不是为了销售电话，不是为了启动会议——而是连续数周，坐在那些真正使用产品的人旁边，痛苦地详细了解他们的工作流程，并交付定制的代码，使适合他们的版本能够运行。
最好的思维模型不是顾问，也不是解决方案工程师。它是创始工程师，只是在别人的产品上工作。
房间里没有产品经理（PM）来决定范围，没有高级工程师来升级架构问题，也没有待办事项列表告诉你什么重要——你就在现场，在那周里，决定构建什么、模拟什么，以及回绝什么。
在顶级 AI 公司中，典型的节奏惊人地一致：FDE 与客户坐在一起四到八周，交付一个能运行的东西，然后核心工程部门慢慢将那些通用的部分产品化。
这个循环是该角色的全部战略重点。你既在产生收入，同时在进行公司最高保真度的产品研究。
## 02. 理解为什么这个职位爆发式增长
导语中提到的那个 95% 的数据是整个职业路径的基础，所以值得准确理解。
- 那些企业 AI 项目失败不是因为模型很差。
- 它们失败在集成上：无法与遗留 SQL 数据库对话的系统，无法处理客户的 SAML 身份验证，无法满足数据驻留要求，以及无法被接手的运维团队维护。
随后有三股力量同时指向了同一个方向。
- AI 打破了通用 SaaS——“即插即用”的横向承诺在成熟类别中尚存，但在 AI 中已不复存在，因为每家企业都有独特的数据、独特的工作流程、独特的合规约束，以及自己对“足够好”的定义。向财富 500 强企业销售 AI 现在总是伴随着一个集成项目。
- 实验室需要以技术发展的速度进行部署——为期六个月的集成会在试点落地前就将其扼杀。
- AI 工具使得经济学账目能够算平：借助 Claude Code 和现代技术栈，一个强有力的 FDE 可以完成几年前需要三个人团队才能完成的工作，这也是派遣一个人驻场六周在经济上可行的原因。
注意这对意味着什么。AI 的瓶颈不再是能力。而是部署——市场正在据此重新定价。
## 03. 绘制市场图谱并选择目标
职位名称并不稳定，这是你需要知道的第一件实务——只搜索“Forward Deployed Engineer”会让你错过市场的大部分机会。
同样的工作在不同的公司有不同的称呼：Applied AI Engineer（Anthropic 的称呼）、Forward Deployed Software Engineer 或 FDSE（Palantir 的称呼）、Solutions Engineer、Deployment Engineer，以及在小型初创公司中的 Founding Engineer（Customer Facing）。要把这些都搜一遍。
这种增长并不微妙。Indeed 上的 FDE 职位发布量从 2025 年 4 月的 643 个增加到 2026 年 4 月的 5,330 个——十二个月内增长了 729%。
到 2026 年年中，39 家 AI 公司共有 224 个开放的 FDE 职位，这还只计算了公开发布的。Salesforce 承诺招聘一千人。EY 于 2026 年 4 月在英国和爱尔兰推出了专门的 FDE 业务——第一家正式采用该模式的大型咨询公司。
薪酬反映了稀缺性，并按层级急剧分化。Levels fyi 的数据显示，美国平均总薪酬约为 238,000 美元，典型范围在 205,000 至 486,000 美元之间，而 Staff 级别的 FDE 可超过 630,000 美元。Palantir 的中位数接近 215,000 美元。
在处于前沿的实验室，这是一个完全不同的市场：Anthropic 和 OpenAI 的高级 FDE 薪酬可超过 785,000 美元，Anthropic 的 Applied AI Engineers 在高级别的基础薪资就超过 300,000 美元，总薪酬经常突破 500,000 美元。
有一个值得尽早注意的规划提示：Anthropic 通常不会对录用通知进行谈判。
## 04. 建立工程广度
这是反直觉的部分，也是来自专业轨道的工程师容易出错的地方。
最强的 FDE 不是公司里技术最深的工程师。
他们是那些能同时在脑海中容纳六个领域并能在它们之间低成本切换的人。在这里，一个领域的深度远不如在所有领域都真正扎实有价值。
具体来说，底线是这样的。Python 和 TypeScript 覆盖了你将接触的大部分领域。一个云平台——AWS、GCP 或 Azure，选择你的目标客户实际运行的那个。
一个你很熟悉且能在压力下调试的数据库，以及一个你能快速拼凑出一个可用界面的前端框架。
这就足以开始了。你不需要成为房间里最好的工程师；你需要成为房间里唯一能做所有这些事情的人。
两个软性层面与技术层面同样重要，而且它们才是面试真正会考察的内容。
产品判断力，因为你是房间里的 PM，没有其他人来决定构建什么、模拟什么。
商业敏锐度——有人会问投资回报率（ROI）是多少，他们需要这个答案来为自己的领导层捍卫项目。
用节省的美元和小时数来表述你的工作是一项真正的、可学习的技能，而大多数工程师从未练习过。
## 05. 学习交付 AI，而不是训练它
这是阻碍工程师获得这份工作的最常见误解：他们认为自己需要能够训练模型。
你不需要。没有人会要求 FDE 对任何东西进行微调。你绝对需要交付它们——这是一个完全不同且更容易学习的技能集。
AI 原生层在现在已经定义得很清楚了。强大的提示词工程。熟练掌握主要的模型 API。
- RAG 模式——特别是要知道何时检索是错误的答案。
- 结构化输出，因为生产系统需要经过验证的形状，而不是散文。
- 基本的评估纪律，这是区分只会演示的人和能交付产品的人的关键层。
以及至少一个你真正在其中构建过东西的智能体框架。
将你的准备重心放在评估和故障模式上，因为这才是企业部署的实质内容。调试幻觉、检索失败、错误的工具调用、脆弱的多步工作流。
知道如何推理延迟、成本、可靠性和安全性之间的权衡，而不是将它们视为勾选框。
```
# 评分 1-5。低于 3 分的是你下个月的工作内容。
## 工程广度 # 扎实，而非精英
[ ] Python // 后端、脚本、数据
[ ] TypeScript // 集成 + 可用的前端
[ ] 一个云平台，在上面部署过真实的东西
[ ] 一个数据库，能在压力下调试它
[ ] 能在一天内搭建一个可用的 UI
## AI 原生 # 交付，不要训练
[ ] 超越试错的提示词工程
[ ] 模型 API：流式传输、工具使用、token 预算
[ ] RAG // 并且知道何时检索是错误的答案
[ ] 结构化输出 + 模式验证
[ ] 评估 // 区分演示和生产的关键层
[ ] 一个智能体框架，真正构建过东西
## 没人练习的那一半
[ ] 与非技术利益相关者举办过研讨会
[ ] 对付费客户说过“我们不应该构建那个”
[ ] 用节省的美元或小时数表达你的工作
[ ] 充分学习一个陌生的行业以便在其中交付
6
构建技术栈
```
任何人都可以让演示工作起来；FDE 的全部价值在于成为那个知道为什么演示无法在与真实公司的接触中存活下来，以及对此该怎么做的人。
## 06. 构建企业购买的三大工件
这就是通用的“学习 AI”路线图不再有用、具体细节开始变得重要的地方。
Anthropic 自己的 FDE 职位发布清楚地描述了交付物：你嵌入到战略客户中，用 Claude 构建生产应用程序，并交付 MCP 服务器、子智能体和智能体技能。
这三个工件是具体的工作单元。
- MCP 服务器是集成层——将 Claude 连接到客户实际系统的东西：他们的票据系统、他们的仓库、他们没有文档且只有一个人懂的内部 API。
- 智能体技能编码了客户特定的工作流程和制度知识，以便 Claude 遵循他们的流程而不是通用流程。
- 子智能体处理那些在长时间运行的任务中可能撑爆上下文窗口的工作。
针对一个真实系统构建各一个，你就拥有了几乎没有任何候选人拥有的东西：一份完全由该职位产生的工件组成的作品集。
```
# FDE 实际交付的工件：Claude，接入到一个并非为它设计的系统。
# 遗留 API，没有文档，只有一个懂它的人。
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("warehouse-ops")
@mcp.tool()
def find_stalled_shipments(hours_stalled: int = 24) -> list[dict]:
"""在 N 小时内没有扫描事件的货物。当运维询问
有什么卡住了，或者在客户升级审查之前使用。"""
# 真正的工作：他们的遗留模式，他们的时区怪癖，
# 他们的软删除列，没人记录在文档里。
return query(STALLED_SQL, hours_stalled)
@mcp.tool()
def reroute(shipment_id: str, hub: str, reason: str) -> dict:
"""重新路由货物。写入审计行——合规要求
每次手动干预都要有原因字符串。"""
return post_with_audit(shipment_id, hub, reason)
# 注意是什么让这成为 FDE 工件而不是演示：
# - 文档字符串说明了何时使用该工具，而不仅仅是它做什么
# - 审计行的存在是因为他们的合规团队要求
# - 模式的怪癖在这里处理，而不是留给模型
```
一个封装了真正混乱 API 的 MCP 服务器比任何证书都更强，因为它证明了他们无法通过其他方式测试的东西——即你能让前沿模型在一个并非为它设计的系统内发挥作用。
## 07. 掌握 Claude Code 作为你的倍增器
还记得第二步中的第三股力量——被低估的那股吗。AI 工具让 FDE 的生产力大幅提高，这就是为什么该角色在经济上能够大规模可行的原因。
现在，一个强有力的 FDE 完成的工作需要几年前三个人团队才能完成。之所以派遣一个人驻场六周在经济上划算，正是因为这个倍增器。
因此，工具化不仅仅是工作之上的锦上添花；它是你席位商业案例的承重支撑。
实际上，这意味着熟练掌握 Claude Code 是技能堆栈的一部分，而不是与其相邻。
具体的杠杆点直接映射到 FDE 的工作：当你到达新客户时快速进入陌生的代码库，编写构成你大部分输出的集成胶水代码，以及将研究委托给子智能体，以免漫长的部署任务在其自身的上下文压力下崩溃。
这也是一个值得为此变强的招聘信号原因，而且它异常直接。在 Anthropic 的技术用例筛选中，你可能会获得 Claude 的访问权限并被要求用它来解决问题——这是有意为之，因为它反映了实际的工作。
你如何驱动模型是被评估的内容之一。练习这一点既是在准备面试，也是在同时做工作。
```
› 使用子智能体映射订单在此仓库中从接收到履行的流程。
我需要数据模型、集成点，以及任何可以双重写入状态的地方。
将其写入 notes/orders.md。
● 生成研究子智能体 · 独立的上下文窗口
● 读取 23 个文件 · 41.2k tokens —— 你的窗口中没有任何这些内容
✓ 返回 680-token 摘要 → notes/orders.md
发现：接收到 `orders` 和 `legacy_orders` 都有写入。
核对作业每晚运行。任何在 18:00 到 02:00 作业之间失败的
东西对运维来说是不可见的。
› 那个差距就是客户的实际投诉。起草能暴露这些进行中订单
的 MCP 工具，然后我们要带运维过一遍。
第 2 天。之前的供应商花了六周才发现这个。
```
## 08. 为真实用户交付一个真实的部署
每个 FDE 的职位发布都在筛选某种形式的同一句话：交付了生产级 AI 系统。不是研究过，不是原型过——是交付了，交付给依赖它的人。
这是大多数候选人碰壁的地方，也是这份清单上你唯一无法通过阅读来跨越的事情。
所以要有目的地制造这种体验。找一个属于非你本人的真实工作流程——一家小企业、一个非营利组织、你当前公司内部的一个团队、一个朋友的运维流程。
坐在他们旁边。观察他们工作。构建一个能消除他们一周中最糟糕部分的东西，将其部署在他们实际使用的地方，然后停留足够长的时间以修复出现的问题。
最后一部分不是可选的——整个工作就是演示之后发生的事情。
然后像 FDE 报告那样写下来，因为写作本身就是工件的一半。不是“用 LangChain 构建了一个 RAG 聊天机器人”。
而是：之前他们的工作流程在时间上花费多少，你无法改变的限制，你故意选择不构建什么，第二周出了什么问题，以及现在花费他们多少。
```
# 一家拥有 14 辆货车的管道公司的调度分诊
// 像FDE事后分析一样构建结构，而不是项目 README。
## 之前的工作流程
调度员每天花费约 2.5 小时阅读工作笔记并重新分配货车。
一年内有两个人因此辞职。从未有人计算过这个时间。
## 我无法改变的约束
- 调度数据驻留在一个具有只读 API 的托管工具中。
- 调度员不会使用新应用程序。它必须存在于 SMS 中。
- 所有者不会批准任何涉及客户付款数据的东西。
## 我故意不构建的东西
自动重新分配。他们不信任它，并且会在第一周就关掉它。
取而代之的是建议 + 一键批准。
// 在这个问题上正确比模型选择更重要。
## 第二周出了什么问题
工作笔记中的货车昵称不一致（“大蓝” vs “V-3”）。
通过一个由调度员自己编辑的别名表修复。
// 这是区分已交付和已演示的部分。
## 之后
每天约 40 分钟。运行了 5 个月。她仍在使用。所有者增加了 2 辆货车。
```
那份文件就是你的面试。每一个阅读它的招聘经理都比任何简历条目更能了解你。
# 09. 学习客户探索
这一步要读两遍。Anthropic 的 Applied AI Engineer 流程包含一个客户对话轮次，它具有隐藏的权重：它淘汰了大约 60% 已经通过了编码阶段的候选人。
强大的工程师在他们没有准备的轮次被淘汰。同时 73% 的前沿实验室 FDE 报告说，运行探索对话是他们从传统软件背景转型过来时准备最不充分的技能。
失败模式是可预测且几乎普遍的：候选人听到客户的问题并开始解决它。他们提出架构。有些人打开编辑器。
- 晋级的候选人则相反——他们像研究访谈一样进行这一轮。他们询问买家当前的评估标准。
- 他们询问之前失败的 AI 部署，所有真正的限制都埋藏在那里。他们询问什么真正不能改变：合规、延迟、数据驻留。
- 他们询问这将取代哪个具体的工作流程，如果成功谁会失去工作。他们做笔记。他们反思他们听到的内容。他们不写代码。
Anthropic 明确筛选这一点，因为企业 Claude 的交易不仅仅靠技术深度就能达成。这是一项可学习的技能——你可以在第 8 步的完全相同的会议中练习它。
```
# 像研究人员一样进行这一轮。过早解决是破绽。
## 揭示真正的约束
- 你们在这里已经尝试过什么，为什么停止了？
// 失败的部署隐藏了每一个重要的约束
- 无论我们构建什么，什么都不能改变？
// 合规、延迟、数据驻留、工会合同
- 谁必须批准这个，他们会反对什么？
## 找到实际的工作流程
- 带我回顾上一次出错的情况。
- 现在是谁在做这个，每周花费他们多少成本？
- 如果我们在凌晨 3 点搞砸了，下游会发生什么？
## 定义“足够好”——他们的标准，不是你的
- 什么准确率会让你关闭它？
- 90 天后你将如何知道这是否有效？
- 现在做这件事的人在那之后会做什么？
## 闭环
- 反思你听到的内容。获得纠正。
- 说出你不会构建什么，以及为什么。
// 说“我们不应该构建那个”是一个高级信号，而不是回避。
```
每次你与工作流程正在被修复的人坐在一起时，你都在排练这一轮。
# 10. 运行面试循环
顶级公司之间的循环异常一致，它的设计旨在同时进行双向筛选——针对无法沟通的纯算法工程师，以及针对无法编码的圆滑顾问。
预计大约有五个阶段：
- 招聘人员筛选，考察动机、背景和级别匹配度。
- 技术用例筛选——在 Anthropic，这是一个围绕使用 MCP 工具部署 Claude 的实际场景，你需要规划和执行一个长时间运行的任务，并推理生产环境中的可靠性、上下文窗口管理和一致性。
- 编码轮次，是实际应用而非 LeetCode：一个速率限制器、流式数据处理、分布式作业队列、token 预算分配器、结构化工具使用编排器——通常会在练习中途添加新的客户约束，以查看你是否能干净地重构。
- 招聘经理轮次，考察过去的项目和客户推理。然后是最后一轮的小组解决方案设计和价值观筛选。两个人们会跳过的准备提示。
- 使命一致性在 Anthropic 受到严肃审查——在申请前阅读关于 AI 安全的核心观点、负责任扩展政策以及最近的可解释性工作；通用的热情无法通过。
他们的招聘信息要求“对模型风险有校准过的判断”，这是悄悄淘汰了本来很强的候选人的要点。能够清楚地说出你在哪里不会部署模型以及为什么，这是门槛的一部分。
## 六个起点——找到你的
- 添加 AI 层，保持严谨。你的生产直觉是稀缺的那一半——大多数 AI 原生候选人从未运行过任何真实的东西。添加提示、模型 API、结构化输出和评估，然后针对一个混乱的内部系统交付一个 MCP 服务器。
- 停止训练，开始落地。你在建模方面资历过高，在其他一切方面资历不足。工作是集成、约束和利益相关者。有意识地构建一些无聊的东西，使其能够经受住合规审查和运维移交。
- 去部署所在的地方。前沿实验室的 FDE 角色很少是入门级的。目标向外瞄准一圈——将 AI 部署到企业中的初创公司和咨询公司——在那里你将做同样的工作但关卡较少，然后在两年内向上发展。
- 快速缩小编码差距。你已经拥有了淘汰 60% 申请者的那一半。现在通过编码轮：实际练习，不是 LeetCode——速率限制器、流式传输、作业队列、工具使用编排器，在变化的约束下干净地编写。
- 证明你实际上能构建。探索和利益相关者管理已经是你的了。循环明确设计为淘汰无法编码的能说会道者——所以你的整个准备就是一个已交付、已维护、公开记录的系统。
- 你可能已经在做这份工作了。与业务部门坐在一起的内平台工程师正在以不同的头衔运行 FDE 模式。用角色的语言重写你的经验——改变的工作流程、节省的时间、导航的约束——那你今天就是现成的候选人。
# 结论：
稀缺的东西从来都不是模型。而是那个能让它落地的人。
能力大约在两年前的某个时候不再是瓶颈。
现在稀缺的是那个能走进一家拥有遗留系统、合规部门和怀疑论运维团队的公司——并在六周后拿出一个真正能运行的东西出来的工程师。
这是一种奇怪的技能组合，这正是它薪水如此之高的原因。工程广度优于深度。在没有 PM 可以依赖的情况下的判断力。有足够的耐心坐在别人的混乱现实中，在写下一行代码之前先理解它。
大多数工程师将继续优化针对 2020 年存在的角色。那些学会部署的人将拥有这十年——因为从这里交付的每个模型仍然必须在真实公司的接触中存活下来。
## 相关链接
- [Codez](https://x.com/0xCodez)
- [@0xCodez](https://x.com/0xCodez)
- [67K](https://x.com/0xCodez/status/2082468167935308098/analytics)
- [movez.substack.com](https://movez.substack.com/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [10:07 PM · Jul 29, 2026](https://x.com/0xCodez/status/2082468167935308098)
- [67.8K Views](https://x.com/0xCodez/status/2082468167935308098/analytics)
- [View quotes](https://x.com/0xCodez/status/2082468167935308098/quotes)
---
*导出时间: 2026/7/30 10:05:17*