Theo：更聪明的模型为何能帮助更多人

两年前，我很有把握地预测 AI 智能将达到平台期，后续提升会越来越有限。我错了。我们已经从偶尔使用自动补全，走到可以询问代码库、指挥修改，再到给智能体一张 bug 截图，让它调查、测试，甚至完成合并。

接着我又犯了另一个错误：我以为模型也许不需要更聪明了。Fable 5 发布时，我几乎想象不出如何用尽它的能力。Opus 5.5 改变了我的看法，不只是因为它更快、更擅长熟悉的工作，还因为更强的能力能帮助一些我以前没有想到的人。

让我意外的例子是 Halo 和 Call of Duty 的混合作品。看到有人逆向工程并组合老游戏，我意识到更聪明的模型带来的影响可能超出专业软件开发者。其中包括不以编程为生的技术爱好者，最终也包括他们身边的人。

第一个、也是最熟悉的影响是：开发者能更快地构建更好的软件。根据我的经验，智能体让开发者更快推进路线图，也能承担过去不值得投入的工作。要充分利用这些工具，经验仍然重要。

我创建 Lawn，是因为对某个视频审阅服务的速度和价格感到不满。我说自己用了几天搭建了一个开源替代方案，现在团队用它处理视频工作。我估计它复现了原产品早期的大部分功能，同时加入我们想要的功能；这是我的判断，并非独立比较。

Lawn 展示了一个曾经看起来成本过高的产品，如何变得适合小团队尝试。我说有几百人在视频工作流中使用它，还有人 fork 了它。这引出了下一类人：熟悉电脑、技术能力不错，但不是职业程序员的人。

技术爱好者可能理解应用需要解决的问题，却不了解每个框架和工具的限制。他们可能把应用和数据库部署在相距很远的地区，然后疑惑为什么速度很慢。更聪明的模型可以帮助调查系统，填补一些知识空白。

这些用户可以 fork 工具、编写脚本，并调试超出当前理解范围的系统。会更换电脑零件的人，也越来越有机会请智能体帮助修改软件。早期模型可以帮助制作小型个人应用；现在用户还能尝试改造自己依赖的工具。

不过，只在自己机器上运行的定制功能，与其他人能够安全安装的产品之间仍有差距。打包和分发改动很难。我的框架从熟悉领域的辅助开始，依次延伸到修改常用工具、构建自己不完全理解的东西，最后是重建复杂的现有系统。

例如，我有一些 Rust 项目，尽管自己几乎不写这门语言。最深的一层是利用这些工具帮助理解、反编译或重建已有软件。即使未必有人完全理解整个反编译后的游戏代码库，我仍觉得智能体能够掌握足够上下文并在其中工作十分惊人。

随着模型进步，不同人群会在不同时间跨过这些层级。早期编程自动补全帮助了开发者，却几乎不能让非程序员构建软件。后来工具可以编辑文件，技术用户得以定制自己的网站，开发者也能在代码库中做更广泛的修改。

Opus 4.5 出现后，我看到技术爱好者构建更完整的应用，开发者则开始探索游戏、移植和反编译。后来的模型让开发者又前进了一大步。我最初担心，开发者与不编程的技术爱好者之间的差距只会越来越大。

Opus 5.5 改变了我的想法。它没有让我获得完全无法用其他工具组合出来的新工作类别，但一个集中提供、可以通过订阅使用的高能力模型，让技术爱好者更容易尝试雄心勃勃的项目。我看到从未编程、也没用过 Blender 的人尝试移植游戏地图和制作混合作品。

我认为非技术用户目前还没有在这些层级中前进得那么多。但有技术背景的朋友如今可以为别人制作或改造实用软件，也可以把游戏修改分享给不理解其实现方式的人。好处能传递给直接使用模型的人之外的其他人。

我有一个颇具争议的看法：开发者未必像自己想象的那样有创造力。产品经理和设计师提供了编写代码之外的能力。我是在根据经验概括，并非声称每位开发者都缺乏创造力；重点是，技术训练也可能让熟悉的限制看起来不可改变。

