企业AI试点怎么立项、怎么验收：从场景打分到结项报告的完整路径

企业 AI 试点怎么做才不至于三个月后没人用？本文给出立项前的场景打分表、基线怎么定、验收指标与结项报告结构，覆盖企业智能体平台、智能体开发平台、多智能体协同、私有化部署与数据不出域、内网 AI、企业知识库、AI 办公助手与制造业 AI 落地等关键决策点。

本文目录

一、先纠正一个共识：立项不是"申请预算"，是"锁定可验证的承诺"

二、场景怎么选：一张五维打分表

三、基线怎么定：没有基线就没有验收

四、建设阶段：平台选型只需要回答两个问题

五、验收怎么定：四个维度，缺一个就会被追问

六、结项报告怎么写：结构比数据更重要

七、六种常见的翻车方式

八、第二批场景：什么时候轮到软件工厂

九、演练一遍：设备手册查询试点的完整时间线

十、验收通过之后：把试点变成能力

十一、给立项人的一页检查单

# 企业 AI 试点怎么立项、怎么验收：从场景打分到结项报告的完整路径

企业 AI 试点最难的不是把智能体搭起来，而是让它在结项评审上站得住。搭一个能演示的智能体，通常两周就够；但要让财务、IT、业务三方都在结项报告上签字，需要在立项之前就把场景、基线、指标和证据链定下来。本文按立项 → 建设 → 验收 → 结项的顺序，给出一条可以直接拿去用的路径：一张场景打分表、一套基线方法、四个验收维度、一份结项报告结构，以及最常见的六种翻车方式。

文中涉及的平台能力、部署方式与交付周期，以最终交付及双方签订的合同为准。

一、先纠正一个共识：立项不是"申请预算"，是"锁定可验证的承诺"

多数企业的 AI 试点立项表只有三栏：项目名称、预算、预期收益。这三栏写不出可验收的承诺，因为它没有回答两个问题——现在是什么水平，以及三个月后拿什么证明变好了。

一份能被验收的立项，至少锁定四件事：

• 一个具体到岗位的场景：不是"提升办公效率"，而是"设备科工程师查液压故障代码的平均耗时"。

• 一条现状基线：现在这个动作花多少时间、需要几个人、返工率多少。

• 一个改进目标：目标值 + 达成口径。

• 一份证据清单：结项时拿什么材料证明目标达成。

这四件事在立项时写清楚，后面建设阶段就只剩执行；写不清楚，验收时必然变成口头争论。

从更大范围看，试点是一次低成本的验证机会：用最少的投入，确认 AI 智能体企业应用在这家企业里能不能成立。厂商演示的是能力上限，试点要验证的是落地下限——在你们的网络、你们的数据、你们的流程里，它到底能稳定到什么程度。

图 1 立项前要锁定的四件事

二、场景怎么选：一张五维打分表

选场景是整个试点里最容易拍脑袋、也最影响成败的一步。建议按五个维度打分，每项 1～5 分，总分 25 分，低于 16 分的不进第一批。

在这个框架下，第一批试点的优选是三类：

设备手册与工艺文件查询。频次高、资料电子化程度尚可、答案有标准出处、答错代价小。这是最典型的入门场景，也最适合用企业知识库加知识问答系统的组合来承接。

制度与流程问答。报销、考勤、审批流程这类问题，几乎每个员工每年都会问几次，人事和财务被反复打扰的成本很高。这类场景适合直接做成 AI 办公助手，嵌进员工本来就要打开的界面。

跨系统数据查询。比如"这个订单现在到哪道工序了""这条产线昨天的良率是多少"，答案分散在 MES 和报表系统里。这类场景的价值不在回答本身，在于它验证了智能体能不能调通内部接口——这是后面所有进阶场景的地基。

反过来，第一批应当明确回避的：排产算法优化、报价策略生成、涉及安全和合规判断的处置建议。这三类的共同点是答错代价高且难以短期验证，适合放到第二批。

图 2 场景打分的五个维度与 16 分门槛

三、基线怎么定：没有基线就没有验收

基线是这个环节里投入产出比最高、又最常被跳过的一件事。做法不复杂，但必须在系统上线之前完成。

第一步，采集现状样本。 选 20～30 条真实的历史问题或工单，记录现状下每个环节的耗时。比如设备科查一次故障代码：找手册 8 分钟、翻到对应章节 5 分钟、确认版本 3 分钟，合计 16 分钟。这个数字要来自实际记录，不能是访谈估出来的"大概十来分钟"。

第二步，定义指标口径。 同一个"耗时"，口径可以差出一倍。要说清楚计时的起点和终点：是从接到问题开始，还是从打开系统开始；到给出答案结束，还是到问题实际解决结束。口径写进立项表，结项时不允许改。

