你有没有注意到一个正在发生的错位——
AI 写代码越来越强了。DeepSeek V4 写个 CRUD 接口几秒钟，豆包 Seed 2.0 能自动修 Bug，OpenCode 可以在你睡觉的时候跑完一个完整的开发任务。代码生成这件事，正在从"人写"变成"AI 写"。
但另一边，代码写出来之后，让它真正在业务里跑起来、被人用起来、在客户现场落地——这个环节，反而越来越没人管了。
不是大家不想管，是管不了。因为落地需要的不是写代码的能力，是写代码之外的能力。而这些能力，AI 给不了你。
这篇文章写给两种人：一种是想入局 AI 但不知道从哪下手的，另一种是已经在局里但发现自己在干 AI 最擅长的活。两种人面对的是同一个问题——AI 时代的软件交付，到底应该怎么干？
一、FDE 不是驻场开发的升级版
FDE——Forward Deployed Engineer。中文叫"前线部署工程师"。听起来像驻场开发的换皮版，这可能是对 FDE 最大的误解。
我给你两组词，你对比一下：
| 驻场开发 | FDE | |
|---|---|---|
| 需求来源 | 甲方告诉你做什么 | 你要去发现客户真正的问题 |
| 交付标准 | 代码写完、验收通过 | 系统在客户现场跑起来、客户自己能用了 |
| 做完之后 | 走人，下一个项目 | 抽象共性的东西，沉淀成工具和方法 |
| 价值在哪里 | 写代码的能力 | 让代码产生业务价值的能力 |
驻场开发是需求确定了你去实现。FDE 是需求不确定，你要去发现、去定义、去把客户说不清的东西变成可执行的方案。
长得像，内核完全不同。把 FDE 当驻场干，就废了。
二、AI 越强，FDE 反而越值钱
现在回到开头那个错位。
AI 越来越擅长执行：写代码、跑测试、部署上线、甚至修 Bug。OpenCode 的 Agent 可以在你睡觉的时候自己定位问题、修代码、提 PR。
但 AI 做不了什么？
- 做不了客户现场的需求澄清。客户说"我想做个自动化"，你得跟他聊半小时才能发现他真正要的是"自动把 Excel 里的数据对接到 ERP，还要保留修改痕迹"。AI 猜不到这一步。
- 做不了跨角色的翻译。业务方说的话技术听不懂，技术说的方案业务听不懂。你得在中间翻译。
- 做不了抽象和沉淀。做完一个客户，把共性的东西抽出来变成下一个客户能用的资产——这不是大模型能干的活，这是人的判断。
所以 FDE 的价值不是被 AI 取代，而是被 AI 放大了。
AI 把执行变便宜了——代码生成、测试、部署，这些成本趋近于零。但"让执行落地"这件事，变得更贵了。因为落地需要的是 AI 做不了的那部分能力。
这也是为什么 2026 年 OpenAI、Anthropic、Google 同时在扩编 FDE 岗位，字节和华为在抢着招。不是他们在赶时髦，是他们都发现了一个共同的事实：AI 写代码的能力越强，把 AI 接到业务里的人就越值钱。
三、FDE 的核心能力第一条：表达
这是门槛。过不去，后面都不用谈。
FDE 大部分时候不是在写代码，是在说话。
- 客户说不清自己要什么，你得能问出真正的问题。不是"你要什么功能"，是"你现在怎么做的、卡在哪、希望变成什么样"。问不对，后面全错。
- 技术团队听不懂业务场景，你得能翻译。把"财务部每个月要对账"翻译成"一个定时任务，从 A 系统拉数据，按 B 规则匹配，异常走人工审批"。翻不对，做出来的东西客户不认。
- 项目做完了，你得教会客户用。不是扔一本手册，是让他真的会用、敢用、出了状况知道找谁。
FDE 做不下去，大部分时候不是技术不行，是沟通先崩了。
四、FDE 的核心能力第二条：业务架构力
不是去客户那里写 CRUD 的。
你要能看懂客户的业务怎么跑的：流程怎么走、数据在哪、决策谁做、卡点在哪。然后把这些东西抽象成业务架构——不绑定这个客户、这个场景，而是能平移复用的结构。
行业认知决定你在客户说第一句话的时候，能不能听懂他在说什么。
五、FDE 的核心能力第三条：抽象→沉淀→中台
这是 FDE 跟驻场开发最本质的区别，也是最值钱的部分。
驻场开发做完一单就是一单。FDE 做完一单，要把共性的东西留下来：
- 这个行业的数据长什么样
- 接入流程有哪些固定步骤
- 对接踩过什么坑
- 哪些环节可以用工具自动化
沉淀成工具、模板、脚本、文档。一个客户做完，下一个客户 80% 不用从头来。多个客户攒下来，就形成了中台能力。
做一单、留一手，越做越轻松。 这是 FDE 真正值钱的地方，不是写代码，是长能力。
六、FDE 装备清单
FDE 不需要精通一门语言或框架，需要一套能解决问题的工具箱。分两层：思考装备和干活装备。
思考装备（方法论）
| 方法论 | 不是学什么 | 是帮 FDE 解决什么 |
|---|---|---|
| DDD | 不是学四层架构怎么写代码 | 跟客户聊半小时，从他含糊的描述里找出业务边界，判断"这个是通用的还是这个客户特有的" |
| 事件风暴 | 不是学一种 workshop 形式 | 进场第一天，拉上客户业务方和技术方，几小时内把业务全流程画出来，对齐认知 |
| SDD | 不是学一种开发流程 | 客户说"我要做个 XX"，你能从目标倒推：先不问用什么技术，先问"你想解决什么问题、怎么判断做完了" |
| 业务建模 | 不是学 UML 画图 | 客户数据在哪、流程怎么走、决策谁做——能快速建模，不依赖客户给你写清楚需求 |
干活装备（技术栈）
不要求你全栈精通，但要有"串起来"的能力：
- 能看懂前后端代码，知道自己改哪一段
- 会调 MCP 工具，能把 AI 系统接到客户的 ERP、CRM 里
- 能写胶水代码，把不同系统之间的数据打通
- 懂基本部署运维，容器、CI/CD、日志至少能上手
这些东西组合起来，就是支撑你从进场到交付的全套能力。
但光有装备不够，你得知道这些装备搭在什么地基上。你调 MCP 工具，总得有个底座来接吧？你写胶水代码，总得有个网关来透传吧？你沉淀出来的中台能力，总得有个地方放吧？
AI SaaS 底座长什么样、每一层由什么构成、你和团队可以从哪开始搭——下一篇拆开讲。
关于 ArchAIHarness
这篇文章是「看懂 AI 与智能体」专栏的一部分，由 ArchAIHarness 持续输出。
ArchAIHarness 是一套面向 AI 时代软件工程的人机协同架构哲学与公开工程资产，主张：
架构师定义秩序，AI 在秩序中生长。人立法，AI 执行，体系审计。
如果你也希望 AI 在明确的架构边界内协作，而不是在混沌中碰运气，欢迎到 GitHub 上看看我们在做什么：
- 组织主页：github.com/ArchAIHarne… — 了解完整理念与资产全景
- 本专栏：
zhuanlan-ai-and-agents— 所有文章的源码与发布记录 - 实践指南：
docs— 架构哲学、工程方法和落地指南 - 开源工具：
agent-workflows— 可复用的 AI 协作 Agents、Skills 与 Tools - 工程样例：
framework— DDD + AI 协作的工程底座，展示如何在开发中融合 AI
Engineered by Architects · Empowered by AI · Audited by Discipline
