AI 杠杆的真相：模型编排、个人系统和暴富叙事之间的距离

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

Sakana AI 发布了 Sakana Fugu，把多代理系统包装成一个 OpenAI 兼容的模型接口。
Dan Koe 的爆款长文在讲如何重启人生、摆脱旧工作方式，中文圈又把它翻译成"如何在 AI 大规模替代中活下来"。
另一个中文帖子讲一个 19 岁学生用 Claude 写了 AI 测速系统，一个月卖给香港政府 55 万美元；这条我没有找到可独立验证的来源。

把它们放在一起看，真正有意思的不是哪条推文更火，也不是哪个故事更刺激，而是它们共同指向了一个变化：AI 杠杆正在从"会用一个模型"转向"会设计一个系统"。

但这句话也容易被误读。系统不是把几个 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 后面。对使用者来说，这会降低接入门槛；对采购者和交付者来说，验证责任不会因此消失。

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

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

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

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

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

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

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

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

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

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

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

真正的 AI 杠杆在哪里

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

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

这个系统至少包含五层。

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

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

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

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

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

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

个人应该怎么做

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

选一个具体场景

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

把工作拆成可检查的步骤

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

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

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

补齐分发、销售和合规

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

沉淀成可复用系统

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

结论

Fugu 这类产品说明，AI 能力正在向系统编排演化。X 上的暴富故事说明，大众对这种能力的想象已经开始失真。Dan Koe 这类内容说明，个人也在寻找新的工作组织方式。

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

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

更准确的看法是：AI 正在降低原型成本，但提高了判断、验证、交付和信任的相对价值。越多人能做出 demo，越稀缺的就不是 demo，而是把 demo 变成可靠系统的能力。

这才是 AI 杠杆的真相。