AI 杠杆与面包悖论：原型越便宜，可信交付越值钱

最近连续看到几类 AI 内容，表面上在讲不同的事：

Sakana AI 发布了 Sakana Fugu，把多代理系统包装成一个 OpenAI 兼容的模型接口。
Dan Koe 的爆款长文在讲如何重启人生、摆脱旧工作方式，中文圈又把它翻译成"如何在 AI 大规模替代中活下来"。
另一个中文帖子讲一个 19 岁学生用 Claude 写了 AI 测速系统，一个月卖给香港政府 55 万美元；这条我没有找到可独立验证的来源。
Joan Westenberg 写了一篇《The Bread Paradox》，用"人人都会烤面包，面包店却开了五千年"回答另一个方向的焦虑：AI 让写软件变得便宜之后，SaaS 会不会死。

把它们放在一起看，真正有意思的不是哪条推文更火，也不是哪个故事更刺激，而是它们共同指向了一个变化：AI 杠杆正在从"会用一个模型"转向"会设计一个系统"。而 Westenberg 的面包悖论恰好补上了这个变化的经济学底座——买方付钱买的从来不是"做出来的能力"，是"不用自己操心的服务"。

但"设计系统"这句话也容易被误读。系统不是把几个 API 串起来，也不是写一段提示词让模型自动赚钱。真正有用的系统，必须能验证结果、能交付给别人、能承担风险，还要经得起维护。

这也是我对这些材料的基本判断：Fugu 展示的是基础设施层的真实方向；Dan Koe 和 Smith 的内容展示的是个体如何重新组织自己的工作；那个 55 万美元的测速故事，如果没有更多证据支撑，更适合被当作一个把真实趋势压缩成暴富神话的流量样本。

先把边界说清楚：这篇不是在给任何公司、工具或推文背书。Fugu 的产品方向可以讨论，但它的效果仍要回到具体任务验证。X 上的个人叙事可以提供观察材料，但不能直接当事实依据。真正值得留下的，不是某个故事有没有让人兴奋，而是它逼我们重新区分三件事：原型能力、可验证系统、可信交付。

Fugu 真正卖的不是模型，而是编排

Sakana Fugu 的标题很直接：Multi-Agent System as a Model。

这句话比页面上的 benchmark 更重要。它不是单纯说"我们的模型分数更高"，而是说：你不用直接管理一堆模型、agent、路由和提示词，Fugu 把这些复杂性压到一个模型接口后面。对开发者来说，它看起来像一个 OpenAI-compatible API；对 Sakana 来说，里面实际是一个会选择、切换、协调专家模型的系统。

这就是 AI 产品形态正在变化的地方。

过去我们讨论 AI，常常问：

用 GPT 还是 Claude？
哪个模型写代码更好？
这个任务该怎么写 prompt？

Fugu 想把问题改成：

你要什么结果？
这个任务该由哪组模型协同完成？
系统如何在质量、延迟、成本和合规之间做取舍？

它把"模型选择权"变成了一个被产品隐藏起来的能力。用户买的是结果，不是底层路由。

这不是小变化。很多软件产品最后都会走到这一步：底层选择越来越复杂，用户界面反而越来越简单。云服务隐藏服务器，支付网关隐藏银行通道，搜索引擎隐藏网页排序。现在，模型编排也开始被隐藏到一个 API 后面。对使用者来说，这会降低接入门槛；对采购者和交付者来说，验证责任不会因此消失。

面包悖论：一门"早该死掉"却活了五千年的生意

Fugu 这种"把复杂性藏到接口后面"的产品逻辑，Westenberg 用一个更古老的例子讲透了。

他家里有一台面包机，闲置。面粉和酵母不贵，做法五千年前就是公开知识，机器会自动揉面和烘烤。但他每周仍然去店里买面包。因为"会做"和"值得自己做"是两回事：计划、采购、维护机器、接受更短的保质期，这些心智成本加起来，超过了在超市拿起一条面包的成本。经济学里这叫 make-or-buy 决策，而对大多数人来说，buy 几乎总是赢。

历史站在买方这边：古埃及尼罗河边就有商业面包坊，罗马有面包师行会和机械揉面，中世纪伦敦有面包公会管品控——每一代人都完整掌握做面包的知识，每一代人都继续买面包。到今天，美国人一天消耗约一千万条量产面包，而面包机在无数厨房积灰。

Westenberg 的点睛之笔是：面包店卖的从来不是面粉和配方，而是便利、一致性、责任兜底，以及出问题时可以怪罪的人。

