第 05 章第 2 部v0.1E1 已建立 · E2/E3 待验证约 42 分钟

FDE 的 10 步交付闭环

用价值、可靠性和组织责任三条线，为项目从真实工作到能力移交建立十个证据门。

最近更新：2026年7月19日

本章目录

阅读边界： 本章明确区分官方事实、本站工作框架与待案例验证判断。本站框架不是行业认证或合规标准。

1. 十步不是瀑布，而是一组证据门

【本站框架】 十步给出默认顺序，但项目不会只向前走。第 6 步的真实样本可能推翻第 2 步的问题判断；第 7 步的失败模式可能迫使团队回到第 5 步降低自主性；第 8 步的权限限制可能要求重新设计整个工作流。

因此，步骤编号只表示当前主要决策，不表示合同阶段、部门边界或项目进度百分比。一个步骤只有在退出条件成立时才算通过；“开过会”“文档已提交”“Demo 能跑”都不能单独作为通过证据。

本章建议统一使用以下证据状态：

Missing：关键材料不存在
Planned：已指定收集方式和负责人
Observed：有观察或数据，但尚未复核
Verified：已由数据、系统状态或授权参与者确认
Contested：不同来源存在冲突，尚未解决
Not publishable：内部存在，但因隐私、商业秘密或授权不可公开

项目可以在 Not publishable 状态下完成内部交付，但不能把无法公开的证据替换成营销叙事。

2. 三条贯穿线

【本站框架】 每一步同时检查三条线。只完成其中一条，项目仍可能失败。

贯穿线	一直追问的问题	典型证据	常见假完成
价值线	真实问题是否值得解决，结果是否优于基线？	工作量、周期、质量、风险、成本、采用、结果	只展示模型能力或估算 ROI
可靠性线	系统如何失败、被限制、恢复和持续验证？	Eval、权限、日志、回滚、SLO、事故、持续监控	Demo 成功、一次测试通过
组织线	谁决策、谁承担风险、谁使用、谁长期运行？	Sponsor、Owner、RACI、审批、培训、移交	“项目组共同负责”或 FDE 一人兜底

3. 最小角色集合

同一个人可以承担多个角色，但角色不能消失。

角色	最小责任
业务 Sponsor	决定项目优先级、资源和业务风险接受范围
业务流程 Owner	拥有当前流程、基线、验收和采用结果
FDE 交付负责人	维护结果链完整性，推动十步证据门和跨团队决策
工程/平台 Owner	拥有系统设计、集成、部署与技术运行责任
领域与 Eval Owner	定义正确、严重失败、样本和人工评分规则
数据/安全/隐私/法务 Owner	在各自授权范围内批准数据用途、访问和风险控制
服务运行 Owner	拥有上线后的 SLO、告警、事故、成本与版本管理
真实用户/采用 Owner	参加工作流设计、试用、反馈、培训和采用决策

FDE 不替代这些角色签字。FDE 的责任是让缺失责任暴露出来，并阻止项目在责任未闭环时被叙述成“已完成”。

4. 十步总览

步骤	核心决策	主负责人	最小证据	主要退出条件
1. 观察真实工作	我们究竟要改变哪一段工作？	FDE + 流程 Owner	当前流程图、角色、真实样本	用户、触发、完成状态和例外被确认
2. 建立价值基线	这个问题是否可测且值得解决？	流程 Owner	基线、指标口径、停止条件	价值假设可检验，Sponsor 同意继续
3. 锁定责任与决策权	谁决定、验收、承担风险和长期运行？	Sponsor	项目责任书、RACI、决策门	每个关键决定都有唯一负责角色
4. 验证交付边界	数据、权限、系统、法规和采购是否允许？	各治理 Owner	数据清单、权限矩阵、风险登记	无未处理硬阻断，实验边界获批准
5. 选定最小系统形态	什么是足够简单且可运行的方案？	FDE + 工程 Owner	方案对比、ADR、自主级别	最小方案及权衡被确认
6. 打通真实样本纵切	关键假设能否在真实链路上成立？	FDE + 工程团队	可运行纵切、轨迹、失败日志	关键假设被证实、推翻或明确停止
7. 把失败写成评测门	什么质量与风险足以进入真实流量？	Eval Owner	任务集、评分器、阈值、回归报告	门槛可重复执行且获风险 Owner 同意
8. 接入生产控制面	系统能否在身份、权限、审计和故障中运行？	工程/安全/运行 Owner	接口、权限、审计、回滚演练	高风险动作受控，回滚和响应可用
9. 用受控流量证明采用	用户是否持续完成真实任务并产生价值？	流程/采用 Owner	发布、使用、质量、成本和反馈	达到扩量、修改或停止的预定标准
10. 转成可持续服务	谁能在 FDE 退出后继续运行和改进？	服务 Owner	SLO、持续 Eval、培训、移交演练	客户团队可独立运行，或续约责任明确

5. 第一步：观察真实工作

核心决策： 我们准备改变的不是一句需求，而是哪一个真实用户在什么触发时刻完成的哪一段工作？

输入

Sponsor 的初始目标或机会假设
初步利益相关者名单
进入现场、查看流程和使用样本的授权
已知的隐私、保密和访问边界

动作

