LUOYU INSIGHTS · FDE 与交付
FDE 如何把业务目标变成生产应用？识别企业 AI 的七类部署缺口
从数据、规则、系统、评测、权限、组织和运维七方面识别部署缺口，避免把模型演示能力直接等同于企业交付能力。
模型能够完成一道题，与企业能够持续使用一个系统，是两种不同条件。前线交付的重要工作，是找出中间缺少什么，并把缺口变成可执行、可检查的任务。不是所有问题都需要换模型，有些需要补资料、统一规则或重新安排责任。
业务目标要落到具体任务
“提高服务效率”应继续拆解为查询、判断、回复、审批和执行。明确用户、输入、完成条件和错误后果。一个模型可能擅长生成回复，却无法凭已有资料确认库存或客户授权。
把完整流程画出来，标出模型、系统和人员各自承担什么，才能判断新能力应该放在哪里。没有确定任务时，演示容易替代决策，项目也容易不断扩大。
七类缺口怎样排查
| 缺口 | 需要检查的条件 |
|---|---|
| 数据 | 资料是否有效、完整、获准使用并能更新 |
| 规则 | 术语、例外和判断依据是否有人确认 |
| 系统 | 接口、账户、环境与业务状态是否可用 |
| 评测 | 是否有代表任务、阈值和失败记录 |
| 权限 | 输入、输出、日志和动作是否受控 |
| 组织 | 谁配合、谁验收、谁处理争议 |
| 运维 | 谁维护、成本如何监测、异常怎样恢复 |
这是一张工作清单，不是用来给企业贴成熟度标签的评分表。每个缺口应有证据、负责人、解决方式和放行条件。
用缺口决定下一步
假设产品助手回答不准：先检查资料中是否有正确规格，再看检索是否找到，最后看模型是否误解。若手册本身冲突，增加提示无法替代业务确认；若接口不可用，演示数据也不能证明正式系统已连接。
把未知问题分类，可以减少盲目投入。某个关键条件需要客户协调时，应写进排期与范围，而不是让工程人员不断用临时补丁绕开。
工程负责人和交付负责人如何配合
工程人员提出实现、测试和运行要求；交付负责人组织依赖、范围、用户反馈与验收；客户确认业务规则和优先级。小团队可以兼任角色，但不能让这些工作无人负责。
在每个里程碑同时回答：软件做到哪里、业务任务改善多少、还缺什么。三者互相联系，却不能相互替代。进度条完成不代表用户采用，用户喜欢也不证明权限正确。
为什么要尽早接触真实使用
实际任务会暴露简称、缺资料、工作习惯和异常。先以受控范围让使用者参与，可以在扩大投入前发现问题。这里的“早”不是绕过授权上线，而是尽早安排真实任务与明确审核。
测试失败后记录原因，调整范围或方案，再验证。不要只保留成功样例，也不要把用户不采用一概归为不愿改变；可能是工具增加了核查和复制成本。
成果如何变得可重复
将通用接口、测试方法、流程模板和维护说明从项目中提炼出来，减少下一次从零开始。客户专属数据与规则仍按授权管理，不能因为有复用价值就进入公共资产。
对于暂时无法可靠解决的问题，保留失败条件与替代路径。技术能力变化后可以重新评估，但不能提前把未来可能性写成当前承诺。
交付结束时应留下什么
至少留下运行成果、测试证据、已知局限、规则与权限、操作维护和后续建议。客户应知道能用在哪里、不能用在哪里、问题找谁。