核心变量是容错度
评估 AI 场景，我第一个看的永远是容错度：模型出一次错，代价是什么。推荐系统推错一条内容，用户划走就完了，容错度极高；医疗辅助诊断错一次，可能是人命，容错度逼近零。GitHub Copilot 能成，一半功劳在场景选得好：代码写错了，编译器报错、测试跑不过、code review 拦住，工程师兜底的机制本来就是现成的，AI 犯错的成本被压到很低。反过来看，自动驾驶喊了十年还在爬坡，卡的就是同一个变量。
完整框架：五个问题
我把评估拆成五个问题，按顺序问，任何一问答不下去就先停下。一，任务是否高频重复？低频任务用户形不成习惯，AI 的价值也摊不开。二，输出是否容易被校验？代码有编译器，翻译有双语对照，客服回复有用户的即时反馈——校验成本低的场景，AI 的「不确定」就不是致命伤。三，出错的代价有多大？这决定你需要多高的准确率、多厚的人工兜底。四，数据从哪来？没有领域数据，模型效果停在及格线，体验撑不起留存。五，省下来的时间值多少钱？算得清 ROI 的场景，付费才好谈，「帮你省事」和「帮你省钱」之间隔着一条付费鸿沟。
五个问题不用打精确分，挨个过一遍就行。拿「AI 客服」走一遍：高频重复，过；输出被用户即时检验，答得不对用户马上追问，过；出错代价中等，答错一次丢的是满意度不是人命，配人工接管就能控住；数据有现成的历史工单和知识库，过；省的是客服人力，ROI 一算就清楚。五问全绿，所以客服是这波 AI 落地最狠的场景之一。换一个「AI 自动生成法律判决书」：高频，过；校验难，出错代价极高，第三问就卡死了，只能退回「辅助法官起草」的形态。
AI 做草稿，人做终审
五个问题背后其实是同一条原则：现阶段 AI 最适合「生产草稿」而不是「交付终稿」的场景。写文案初稿、生成会议纪要、出代码骨架、做设计初版，都是人对结果做最后一道把关。所以选场景时我会刻意找「人本来就要审一遍」的流程，把 AI 嵌在审之前，人和 AI 各干擅长的事。如果一个场景要求机器直接交付、人完全撒手，现阶段大概率做不起来——不是技术永远不行，是还没到时候。
低容错场景不是不能做，是换个做法
医疗、金融、法律这些低容错场景并非禁区，但打法完全不同：AI 只做辅助和提示，决策权和责任都留在人手里；准确率门槛高，冷启动期长；往往还要牌照和合规先行。看过太多团队用做 C 端工具的速度预期去做医疗 AI，最后死在验证周期和合规流程上。所以这个框架的结论不只是「适不适合」，还包括「该用什么节奏做、做什么形态」。同一个需求，「AI 替人做」可能五年都做不成，「AI 帮人做」也许三个月就能上线收钱——选形态往往比选场景更决定生死。