回头看 Fugu，它做的就是这件事。模型、路由、提示词、协调策略——这些"面粉和配方"全部藏进后厨，柜台上只摆一个 API。你买的不是配方使用权，是"不用自己操心配方"。所以"AI 让每个人都能自己搭多代理系统"并不构成对 Fugu 的威胁，正如"每个人都会烤面包"从来没有威胁过面包店。真正的竞争发生在另一个维度：谁的面包更稳定、出了问题谁负责。

Benchmark 可以看，但不能全信

Fugu 页面给出的分数很强。它列了 SWE Bench Pro、TerminalBench、LiveCodeBench、Humanity's Last Exam、GPQA-D、SciCode、长上下文推理等任务，Fugu Ultra 在很多项目上排第一或接近第一。

这些结果值得看，但不应该照单全收。

原因有三个。

第一，页面自己也说明，部分基线使用的是模型提供方报告的分数。不同厂商的评测条件、工具链、scaffolding 和采样设置很难完全一致。

第二，Fugu 的底层路由不公开。FAQ 里明确说，具体用了哪些模型、如何协调，是专有设计，不对用户暴露。这在产品上可以理解，但也意味着外部用户很难复现同样的判断链。

第三，生产环境里决定能不能用的，不只是分数。还包括响应时间、长任务稳定性、成本可预测性、失败时如何降级、数据是否能满足合规要求。

所以更稳的读法是：Fugu 的 benchmark 证明"多模型编排可能是有效方向"，但还不能证明"它在每个真实业务里都优于你直接用单个 frontier model"。

这是一个可信的趋势信号，不是一张无需验证的采购单。

AI 暴富故事省略了最难的部分

再看那个"19 岁学生用 Claude 写测速系统，卖给香港政府 55 万美元"的帖子。这里我只把它当作传播样本，不把它当作已经确认的商业案例。

它的叙事非常标准：年轻人、低成本、短周期、大客户、政府采购、现场演示、立即付款。几乎每个元素都在服务同一个情绪：AI 让普通人突然拥有了过去只有公司才有的生产力。

这个情绪不完全是假的。Claude 这样的模型确实能让一个人更快做出原型。一个懂一点工程、产品和沟通的人，也确实可以用 AI 做出过去需要小团队才能做出的东西。

但问题在于，这个故事把真正难的部分都省略了。

一个交通执法系统不只是"摄像头识别车速和车牌"。它还涉及：

速度测量的准确性和校准责任。
视频证据能否作为执法依据。
车主身份数据从哪里来，谁有权限查。
罚单自动发送是否符合行政流程。
误判、申诉、审计和日志留存怎么处理。
政府采购是否能被一次 U 盘演示绕过。
55 万美元付款为什么会以现场支票形式出现。

Claude 写原型不是最难的。最难的是让一个系统进入真实世界，并被一个有法律责任的组织采用、验收和长期维护。

用面包悖论的语言说：这个故事声称有人靠"会烤面包"卖出了面包店的价钱。但采购方付钱买的从来不是烤面包的能力——是凌晨两点系统宕机时有人爬起来修，是审计来了有日志可查，是误判罚单时有一个能被问责的主体。把这些责任全部接过来，才是那 55 万美元真正对应的商品。原型只是面包，采购买的是面包店。

所以我不会把这类故事当成路线图。它更适合作为一个反面提醒：AI 暴富叙事之所以有传播力，是因为它抓住了一部分真实趋势，但把来源验证、需求验证、可信交付、合规、销售和维护全部折叠成一句"用了 Claude"。

这对读者很危险。因为它让人误以为提示词就是商业模式，原型就是产品，演示就是成交。

Dan Koe 式内容真正有用的部分

Dan Koe 的内容和 Smith 的中文转译，另一端讲的是个人如何面对 AI 替代。

这类内容常常会混合自我管理、创造者经济、技能重组和反打工叙事。它的问题是容易鸡血，优点是抓住了一个现实：如果 AI 让普通执行劳动越来越便宜，个人就必须从"完成任务的人"升级成"设计系统的人"。

这里的关键不是"逃离工资奴役"这种标题，而是工作方式的转变：

从等别人分配任务，变成自己定义问题。
从只做交付物，变成设计可复用流程。
从单点技能，变成组合技能。
从依赖简历证明能力，变成用公开作品和真实案例证明能力。

这和 Fugu 的方向其实是同构的。

Fugu 在基础设施层做的事，是把多个模型协调成一个更强的系统。个人在职业层要做的事，是把写作、代码、研究、销售、交付、复盘协调成一个能持续产出的系统。

区别只是尺度不同。一个是公司产品，一个是个人工作流。

哪些软件会死，哪些会活