观察或访谈真实执行者，而不只访谈管理者。
记录触发、输入、判断、动作、交接、等待、例外和结束状态。
区分制度规定的流程与实际发生的流程，包括 Excel、聊天、复制粘贴和线下补偿。
选取代表性样本，覆盖正常、边界、失败和高风险任务。
标记当前使用的系统、数据来源、权限和人工判断。

负责人

Accountable：业务流程 Owner
Responsible：FDE 交付负责人
必须参与：真实用户、领域专家、系统 Owner；涉及敏感数据时加入数据/隐私 Owner

必须证据

一张由真实用户确认的当前流程图
用户、触发时刻、完成状态和主要例外
角色与系统清单
脱敏后的代表性任务样本及来源说明
观察限制：没看到什么、哪些人没访谈、哪些材料不能访问

退出条件

至少一名真实执行者确认流程图没有遗漏关键步骤。
团队能用一句话写清“谁在何时完成什么工作”。
至少一个失败或例外路径被记录，而不是只有 happy path。
数据采集目的、范围和访问授权已明确。

常见失败

只接受高层给出的“做一个 Agent”或“建一个知识库”。
把操作手册当成现场事实。
只看演示样本，不看脏数据和失败任务。
为了调研无限收集数据，超出必要范围。
FDE 代替用户想象流程，真实用户直到上线才出现。

三线检查

价值线：哪里真正耗时、出错、积压或产生风险？
可靠性线：现有流程如何发现错误、回退和人工接管？
组织线：谁实际执行、谁批准、谁承担错误后果？

官方依据与边界

OpenAI 当前 FDE 岗位把 discovery 列为明确阶段，并要求与客户领导和一线团队共同工作。[OAI-FDE]
Palantir 当前 FDE 岗位强调进入客户现实并从第一次对话走向改变操作方式的交付。[PAL-ROLE]
NIST AI RMF 的 MAP 要求理解预期用途、使用场景、相关方、影响和限制。[NIST-RMF]
这些来源支持“先理解真实场景”，但本步骤的流程图、样本要求和退出条件属于本站框架。

6. 第二步：建立价值基线

核心决策： 当前损失是什么，改善多少才值得继续，什么时候应该停止？

输入

第一步的当前流程、真实用户和样本
可获得的任务量、周期、质量、成本、风险或收入数据
Sponsor 的优先级和可接受投资范围

动作

把需求改写成可测的问题声明，不把“使用 AI”写成目标。
为每个指标定义分母、时间窗、数据来源、排除项和负责人。
建立当前基线，包括隐藏人工、返工、等待和失败处置成本。
设定目标区间，而不是伪精确的单点承诺。
写出最小可接受价值、停止条件和反事实：不做项目会怎样？

负责人

Accountable：业务流程 Owner
Responsible：FDE 交付负责人和业务分析负责人
Approver：业务 Sponsor

必须证据

一页问题声明
指标字典和基线数据快照
价值假设及计算口径
已知不可测部分和代理指标说明
继续、暂停和停止条件

退出条件

问题至少有一个可重复测量的基线。
指标 Owner 能说明数据从哪里来、多久更新一次。
Sponsor 同意“达到什么值得扩量，达不到什么应停止”。
目标没有把模型准确率直接等同于业务价值。

常见失败

没有分母地写“效率提升 30%”。
只算模型费用，不算整理输入、人工复核、集成和运行成本。
用管理者满意度代替用户任务结果。
项目开始后不断改变成功口径。
没有停止条件，失败项目只能继续追加资源。

三线检查

价值线：基线、目标、观察窗和单位经济是否一致？
可靠性线：严重错误造成的损失是否进入价值模型？
组织线：谁拥有指标，谁有权宣布成功或停止？

官方依据与边界

OpenAI Deployment Company 公开方法包含聚焦诊断、影响优先级路线图和可测结果；这是其官方经营模式陈述，不是独立成效证据。[OAI-DEPLOY]
OpenAI Frontier 把可测影响作为部署工作的组成部分，并强调围绕既有数据、系统和权限建设。[OAI-FRONTIER]
NIST MAP 1.4 要求明确商业价值或背景、指标和风险容忍度。[NIST-RMF]
价值基线模板和停止条件属于本站框架。

7. 第三步：锁定责任与决策权

核心决策： 谁能做决定、谁验收、谁接受风险、谁负责上线后运行？

输入

已确认的问题、价值基线和初步范围
项目涉及的业务、技术、数据、治理和用户角色
预算、周期和组织约束

动作

指定 Sponsor、流程 Owner、FDE、工程 Owner、Eval Owner、治理 Owner、运行 Owner 和采用 Owner。
为范围、数据、方案、上线、风险接受、扩量和停止设置决策门。
为每个决策门指定唯一 Accountable 角色、所需证据和最长响应时间。
约定争议升级路径，区分“咨询意见”与“批准权”。
写清 FDE 能推动但不能越权替代的决定。

负责人

Accountable：业务 Sponsor
Responsible：FDE 交付负责人
必须确认：所有被列为 Accountable 或 Approver 的角色

必须证据

项目责任声明
RACI 或等价责任矩阵
决策门和升级路径
会议与决策记录的保存位置
风险接受与停止权归属

退出条件

