FDE 不是一个新职位，是 AI 时代软件交付的新方式。越早看懂这个逻辑，越早卡位。你有没有注意到一个正在发生的错位—— - 掘金
你有没有注意到一个正在发生的错位—— AI 写代码越来越强了。DeepSeek V4 写个 CRUD 接口几秒钟，豆包 Seed 2.0 能自动修 Bug，OpenCode 可以在你睡觉的时候跑完一个你有没有注意到一个正在发生的错位—— AI 写代码越来越强了。DeepSeek V4 写个 CRUD 接口几秒钟，豆包
FDE 不是一个新职位，是 AI 时代软件交付的新方式。越早看懂这个逻辑，越早卡位。
魏祖潇
2026-06-30
202
阅读7分钟
你有没有注意到一个正在发生的错位——
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