Forward Deployed Engineering 真相：9 年老兵拆穿 hype
最近一篇 viral 帖子把 Forward Deployed Engineering（FDE）称为"科技界最热门的岗位"，并给出了 30 天速成路线图。一位从 2016 年就开始做这行、累计完成 174 个客户项目的老兵站出来说：这篇帖子本质是招聘广告，那个 30 天计划会把人炒掉。
FDE 不是新东西
Forward deployed engineer、field engineer、post-sales engineer、solutions architect、sales engineer——这些角色已经存在几十年。把工程师放进客户环境、在对方基础设施上构建定制系统，这是每一个严肃的嵌入式工程公司一直以来的运作模式。
变化的不是岗位本身，是 AI 让它变得性感了。"我们坐在你团队里写代码"被包装成"Forward Deployed Engineering"，然后 VC 的钱就开始飞了。
一位正在 Google Cloud 面试 FDE 候选人的工程师说得实在：这 basically 就是全栈工程师，算法要求低一点，但更注重交付能力和利益相关方管理。
全栈 + 客户技能。这就是这份工作。一直都是。
FDE 的 hype 是科技行业最擅长的事：给已经存在的东西起个新名字，然后假装这是场革命。
真正不同的是 AI 原生工作流
两个工程师用对的方法论，现在能交付过去需要六个人的工作量。作者有数据：
一个 B2B 物流平台的核心系统重建，2 人小组，90 天内合并了 122 个 PR。时间线从 7-8 个月压缩到 3.5 个月。80%+ 的代码由 AI 辅助生成，100% 经过人工审核。
这是生产环境的合并代码。不是 demo。不是 pitch deck 上的数字。
真实的 30 天是什么样子
那个 viral 帖子的 30 天计划是：读 Anthropic 文档、构建 agent loop、添加 tool calls、学习结构化输出。这确实是学习 LLM API 的好计划，但和实际工作几乎无关。
第一周：你盯着从未见过的代码库。没有文档。最后三个懂认证层的开发者已经离职，把文档也带走了。一个基于 2018 年基础设施决策的 monolith 在运行。你的任务是在不破坏任何东西的前提下，构建这个系统的 AI 可读架构图。你用 AI 加速理解，而不是生成——揭示隐藏关系、未记录的流程、多年决策积累下来的代码真实形态。
第二周：你已经标出 AI 能帮忙的地方和不能帮忙的地方。这就是 viral 帖子框架彻底崩塌的地方。它说"构建 agents"，但没提大多数自动化任务需要一系列 tool calls 和一个 LLM call 作为编排层。AI 用得太多意味着 token 成本叠加，规模扩大后输出质量反而下降。知道区别需要多年的 reps，不是 30 天的教程。
第 3-4 周：第一批 PR 开始上线。每一行 AI 生成的代码通过三个检查：你验证过它有效吗？你理解到能在凌晨 2 点调试它吗？你能在 3 分钟内给队友解释清楚吗？如果你信任它的唯一理由是"模型看起来很自信"，那它不能上线。
80% 的 boilerplate 用 AI 辅助。业务逻辑经过严格的高级审核。安全、支付、架构决策？零 AI。纯人工。
这是在一个客户上达到初始速度的 30 天。而且是有经验的工程师。不是读了篇博客就做了 side project 的人。
审计是整个游戏
viral 帖子把审计简化为"映射流程、发现瓶颈、做原型"。几段话。完事。
实际上，审计就是整个球赛。
你不只是找瓶颈。你在决定什么应该自动化、什么不应该。你在评估客户接触的每个系统的数据质量。集成接口。组织准备度。团队是会真正采用你构建的东西，还是悄悄绕过它。
真实的 agentic 工作审计需要 BPMN 建模、启发式分析、业务流程分解，以及理解哪些工作流有足够的体量和复杂度来证明 agent 的合理性，哪些用简单脚本就够了。
80% 的 AI 项目没能进入生产或交付预期 ROI。RAND Corporation 的数据是 80.3%。MIT 发现 95% 的生成式 AI pilot 没能产生可衡量的 P&L 影响。
这些不是模型失败。是审计失败。部署在任何人写第一行代码之前就已经死了，因为没人做真正的发现工作。
架构先于 AI
当你在多个团队快速部署 agents 而没有架构纪律时，你构建的是 Frankenstein。每个部门有自己的 agent、自己的数据管道、自己的集成模式。六个月后 CTO 盯着一堆比开始时更难维护的烂摊子。
快速见效感觉很好。但过多的快速见效而没有强有力的架构师协调全局，会把大型企业埋在额外的复杂度里。而且没人讨论在没有治理框架的组织中释放 AI agents 的审计风险。
这就是为什么在作者的每个项目中，架构都排在 AI 之前。在接触模型之前，先理解系统。映射代码库。识别边界。找到每次变更的爆炸半径。
AI 不修复坏架构。它让坏架构死得更快。
地理无关紧要
viral 帖子引用 Palantir CTO 的话：你无法在不身处其中的环境中构建产品。
这在 Palantir 深夜在阿富汗写代码时可能是真的。但现在不是了——当你有 repo 访问权限、基础设施访问权限、Slack 上下文，以及严格的入职方法论。
作者从布拉格、圣保罗、波哥大的小组服务美国和欧盟客户。完全时区重叠。当天交付。工程师参加 standup、Slack、代码库。不是作为承包商。作为队友。
他们的入职流程在 7 天内构建客户代码库的完整知识图谱。AI 加速了这个过程。当你的理解深度超过客户自己的团队时，地理无关紧要。
而 Palantir 自己的 Glassdoor 评价讲的是另一个故事：50+ 小时工作周。持续的上下文切换。模糊的工作职责。领导层没解决的留人问题。物理在场和有效工作是两回事。
给从业者的实用框架
Know your zones：
- 80% AI：boilerplate、测试、重构、CRUD、文档
- 20% AI：业务逻辑和集成，需高级审核
- 0% AI：安全、支付、架构
如果你的指南没告诉你什么时候不用 AI，那它是销售 pitch。
用 DORA 证明，不用 war stories： 部署频率、变更前置时间、变更失败率、恢复服务时间。从第一天开始埋点。如果你无法衡量改进，你就无法证明价值。没人关心你的 Palantir 轶事。
为退出而构建： 测试标准不是你部署了多少 agents，而是客户六个月后能否在没有你的情况下以这个水平运营。
那个 viral 帖子称 FDE 为"科技界最热门的岗位"。
作者称它为：周一。