每个关键决定都有唯一 Accountable 角色，而不是“项目组”。
安全、隐私、法务和数据角色在进入生产前有明确介入点。
真实用户在需求、Eval 和采用阶段有正式参与方式。
上线后的运行 Owner 已出现，不把责任默认留给开发者或外部 FDE。

常见失败

Sponsor 只在启动会出现，之后无人拍板。
每个人都有否决权，但没人有决定权。
FDE 被要求为法律、安全或业务战略独自签字。
运行团队在上线前一周才得知项目。
责任矩阵存在，但当事人从未确认。

三线检查

价值线：谁确认价值口径和扩量投资？
可靠性线：谁接受剩余风险，谁有紧急停止权？
组织线：谁拥有每个交付物和长期能力？

官方依据与边界

NIST AI RMF 要求与 AI 风险有关的角色、责任和沟通线被记录并保持清晰，执行层对风险决策负责。[NIST-RMF]
OpenAI Frontier 明确把访问控制、审计和组织采用置于同一交付体系中。[OAI-FRONTIER]
本章的最小角色集合和决策门格式属于本站框架。

8. 第四步：验证交付边界

核心决策： 在真实的数据、权限、系统、法规、采购和运行约束下，什么可以做，什么不能做？

输入

真实工作流、样本、价值基线和责任矩阵
当前系统架构、数据资产和供应商信息
企业制度、行业规则和适用法规初步清单

动作

盘点数据类别、来源、Owner、处理目的、最小必要范围、保留和删除要求。
绘制数据流和系统边界，标出第三方模型、工具、插件、跨境和委托处理关系。
盘点身份、角色、服务账号、审批、职责分离和审计要求。
核验网络、私有化、延迟、容量、成本、采购、合同、知识产权和供应商退出条件。
建立风险登记，区分硬阻断、可缓解风险、待验证假设和可接受限制。
对高风险处理触发必要的隐私、安全、法律或伦理评估；具体适用性由授权专业人员判断。

负责人

Accountable：对应的数据、安全、隐私、法务、采购或平台 Owner
Responsible：FDE 维护统一约束登记，工程 Owner 提供技术证据
Approver：各治理角色在其授权范围内批准

必须证据

数据清单和数据流图
权限与身份矩阵
系统/供应商边界和部署约束
风险登记及 Owner、缓解措施、截止时间
必要的评估、审批或法务意见引用
明确的不可做事项和实验隔离条件

退出条件

没有未指定 Owner 的硬阻断。
原型所用数据、账号和环境已有合法、合规且可审计的使用边界。
生产所需的关键网络、身份、部署和采购路径至少被证明可行；若未证明，缺口被显式标记，不能把原型称为生产近似。
对无法消除的风险，具备有权角色的书面接受、降级方案或停止决定。

常见失败

把“已脱敏”当结论，却没有脱敏方法和复识别风险验证。
使用个人账号、共享密钥或开发者高权限凭证推进试点。
先把数据送入第三方服务，再补供应商和跨境审查。
把提示词当访问控制，把“模型不会做”当安全措施。
把法规清单当法律意见，忽略行业监管和企业内部制度。
因合同要求交付文档，就误以为系统边界已经闭环。

三线检查

价值线：合规、私有化和集成成本是否使项目不再值得做？
可靠性线：权限、审计、数据生命周期和供应商故障如何受控？
组织线：每个限制由谁解释、批准、缓解和持续复核？

官方依据与边界

NIST AI RMF 和 GenAI Profile 要求在具体场景中识别风险、影响、责任和监控，不把通用模型能力等同于可部署性。[NIST-RMF] [NIST-GENAI]
MCP 安全指南强调最小权限、受众约束、Token 安全、SSRF 防护和会话边界；它只覆盖 MCP 相关攻击面。[MCP-SEC] [MCP-AUTH]
OWASP LLM/Agentic 项目把提示注入、敏感信息泄露、过度代理、工具滥用和身份权限滥用列为重点风险；它们是社区安全框架，不是合规证书。[OWASP-LLM] [OWASP-AGENTIC]
中国个人信息保护法、数据安全法、网络数据安全管理条例和生成式 AI 暂行办法可能影响数据处理与服务设计；具体适用范围必须按场景和行业判断。[CN-PIPL] [CN-DSL] [CN-NETDATA] [CN-GENAI]

9. 第五步：选定最小系统形态

核心决策： 在价值和约束成立的前提下，什么是足够简单、可评测、可治理和可运行的方案？

输入

问题、基线、约束和风险登记
代表性样本与初步失败模式
可用模型、工具、系统和团队能力

动作

同时比较不做、流程改造、规则、搜索、传统软件、RAG、LLM workflow 和 agent。
把任务拆成可确定执行、需要模型判断、需要人工批准和不可自动化的部分。
为 agent 定义自主级别、工具范围、状态、记忆、人工确认和终止条件。
比较买、建、联合交付和复用现有平台的成本与锁定风险。
记录架构决策、被放弃方案和未来升级条件。
预先定义降级路径：模型不可用、工具失败或风险升高时，系统如何退回规则、只读或人工流程。

负责人

Accountable：工程/平台 Owner
Responsible：FDE 与架构/工程团队
Consulted：流程、Eval、安全、运行和采购 Owner

必须证据

方案对比矩阵
架构决策记录 ADR
自主级别与人工确认矩阵
模型、工具、数据和系统边界图
延迟、容量、成本预算和降级方案
需要原型验证的关键假设列表

