夜雨聆风我在之前有一篇万字长文《AI 投入的价值评估：三类钱，三把尺子》里聊过 AI 投入按 portfolio 分三类：探索类、价值类、基础设施类，每一类有自己的 ROI 口径。其中"探索类"那一节讲了它的算账方式是"单位学习成本"，讲了 Stage Gate 流程，讲了应该用 VC 思维做组合、不押单点。
那篇文章发出之后，我自己又仔细琢磨了下，发现：探索类投入的"执行细节"还有一个反直觉的点没讲透。
把我的观察先讲在前面：
探索类 AI 项目，应该用最好的模型、最好的 AI 工具、投入最好的资源。
这话听起来跟"探索类要控制成本、要小步快试"是矛盾的。我自己最初也是这么想的。这一两年下来踩了不少坑、又看了一些客户和同行的实践，反而更加确信：探索阶段（无论是 POC 还是应用早期）在工具和模型上省钱，是最贵的省钱。
顺便把"探索阶段"的范围讲清楚。它在企业 AI 实践里有两种典型形态：
POC 阶段：还没上生产，只为回答"能不能做"的小规模验证
应用早期：已经上了生产，但还在前 3-6 个月的快速迭代期，模型选型、prompt 设计、产品形态都还没定型
两种形态在成本结构上有差异（POC 调用量小、应用早期调用量已经起来），但共性是认知还没固化、决策错位的代价远远高于单次调用的差价。下面五条论据，对两种形态都适用。
下面把这个判断展开，分五条讲清楚。
一、归因可信度：用最好的都不行，结论才下得了
POC 最怕的不是"做不出来"。最怕的是做完之后，团队说不清楚到底是哪里不行。
这件事可以分两层看。
表层：分不清是模型问题还是路线问题
一个具体场景。某团队要做"AI 自动生成营销文案"的 POC，为了控制成本，选了一款中等档次的模型，跑了 4 周，发现生成的文案在专业度、品牌调性上都达不到业务部门的接受门槛。
这个 POC 算成功还是失败？团队内部立刻分成了两派：
一派说"是模型不行，换 GPT-5 / Claude Opus / Gemini Ultra 应该就能跑通"
另一派说"是这个场景本身就不适合 AI，再强的模型也没用"
两派谁也说服不了谁。最后只能再做一轮 POC，这次换顶级模型。又是 4 周、又是几十万投入。
如果一开始就用顶级模型，结论清晰得多：
顶级都跑不通，路线问题，当场 kill
顶级跑通了，进入价值类讨论，再考虑成本优化用次一档模型
学习成本被次品模型翻了一倍。
深层：用次品做出的失败结论，会污染整个组织对 AI 的判断
这才是最致命的一层。
POC 失败之后，比预算打水漂更危险的事情，是组织内部会给这个方向贴一个标签："我们试过了，AI 在这个场景不行"。一旦这个标签贴上去，3-5 年内很难再立项。
我接触过的几家企业里，都见过这种情况。某个业务线一两年前用次品工具试过 AI，效果一般，后来这个业务线再讨论 AI 时第一反应永远是"我们试过了不行"。等到团队重新被说服愿意再试一次时，市场窗口早就过了。
用次品做出的"AI 在这个场景不行"的结论，会污染整个组织对 AI 的判断。它影响的范围远远超出这一个项目，会延伸到后面所有项目。
二、上限锚点：POC 真正要测的，是天花板在哪里
很多人把 POC 的目标理解成"验证可行性"：能跑就成功、跑不动就失败。这个理解只对了一半。
POC 真正应该产出的，是这个场景能达到的天花板在哪里。这个天花板才是后续生产决策的依据。
用顶级模型做 POC，团队就有了一个"上限锚点"。有了锚点，后续生产部署时怎么选模型才有可对照的尺子：
POC 用顶级模型测到准确率 95% → 生产可以选次一档模型，掉到 85% 还能接受，主动降本
POC 用顶级模型只能到 60% → 这个场景压根不适合，直接 kill
POC 用次品模型测到 60% → 这是最尴尬的情形：不知道是场景上限就这样，还是模型限制。既不敢 kill，也不敢上
这个逻辑其实有一份学科级的方法论背书。Geoffrey Hinton、Oriol Vinyals、Jeff Dean 在 2015 年那篇定义了知识蒸馏（Knowledge Distillation）的论文里，提出的范式是：先训一个复杂的模型或集成模型拿到高性能，再把这部分知识蒸馏到易于部署的小模型里。
蒸馏这个学科的整个前提，就是先有顶级 teacher 模型，再考虑压缩成可部署的 student。压缩永远是第二步。
放到企业 POC 的语境里，逻辑一模一样：先用顶级模型测出场景的上限，再讨论生产部署怎么选合适的成本档次。次品模型测不到上限，就给不了后续决策依据。
三、综合成本：单次调用贵，TCO 反而低
讲完归因问题、上限问题，再说成本问题。
很多人本能地想"用顶级模型成本太高了"。这个判断只在某一个维度上成立：单次调用成本确实更高。但放到 POC 整个生命周期看综合成本（TCO），结论往往是反过来的。
一个简单的算账。
一个 4 周、30 万预算的 POC，里面：
工程师人力成本（按 2 个人算）：大致 18-20 万，占总预算 60%+
模型调用 / API / 工具订阅成本：用顶级模型大致 1-3 万，用次品大致 3000-8000 块
其他（环境、数据准备、测试）：剩余部分
模型成本档次之间的差，最多也就 1-2 万。但用顶级模型带来的好处是：
POC 周期更短（少返工、少调参、少处理工具的边角问题）
中间不用花时间研究"为什么这个 case 不行"，大概率是真的不行，与工具无关
团队精力更聚焦在场景验证本身
我个人的实践经验里，用顶级模型做 POC，整体周期一般能缩短 30-50%。一个本来要 6 周的 POC 压缩到 4 周，相当于省下 2 周 × 2 人 = 28 个人日。按人日成本算下来，省的钱远远超过模型成本的差价。
模型贵几万，但项目早完成两周。这账不用算细，方向就明确。
对于已经上了生产的 AI 应用早期，调用量起来之后 token 成本占比会比 POC 高一些，单笔模型差价的绝对值也会被放大。但核心算账逻辑不变：应用早期的决策错位成本（产品形态错配、模型选型错配、用户认知伤害），远远高于节省的那点 token 钱。这一阶段的"省"，要省在生产稳定期再做，不要前置过来。
四、工程聚焦：把团队 80% 的精力还给"真问题"
这一条是从工程效率的角度看的。
用次品工具和次品模型时，团队的精力会被消耗在哪里？我观察下来大致是这几件事：
上下文长度不够，需要拆分文档、设计分段策略
推理速度慢，需要加缓存、加批处理
JSON 输出不稳定，需要加重试机制、加格式校验
长上下文遗忘，需要做摘要再喂回去
复杂推理出错，需要拆 prompt、加 chain-of-thought
这些事情每一件都是真的需要做的工程工作。但放在 POC 阶段，它们都不是 POC 要回答的核心问题。
POC 阶段最该想清楚的是业务问题：这个场景到底能不能用 AI 做、AI 产出的质量业务方能不能接受、整个工作流上 AI 应该承担哪些环节。
用次品工具，团队 80% 的精力会被各种"对付工具的局限"消耗掉，真正花在业务问题上的精力只剩 20%。
用顶级工具，比例就反过来。这 60% 的精力差，决定了 POC 的质量。
这件事其实不是 AI 时代才有的观察。Joel Spolsky 2000 年那篇被工程界传烂的《The Joel Test》里，第 9 条专门讲"Do you use the best tools money can buy?"，原话大致是：
"顶级开发团队不会折腾自己的程序员。即使是使用低性能工具带来的小挫折，累积起来也会让程序员沮丧。一个沮丧的程序员，就是一个低产的程序员。"
这是 25 年前的工程界共识。最贵的工程师身上省工具钱，是反向经济学。
到了 AI 时代，这条共识不仅没过时，反而更适用。因为 AI 工具的能力差距比传统工具大得多。同一段代码任务，顶级模型可能 30 秒就跑通了，次品模型可能要工程师调一整天 prompt 才能勉强跑出来。
五、回到本质：POC 预算买的是判断
前面四条其实都在回答同一个问题：为什么 POC 阶段省工具钱反而是亏的？答案最终落到这一句：
POC 预算的本质是"买判断"。
这是我在上一篇万字长文里反复讲的一个点。如果接受了这个前提，那"用最好的模型 / 最好的工具"就是顺理成章的结论：
买判断，要求的是"判断质量高、判断速度快"
判断质量高 → 要用能产出可信信号的工具 → 顶级模型
判断速度快 → 要让工程师精力聚焦在场景而不是工具 → 顶级工具
判断本身要可重用 → 要给后续生产决策留上限锚点 → 顶级模型才测得到上限
探索阶段（无论是 POC 还是应用早期）和生产稳定期不在一条逻辑线上。生产稳定期要的是 unit economics 为正、单位成本可控、规模化稳定，那时候才该谈"用次一档模型省成本"。但在探索阶段把生产稳定期的成本焦虑前置过来，是把两件事的口径搞混了。
一段需要做的区分
写到这里，需要主动把一个潜在的反方观点拎出来讲一下，否则容易被读者反将一军。
市面上有一种相当主流的叙事，强调"快速搭粗糙原型再迭代"，意思是 POC 不需要做得太重，能跑就行，先把方向试出来再说。这套叙事在传统 SaaS / web 时代是对的。因为那个时代的"粗糙"意味着功能不全，但"功能不全"是可控的、可补的：前端少几个按钮、后端少几个接口，不影响判断"这条产品路线有没有市场"。
但 AI 时代的"粗糙"有一个本质区别：
AI 时代的"粗糙"是模型能力不全。模型能力不全，会产出误导性的信号。
一个粗糙的前端，不会让你以为产品方向错了；但一个粗糙的模型，会让你以为这个 AI 场景做不通。这是和传统 SaaS / web 时代的根本差异。
所以"快速粗糙原型"这条经验在 AI 时代要做修正：速度仍然要快，但"粗糙"的范围不能扩到模型能力本身。模型能力要顶级，其他环节可以粗糙。
边界条件
任何观点都有适用边界，这一条也不例外。我能想到的几个不适用场景：
1. 数据合规场景。POC 涉及的数据不能传给闭源 API，或者只能在内网部署的开源模型上跑。这种情况下"用最好的模型"受合规约束，要在合规允许的范围内取最好的那个。
2. 目标本身就是验证"低成本下能不能跑通"。比如某些 To C 场景，POC 要回答的问题就是"这个功能在 token 成本 5 分钱以内能不能跑通"。这时候用顶级模型就违背了 POC 的目标。
3. 防止过强模型遮蔽真实场景挑战。如果 POC 或应用早期只用顶级模型测了一次就过关，没有再做"次模型能否覆盖"的二次验证，可能出现进入生产稳定期换次模型立刻崩溃的情形。所以顶级模型测上限之后，最好还做一次"次档模型能不能接住"的二次验证，再决定生产稳定期用什么档次。
这三个边界都成立，但都是局部场景。在大多数企业 AI POC 的场景里，默认应该用最好的模型和工具。
写在最后
回到上一篇万字长文里的那条核心判断：
探索类投入的 ROI 口径，是单位学习成本。
这一篇文章其实是把这条判断进一步往下推了一层。如果接受了"探索类是买判断"这个前提，那"买判断的钱要花在最能产出高质量判断的工具上"就是不需要再论证的常识。
我猜大多数 CIO / CTO 朋友其实心里都知道这件事。但落到具体的 POC 立项时，预算管理流程会本能地要求"用最经济的方式"。这套预算管理的本能是对的，但用错了地方。对生产部署是对的，对 POC 是错的。
如果一定要给一个具体的建议：下一次提 AI POC 预算、或者评审一个还在早期阶段的 AI 应用时，主动把"模型用最顶级版本"写进申请书或评审纪要里，并把理由讲清楚。不为别的，只为让判断质量更高、判断速度更快、后续决策依据更扎实。这件事算是 CIO / CTO 层面的方法论判断，不该被当成工程师的工具偏好。
参考资料
Geoffrey Hinton, Oriol Vinyals, Jeff Dean, Distilling the Knowledge in a Neural Network, arXiv:1503.02531, 2015
Joel Spolsky, The Joel Test: 12 Steps to Better Code, 2000（Item 9: Do you use the best tools money can buy?）
Andreessen Horowitz, How 100 Enterprise CIOs Are Building and Buying Gen AI in 2025, 2025
徐翔轩，《AI 投入的价值评估：三类钱，三把尺子》（万字长文）
我是徐翔轩，做了 18 年企业软件。后续会持续聊聊数字化、企业 AI、产品商业化和 to B 经营方面的观察和思考。如果你也在推动数字化，希望这些内容对你有用。
往期精选：
OpenClaw 这么香，"企业级的 OpenClaw"该怎么搞？
CIO 的下一个身份是 C AI OO（一个不算严肃的判断）
企业 AI 团队的负责人，内部转化还是外部招聘？（五种常见的牵头路径与思考）
为什么 AI Coding 产品都在长出 spec？聊聊规范驱动开发（SDD）
Workflow 还是 Agentic？可能是一个被问错的问题
Vibe Coding 来了，还要 IT （部门/团队）干什么？
