浮力 / Buoyancy

Every few months a new AI model comes out, and each time, the same event has opposite effects on different products. Some get better the moment the model ships — no one touches a line of code. Others get worse. Their prompt chains misfire, their workarounds start working around problems that no longer exist, and features that took months to build turn into things the model simply does.

每隔几个月就会出现一个新的AI模型，而每次同样的事件对不同的产品都会产生截然相反的影响。有些产品在模型发布后立即得到改进——无需任何人修改一行代码。而另一些产品则变得更糟。它们的提示链出现故障，原本的变通方案开始针对已经不存在的问题，而那些耗时数月开发的功能，现在却变成了模型自动完成的事情。

The property that separates them needs a name. I call it buoyancy. Buoyant software rises with model improvements the way a boat rises with the tide. It gets better every time the models do, without even trying.

区分它们的这种特性需要一个名字。我称之为“浮力”。具有浮力的软件会随着模型的改进而提升，就像船随着潮水上升一样。每次模型改进，它都会变得更好，甚至无需刻意改进。

Why would one event help some products and hurt others? Look at where the model sits. An AI product is a model plus everything built around it, and everything around the model is there for one of two reasons: to connect it to the problem — context in, results out, users to the door — or to compensate for something it can't do yet. Call the first kind plumbing and the second scaffolding.

为什么某个事件会对某些产品有利而对另一些产品不利？关键在于模型所处的位置。人工智能产品是由模型及其周围构建的一切组成，而模型周围的一切存在的目的不外乎以下两点：一是将模型与问题连接起来——输入上下文，输出结果，引导用户——二是弥补模型目前尚不具备的功能。我们可以把前者称为管道​​，后者称为脚手架。

When the model improves, plumbing appreciates: the same pipes now carry something smarter. Scaffolding depreciates, because it was a workaround for a weakness, and the weakness is what just improved. Often it doesn't stop at zero: prompts tuned to one model's quirks misfire on the next, and you end up paying engineers to remove what you paid them to build. So buoyancy is mostly a question of proportions. A product that's mostly plumbing floats. One that's mostly scaffolding is anchored to the model it was built for.

当模型改进时，管道系统也会随之升级：同样的管道现在承载着更智能的东西。而脚手架系统则会贬值，因为它原本是为了弥补缺陷而采取的权宜之计，而缺陷本身却得到了改进。通常情况下，这种变化并不会止步于零：针对某个模型特性而设计的提示信息在下一个模型上可能失效，最终你不得不花钱请工程师来移除你当初付费让他们建造的东西。因此，浮力主要取决于比例。一个主要依靠管道系统的产品能够漂浮。而一个主要依靠脚手架的产品则会被牢牢地固定在它最初所依附的模型上。

The strange thing is that non-buoyant products are usually built by good engineers — partly because they're good. Ordinary software teaches you to handle the edge cases, add the guardrails, harden the system. And ordinarily that's right, because the platform holds still. A CPU never wakes up one morning understanding your problem. A model does; that's roughly what a release is. When the platform improves along the very axis your hardening covers, the instinct to harden becomes an instinct to build what the tide will strand.

奇怪的是，那些难以适应市场变化的产品通常都是由优秀的工程师打造的——部分原因在于他们确实优秀。普通的软件开发会教会你如何处理极端情况，添加防护措施，强化系统。通常情况下，这样做是正确的，因为平台本身不会发生根本性的变化。CPU 不会突然有一天早上醒来就理解了你的问题。模型可以；这大致就是版本发布的意义所在。当平台沿着你强化措施所涵盖的方向发展时，强化系统的本能就会转变为构建那些注定会被市场淘汰的产品。

The mistake, in one sentence: every workaround for a model's weakness is a short position on model progress. So far that's been one of the great losing trades. But people mostly make it unknowingly. Every architecture contains a forecast about models, and the default forecast is stasis: next year's models will be like today's. Under that assumption, elaborate scaffolding is simply good engineering. So non-buoyancy usually isn't an engineering error. It's a forecasting error smuggled inside an engineering decision.

一言以蔽之：任何试图弥补模型缺陷的变通方案，实际上都是对模型发展前景的空头押注。迄今为止，这已成为最惨重的亏损交易之一。但人们大多在不知不觉中犯下这种错误。每一种架构都包含着对模型的预测，而默认的预测是停滞不前：明年的模型将与今天的模型并无二致。在这种假设下，精心设计的框架就等同于良好的工程设计。因此，模型缺乏流动性通常并非工程设计上的失误，而是隐藏在工程决策中的预测误差。

