夜雨聆风上周做了一个测试。
稳定性跑得不错，展示效果也可以。做完给领导看，他走过来，问了一句：
"你用什么模型做的？"
就这一句话，我琢磨了好几天。
不是因为被冒犯。是因为我突然意识到，在他眼里，这个产品的能力约等于一个变量——模型名字。做出来了说明模型选得好，做不出来说明模型不行。
他不是一个人。你去看任何一个 AI 产品的评论区、任何一个技术群的讨论、任何一场产品复盘会——只要效果不好，"换个模型试试"永远是第一个被提出来的方案，也往往是唯一一个。
这件事，到底为什么？
为什么所有人的第一反应，都是"换模型"？
三个原因，一个比一个深。
模型有名字，系统没有
ChatGPT、Claude、Gemini——你能指着它说"我们用的是这个"。它有发布会，有技术博客，有 logo。它是一个"东西"。
但你的上下文管理策略叫什么？多步推理链路叫什么？prompt 编排逻辑叫什么？RAG 的 chunk 策略和检索方式叫什么？
它们没有名字。你没法在会议室里说"问题出在我们上下文窗口管理策略第三阶段的退化检测机制上"。一张嘴就是术语堆砌，说半分钟对面就开始看手机。
所以你只能指着模型说"它不够好"。
人天然用可见的东西做归因。模型是唯一的可见物。背后那些真正决定产品好坏的工程设计——在你能叫出它们的名字之前，它们就不存在。
这行被训练得只会看跑分
每次模型发布都是一张 benchmark 表：MMLU、HumanEval、GSM8K。整个行业被训练出了同一种条件反射：模型质量 = 一个数字。
这个数字有用。但它也制造了一个危险的认知捷径——让你觉得产品的好坏，约等于这个数字的高低。
实际上呢？SWE-bench Verified 榜单上，排名前六的模型首尾分差只有 1.3 分。同一个模型嵌入不同的 agent 框架，分差可以去到 10 分。
框架工程的价值远大于模型代际差。但没有人给框架发 benchmark。你永远不会看到一张表，上面写着"xxx workflow 在投研场景评测得分 92，排名行业第一"。你每天看到的都是"某某模型 MMLU 又涨了 1.5%"。
能上跑分表的东西，才会被讨论。上不了表的，等于不存在。
换模型是最低成本的"在做事"
这一点最微妙。
领导说"换成 GPT-5 试试"——听起来像行动。半小时换完 API，下周就能汇报"我们已切换到最新旗舰模型"。
他说"我们需要重新设计评估体系、上下文管理策略和失败回溯机制"——这听起来像一个季度的项目。没人想启动。
这不怪某个人。组织天然偏好两样东西：低成本决策 + 外部归因。
换模型是外部归因，锅在供应商那边。改系统是内部归因，锅在自己身上。前者半小时搞定，后者要论证、要排期、要跨团队协调——而且你是在一个没有标准尺子的领域里论证。你怎么跟老板说"我们的 workflow 设计比行业平均水平低了 23%"？你说不出来。但你永远可以说"这个模型 MMLU 88，那个 92，换那个"。
不可量化的东西，在会议室里就是不存在的东西。
到这里，你可能会想：这些我都理解。但模型确实很重要，换模型有时候确实有效果。模型难道不是主要问题吗？
好问题。这也恰好是我想说的——
AI 产品跟传统软件，根本不是一个东西。你用错了脑子。
AI产品跟传统软件，根本不是一个东西
确定性死了
传统软件的逻辑很简单：输入 A → 处理 → 输出 B。如果不是 B，一定有一个确定的 bug。找到它，修掉它。上线。
LLM 产品呢？同样的输入，跑十次给你八种略有不同的输出。而且"好"和"不好"的边界本身是模糊的。什么叫"翻译得不够好"？什么叫"回答太敷衍"？你怎么量化？
你拿着一套为确定性系统设计的归因框架，试图理解一个概率性系统。你找不到 bug——因为根本不存在一个"修掉就对了"的 bug。
你找到的只能是概率分布。
一个被严重低估的问题：你怎么知道它好不好？
传统软件有成熟的评测体系。响应时间破了多少毫秒、QPS 到了多少、线上 bug 率是多少，都有现成的监控和标准。一个功能上线，行不行，数字说话。
AI 产品呢？"这个回答好不好"——你拿什么数字说？
我观察到的一个现象是，很多团队在做 AI 落地的时候，最容易跳过的步骤就是评测体系。因为没有现成的、标准化的、好量化也好理解的评测方案可以直接拿来用。
但这不代表评测不重要。恰恰相反——不同的业务场景，需要的评测维度完全不同。你做投研，需要评估推理深度和信息准确性；你做客服，需要评估意图识别和话术合规；你做内容生成，需要评估的是风格一致性和事实正确性。
评测体系没法买现成的。你得自己拼。
但大多数团队不拼。因为拼一个评测体系需要想清楚"这个场景下什么叫好"——这本身就是整个项目里最难的那步。相比之下，去抱一个最新的模型，改一行 API 调用，轻松多了。
于是恶性循环形成了：不搭评测 → 只能用模型跑分替代评测 → 跑分差距被无限放大 → 所有产品问题坍缩为一个解释："模型跑分不够高"。
你连自己的产品在什么场景下失败、失败率是多少都不知道，却能精确报出自己用的模型在 MMLU 上排第几。这不荒诞吗？
模型是一台抽奖机。但你不需要换一台更好的。
把 LLM 想象成一台抽奖机。SOTA 模型的波动区间高一些——在 70 到 95 分之间晃。普通模型可能 50 到 80。
大部分人的思路是：换一台波动区间更高的机器。
但你有没有想过另一个思路——不换机器，而是围着这台机器，搭一套让它每次都能抽出高分的系统？
这就是 AI 产品的真实公式：
产品能力 = 模型能力 × 工作流设计 × 上下文管理 × 工具调用 × 评估体系 × 约束设计 × …
模型决定上限。这一点没人否认。但后面的每一个因子，都可能让你的产品翻倍，也可能让上限形同虚设。
一个中等模型待在精心设计过的系统里，比一个强模型裸奔，上限要高得多。
这件事，我在两个实验里亲自验证过。
两个让我重新理解这件事的实验
第一个：投研 Agent
我做了一个投研场景的 agent。核心思路不是"找个最强模型怼上去"，而是反过来——模型够用就行，系统是主角。
具体做法：
参照了 Claude Code 的精确搜索方式，搭配 tool calling 和一个 planner。主体走流水线，生产管路几乎不用并行子代理。投研场景需要的是精确、不自相矛盾的上下文——子代理放进去，容易萝卜开会、前后矛盾、白费 token。
能用算法的，绝不用 LLM。比如数学计算——确定性方案又快又准，喂给模型纯属浪费。很多人觉得"反正模型也能算"——能算，但有时对有时错。你的产品能容忍"有时错"吗？
评估怎么搞？这类任务没有客观 benchmark。我用了教师模型加约定规则评分——让一个更强的模型当裁判，按事先定好的规则打分。办法很土，但管用。
结果：同样的输入数据，agent 的生成质量超过无约束开源 SOTA 30% 以上。
而且评分标准本身没覆盖 agent 的一部分优势维度——实际差距可能更大。
这不是模型赢了模型。是系统赢了裸奔。
第二个：7B 小模型，也能赢
做一个公告信息抽取系统。任务很简单——从财经公告里抽字段。微调了 Qwen 7B。
长难句抽取：微调后的 Qwen 7B 胜率大概 70%。不高，但开源 SOTA 只有 60% 多。7B 的小模型，在有一定难度的任务上，打赢了参数规模可能是它几十倍的大模型。
当然，70% 还是不可用。但这个实验的意义不在这里。意义在于——谁说小模型一定不如大模型？
简单字段抽取：指令遵循成功率接近 95%。可以进真实管线的水平。而且在大模型身上反而容易出现"想太多"的情况——你让它抽一个日期字段，它给你分析一通这个日期代表什么意义。小模型没这个毛病，你说抽什么它就抽什么。
直觉告诉你的东西——"大模型一定更好"——在真实场景里常常是错的。
不只有我发现了这件事
HumanEval 编程基准测试上有一个经典对比：
老模型直接跑：48.1%
新模型直接跑：67%
老模型 + 好 workflow：95.1%
换模型提升了 19 个百分点。加 workflow 提升了 47 个百分点。 后者的收益是前者的 2.5 倍。
还有一个更极端的例子。GLM-4.7-FP8，一个国产开源模型。裸用写代码，通过率 28.6%，几乎是废的。但套上一层收敛运行时——自动测试 → 语义裁决 → 发现问题 → 回滚 → 重新生成 → 再测试——通过率拉到 100%。
模型没变。系统变了。从不能用变成了全过。
道理不复杂。为什么行业改不过来？
人才结构没跟上
以前做模型的人和做产品的人是两拨人，各干各的。
现在 AI 产品的核心工作——workflow 设计、评估体系搭建、上下文策略、工具链编排——需要你同时懂点 ML、懂点后端、懂点 UX、懂点业务。这种人在市面上不好找。
而且"会用最新模型"比"会搭系统"更容易在简历上展示。你说你搭了一套评估体系让准确率提升了 15%，面试官不知道怎么往下问。你说你用过 Codex、Claude Code、Workbuddy全套，面试官点头。
人才市场天然偏好可验证的信号。模型名是可验证的。系统设计不是。
组织架构没跟上
大多数 AI 团队还是"算法 / 工程 / 产品"三分天下。但 workflow 设计归谁？评估体系谁来搭？
算法说这是工程的事。工程说这是产品的事。产品说我不懂技术。
AI 产品最重要的一块工作，掉在三不管地带。
而且最近一个更具体的症状正在上演。国内部分互联网大厂开始激进尝试"产品 + AI 代替开发"——让产品经理直接用 AI 生成功能，跳过工程师。
结果呢？一团糟。不仅是产品经理不会调校 AI 生成优质代码，整条链路上的每个环节都出了问题：产品和设计因为 AI 写的 PRD 不够精确互相甩锅，产品和开发因为 demo 漂亮但上线难以维护而互相推诿。
一个粗糙的判断：产品用 AI 撸一个 demo，现在普遍可达。撸到真正可上线、可维护的程度——非常罕见。
因为 demo 只需要"看起来对"。上线需要可控的边界、可追溯的逻辑、可回滚的变更。这些东西不会从模型里自己长出来。
更深一层：20 世纪的脑子，21 世纪的系统
传统软件工程的核心假设是：系统行为可预测、可穷举测试。
LLM 产品打破了这个假设。你需要用统计思维去理解系统行为——概率、分布、抽样误差——而不是用确定论思维去"找 bug"。
大部分从业者没转过这个弯。包括很多写 AI 产品文章的人。
这不是能力问题。旧的工程训练教了你一套方法，这套方法在旧的系统上运行了几十年，深入骨髓。突然你面对的是一个输出在统计意义上"差不多对"的系统，你的工具箱全废了。
也不是完全没有好消息
行业头部已经在转了
Anthropic Claude Code 的负责人最近说了句话："我不再写 prompt 了。我有循环在跑，它们负责提示 Claude。我的工作是写循环。"
OpenAI 的工程师也说过类似的话："你不该再给编程 Agent 写提示词了。你应该设计循环，让循环去提示你的 Agent。"
概念正在从 Prompt Engineering 往 Flow Engineering、Loop Engineering ，甚至自进化转。从"怎么问"到"怎么搭可以自我迭代的系统"。
连"AI 变懒了"这事，都不只是模型退化
今年大量用户反映 DeepSeek、豆包、Gemini "越来越难用"。看起来像模型退化了。
真实原因呢？厂商引入了动态推理预算、缓存优化和路由降级——为了控制成本，系统层面降低了每次推理的深度。 模型本身没变，是围着它的那层系统参数被调了。
"模型效果下降"这件事本身，有时候也是系统问题。
我们在 AI 的"编译器时代"
早期软件时代，程序跑得慢，人们会怪编译器。"你的编译器不行"曾经是一个合理的判断。
后来行业成熟了，大家才意识到：算法复杂度、数据结构、架构设计才是决定性能的东西。今天没人会问"你用什么编译器写的"——问了就露怯。
AI 行业正在经历一模一样的阶段。只是因为模型太新、太神秘，这个"编译器时代"会比它的前身持续得更久。
下次有人问你"用什么模型做的"
不怼人。不回"你不懂"。
但你可以试着把对话往下一层带：
"模型是 GPT-5.6 Sol。不过真正花时间的是出错了怎么自动兜底——你想聊这块吗？"
"模型这边其实只占整体工作量的两三成。核心是评估体系怎么搭的，有兴趣我展开说。"
"我们有个发现挺有意思的——小模型在特定任务上反而比大模型稳。要不要看看数据？"
五年前，一个程序运行慢，没人会问"你用什么编译器写的"。大家会问算法、架构和数据结构。
今天人们问"你用什么模型"，不是因为他们外行。是因为他们还不知道该问什么。
问对问题的人，才可能做出对的产品。
你的回答，可以帮他们知道。