夜雨聆风第一篇：认知
第 2 章｜PoC 地狱
一个故事
2022 年，一家医疗影像公司决定用 AI 帮放射科医生做肺结节筛查。
PoC 做得非常漂亮。算法团队在三家合作医院的历史数据上训了一个检测模型，敏感度 96%，假阳性率控制在可接受范围。内部演示的时候，CTO 把一张肺部 CT 拖进系统，三秒出结果，结节位置标得清清楚楚——每个结节一个红圈，旁边显示尺寸和恶性风险评分。
董事长看完 demo 说："这个上线之后，我们就是行业第一。"
董事会批了预算。项目进入"产品化"阶段。
然后事情开始不对。
第一周：工程师发现，训练用的是 DICOM 标准格式的 CT 数据。但公司签约的二十几家县级医院，CT 设备来自七个厂商，每个厂商的 DICOM 实现都有微妙的差异。有些医院导出的 DICOM 文件缺关键元数据——层厚、窗宽窗位有时候在私有 Tag 里，有时候直接没有。预处理程序不能"读取 DICOM 就行"——需要为每一种设备型号写适配器。
第一个月：模型在县医院的数据上表现退化。敏感度从 96% 掉到 81%，假阳性率从 6% 飙升到 22%。排查发现，训练数据全部来自三甲医院的高端 CT——64 排以上，图像噪声低。县医院大多是 16 排甚至 8 排 CT，图像噪声高一个量级。模型在训练时从未见过这种噪声水平的图像——它不是在"诊断"，它是在"猜"。
第二个月：放射科医生终于开始用系统了。但日均使用 3 次——整个科室 15 个医生，一天只用 3 次。调研发现：系统是独立的——医生需要从 PACS（影像存档系统）里先导出影像、保存到本地、再上传到这个 AI 系统。这多出来的三步操作需要 3-5 分钟。对于日均阅片 80+ 的放射科医生，每多花 3 分钟等于每天多花两个小时。不可能。他们不是不想用——是用不起这个时间。
第三个月：CTO 提议"把 AI 系统集成到 PACS 里"。PACS 厂商回复：开放 API 需要定制开发费 50 万，排期 6 个月。CTO 沉默了。
第六个月：项目叫停。
花掉的预算是 PoC 阶段的 14 倍。
这个项目里没有人是骗子。算法团队没有虚报——96% 的敏感度在那三家三甲医院的数据上是真的。CTO 没有隐瞒风险——他自己也不知道 DICOM 实现有这么多种变体。董事长没有过度干预——他看到了一个令人印象深刻的 demo，给了预算。
每个人都在自己的职责范围内做了正确的事。
但这个项目从一开始就被设计成会失败的。
因为 PoC 的问题不是"技术做得好不好"。是 PoC 验证的东西和上线需要的东西，不是同一件事。
PoC 验证了"在一个受控环境中，算法可以表现好"。上线需要的是"在所有真实环境中，系统能持续产生价值"。
这是两个问题。全世界都把它们当成一个问题。
PoC 为什么容易过
做 PoC 的时候，你会不自觉地挑有利于自己的条件。不是作弊——是工程师本能。
数据挑最干净的。没有缺失值、格式统一、标注质量高。PoC 数据集的分布代表了"数据在最好的情况下长什么样"——不代表"数据在真实世界里长什么样"。
场景挑最典型的。 最清晰的正例和负例。边缘 case 被跳过——因为在 PoC 阶段，"边缘 case 可以以后再说"。但"以后"在大多数项目里是"永远不会"。
评估挑最好看的指标。分类任务看准确率而不是 F1。生成任务看 BLEU 而不是人工评估。不平衡数据集用整体准确率——一个 95% 正例 5% 负例的数据集，模型预测"永远为正"就有 95% 准确率。这在 PoC 报告里看起来很好，在生产中是个笑话。
环境是最可控的。 本地开发机、固定的依赖版本、没有并发压力、没有网络延迟。所有的"环境噪声"在 PoC 中不存在——而这些噪声在生产中无处不在。
用户是友善的。 如果 PoC 阶段有用户测试，那批用户通常是精挑细选的——"找几个跟我们要好的客户试一下"。他们的包容度是普通用户的三倍。他们的反馈不代表真实用户的反馈。
这些选择在 PoC 阶段是合理的——你需要验证"这条路从技术上看走得通"。但问题出在 PoC 过了之后。很少有人回头把这些"选择性优势"一项一项拆掉，换成真实的生产条件。
就好比你造了一艘船，在水缸里测试浮力——通过。然后你说"可以出海了"。水缸里的浮力是真的。但大海里的浪、风、盐、碰撞——这些水缸里没有的东西，才是海难的真正原因。
PoC 地狱：一个组织的集体学习失败
PoC 地狱的运转机制像一条工业生产流水线：
第 1 步：模糊需求。 业务方有一个模糊的愿望（"用 AI 做 XX"），通常来自"看到竞品做了"或"看到新闻说 AI 能做"。
第 2 步：精选 PoC。技术团队挑了最好的数据、最典型的场景、最宽容的评估标准。PoC 结果好于预期。业务方看了 demo，觉得"AI 确实厉害"。
第 3 步：立项。 预算批了，团队组建了，deadline 定了。
第 4 步：现实回来报仇。 PoC 转产品化时，所有被绕过的问题全部回来。数据脏——训练数据集是精选的，生产数据不是。系统不通——PoC 用的是 CSV 导入，生产需要实时 API。用户不配合——PoC 没有测试真实用户行为，生产中的用户有自己的习惯和抵触。预期对不上——业务方记得的是 demo 的效果，真实系统的效果差一个量级。
第 5 步：互相怪罪。业务方觉得技术方"吹牛"。技术方觉得业务方"不懂技术难度"。管理层觉得"AI 团队还是不行"。AI 团队觉得"我们的技术被组织拖累了"。所有人的观点都有一部分是对的——问题是没有人看到完整的图景。
第 6 步：团队重组。 项目失败后，负责人离职或调岗。新人接手。新人从零开始做新的 PoC。
第 7 步：重复第 1 步。
第 6 步和第 7 步是最致命的。组织没有学到任何东西。上一个项目的复盘报告——如果写了的话——躺在某个共享文件夹里，没有人看。新人不知道前人踩过什么坑。下一次 PoC，同样的问题再来一遍。
PoC 地狱的标志不是"项目失败"——项目失败是正常的商业风险。标志是：组织在同一个位置反复跌倒，每次绊倒的石头不同，但没有任何石头被标记在地图上。
一个经历过三次 PoC 地狱的组织：第一次死在数据不可用、第二次死在系统不互通、第三次死在用户不配合。每一次都是独立的问题，每一次都在启动时被认为是"小问题、可以解决"。但每次解决这些小问题的时间都超过了项目容忍度。
这个组织到目前为止没有失败的项目——它只有一个反复失败的流程。
六个问题筛掉一半项目
AI 项目能不能落地，技术可行性是最不重要的一环——不是因为它不难，是因为另外两个维度更容易被忽略。而且被忽略后更致命。
数据轴（三个问题）
第一问：有数据吗？
"有没有"和"能不能用"的区别，在第 7 章会展开讲。这里先讲一个典型场景。
案例 B 里，SaaS 公司 CTO 说"我们的 CRM 有三年销售数据"。林小棠去看了。发现三年里两年半的数据是销售手动填的，很多人只填了客户名和金额，备注栏要么空着，要么写"已联系"三个字。"已联系"是 CRM 里最常见的两个中文字——没有任何信息量。
真问题不是"有没有数据库"。是"数据库里的内容能不能支撑一个 AI 系统的训练或评估"。
字段完整度是多少？ 文本字段的平均长度是多少？只有三个字的信息列不是数据，是占位符。 数据的时间跨度够吗，覆盖了业务周期的完整波峰波谷吗？
第二问：能拿到吗？
数据在法务那里卡三个月是常态。医疗、金融、政务行业尤甚。
一个 AI 项目，数据跨部门共享需要审批、脱敏、签署数据使用协议。这些事情不会自动发生。需要人去推。而推动这些事情的人需要理解：我不是在"走流程"——流程本身是合理的（保护数据安全），但流程的时间线需要纳入项目计划。
FDE 在第一天就要把数据获取时间线排出来。在数据样本真正到手之前，所有"方案设计"和"技术选型"都是在假设数据能拿到的基础上做出的。假设没有验证，项目的底座就是空的。
第三问：够用吗？
覆盖面够不够全场景？长尾 case 有没有？标注质量行不行？
一个做合同审查 AI 的团队，拿到了公司法务部过去三年的合同数据。训练完后发现：模型对租赁合同的审查效果很好，遇到并购条款就完全抓瞎。回头看数据分布——过去三年公司签的合同里 80% 是租赁，并购合同只有 12 份。
数据量够（几千份合同），但数据分布偏到让模型在一个关键场景上等于没有训练。
数据量不是问题。数据分布才是问题。 而数据分布的问题，不看原始数据的人是发现不了的。
组织轴（三个问题）
第四问：有人真的需要这个吗？
案例 A 里的客服团队。如果 AI 被定位成"替代客服"，她们真的需要吗？她们会说需要——在领导面前。她们的实际行为是用一切办法让系统看起来不好用——因为没有人会主动配合裁掉自己的工具。
第五问：决策链上有拦路虎吗？
一个 AI 项目要立项、要预算、要数据权限、要跨部门配合。这条链条上的任何一个关键节点有阻力，都能让项目停滞。
案例 B 里 VP of Sales 为什么消极抵抗？不是因为他不相信 AI。是因为他最好的销售的方法论一旦可以被 AI 复制——他自己最核心的价值（"只有我才能培养出 top sales"）就被消解了。他不是在反对 AI。他是在保护自己的不可替代性。
这种隐藏敌意不会在启动会上说出来。它表现为"这个月太忙，下个月再看"、"能不能先做个内部测试"、"我觉得团队还没准备好"。每一句话单独拿出来都是合理的。放在一起，是阻力。
FDE 要从推脱中读出敌意，从礼貌中读出不配合。
第六问：成功标准能度量吗？
"AI 客服好不好"——没有人能量化。你需要把它拆成可度量的东西：自动解决率、人工转接率、客户满意度评分、平均处理时长、重复来电率。
如果项目启动时没有人定义"什么叫成功"，项目结束时一定有人定义"什么叫失败"。通常是由对你的方案最不满的那个人来定义。
双轨验证：技术轨和价值轨必须同时跑
AI 项目天生是一边造飞机一边学飞。但大多数团队只验证了"飞不飞得起来"——没验证"飞的方向对不对"。
技术轨： 技术上能不能做？模型精度够不够？延迟达不达标？
技术轨的验证方法很成熟——训练、测试、调参、评估。工程师轻车熟路。
价值轨： 做了有没有用？用了之后业务指标动了吗？
价值轨验证比技术轨慢得多——需要真实用户、真实场景、足够使用量、足够观察周期。但价值轨不能在技术轨之后跑。必须同时跑。
因为价值轨如果跑不通，技术轨的结果没有意义。花三个月把精度从 89% 提到 93%，用户不在乎——这个项目从一开始就不该做。
案例 A 的双轨验证
陈柏宇在项目启动时同时开了两条线：
技术轨（工程师主导）：
第一周：用共享 Excel 的 1200 条话术做知识库索引 第二周：Elasticsearch 搭建 + 关键词匹配准确率测试（baseline: 78%） 第三周：引入语义检索，对比关键词和语义的 recall 差异 第四周：退换货意图分类器（规则版）准确率测试
价值轨（陈柏宇自己主导）：
第一周：拿到客服中心过去三个月的关键指标基线（首次解决率 62%，平均通话时长 8 分半，客户满意度 3.6/5） 第二周：定义"AI 客服成功"的测量方案——不只是看模型准确率，是看"客服使用 AI 辅助后的解决率变化" 第三周：找了 3 个客服做 AI 辅助的纸质模拟——不是用系统，是用人工模拟 AI 输出，观察客服使用行为 第四周：从模拟中得出关键发现：客服需要的不是"完整回复"，是"关键信息片段"——她们自己能串成句子，比 AI 生成的完整段落更自然
价值轨的第四周发现直接影响了整个方案的方向：回复生成模块从"生成完-整回复"改成了"生成关键信息点 + 客服自行组织"。这个决策在离线评估中不会被触发——只有在观察真实用户行为时才会浮现。
双轨验证的精髓
不是"两条轨都跑一下"。是：每一次技术轨的迭代，都要回答一个价值轨的问题。
"我们把检索的 recall 从 72% 提到了 85%——客服寻找答案的时间缩短了多少？" "我们加了情绪安抚功能——客户满意度涨了还是跌了？"（有可能跌，因为生成内容更长了） "我们换了更大的模型——回复生成更好了，但延迟涨了。客服在等的那个 2 秒里是不是在骂？"
技术指标提升不等于价值提升。而 FDE 的判断力体现在：在价值轨数据出来之前，就能合理推断哪些技术优化会产生价值影响、哪些不会。
案例推演：两个项目在 PoC 地狱的门口
案例 A：AI 客服
陈柏宇在客服中心坐了两天之后，做了一件事：他没有做 PoC。
他在第二周给老周交了一份报告，核心结论：
60% 以上的来电可以通过整理现有信息解决，不需要 AI 退换货场景的复杂对话适合用 LLM，但前提是物流系统先打通、知识库先建好 建议三步走：Step 1 统一知识库 + 物流系统对接（2 个月），Step 2 规则化高频问答 + App 自助查询（3 个月），Step 3 LLM 处理退换货复杂对话（再做评估） 整个过程中不要宣传"我们上了 AI"——宣传"我们优化了客服体验"
老周看完报告沉默了一会儿："别的供应商都在跟我讲大模型，你让我先做知识库。"
"你现在的问题不是缺 AI。是缺一个统一的信息系统。AI 来了也找不到答案——因为答案散落在 OA、Excel、客服主管的脑子里。先整理答案，AI 才有东西可读。"
"但老板想看 AI。"
"两周后你给老板看一个知识库 demo——不是 AI，但能用。客服输入'退换货条件'，0.3 秒出结果。这个比 AI demo 更实在——因为它是真的、能用的、今天的，不是未来的、训练中的、不确定的。"
这个判断帮老周避免了一个经典的 PoC 地狱。如果选了"全量 AI 客服"方案，他们会先在一个没法用的数据基础上烧三个月钱，做出来一个 demo 好看但上线全垮的系统。然后重来一遍。
案例 B：AI 销售助手
林小棠面对的状况比陈柏宇糟糕：CTO 强力推动、VP of Sales 消极抵抗、销售团队不吭声。
她做的第一件事不是调研需求。是约 VP of Sales 喝咖啡。
咖啡桌上她没有推销任何一个方案。她只是问："你现在最头疼的团队管理问题是什么？"
VP of Sales 说了第一句话："新人出不了单，老人在吃老本，CRM 里的数据基本是垃圾。"
这句话里三个信号：新人培训缺体系、老人缺激励、数据基础设施差。三个信号全部跟 AI 助手有关系——但没有一个是"买个 AI"能解决的。
林小棠改了她的第一步：原计划"做 AI 邮件生成 demo"被替换成"做 CRM 数据质量扫描"。
一周后她拿出了一个报告：CRM 里 37% 的客户记录超过三个月未更新，52% 的沟通记录是空的或只有 5 个字以内的描述，18% 的联系人已经离职但记录还在，6% 的公司名是重复的（同一家公司被不同销售用不同名称录入）。
她把这份报告给了 VP of Sales 和 CTO 同时看。
VP of Sales 的反应变了。不是因为突然喜欢 AI——是因为他终于看到了一个外部顾问在"解决他真正在意的问题"。
她没有成为一个"来推 AI 的人"。她成了一个"来帮他看清问题的人"。
信任是从这里开始的。而信任是一切后续推动的前提。
别这么干
1. 别上来就做 PoC。
你都不知道问题是什么，你去验证什么技术可行性？你验证的是你自己编的问题。
在 PoC 之前至少做完三件事：需求洋葱剥到第三层、数据样本亲手拿到并看过、跟至少三个一线用户聊过（不是他们的老板）。
2. 别用最干净的数据做 PoC。
如果你用精选数据集跑出 96% 精度，你得到的信息是"模型在最好的情况下有这么好"。这个信息对上线决策几乎没价值。
用你真正能拿到的、未清理的数据。看着精度掉到 78%，那才是你的起点。
你不需要在 PoC 里展示完美的结果——你需要展示"在这个真实数据的起点上，我们有多少提升空间、用什么手段提升"。
3. 别只跑技术轨。
PoC 结束时，如果你的结论只有"技术上可行"，你只做了一半。
另一半是：谁会用它？为什么用？不用的后果是什么？业务怎么衡量？成功长什么样？
4. 别把 PoC 的结果当交付承诺。
PoC 的 96% 是受控环境下的 96%。生产环境不受控制。
在 PoC 结论中写清楚：当前精度是在什么数据、什么场景、什么假设下取得的。列出这些假设在生产中哪些会发生改变。不是给自己留退路——是给决策者完整信息。
你写了假设清单，对方仍然决定上线。后续出问题的时候，双方不会互相怪罪——因为决策是透明的。你不写假设清单，上线效果打了折扣——对方记住的是"你说了 96%，为什么现在是 78%？"
检查清单
项目启动前，回答这些问题。不要跳过任何一个。
有没有一份文档，明确写出了"这个项目成功了意味着什么"？不是"用上了 AI"，是业务指标的改善幅度。 数据到手了吗？不是"有人答应了给数据"——是数据样本真的在你硬盘上。你打开看过至少 500 行。 你看过的数据分布和训练数据的分布一致吗？如果不一致，知道差异在哪吗？ 谁会用这个系统？你跟他们本人聊过吗？不是跟他们的老板聊。 有人不希望这个项目成功吗？如果有，原因是什么？你做过什么来化解或缓解？ 如果这个项目不用 AI——只靠规则、流程优化、信息整理——能解决多少？认真评估过吗？ 价值轨的测量方案定了吗？基线数据拿了吗？ PoC 结论里有没有"假设清单"？假设清单给决策者看了吗？