一个 AI 项目开工前，我们会先问的 12 个问题

AI 项目最常见的失败方式，不是模型不够强，而是开工那天没人把问题问清楚。技术选型错了可以换，架构歪了可以重写，但目标含糊、数据没着落、验收标准靠猜，这些成本会在项目后半程一次性爆发出来。所以在任何一行代码落地之前，我们习惯先把下面 12 个问题问完。它们按「越靠前越便宜、越靠后越贵」的顺序排列。

一、先问清楚「为什么做」

1. 这件事不做，业务会疼在哪里？

如果一个项目取消，业务方只是说「有点可惜」，那它大概率不值得投。我们要听到的是具体场景：哪个岗位、每天多少单、卡在哪个环节。找不到这个痛点，说明需求是从技术出发的，而不是从业务出发的。

2. 谁签字验收，按什么算成功？

「效果不错」「比人工快」都不是验收标准。必须落到可观测的口径：通过率、人工复核比例、单均处理时长、错误带来的赔付成本。而且要问清一句：这个数字由谁统计、在哪个系统里看。验收人不清，项目结束时必然扯皮。

3. 错一次的代价是多少，谁来兜底？

AI 输出是概率性的，一定会有错。错一次是客户投诉、财务损失，还是安全事故？错了之后是人工接手、回滚流程，还是只能认赔？容错率决定了这个项目该用多重的模型、要不要人在环路里，也决定了它能上线的边界。

二、再问数据

4. 数据在谁手里，授权链条完整吗？

数据往往不在项目组手里，而在业务系统、第三方平台或某个离职员工的电脑里。要问的是：谁有权提供、以什么名义提供、能不能用于训练、留存多久。授权不清的数据，用起来比没有数据更危险。

5. 数据能不能代表真实世界？

演示环境里的样本通常干净、规整、分布集中；真实世界的数据长尾极长、格式混乱、含大量空值和异常。我们会要求业务方提供最近一个月的原始数据，而不是整理过的样例。拿演示数据训练出来的模型，上线第一周就会暴露问题。

6. 出了错，能不能查回到某一条数据？

线上结果被质疑时，我们需要回答「这个判断基于什么」。如果数据没有版本、没有采集时间、没有溯源链路，模型就只能是个黑箱，出了问题连复盘都做不了。

三、然后问评估

7. 有没有一条不用模型的基线？

规则、关键词、人工流程、上一次的旧模型，都能当基线。没有基线的项目无法证明 AI 的价值，也无法判断这次迭代到底是变好了还是变差了。基线越简单越好，它只需要存在。

8. 评估集谁写、什么时候冻结？

评估集是项目的「考卷」，考卷由出题人定，不能由考生自己出。我们会要求业务专家参与标注，并在开发启动前冻结一批不参与调优的测试集。否则所有指标提升都可能是对考卷的过拟合。

9. 上线之后，指标掉了谁先知道？

模型不是一次交付物，它会随着数据分布变化而缓慢失效。上线前要明确：看哪些监控指标、阈值是多少、谁收到告警、多久复盘一次。没有这套机制，项目会在无人察觉中悄悄退化。

四、最后问组织和风险

10. 谁是真正的产品负责人？

不是「对接人」，而是能在需求冲突时拍板、能调动业务资源、能为结果负责的那个人。多位领导都能提需求、没人能最终决定的局面，是项目延期的头号原因。

11. 合规红线画在哪里，谁签字？

涉及个人信息、内容生成、对外发布的项目，必须提前划出不可触碰的边界：什么数据不能进模型、什么输出必须人工审核、什么场景不能自动化。这条线由法务和业务共同确认，不能由技术团队自行判断。

12. 三个月后，这个项目靠什么活着？

AI 项目的成本不止在开发期。模型要迭代、数据要更新、提示词要维护、使用方要培训。要问清：谁来运维、预算从哪出、如果效果不达预期，退出机制是什么。一个没有维护方案的项目，交付即终点。

结语

这 12 个问题没有一个是技术问题，但它们决定了技术能走多远。我们的经验是：能把这 12 个问题答上八成的项目，通常推进得又快又稳；答不上来的项目，即使勉强开工，也会在第三个月以另一种形式把问题还回来。开工前多花两天问问题，往往能省下后面两个月返工。