退出条件

团队能说明为什么更简单的方案不足，或为什么当前不需要 agent。
方案的关键假设、已知风险和不可承诺事项被记录。
高风险动作默认不依赖模型自行决定是否批准。
方案能被第七步的 Eval 和第八步的生产控制验证。

常见失败

先决定“做多 Agent”，再寻找问题。
把 RAG、记忆或 MCP 当作必须出现的架构部件。
为了演示效果增加自主性，却没有恢复和审计能力。
只比较模型准确率，不比较总延迟、集成、人工复核和运营成本。
方案完全依赖单一专家或临时脚本，无法移交。

三线检查

价值线：最小方案能否验证最关键的价值假设？
可靠性线：复杂度是否带来可测收益，失败时能否降级？
组织线：现有团队是否有能力拥有、运行和继续开发该方案？

官方依据与边界

Anthropic 建议先采用尽可能简单的方案，并区分 workflow 与 agent。[ANT-AGENTS]
OpenAI 的 Agent 指南建议在复杂决策、难维护规则或非结构化数据成为主要瓶颈时考虑 agent，并从单 Agent、清晰工具和分层 guardrail 起步。[OAI-AGENT-GUIDE]
方案对比矩阵、自主级别和退出条件属于本站框架。

10. 第六步：打通真实样本纵切

核心决策： 在受控环境中，关键假设能否穿过真实数据、模型、工具和输出，形成可检查的最终状态？

输入

已批准的最小系统形态
代表性样本、使用授权和隔离环境
关键假设、失败模式和初步验收口径

动作

构建最薄的端到端纵切，而不是先铺完整平台。
尽量使用真实格式、真实权限模型和真实接口；无法使用时明确模拟差距。
为每次运行保存输入版本、配置、模型、工具调用、轨迹、输出和最终环境状态。
同时运行正常、边界、失败和对抗样本。
保留人工基线或现有流程对照，记录所有隐藏人工修正。
让真实用户完成任务并解释何时信任、拒绝或需要补充信息。
在触及生产写操作前使用只读、沙箱或明确人工批准。

负责人

Accountable：工程 Owner
Responsible：FDE 与工程团队
必须参与：领域/Eval Owner、真实用户、必要的安全与数据 Owner

必须证据

可重复运行的纵切版本
样本来源、覆盖和脱敏说明
运行轨迹与最终状态
失败日志、人工修正和已知限制
与人工或现有流程的对照结果
继续、改方案或停止的假设判定记录

退出条件

至少一个关键价值假设和一个关键可靠性假设被真实样本验证。
结果不是由演示者在系统外手工补齐后才成立。
团队知道失败发生在哪里，能复现至少主要失败类型。
对生产差距有明确清单，不把沙箱成功写成生产就绪。
形成 continue / redesign / stop 的明确决定。

常见失败

只挑模型最容易成功的样本。
使用假的 API、假的权限和整理好的数据，却声称已验证集成。
没有版本和轨迹，成功无法复现。
人工在幕后修正输入或结果，但没有计入成本和质量。
原型直接拿生产高权限写入系统。

三线检查

价值线：真实用户是否完成了目标任务，投入是否少于基线？
可靠性线：失败是否可见、可复现、可分类和可恢复？
组织线：用户、工程和治理角色是否共同看过同一份证据？

官方依据与边界

OpenAI 当前 FDE 岗位把原型、系统设计、构建和生产发布连成同一职责链；原型只是阶段，不是终点。[OAI-FDE]
OpenAI Frontier 强调围绕企业已有数据、系统、工具、权限和控制构建 agent，并形成评测与优化循环。[OAI-FRONTIER]
NIST 要求测试条件尽量匹配部署条件，并记录条件不匹配带来的限制。[NIST-RMF]
“最薄纵切”和本步骤的假设门属于本站框架。

11. 第七步：把失败写成评测门

核心决策： 哪些任务必须成功，哪些失败可以接受，哪些失败一次都不能放过？

输入

真实工作流、代表性样本和纵切轨迹
已观察失败、业务风险和上线范围
当前人工或旧系统基线

动作

采用 top-down 与 bottom-up 两种方式建立任务集：从业务目标拆任务，也从原型日志和真实失败反推任务。
同时覆盖成功路径和多种失败模式：输入缺失、知识冲突、工具选择错误、参数错误、权限拒绝、状态不一致、越权动作和无法完成。
分开评估最终结果、关键过程/轨迹和安全控制，不把“回答像对的”当任务完成。
组合确定性评分、规则评分、模型评分和人工评分；高风险判断保留人工校准。
为严重度、通过率、人工复核率、成本和延迟设置阈值。
记录数据集来源、版本、污染风险、代表性和不可覆盖部分。
把 Eval 放入每次提示词、模型、工具、数据和代码变更后的回归流程。

负责人

Accountable：领域/Eval Owner
Responsible：FDE、Eval/工程团队
Approver：业务流程 Owner 与相应风险 Owner

必须证据

任务集目录、来源和覆盖矩阵
失败分类与严重度
评分器、rubric、人工校准样本和分歧记录
基线、候选版本和回归结果
上线阈值、禁止上线条件和已知限制
对高风险动作的安全/权限测试

退出条件

