写一份能推进决策的 FDE 客户方案

能推进决策的客户方案，不是产品功能、模型参数和架构名词的集合。它应该让业务负责人知道为什么值得做， 让技术负责人知道怎样做，让安全团队知道风险如何控制，让项目双方知道怎样判断成功。

客户方案的八个必要部分

先写“一页纸”，再写完整方案

如果一页纸说不清，三十页 PPT 也不会更清楚。先使用下面的结构与客户对齐，确认方向后再补充架构、接口、里程碑和商务细节。

如何设计可验收的指标

避免“提升效率”“改善体验”这类无法验收的表达。至少同时定义四类指标：

• 业务结果：平均处理时长下降、转化率提高、错误损失减少或风险事件下降。
• 用户采用：周活用户、目标流程覆盖率、建议采纳率和持续使用率。
• 系统质量：准确率、召回率、延迟、可用性、人工纠错率和单次成本。
• 安全合规：越权率、敏感信息泄露、审计覆盖、人工审批和数据留存要求。

每个指标都要写明当前基线、目标值、数据来源、统计周期和负责人。如果无法获得基线，POC 第一周的任务之一就是测量基线。

先用范围边界表，把“做什么”钉死

范围不能只写“建设智能助手”或“完成知识库”。应从用户、流程、数据、系统、功能、环境、服务和周期八个维度逐项界定， 并同时写出范围内、范围外、前提依赖和确认人。范围外不等于永远不做，而是本期不纳入交付和验收。

范围界定的五条判定规则

1. 能枚举：用户、系统、接口、数据集和功能尽量列出名称与数量，避免“相关系统”等模糊词。
2. 能测量：每项范围都应关联交付物或验收指标，没有验证方法的承诺不要写入交付范围。
3. 有边界：写清开始点、结束点、环境、数据时间段、支持期限和异常处理责任。
4. 有前提：客户数据、接口、人员、审批延期时，计划怎样顺延或重新评估必须提前约定。
5. 能变更：范围不是不能改，但任何新增都必须走变更单，重新评估工期、费用、风险和验收。

把验收标准写成一张可执行表

一条合格的验收标准至少包含：验收对象、指标定义、基线、目标、样本范围、测量方法、证据、负责人和失败处理。 “效果良好”“基本可用”“客户满意”都不能直接作为合同或 POC 的验收标准。

表中数字只是示例，必须根据客户基线、风险等级和项目阶段共同确认。POC 可以重点证明可行性，生产验收则要增加稳定性、 容量、灾备、监控、运维和安全要求，不能直接照搬 POC 门槛。

ROI 粗算：只使用可审计假设

用保守、基准、乐观三组情景展示区间，并把每个假设标注来源。不要把“节省的时间”自动等同于现金收益； 客户必须说明节省时间将如何转化为增产、降本或风险下降。

POC 方案必须包含退出条件

POC 不是无限期免费定制。方案中要明确时间盒、数据边界、参与人数、交付物、验收会议和退出条件。 如果关键数据无法获得、内部负责人长期缺席、合规前提不成立或核心指标明显不可达，双方应能够停止、调整或转向， 而不是继续消耗资源。

方案评审前的最后检查