企业 AI 试点 90 天实战：场景、上线与验收

试点的目标不是证明 AI 很聪明

不少企业 AI 试点从工具采购或领导看到的演示开始，几周后完成一个能对话的原型，却说不清谁会每天使用、替代哪一步工作、怎样验收。Demo 证明技术可能性，试点必须证明业务闭环：需求、方案、上线、使用、测量、复盘和迭代都有人负责。

90 天不是所有项目的固定工期，而是一种管理边界。它足够团队接触真实数据和用户，也能迫使项目控制范围、快速暴露卡点。复杂项目可以延长，但每个阶段仍应有明确交付物和退出条件。

候选场景至少从业务价值、使用频率、数据条件、实施可行性、风险容忍度和结果可测性六个维度评分。增加收入、降低成本、缩短周期或减少风险，是价值方向；高频且重复，才容易形成累计收益。

优先选择业务负责人明确、数据可获得、错误可人工复核的小场景。不要用“最酷”代替“最值得”。客服知识检索、报表整理、文档初审、销售记录完善等任务，通常比自动定价、自动付款或重大决策更适合作为首个试点。

基线必须在开发前记录，包括任务量、处理时长、等待时间、返工率、质量抽检和现有成本。还要约定目标区间、风险护栏、观察周期与退出条件。没有基线，验收只能依赖主观感受。

本阶段交付一张场景卡、当前流程图、指标卡、风险清单和责任矩阵。业务负责人对结果负责，产品或项目经理负责范围，技术团队负责实现与稳定性，安全和法务参与高风险边界。

开发不应从模型接口开始，而应先确认数据来源、权限、版本和更新机制。用真实但受控的数据构建最小流程，覆盖输入、知识或数据读取、模型处理、工具调用、人工复核和结果回写。

评测集应同时包含典型、边界、失败和恶意样本，并记录预期结果。对于知识问答，不只看语言流畅，还要看召回来源、事实一致、引用可追溯和拒答是否正确；对于工具调用，要检查参数、权限、幂等、超时与回退。

每周让真实用户参与，而不是等到“做完”才展示。记录他们在哪些步骤不信任、需要重新输入什么、为何放弃使用。很多改进来自流程和交互，不来自更换更大的模型。

第 45 天应该能够回答：核心任务是否可完成，最主要失败类型是什么，单位调用成本大致多少，哪些动作必须保留人工。如果无法回答，项目还没有进入有效试点。

选择一个团队或一类任务灰度上线，设置使用上限和回退开关。上线不是项目结束，而是开始收集真实分布。监控使用率、成功率、转人工、延迟、单位成本、用户反馈和业务指标，并保留每次调用的必要审计信息。

为一线人员准备简短 SOP：适用场景、正确输入、如何核验、哪些信息不得提交、出错找谁。项目组建立固定节奏处理低评价和失败案例，将问题归类为知识、数据、提示词、模型、系统或流程原因。

版本变更必须回归评测。一次修复可能改善某类问题，却破坏另一类结果。模型、Prompt、知识库和工作流都应有版本记录，关键指标异常时能回退。

验收同时看五类证据：业务指标是否相对基线改善；护栏是否保持；目标用户是否稳定使用；总拥有成本是否在预算内；流程是否具备负责人、监控、异常和迭代机制。

结论不只有“成功”或“失败”。可以扩大范围、保留现状继续观察、缩小场景、改用规则/RPA，或者停止。停止一个无法形成价值的项目，也是试点的重要收益，因为企业避免了更大的规模化投入。

若决定推广，先沉淀场景模板、数据规范、评测集、接口、权限规则、培训和复盘方法，再复制到相近部门。不要把原型代码直接当平台，也不要把一次成功当成所有业务的证明。

今天就可以启动的动作，是邀请业务、技术和运营共同选出三个候选场景，用同一评分表排序，并为第一名写下基线、负责人和退出条件。90 天试点的价值，在于用小成本获得真实证据，而不是用紧迫工期制造另一个 Demo。

本文依据本地知识库《AI 项目实施方法》《AI 生产化三大鸿沟》及企业试点相关笔记整理。