任务集覆盖核心成功路径和主要失败模式，而不是只有正例。
评分器能重复运行，并经过人工抽检或校准。
严重失败有单独阈值，不被平均分掩盖。
通过标准由业务与风险 Owner 同意，不由模型团队单方面宣布。
任一变更都能触发可复现的回归比较。

常见失败

使用“看起来不错”的展示样本做验收。
只有平均准确率，没有严重错误率。
用另一个模型评分，却没有人工校准和偏差检查。
测试集泄漏进提示词、微调或开发过程。
只评模型回复，不检查数据库、工单、文件或工具执行后的最终状态。
上线后不再更新任务集，真实失败无法回流。

三线检查

价值线：Eval 是否测到用户任务和业务结果，而不只是语言质量？
可靠性线：成功、失败、恢复、权限和回归是否都有门槛？
组织线：谁维护任务集、批准阈值、裁决评分分歧？

官方依据与边界

Anthropic 官方 Agent eval 指南建议从 top-down 与 bottom-up 任务开始，覆盖成功与多种失败模式，组合确定性、模型和人工评分，并用真实生产流量持续监控。[ANT-EVALS]
OpenAI Eval 指南强调任务特定评测、日志、自动化评分、人工判断和持续评测。[OAI-EVAL]
NIST 要求测量与部署条件相关，并警惕从狭窄、非系统或轶事性测试外推。[NIST-RMF]
任务集字段、严重度门和退出条件属于本站框架。

12. 第八步：接入生产控制面

核心决策： 系统不仅能调用工具，还能在企业身份、权限、审计、事务和故障约束下安全运行吗？

输入

通过评测门的候选系统
架构、权限、风险登记和生产环境要求
运行 Owner、发布策略和支持路径

动作

使用生产身份体系和最小权限，避免共享高权限 Token。
对用户输入、外部内容、模型输出和工具参数做结构化验证。
对付款、发送、删除、审批、权限修改等有副作用或高风险动作设置人工批准和范围预览。
设计幂等、重试、超时、事务、补偿、回滚和人工接管。
记录用户、Agent、工具、数据、批准者、时间、参数和最终状态，形成可追溯审计。
验证提示注入、敏感信息泄露、工具滥用、供应链和会话/Token 攻击。
建立监控、告警、SLO 草案、事故分级、停止开关和回滚演练。
为账号撤销、员工离职、供应商变更和密钥轮换设计生命周期控制。

负责人

Accountable：工程/平台 Owner 与安全 Owner，各自负责其控制面
Responsible：工程、平台、SRE/运行团队；FDE 维护跨域证据
Approver：业务、数据、隐私、法务等有权角色

必须证据

接口契约、数据映射和错误语义
Tool/数据权限矩阵与授权流程
威胁模型、安全测试和整改记录
审计日志样本及查询方式
幂等、重试、回滚和人工接管演练
运行手册、SLO 草案、告警和事故联系人
高风险动作的人机确认设计

退出条件

每个生产身份和工具权限都能映射到最小业务需要。
所有高风险写操作都有授权、预览、确认或等价控制。
关键故障能被监测，回滚或降级已实际演练。
日志能回答谁在何时基于什么输入执行了什么动作，结果是什么。
运行与安全 Owner 同意进入受控真实流量。

常见失败

一个服务账号拥有所有用户和系统权限。
直接把模型文本拼接成 SQL、Shell、API 或审批动作。
把 MCP 或工具协议接通等同于完成授权设计。
只有重试，没有幂等和补偿，导致重复写入。
有日志但无法关联用户、工具调用和最终状态。
生产故障只能找最初的 FDE 手工修复。

三线检查

价值线：控制带来的摩擦是否仍低于风险与返工成本？
可靠性线：最小权限、确认、审计、回滚和事故响应是否可用？
组织线：谁拥有生产身份、告警、事故和风险接受？

官方依据与边界

OpenAI Frontier 把共享业务上下文、执行环境、评测优化和治理控制视为企业 agent 的共同底座。[OAI-FRONTIER]
OpenAI Agent 指南建议分层 guardrail，并对高风险动作保留人工干预。[OAI-AGENT-GUIDE] [OAI-GUARDRAILS]
MCP 官方安全材料要求最小权限、Token 受众和安全授权，明确反对 Token passthrough 等不安全模式。[MCP-SEC] [MCP-AUTH]
OWASP LLM/Agentic 风险支持提示注入、过度代理、工具滥用和身份权限控制要求。[OWASP-LLM] [OWASP-AGENTIC]
控制清单和退出门属于本站框架。

13. 第九步：用受控流量证明采用

核心决策： 在真实用户、真实任务和可控风险下，系统是否被持续使用，并比原流程创造更高净价值？

输入

通过生产控制门的系统
明确的试点人群、工作流和支持方案
上线、采用、质量、成本和停止阈值

动作

采用影子运行、并行对照、灰度或限定人群，而不是一次性全量切换。
在真实工作流中培训用户，说明能力边界、复核点、失败升级和反馈入口。
同时观测任务完成、使用频率、留存、人工复核、严重错误、延迟、成本、支持工单和退出原因。
区分“打开过”“生成过内容”和“完成了真实任务”。
把真实流量中的新任务和失败持续加入 Eval。
定期与原基线比较，记录外部因素和激励变化，避免把同时发生的流程改革全部归因于 AI。
按预定门槛做扩量、保持、修改或停止决定。