第三步，留存对照材料。 基线阶段的问题是宝贵的测试集。把它们整理成一份带期望答案的评测集，上线后每周用它回归。这份评测集本身就是企业自己的资产，比任何厂商给的演示数据都更贴合实际。

有了基线，验收时就有一个可比较的锚点；没有基线，所有"效率提升"都只能靠感觉，而感觉在评审会上是最没有说服力的东西。

四、建设阶段：平台选型只需要回答两个问题

试点阶段的平台选型，不需要做全面比价，只需要回答两个问题。

第一个问题：谁来搭？ 如果由 IT 部门集中搭建，那么智能体开发平台的能力就够用——流程编排、工具接入、调试与评测，一个具备基本技术能力的团队可以上手。如果希望业务部门自己动手改提示词、调流程，就需要企业智能体平台提供的权限隔离和版本管理。

第二个问题：数据能不能出去？ 这个问题决定后续所有架构选择。如果工艺参数、图纸、客户信息属于核心资产，那么数据不出域就是硬约束，私有化部署 AI 基本是既定前提。再往下追一层：厂区网络是否稳定、机房是否有运维力量——这两个答案会把方案推到本地化部署，或者进一步推到 AI 一体机、边缘 AI 一体机这类软硬一体的交付形态。

附加要求：出问题时谁负责？ 智能体答错了、调错了接口、把不该给的数据给出去了，追责路径是什么？这需要调用日志、权限记录和版本回溯。试点阶段可以不建完整体系，但日志必须从第一天就开始留。

两个问题回答完，方案形态基本就确定了。反过来，先做厂商比价再回头补这两个问题，往往会推翻已经选好的方案。

还有一条容易被忽略的判断：试点阶段要不要按内网 AI 的标准准备。 如果最终形态一定是内网运行，那试点就应该在内网跑。在联网环境里验证出来的效果，换到内网可能因为模型版本、检索组件或数据源权限不同而明显下降，这种落差在验收时非常难解释。

试点阶段不建议上多智能体协同。单智能体加两个工具就能覆盖上面三类入门场景；把任务拆成多个角色，会显著增加调试难度，而收益在试点规模下看不出来。多智能体协同更适合放到第二批——等流程稳定、单点能力被验证之后，再把链式任务交给多个角色分工。

图 3 试点阶段平台选型的两个问题

五、验收怎么定：四个维度，缺一个就会被追问

验收指标建议分四个维度设计，每个维度至少一个指标。只写效率指标的项目，通常在评审会上会被问到"质量怎么保证"和"钱花得值不值"。

一、效率维度。 同一批任务在系统上线前后的耗时对比。这是最直观的，也是最容易做手脚的——口径必须沿用基线阶段定好的那一套。

二、质量维度。 回答的准确率、需要人工二次确认的比例、引用的出处是否可点开核对。质量指标建议用评测集跑，而不是靠满意度打分。

三、使用维度。 周活跃用户数、人均调用次数、连续四周仍在使用的用户占比。这个维度最能反映真实价值——很多项目效率指标漂亮，但使用曲线在第三周断崖式下跌，那就是没被真正用起来。

四、成本维度。 除了采购成本，还要算上运维人力、数据整理投入和后续扩容的预期支出。试点常见的隐性成本是数据整理——把散落的文档整理进企业知识库，往往比部署系统本身更耗时。

四个维度里，使用维度是最容易被忽略、也最能决定项目生死的。建议在立项时就明确：连续四周活跃用户低于目标人数时，视为未达成，需要复盘而不是直接扩大范围。

六、结项报告怎么写：结构比数据更重要

结项报告不需要长，但要有固定结构，让评审的人能在五分钟内判断这件事值不值得继续投。

一份可用的结构是六段：

第一段，原始承诺。 把立项表里的场景、基线、目标原样贴出来，不做任何修饰。这一段的作用是让评审对照，而不是接受新叙事。

第二段，实际数据。 四个维度的实际值，与基线并列呈现。不要只放提升幅度，基数必须同时出现。

第三段，未达成项。 哪些指标没到目标、差多少、原因是什么。这一段主动写，比被追问出来要好得多。

第四段，意外收获。 试点过程中发现的、立项时没预料到的价值或问题。这一段往往是下一次立项最有价值的输入。

第五段，资产清单。 沉淀下来的模板、评测集、提示词结构、踩坑清单。这是决定第二个场景要花一个月还是半年的关键。

第六段，下一阶段建议。 扩大范围、调整方向，还是终止。给出明确建议，不要只写"继续观察"。

