FDE 进入客户现场，把产品能力接到真实工作中，并对可运行结果负责。教练式 FDE 在这个工程内核上增加一项明确责任：让业务人员参与问题定义、知识校准和新工作设计，使系统、组织与人能够一起接住变化。本课将这一角色边界放进一份可执行的项目契约，并用阶段门防止 Demo、PoC、试点和生产被混为同一种承诺。
- 理解 FDE 与研发、售前、实施、咨询和驻场外包的区别
- 理解 Echo、Delta、Platform 三种视角及生产工程硬边界
- 掌握看见—定锚—共创—部署—进化与 L1、L2、L3 进阶
- 建立人的主体性、职业伦理、数据安全和责任边界意识
- 建立有进入、退出、修改和停止条件的阶段门
从概念到可执行判断
FDE 连接产品能力与客户价值
模型和平台提供通用能力，业务价值却发生在具体任务中。数据散落在不同系统，规则藏在专家经验里，用户还要面对权限、责任和旧流程。FDE 进入这些真实约束，把产品能力接到能够运行和验证的工作中。
系统上线只说明技术可以访问。真实用户是否在关键任务中使用、业务结果是否改变、风险是否受控、内部人员是否能够继续维护，决定项目有没有完成。
工程硬边界
FDE 可以参加访谈、方案和项目沟通，但不能停在建议书或演示。FDE 必须能够亲自编写生产代码，或组织工程团队对数据、接口、评估、日志、发布、故障和回滚负责。没有可运行原型、真实测试和业务证据，工作更接近咨询。
售前帮助客户理解方案，实施人员部署已确定的系统，咨询顾问分析问题，产品研发建设通用能力。FDE 横跨这些边界，对一个尚不清楚的业务问题如何变成可运行结果负责，也把现场发现带回产品团队。
- 不把长期驻场和按人月执行包装成 FDE
- 不把演示效果包装成生产结果
- 不把系统错误与运行责任全部推给客户
- 不让每个客户的临时修补无限累积
Echo、Delta 与 Platform
Echo 视角负责业务问题、现场关系、使用行为、价值证据和组织条件。Delta 视角负责生产代码、数据、集成、评估、可靠性和运行。Platform 视角把重复出现的问题转成组件、连接器、模板或平台能力。
三个视角可以由不同的人承担。教练式 FDE 不要求一个人假装全能，但要求项目明确谁负责业务结果、谁负责生产运行、谁接收产品反馈。
五步主线与三段成长
课程使用看见、定锚、共创、部署、进化五步主线。L1 前沿交付工程师解决怎样做成，L2 前置部署赋能师解决怎样让客户自己做，L3 前沿动态赋能者处理跨部门难题、组织变化和未来方向。
每个项目同时设计最小可行工作流和最小可行角色变化。AI 接走确定性任务后，人新增什么判断、责任、创造和发展空间，需要在设计阶段说清楚。
教练式 FDE 七条工作契约
职业伦理写在方法之前。下面七条不是宣传口号，而是场景选择、知识提取、工作流设计和项目验收时都要检查的约束。
- 不把员工抵触简单解释成心态问题
- 不隐瞒 AI 对任务、岗位和责任的真实影响
- 不在未经授权时抽取、复制或外传隐性知识
- 不用无法核验的 ROI 推动项目
- 不让 AI 承担没有人最终负责的判断
- 不通过代操作或信息不透明制造客户依赖
- 不以组织进化之名越过人的选择权
用阶段门管理项目承诺
启动、原型、PoC、试点和生产需要不同证据。每道阶段门都要写清进入条件、要验证的最大不确定性、退出证据，以及证据不足时的修改或停止动作。
契约同时明确 Sponsor、业务 Owner、使用者、IT、安全与交付方的责任。未获授权的数据、无人承担的高风险判断和无法核验的价值不能被阶段时间表掩盖。
药企合规：交付工作流，也交付接管能力
某大型药企的合规审查规则复杂、人工成本高，不同团队对标准的理解也不一致。只做一个文档问答工具，无法解决责任、标准与更新问题。
FDE 深入合规部门，把审查规则、判断边界与异常处理转成 Agent 工作流，同时建立评估标准、知识更新责任和内部维护 SOP。
真正的成果不只是审核周期缩短，而是规则、评估和维护方式一起成为企业资产，能够被其他地区继续复用。
FDE 五步判断卡
面对任何 AI 项目，先连续回答五个问题：
真实用户每天在完成什么任务，哪里发生等待、返工、错误或风险？
为什么值得做，谁对价值负责，用什么基线和指标判断？
人、AI、知识和系统怎样重新分工，异常由谁处理？
最小原型怎样进入真实工作，并被测试、记录和修正？
项目结束后留下什么资产，谁能接手，下一轮怎样开始？
先回答，再展开答案
01为什么只有访谈和方案、没有可运行结果的工作还不能称为 FDE？
FDE 有生产工程边界，需要把问题推进到真实系统、测试、运行和业务证据。只有建议而没有运行结果，更接近咨询。
02Echo、Delta、Platform 分别关注什么？
Echo 关注业务与采用，Delta 关注工程与运行，Platform 关注把现场共性问题转成可复用产品能力。
03为什么人的主体性属于系统条件？
业务知识、异常样本和纠错反馈依赖员工真实参与；身份、利益和选择权没有被处理时，系统会失去关键输入。
04FDE 是否需要答应客户提出的所有项目？
不需要。FDE 应依据价值、可行性、责任与伦理边界判断推进、修改或拒绝。
把方法带回真实工作
企业内部推进（默认）
选择所在企业的一项具体任务，说明它当前由谁完成、产生什么价值、为什么仅增加一个 AI 工具仍不足以解决问题。与 Sponsor、业务 Owner和 IT 共同补齐项目契约与阶段门。
外部客户交付（可选）
选择一个明确客户场景，写清客户提出的表面需求、你认为需要进入现场验证的问题，以及项目结束时希望客户能够自己完成什么。与客户补充确认交付方、客户和第三方的责任边界。
所需材料
- 一个具体企业与部门
- 一个高频或高价值任务
- 当前流程或实际案例
- 可接触的业务 Owner 或用户
交付物
- FDE 责任边界图
- 项目契约与心理契约
- 项目章程
- 启动、原型、PoC、试点和生产阶段门与停止条件表
通过标准
- 项目角色、交付责任、最终负责人与升级路径清楚
- 每道阶段门都有可核验的进入证据、退出证据、修改与停止条件
- 工程、伦理、数据安全和人的选择权边界进入契约
能力证据
- Sponsor、业务 Owner 和交付方确认的项目契约
- 一份含实际证据要求的阶段门记录
填写模板或完成课程不等于能力达标；通过必须以真实任务、现场行为和可复核证据为依据。