负责人

Accountable：业务流程/采用 Owner
Responsible：FDE、产品/运营、工程与支持团队
Approver：Sponsor、运行和风险 Owner

必须证据

发布版本、时间、人群和回滚点
真实任务完成与采用漏斗
线上质量、严重失败、人工复核和支持数据
延迟、容量、模型与基础设施单位成本
用户反馈、退出原因和流程变化记录
与原基线一致口径的阶段结果
扩量、修改或停止决策记录

退出条件

在预先约定的观察窗口内达到最低运行稳定性。
目标用户使用系统完成真实任务，而不是只参加培训或尝试 Demo。
质量、成本和采用同时在可接受范围，未用其中一个掩盖另一个。
真实流量失败已进入任务集和修复队列。
Sponsor 和流程 Owner做出明确的下一阶段决定。

常见失败

用账号开通数、页面访问或一次使用代替采用。
只报告好评，不记录拒绝、绕开和回退旧流程。
观察窗过短，或上线期有强制激励却不说明。
采用提升，但人工复核和支持成本高于节省价值。
线上发现新失败后，只修提示词，不更新 Eval。
没有停止机制，低价值试点长期占用团队。

三线检查

价值线：真实任务的净结果是否优于基线？
可靠性线：真实流量是否维持评测、安全、延迟和成本门槛？
组织线：用户为何采用或拒绝，流程与考核是否支持新方式？

官方依据与边界

OpenAI 当前 FDE 岗位把 production adoption、measurable workflow impact 和一线反馈列入成功职责。[OAI-FDE]
OpenAI Deployment Company 把构建生产系统、推动采用和可测结果放在同一部署路径中。[OAI-DEPLOY]
Anthropic Agent eval 指南建议在生产中监控真实分布，因为离线任务集不能覆盖所有真实行为。[ANT-EVALS]
NIST MANAGE 包含部署后监控、用户反馈、申诉/覆盖、停用和退役机制。[NIST-RMF]
采用漏斗和联合门槛属于本站框架。

14. 第十步：转成可持续服务

核心决策： 如果最初的 FDE 明天退出，客户团队能否继续运行、评测、恢复、变更和停止系统？

输入

生产运行、采用和阶段结果证据
目标运营模式和商业/组织安排
未解决风险、技术债和产品反馈

动作

明确服务 Owner、业务 Owner、Eval Owner、安全 Owner 和供应商责任。
固化 SLO、成本预算、容量、告警、值守、事故、变更和发布流程。
建立持续 Eval：从真实流量采样、补任务、回归版本并追踪严重失败。
定期复核账号、权限、数据保留、供应商、模型和第三方工具。
完成运行手册、培训、故障桌面演练、回滚演练和关键人员备份。
移交代码、配置、提示词、数据管道、任务集、评测结果、日志查询和资产权限。
把现场反馈分成客户特有配置、可复用方法、产品缺口和不应继续支持的定制。
明确扩大、维持、重构、续约或退役的下一次决策日期。

负责人

Accountable：服务运行 Owner
Responsible：客户工程/运行团队与 FDE
Approver：业务流程 Owner、Sponsor 及相应风险 Owner

必须证据

服务目录、SLO、告警和事故流程
成本、容量和供应商依赖看板
持续 Eval 计划、回归历史和真实失败回流记录
权限复核、数据生命周期和密钥轮换记录
运行手册、培训记录和演练结果
完整资产与责任移交清单
产品反馈、定制债和退役计划

退出条件

新 Owner 能在没有原始 FDE 实时帮助时完成一次运行检查、故障处理和版本回归。
生产账号、密钥、任务集、日志和发布权限不再只掌握在个人手里。
供应商或模型变化时，有明确的再评测和回滚机制。
若继续由外部 FDE/服务团队运营，责任范围、SLO、成本和退出方式已正式续约，而不是默认依赖。
系统有明确的下一次价值复核和退役条件。

常见失败

发一份文档就宣布移交，没有演练。
客户只会点击使用，不会评测、恢复或升级。
最初 FDE 持有唯一生产权限和关键上下文。
没有持续 Eval Owner，模型或数据变化无人发现回归。
客户特有定制从不回流产品，也从不被停止。
项目永久运行，却没人再次检查价值是否存在。

三线检查

价值线：系统是否仍创造净价值，何时再次复核或退役？
可靠性线：持续 Eval、SLO、事故、变更和供应商风险是否被拥有？
组织线：能力是否真正转移，或依赖关系是否被明确购买和治理？

官方依据与边界

OpenAI Frontier 强调可评测和优化的反馈循环、企业控制以及组织可以长期拥有的重复模式。[OAI-FRONTIER]
OpenAI Deployment Company 把现场建设与长期运营支持、组织采用放在同一模式中。[OAI-DEPLOY]
Anthropic Agent eval 指南强调生产监控和随真实流量更新 eval。[ANT-EVALS]
NIST 要求部署后监控、人员培训、风险响应、停用和退役计划。[NIST-RMF]
“客户团队独立演练”与本步骤的移交门属于本站框架。

15. 五个决策门

十步用于执行，决策门用于控制投入。任一门都允许停止项目。

