周一早上九点，小林到了客户的运营部。
他不是来做产品演示的，也不是来签合同的。他的工牌上写的是「Forward Deployed Engineer」——一个在钉钉内部新设立的岗位，外部还没有对应的职称。
上周客户提了一个需求：「每天有 20 个人整理会议纪要，能不能用 AI 提效？」
普通工程师听到这句话，想到的是做一个会议纪要工具。
小林想到的是：
会议
↓
纪要
↓
任务拆解
↓
责任人
↓
审批
↓
提醒
↓
知识沉淀
他要做的不是一个纪要工具，而是一个 会议 Agent。
什么是 FDE？
FDE 的全称是 Forward Deployed Engineer，直译是「前沿部署工程师」。但钉钉给它的定义是：
企业 AI 工作流设计师 + Agent 工程师 + 客户成功负责人。
他们不是传统实施顾问，也不是售前，而是帮助客户完成从 Business → Workflow → Agent → Product 的闭环。
整个工作可以抽象成：
企业业务
↓
业务调研（Business Discovery）
↓
工作流抽象（Workflow）
↓
Agent 设计（AI Native）
↓
AI Coding 快速实现
↓
客户验证
↓
沉淀为钉钉标准产品能力
所以， FDE 其实就是钉钉产品能力的前沿实验室。
在 工作流即软件，软件即 Agent 中，我讨论过为什么企业真正缺的不是软件，而是把企业工作流重构成 AI Native 工作流。FDE 就是来做这件事的人。
一天怎么过？
09:00 — 业务调研（Business Discovery）
小林到客户现场，不是带着 PPT，而是带着一个问题清单：
- 这个岗位的 SOP 是什么？
- 哪些动作重复、耗时、易出错？
- 现在的工具链是什么？哪些是断裂的？
- 如果 AI 介入，哪些环节可以自动化？
- 自动化之后，谁来验证结果？
他花两个小时跟着运营总监走了一遍「会议纪要」的完整链路：
- 开会（1 小时）
- 手写纪要（30 分钟）
- 拆解任务（20 分钟）
- 分配责任人（10 分钟）
- 等审批（2 天）
- 催进度（每天 15 分钟）
- 归档到知识库（10 分钟）
一个会议纪要，从开完会到归档，平均耗时 4 天。
小林在笔记本上画了一个图：
会议纪要耗时分布（4天 = 96小时）
等待审批: ████████████████████████ 48小时 (50%)
等待回复: ████████ 16小时 (17%)
手写纪要: ███ 6小时 (6%)
拆解任务: ██ 4小时 (4%)
分配责任人: █ 2小时 (2%)
催进度: ██████ 12小时 (13%)
归档: █ 2小时 (2%)
其他: ███ 6小时 (6%)
真正在「干活」的时间不到 20%，剩下 80% 全是等待。
这和 把组织当成产品来打造：AI 原生组织的 MVP 设计 中提到的案例如出一辙——14 天链路里 9 天等待。
11:00 — 工作流抽象（Workflow）
小林回到临时工位，开始画工作流。
他不是在画流程图，而是在回答一个问题：
这个岗位的工作，能不能拆成多个专业 Agent 协作？
他画了一个「运营岗位 Agent 矩阵」：
运营岗位
↓
┌─────────────────────────────────────────────┐
│ 会议 Agent 记录 + 拆解 + 分配 + 跟进 │
│ 数据 Agent 查表 + 分析 + 报告 │
│ 审批 Agent 发起 + 催办 + 提醒 │
│ 知识库 Agent 归档 + 检索 + 推荐 │
└─────────────────────────────────────────────┘
不是一个超级 Agent。
而是多个专业 Agent 协作。
在 企业业务流程 AI 化的决策框架 中，我讨论过为什么「AI 参与了但人力没降」——因为大多数企业只是给每个环节加了一个 AI 建议按钮，没有重构工作流本身。
小林的工作流抽象，是在回答这个问题：
如果从零开始设计这个岗位，AI 应该承担哪些动作？
14:00 — Agent 设计（AI Native）
下午，小林打开 Claude Code，开始设计「会议 Agent」的架构。
他不是在写代码，而是在定义：
会议 Agent
├─ Memory: 会议历史 + 任务状态
├─ Tools: 钉钉会议 API + AI 表格 + 审批流
├─ Triggers: 会议结束事件
└─ Outputs: 纪要 + 任务卡片 + 审批请求
他花了 30 分钟用 AI Coding 写了一个 Demo：
from dataclasses import dataclass
from typing import Optional
@dataclass
class MeetingAgent:
"""会议 Agent：从纪要到归档的全链路自动化"""
meeting_id: str
memory_scope: str = "workspace"
def generate_minutes(self, transcript: str) -> dict:
"""生成会议纪要"""
return {
"summary": self._summarize(transcript),
"action_items": self._extract_actions(transcript),
"decisions": self._extract_decisions(transcript),
}
def assign_tasks(self, action_items: list) -> list:
"""拆解任务并分配责任人"""
tasks = []
for item in action_items:
task = {
"title": item["description"],
"assignee": self._infer_owner(item),
"deadline": self._infer_deadline(item),
"approval_required": item["priority"] == "high",
}
tasks.append(task)
return tasks
def trigger_approval(self, task: dict) -> str:
"""发起审批流"""
if task["approval_required"]:
return self._create_approval_card(task)
return "auto_approved"
# generated by hugo AI
重点不是代码质量。
而是： 两小时之内，他验证了一个业务想法。
16:00 — 客户验证
下午四点，小林带着 Demo 回到运营总监办公室。
他没有说「这是我们的解决方案」，而是说：
「我画了一个初稿，你帮我看看哪里不对。」
运营总监看了五分钟，指出了三个问题：
- 任务分配的「责任人推断」逻辑不对——应该按「项目归属」而不是「发言频率」
- 审批流太简单——高优先级任务需要「部门经理 + 项目总监」双签
- 缺少「进度同步」——任务状态变更应该自动推送到会议群
小林当场改了三版，运营总监点头：「这个方向对了。」
一天之内，从调研到验证，闭环了。
18:00 — 产品沉淀
晚上，小林回到酒店，写了一份「模式识别报告」：
本周客户调研（3家）
共同模式：
- 会议纪要 → 任务拆解 → 审批 → 跟进（3/3）
- 痛点集中在「等待审批」和「催进度」（3/3）
- 现有工具链断裂：会议系统 ≠ 任务系统 ≠ 审批系统（3/3）
建议：
- 进入「钉钉会议 Agent」产品规划
- 复用 [工作流即软件] 中的 Agent 矩阵模式
- 参考 [VOC 闭环] 中的 Harness Engineering 纪律
他不是在做项目交付。
他是在做 产品创新来源。
如果十家公司都在做「会议总结」，那就应该进入「钉钉会议 Agent」产品规划，而不是继续实施。
一个人怎么可能懂这么多？
有人会说：FDE 要求太高了。又要懂业务，又要懂 Agent，又要会 Coding，还要有产品感——这样的人存在吗？
答案是： 不需要一个人全部精通，而是需要一个人在 AI 辅助下全部及格。
传统岗位分工的假设是：每项能力都需要 10 年积累才能胜任。但 AI Coding 改变了这个等式：
| 能力 | 传统要求 | AI 时代要求 |
|---|---|---|
| Coding | 5 年全栈经验 | 会用 Claude Code，一天写一个 Demo |
| Agent 设计 | 深度学习背景 | 理解 Memory + MCP + Tool Calling 概念 |
| 产品感 | 3 年产品经理 | 能识别「三个客户都在做同一件事」 |
| 业务理解 | 行业专家 | 能跟着客户走一遍 SOP，画出工作流 |
小林不是全栈工程师，也不是产品经理。他原来是一个做解决方案的技术人员，但 AI Coding 让他能在两小时内验证一个业务想法。
真正的门槛不是技术能力，而是业务抽象能力——这也是为什么业务抽象占 40% 权重。
FDE 的五大能力
小林的这一天，展现了 FDE 需要的五大能力。
一、业务抽象能力（Business）— 40%
这是最重要的能力。
能够做到：
- 理解企业组织架构
- 理解岗位职责
- 理解 SOP
- 找到真正耗时的工作
- 找到 AI 可以替代的部分
小林听到「20 个人整理会议纪要」时，没有想到做一个纪要工具，而是想到了一个会议 Agent。
第一能力不是 Coding，而是：
Workflow Thinking（工作流思维）
二、Agent 设计能力（AI）— 25%
能够设计：
一个岗位
↓
多个 Agent
↓
多个 Workflow
↓
多个 Tool
例如销售岗位：
CRM Agent
报价 Agent
合同 Agent
会议 Agent
客户画像 Agent
售后 Agent
不是一个超级 Agent。
而是多个专业 Agent 协作。
所以需要理解：
- Agent Memory
- MCP
- Tool Calling
- Workflow
- Multi-Agent
- Eval
三、AI Coding 能力（Engineering）— 15%
未来 FDE 不需要写很多代码。
但是必须：
100% 会 AI Coding。
例如一天之内完成：
- 一个审批系统
- 一个机器人
- 一个知识库
- 一个 Agent
- 一个 MCP Server
熟练使用：
- Claude Code
- Codex
- OpenCode
- Cursor
- Gemini CLI
重点不是代码质量。
而是：
一天可以验证十个业务想法。
速度远比代码重要。
四、产品沉淀能力（Product）— 10%
这是传统实施最大的缺陷。
很多项目：
客户 A
↓
定制
客户 B
↓
重新定制
客户 C
↓
继续定制
能力完全没有沉淀。
FDE 应该做的是：
客户 A
↓
发现模式
客户 B
↓
验证模式
客户 C
↓
确认模式
↓↓↓
变成钉钉产品能力
FDE 不是项目经理。
而是：
产品创新来源。
五、客户经营能力（Customer Success）— 10%
优秀 FDE 应该能够：
不是回答：
客户想要什么？
而是回答：
客户真正需要什么？
需要做到：
- Workshop
- Design Thinking
- ROI 分析
- AI Adoption（推动 AI 落地）
- Change Management（组织变革）
AI 项目最大的失败原因，往往不是技术，而是组织没有真正改变工作方式。
培养体系
相比传统的软件培养体系：
开发
↓
高级开发
↓
架构师
↓
技术专家
AI 时代更适合演进为：
| 阶段 | 核心能力 | 目标 |
|---|---|---|
| AI Coding Engineer | AI Coding、全栈开发 | 一天完成一个可运行 Demo |
| Workflow Engineer | 流程建模、SOP 分析 | 能把岗位工作抽象为工作流 |
| Agent Engineer | Agent、MCP、RAG、工具调用 | 能设计多 Agent 协同系统 |
| FDE | 客户调研、方案设计、快速交付 | 两周内帮助客户完成 AI 工作流上线并验证价值 |
| AI Product Manager | 产品抽象、平台能力沉淀 | 将多个客户实践沉淀为标准产品 |
| AI Business Leader | 行业方案、生态建设 | 推动行业 AI 转型和规模化复制 |
FDE 的真正使命
如果用一句话概括，我认为是：
深入客户业务，用 AI 重构企业工作流，并将客户实践持续沉淀为钉钉平台能力。
这里有一个很重要的思维转变：
- 传统实施：交付一个项目
- 传统售前：卖出一个产品
- 传统产品经理：规划一个功能
- 钉钉 FDE： 通过 AI Coding 快速验证企业工作流，把一次次客户实践沉淀成可复用的平台能力
这也意味着，钉钉的 FDE 不应隶属于传统实施体系，而更像连接 **客户、产品、研发和生态 **的「前沿产品工程师」。
他们直接参与真实业务场景，用最快速度完成 业务发现 → Agent 构建 → 价值验证 → 产品沉淀 的闭环。
如果把这一定位做成组织能力，那么 FDE 不只是一个岗位，而会成为钉钉 AI 时代最重要的增长引擎： 每一个客户现场都是产品创新的来源，每一个成功的 Agent 都有机会演化为钉钉下一项标准能力。
你的企业里，有没有一个角色能同时懂业务、懂 Agent、懂产品？还是继续用售前+实施+产品经理的传统模式？欢迎留言讨论。