时长约 75–90 分钟 | 难度 ⭐⭐⭐
3.1 为什么是"三角"，而不是一张能力清单
上一课我们说了，FDE 的稀缺性来自"三块能力的交集"。这里必须先解释一个问题：为什么是三角关系，而不是一张打勾清单？
因为清单可以"补齐"，而三角必须"同时成立"。
技术实现
╱╲
╱ ╲
╱ ╲
╱ ╲
解决方案 ────── 交付闭环
如果它是一张清单，你可以说"我现在只会技术，业务那块以后再说"。但三角的意思是：
- 只有技术 + 业务 → 你能诊断问题，但拿不出东西
- 只有技术 + 交付 → 你能干活，但干的是别人指定的活
- 只有业务 + 交付 → 你能推动事，但做不出系统
任何两边都不产生结果，必须三边同时在场。
💡 这也是为什么它很难招人。传统岗位只需要一边或两边：研发要技术，咨询要业务，实施要交付。要三边同时成立，交集自然非常小。
三块的权重会因公司和项目而异（厂商侧偏技术，顾问侧偏业务），但一块都不能是零。
3.2 第一块：技术实现 —— 能搭系统
这一块的核心，可以用一句话概括：
能把"模型能力"翻译成"可运行的系统"。
注意是"可运行的系统"，不是"能跑通的代码"，也不是"能演示的原型"。它包含五个具体能力：
① AI 编程：把原型速度提上来
熟练使用 Cursor、Claude Code 这类工具，快速搭出可用原型。
这里有一个认知转变很关键：过去的工程师以"我手写得多"为荣，但在 FDE 场景里，速度比优雅重要。因为你要在两周内让业务部门"明天上班就能点开用"，手写全栈来不及。
⚠️ 但注意：这不等于"AI 写的东西不审"。涉及权限、金额、删除动作的逻辑，必须自己写并复核。第 9 课会专门讲这条边界。
② Agent 设计：想清楚"它不能做什么"
除了能做什么，更要能定义不能做什么：
- 权限模型：它能碰哪些数据？
- 工具调用边界：它能执行哪些动作？（能不能发邮件？能不能改数据库？）
- 失败兜底：它错了会怎样？有没有人工确认环节？
- 发布闸门：什么条件下才允许正式给业务方用？
💡 新手最容易只关注"能力"，老手先定义"边界"。因为在企业场景里，一个会乱动的 Agent 比一个不会做的 Agent 危险得多。
③ MCP / 工具集成：安全地接上企业已有系统
企业里已经有一堆系统在跑：CRM、ERP、数据库、工单、审批流。FDE 的价值不来自"新造一个系统"，而来自让模型安全地接入这些已有系统。
MCP 这类标准化协议的意义就在这里：把"接入"从一次性定制，变成可复用的能力。
④ RAG 与知识库
企业级知识问答是 FDE 最常交付的形态之一。这里的关键不是"会用某个框架"，而是理解检索质量的真正影响因素。
一句话结论（细节见 rag-deep-dive 课程）：
先调切分，再调检索，最后调 Prompt。
顺序颠倒的人，会在 Prompt 上耗掉大量时间，而问题其实在切分上。
⑤ 评测工程：把"感觉不错"变成"可以验收"
这一块最容易被工程师忽略，但在 FDE 场景里权重极高。因为企业要的是可验收的结果，不是"我感觉比昨天好"。
三类比"准确率"更贴近交付的指标（第 9 课展开）：
- 工具选择正确率——该调这个工具的时候，它调对了吗
- 连续成功率——一个完整任务链跑完不断链的比例
- 静默失败检测——看起来跑通了，答案其实是错的
3.3 第二块：解决方案与业务 —— 能听懂需求
核心一句话：
能把模糊期待（"我们想上 AI"）翻译成可定义、可验证、可交付的方案。
① 行业诊断：快速抓住核心对象、流程、痛点
进一个陌生行业，不需要成为专家，但要在很短时间内回答三个问题：
- 这个行业的核心对象是什么？（订单？病历？工单？）
- 钱和人卡在哪条核心流程上？
- 哪些环节是"大家都抱怨但已经习惯了"的？
② 场景识别与排序：找到最该先做的那个
"想上 AI"的需求通常有一堆。FDE 的价值在于排序，而不是全都做。第 8 课会给出一个五维排序矩阵。
💡 排序能力比实现能力更能区分 FDE 的水平。因为做错第一个场景，后面就没有第二个机会了。
③ ROI 测算：把改善算成财务能确认的账
这是工程师最陌生、也最容易逃避的一块。
"省了多少人时""涨了多少产出"——这些必须能换算成财务口径上的数字。第 10 课会专门讲方法。
④ 变革管理：推动员工真的用起来
系统上线了不等于被使用。阻力通常来自两个地方：
- "怕被替代"——需要给出角色升级的路径，而不是只讲提效
- "改变习惯的成本"——新流程必须比旧流程更省事，而不是更麻烦
3.4 第三块：交付闭环与软技能 —— 能拿到结果
核心一句话：
让企业尽快不再需要你。
① 灯塔项目策略
选对第一个场景，做出可衡量的结果，再用这个结果去换信任、换资源、换第二个场景。
② 利益相关者协调
一个企业里通常有四类人，目标各不相同：
| 谁 | 他要什么 | 你该怎么对他 |
|---|---|---|
| 业务方 | 少加班、不出错 | 给他看得见的省事 |
| IT | 别给我埋雷 | 讲清权限与运维边界 |
| 管理层 | 投入产出比 | 给他财务口径的账 |
| 财务 | 数字要对得上 | 基线 + 可复现的算法 |
③ 知识沉淀
把经验变成 SOP、知识库、培训材料。沉不下来 = 白做一遍。
④ 持续迭代
上线后跟踪使用数据，把投诉和失败转成改进动作。
3.5 三块必须都沾：三种典型的"残缺形态"
这一节是本课最有诊断价值的部分。对照看看你在哪一种：
形态一：技术强，业务弱
表现：拿到需求就开干，做出来的东西"技术上很漂亮，但业务说不是我要的"。
常见于：优秀工程师转型。
卡点：缺的不是技术，是"往上游追一层"的习惯。客户给的是他自己想到的解法，不是问题本身。
形态二：业务强，技术弱
表现：很会谈，需求梳理得很清楚，但交付物是 PPT 和方案文档，没有能点开用的东西。
常见于：顾问、售前、解决方案岗转型。
卡点：在企业眼里，这仍然是"咨询"而不是"交付"。而第 4 课会讲，这两者的付费逻辑完全不同。
形态三：两边都强，交付弱
表现：技术好、也懂业务，但东西交出去就没人用；或者只有他会跑，一撤场就停摆。
常见于：偏研发型的 FDE。
卡点：把"系统上线"当成终点。缺的是灯塔策略、变革管理、SOP 沉淀这些"软"能力——恰恰是决定结果能不能留下的那一层。
⚠️ 三种形态里，形态三最隐蔽。因为前两种当事人自己会疼，第三种是别人疼：你觉得交付完了，客户觉得被扔在原地。
3.6 一个反直觉判断：AI 工具越便宜，FDE 越值钱
这是第 2 课留下、现在可以完整回答的问题。
AI 工具越便宜（搭 Agent 的门槛越低） → 被消灭的是什么？
被消灭的，是"把系统搭出来"这件事的操作难度。
没被消灭的，是这四件事：
- 理解企业现场——知道真实工作流长什么样
- 定义真问题——在一个含糊的诉求里找到真痛点
- 设计验收标准——什么算成功，写得可测量
- 推动组织采用——让人真的用起来
这四件事没有一件能靠"更强的模型"自动解决，因为它们全都依赖"进入现场、和人打交道、承担责任"。
💡 换个角度说：技术那块的门槛在下降，另外两块的门槛没有降，甚至因为期望值变高而在上升。
那么第 2 课的最后一个反问呢——FDE 会不会也被工具便宜化干掉？
答案取决于你把 FDE 定义为"会用工具搭系统的人"，还是"能对业务结果负责的人"。
- 前者：会被干掉，而且正在被干掉
- 后者：工具越强，他的杠杆越大
这也是为什么第 4 课必须先划清"FDE 不是谁"——划错了，你就会被当成一个可替代的执行角色。
3.7 能力三角自测
给自己打分（每块 1–5 分），然后看总分结构而非总分。
技术实现
- 能用 AI 编程工具在 2 天内做出一个能点开用的原型
- 能说清一个 Agent 的权限边界和失败兜底
- 能独立把 RAG 的检索质量调上去
- 能为一套系统写出可验收的评测指标
解决方案与业务
- 进一个陌生行业，两小时内能画出它的核心流程
- 能在 10 个"想上 AI"的需求里排出优先级并说明理由
- 能把"省了 3 个人力"换算成财务口径的数字
- 能识别出"怕被替代"这类隐性阻力
交付闭环
- 能设计一个 2–4 周出结果的第一场景
- 能同时应对业务方、IT、管理层、财务四类诉求
- 能写出让别人独立复现的 SOP
- 撤场后，客户还能继续跑第二个场景
💡 用法：不要算总分。看哪一块的平均分最低——那就是你接下来的补课方向，也基本决定了你更接近第 3.5 节的哪种残缺形态。
💡 提示
- 三块不是并列的，是有优先级的：第一块决定你能不能进场，第二块决定你选得对不对，第三块决定你的活能不能留下。顺序上，第二块常被工程师跳过，第三块常被所有人低估。
- 能力三角是"入场资格"，不是"成长路径"。不要等三块都到 5 分才动手——带着短板去做一个真实项目，比刷完三块再开始快得多。
- 第三块（交付闭环）最容易被当成"软技能"而轻视。它不是情商，是一套有具体方法的工程活动：灯塔策略、验收标准、SOP、撤场演练。
⚠️ 常见坑
坑一：拿"我会用 AI 工具写代码"当技术实现。 技术实现的标准不是"我能生成代码"，是"我能定义一个系统不能做什么"。只会生成、不会设边界，做不出企业敢用的东西。
坑二：把"听懂需求"当成"理解业务"。 听懂需求是入门。理解业务意味着你能预判：这个改动会牵动哪个部门、谁会反对、为什么反对。
坑三：认为"交付完成"就是上线。 上线只是第三块的起点。真正完成的标准是第 11 课那个问题：你撤场一个月后，他们自己能转吗？
坑四：用总分给自己打分。 三块各 4 分（总分 12）和三块 5/5/2（总分 12）是完全不同的两种人。看结构，不看总分。
📝 思考题
-
结构题：用 3.7 的清单给自己打分，写出你的最低分那块，以及一个具体的补法（"多学学业务"不算，要能落到下一周能做的动作）。
-
形态题：判断你自己更接近 3.5 节的哪种残缺形态？说出一个你身上真实发生过的例子作为证据。
-
判断题：下面四种说法，哪些是"技术强业务弱"的典型症状？
- 甲："客户说要个看板，我三天就做出来了，他说不错但没在用。"
- 乙："我习惯先问他现在这件事怎么做的、多久做一次、哪里最烦。"
- 丙："需求文档写得很清楚，我照着做完了。"
- 丁："上线后我每周看一次使用数据。"
-
反问题（本课最难）：如果 AI 工具便宜化真的会淘汰一批"FDE"，你会怎么判断自己是会被淘汰的那一批，还是杠杆变大的那一批？ 给出一条可检验的标准。
✅ 本节小结
- 能力三角不是清单，是三边同时成立的关系；任何两边都不产生结果
- 技术实现的核心是"把模型能力翻译成可运行的系统"：AI 编程、Agent 设计（重点是边界）、MCP 集成、RAG、评测工程
- 解决方案与业务的核心是"把模糊期待翻译成可验证的方案"：行业诊断、场景排序、ROI 测算、变革管理
- 交付闭环的核心是"让企业尽快不再需要你"：灯塔策略、干系人协调、知识沉淀、持续迭代
- 三种残缺形态：技术强业务弱（工程师常见）、业务强技术弱（顾问常见）、两边强交付弱（最隐蔽，因为疼的是客户不是你）
- 反直觉判断：AI 工具越便宜，FDE 越值钱——被消灭的是"搭系统"的操作难度，没被消灭的是理解现场、定义问题、设计验收、推动采用
- 自测要看结构不看总分
下一课预告：第 4 课划一条线——FDE 不是谁。我们会把咨询顾问、实施顾问、售前、SRE 和 FDE 放在六个维度上比一遍，然后给出判断"真 FDE 还是高阶外包"的三个分水岭。这一课决定你做的到底是不可替代的活，还是可被替换的执行。
