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 官网的整体逻辑可归纳为：

为什么：AI 项目大量停留在 Demo，根因常是交付断层，而不是模型不够强
   ↓
是什么：FDE 是客户现场的 AI 交付负责人，以生产采纳、业务影响、复用资产为结果
   ↓
怎么做：现场发现 → 价值诊断 → 协同设计 → 构建评测 → 试点采纳 → 复用沉淀
   ↓
如何建模：用 LDO 把价值、对象、状态、规则、受控 Action、数据权利和结果证据连起来
   ↓
如何规模化：用 C6、D1–D9、FDE Squad、评审门、Portfolio 和 Industry Pack 复制能力

2. 文档地图

3. 关键术语

4. 建议阅读路径

• 管理者/业务负责人：01 → 02 → 06 → 07。
• 产品/咨询/售前：01 → 02 → 03 → 模板包。
• AI/工程团队：02 → 03 → 04 → 06。
• 组织与人才负责人：01 → 05 → 07。

来源代号 [S1] 等统一见 08-来源索引与抓取说明。

01 · FDE 知识体系

1. 定义

依据官网公开定义，FDE 是客户现场的 AI 交付负责人：统筹场景、技术、治理和采纳，推动 AI 系统进入生产运营；衡量标准不是“功能做完”，而是生产采纳、业务影响和复用资产。[S2][S3]

这一定义包含四层责任：

1. 现场责任：理解真实角色、任务、流程、约束和例外。
2. 价值责任：把“想要 AI”改写为有基线、指标和证据口径的业务假设。
3. 系统责任：定义人机协同、数据/工具接口、权限、异常和验收边界。
4. 采纳责任：推动试点、运营反馈、管理层决策和资产沉淀。

FDE 不必独自实现所有工程工作；其价值是“前台串联与结果闭环”，后台由 AI、数据、工程、安全、运维和平台团队提供专业支撑。[S3][S5]

2. 为什么 FDE 会出现

官网对企业 AI 失败的判断是：组织往往不缺能做原型的人，而缺少把战略目标、管理层预期、一线流程、异常处理、人机协同和工程交付统一起来的人。[S1]

典型断层如下：

因此，FDE 的问题域不是“模型能力”单点，而是：

现场事实 × 业务价值 × 人机协同 × 工程系统 × 评测治理 × 组织采纳

任何一项接近零，整体结果都可能失败。

3. FDE 与传统岗位的边界

官网明确强调：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]

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 价值流

经营目标 → 现场痛点 → 基线 → 可证伪假设 → 试点指标 → 结果归因 → 投资决策

3.2 产品与工程流

任务/决策 → 上下文 → 工作流 → Agent PRD → 数据/工具契约 → MVP → 生产系统

3.3 治理与采纳流

利益相关者 → 权限/责任 → 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. 三套方法的关系

Lean SIM：从战略与产业任务中选择、定义并运营高价值场景
   ↓
LDO：围绕岗位决策构建最小充分、可授权、可行动的业务世界切片
   ↓
FDE Delivery Loop：把切片实现为系统，完成评测、试点、采纳和复用

• Lean SIM 回答“做什么、为何投资、如何形成场景组合”。[S7]
• LDO 回答“系统最少要理解什么世界、谁能做什么、结果如何反馈”。[S4]
• FDE 回答“谁进入现场把它交付并形成生产结果”。[S2][S5]

2. 精益动态本体 LDO

2.1 定位

官网把 LDO 定义为：以可验证业务价值为牵引、以“最小充分本体切片”为交付单元，把现实对象、时空事件、动态状态、规则模型、受控行动、数据权利和结果证据统一起来，并通过业务与学习双闭环持续演化的平台无关方法。[S4]

它与知识图谱的区别不是“图更复杂”，而是责任层级不同：

2.2 十要素元模型

1. 价值目标。
2. 业务场景与岗位任务。
3. 产业/业务对象。
4. 对象关系。
5. 事件与时间。
6. 状态与指标。
7. 规则、模型与约束。
8. Action、审批与回退。
9. 身份、数据权利与用途。
10. 证据、版本与价值结果。

缺少 Action，系统只是分析；缺少状态，系统只是静态知识；缺少结果证据，系统不能学习；缺少价值，语义只会变成库存。[S4]

2.3 “六定”方法

2.4 “六化”转换

表字段 → 对象化 → 关系化 → 状态化 → 逻辑化 → 行动化 → 资产化

• 对象化：围绕客户、订单、设备等现实对象，而非源表名。
• 关系化：表达供应、持有、交易、风险传导等现实含义，而非技术 Join。
• 状态化：用事件和时间表达当前、历史、预测、计划和行动状态。
• 逻辑化：把指标、规则、模型和置信度绑定到对象与场景。
• 行动化：把判断转为有授权、有审批、有写回和回退的 Action。
• 资产化：对切片、数据合约、模型和 Action 做版本、授权、复用和运营。

2.5 双闭环

业务闭环：事实 → 状态 → 风险/机会 → 建议 → 受控 Action → 经营结果
学习闭环：轨迹/结果 → 失败评测 → 数据集更新 → 模型/规则更新 → 本体更新

真正关键的数据不只是“过去发生了什么”，还包括：人在什么信息条件下做了什么决定、是否采纳 AI 建议、最后产生什么结果。[S4]

3. Lean SIM 精益场景创新

3.1 方法结构

官网将 Lean SIM 概括为“一核、双轮、五层”：[S7]

• 一核：可核验的场景价值。
• 双轮：业务价值飞轮 + 数据智能飞轮。
• 五层：战略层、场景层、能力层、治理层、运营层。