懂电脑但不了解既有实现的人，可能用不同方式解决问题。我见过非常复杂的 OBS 设置，包括一个用数万个场景作为动态图层的例子。不熟悉系统之间所谓边界的人，可能会尝试经验丰富的开发者直接否定的组合。

想想这个问题：“为什么不能提交环境变量文件？”如果把它理解为要求暴露秘密，听起来当然很荒唐。我想问的是更广泛的问题：我们现在隔离和共享配置的方式是否是唯一设计，还是只是接受了现有工具的做法？追问惯例的原因，并不等于忽略它的安全目的。

外来者可以提出动摇既有假设的问题。我把这比作不同文化的人以出乎意料的方式改编音乐。更强的工具可能让缺乏正式软件背景的人，尝试有经验的工程师从未想过提出的想法。

有些人评论我的环境文件例子时，立刻假定现有访问模型必须保持不变。我想讨论的是那个模型本身。有创造力的开发者同样能够受益：愿意探索陌生想法、追问限制为何存在，比直接否定惯例更重要。

许多限制是实践成本造成的，并非理论上绝对不可能。移植编译器或逆向工程设备可能需要几个月或几年，还会带来很大风险。如果智能体降低了尝试成本，更多人就能研究过去代价过高、无法测试的想法。

我的职业生涯中尝试过不少大胆项目，包括技术栈、游戏引擎和网络方案。探索更便宜并不保证成功，而是意味着要愿意尝试大胆方案、从失败中学习，并丢弃不值得交付的工作。

开发者习惯于 PR 最终被合并，关闭它可能让人觉得浪费了别人的努力。我甚至曾因为不好意思拒绝而合并代码。当智能体能够快速生成大型改动时，我们需要把实验的成本与是否接受成果的决定区分开。

我推测，开发者和技术爱好者面对被关闭的 PR 时，感受可能不同，因为他们带着不同的期望。但这不是适用于每个人的规律。实际教训是：问清楚工作要达到什么目的、它是否真的有帮助、是否应该丢弃，而不是把失败当成人身挫折。

我用 Rust 重写 TypeScript 的实验，就是一个我最初认为 AI 无法完成的想法。我说它在不到 20 小时内开始工作，能在 WebAssembly 中运行，并在我测试的项目上表现不错。我还引用了自己项目的速度和兼容性数字；这些说法取决于所选测试，并非独立基准。

一位观众认为，能在更高抽象层工作的人会受益最多。我想补充一点：优势属于那些能灵活切换高低层次的人，也属于愿意放下自己偏好的实现、选择更有利于目标的方案的人。

对于我们的移动应用，我个人更喜欢用 SwiftUI 重写，但 React Native 版本受益于智能体的工作速度、空中更新，以及团队带来的性能改进。我可能选择个人技术偏好之外的实现，因为它能更快达成产品目标。

我还在尝试 T3OS：一个面向智能体、而非我自己桌面偏好的定制 Ubuntu 镜像。它启动时没有图形界面，但可以为智能体创建图形环境。我一方面深入操作系统工作，另一方面是为另一类用户——智能体——作选择。

一个例子是选择 Bash，而不是我更喜欢的 Zsh。在我自己的审计中，Claude 在多台机器上的错误有相当一部分涉及 shell 格式以及错误的 ripgrep 命令。我还发现，有些 Linux 发行版更难让智能体管理。这些观察影响了我对环境的选择。

愿意改变工作深度很重要。我并不是直接为自己构建 T3OS，而是在构建一个让智能体替我制作东西的环境。如果开发者把现有偏好和边界当成固定不变，可能会错过那些限制较少的技术用户正在追逐的机会。

我以前相信，模型产出的工作会复杂到只有职业开发者才能利用。现在我认为，过去帮助我们使用早期模型的一些知识，也可能让我们过于谨慎。我不知道下一次变化对非技术用户究竟意味着什么。

能够完成大量编译器工作的模型，也可能帮助某人重新构想自己喜爱的游戏。我没有想到，缺乏传统编程背景的朋友也能做到这些。他们的项目不断改变我对受益人群的看法，我预计可能性还会继续扩大。

我错了，也一直在反思。我希望开发者重新思考模型能力的发展方向，以及谁能够使用它们。多提问题、尝试大胆的想法，保留有效的结果，也愿意丢弃其余部分。