YGG臻星科技

AI 问答库

企业第一个 AI 项目应该怎么分阶段推进？

一句话回答

分四步：选一个边界清晰的小场景、建评测集、做最小可用版本、再谈推广。第一个项目的目标不是做出多强的系统，而是让组织学会怎么判断好坏——没有评测集就没有判断依据，后面所有争论都会变成「感觉不太行」。场景要选有真实使用者、失败也不影响主业的，别拿核心流程练手。

关键要点

01第一个项目的真正产出是判断力，不是系统。做完之后团队应该能回答「什么样算做好了」，这比功能多少重要得多。
02评测集必须在开发之前建好，且由业务方构造。先写代码后补评测，等于让实现者自己定考题。
03场景选择的三个条件：有真实且固定的使用者、边界清晰能说清「什么不做」、失败不影响主业。三条缺一条都会显著提高烂尾概率。
04技术选型应该尽量晚做、尽量简单。先用最朴素的方案跑通全链路，暴露出真问题之后再决定要不要上更复杂的技术。
05上线不是终点，交接才是。如果只有供应商能改动系统，项目在第二年就会停止演进。

每个阶段的目标与出口条件

下表把前面那四步拆得更细一些——「推广」实际上包含小范围真人试用和运维交接两段，很多项目正是死在这两段上。关键不在于阶段划分本身，而在于每个阶段都有一个明确的「凭什么可以进入下一步」的判据；没有出口条件的阶段划分只是把一团活切成几块，并不会降低风险。建议在启动会上就把最后一列写进项目计划，并约定判据不满足时宁可延期也不跳过。

阶段	这一阶段的目标	交付物	进入下一阶段的判据
一、场景筛选	找到边界清晰、有人真用的问题	一页纸场景说明：谁用、多久用一次、现在怎么做	能说清「不做会怎样」，且有明确的业务责任人
二、评测集构建	把「做得好不好」变成可测量的东西	真实问题 + 参考答案 + 评分口径，由业务方产出	两个人独立按口径打分，结论基本一致
三、最小可用版本	用最朴素的技术路线跑通全链路	真实用户能自己打开使用的系统	评测集上的表现趋于稳定，不再因改一处而大幅波动
四、小范围真人试用	暴露评测集覆盖不到的真实问题	使用日志、错例清单、用户反馈记录	有人在没被要求的情况下继续使用
五、推广与运维交接	让本方团队能独立维护和演进	后台配置界面、运维文档、一次真实交接培训	本方工程师能独立完成一次改动并上线

第一个场景该怎么选

选场景比选技术重要得多，而且最容易选错。常见的错误有三种。一是选了个「看起来很有价值但没人天天用」的场景，比如给管理层做的分析助手——使用频次低就拿不到反馈，项目会安静地停在演示阶段。二是选了核心业务流程，一旦出错影响生产，团队会因为怕出事而不断加人工复核，最后自动化收益归零。三是范围没边界，需求方说「我们希望它什么都能答」，这种项目验收时永远有人不满意。可用的筛选标准是三条同时成立：有一批固定的人每周都会遇到这个问题；这件事现在的做法能被描述清楚；做错了有人能在下游发现并纠正。同时满足这三条的场景通常不惊艳，但成功率高得多，而第一个项目最需要的就是一次成功。

组织侧的准备，往往比技术侧更决定成败

三件事必须在启动前落实。第一，有一个能拍板的业务负责人，而不只是一个技术对接人。AI 项目会不断遇到「这种情况该怎么答」的判断题，没有人有权定调，项目就会卡在无休止的讨论里。第二，数据的责任人要明确。谁能决定哪些文档进知识库、哪个版本是准的、谁能看到什么，这些问题在技术上都很简单，在组织上都很难，越早解决越省时间。第三，对预期做一次校准。要提前说清楚：系统会出错，第一版一定不如人工，价值来自把大量简单情况处理掉而不是替代专家。跳过这一步，上线后第一次答错就可能变成「这东西不行」的结论。这三件事不需要任何技术投入，但它们的缺失是 AI 项目失败最常见的原因，且技术再强也补不回来。

适用边界

什么情况下本答案不成立

本文针对企业第一个 AI 项目。已经有多个 AI 系统在跑的组织，重点应转向平台化、复用与统一治理，阶段划分方式不同。
如果本方没有任何能对接的技术负责人，无论选哪家供应商、怎么分阶段，风险都会显著上升——这是必须先补齐的前置条件。
强监管行业（医疗、金融、涉密）需要在场景筛选阶段就引入合规评审，把合规留到上线前会导致架构返工。
文中的阶段顺序假设需求相对稳定。若业务本身正在快速变化，应缩短每个阶段并增加迭代次数，而不是延长单个阶段。

同义问法

企业刚开始做 AI 该从哪下手？
AI 项目怎么做试点才不烂尾？
第一个 AI 场景应该选什么？
AI 落地的实施步骤有哪些？
怎么判断 AI 项目做得好不好？