核心链路：

场景定义任务 → 任务定义模型 → 模型定义数据 → 执行结果反哺数据与模型

3.2 场景五级粒度

FDE 项目通常应从 L3/L4 进入交付，最终把稳定能力沉淀为 L5 Skill；直接从 L1 跳到“建设平台”容易产生范围失控。

3.3 八步场景闭环

1. 战略锚定。
2. 机会扫描。
3. 场景原子化。
4. 价值假设。
5. 能力设计。
6. MVS 构建。
7. 证据验证。
8. 规模运营。

3.4 场景成熟度 S0–S5

高风险场景不能因为离线指标高而跳过真实环境验证、安全审批和灰度运行。[S7]

4. 避免“本体大跃进”

LDO 的精益性要求围绕单个决策闭环做最小切片，而不是先建全企业大本体。每加入一个概念、属性、规则或 Action，都应回答：

• 谁是业务 Owner？
• 服务哪个场景和决策？
• 数据从哪里来，质量和 SLA 是什么？
• 谁能访问、用于什么目的？
• 触发什么行动，如何审批与回退？
• 用什么结果证明其仍有价值？
• 多久未使用或效果失效后淘汰？

04 · 工程架构与工具栈

官网给出方法、产物和能力类别，但没有指定一套唯一厂商产品。下表把官网明确提到的 RAG、工具调用、MCP、HITL、评测、日志监控、安全等能力组织成可实施的平台无关参考栈；具体产品例子属于工程化补全，不应理解为官网推荐或采购清单。[S3][S4][S5][S6]

1. 工具栈不等于软件清单

FDE 的第一工具栈是“认知与交付工具”，其次才是工程软件：

没有这些产物，仅拥有模型平台和 Agent 框架，仍然容易停留在 Demo。

2. 平台无关工程栈

3. 参考架构

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 合约

所有能改变业务世界的工具调用都应有显式合约：

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

3. C6 胜任力模型

官网的人才页面给出六项核心胜任力：[S9]

注意：官网首页 FAQ 同时强调 FDE 不必替代工程师。[S1] 因而 Code 不应只理解成个人编码量，而应评估其能否定义工程边界、验证实现并推动系统进入可运行状态。

4. 九大能力域 D1–D9

来源：[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 项目。建议使用六层指标：

每个指标必须有：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]

看见 → 理解 → 首次使用 → 重复使用 → 嵌入流程 → 主动反馈 → 成为标准工作方式

常见阻力：

• 不相信输出质量。
• 担心责任转移或岗位影响。
• 新系统增加额外步骤。
• 异常时不知道找谁。
• Sponsor 没有资源和制度动作。
• 价值归因不清，业务团队只承担成本。

对应策略：用真实证据建立信任；清楚展示来源和责任；减少双重录入；设计人工接管；让 Sponsor 明确资源、指标和决策节奏；把一线反馈纳入迭代。

6. Value Ledger

每个 Pilot 建议维护价值台账：

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

原则：事实、解释、假设分栏；记录等待、返工、信息搬运、判断瓶颈、异常和绕行。

T05 · As-Is / Value Stream Map

• 总 Lead Time：
• 真正增值时间：
• 最大瓶颈：
• 专家依赖：

T06 · Opportunity Scorecard

每项 1–5 分，并记录证据：价值、频率/规模、痛感、数据可得性、流程嵌入度、Sponsor 强度、技术可行性、治理风险、六十天可验证性。风险项可采用反向分。

T07 · Hypothesis Card

• 对于【用户/角色】
• 在【触发与任务】中
• 如果【改变工作流/引入能力】
• 将使【指标】从【基线】变为【目标】
• 因为【机制假设】
• 我们用【样本/实验】验证
• 当【阈值】时扩大；当【阈值】时停止。

T08 · LDO 最小充分本体切片

T09 · Agent PRD

• 目标用户与 Job：
• 触发条件与完成定义：
• 能做/不能做：
• 上下文与知识来源：
• 工具与外部系统：
• 数据和权限：
• 交互与解释：
• HITL：
• 异常、升级、接管、回退：
• 评测集与验收阈值：
• 日志、审计、SLO：

T10 · Data / RAG Spec

• 切分/索引策略：
• 检索与重排：
• 权限过滤：
• 召回评测：
• 无依据/冲突/过期处理：

T11 · Tool / Action Contract

• Action 名称与业务 Owner：
• 目的与调用主体：
• 输入/输出 Schema：
• 前置条件：
• 最小权限与数据用途：
• 人工确认条件：
• 超时/重试/幂等：
• 写回系统：
• 回退/补偿：
• 审计字段：

T12 · HITL Map

T13 · Exception Matrix

T14 · Solution Canvas

• 用户、任务和价值：
• As-Is / To-Be：
• LDO 切片：
• 模型/RAG/工具：
• 数据与接口：
• HITL/异常/权限：
• 评测与生产指标：
• Pilot 边界：
• 最大风险与待验证假设：

T15 · Experiment Card

• 最大不确定性：
• 可证伪假设：
• 最小真实样本：
• 实验组/对照：
• 预设指标和阈值：
• 时间与资源：
• 安全边界：
• Go / Adjust / Stop：

T16 · Eval Plan / Failure Log

报告需包含：数据集版本、模型/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. 核心来源

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. 可复现命令

python -m pip install -r requirements.txt
python scripts/crawl_leanfde.py --output sources --delay 0.6

客户端渲染页面使用 Playwright 浏览器快照保存；账号后页面未采集。