第 2 节 · 幻觉：以为接个模型就完事¶
导读¶
做 AI 产品最大的幻觉，是以为"接个大模型"就是全部工作量。
我自己的产品 OneCode，第一版里一个真模型都没有——可它的演示毫无破绽。从"我差点以为成了"，到亲口承认缺的从来不是模型，我用了两个月。这一节把这段账翻开。
一、第一版是假的：十个 AI 员工全是演的¶
2026 年 6 月，OneCode 第一版出来，编号 0.1.0。
那是一个网页版的开发工具，界面上排着一列角色：CEO、产品经理、设计师、架构师、开发、运维、测试、运营、数据、财务。十个。
你打一句话，对应角色就回你。看起来很齐整——一家公司该有的岗位，一个不少。
只有一件事不对：这十个员工，一个模型都没接。
他们的回复来自一条假的数据管道。版本记录里对这一条的原文是"给 agent 的回复做了一条假的数据管道"。当时的代码注释写得更直白——真正的调用被注释掉了，旁边留了一句，大意是"先用模拟数据，后续替换为真实调用"。
连"流式输出"也是演的。你会看到字一个一个往外蹦，很像有人在那边思考——其实那一串字是脚本一帧一帧喂给屏幕的。会话是怎么开始的，是假的；工具是怎么被调用的，是假的；文件是怎么被改的，还是假的。
那不是十个 AI 员工在干活，是十个提线木偶在对口型。
说出来很丢人。但当时我并不觉得丢人——我当时还挺得意。界面上有十个角色，有输入框，有回话，还有一个像模像样的代码编辑器，一个"AI 原生 IDE"该有的样子，它全都有。
这就是幻觉第一次露头：我以为我做出的是产品，其实我做出的是一个演示。
图 B-2-1（待出）：第一版的样子——十个角色，零个模型
二、假的最骗人的地方，是它"看起来"是对的¶
假的东西分两种。
一种假得明显，你一眼就拆穿；另一种假得专业——它把"看起来对"的每一个细节都补齐了：模拟的流式输出、模拟的工具调用、模拟的文件变更。很不幸，我做的是后一种。
为什么会这样？因为"看起来对"和"跑得对"，用的根本不是同一套证据。
看一个界面，你判断的是：有没有角色、点了有没有反应、字有没有往外蹦、动作有没有一个接一个。这些全是表面特征。而一个模型到底在不在后面干活，是内部事实。表面特征可以伪造，内部事实伪造不了——但我当年只做了表面。
最有欺骗性的假零件，不是那些一眼假的，是把细节做足的。
这就像样板间。样板间和真住进去的家，在你走进去的那十分钟里没有区别——墙是白的，灯是亮的，柜门是顺滑的。区别要等你开火做饭、洗澡排水、住够一个雨季才暴露。
假界面也一样：它在你按下回车的那三十秒里，和真界面一模一样。
而它骗到的不只是观众，还有做它的人。因为演示是一个关于"动"的信任游戏——只要有东西在动，人就会默认它在工作。我盯着那串往外蹦的字看了很多遍，越看越觉得它在思考。
更隐蔽的一层是：演示首先骗到的是做演示的人自己。 我是先有界面、后有模型的，所以每次点开它，我看到的是"它已经能跑了"；至于"跑的是什么"，被我自动跳过了。
一个东西看起来对，和它真的是对的，中间隔着的是全部工程。 而工程恰恰是所有演示里看不见的那部分。
假的东西最狠的一点是：它从不报错。 真的会断、会超时、会说不该说的话；假的永远按你写好的路线回话，一次意外都没有。一个从不报错的系统，看起来就是一个完美的系统。
三、把它换成真的，问题才开始¶
几天后，我把假的换掉了。
真的网关服务、真的终端进程、真的把命令行 AI 接进来——版本记录里留下的是一串真实的替换动作，不是形容词。
换完我等着看它变好。结果它没有变好，它开始暴露。
因为假的从不报错（再说一遍），而真的一接上，第一次真实调用就带来一堆假的永远遇不到的东西：密钥没配、额度会满、连接会断、上下文会超长、本地终端会挂掉。
| 0.1.0（第一版） | 几天后（第二版） | |
|---|---|---|
| 十个角色 | 有 | 有 |
| 背后的模型 | 无，回复来自假的数据管道 | 真的网关、真的终端、命令行 AI 接上 |
| 流式输出 | 脚本一帧一帧喂出来的 | 真的 |
| 会不会报错 | 永远不 | 经常 |
这些问题里，有一类特别顽固，也特别值得记住：
不是模型接不上，是模型接上了之后，整个系统不知道该怎么对待它。
我想换个模型试试，发现要做到这件事，得改配置、再重启整个会话。想同时留着两个供应商备用？系统里根本没有"供应商"这个概念。
于是第二层幻觉浮出来：我一直把"接个模型"当成一个动作——接完，就完了。它不是动作，它是接口。动作做完就结束，接口要长期维护、要能换、要在坏了的时候自动兜住。
补这一层，不是一两个版本能补完的。每加一次能力，本质上都是在把"模型"这件事，从一个零件，重新摆回到一个系统里去。
也是在这段时间，我碰到了第三个幻觉，比前两个都更容易上钩：以为模型越强，产品就越好。 可模型再强，也只是你手里一个更强的零件。零件换得再勤，如果零件之间还是用手拧的，整台机器该散还是散。
四、两个月后我才承认的那句话¶
2026 年 8 月，我在一份设计文档里，写下一句自我判决：
这个产品的网关不是 LLM 网关。它只是网页工具的入口，零模型路由能力。
这句话有两个重量。
第一，零路由。模型接上了，但我并没有得到"换模型"的能力，我得到的只是"能跑一个模型"。第二，现状是单供应商：改模型等于改配置加重启后端会话。换句话说——模型的入口只有一个，而且换一次要停一次。
这就是"接个模型就完事"真正的破处。不是模型没接上，是模型接上了，而模型之上的那一层，一层都没有：谁来选、怎么切、坏了换谁。
更刺人的是，这个缺口不是我"还没来得及做"，是我"才第一次意识到它是个东西"。在此之前，我反复找的原因都是模型不够强、工具不够顺手——唯独没想过，问题坐落在模型和我之间。
后来做"换模型"这件事，从开工到验收闭环，中间挂起了 12 天。12 天的原因不是技术难，是其中一个环节——人工走查——非我不可，而我能给它腾出的时间有限。模型可以 24 小时不睡地等，人不能。
顺带把这个产品的真相说清楚：它本质上是"命令行 AI 编程工具"的桌面壳。它自己不产生智能，它做的事情，是把外面已经很好用的命令行 AI，装进一个能点、能看的窗口里。这句话比任何宣传语都更接近它。
五、从"接模型"到"接系统"¶
到这里，幻觉的全貌才露出来。
缺的从来不是模型，缺的是模型之上的那一层。这一层在本书后面会讲到的那张七层图里，往上对应两个位置：
- 一个是工具层（L2）。模型不是被你直接使用的，是被工具调起来的。谁可以用什么工具、怎么用、用完怎么回，这一层说了算。
- 一个是组织层（L6）。谁用哪个模型、什么时候切、坏了交给谁、几个模型之间怎么分工——这不是模型的能力，这是路由的能力，是组织的能力。
一层是路由，一层是切换，一层是谁坏了好顶上——这些没有一个字写在模型的能力清单里，但它们决定了你的产品能不能换、能不能长、能不能在半夜挂掉之后自己站起来。
所以"接个模型就完事"这句话，错在哪？
它把第一步的采购，当成了整件事的交付。
用造车说最清楚：接模型，是买了一台发动机。 发动机是好东西，但你离一辆车还差一整套传动系统和一个底盘。你不能抱着一台发动机上高速；同样，你也不能拿着一个模型接口去做产品。
图 B-2-2（待出）：幻觉的三层——接模型（以为的终点）、接路由（真正的第二层）、接组织（一直缺的那层）
可以说得再直接一点：模型是买来的，那一层是长出来的。 买来的东西随时能买到更好的；长出来的东西，你不种，它就不会有。
真正的瓶颈不是模型够不够强，是模型之上有没有那一层组织。
尾声¶
第一节说，一个人干 14 件事的解法，是给混乱起名字、分部门。这一节说的是同一件事的另一面：
接了模型不等于有了系统，正如招了人不等于有了公司。
第一版里我有十个角色，却没有一个模型；换真的之后，我有模型了，却没有路由。每一次我都以为少的那个东西在别处——先以为缺模型，再以为缺工具，最后才发现，一直缺的是把零件组织起来的那一层。
这套东西不是自动长出来的。你不去划，它就不存在。
接个模型，只是买了台发动机。造一辆车的事，从发动机之后才开始。