中文全文译本
### 三个互不相干的人，各自独立想通了关于交付软件的同一件事
Mitesh · 2026-08-24
1969 年，IBM 做了一件意外催生整个独立软件业、整个 IT 咨询业，以及本文标题那个岗位名称的事。它做了什么？
先把这想法按住。我会回来讲，因为答案比任何咨询幻灯片都更能解释你 2026 年的 AI 组织架构（我认为）。
先说我为什么写这篇文章。
几个月前，我在悉尼一间会议室里，跟客户的工程团队开会。好团队。真的很锋利。他们为贸易金融单据检查建了一个聪明的 Agent。Demo 漂亮。界面光滑，回答自信，该有的都有。
人人鼓掌。
然后他们的工程负责人——一位可爱的人，语调像周二下午那样平淡——说：「它已经 Demo 了十一个月。」
十一个月。同一套 Demo。同一套十五份样本文档。那栋楼里每位高管都看过。没人上线。
我现在已经在六个国家、四种语言里看过这同一部电影大约四十次（问之前先说：我开着口译机）。结局总一样。总有人最终得坐进客户的真实系统，带着客户的真实烂摊子，做无聊、具体、不光鲜的工作，让东西熬过与现实的接触。
那个人现在有了名字、LinkedIn 横幅，和薪资带。
我在《Engines Without a Chassis》里写过这支团队，大约四段。好几位读者回信问：这角色到底是什么、谁做什么、会不会取代你们现有的技术现场团队。问题公平。这是长答案。
## 你以前跟主机一起白送的免费工程师
回到测验题。
1969 年 6 月 23 日，IBM 宣布将软件和服务与硬件拆开销售。在那之前，你买主机，软件免费。培训免费。Systems Engineers 也免费。
再读一遍。IBM 发明了前线部署工程师的概念，差不多永久地把他们停在你现场，却一分钱不收。他们被包含在内，像酒店里的薄荷糖。
为什么停？部分因为美国司法部那年一月开了反垄断案，那些免费捆绑看起来像垄断论证的承重墙。IBM 在被推之前自己跳了。
后果巨大，几乎全非本意。
软件变成可以单独卖的产品。1969 年之前，「软件公司」几乎还不是可行商业模式。服务变成可以单独卖的产品——这是你曾为日费率讨价还价过的每一家咨询公司的起源。
而坐在客户身边的工程师，变成了预算行项目。
某样东西一旦变成行项目，财务里就会有人开始问你是否真的需要这么多。那一次会计变更，是你今年听过的每一次「这笔资源算谁的预算？」争论的祖先。争论已经五十七岁了。
更好玩的细节：到 1969 年，IBM 的现场文化已经古老。Thomas J. Watson Sr. 1920 年在纽约 Endicott 开办 IBM 第一所正式销售学校，训练人们先理解客户的会计部门再卖制表机。Systems Engineer 头衔后来才来，被明确设计成桥梁：够业务流利以理解工资流程，够工程以知道为什么读卡机一直卡纸。
我们花了五十年重新发明那份工作，并给它新名字。
Watson 还给 IBM「THINK」标语，禁止公司活动饮酒，并发行正式公司歌本。有一首叫《Ever Onward》。我读过歌词。跟全员大会比，我们逃脱得算轻。
## 从士兵那儿借来的词
「Forward deployed」不是硅谷造词。它来自军事学说：把力量部署在预期出事的地方附近，而不是舒舒服服待在大本营。
逻辑不浪漫。关乎响应时间。如果你的能力离问题八千公里，你永远会在问题已经改形之后才到达。
而这——我说这话带着感情——几乎完美描述了过去三十年的企业软件交付。
厂商坐在总部。客户坐在问题旁边。中间跑着一串文档：RFP、工作说明书、架构图、as-is 和 to-be。每一份都是对真相略更失真的复印件。等需求到达工程师，已经过五次翻译，丢掉了唯一重要的细节：源系统按哪个区域办公室录入，会吐出三种不同日期格式。
老毛奇（Helmuth von Moltke the Elder），普鲁士元帅、职业悲观主义者，通常被转述为「没有任何计划能在接触敌人后存活」。他实际写的更长更好：任何作战计划，都无法有把握地延伸到与敌主力首次遭遇之后。
他的结论不是「别计划」。而是把决策权推给能看见地形的人，因为他们是唯一握有当前信息的人。他围绕那想法建了整个军官团。
有一个我更喜欢的东方版本，部分因为它更实用，部分因为我住在这一带。
丰田称之为 genchi genbutsu。自己去看。它的姊妹概念是 gemba，实际发生的地方。规则是：你不在会议室拿着电子表解决产线上的问题。你走到工作发生的地方去看它。
据说大野耐一把工程师关在车间粉笔画的圆圈里站几小时，直到他们真正看见正在发生的事，而不是他们以为正在发生的事。
我合作过的每个好 FDE 都站在大野圆圈里。他们只是有像样的椅子和冷萃，而不是粉笔。
## 一份工作如何变成十四份
大约 1969 到 2015 年间，面向客户的技术角色像组织良好的变形虫一样分裂。每次分裂单独看都合理。合在一起却产出没人会故意设计的东西。
大致按出场顺序。
Systems Engineer，后来是 Sales Engineer。原版。跟客户经理坐一起，回答难题，做 Demo。按成交付酬。签字第二天就消失，有时更早。如果没消失，他们后来被称为「trusted advisor」。
Account Manager。拥有关系、数字和高尔夫。真的很难的工作，常被从未不得不向 VP 解释季度滑落、或上过 forecast 电话会的工程师嘲笑。
Solution Architect。系统大到一个人脑子装不下时出现。画框。拥有 to-be 状态。产出质量真实的文档，然后被大约 1.4 个人读。
Specialist，或 overlay。因为没有通才能在数据库、网络、安全以及现在 31 种 AI 模型服务上保持当前。于是我们加了像救援投手一样被拉进交易的深专家。
Customer Engineer。我们在 Google 的叫法，好名字。偏售前技术，建原型和概念验证，拥有技术赢单。他们通常是某一领域的深主题专家，大体懂业务，有时会在 forecast 电话会上用技术黑话把销售 VP 绕晕。
Platform Architect。拥有落地园区、护栏、组织策略、身份模型。极重要又几乎隐形，像管道。非技术时爱画 markitecture 图或六边形。
Technical Account Manager 或 Customer Success Engineer 或 Adoption Engineer。售后。拥有采用、健康、续约。很大程度上因为订阅收入意味着厂商终于关心发票结清之后发生什么。在 AI 世界，通常用来协调「实际交了什么」与「宣传交了什么」之间的混乱。
Professional Services。可计费交付。工时与材料。工作说明书里的变更控制条款可当凶器用。
Partner 和 Systems Integrator。在多数大型企业真正做多数工作的人，值得比厂商现场通常给的更多赞誉。不过，他们对保护自己的遗产非常沉重。
现在数交接。
发现工作坊里生出的想法，从客户经理传到客户工程师传到架构师传到专家传到合作伙伴交付负责人传到离岸小组传到支持队列。每次交接都是一次翻译。每次翻译都丢掉东西。
而这是要紧的部分。那条链上没人对东西在生产里真正工作负责。人人只对自己那一棒负责。
Melvin Conway 1967 年发表论文《How Do Committees Invent?》。如今称为康威定律的观察是：组织设计的系统会镜像其自身沟通结构。
再读一遍那角色列表，然后看为什么你的 AI 部署有十一个集成点和一张开着 340 个工单的 Jira 板。那是带着项目代码的康威定律。
## Delta 与法国服务员
现在是人人半知的起源故事。
2000 年代中期，Palantir 为国防和情报客户建软件。他们撞上一个结果成了礼物的约束。数据不能离开大楼。涉密环境不会把样本数据集电邮给你，好让你回办公室建点聪明东西。
于是 Palantir 做了唯一能做的事。他们派真正的软件工程师——不是售前工程师，也不是顾问——坐进客户环境，在那儿写生产代码。
结构有两边。
Devs 建平台本身。通用原语，写一次，意在对每个买的人管用。
Deltas——前线部署工程师——去坐进单个客户的现实，直到平台真正解决那个客户的特定问题，无论它有多具体、多不光鲜。
Delta 这名字是好工程幽默。他们存在是为了关闭平台能做什么与这个特定客户需要什么之间的差距。
Shyam Sankar，Palantir 的 CTO、员工编号 13——正是我为问答赛囤的那种细节——用我永远甩不掉的说法描述灵感：法国餐厅服务员。不是把你的订单端到厨房的中间人，而是厨房在堂食区的真正延伸，行使判断、读桌子、调整。同一组织。只是站得离吃发生的地方更近。
反馈环跟部署一样重要。Palantir 把它描述成砾石路到铺装公路。FDE 在现场建点定制、略脏的东西解决真问题。那是砾石路。当同一条砾石路被五个不同客户踩进地里，Devs 把它铺上，它就成为平台功能。
定制工作不是浪费。它是客户付钱的产品发现。
那是真正优雅的商业模式，我仍略恼十五年来没别人抄它。
Sankar 2012 年 TED 演讲倚靠 J.C.R. Licklider 1960 年论文《Man-Computer Symbiosis》，主张有趣的前沿在人机耦合，而非机器单独。Licklider 1960 年写下那个，后来资助 ARPA 的计算研究，悄悄导致了互联网。
他的要点是：机器擅长的事与我们不同，工程问题住在结合部。
六十六年后再发现：结合部正是 AI 项目断裂之处。Licklider 会对此不可忍受地得意，他也有资格。
再给你下次团建一条。Licklider 把他的 ARPA 备忘录写给「星际计算机网络的成员与附属」。那是 1963 年。这人在互联网存在之前就把它当笑话命名了。
## 为什么所有人突然醒了
MIT 的 Project NANDA 2025 年发表报告《The GenAI Divide: State of AI in Business 2025》。人人引用的数字——包括几个我怀疑没读过数字之后的人——大约是：企业生成式 AI 试点中约 95% 没有可衡量的损益影响，对照大约 300–400 亿美元企业支出。
我会给那标题加注。这是调查。「可衡量的损益影响」是苛刻门槛。大量真正的早期基础设施工作不会出现在季度结果里。任何老兵都该对又圆又病毒式传播的统计怀疑。
剥掉戏剧性，底下的发现我愿拿自己的钱赌。
试点不是败在模型质量上。它们败在模型周围的一切上。
报告称之为学习差距。通用系统不会适应给定公司实际工作的特定、丑陋、无文档方式。这与我每周所见吻合。
## 餐厅问题
让我不用行话解释 Demo 到生产的差距，因为这是人人挥手带过而不解释的部分。
想想给朋友做晚饭和开餐厅的差别。
做晚饭：你认识那人，知道他们讨厌香菜，你有一次机会，边做边尝，如果平庸他们会客气。
开餐厅：每晚两百桌，周四送错鱼的供应商，卫生检查员，没提过自己有贝类过敏的人，服务中途炸锅坏掉，以及一个因停车而愤怒的人的一星评价。
AI Demo 是给朋友的晚饭。生产是餐厅。
那么两者之间实际坐着什么？
上下文。模型很聪明，却对你一无所知。它不知道「账户状态：7」意味着休眠但未关闭，因为 2011 年的一次迁移。它不知道你的三个系统对「客户」是什么意见不合。得有人去查清，而那人得被允许进房间。或者你用 Gemini Enterprise for Financial Services。忍不住打个广告！
管道。检索、分块、权限、新鲜度。如果你的 AI 能回答员工无权看的文档问题，你没有 AI 问题。你有事故。这工作不光鲜，却是工作的大部分。
Evals。这是分开成年人的那一项，我以前写过，所以短说。传统软件是确定性的。给定输入 X 永远返回 Y，你写测试断言正是那样。生成式系统是概率性的。同一问题周二可能给出略不同答案。
于是「它工作吗？」不再是是否问题，而变成测量。你需要一套带已知正确答案的真实样例分级集，以及你随时间盯着的分数。多数企业从未建过一套，因为他们整个质量流程假设确定性。
Agent 让这一切以算术方式更糟。一个走十步、每步 95% 可靠的 Agent，端到端大约 60% 可靠。那不是模型缺陷。那是乘法。任何交过分布式系统的人都感受过，因为那是把有脆弱依赖的微服务串起来的同一套数学。
修复不是更好的模型。是更窄的范围、检查点、重试、在昂贵步骤的人工确认，以及诚实测量。
而最后一英里按定义是定制的。每家企业的烂摊子都独特。他们的烂摊子，在真实意义上，是他们的竞争位置。三十年累积的决定、收购、监管补丁，以及一个叫 Raj 的人 2017 年离开前写的、人人都不敢碰的 Excel 宏。
## 两个非常昂贵的集成失败
1999 年 NASA 丢掉火星气候轨道器——一艘 1.25 亿美元的航天器——因为一队软件产出磅力·秒的推力值，另一队期望牛顿·秒。两边软件都正确。集成不正确。没人的模型错了。结合部错了。
2006 年 Airbus 发现图卢兹和汉堡工厂都在用 CATIA 设计软件，却是不同版本。A380 线束——每架飞机大约 500 公里电缆——在机身段会合时对不齐。大约两年延误和数十亿欧元，由同一公司两栋楼之间的版本不匹配造成。
如果 Airbus 能因集成问题丢掉那么多钱，你的银行绝对能因 PDF 解析器丢掉十一个月。
我的确实丢了。抱歉，我客户的丢了。我只是在场。
## FDE 整天实际做什么
先杀掉浪漫，因为周围有很多。
FDE 不是空降进来、狂敲九十分钟、在系统启动和管弦乐渐强时离场的天才。那是布鲁斯·威利斯电影，即便在电影里他也还得交工时单。
一次好对接的诚实形状大致如下。
### 第一到两周：闭嘴看
我合作过的最好的 Customer Engineer 或 Architect，前两周多数时间在听。跟运营团队坐一起。看某人手工做任务。问让房间安静的问题：「抱歉，你们为什么那样做？」
答案要么是「因为你没听过的一条监管」，要么是「没理由，我们一直这样」。你需要知道是哪一种。
那是切斯特顿的篱笆。在知道为什么有人建它之前，别拆田里的篱笆。企业里满是篱笆，大约一半是承重的。弄清哪一半是第一份工作。
第二周末的交付物不是幻灯片。是对三件事的短、直、书面答案。我们在建什么，工作在数值上意味着什么，什么会杀死这项目。他们总会文档化、写规格、写业务目标，并通常带上一位 FDE。
### 第三到六周：建丑陋版本
真实数据。真实系统。真实权限。故意窄的范围。一个工作流，一个团队，一个可衡量结果。这是 FDE 以为自己在建的黄砖路。
通常，这里建成的东西会不优雅，那是正确的。它是砾石路。目的是发现什么真正难，唯一办法是撞上它。
这也是 FDE 发现发现阶段没人提过的三件事的时候。API 限速到每分钟十次调用。只每周刷新的数据源。需要另一个时区、目前在休陪产假的人批准的步骤。
### 第七到十二周：让它存活
Evals。监控。失败模式。每笔交易成本——对 agentic 系统，如果没人盯，可以真的吓人。我见过 CFO 发现晚了时的脸。
然后是移交，多数厂商表演得极糟的部分。如果客户自己的团队在你离开后不能运行、调试和扩展那东西，你没有交付系统。你交付了一个带漂亮界面的依赖。
### 全程：把砾石送回家
FDE 建的每一个变通都是给产品组织的信号。每一个。
如果四个国家的四名 FDE 都手建同一个连接器，那不是四次英勇努力。那是缺失的产品功能，和断裂的反馈环。
这是组织最常搞错的。他们部署 FDE，庆祝客户结果，却从不建回工程的管道。你最终得到的是穿着产品公司 T 恤的非常昂贵的咨询臂膀。
> 快速冷知识。1947 年 9 月 9 日，Harvard Mark II 的操作员在继电器 70 里发现一只飞蛾。他们把它贴进日志本，写上「发现 bug 的第一个真实案例」。日志本在史密森，Grace Hopper 讲了几十年。
>
> 我带着巨大个人满足部署的纠正——通常换来呻吟：这并没有创造「bug」这个词。工程师至少从 1870 年代爱迪生起就用它指故障。正因如此笔记才说「第一个真实案例」。那是笑话，因为屋里人人已经知道这词。笑话本身就是证据。
>
> 也值得注意实际发生了什么。问题是被站在机器旁、物理看着它的人发现的。因此，FDE 的 FD。
## 我们在 Google Cloud 如何想这件事
公平警告。我在这儿工作。用你觉得合适的盐量读这一节。我会把营销压到最小——这容易，因为有趣的部分是结构性的，而非宣传性的。
在 Google Cloud Next 2026，Thomas Kurian 宣布了 7.5 亿美元合作伙伴基金，旨在在生态中构建和扩展 agentic AI。与此同时我们一直在建立 Forward Deployed Engineers，跨多国招聘，嵌入客户和大集成商，在生产环境里写生产代码。
那段话里重要的词是「与此同时」。不是「取代」。
Google Cloud 已有非常强的售前技术职能。Customer Engineer，尤其是 AI Specialist 变体，擅长它所做的事。技术发现、架构、原型、概念验证、赢下技术决策。那角色哪儿也不去，任何告诉 CE 他们的工作正被 FDE 吃掉的人都严重误读了局势。
差距从来不是「我们能不能证明这管用？」我们总能证明。
差距是那之后的十一个月。
所以 FDE 拥有那列表上没别人握着的问题。
过去十年多数时候，我们把那六个问题全扔给最近的人——通常是售前团队——然后纳闷为什么答案越往列表底下越稀薄。
还有第二件我以蛇吞尾方式觉得真好笑的事。我们也在建 AI agent 来自动化 FDE 工作的部分：上下文收集、环境发现、样板集成。
这要么深深讽刺，要么正是要点，取决于我心情。我诚实的读法是：它是要点。如果 FDE 的价值是判断和关系，自动化他们的苦力正确。如果 FDE 的价值是打字，我们有更大问题。
合作伙伴角度是多数人低估的那个。Google Cloud 永远不会有足够 FDE 坐进 JAPAC 每一家企业。没人会有。扩展机制是合作伙伴生态，而 FDE 的第二份工作——悄悄地杠杆更高——是让合作伙伴比我们更擅长这个。
解决一个客户问题的 FDE 有用。教会四个合作伙伴交付团队模式的 FDE，做了带乘数的事。这就是我们有 Partner FDE 角色的原因。
我爱维恩图——所以这儿有一张我用来跟团队描述角色的。
## 其他人会发生什么
这是人们真正想要、多数文章却胆怯躲开的一节。所以直说，来自一个看过角色被重组二十八年、并在那对话的给予端和接收端都待过的人。
Account Managers。楼里最安全的工作，也在悄悄变难。当结果成为销售单位而非容量时，你得谈业务结果而不是消费曲线。茁壮成长的是那些能对自己的客户说「我们不做那个用例，它不会管用」的人。能做到的比自称能做到的少。
Customer Engineers 和 AI Specialists。不受威胁。被重新定位。售前技术赢单是真工作，必须有人做。但门槛从「能 Demo」移到「能 Demo，并对生产会花什么、坏什么有知情看法」。一个能说「是的这管用，而这三件事会在第四个月咬你」的 CE，值三个只能做前半的。那种可信度复利很快。
Industry Solution 和 Platform Architects。在上升，我认为这尚未被广泛体会。Agentic 系统让架构更重要，不是更不重要。身份、权限、数据边界、审计轨迹、成本控制，以及 agent 凌晨三点做了热情过头的事时的爆炸半径。那全是架构。附带条件是：只产地图、从不走地形的架构师，会被两者都做的人温和挤到一边。如果你在行业语境里理解它——你很值钱！
Sales Specialists 和 overlays。真正承压，我宁愿说出来。当通用模型吸收能力时，窄产品深度迅速贬值。活下来的专家是有领域深度而不只是产品深度的人。理解贸易金融、或理赔裁决、或临床编码、并能把 AI 映射上去的人。产品知识现在半衰期以季度计。领域知识复利几十年。
Professional Services 和咨询。商业模式承真实压力，里面人人知道。Accenture 在 FY2025 记下大约 59 亿美元 GenAI 工作，听起来像胜利，同时又在重组，因为同一技术压扁传统金字塔。
如果初级顾问头两年是研究综合、做幻灯片和基础代码，而模型现在一个下午就能做，金字塔失去底座。金字塔曾是利润率。
工时与材料正被挤向结果和固定费用。那不是末日情景，而是完全不同的业务，需要完全不同的肌肉，被为旧业务优化的组织在飞行中尝试。
Partners 和 Systems Integrators。整幅图里最大的机会——如果他们动。他们有厂商装不出来的领域深度、本地关系、交付规模和行业语境。他们需要的是工程文化。真代码、真 eval、真生产所有权，而不是按容量计划堆人。
现在做那转向的合作伙伴，将拥有 JAPAC 企业 AI 的下一个十年。优化利用率的那些大约还能再好十八个月。
所有人。一个结构性变化比以上都重要。售前和售后之间的墙在倒下。它一直有点人为，是我们如何记账收入而非客户如何体验我们的产物。客户从未理解为什么承诺的人和建造的人从没见过面。
我花了多年向客户解释那分裂，从未有过一个解释能撑过追问。
> ELIZA 故事，因为它直接适用于你的试点。1966 年 MIT 的 Joseph Weizenbaum 写了 ELIZA，几百行程序，通过把你的陈述反射成问题来模仿罗杰斯式治疗师。粗糙。零理解。
>
> 他自己的秘书——完全知道它怎么工作——请他离开房间，好私下跟它说话。
>
> Weizenbaum 如此不安，以至于余生大量时间警告 AI。ELIZA 效应——我们把理解归给任何产出说得通文本之物的准备——是为什么你的指导委员会爱那个 Demo。也是为什么屋里没人问第四百份文档时会发生什么。
>
> 六十年后我们仍是同一物种。只是有了更好的 GPU。
## 谁在何时做什么
实用一节。如果你在立起 FDE 职能——作为厂商、合作伙伴，或自建的企业——这是我会在有钟跑着时实际做的。
### 第 0–30 天：大声决定这是什么
一页纸写下 FDE 对什么负责。我的版本是：具名账户的生产结果，加上回产品的反馈环。如果你不能用一句话写下，你即将创造一个没有所有者的昂贵资源池。
挑三到五个灯塔账户。不是你十大 logo。有真问题、会回电话的赞助人、以及实际存在的数据的账户。让其中一个不时髦，因为有趣模式很少来自人人都在看的试点。
现在解决资金之争。销售成本、交付成本，或可计费。这争论每个未解决版本都会在第四个月变成公开、当着客户的刀战。
点名产品对口人。工程里接收 FDE 所学的一个具体人类。不是「产品组织」。一个人，有名字，你什么都不发时会恼火。如果你是合作伙伴在搭，问我们或问 Partner FDE。
### 第 30–90 天：证明一次
一个客户，一个工作流，进生产。窄胜宽。一个能工作的东西胜过四个令人印象深刻的试点，在复述里值钱得多。
开始前给指标打基线。今天这要多久，今天多常出错，今天花多少。跳过这个你永远证明不了你帮了忙。最终有人会问。
第一周跟客户一起建 eval 集。他们的样例，他们对正确的定义，他们的签字。这对信任的作用超过任何季度业务回顾。
记录每个变通。每个 hack，每个手建连接器。那日志是伪装成你的产品路线图。
### 第 90–180 天：让它可重复
第二、第三次部署，故意在不同行业。你在找共同点，一次找不出来。
交付第一次砾石到公路转换。拿走现已出现三次的变通，弄进平台。然后在内部大声说出来。这是模型要么成真、要么悄悄退回咨询的时刻。
把合作伙伴当共同建造者而非观察者带进来。同一房间，同一仓库，同一站会。如果他们只参加每周读出电话会，他们什么也没学。
在内部发布失败。没管用的部署比三个管用的教得更多。那需要一种说出来可存活的文化，那是领导力问题而非 FDE 问题。
### 第 180 天起：制度化
建职业路径。如果 FDE 是死胡同，你最好的人做两轮就走。定义高级、Staff、Principal 意味着什么，以及他们迁往何处。
与产品工程双向轮岗。做过现场轮岗的产品工程师设计更好产品。做过产品轮岗的 FDE 建更可复用的东西。
衡量环，不只是交易。本季度有多少现场模式变成产品功能？如果答案是零，你没有 FDE 职能。你有品牌更好的服务团队。
## 招他们，以及我问的一个问题
市场注意到了。视你取谁的数据，FDE 招聘贴文在 2025 年同比增大约 700% 到 1100%。Live Data Technologies、Revealera 和 Indeed 都落在那范围，与其说是精确测量，不如说是警笛。美国中位底薪集中在 17–18.5 万美元，Principal 在股权前可达 29 万美元。
据报 OpenAI 在大约一年内把 FDE 组织从 2 人扩到约 140，然后又在上面转出单独的部署实体。Anthropic 在 Applied AI 团队内运行 FDE，直接在客户环境建 MCP 服务器和 agent 评估。
人人在大约十八个月内得出同一结论，要么意味着它正确，要么意味着我们都读了同一篇博文。
我喜欢的一个数据点。在大约一千条 FDE 招聘贴文样本中，Python 出现在 66%，TypeScript 在 35%。那告诉你真实东西。这是全栈画像，会建后端和人实际用的界面的人。不是研究科学家画像。FDE 交应用，不是论文。
我按顺序找什么。
1. 他们交过真人用过的东西，并为它值过班。凌晨两点被叫永久改变一个人如何设计系统。没有替代，也没法在面试里假装。
2. 他们能跟非技术运营经理谈话而不居高临下。巨大过滤器。去掉数量惊人的其他方面很强的工程师。
3. 他们舒服当大约三周客户领域里房间里最无知的人。这主要是自我管理。
4. 他们把事做完。现场杰出工程师的失败模式是漂亮的 80%，没别人能跑。
5. 他们写得清楚。FDE 的第二产品是让八千公里外的人能做正确决定的书面更新。
以及我问的问题：
告诉我一件你为客户建的东西，然后发现他们用法跟你意图完全不同。你做了什么？
平庸答案是关于再培训用户。好答案是关于改产品。伟大答案是关于他们意识到用户是对的、他们误解了问题、以及那让他们付出什么的那一刻。
既然这问题已公开、人们大概会编答案，我已经准备好下一个了！！！
## 无视手册的施乐技术员
这是整篇我最爱的历史片段，科技圈几乎没人知道。
1980 年代，施乐 PARC 派人类学家 Julian Orr 研究公司的复印机维修技术员。领导层假设工作直截了当。按文档化诊断流程走，换指示的零件，继续。他们在让那些手册出色上投了大量。
Orr 发现的完全是另一回事，1996 年出版为《Talking About Machines: An Ethnography of a Modern Job》。所有科技史迷必读。
技术员几乎不用手册。
他们实际做的是互相讲战争故事。早餐时，停车场里，电话上。「你知道那款间歇卡纸的型号吗？如果客户办公室潮湿、用的是便宜纸，查第三个辊。」知识活在在现场待过的人之间的口头传统里。每台机器被理解成三角形：技术员、机器，以及用设计师从未想象的方式使用它的客户。
施乐管理层为不存在的工作建了系统。真正的工作是社交的、叙事的、即兴的。
那是整件事，早四十年。
你的 FDE 是技术员。战争故事是实际资产。如果你的组织没有结构化方式让雅加达部署故事两个月后到达悉尼部署，你就是 1985 年的施乐，为没人在做的工作写漂亮手册。
## 摘要
给想看 TLDR 的人。
我用最先想通它们的人命名这些规则。部分因为那样好记，部分好让你在指导委员会里说出口时听起来比「我读过一篇帖子」好。
- **大野规则。** 去站在工作实际发生的地方。丰田让工程师站在车间粉笔画的圆圈里直到他们停止猜测。你的版本是十二周待在客户的烂摊子里，而不是十二页关于它的幻灯片。
- **毛奇规则。** 谁能看见地形谁做决定。任何必须飞八千公里才能获批的决定，会在问题改形之后才到达。
- **Delta 规则。** 先建丑陋版本，再铺路。你已建过两次的任何变通，都是还没人提交的产品功能。记下来，送回家，交给工程里一个具名人类。
- **Orr 规则。** 战争故事是资产。施乐技术员在早餐上修复印机，而不是照手册。如果雅加达部署故事不能在两个月内到达悉尼，你在为没人做的工作写漂亮手册。
- **1969 规则。** 工程师一旦变成行项目，就有人开始数他们。在宣布之前解决谁出钱，而不是第四个月当着客户公开吵。
然后是数字。三个灯塔账户，因为五个意味着谁都得不到你的注意力，一个意味着你什么也学不到。九十天到一个无聊的东西在生产里跑，因为十二个月买给你的是华丽试点和一次重组。两个指标：它是否上线，以及你的现场团队建的任何东西是否实际进了产品。一位具名负责人，和一位你什么都不发时会注意到的工程对口人。
如果你的仪表盘最终带着十一个指标，恭喜，你建了墙纸。
如果你担心这又是一个三年后会被改名的岗位，放松，绝对会。IBM 1960 年叫它 Systems Engineer。Palantir 2006 年叫它 Delta。我们 2026 年叫它 Forward Deployed Engineer。大约 2032 年会有人改名并写一篇非常自信的帖子说发明了它。统计上那人是我，请你们仁慈一点。
工作本身一寸没动。到工作所在之处，自己看，建东西，然后待够久以发现它是否管用。那就是全部诀窍。没人把它包装成方法论，因为没人搞清怎么按它计费。
毛奇用地图和马到达。大野在工厂地板上画圆圈让成年工程师站进去。Watson 1920 年为它建了整所学校，然后——作为 Watson——让人人唱歌。Orr 在施乐停车场发现整件事正在发生，在早餐上，在一场没人授权的谈话里。
然后大约每十年我们忘一次，再从头想通，通常大约在 Demo 十一个月、再多个 PDF 解析器之后。
## 是时候建造了
如果你有一个 Demo 超过一个季度的 Agent，问题几乎肯定不是模型。把这发给拥有生产决策的人，然后去找愿意在烂摊子里坐十二周的人。
厚脸皮广告，跟上次一样。这是我在 JAPAC 建的团队。如果你在这地区，盯着一个拒绝变成产品的漂亮试点，来跟我们谈。把丑陋系统带来。我们更喜欢丑陋系统。
如果你答对了 1969 年那题，告诉我。我总在找能出测验题的人。
## 强制公司免责声明
这些意见是我的，由同一个曾自信告诉满屋客户迁移只需六周的个人神经网络产出。
我在 Google Cloud 工作，负责 JAPAC 的 AI 与数据 Forward Deployed Engineering 团队。所以是的，我写了大约五千词论证我在招的工作很重要。你应按此加权。披露一直是这儿的目标。中立从未在桌上。
我在文中点名了其他公司，包括至少两家直接竞争者和一家我从未获准看见其软件的公司。它们没有赞助、付钱，也不知道这存在。
这里没有任何财务建议、架构建议、招聘建议，或 19 世纪马具建议。如果你读了这文，立刻重组整个技术现场组织，然后搞砸了，那是你、你的 CFO，以及你周二毫无警告改了头衔的那个人之间的事。我绝对零责任。
鉴于主题，完全透明：Gemini 帮编辑了这文，但想法、结构、大约 3700 词是我的。上回马项圈是真的。这回继电器 70 里的飞蛾是真的。关于两者的意见，就我仍能判断的而言，是我的。
撰写本文时没有 Systems Engineer 被拆包。那发生在 1969 年，坦白说，我们都还在恢复中。