图 4 结项报告的六段结构

七、六种常见的翻车方式

下面六种情况在试点项目里反复出现，每一条都对应前面的某个环节。

场景选得太大。 一上来就做"全厂智能问答"，覆盖所有部门和所有文档。结果是每个问题都答得马马虎虎，没有一处能被验证。对策：把第一个场景缩到一个人、一个动作。

基线是估出来的。 立项时写"目前平均耗时约 15 分钟"，但这个数字来自访谈而非记录。验收时业务部门不认，因为实际是 25 分钟，改善幅度一下被腰斩。对策：基线必须有原始记录。

指标事后补。 建设快结束时才定指标，于是指标自然长成了"系统能跑通"。对策：指标写进立项表，评审时以立项表为准。

入口放错地方。 智能体做在独立网页里，员工需要记住地址、单独登录。用了两次就忘了。对策：把入口嵌进 OA、企业微信或业务系统里。

数据没整理就先上模型。 知识库里塞进几千份格式混乱、版本重复的文件，检索质量差，回答自然差。对策：先做窄库，挑 50～100 份高质量文件跑通，再逐步扩。

试点结束即解散。 项目组结项后人员回原岗，没人维护提示词、没人更新知识库、没人看评测曲线。三个月后系统名存实亡。对策：立项时就明确运营责任人。

图 5 试点中反复出现的六种翻车方式

八、第二批场景：什么时候轮到软件工厂

第一批试点跑通之后，很多企业会问：要不要直接上 AI 软件工厂？

合理的位置是第二批。理由是 AI 软件工厂和自然语言生成应用解决的是长尾小工具问题——一个良率统计看板、一个交期提醒、一个报工校验。这类需求单个价值不高，但数量多、排队久。它依赖两个前置条件：一是企业已经跑通了数据接入和权限体系，二是有一批可参考的模板。

在试点阶段直接上，常见的结果是生成了一堆没人维护的页面，反而增加 IT 的清理负担。正确顺序是：先用第一批试点验证数据接入通道和评测机制，再把软件工厂接入这套体系，让生成的应用天然带审核、带回滚、带统一身份。

图 6 长尾需求从排队到消化的路径

九、演练一遍：设备手册查询试点的完整时间线

把上面的方法串起来，走一遍具体案例。背景是一家有若干车间的装备制造企业，试点场景是设备科工程师查询液压系统故障代码。

第一周，立项。 场景打分为 21 分：频次高（每天多次）、手册电子化（可得性好）、答案有标准出处（可验证）、答错代价小（风险可控）、可复用到电气和机械手册（复用潜力高）。基线采集完成：20 条历史问题，平均耗时 16 分钟。目标定为实现 6 分钟以内，口径沿用基线定义。验收四维度指标同时写入。

第二至四周，建设。 选择本地化部署方案：厂区有现成机房，数据不出域是硬要求。先整理 60 份核心手册进入企业知识库，按设备型号和章节做切分。智能体配置单角色，接入两个工具：手册检索、设备台账查询。每周跑一次评测集，记录准确率变化。

第五周，小范围上线。 设备科 12 名工程师试用，入口放在设备管理系统首页。前两周每天收集反馈，修正了 9 处检索偏差——主要是型号别名和旧版手册混淆。

第九周，验收。 效率维度：抽样 20 条问题，平均耗时 5.4 分钟，达标。质量维度：评测集准确率 88%，引用出处全部可点开核对。使用维度：12 名工程师中 10 人连续四周使用，达标。成本维度：数据整理投入约 6 人日，超出预估 2 人日。

第十周，结项。 报告中主动写明：准确率在旧型号设备上只有 71%，原因是手册版本不全，建议下一阶段补齐。资产清单包含 60 份整理后的手册、20 条评测集、提示词结构和 9 条检索偏差的处理记录。

这个时间线的价值不在数字本身，而在于它每一步都可追溯：立项表里的承诺，在第九周被逐条对照。这就是可验收的试点应该长的样子。

十、验收通过之后：把试点变成能力

试点通过评审，最常见的结局是"复制到第二个部门"。但如果第一次只是把一个场景做成了，第二次很可能要从头再来一遍。

把试点变成能力，需要三样东西真正落地：

可复用的模板。 场景模板、提示词结构、知识库切分规则、评测集格式——这些东西写成文档，第二个场景的启动时间会大幅缩短。

统一的治理入口。 当场景数量从 1 个变成 5 个，权限、审计、版本、成本统计就需要统一管起来，这时候企业智能体平台的价值才真正显现。这也是很多企业选择"试点用开发平台、扩展时补企业智能体平台"的节奏。

