从 POC 到签约、上线与扩单
用四周交付节奏、验收证据、变更控制和 90 天客户成功计划，让技术验证真正走向生产。
客户批准 POC，不等于项目成功。FDE 需要把技术验证变成业务决策：在有限时间内取得可信数据， 让用户真实使用，处理安全和系统约束，并提前设计上线后的责任边界。
POC 开始前必须写清的六件事
- 业务目标：验证哪个流程、为什么值得验证。
- 范围边界：用户、数据、系统、功能以及明确不包含的内容。
- 成功标准：基线、目标值、测量方式和最终决策规则。
- 双方投入：客户提供的负责人、用户、数据、接口和评审时间。
- 安全条件：数据分类、权限、日志、环境、留存、删除和人工审批。
- 后续路径：通过后的采购与上线步骤，未通过时怎样停止或调整。
一个可执行的四周节奏
基线与数据
确认用户流程，完成数据检查、安全边界、基线测量和 eval 样本集。
最小闭环
跑通一个端到端流程，让真实用户完成任务，记录失败样本而不追求功能数量。
校准与采用
依据错误类型调整系统、提示词、检索和流程，跟踪用户是否持续使用。
验收与决策
冻结版本，按预先约定的方法测量，输出结果、限制、成本和上线建议。
每周用一张状态表管理风险
用加权评分表做交付考核
验收指标不应简单平均。先设置不能妥协的“门槛项”，再对其余项目按业务重要性加权评分。 以下是一套适合 AI / FDE 项目的示例，双方可在项目启动会上调整权重，但启动后不能单方面修改。
| 考核维度 | 权重 | 主要考核内容 | 评分方法 | 证据 |
|---|---|---|---|---|
| 业务效果 | 30% | 效率、成本、转化或风险指标 | 按目标完成比例评分，上限 100 | 业务数据对比报告 |
| 模型 / 系统质量 | 25% | 准确率、稳定性、延迟、单次成本 | 各子指标按约定权重汇总 | 评测与压测报告 |
| 安全与合规 | 20% | 权限、敏感数据、审计、人工控制 | 门槛项通过后再计分 | 安全测试与审计日志 |
| 用户采用 | 15% | 活跃率、流程覆盖率、采纳率 | 实际值 ÷ 目标值，上限 100 | 产品使用日志 |
| 交付与可运维性 | 10% | 文档、培训、部署、监控、移交 | 按交付清单逐项计分 | 签收单与培训记录 |
单项得分：实际完成值 ÷ 目标值 × 100，最高按 100 分计算；越低越好的指标需使用相反口径。
加权总分：各维度得分 × 对应权重后相加。
建议判定：总分 ≥ 85 为通过；70—84 为有条件通过，必须列整改项和期限；低于 70 为未通过。
门槛项：严重越权、敏感数据泄露、核心流程不可用、关键交付物缺失等任一发生时，不论总分多少均不得通过。
考核时避免三种争议
- 分母争议：开始前冻结样本集、用户范围、统计周期和异常数据剔除规则。
- 归因争议：写明哪些结果由方案负责，哪些受客户流程、人员、上游系统或市场变化影响。
- 主观争议：主观满意度只能作为辅助指标，核心验收应使用系统日志、评测集和可复核记录。
交付物清单也必须纳入验收
| 交付物 | 最低内容 | 验收方式 | 签收角色 |
|---|---|---|---|
| 范围与需求基线 | 范围表、流程图、假设、依赖、不包含项 | 双方逐页确认并冻结版本 | 业务负责人 + 项目经理 |
| 解决方案设计 | 架构、数据流、权限、接口、异常与降级 | 技术和安全评审 | 技术负责人 + 安全负责人 |
| 可运行系统 | 约定环境、版本、配置和账号权限 | 现场演示 + 测试用例 | 用户代表 + 技术负责人 |
| 测试与验收报告 | 指标结果、样本、失败案例、限制与结论 | 复核原始证据 | 验收委员会 / Sponsor |
| 使用与培训材料 | 用户手册、培训、常见问题、反馈入口 | 培训签到 + 操作抽查 | Champion |
| 运维与移交材料 | 部署、监控、告警、备份、应急和联系人 | 运维演练或检查表 | 运维负责人 |
| 数据与账号处置 | 数据保留 / 删除、账号回收、日志留存 | 处置记录签字 | 安全负责人 |
验收材料：把 Demo 变成证据
最终验收包至少包括：
- 基线与最终指标对比，包含样本范围、统计方式和未达到目标的项目。
- 代表性成功案例与失败案例，说明系统在哪些条件下可信、哪些情况下需要人工处理。
- 用户采用数据和访谈反馈，避免只由项目团队内部评价。
- 安全、权限、审计、成本、性能和运维结果。
- 上线所需的产品差距、责任分工、预算、时间表和风险清单。
新需求先记录，不立即承诺。判断它是修复既定目标的缺陷，还是扩大范围的新需求；后者必须评估对时间、成本和验收的影响， 由双方负责人确认后再进入计划。否则 POC 会被不断新增的“顺便做一下”拖垮。
缺陷还是新增范围：用原始基线判断
属于缺陷，原范围内处理
已冻结的需求、设计或验收标准明确承诺了某项能力，但实际结果不符合；修复后不改变用户、数据、系统、流程和交付周期的基本边界。
属于变更，需要重新评估
新增用户群、数据源、系统接口、业务流程、功能、部署环境、性能等级、服务期限，或改变原验收口径，都属于范围变化。
| 变更编号 | 需求说明 | 缺陷 / 变更 | 范围影响 | 工期影响 | 费用影响 | 风险影响 | 决定与签字 |
|---|---|---|---|---|---|---|---|
| CR-001 | 示例：增加第二套 CRM 接口 | 变更 | 新增系统与数据映射 | +5 个工作日 | 重新报价 / 使用预留工时 | 接口稳定性待验证 | 批准 / 拒绝 / 延后 |
从 POC 到合同：提前消除断层
不要等 POC 最后一天才询问采购流程。在第二周前确认供应商准入、预算科目、合同主体、安全评审、法务条款、 部署方式、付款节点和预计周期。技术成功却因采购、合规或责任边界无法上线，仍然是一次失败的 FDE 交付。
上线后的 90 天客户成功计划
稳定上线
监控质量、权限和成本；建立问题响应机制；帮助首批用户形成使用习惯。
扩大采用
培训更多用户，优化流程，追踪采用率和业务指标，清理低价值功能。
复盘扩展
形成业务复盘，确认可复制资产，再选择同流程扩量或相邻场景扩展。
扩单的正确顺序
扩单必须建立在已验证价值上，而不是用尚未实现的承诺推动更大合同。每次扩展都重新确认用户、数据、指标和风险， 并把当前项目中可复用的连接器、eval、流程模板和实施方法沉淀回产品。
项目关闭也要有交付
如果决定停止，仍应完成数据删除或返还、账号与权限回收、文档移交、失败原因复盘和后续条件说明。 专业地结束不合适的项目，往往比勉强签下一份无法成功的合同更能建立长期信任。
本章常见问题
POC 做到什么程度才算成功？
成功不是 Demo 能运行，而是在约定范围和数据上达到预先定义的业务、采用、质量与安全指标，并形成足以支持继续、调整或停止决策的证据。
怎样避免 POC 变成无限期免费项目？
开始前写清时间盒、范围、双方投入、成功标准、变更流程、验收会议和退出条件。新增需求必须评估对时间、成本与验收的影响，并由双方负责人确认。
交付考核应该怎样设置通过标准？
先设置安全、越权和核心流程等一票否决门槛，再按业务效果、系统质量、安全合规、用户采用和交付完整性加权评分。可约定 85 分以上通过、70 至 84 分有条件通过、低于 70 分未通过。