决策门	发生位置	必须回答	允许决定
G0 值得解决吗	第 2 步后	问题可测、价值足够、停止条件明确吗？	继续发现 / 暂停 / 停止
G1 允许且可行吗	第 4-5 步后	责任、数据、权限、方案和成本是否成立？	原型 / 降范围 / 换方案 / 停止
G2 值得进入真实流量吗	第 7 步后	任务集、失败门和风险接受是否可执行？	受控试点 / 补证 / 停止
G3 可以生产运行吗	第 8 步后	身份、审计、回滚、响应和 Owner 是否就绪？	灰度 / 延期 / 降级 / 停止
G4 应该扩大并移交吗	第 9-10 步	价值、采用、可靠性和能力拥有是否同时成立？	扩大 / 维持 / 重构 / 退役

16. 中国企业环境中的变体

以下内容是**【中国现场假设】**。官方法规能证明某些义务存在，但不能证明每家企业都采用相同流程。

16.1 采购顺序可能早于发现顺序

有些项目先有预算、招标或合同范围，再开始接触真实用户。此时不要假装第 1-2 步已完成。建议并行维护两套状态：

合同交付状态：合同要求的里程碑、文档和验收材料
实际结果状态：十步的价值、可靠性和组织证据

合同材料可以是证据的一部分，但不能替代真实采用和结果。

16.2 原型环境与生产环境可能差异很大

公网模型、个人账号和外部 SaaS 可能只允许用于早期实验，而生产要求专线、私有化、网络隔离、统一身份或国产化环境。第 6 步必须单列“生产等价性缺口”；若关键约束未被复现，不能按接近生产的原型估算质量、延迟和成本。

16.3 数据、系统和流程可能属于不同部门

业务有价值目标，不代表拥有数据；科技有系统，不代表有权改变流程；风险和法务拥有否决点，但不负责实现。第 3、4 步需要更早明确跨部门决策时限、材料格式和升级路径。

16.4 法规适用性不能用一张通用清单代替

个人信息保护法要求个人信息处理具备明确合理目的、与目的直接相关，并采取影响个人权益最小的方式；敏感个人信息、自动化决策、委托处理和跨境等场景可能触发额外要求。[CN-PIPL]
数据安全法强调数据分类分级、全流程安全管理和风险监测处置。[CN-DSL]
网络数据安全管理条例自 2025-01-01 起施行，进一步规定网络数据处理活动和相关责任。[CN-NETDATA]
生成式人工智能服务管理暂行办法主要针对向境内公众提供生成式 AI 服务；企业内部使用是否落入具体条款，必须按服务对象、功能、行业和部署方式判断。[CN-GENAI]

本章不提供法律意见。项目应由有权的法务、隐私、安全和行业合规人员完成适用性判断。

16.5 “验收”可能偏向文档，采用可能偏向组织激励

项目可能按接口、功能、报告和培训完成合同验收，却没有证据表明用户持续使用。反过来，短期强制使用也可能制造虚假采用。第 9 步应记录真实任务完成、旧流程回退、人工复核、用户退出原因和激励变化。

16.6 供应商联合交付需要明确最终 Owner

模型商、集成商、软件商、咨询方和企业内部团队可能共同交付。责任矩阵要回答：谁修模型问题、谁修业务规则、谁修接口、谁响应事故、谁维护 Eval、谁拥有数据和提示词资产。不能用“供应商负责”作为一个模糊角色。

17. 中国企业证据缺口

截至 2026-07-19，本章仍缺以下 E2/E3 证据：

至少 3 个中国企业 AI 项目按同一十步框架回填的完整记录。
至少 1 个银行或强监管行业项目的权限、审计、上线与移交证据。
至少 1 个 Demo 成功但采用失败的项目时间线。
至少 1 个因数据、采购、成本或组织责任停止的项目。
安全、法务、隐私、采购和数据治理人员对第 3、4、8 步的联合复核。
合同验收指标与真实业务结果不一致的可脱敏样本。
私有化/隔离环境与公网原型之间质量、延迟、成本差异的实测数据。

在这些证据补齐前，本章可以作为项目工作框架公开讨论，但不能宣称“已被中国企业普遍验证”。

19. 中文版结论

FDE 的价值不在于同时做了产品、工程、咨询和项目管理，而在于阻止项目用一个阶段的成功冒充整条结果链的成功。

十步中最重要的不是“做完十件事”，而是每次前进都能回答：

价值线有没有新的可测证据？
可靠性线有没有新的失败、控制和恢复证据？
组织线有没有明确的决定、责任和长期拥有者？

如果不能回答，就应该回退、降范围或停止，而不是用更多功能掩盖缺口。

行动资产

打开《FDE 10 步交付画布》，用于项目立项、周评审、阶段门禁和移交复盘。

来源与证据边界

All sources below were accessed or rechecked on 2026-07-19. Short quotations elsewhere in the chapter remain within the editorial excerpt limits. Dynamic pages may change; citations should be read with the access date, and source changes or factual errors are welcome as correction reports.