持续的评价机制。 评测集每周回归、使用数据每月看、效果异常时能定位到是数据问题还是模型问题。没有这套机制，系统会缓慢退化而无人察觉。

对制造业 AI 落地而言，这一步的难度通常高于其他行业：场景多、部门多、既有系统多，模板能不能复用，直接决定推广速度。

对内网 AI 部署的企业来说，还要额外确认一件事：断网状态下核心功能是否仍然可用。这一点在试点阶段容易漏掉，因为试点期通常还有外网可连。

图 7 从试点到能力的转化路径

十一、给立项人的一页检查单

如果只带走一页纸，就用这一页。

立项前

• 场景能用一个岗位、一个动作描述清楚吗？

• 五维打分是否达到 16 分以上？

• 基线是否有原始记录，而不是估算？

• 目标值、达成口径、证据清单是否都写进了立项表？

建设中

• 数据是窄库起步，还是把所有文件一次性灌进去？

• 日志从第一天就开始留了吗？

• 评测集建好了吗，每周跑吗？

验收前

• 四个维度的指标是否都有实际值？

• 未达成项是否主动写明？

• 资产清单是否包含模板和踩坑记录？

• 运营责任人是否已指定？

上线后

• 入口是否在员工本来就要打开的界面里？

• 断网状态下核心功能是否仍可用？

• 第二个场景能否复用本次的模板？

常见问题（FAQ）

Q1：企业 AI 试点应该从哪个场景开始？

从频次高、数据可得性好、结果可验证、风险可控、能复用到别的部门的场景开始。设备手册查询、制度流程问答、跨系统数据查询是三类典型入门场景。用五维打分表过一遍，达到 16 分再立项。

Q2：试点立项表里必须写哪些内容？

至少四件事：具体到岗位的场景、现状基线、改进目标与达成口径、结项时的证据清单。只写预算和预期收益的立项表，在验收阶段无法支撑任何结论。

Q3：没有历史数据，基线怎么定？

用上线前的真实问题抽样采集。选 20～30 条历史工单或问题记录，逐条记录各环节耗时，作为基线。不要用访谈估算代替实际记录，估算值在验收时最容易被推翻。

Q4：试点该用智能体开发平台还是企业智能体平台？

试点阶段通常只需智能体开发平台：场景数量少、参与人员集中、权限要求简单。当场景扩展到 5 个以上、涉及多部门权限和审计需求时，再补企业智能体平台。反过来先上大平台、场景没跑起来，容易变成摆设。

Q5：试点阶段要不要做多智能体协同？

通常不需要。单智能体加两三个工具就能覆盖入门场景，多角色分工反而增加调试难度。等单点能力被验证、流程稳定后，再考虑把链式任务拆给多个角色。

Q6：验收指标应该怎么设计？

分四个维度：效率（耗时对比）、质量（准确率与出处可核对性）、使用（活跃用户与留存）、成本（含数据整理与运维投入）。只写效率指标，评审时必然被追问质量与投入产出。

Q7：试点需要私有化部署吗？

取决于数据能否离开企业边界。涉及工艺参数、图纸、客户信息的场景，私有化部署 AI 通常是既定前提；厂区无稳定外网时，还需要进一步走本地化部署，或采用 AI 一体机、边缘 AI 一体机这类软硬一体的形态。

Q8：企业知识库应该先做多大？

先做窄库。挑 50～100 份质量最高的文件跑通检索与回答，确认准确率达标后再逐步扩充。一次性灌入大量格式混乱、版本重复的文件，会把回答质量拉低。

Q9：AI 办公助手在试点里适合放哪类问题？

制度、流程、审批规定、报销标准这类高频问题最合适。关键是把入口嵌进员工本来就要打开的界面——企业微信、钉钉、OA 首页，而不是独立网页。

Q10：试点通过后，怎么避免第二个场景从零开始？

结项时强制输出资产清单：场景模板、提示词结构、知识库切分规则、评测集、踩坑记录。同时指定运营责任人，保证评测集持续回归。这两件事决定了第二个场景是花一个月还是半年。

Q11：制造业 AI 落地在试点阶段有什么特别的注意点？

两点。一是数据真实性优先——设备参数、工艺配方、良率数据都要来自真实系统，不能用演示数据凑指标。二是断网验证要提前做，试点期通常还有外网可连，等到正式上线才断网测试，问题会集中爆发。

Q12：试点没达成目标，应该怎么处理？

按结项报告结构如实写未达成项、差距与原因，给出明确建议：调整场景重做、缩小范围，还是终止。试点的价值包含"证明某条路走不通"，如实复盘比勉强扩大范围更有意义。