解决什么问题，为什么值得做？
OpenAI 在 2026 年 5 月公布 Deployment Company 的交付模式：工程师与管理者、运营和一线团队共同选择高价值工作流，再连接数据、工具与业务系统，完成构建、测试和部署。其组织设计同时强调现场经验向产品团队反馈。
把“买到了模型”推进到“业务有人持续使用”，同时减少下一次交付的重复劳动。
- 协作角色
- 业务负责人、一线使用者、客户 IT、FDE、核心产品研发
FDE 怎样把症状变成可解决的问题？
以下为结合案例设计的 FDE 实战推演，展示同类问题的排查与实施方法；公开团队的已披露做法见上方背景。
先看一次任务怎样完成
实战推演：面对“做一个客户运营 Agent”，先请使用者演示选人、查规则、执行和回看。逐步记录在哪个系统取数、何时切换表格、谁解释异常；把时间耗在找资料还是判断上分开。
用失败样本找适配边界
拿同一会员有两个身份、活动规则冲突、工具超时三类合成样本跑产品。把失败归为配置缺口、客户数据适配或产品共性缺陷；不要把所有问题都塞进提示词。
方案如何一步步落到工作里？
- 01
选切口
只选一个可完成的任务，例如为一个门店产出可核验的召回建议；写明业务负责人、样本与成功定义。
- 02
做薄切片
读数据、识别对象、调用只读工具、生成证据化建议，先打通一条完整路径，再扩展异常。
- 03
进入工作流
让使用者用实际任务试用，记录接受、修改、放弃的原因；把这些反馈变成测试，而非只记录登录数。
- 04
回流产品
把客户映射放进适配器，把通用错误做成最小复现，把稳定任务沉淀为行业模板，并分别指定维护人。
哪些判断决定方案是否可靠？
什么时候停止定制？
若新增需求只改善当前客户的特殊流程，保留在适配层；若两个不同数据结构都复现同类问题，再讨论核心能力。证据是迁移测试，不是“看上去通用”。
先做建议还是直接执行？
业务定义和数据尚不稳定时先交付建议；只有动作范围、失败恢复和结果查询都可测试，才开放写入。
同一个会员，两套身份
合成演练：两个 CRM 导出文件中分别出现 member_id=M-17 与 loyalty_id=L-92，但没有权威映射。
- 客户适配
- 映射未知 → 不合并、不触达；由数据负责人补充映射版本。
- 产品反馈
- 构造两条最小样本，复现“重复候选人”，提出唯一性约束测试。
- 行业资产
- 输出身份冲突处理规则，第二套合成 CRM 也必须通过同一组测试。
对应课程：你要做什么、交什么？
写清一个必须做与两个暂不做的工作流
- 交付物
- 项目判断书 + Fit/Gap
- 通过条件
- 每个 Gap 有证据、负责人和验证动作
实现两种 CRM 输入的映射与隔离
- 交付物
- 适配器 + 冲突样本
- 通过条件
- 未知身份不能静默合并
把定制代码拆成三类资产
- 交付物
- 客户扩展 / 核心改进 / 场景模板
- 通过条件
- 另一人能在新样本上复现
怎样证明完成，下一次复用什么？
验收检查
验收看任务完成率、异常定位时间和第二次适配成本；同时保留未解决问题与维护责任。
可复用资产
真正可复用的是诊断方法、接口契约、测试与产品反馈机制；不是把某个客户的业务规则复制给所有企业。
