两种死法
大多数企业 AI POC 不是死于技术，而是死于两种常见开局。第一种：演示很惊艳——模型在会议室里流畅地总结、回答、生成，然后两周后没有人再打开它。第二种：范围过大——POC 变成“小一号的大系统”，需求评审、权限设计、系统集成接踵而来，半年后和正式项目一样难产。两种死法共用一个根因：把 POC 当成了能力的展示，而不是一个待回答的问题。
POC 要回答的唯一问题
一个值得做的 POC 只回答一个问题：如果 AI 介入某个动作，是否会带来可观察、可重复、可被负责人判断的改善？这三个词各自是一道门槛。可观察，意味着改善有基线可比，而不是“感觉更快了”；可重复，意味着同样的输入再次发生时，改善仍然出现，而不是一次性的运气；可被负责人判断，意味着业务负责人能基于自己的标准说“这算成功”或“这不算”。任何一个词站不住，POC 结束时你得到的只是一段无法决策的观感。
先排除，再比较
在给候选流程打分之前，先用三条规则做排除。高风险的排除：对外发送、不可逆、或合规敏感的动作，第一次验证不应该从这里开始。低可见性的排除：产出没有人用得上的流程，优化得再好也不会被采用。无负责人的排除：找不到一个愿意为采用结果负责的人，POC 结束时就没有人接手。排除法比打分法更重要——它防止你因为“技术上有趣”而破例。
业务价值：估算而不是感觉
价值不需要精确，但需要拆开：这个动作发生的频率、每次消耗的时间、出错或返工的代价。三个数相乘，就是一个可以和同事讨论的量级，而不是一句“提升效率”。同时问一个反向问题：如果什么都不做，一年后的代价是什么？有些流程每次只省几分钟，但每天发生五十次；有些流程一年只做两次，但每次出错都很贵。量级不同，优先级自然不同。
可行性：看输入，不看模型
可行性判断的是启动条件，不是模型能力。输入有没有边界——能不能说清楚“进来的是什么、长什么样、从哪里来”；数据拿不拿得到——授权、格式、样本三件事是否都能落实；输出能不能被检查——是否有人能快速判断“这个结果是可用的”。可行性差最常见的表现是：要先把三件系统改造做完，才能开始验证。遇到这种情况，要么换一个不依赖改造的切片，要么把改造本身当作第一个项目。
风险：问错了会怎样
风险不是“模型会不会出错”——模型一定会出错——而是“错了会怎样”。影响面有多大、是否对外可见、能不能回退。第一次验证优先选择只读动作：AI 生成草稿、建议和摘要，人确认之后才写回或发送。一个错误只存在于草稿里的系统，和一个错误直接到达客户的系统，验证策略应该完全不同。
采用复杂度：最常被漏掉的维度
前三个维度都能在会议室里讨论，采用复杂度只有走到现场才能看清。它问的是：谁的工作习惯会被改变？产出要不要经过审批？和现有系统如何共处？一个技术上简单、但要求销售改变工作习惯的 POC，失败率远高于一个技术上中等、但完全嵌入现有流程的 POC。评估方法很朴素：把使用这个动作的人请进来，问他们“如果每天多这一步，你会做吗”。
验证计划写在开始之前
五件事必须在 POC 开始前写下来：基线是什么——现在的耗时、出错率或延迟；评估集从哪里来——用什么样本判断质量；谁确认结果——判定人及判定标准；何时停——时间盒或失败条件；什么条件下扩大——从单点走向流程的前提。没有这份计划，POC 结束时你们讨论的是观感；有了它，讨论的才是一个可以复核的结论。
两周是一个合理的时间盒
第一次验证的时间盒建议定在两周。两周不够得出结论，但足够看到信号：真实使用次数、人对 AI 产出的修改率、负责人的直接反馈。这三个信号比任何汇报都诚实。如果两周内连信号都没有——没人用、没人改、没人评价——这本身就是结果：问题不在模型，在流程选择或采用条件。
四个常见反模式
第一，从最难的流程开始——因为最有价值，也因为最不可能在时间盒内跑通。第二，以模型选型为第一步——方向由流程决定，模型影响的是成本与质量的边际。第三，POC 变成采购理由——验证的目的是学习“该不该、在哪、如何做”，不是为一份采购清单背书。第四，没有“不采用”的选项——如果一个 POC 无论结果如何都一定会“成功”，它就不是验证，是仪式。
什么时候轮到模型
模型选型有其位置，但在流程判断之后。同样的工作流，换一个更强或更便宜的模型，改变的是单位成本和错误率；但如果流程本身不值得做，模型再强也没有意义。先固定动作、边界和判定标准，再让模型成为可替换的变量——这也是为什么健康的 POC 架构里，模型永远不是硬编码的部分。
把判断写成可传阅的一页纸
这套排除与打分不必留在会议室里。把它写成一页纸：候选流程、四个维度的分数、排除理由、第一个切片的定义、验证计划。这一页纸的作用是让没参加会议的同事也能挑战你的判断——被挑战后仍然站得住的选择，才是值得投入两周的选择。我们在陪跑诊断里交付的机会地图，本质上就是这一页纸的完整版。