ID	Primary source	Publisher/date	Supports	Does not prove
OAI-FDE	Forward Deployed Engineer, NYC	OpenAI; dynamic job page	Current OpenAI role scope across discovery, technical scoping, design, build, rollout, adoption, measurable workflow impact, and field feedback	A universal FDE definition or evidence that every engagement succeeds
OAI-DEPLOY	OpenAI launches the OpenAI Deployment Company	OpenAI; 2026-05-11	OpenAI’s stated deployment model, focused diagnostic, impact roadmap, production work, adoption, and measurable results	Independent validation of commercial or customer outcomes
OAI-FRONTIER	Introducing OpenAI Frontier	OpenAI; 2026-02-05	Enterprise context, execution, evaluation/optimization, controls, identity, audit, and repeatable production patterns	A vendor-neutral architecture standard or a compliance certification
OAI-AGENT-GUIDE	A practical guide to building agents	OpenAI; living guide	Agent suitability, starting small, real-user validation, tool design, fallback, guardrails, and human intervention	That an agent is required for the project or that the described pattern is optimal everywhere
OAI-EVAL	Evaluation best practices	OpenAI Developers; living documentation	Task-specific evaluation, logging, automated scoring, human judgment, and continuous regression	Business acceptance thresholds or independent proof of a deployed system’s quality
OAI-GUARDRAILS	Guardrails and human review	OpenAI Developers; living documentation	Automatic input/output/tool checks and human approval before sensitive side effects	Complete application security or authorization design
ANT-AGENTS	Building effective agents	Anthropic; 2024-12-19	Workflow/agent distinction, simple composable designs, tool contracts, and adding complexity only when justified	A universal production architecture or independent benchmark
ANT-EVALS	Demystifying evals for AI agents	Anthropic; 2026-01-09	Top-down and bottom-up task construction, success and failure coverage, mixed graders, traces/outcomes, and production monitoring	Project-specific risk tolerance, legal approval, or a complete security program
PAL-ROLE	Forward Deployed Software Engineer, New Grad - Commercial	Palantir official ATS; dynamic job page	Palantir’s current end-to-end FDE role, customer reality, stakeholder work, data, architecture, and operational change	The responsibility model of every Palantir team or the wider FDE market
NIST-RMF	Artificial Intelligence Risk Management Framework 1.0	NIST; 2023-01-26	Govern, Map, Measure, Manage; documented responsibilities; context; deployment-relevant testing; monitoring and retirement	Legal compliance by itself; the framework is voluntary and requires contextual implementation
NIST-GENAI	Generative AI Profile, NIST AI 600-1	NIST; 2024-07-26	GenAI-specific risk considerations and actions that extend AI RMF	China-specific legal compliance or project acceptance
MCP-SEC	MCP Security Best Practices	Model Context Protocol; living documentation	OAuth/authorization risks, least privilege, token handling, SSRF, sessions, and MCP threat patterns	Security outside the MCP boundary or compliance certification
MCP-AUTH	MCP Authorization	Model Context Protocol specification; 2025-11-25 version	Authorization roles, resource indicators, token audience, and protocol-level requirements	A complete enterprise IAM design or permission model for business actions
OWASP-LLM	OWASP Top 10 for LLM Applications	OWASP GenAI Security Project; current 2025 release	Prompt injection, sensitive information disclosure, excessive agency, output handling, supply-chain, and related LLM risks	Exhaustive threat coverage, legal compliance, or proof that mitigations work in a specific deployment
OWASP-AGENTIC	OWASP Top 10 for Agentic Applications for 2026	OWASP GenAI Security Project; published 2025-12-09 as the 2026 release	Tool misuse, identity/privilege abuse, memory/context risks, orchestration, and human-agent trust boundaries	A formal standard, certification, or complete project threat model
CN-PIPL	中华人民共和国个人信息保护法 / Personal Information Protection Law	National People’s Congress; passed 2021-08-20, effective 2021-11-01	Primary legal text for personal-information processing obligations in China	Project-specific legal advice or a conclusion that every AI project processes personal information
CN-DSL	中华人民共和国数据安全法 / Data Security Law	National People’s Congress; passed 2021-06-10, effective 2021-09-01; official full-text republication by CAC	Primary legal text for data classification, security management, monitoring, and response	A complete sector-specific compliance determination
CN-NETDATA	网络数据安全管理条例 / Network Data Security Management Regulations	State Council; promulgated 2024-09-30, effective 2025-01-01	Primary rules for network-data processing activities and related responsibilities	Automatic applicability to every internal AI experiment
CN-GENAI	生成式人工智能服务管理暂行办法 / Interim Measures for Generative AI Services	CAC and six other authorities; published 2023-07-13, effective 2023-08-15	Primary rules for generative AI services offered to the public in mainland China	A conclusion that every private or internal enterprise AI system falls within the same scope

Final evidence statement

Official facts: current role expectations, published vendor methods, technical documentation, standards, and legal texts are cited with source and access date.
First-party claims: OpenAI, Anthropic, and Palantir materials establish what those organizations say they do; they are not treated as independent proof of outcomes.
FDE working framework: the ten names, sequence, three lines, artifacts, gates, evidence states, and exit conditions are original editorial synthesis for this handbook.
China-context hypotheses: organizational and procurement variants remain hypotheses until supported by reviewable China enterprise project evidence.
Beta status: this chapter is a public working framework. It has not been validated across Chinese enterprise projects and does not represent completed project-specific legal, privacy, security, confidentiality, or compliance review. The framework will continue to evolve; factual corrections and reviewable field evidence are welcome and will be reflected in later versions.