You can see the sediment in any long-lived prompt. Instructions accumulate like scar tissue — each added because some model once misbehaved, none ever removed — until no one knows which parts still do anything. The file is overfit to models that no longer exist.

任何长期存在的提示符中都可见到这种沉积痕迹。指令像疤痕组织一样不断累积——每一条指令的添加都源于某个模型曾经出现故障，却从未被移除——直到无人知晓哪些部分仍然有效。该文件过度拟合了那些早已不复存在的模型。

Sometimes, of course, the model can't do the thing yet, and the choice is scaffold or don't ship. Then you scaffold. The mistake isn't building it; it's believing in it. Scaffolding is a loan against the current model's weaknesses, and a payment comes due at every release. Buoyant teams treat it as disposable: the day a new model ships, they delete code, happily. Non-buoyant teams defend it: it was the hard part to build, so it feels like the valuable part. That's backwards. Whatever was hard because the model was weak is what a stronger model erases. In six months it will feel expensive and unnecessary.

当然，有时候模型还无法完成任务，这时的选择要么是搭建脚手架，要么就别发布了。如果是这样，那就搭建脚手架。错误不在于搭建脚手架，而在于对它深信不疑。脚手架相当于用现有模型的缺陷做抵押借款，每次发布都要偿还。充满活力的团队会把它当作一次性用品：新模型发布当天，他们会毫不犹豫地删除代码。而缺乏活力的团队则会维护它：因为搭建脚手架是最难的部分，所以它感觉最有价值。这是本末倒置。模型缺陷导致的困难，正是更强大的模型会消除的。六个月后，这些脚手架就会显得既昂贵又多余。

We've been through a rising tide before. For fifty years the winning move in software was to waste machine cycles to save programmer time. High-level languages were a long position on Moore's Law; hand-tuned assembly won benchmarks and lost decades^[1]. Models are the new thing that doubles. Machines used to get faster. Now they get smarter.

我们以前也经历过类似的浪潮。过去五十年，软件领域的制胜之道是浪费机器周期来节省程序员的时间。高级语言是摩尔定律的长期受益者；手工优化的汇编语言虽然赢得了基准测试，却也因此损失了数十年[1]。如今，模型才是真正成倍增长的事物。过去，机器速度越来越快。现在，它们变得更智能了。

The reason to want a word for this is to use it as a question. "Is it buoyant?" is a different question from "is it AI?" The second is about ingredients. The first is about the derivative: as models improve, does the thing get more valuable or less? Two startups can have identical demos and opposite signs.

之所以需要一个词来描述这种情况，是为了把它当作一个问题来问。“它有吸引力吗？”和“它是人工智能吗？”是不同的问题。后者关注的是构成要素，而前者关注的是衍生品：随着模型的改进，事物的价值是会增加还是降低？两家初创公司可能拥有完全相同的演示，但结果却截然相反。

And the question scales down. Suppose you need a classifier. Boosted trees get you 94%; a prompted model gets you 91%. But you can't teach the trees anything from one bad example, and next year's models do nothing for them. The prompted judge you improve by editing a sentence, and it inherits every future model for free. Ask which is more accurate and you choose the trees. Ask which is buoyant and you choose the judge.

而且问题会缩小。假设你需要一个分类器。提升树的准确率是 94%；提示模型的准确率是 91%。但你无法通过一个糟糕的例子教会树任何东西，而且明年的模型对它们也毫无帮助。提示模型可以通过编辑句子来改进，并且它还能免费继承未来所有模型。问哪个更准确，你会选择树。问哪个更稳定，你会选择提示模型。

By now an alert reader has an objection. If buoyancy means keeping as little as possible between the model and the problem, doesn't maximal buoyancy mean being a thin wrapper? And thin wrappers are what platform owners absorb. There's even a word for it: in 2002 Apple shipped Sherlock 3, which copied a beloved third-party tool called Watson so thoroughly that "Sherlocked" became the verb for being absorbed by the platform. So it seems the tide that lifts you can also dissolve you.

这时，一位敏锐的读者可能会提出异议。如果浮力意味着尽可能减少模型与问题之间的隔阂，那么最大程度的浮力岂不意味着成为一个“薄包装”？而平台所有者吸收的正是这种“薄包装”。甚至还有一个专门的词来形容这种情况：2002年，苹果公司发布了Sherlock 3，它完全复制了一款名为Watson的备受喜爱的第三方工具，以至于“Sherlocked”成了被平台吸收的动词。所以看来，既能让你飞黄腾达的浪潮，也能将你吞噬。

