SDD 与 FDE：AI 时代最热的一对「方法论 + 角色」
AI 写代码越来越强之后，工程圈的焦虑点悄悄换了位置：不再是「AI 会不会写」，而是「我们有没有把它用对、并且真的落地到生产」。
这两年冒出来的两个热词正好对应这两个焦虑：SDD（Spec-Driven Development，规格驱动开发） 管「怎么让 AI 做对的东西」；FDE（Forward Deployed Engineer，前沿部署工程师） 管「怎么让 AI 真的在客户的生产环境跑起来」。一个是方法论，一个是角色；看似不搭，其实是同一件事的两面。
这篇把它们讲清楚：是什么、为什么现在火、具体怎么做、以及有哪些坑。
术语歧义说明（先排除）：SDD 也常被当作「Software Design Document（软件设计文档）」、FDE 也有人指「Frontend Development Engineer（前端开发工程师）」。本文按 2025–2026 年 AI 工程语境写：SDD = Spec-Driven Development，FDE = Forward Deployed Engineer。若你问的是另一种含义，告诉我我另写一篇。
文中行业数据来自公开报道，统计口径与时点不一，已尽量标注来源，引用请以原文为准。
一、SDD：别再直接让 AI 写代码
1.1 它要解决的痛
先说一个很多人踩过的坑：把模糊需求丢给 AI，它一定会自由发挥——顺手改掉公共组件、删掉历史兼容逻辑、自行补全你没说的需求，最后留下难以维护的代码。问题不在「AI 不会写」，而在人没把规格讲清楚。
Vibe Coding（凭感觉写）在小原型上很爽，但系统一大就会「悄悄失败」：上下文漂移、逻辑冲突、技术债累积。SDD 的主张很直接：先写清规格，再让 AI 按规格开发。
1.2 核心比喻：规格是「人和 AI 之间的契约」
- 人负责 What / Why：范围、边界、关键决策、验收标准；
- AI 负责 How：任务拆解、代码实现、跑测试的闭环；
- 规格是**「活契约」（living contract）：它是唯一事实来源**，代码只是它的产物之一。
把安全要求、性能指标、设计系统这些非功能性需求前置写进规格，AI 从第一行代码起就在合规轨道上——而不是等 code review 才发现跑偏。
1.3 典型工作流（七步）
各阶段的关键产出（不同工具命名略有差异，但思路一致）：
| 阶段 | 回答什么问题 | 产出 |
|---|---|---|
| Constitution | 项目级长期规则？ | 技术栈/架构/质量/安全约束 |
| Specify | 系统要做什么？ | 只写功能行为，不写技术实现 |
| Clarify | 还有哪些隐性假设？ | 消除歧义、回写规格 |
| Plan | 技术上怎么实现？ | 接口、数据模型、状态机、架构 |
| Tasks | 怎么原子化执行？ | 可独立验证的小任务清单 |
| Implement | 按 Tasks 做出来 | 代码 + 测试 + 提交 |
| Validate | 是否符合原始规格？ | 逐条验证 + 全量回归 + 人工审查 |
注意两个细节：
- 阶段之间要设人工审查关卡（review gates）——出问题时先判断是「需求错、设计错、任务拆错」还是「代码写错」，而不是反复打补丁；
- Specify 阶段刻意不谈技术——把「做什么」和「怎么做」分开，是这套流程最值钱的纪律。
1.4 工具生态（2026）
| 工具 | 特点 | 路线 |
|---|---|---|
| GitHub Spec Kit | 微软/GitHub 团队主导，用斜杠命令强制走完五阶段 | Spec-First（规范先行） |
| Kiro（Amazon） | 把 Spec 流程内置进 AI IDE，围绕 requirements.md / design.md / tasks.md | 内置化 |
| OpenSpec | 分离「变更（change）」与「系统规格（spec）」 | Spec-Anchored（规范锚定），适合已有项目迭代 |
| Tessl | AI-native，强调结构化、版本化的上下文管理 | 上下文工程 |
| BMAD | 角色驱动的多智能体编排 | 多 Agent |
1.5 成熟度分级（很重要的一组坐标）
SDD 不是「非黑即白」，公开资料把它分了几档：
Spec-First 规范先行：先写 spec，再让 AI 写代码
↓
Spec-Anchored 规范锚定：spec 长期存在，作为改动的锚点（适合老项目）
↓
Spec-as-Source 规范即源码：人只维护 spec，代码是派生物
↓
Spec-to-Application 规范直接编译成应用（最激进）
给团队的建议：从 Spec-First 起步——只要「先写规格再动手」这一条纪律，收益就很大；Spec-as-Source 这类激进形态，等你团队的规格质量和评审机制成熟了再说。
1.6 SDD vs Vibe Coding vs TDD
- vs Vibe Coding：Vibe 追求速度与探索，适合原型；SDD 追求准确与可维护，适合严肃系统；
- vs TDD：互补，不是替代。SDD 更靠前，解决「到底要做什么」；TDD 更靠后，解决「代码有没有做到」。没有 SDD 的 TDD，可能只是把错误的需求测得很完整。
1.7 什么时候不必上 SDD
一次性脚本、极小改动、低风险文案调整——上 SDD 是给自己找事。它的甜点区是：跨模块变更、多人协作、高要求功能（支付/权限/风控）、需要长期维护的系统。
二、FDE：把 AI 真正塞进客户的生产环境
2.1 它是什么
FDE 是长期嵌入客户现场、亲手写生产代码、把产品（如今多是 AI 系统）在客户自己的环境里跑通、并对生产结果负责的工程师。 两个关键词：嵌入、负责。
它的源头是 Palantir（约 15 年前）：再强的平台，交到客户手里也会被旧系统、脏数据、高度定制的工作流拖住；传统「卖软件 → 培训集成商 → 撤离」只会做出漂亮 demo。Palantir 的解法是把最顶尖的全栈工程师直接派进客户现场，对着真实数据写生产代码、亲自负责上线与运维。
Palantir 内部把 FDE 叫 「Delta」（Δ），做产品的工程师叫「Dev」，一句经典概括是：
「Dev 是为很多客户构建一个能力，Delta 是为一个客户构建很多能力。」
还配了一套 Echo × Delta 结构：Delta 写代码，Echo（部署策略师，Deployment Strategist）是客户行业专家，用「现场的语言」挖需求。
2.2 和 SE / SA / TAM / 驻场开发的区别
关键差别只有两个：是否提交生产代码、责任的终点在哪。
- 售前/解决方案架构师：技术选型、架构规划，签约后往往交接离开；
- 顾问：交付的是报告与建议，不是跑起来的系统；
- 驻场外包：卖劳动力，听指挥干活，经验留在客户那边；
- FDE：写进客户仓库、从 PoC 一直负责到生产运维，并把现场经验回流成可复用能力。
有个一句话的真伪测试：
问：「系统上线六周后在生产挂了，谁负责？」
- 答「客户 IT 团队」→ 这个组织里没有 FDE 职能；
- 答某个具体的人（有系统权限、有责任）→ 那才是 FDE。
2.3 为什么在 AI 时代爆红
业界的共识判断是：部署鸿沟（Deployment Gap）远大于能力鸿沟（Capability Gap）——模型之间的差距，远没有「能不能在真实业务里用起来」的差距大。
数据支撑（来源时点请注意）：
- MIT Project NANDA《The GenAI Divide》调查 500+ 家企业：约 95% 的生成式 AI 项目对损益没有可量化影响；成功的少数普遍做了深度定制与流程整合——这正是 FDE 干的活；
- 2025 年 FDE 职位年增幅被报道高达 1,165%（Bloomberry 研究，报道于 CIO Taiwan）；英国《金融时报》统计 2025 年 1–9 月 FDE 职缺月增超 800%；
- 供给端稀缺：有猎头估计，全球真正「为企业部署过生产级 AI 代理系统」的工程师不到一万人。
AI 系统为什么不能「自助部署」：工作流必须定制、数据集成极复杂、幻觉输出要有人管、合规无法模板化。Palantir 把这套方法论称为 Ontology（本体论）——不是「把数据接进来」，而是把企业的对象、关系、规则、动作、权限、反馈，翻译成 AI 能理解、系统能执行、组织能治理的结构。
2.4 谁在抢这类人
- OpenAI：组建部署相关公司（报道称联手 PE 投入数十亿美元），并收购 AI 咨询公司补充 FDE 团队；
- Anthropic：与多家金融机构合资做企业 AI 服务，公开招聘 FDE；应用 AI 团队扩编，岗位偏向「Applied AI Engineer」；
- Google Cloud：设立 GenAI FDE 职位，内部代号 Embedded Builder，计划招募数百人；
- 其它：Scale AI、xAI、Databricks、Cohere、Cursor、Salesforce 等；咨询侧也有对应变体（如 Accenture 的 RDE）。
薪酬参考（报道数据，时点以来源为准）：Anthropic FDE 约 20–30 万美元；OpenAI 总包约 35–55 万美元区间；Palantir 历史中位约 16.7 万美元。
2.5 日常与技能
约一半时间写代码（集成、数据转换、把生产级应用 ship 出去），一半面向客户（需求探查、现场演示、结对编程），出差比例可达 50%。
技能要求在四个方向都有生产级深度：Python 与 LLM 集成、RAG、MLOps/生产运维、云原生；此外是业务流程理解力、沟通带宽，以及「在模糊环境里独立推进」的能力——Anthropic 的岗位要求里甚至写了「保持低自我感与协作态度」。
一个直观案例：OpenAI 曾派 FDE 协助农机厂商 John Deere，做出把化学喷洒量降低 60%~70% 的智慧农业工具。
2.6 风险：被用滥的「弱版本 FDE」
热度一高，标题就会被滥用：只做演示、只接工单、不对生产结果负责的岗位也自称 FDE——招来的人 burnout，客户也拿不到价值。
判断标准仍然是 ownership 落在哪：JD 里只写「支持客户」「做技术演示」，却从不提「写生产代码」「对上线结果负责」，那大概率不是真 FDE。
三、为什么这两个词是一体两面
| SDD | FDE | |
|---|---|---|
| 层面 | 方法论/流程 | 角色/组织形态 |
| 解决 | 让 AI 做对的东西（意图 → 规格 → 验证） | 让 AI 真的跑起来（嵌入 → 集成 → 生产负责） |
| 载体 | 规格文件、审查关卡、工具链 | 人：写生产代码 + 直面业务 |
| 共同前提 | AI 让「写代码」变便宜了，瓶颈转移到了「定义」与「落地」 | 同左 |
对个人的启发（尤其我们这些写前端/写业务的工程师）：
- 写作与定义能力正在升值：能不能把模糊需求写成可执行、可验证的规格，正在变成核心技能——这跟我们这个 blog 一直在强调的「schema/协议/契约」是同一件事（见 Zod 系列、MCP）；
- 「把东西跑起来」比「写出来」更难：FDE 的流行说明，集成、部署、运维、对结果负责这些「最后一公里」的活，AI 短期内替不掉；
- 两条都能马上试：给下一个需求先写一页规格（Spec-First 的最小版本）；给手头的项目多做一点「上线后谁负责」的功课。
顺带一提：本站 frontend-agent 系列 手写过 agent 的工具循环，InkOS 拆解 里那套「模型提议、宿主执行、以落盘为准」——本质也是同一思路：把意图固化成约束，让机器在约束里干活。SDD 只是把这条原则搬到了整个软件生命周期。
参考
- 字节面试官：别再直接让 AI 写代码了，先学会 SDD 规格驱动开发（阿里云开发者）
- 超越 Vibe coding！Spec-Driven Development 如何降低 AI 写程式的混乱（TechOrange）
- Spec-Driven Development in 2026（Devoteam）
- FDE 前线部署工程师，让 AI 真正落地的角色（CIO Taiwan）
- OpenAI、Anthropic 都开始押注 FDE，FDE 才是 Agent 时代的 PMF 范式？（BAAI Hub）
- 企業買了 AI 卻跑不起來，FDE 成為科技業最搶手的職位（TechOrange）
- FDE 前線部署工程師，你看好嗎？（阿里云开发者）
声明：本文为行业观察整理，无任何厂商合作；涉及数字均来自上述公开来源，统计口径与时点不一，请以原文/官方为准。方法论部分（七步流程、成熟度分级）为公开资料的归纳，不同工具实现有差异。