一个 FDE 试点应该交付什么

任务目标

通过一次边界清楚的试点，判断某个业务场景是否值得用 AI 落地，并交付可验收的输入、输出、测试证据与交接责任。

适合与不适合

适合：

• 有一个明确的业务问题，且能找到业务负责人。
• 任务有可观察的输入与输出，能定义合格结果。
• 能获得试点所需的系统访问授权与样本数据。

不适合：

• 业务问题尚未定义，希望通过试点「找方向」。
• 拿不到系统访问权限或真实样本。
• 没有业务负责人参与验收。
• 期望试点就直接形成生产系统。

材料与权限准备

• 业务负责人与一线使用者名单。
• 真实流程样本（脱敏后可用于试点）。
• 系统访问授权范围与期限。
• 预先讨论过的验收标准草案。
• 试点结束后的交接对象与方式。

具体步骤

1. 业务诊断：与业务负责人一起描述问题、当前做法与痛点，写下不做 AI 时的基线。
2. 圈定任务：选择一项可验收的任务，明确输入、输出与边界。
3. 明确权限：列出需要的系统访问授权，确认范围与期限。
4. 定验收标准：与业务负责人共同确定合格结果的判定方法与阈值。
5. 准备样本：整理脱敏后的真实流程样本，覆盖正常与异常情况。
6. 实施与迭代：按样本跑通流程，记录每次失败与修正。
7. 收集测试证据：记录成功与失败案例，不以成功演示推导可靠性。
8. 验收：对照验收标准逐项确认，未达标项明确说明原因。
9. 交接：形成交接文档与责任人，说明后续维护方式。

产出示例

一份《试点交付包》：业务诊断记录、任务定义（输入 / 输出 / 边界）、权限说明、验收标准、测试证据（含失败案例）、验收结论、交接文档与责任人。

结果检查

• 验收标准是试点开始前就确定的，不是事后补的。
• 测试证据包含失败案例，而非只有成功演示。
• 业务负责人参与了验收并签字确认。
• 权限范围与期限明确，到期可回收。
• 交接文档说明后续由谁维护、如何维护。
• 结论是条件化的：在什么条件下值得继续，什么条件下应该停止。

常见失败

• 用演示代替验证：几次成功演示不能推导可靠性。
• 验收标准事后补：结论变成主观争论。
• 权限不清：试点用了超出授权范围的数据。
• 没有交接：试点结束无人维护，成果闲置。
• 结论过度推广：单一场景成功被说成整体可行。

替代路径

如果只需单点能力增强而非业务流程改造，参考《模型 API 接入前应准备什么》。如果只是办公提效，参考《给团队引入 AI 办公工具，先核对哪些条件》。

相关产品与来源