This is where it pays to take the metaphor seriously. What rises with the tide is boats, not water. Pour a bucket of water into the ocean and it doesn't ride the tide; it becomes the tide. To float you need a hull — something that displaces water instead of merging with it. If your product is nothing but intelligence applied to a generic task, you're made of the same stuff as the model, and a better model doesn't lift you. It includes you.

这就是为什么认真对待这个比喻很重要的原因。随着潮水上涨的是船，而不是水。把一桶水倒进海里，它不会随波逐流；它会变成潮水的一部分。要想漂浮，你需要船体——一种能够排开水而不是与水融合的东西。如果你的产品仅仅是将智能应用于一项通用任务，那么你和模型是由相同的物质构成的，而更好的模型并不会提升你，而是会将你纳入其中。

So the definition needs a second clause. Buoyant doesn't mean thin. It means having a hull — something models don't acquire by getting smarter: your users' accumulated context, your data, your distribution — and connecting it to the model as directly as possible. The hull makes you distinct from the tide. The directness lets the tide lift you.

所以这个定义需要第二个限定词。“浮力”并非指“薄弱”，而是指拥有一个“船体”——这是模型无法通过提升智能而获得的：用户积累的上下文信息、数据和分布情况——并尽可能直接地将其与模型连接起来。这个“船体”使你与潮汐区分开来。而这种直接性则让潮汐能够托起你。

Which means there are two ways to sink. You can be anchored: so much scaffolding that each release arrives as a renovation project. Or dissolved: so little of your own that the next release includes your product as a feature. Buoyancy is the ridge between two ways of drowning.

这意味着有两种沉沦的方式。一种是被束缚：脚手架搭建得太多，以至于每次发布都像是一次翻新工程。另一种是消亡：自身实力薄弱，以至于下一次发布时，你的产品会被当作一项功能来添加。浮力是介于这两种沉沦方式之间的屏障。

The question works on people too. If your work is compensating for what models can't do yet — checking their output, being the human in the loop — you are the scaffolding, and the tide is against you. If it's knowing what's worth doing — the context, the taste, the ownership of a problem rather than a task — you're a hull. The most buoyant people greet each release with a backlog: things they already wanted to do, waiting for the intelligence to catch up. That's what "be buoyant" means, decompressed.

这个问题对人也适用。如果你的工作是弥补模型目前无法完成的任务——比如检查模型的输出，或者作为人参与其中——那么你就是脚手架，而你注定要失败。如果你的工作是判断什么值得做——比如理解问题的背景、把握其意义、以及对问题本身而非仅仅对任务负责——那么你就是船体。那些心态最积极的人，每次发布新版本时都会带着待办事项清单：那些他们早就想做的事情，只是在等待模型的智能水平跟上。这就是“保持积极心态”的真正含义，一种放松的理解。

There's a diagnostic that requires no analysis. The next release is at most a few months away. When it comes, notice your first reaction. If it's greed — you can't wait to pour the new model through what you've built — you're buoyant. If it's dread — a migration, a re-tune, a quiet question about whether you're still needed — you're not. You can't fake the reaction; that's what makes it trustworthy. But you can change what causes it. The tide is rising either way^[2]. The only thing you choose is what it does to you.

有一种诊断方法无需任何分析。下一个版本最多几个月后就会发布。当它到来时，注意你的第一反应。如果是贪婪——你迫不及待地想把新模型应用到你已构建的系统中——你感到振奋。如果是恐惧——迁移、重新调整、默默地质疑自己是否还有存在的必要——你不再需要它了。你无法伪装这种反应；正因如此，它才值得信赖。但你可以改变引发这种反应的原因。无论如何，潮流都在上涨[2]。你唯一能选择的，是它对你的影响。

August 17, 2026: This was written by Claude Fable via a custom argument-structuring pipeline with a tweet I wrote as the kernel, and PG's essays as voice input. I was so surprised at the output I'm publishing it as-is.

2026年8月17日：这是克劳德·费布尔（Claude Fable）通过一个自定义的论证结构管道写成的，其中我写的一条推文作为内核，PG的文章作为语音输入。我对输出结果感到非常惊讶，所以决定原样发布。