面包悖论还回答了一个更实际的问题：AI 降低软件生产成本之后，什么会被淘汰。

Westenberg 的判断是，真正危险的是那些单一功能、AI 一句话就能复刻的薄工具——PDF 转换器、会议纪要生成器这一类。它们的本质是"把一个功能按一家企业来定价"，当功能本身的边际成本趋近于零，这个定价就守不住了。

但 Notion、Jira 这类成熟平台卖的早就不只是代码：集成生态、合规认证、稳定性记录、组织内积累的使用惯性，以及最重要的——出了问题有人负责。他还引用了一个值得记住的数据：AI 生成的代码比人写的代码携带约 1.7 倍的重大缺陷。自建不仅要承担生成成本，还要承担此后每一天的维护、安全和知识流失风险。当初写这套内部工具的人离职了，谁接？

这条分界线对个人同样成立。如果你提供的价值是"我会用 AI 做出某个功能"，你就站在薄工具那一侧，和零成本竞争；如果你提供的是"这个环节交给我，出问题找我"，你就站在面包店那一侧——AI 越强，你采购原材料越便宜，生意反而越好做。

真正的 AI 杠杆在哪里

如果把这几个材料压缩成一句话，我会这样说：

真正的 AI 杠杆，不在"我用了哪个模型"，而在"我能不能把模型能力接进一个可信系统"。

这个系统至少包含五层。

第一层是具体场景。不要从"我要用 AI 赚钱"开始，而是从一个真实、窄、可验证的问题开始。比如职位解析、代码审查、客户资料整理、投研资料初筛、文档迁移、内部知识库问答。

第二层是可验证步骤。AI 可以负责提取、生成、比较和总结，但每一步最好有验收标准。结果对不对，不能只靠模型自己说。

第三层是人工责任。AI 产出原型、草稿、候选方案，人负责最终判断。越接近法律、财务、医疗、招聘、执法、公共服务，越不能把责任推给模型。

第四层是交付与信任。别人为什么敢用你的系统？数据怎么处理？失败怎么办？谁维护？日志在哪里？权限怎么管？这些问题不性感，但它们决定了原型能不能变成产品。

第五层是复用。一次性的 prompt 没有太大护城河。可复用的数据结构、检查清单、工作流、评估集、文档和交付模板，才会让你的能力随着时间累积。

这也是为什么我对"一个月卖给政府 55 万美元"这种故事保持怀疑。不是因为 AI 做不到原型，而是因为真实世界不会只为原型付款。真实世界为风险被处理、责任被承担、流程被打通、结果可复现而付款。

个人应该怎么做

如果你已经在用 AI，但还停留在工具层，我觉得下一步不是继续收藏更多 prompt，而是做五件事。

选一个具体场景

不要做泛用助手。选一个你熟悉、重复、痛感明确的场景。越具体，越容易验证 AI 是否真的帮上忙。

把工作拆成可检查的步骤

把"让 AI 帮我完成任务"拆成输入、处理、输出、验收。每一步都问：错了怎么发现？谁来确认？有没有样例？

用 AI 做原型，但自己负责验收

AI 可以让你更快看到第一版，但验收不能交给它。尤其是要写进简历、发给客户、提交给老板、影响用户决策的内容，必须人工审。

补齐分发、销售和合规

很多人卡住不是因为不会做 demo，而是不会找到真实需求，不会解释价值，不会处理数据和权限，不会让别人相信它可以长期运行。

沉淀成可复用系统

把有效的步骤写成文档、模板、脚本、检查清单和小工具。真正的效率来自复利，不来自每次重新和模型聊天。

这五件事合起来，其实就是从"买了面包机的人"变成"开面包店的人"。面包机人人都买得起——prompt 和工具从来不是护城河。面包店的护城河是别人愿意长期把这件事外包给你：你稳定、可预期、出了问题认账。

结论

Fugu 这类产品说明，AI 能力正在向系统编排演化。X 上的暴富故事说明，大众对这种能力的想象已经开始失真。Dan Koe 这类内容说明，个人也在寻找新的工作组织方式。而面包悖论说明，这一切底下的经济规律其实五千年没变过：人们永远愿意付钱把复杂性外包给可信的人。

这几件事放在一起，给我的提醒很明确：

不要把 AI 当作一台许愿机。也不要把 AI 只当作一个聊天框。

更准确的看法是：AI 正在降低原型成本，但提高了判断、验证、交付和信任的相对价值。越多人能做出 demo，越稀缺的就不是 demo，而是把 demo 变成别人敢于长期依赖的系统的能力。会烤面包的人越多，好面包店反而越值钱。

这才是 AI 杠杆的真相。