# FDE 系统知识手册
---
> 基于 Lean-FDE 官网公开资料的结构化归纳与工程化补全。
---
> 生成方式：`python scripts/build_handbook.py`。
---
## Lean-FDE 系统知识库：阅读指南
> 抓取日期：2026-08-14（Asia/Shanghai）
> 研究范围：`leanfde.com` 无需登录即可访问的公开页面
> 性质：公开资料的结构化归纳，不是官网原文复制，也不代表官方认证口径
### 1. 一句话总览
FDE（Forward Deployed Engineer）不是“去客户现场写代码的人”，而是**在客户现场串联业务、产品、工程、数据、安全和管理层，对 AI 从问题定义到生产采纳的结果闭环负责的人**。[S1][S2][S3]
Lean-FDE 官网的整体逻辑可归纳为：
```text
为什么：AI 项目大量停留在 Demo，根因常是交付断层，而不是模型不够强
↓
是什么：FDE 是客户现场的 AI 交付负责人，以生产采纳、业务影响、复用资产为结果
↓
怎么做：现场发现 → 价值诊断 → 协同设计 → 构建评测 → 试点采纳 → 复用沉淀
↓
如何建模：用 LDO 把价值、对象、状态、规则、受控 Action、数据权利和结果证据连起来
↓
如何规模化：用 C6、D1–D9、FDE Squad、评审门、Portfolio 和 Industry Pack 复制能力
```
### 2. 文档地图
| 文档 | 回答的问题 |
|---|---|
| [01-FDE知识体系](01-FDE知识体系.md) | FDE 是什么、为什么出现、和传统岗位有何不同 |
| [02-端到端交付方法论](02-端到端交付方法论.md) | 一个 FDE 项目从线索到生产采纳如何推进 |
| [03-LDO与Lean-SIM](03-LDO与Lean-SIM.md) | 如何选场景、建模业务世界并形成行动闭环 |
| [04-工程架构与工具栈](04-工程架构与工具栈.md) | 方法工具、工程组件和生产架构如何组合 |
| [05-组织能力与人才体系](05-组织能力与人才体系.md) | FDE Squad、能力模型、成熟度和人才评估 |
| [06-评测治理与生产采纳](06-评测治理与生产采纳.md) | 如何定义指标、评测、风控、上线和采纳 |
| [07-90天落地路线图](07-90天落地路线图.md) | 企业如何用 90 天建立首个 FDE 闭环 |
| [templates/FDE项目模板包](templates/FDE项目模板包.md) | 可直接复制使用的 20 类项目模板 |
| [08-来源索引与抓取说明](08-来源索引与抓取说明.md) | 资料从哪里来、覆盖到哪里、有哪些限制 |
### 3. 关键术语
| 术语 | 本知识库中的含义 |
|---|---|
| FDE | Forward Deployed Engineer，前线部署/交付工程角色；重点是现场结果闭环，不等同于驻场开发 |
| Gemba | 现场主义：观察真实工作，而不是只听需求描述 |
| LDO | Lean Dynamic Ontology，精益动态本体；价值约束下的可执行业务世界模型 |
| Lean SIM | Lean Scenario Innovation Method，精益场景创新方法；从战略任务到规模运营的场景生产体系 |
| Agent PRD | 对 Agent 的目标、边界、上下文、工具、权限、异常、评测和责任作出约定的产品责任协议 |
| HITL | Human in the Loop，人在回路；包括建议、确认、接管、复核等模式 |
| MVS | Minimum Viable Scenario，最小可行场景；用真实闭环验证最大不确定性 |
| POC | 验证关键假设的受控实验，不等于功能演示 |
| Pilot | 在有限部门、流程、用户和风险边界内的真实试点 |
| PRR | Production Readiness Review，生产准备评审 |
| Portfolio | 以证据证明能力和结果的作品集，而非只展示 Demo |
| Industry Pack | 从项目沉淀的行业模板、连接器、评测集、实施手册和运营机制 |
### 4. 建议阅读路径
- **管理者/业务负责人**：01 → 02 → 06 → 07。
- **产品/咨询/售前**：01 → 02 → 03 → 模板包。
- **AI/工程团队**：02 → 03 → 04 → 06。
- **组织与人才负责人**：01 → 05 → 07。
来源代号 `[S1]` 等统一见 [08-来源索引与抓取说明](08-来源索引与抓取说明.md)。
---
## 01 · FDE 知识体系
### 1. 定义
依据官网公开定义，FDE 是**客户现场的 AI 交付负责人**：统筹场景、技术、治理和采纳，推动 AI 系统进入生产运营；衡量标准不是“功能做完”，而是**生产采纳、业务影响和复用资产**。[S2][S3]
这一定义包含四层责任：
1. **现场责任**：理解真实角色、任务、流程、约束和例外。
2. **价值责任**：把“想要 AI”改写为有基线、指标和证据口径的业务假设。
3. **系统责任**：定义人机协同、数据/工具接口、权限、异常和验收边界。
4. **采纳责任**：推动试点、运营反馈、管理层决策和资产沉淀。
FDE 不必独自实现所有工程工作；其价值是“前台串联与结果闭环”，后台由 AI、数据、工程、安全、运维和平台团队提供专业支撑。[S3][S5]
### 2. 为什么 FDE 会出现
官网对企业 AI 失败的判断是：组织往往不缺能做原型的人，而缺少把战略目标、管理层预期、一线流程、异常处理、人机协同和工程交付统一起来的人。[S1]
典型断层如下：
| 断层 | 表面现象 | 实质问题 |
|---|---|---|
| 需求断层 | 客户说“做个智能体” | 没有真实任务、角色和触发条件 |
| 价值断层 | 只说节省时间 | 没有连接收入、质量、风险或组织能力 |
| 流程断层 | 把 AI 塞进旧流程 | 没重设责任、确认、升级和回退 |
| 评测断层 | Demo 看起来不错 | 没有真实样本、失败分类和上线阈值 |
| 治理断层 | 功能可运行 | 权限、审计、数据用途和责任边界缺失 |
| 采纳断层 | 系统上线 | 用户不改变工作方式，反馈不进入迭代 |
| 资产断层 | 项目结束 | 连接器、评测集和行业模板没有沉淀 |
因此，FDE 的问题域不是“模型能力”单点，而是：
```text
现场事实 × 业务价值 × 人机协同 × 工程系统 × 评测治理 × 组织采纳
```
任何一项接近零，整体结果都可能失败。
### 3. FDE 与传统岗位的边界
| 角色 | 典型中心任务 | FDE 对其补充的部分 |
|---|---|---|
| 售前/解决方案 | 方案、演示、商务推进 | 把表层需求推进为可验证的生产闭环 |
| 咨询顾问 | 诊断、建议、治理推动 | 对可运行系统、评测证据和持续采纳形成闭环 |
| 产品经理 | 需求、优先级、产品规划 | 覆盖模型不确定性、异常流程、评测和生产治理 |
| 项目经理 | 范围、进度、成本、交付 | 对业务假设、采纳效果和复用资产同步负责 |
| 架构师/工程师 | 架构与系统实现 | 把真实现场、价值指标和工程边界连接起来 |
| 数据/算法团队 | 数据、模型、效果 | 把模型输出嵌入受控 Action 和业务结果反馈 |
官网明确强调：FDE 不是更技术的售前，也不是更商业的顾问；区别在于**以现场和待验证价值假设为起点，以生产采纳和资产复用为结果**。[S1][S3]
### 4. FDE 的工作对象
FDE 管理的不是一张“需求列表”，而是一个相互约束的交付系统：
- **人**：Sponsor、管理层、业务 Owner、一线用户、产品、工程、安全、运维。
- **事**：任务、决策、审批、交接、异常、反馈、复盘。
- **物**：客户、订单、设备、合同、知识、文档等业务对象。
- **数**：基线、状态、指标、样本、模型结果、行动轨迹。
- **权**：身份、用途、最小权限、人工确认、审计、回退。
- **果**：采纳、效率、质量、风险、增长、复用率和学习速度。
### 5. 成功标准
建议把“成功”分成四级，不用单一模型准确率代替项目结果：
1. **可演示**：功能链路跑通。
2. **可验证**：真实样本上达到预设阈值，失败可分类。
3. **可生产**：满足权限、稳定性、监控、审计、人工确认和回滚要求。
4. **可采纳/可复用**：真实用户持续使用，业务指标改善，产物能被下一项目复用。
官网最终把成功标准集中为三个结果：[S2][S5]
- **Production Adoption**：进入真实工作流并被持续采用。
- **Workflow Impact**：对业务流程和经营结果产生可测影响。
- **Reusable Assets**：形成连接器、模板、评测集、手册和平台能力。
### 6. FDE 的核心原则
1. 共识早于方案。
2. 价值必须可定义、可证伪、可归因。
3. 先看现场事实，再抽象产品与系统。
4. AI 介入意味着重构流程和责任，而不是给旧流程加按钮。
5. 模型只是系统组件；数据、工具、权限、HITL、评测和运营共同决定结果。
6. 每个高风险 Action 都必须可授权、可审计、可回退。
7. POC 验证最大风险，不以做全功能为目标。
8. 上线不是终点，采纳和反馈循环才是结果。
9. 每个项目都应沉淀可复用资产。
10. 结论必须由证据支持，失败与停止也是有效学习。
---
## 02 · FDE 端到端交付方法论
### 1. 官网公开的八步交付闭环
官网的 FDE Delivery Loop 给出八步：[S5]
| 步骤 | 关键动作 | 主要产物 | 退出条件 |
|---|---|---|---|
| 1. 客户研究 | 行业压力、组织、关键人、预算、历史基础 | Account Brief、Stakeholder Hypothesis | 线索真实且有进入现场的切口 |
| 2. 现场观察 | 访谈、流程走查、系统演示、影子工作 | Gemba Notes、Shadow Workflow | 模糊兴趣变成有证据的问题 |
| 3. 价值流分析 | 标注任务、系统、文档、等待、返工、风险 | Value Map、Baseline、Waste Diagnosis | 找到高价值介入节点 |
| 4. Agent PRD | 定义角色、任务、知识、工具、权限、HITL、评测 | Agent PRD、HITL Map、Solution Canvas | 方案可构建、可验收、可治理 |
| 5. MVP 构建 | RAG、工具调用、接口、交互、日志和基础安全 | Prototype、接口契约、运行证据 | 最大价值/技术风险获得验证 |
| 6. 评测治理 | 评测集、失败样本、复核、权限、回滚、审计 | Eval Report、PRR、Decision Log | 达到试点阈值或明确停止/调整 |
| 7. 试点上线 | 有限部门/流程上线，跟踪效果、成本、稳定性、采纳 | Pilot Canvas、Adoption Plan、Value Ledger | 形成生产采纳和可测流程影响 |
| 8. 复用沉淀 | 模板、连接器、评测集、运营面板、实施手册 | Industry Pack、产品反馈、复盘 | 下一项目可复用且责任人明确 |
### 2. 实际项目建议使用的六道 Gate
下面是对官网八步、六周训战和 Project Gate 的整合。它是本知识库的操作化版本，不等同于官网未公开的“十动作”原表。
#### Gate 0 · Opportunity：是否值得进场
- 有真实业务 Owner/Sponsor。
- 问题发生频率、损失或风险足够高。
- 能进入真实流程并取得最低限度数据/样本。
- 六至十二周内存在可验证的最小闭环。
- 不以预设技术方案描述问题。
**决策**：进入 Discovery / 暂缓 / 拒绝。
#### Gate 1 · Discovery：问题是否真实、边界是否清楚
- 至少覆盖 Sponsor、业务 Owner、一线用户等两类以上角色。
- 事实、解释、假设分开记录。
- 有 As-Is 工作流、时间/质量/风险基线和异常样本。
- 明确受益人、责任人、范围和停止条件。
**产物**：Project Charter、Stakeholder Map、Discovery Pack。
#### Gate 2 · Design：方案是否可构建、可治理
- 明确 Job/Task/Decision 和目标工作流。
- 确定 AI 自动化、建议、确认、接管的责任模式。
- 明确数据来源、工具接口、最小权限、异常升级和回退。
- 业务、工程、治理三方可理解并同意验收口径。
**产物**：Workflow Redesign、Agent PRD、HITL Map、Solution Canvas。
#### Gate 3 · Build–Eval：最大风险是否被真实证据验证
- 样本来自真实任务而非纯合成演示。
- 质量、业务、安全指标和阈值事先确定。
- 失败分类、红队、人工复核和复现材料完整。
- 有 Go / Adjust / Stop 决策记录。
**产物**：Prototype Evidence、Eval Set、Failure Log、Eval Report、PRR。
#### Gate 4 · Pilot–Adoption：是否形成生产采纳
- 试点人群、流程、周期、责任和风险边界明确。
- Sponsor 有资源和管理动作，一线反馈可进入迭代。
- 同时观测使用、质量、业务、成本、风险和稳定性。
- 扩大、暂停、回退、停止条件量化。
**产物**：Pilot Canvas、Adoption Plan、Sponsor Brief、Value Ledger。
#### Gate 5 · Scale–Compound：是否值得复制
- 价值证据可复核，归因边界清楚。
- 连接器、提示/工作流、评测集、权限策略、手册已版本化。
- 可配置部分与客户定制部分已拆分。
- 复用负责人、SLA、淘汰规则和路线反馈明确。
**产物**：Industry Pack、Portfolio、复盘报告、产品路线输入。
### 3. 三条并行工作流
FDE 项目不应按“先业务、再技术、最后上线”串行推进，而应让三条流并行收敛：
#### 3.1 价值流
```text
经营目标 → 现场痛点 → 基线 → 可证伪假设 → 试点指标 → 结果归因 → 投资决策
```
#### 3.2 产品与工程流
```text
任务/决策 → 上下文 → 工作流 → Agent PRD → 数据/工具契约 → MVP → 生产系统
```
#### 3.3 治理与采纳流
```text
利益相关者 → 权限/责任 → HITL/异常 → 评测/审计 → Sponsor 机制 → 用户采纳 → 运营反馈
```
每道 Gate 都应由业务、工程、治理三方共同评审，避免一条流先完成、另外两条流最后补票。
### 4. 每周运行节奏
官网建议项目每周同步业务假设、评测、上线风险、客户反馈和阻塞点。[S5] 可操作化为：
- **周一**：目标、假设、最大风险、样本计划。
- **周中**：真实任务走查、原型/评测、失败样本复盘。
- **周五**：业务 Owner + 工程 + 治理联合评审，记录 Go/Adjust/Stop。
- **持续**：Action、人工确认、异常、成本、时延、结果统一进入证据账本。
### 5. 决策纪律
1. 不因 Demo 漂亮而扩大范围。
2. 不用模型指标替代业务指标。
3. 不在没有 Owner、基线和真实样本时启动 POC。
4. 不把权限、审计、回滚延后到上线前。
5. 不把“用户接受培训”当作“用户完成采纳”。
6. 不因已经投入而回避停止；停止条件要在实验前写下。
---
## 03 · LDO 与 Lean SIM
### 1. 三套方法的关系
```text
Lean SIM：从战略与产业任务中选择、定义并运营高价值场景
↓
LDO：围绕岗位决策构建最小充分、可授权、可行动的业务世界切片
↓
FDE Delivery Loop：把切片实现为系统，完成评测、试点、采纳和复用
```
- **Lean SIM 回答“做什么、为何投资、如何形成场景组合”**。[S7]
- **LDO 回答“系统最少要理解什么世界、谁能做什么、结果如何反馈”**。[S4]
- **FDE 回答“谁进入现场把它交付并形成生产结果”**。[S2][S5]
### 2. 精益动态本体 LDO
#### 2.1 定位
官网把 LDO 定义为：以可验证业务价值为牵引、以“最小充分本体切片”为交付单元，把现实对象、时空事件、动态状态、规则模型、受控行动、数据权利和结果证据统一起来，并通过业务与学习双闭环持续演化的平台无关方法。[S4]
它与知识图谱的区别不是“图更复杂”，而是责任层级不同：
| 层级 | 重点 |
|---|---|
| 静态知识/本体 | 事实、概念和关系如何统一表达 |
| 运行本体 | 组织如何基于状态、规则和权限采取 Action |
| LDO | 哪些语义和 Action 值得为可验证价值保留，何时扩展或淘汰 |
#### 2.2 十要素元模型
1. 价值目标。
2. 业务场景与岗位任务。
3. 产业/业务对象。
4. 对象关系。
5. 事件与时间。
6. 状态与指标。
7. 规则、模型与约束。
8. Action、审批与回退。
9. 身份、数据权利与用途。
10. 证据、版本与价值结果。
缺少 Action，系统只是分析；缺少状态，系统只是静态知识；缺少结果证据，系统不能学习；缺少价值，语义只会变成库存。[S4]
#### 2.3 “六定”方法
| 六定 | 核心问题 | 主要产物 |
|---|---|---|
| 价值定场景 | 为什么做，改善什么结果 | 价值树、基线、目标 KPI |
| 场景定决策 | 谁在何时需要做什么选择 | 决策卡、角色、触发、约束 |
| 决策定本体 | 做出决策最少要理解什么 | 最小充分本体切片 |
| 本体定数据与模型 | 状态由哪些数据、规则、模型计算 | 数据合约、模型合约、证据要求 |
| 模型定行动 | 输出如何进入真实业务 | Action 合约、审批、写回、回退 |
| 评测定运营 | 如何扩展、调整或淘汰 | 评测集、轨迹、价值账本、迭代清单 |
#### 2.4 “六化”转换
```text
表字段 → 对象化 → 关系化 → 状态化 → 逻辑化 → 行动化 → 资产化
```
- 对象化：围绕客户、订单、设备等现实对象，而非源表名。
- 关系化：表达供应、持有、交易、风险传导等现实含义，而非技术 Join。
- 状态化：用事件和时间表达当前、历史、预测、计划和行动状态。
- 逻辑化：把指标、规则、模型和置信度绑定到对象与场景。
- 行动化：把判断转为有授权、有审批、有写回和回退的 Action。
- 资产化：对切片、数据合约、模型和 Action 做版本、授权、复用和运营。
#### 2.5 双闭环
```text
业务闭环：事实 → 状态 → 风险/机会 → 建议 → 受控 Action → 经营结果
学习闭环：轨迹/结果 → 失败评测 → 数据集更新 → 模型/规则更新 → 本体更新
```
真正关键的数据不只是“过去发生了什么”，还包括：人在什么信息条件下做了什么决定、是否采纳 AI 建议、最后产生什么结果。[S4]
### 3. Lean SIM 精益场景创新
#### 3.1 方法结构
官网将 Lean SIM 概括为“一核、双轮、五层”：[S7]
- **一核**：可核验的场景价值。
- **双轮**：业务价值飞轮 + 数据智能飞轮。
- **五层**：战略层、场景层、能力层、治理层、运营层。
核心链路：
```text
场景定义任务 → 任务定义模型 → 模型定义数据 → 执行结果反哺数据与模型
```
#### 3.2 场景五级粒度
| 粒度 | 示例 |
|---|---|
| L1 战略场景域 | 综合交通现代化、城市安全韧性 |
| L2 行业集成场景 | 港航贸易协同、交通能源融合 |
| L3 业务场景 | 路口自适应控制、航线适飞服务 |
| L4 场景任务 | 拥堵识别、报关状态核验 |
| L5 原子 Skill | 对象对齐、规则校核、匿名化 |
FDE 项目通常应从 L3/L4 进入交付，最终把稳定能力沉淀为 L5 Skill；直接从 L1 跳到“建设平台”容易产生范围失控。
#### 3.3 八步场景闭环
1. 战略锚定。
2. 机会扫描。
3. 场景原子化。
4. 价值假设。
5. 能力设计。
6. MVS 构建。
7. 证据验证。
8. 规模运营。
#### 3.4 场景成熟度 S0–S5
| 等级 | 判定 |
|---|---|
| S0 概念 | 只有方向和设想，没有用户、数据和指标 |
| S1 定义 | 主体、对象、任务、指标、边界基本清楚 |
| S2 验证 | 最小真实闭环上线，获得初步业务与安全证据 |
| S3 可用 | 代表性范围稳定运行，达到 SLA 和价值指标 |
| S4 可复制 | 对象、流程、组件和机制可配置复制 |
| S5 可运营 | 形成持续客户、调用、收入或稳定公共投入 |
高风险场景不能因为离线指标高而跳过真实环境验证、安全审批和灰度运行。[S7]
### 4. 避免“本体大跃进”
LDO 的精益性要求围绕单个决策闭环做最小切片，而不是先建全企业大本体。每加入一个概念、属性、规则或 Action，都应回答：
- 谁是业务 Owner？
- 服务哪个场景和决策？
- 数据从哪里来，质量和 SLA 是什么？
- 谁能访问、用于什么目的？
- 触发什么行动，如何审批与回退？
- 用什么结果证明其仍有价值？
- 多久未使用或效果失效后淘汰？
---
## 04 · 工程架构与工具栈
> 官网给出方法、产物和能力类别，但没有指定一套唯一厂商产品。下表把官网明确提到的 RAG、工具调用、MCP、HITL、评测、日志监控、安全等能力组织成可实施的**平台无关参考栈**；具体产品例子属于工程化补全，不应理解为官网推荐或采购清单。[S3][S4][S5][S6]
### 1. 工具栈不等于软件清单
FDE 的第一工具栈是“认知与交付工具”，其次才是工程软件：
| 层 | 核心工具/产物 |
|---|---|
| 现场 | Account Brief、访谈提纲、Gemba Notes、Shadow Workflow、Stakeholder Map |
| 价值 | Value Stream Map、Baseline Sheet、KPI Tree、Opportunity Scorecard、Hypothesis Card |
| 设计 | Domain Model、Context Map、Agent PRD、HITL Map、Exception Matrix、Solution Canvas |
| 验证 | Experiment Card、黄金样本、Eval Set、Failure Taxonomy、Eval Report、Decision Log |
| 生产 | PRR、权限矩阵、审计策略、Runbook、回滚方案、SLO/SLA、告警面板 |
| 采纳 | Sponsor Brief、Pilot Canvas、Adoption Funnel、Value Ledger、Review Cadence |
| 复用 | Portfolio、连接器、Agent/Skill 模板、评测集、实施 SOP、Industry Pack |
没有这些产物，仅拥有模型平台和 Agent 框架，仍然容易停留在 Demo。
### 2. 平台无关工程栈
| 层次 | 必备能力 | 选型检查 |
|---|---|---|
| 体验层 | 对话、表单、工作台、通知、人工确认 | 能否嵌入原工作流；是否展示来源、置信和责任 |
| 编排层 | Workflow/Agent、状态机、任务队列、超时重试 | 是否显式建模状态、补偿、异常升级和幂等 |
| 模型层 | LLM/多模型路由、结构化输出、内容安全 | 能否版本化、降级、限流和记录模型配置 |
| 知识层 | 文档解析、检索、RAG、引用、知识版本 | 权限是否随检索继承；能否评测召回和答案依据 |
| 工具层 | Tool Calling、MCP、API/数据库/消息连接器 | 输入输出 Schema、最小权限、审批、超时和回退是否明确 |
| 业务语义层 | 对象、关系、事件、状态、规则、Action | 是否形成 LDO 最小切片，而非只复制源表结构 |
| 数据层 | 采集、CDC/事件、质量、血缘、主数据、特征/样本 | 来源、时间语义、用途授权和质量 SLA 是否可追溯 |
| 评测层 | 离线集、回放、红队、在线实验、失败分类 | 是否覆盖任务质量、业务、风险、采纳、成本和时延 |
| 安全治理层 | IAM、密钥、策略、PII、防注入、审计 | 能否对 Agent Action 做逐步授权和不可抵赖记录 |
| 运行层 | 容器/函数、CI/CD、灰度、观测、告警、成本 | 是否支持可回滚发布、端到端 Trace 和 SLO |
| 资产层 | Registry、模板、版本、Portfolio、行业 Pack | 可复用与客户定制边界是否清楚；是否有 Owner 和淘汰机制 |
### 3. 参考架构
```mermaid
flowchart LR
U[一线用户 / Sponsor] --> UX[业务工作台与 HITL]
UX --> WF[工作流 / Agent 编排]
WF --> LLM[模型路由与结构化输出]
WF --> RAG[知识检索 / RAG]
WF --> TOOL[受控 Tool / MCP / API]
TOOL --> SYS[ERP/CRM/工单/数据平台]
SYS --> EVT[事件与状态]
EVT --> ONT[LDO 最小本体切片]
ONT --> WF
WF --> AUDIT[轨迹、审计、成本、时延]
AUDIT --> EVAL[离线/在线评测与失败分类]
EVAL --> LEDGER[价值与采纳账本]
LEDGER --> DECIDE{扩展 / 调整 / 停止}
DECIDE --> WF
```
### 4. Action 合约
所有能改变业务世界的工具调用都应有显式合约：
```yaml
action: create_purchase_order
business_owner: 供应链负责人
actor: procurement_agent
purpose: 经审批后创建补库订单
input_schema: {...}
preconditions:
- inventory_gap > threshold
- supplier_status == approved
authorization:
scope: purchase_order:create
data_purpose: replenishment
human_confirmation:
required_when: amount >= 100000
writeback: ERP.purchase_order
idempotency_key: request_id
timeout_seconds: 15
rollback: cancel_purchase_order
audit_fields: [user, model_version, evidence, approver, result]
```
这正是“模型定行动”：输出必须进入受控、可审计、可回退的业务动作，而不是停留在回答文本。[S4]
### 5. 评测工具链
至少建立四层评测：
1. **组件**：解析、检索、结构化输出、工具参数准确性。
2. **任务**：端到端完成率、事实性、专家接受率、失败类别。
3. **生产**：时延、稳定性、成本、权限违规、回滚和人工接管。
4. **业务/采纳**：周期、等待、返工、质量、风险、活跃使用、覆盖率、采纳率。
工具能力应支持：数据集版本、Prompt/模型版本、Trace 回放、人工标注、红队样本、A/B 或灰度对照、失败聚类和结果归因。
### 6. AI Coding 在 FDE 中的位置
官网把 AI Coding 放在九能力域 D7，强调“速度属于 AI，质量属于工程体系”。[S6] 因此应当：
- 先有 Task Pack/Tech Scope，再生成代码。
- 小步提交，接口和权限先行。
- 自动测试覆盖正常、异常、越权、超时和回滚。
- 人工审查架构、安全、数据用途和业务责任。
- 代码、提示、工作流、评测集与部署配置共同版本化。
### 7. 选型顺序
1. 先定价值、用户和任务。
2. 再定工作流、HITL 与异常。
3. 再定最小本体、数据和 Action 合约。
4. 再用真实样本定义 Eval。
5. 最后选择模型、Agent 框架、RAG、数据库和运行平台。
倒序选型（先买平台、再找场景）与 Lean-FDE 的逻辑相反。
---
## 05 · 组织能力与人才体系
### 1. 三层组织模型
官网对交付组织的设计是：[S5][S8]
1. **Front Stage**：FDE 靠近客户，负责研究、现场、价值流、Agent PRD、验证、上线和复用串联。
2. **Back Stage**：AI、数据、前后端、安全、运维、平台等能力团队提供专业支撑。
3. **Governance**：管理商业机会、范围、评测、上线风险、采纳、复用和毛利。
这意味着企业不应寻找“无所不能的超级 FDE”，而要形成混编 Squad。
### 2. FDE Squad
| 角色 | 核心责任 | 不应被替代的判断 |
|---|---|---|
| Field Lead / FDE | 现场、价值、共识、范围、采纳 | 问题是否真实、下一步是否值得投入 |
| Product | 任务、工作流、体验、Agent PRD | 产品边界和用户责任是否清楚 |
| Engineering/Data/AI | 数据、模型、接口、系统和运行 | 系统是否可构建、可维护、可扩展 |
| Governance/Security | 权限、审计、风险、合规、评测 | Action 是否允许、风险是否可接受 |
| Sponsor/Business Owner | 资源、流程变更、结果归因 | 组织是否愿意改变并承担业务责任 |
### 3. C6 胜任力模型
官网的人才页面给出六项核心胜任力：[S9]
| C6 | 可观察行为 |
|---|---|
| Customer | 能进入现场，识别客户表达背后的真实运营问题 |
| Context | 能理解行业、流程、组织、数据、系统、安全和预算约束 |
| Code | 能构建、集成、部署或至少有效组织工程实现 |
| Cognition | 理解 LLM、RAG、Agent、工具调用、评测、HITL 和工作流 |
| Control | 把权限、安全、审计、确认、回滚和风险边界作为设计材料 |
| Compounding | 把项目沉淀为模板、连接器、评测集、手册和平台能力 |
注意：官网首页 FAQ 同时强调 FDE 不必替代工程师。[S1] 因而 `Code` 不应只理解成个人编码量，而应评估其能否定义工程边界、验证实现并推动系统进入可运行状态。
### 4. 九大能力域 D1–D9
| 域 | 能力 | 证据 |
|---|---|---|
| D1 客户现场发现 | 找到真实问题 | Gemba Notes、Discovery Pack |
| D2 Lean 价值诊断 | 找到浪费与价值 | Value Map、Baseline |
| D3 复杂性判断 | 选择正确打法 | Cynefin 分类、风险/假设地图 |
| D4 概念建模 | 把业务变成可构建模型 | Domain Model、LDO Slice |
| D5 Agent 产品设计 | 定义目标、边界与验收 | Agent PRD、Acceptance Criteria |
| D6 智能体工程 | 组合数据、工具、权限与 HITL | Workflow、Tool Contract、HITL Map |
| D7 AI Coding | 快速形成可运行系统 | Task Pack、代码、测试、Prototype |
| D8 商业作战 | 推动 POC、Pilot 与采纳 | POC/Pilot Canvas、Sponsor Brief |
| D9 产品化与组织沉淀 | 形成可复用行业资产 | Industry Pack、Portfolio、复盘 |
来源：[S6]
### 5. 不要混淆官网中的三套“等级”
公开页面同时出现了不同维度的分级，应分开使用：
#### 5.1 个人认证成长 L0–L6
认证页给出的路径是：L0 入营、L1 AI Coding Builder、L2 Field Researcher、L3 Agent Engineer、L4 Solution FDE、L5 Senior FDE、L6 Industry Partner。每级强调真实 Portfolio 证据；L4 要求真实上线证明，L5 至少两个行业智能体案例。[S10]
#### 5.2 FDE 能力成熟度 L1–L4
人才页另有四级描述：AI App Engineer、场景型 FDE、方案型 FDE、平台型 FDE。[S9] 这更像角色能力/交付范围成熟度，不能直接与认证 L0–L6 换算。
#### 5.3 场景成熟度 S0–S5
Lean SIM 的 S0–S5 评估的是**场景**从概念到可运营的状态，不评估个人。[S7]
建议组织使用不同前缀：`Cert-Lx`、`Capability-Lx`、`Scenario-Sx`，避免混用。
### 6. 人才评估
官网建议用真实案例而不是只靠知识问答：[S9]
1. 给真实流程，识别痛点、角色、数据、系统和价值指标。
2. 编写 Agent PRD，覆盖知识、工具、权限、HITL 和评测。
3. 基于接口/文档样本设计 RAG、工具调用和评测方案。
4. 模拟 POC 谈判，观察范围、风险和商业下一步判断。
认证页的“三评”结构为知识测评 25%、作品评审 45%、路演 30%。[S10] 对企业内部评估也可借用这一结构，但权重应按岗位校准。
### 7. 组织绩效
不要只以项目收入或上线数量考核 FDE Squad，至少观察：
- 现场到 Gate 1 的周期和机会淘汰质量。
- POC 到 Pilot、Pilot 到生产的转化率。
- 真实用户采纳率和流程影响。
- 风险事件、回滚时间和审计完整度。
- 连接器、评测集、模板的复用率。
- 单项目定制工作量、交付毛利和下一项目周期。
---
## 06 · 评测、治理与生产采纳
### 1. 指标树
单一“准确率”无法代表 FDE 项目。建议使用六层指标：
| 层 | 示例 |
|---|---|
| 业务结果 | 收入、损失避免、质量、风险、库存、周期、客户体验 |
| 流程影响 | 等待、返工、交接、处理时长、专家瓶颈、覆盖率 |
| 采纳 | 激活、周活、任务渗透、建议采纳、人工接管、复用 |
| 任务质量 | 完成率、事实性、召回、工具成功、专家通过、失败分布 |
| 生产运行 | 可用性、P95 时延、成本、超时、回滚、告警、恢复时间 |
| 治理安全 | 越权、数据泄露、注入、审计缺口、高风险误动作、合规事件 |
每个指标必须有：Owner、定义、数据源、基线、目标、时间窗、分母、证据和决策阈值。
### 2. Eval 三层
官网课程将评测分为“功能、质量、业务”，并要求黄金样本、失败分类、红队和 PRR。[S6]
#### 2.1 离线评测
- 数据集来自真实任务，并做脱敏和版本控制。
- 覆盖常见、长尾、异常、高风险和对抗样本。
- 同时测组件和端到端任务。
- 预先确定阈值，不看完结果再改标准。
#### 2.2 生产前评测
- 权限、审批、越权和数据用途测试。
- 超时、依赖不可用、重复调用、并发和幂等测试。
- 人工确认、升级、接管和回滚演练。
- 监控、告警、日志、审计和 Runbook 验证。
#### 2.3 在线运营评测
- 灰度、对照或分阶段上线。
- 持续记录输入、上下文、模型/提示版本、工具调用、人工决定和最终结果。
- 将线上失败回流为 Eval 样本。
- 用 Go/Adjust/Stop 机制决定扩展，不以日活增长自动代表价值。
### 3. Failure Taxonomy
建议至少分类：
1. 需求/任务定义错误。
2. 上下文缺失或过期。
3. 检索召回/排序错误。
4. 推理或事实错误。
5. 输出格式/Schema 错误。
6. 工具选择或参数错误。
7. 外部系统/网络错误。
8. 权限、用途或审批错误。
9. 人机责任/异常升级错误。
10. 流程设计或组织采纳错误。
“模型答错”只是其中一类。若大量失败属于流程或权限，继续调 Prompt 并不会解决根因。
### 4. PRR 生产准备评审
上线前至少回答：
- 业务 Owner、技术 Owner、风险 Owner、值班责任是否明确？
- 用户和任务边界是否清楚？
- 数据来源、用途、保留和删除策略是否批准？
- Action 是否最小权限、有审批、有幂等、有回退？
- 高风险场景是否强制 HITL？
- 评测阈值、已知失败和残余风险是否被接受？
- 日志、Trace、审计、告警和成本是否可观察？
- 模型、Prompt、知识、工具和策略是否可版本化与回滚？
- 故障、误动作、泄露和供应商不可用是否有预案？
- Pilot 的扩大、暂停、停止条件是否书面化？
### 5. 组织采纳
采纳不是“办一次培训”，而是行为和运营机制发生变化：[S1][S6]
```text
看见 → 理解 → 首次使用 → 重复使用 → 嵌入流程 → 主动反馈 → 成为标准工作方式
```
常见阻力：
- 不相信输出质量。
- 担心责任转移或岗位影响。
- 新系统增加额外步骤。
- 异常时不知道找谁。
- Sponsor 没有资源和制度动作。
- 价值归因不清，业务团队只承担成本。
对应策略：用真实证据建立信任；清楚展示来源和责任；减少双重录入；设计人工接管；让 Sponsor 明确资源、指标和决策节奏；把一线反馈纳入迭代。
### 6. Value Ledger
每个 Pilot 建议维护价值台账：
| 字段 | 含义 |
|---|---|
| 假设与基线 | 原流程的时间、质量、成本和风险 |
| 目标与阈值 | 什么结果支持扩大、调整或停止 |
| 运行范围 | 用户、流程、时间、样本和例外 |
| 使用与采纳 | 实际任务数、覆盖、采纳、接管、退出 |
| 业务结果 | 前后对比、对照、财务或风险证据 |
| 成本 | 模型、算力、人工复核、集成和运维 |
| 风险事件 | 越权、误动作、泄露、投诉、回滚 |
| 归因与限制 | 哪些变化能归因于系统，哪些不能 |
| 决策 | Go / Adjust / Stop 及责任人 |
Lean SIM 还提出数据账、API 账、模型账、算力账、智能体账、业务账的“六账”计量思路，用于支撑投资和收益分配。[S7]
---
## 07 · 企业 FDE 90 天落地路线图
官网组织转型页建议：1–30 天建立样板 Pod，31–60 天跑通 MVP 与评测，61–90 天上线试点并沉淀资产。[S8] 以下是可执行展开。
### 第 0–10 天：建立赞助与边界
- 指定 Sponsor、业务 Owner、Field Lead、工程和治理负责人。
- 选择一个行业、最多两个客户/业务单元、三条候选工作流。
- 统一目标：不是“做 Agent”，而是验证一个业务结果。
- 设立周评审和 Gate 决策机制。
**交付物**：Squad Charter、候选场景清单、治理规则、会议节奏。
### 第 11–30 天：Discovery 与场景选择
- 完成账户/业务研究和利益相关者地图。
- 至少观察两类真实角色和一条端到端流程。
- 采集等待、返工、质量、风险等基线。
- 用价值、频率、数据、嵌入度、阻力、风险评分。
- 选择一个六十天内能完成真实闭环的场景。
**Gate 1**：问题证据、Owner、基线、范围、停止条件齐全。
### 第 31–45 天：工作流与 LDO 设计
- 拆解角色、任务、决策、触发和异常。
- 设计 To-Be 工作流和 HITL。
- 构建最小充分本体切片。
- 定义数据、模型、Tool/Action、权限和审计合约。
- 形成 Agent PRD 与验收标准。
**Gate 2**：业务、工程、治理三方通过设计评审。
### 第 46–60 天：MVP 与评测
- 围绕最大不确定性构建最小实验。
- 建立真实 Eval Set、黄金样本和失败分类。
- 完成最小接口、工具调用、日志和安全控制。
- 开展红队、人工复核、异常和回滚演练。
- 完成 Eval Report 和 PRR 初版。
**Gate 3**：达到试点阈值，或明确 Adjust/Stop。
### 第 61–75 天：有限 Pilot
- 限定部门、用户、流程、时段和风险范围。
- 运行 Sponsor Brief 和一线培训。
- 每日观察任务、失败、人工接管、成本和时延。
- 每周复盘业务、质量、风险和采纳指标。
**交付物**：Pilot Canvas、Adoption Plan、运行面板、Value Ledger。
### 第 76–90 天：决策与沉淀
- 做前后/对照分析和价值归因。
- 组织 Go/Adjust/Stop 管理评审。
- 沉淀连接器、模板、评测集、权限策略、Runbook 和案例。
- 更新产品路线、报价/交付模型和下一轮场景组合。
- 建立项目 Portfolio 与个人贡献证据。
**Gate 4/5**：决定扩大、保持、调整或停止，并完成 Industry Pack v1。
### 90 天目标状态
不是“建成企业 AI 平台”，而是证明组织具备以下最小能力：
1. 能用现场证据选择场景。
2. 能把业务任务转成可构建、可治理的工作流。
3. 能用真实样本评测并作停止决策。
4. 能完成一次有限生产试点和采纳复盘。
5. 能把一次项目沉淀为下一次可复用资产。
### 反模式
- 同时启动十几个场景。
- 先采购平台，再找问题。
- 没有一线用户和真实样本。
- 把 POC 当小型交付项目，不设置证伪条件。
- 只评模型，不评流程、风险、成本和采纳。
- 只上线，不设运营 Owner。
- 项目结束只移交代码，不沉淀评测与知识资产。
---
## FDE 项目模板包（20 类）
> 使用方法：复制所需章节到项目目录。模板强调“最小充分”，字段没有决策用途时不要机械填写。
### T01 · Account Brief
- 客户/业务单元：
- 行业压力与经营目标：
- 组织结构与关键角色：
- 历史数字化/AI 基础：
- 候选工作流：
- 预算/采购/决策路径：
- 已知风险与假设：
- 进入现场的切口：
### T02 · Project Charter
- 真实问题（不得写技术方案）：
- 证据：
- 受益人/业务 Owner/Sponsor：
- 六至十二周范围：
- 不在范围内：
- 基线与目标：
- 团队与责任：
- Gate 与评审节奏：
- 扩大/暂停/停止条件：
### T03 · Stakeholder Map
| 角色 | 目标 | 担忧 | 权力/影响 | 需要的证据 | 承诺动作 |
|---|---|---|---|---|---|
| | | | | | |
### T04 · Gemba Notes
| 时间 | 角色 | 观察到的事实 | 用户解释 | FDE 假设 | 证据/附件 |
|---|---|---|---|---|---|
| | | | | | |
原则：事实、解释、假设分栏；记录等待、返工、信息搬运、判断瓶颈、异常和绕行。
### T05 · As-Is / Value Stream Map
| 步骤 | 角色 | 输入 | 系统/文档 | 处理时长 | 等待时长 | 返工/异常 | 输出 |
|---|---|---|---|---:|---:|---|---|
| | | | | | | | |
- 总 Lead Time：
- 真正增值时间：
- 最大瓶颈：
- 专家依赖：
### T06 · Opportunity Scorecard
每项 1–5 分，并记录证据：价值、频率/规模、痛感、数据可得性、流程嵌入度、Sponsor 强度、技术可行性、治理风险、六十天可验证性。风险项可采用反向分。
### T07 · Hypothesis Card
- 对于【用户/角色】
- 在【触发与任务】中
- 如果【改变工作流/引入能力】
- 将使【指标】从【基线】变为【目标】
- 因为【机制假设】
- 我们用【样本/实验】验证
- 当【阈值】时扩大；当【阈值】时停止。
### T08 · LDO 最小充分本体切片
| 要素 | 内容 |
|---|---|
| 价值目标 | |
| 岗位任务/决策 | |
| 对象 | |
| 关系 | |
| 事件/时间 | |
| 状态/指标 | |
| 规则/模型/约束 | |
| Action/审批/回退 | |
| 身份/权利/用途 | |
| 证据/版本/结果 | |
### T09 · Agent PRD
- 目标用户与 Job：
- 触发条件与完成定义：
- 能做/不能做：
- 上下文与知识来源：
- 工具与外部系统：
- 数据和权限：
- 交互与解释：
- HITL：
- 异常、升级、接管、回退：
- 评测集与验收阈值：
- 日志、审计、SLO：
### T10 · Data / RAG Spec
| 数据/知识源 | Owner | 用途 | 权限 | 时间范围 | 质量/SLA | 更新 | 引用要求 |
|---|---|---|---|---|---|---|---|
| | | | | | | | |
- 切分/索引策略：
- 检索与重排：
- 权限过滤：
- 召回评测：
- 无依据/冲突/过期处理：
### T11 · Tool / Action Contract
- Action 名称与业务 Owner：
- 目的与调用主体：
- 输入/输出 Schema：
- 前置条件：
- 最小权限与数据用途：
- 人工确认条件：
- 超时/重试/幂等：
- 写回系统：
- 回退/补偿：
- 审计字段：
### T12 · HITL Map
| 决策/动作 | 风险 | AI 角色 | 人的角色 | 确认时点 | 升级条件 | 回退 |
|---|---|---|---|---|---|---|
| | | 自动/建议/确认/接管 | | | | |
### T13 · Exception Matrix
| 异常 | 检测信号 | 自动处理 | 人工升级 | SLA | 最终责任人 | 复盘去向 |
|---|---|---|---|---|---|---|
| | | | | | | |
### T14 · Solution Canvas
- 用户、任务和价值：
- As-Is / To-Be：
- LDO 切片：
- 模型/RAG/工具：
- 数据与接口：
- HITL/异常/权限：
- 评测与生产指标：
- Pilot 边界：
- 最大风险与待验证假设：
### T15 · Experiment Card
- 最大不确定性：
- 可证伪假设：
- 最小真实样本：
- 实验组/对照：
- 预设指标和阈值：
- 时间与资源：
- 安全边界：
- Go / Adjust / Stop：
### T16 · Eval Plan / Failure Log
| 样本 ID | 场景 | 预期 | 实际 | 通过 | 失败类别 | 严重度 | 根因 | 修复版本 |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |
报告需包含：数据集版本、模型/Prompt/知识/工具版本、阈值、总体结果、分组结果、高风险失败、残余风险和决策。
### T17 · PRR Checklist
- [ ] Owner/值班/升级链清楚
- [ ] 数据用途、权限、保留获批
- [ ] Action 审批、幂等、回退已测
- [ ] HITL 和异常接管已演练
- [ ] Eval 阈值达到，残余风险获接受
- [ ] Trace/日志/审计/告警可用
- [ ] 灰度、降级、回滚可执行
- [ ] SLO、成本预算和供应商故障预案明确
- [ ] Pilot 扩大/暂停/停止条件明确
### T18 · Pilot / Adoption Plan
- 试点用户、流程、周期和边界：
- Sponsor 资源与制度动作：
- 培训、支持和反馈渠道：
- 使用/采纳/接管指标：
- 业务/质量/成本/风险指标：
- 每日运营与每周评审：
- 扩大、暂停、停止、回退条件：
### T19 · Value Ledger
| 周期 | 运行范围 | 使用/采纳 | 质量 | 业务结果 | 成本 | 风险事件 | 归因限制 | 决策 |
|---|---|---|---|---|---|---|---|---|
| | | | | | | | | |
### T20 · Portfolio / Industry Pack
- 问题、现场证据和业务边界。
- 关键假设及其修订历史。
- As-Is / To-Be、Agent PRD、LDO、HITL。
- Prototype、Eval、PRR、Pilot 和采纳证据。
- 失败、停止和学习。
- 个人贡献与团队贡献。
- 可复用连接器、模板、评测集、策略和 Runbook。
- 客户特有部分与行业通用部分。
- 版本、Owner、SLA、授权和淘汰规则。
---
## 08 · 来源索引与抓取说明
### 1. 核心来源
| 代号 | 页面 | 本知识库主要引用内容 |
|---|---|---|
| S1 | | FDE 核心命题、工作闭环、角色边界、FAQ |
| S2 | | FDE 总览、结果标准和责任闭环 |
| S3 | | FDE 定义、全球范式、传统岗位边界 |
| S4 | | LDO、六定、六化、十要素、双闭环 |
| S5 | | 前后台模型、八步交付、项目治理 |
| S6 | | 六周训战、九能力域、课程母架构、工具与验收 |
| S7 | | Lean SIM、八步闭环、十二件套、S0–S5 |
| S8 | | 三层组织模型、90 天转型 |
| S9 | | C6、人才库、四级能力成熟度、招聘任务 |
| S10 | | L0–L6、三评认证、Portfolio 证据 |
| S11 | | 课程产品与公开边界 |
| S12 | | 企业合作、Pod/陪跑/资产沉淀 |
| S13 | | 方法来源与创始人公开介绍 |
| S14 | | 客户端渲染的六周课程概要与交付包 |
### 2. 抓取覆盖
- 从首页递归发现同域 HTML 页面：19 个。
- HTTP 200：19 个。
- 有服务端公开正文的主要页面：14 个，加首页共 15 个。
- `group-camp` 的服务端 HTML 只有加载提示，另用真实浏览器保存客户端渲染后的公开文本。
- `assessment`、`assessment/lean-fde` 和三条 `courses/*` 页面在未登录浏览器中跳转登录；本项目保留公开壳页面，但没有绕过登录。
完整机器可读记录见：
- `../sources/manifest.json`
- `../sources/manifest.csv`
- `../sources/raw-html/`
- `../sources/clean-text/`
- `../sources/rendered-text/`
每条记录包含 URL、最终 URL、状态码、标题、文本长度、抓取时间、文件路径和原始 HTML 的 SHA-256。
### 3. 站点边界
- 本次访问时 `robots.txt`、`sitemap.xml` 均返回 404。
- 爬虫限速，默认请求间隔 0.6 秒。
- 只抓同域、公开、无需登录的 HTML。
- 跳过 `/api/`、`/_next/`、登录、注册和二进制资源。
- 不提交联系/报名/支付表单，不抓取个人信息，不绕过权限。
### 4. 解释限制
1. 官网存在营销页、课程页、方法页等不同表达，术语和等级可能属于不同维度；本知识库已尽量拆分，但不能替代官方解释。
2. 官网提到“十动作”“20 SOP”“25+ 模板”等完整资产，匿名访客页面没有公开全部原文；本知识库没有伪造其官方内容。
3. 本知识库的六道 Gate、工程参考架构、指标树和 20 类模板是基于公开方法的二次操作化归纳，已与官网原始框架区分。
4. 认证、人才推荐、课程和价格可能变化，使用前应回到官网核验。
5. 站点材料中的外部公司、人物、奖项和方法来源，本项目未做独立事实核查。
### 5. 可复现命令
```powershell
python -m pip install -r requirements.txt
python scripts/crawl_leanfde.py --output sources --delay 0.6
```
客户端渲染页面使用 Playwright 浏览器快照保存；账号后页面未采集。