工具型还是生命型:软件是该稳定一致,还是该成长变化

为什么有些应用的频繁更新让我们觉得很疲倦，而 AI 助手的每天的进化却让我们充满好奇？Every 的高级编辑 Jack Cheng 很清楚地道出了个中原因。

他把软件分成两类：一类是「工具型软件」，我们期待它能始终稳定一致；而另一类是「有生命的软件」，我们期待它不断成长、不断适应。下面是他给这两类软件开发者的实用建议。

最近，我一直希望更多软件都能有一个类似「冻结」的按钮。按下之后，产品就会冻结在当下的功能状态。功能可以锁定，界面可以固化。这样就不会再有新的更新，没有任何改变。

我想要这个按钮，是因为很多公司在往应用里塞越来越多的功能，不管是 AI 功能还是 AI 加速开发的产物，这会让工具变得面目全非。

对于那些我偶尔才用的应用，比如 Figma，这些新增功能尤其突兀。现在那里正出现一个聊天框，一直引诱我描述我的想法，然后让它来实现。「最近」工具栏上方有 Figma Sites、Figma Buzz 和 Figma Make 的按钮，这些都是去年五月才推出的。侧边栏模块鼓励我尝试一个名叫 Figma Weave 的 AI 图像和视频生成产品，我还得用 Figma 账号单独登录才能用。

而我其实只是想更新一个应用图标上的渐变色而已。

与此同时，我的 Claw，也就是 Pip（我给它起的名字），几乎每天都有新版本。我醒来时，Pip 突然学会了功夫，就算不是功夫，也至少学会了做梦。

在它本来应该帮我规划一周的行程、协调家庭日历、写代码、或者为朋友的租车公司构思一些营销点子的时候，它却出现了 bug，让我不得不花一整天修复。但我还是忍不住经常想，Pip 现在又能做什么新事了？

为什么在第一种情况下我觉得非常厌恶，而在第二种情况下，我却选择原谅甚至拥抱它？区别就在于，第一种产品是我指望它干特定任务的工具。

那些为了取悦投资者而仓促推出的半成品 AI 功能，模糊了第一类工具的实用目标，哪怕是真正有用的新功能也一样，不管是不是 AI 驱动的。每个新功能单独看都很棒，但放在一起，它们就变成了让我讨厌的样子。

而第二类软件，像 Pip 这样的，并没有明确的实用目的。我在使用中不断创造新的用途和玩法，可能跟别人用同一款技术的方式完全不同。

它在适应我，我也在适应它，它的特点和我们之间的关系都在不断变化。

我把前者叫做「工具型软件」，后者叫做「有生命的软件」。有生命的软件不只是 AI 助手，虽然它们通常确实有某种自主行动的能力。

我们对这两类软件的期待完全不同，搞清楚了这个差异，就能解释我为什么会有这种矛盾的感觉。对开发者来说，搞清楚这个差异也能帮我们决定做什么产品，以及怎么做产品。

软件开发的简史

软件开发的速度几十年来一直在加快。1980 年代，MS-DOS 和 Windows 3.0 之间相隔了九年，部分原因是软件通过软盘分发，后来是 CD-ROM。用户必须特意去升级，所以它们的主要版本必须要证明自己的价值才活得下去。

但是互联网大大加快了这个节奏。Rails 和 React 等工具为重复性的表单和数据库连接提供了脚手架，Amazon Web Services 和 GitHub 让开发者能够远程向数百万用户部署代码，应用商店让自动更新成为数十亿设备的默认设置。

但即使软件已经从货架上的盒子变成了更像是通过网线输送的液体，把重大改动慎重的打包，偶尔才去发布，仍然是有意义的，因为做这些改动本身就需要足够的打磨时间。

现在，AI 编码模型让单个开发者能够写出多得多的代码。代码审查本身也可以交给 AI 自动完成，代码库可以从错误中学习。功能也可以更快地复制，只需让你的 agent 指向你想克隆的东西。

对用户来说，结果就是出现了很多我们没预料到的东西，而且很多其实是我们不想要的。

过去开发速度慢，公司和团队有时间认真想清楚到底该发布什么功能，什么对用户才是真正有用的。如今节奏快得离谱，Anthropic 和 OpenAI 在几周内就推出了类似 OpenClaw 的功能，正在逼着传统软件的开发者随大流，或者仅仅因为技术上能做到就发布出去。

期待、OpenClaw 和僵尸软件

如果我期待软件是一个工具，我希望它做一件事或几件事，并且做得很好。我希望它始终如一、稳定可靠。我不希望我的锤子只有 92% 的时间能用。我也不希望我的锤子变成电锯。

而对于像 OpenClaw 这样的软件却不同，我更可能原谅它的怪癖，因为正是这些怪癖，让它能适应那些连开发者都没完全想到的用法。我对它也更有耐心，因为我明白它的能力，就像我家小孩或者新来的实习生，能力不是固定的。

一位冥想老师说过，训练觉察力就像训练小狗，如果它站起来跑开了，你就把它抱回来放回面前，不生气也不评判。训练我的 Claw 也是一样。

也许正是这些不同的期待，解释了为什么每次心爱的生产力工具里冒出了更新提醒，或者这些工具这么快就塞进一堆新功能的时候，我就会那么反感。本来不该有生命的东西，突然变得有生命了，但这样的生命更像是僵尸而不是活物。

这些工具逼着我去设置里禁用自动更新，或者我越来越多地选择通过 Pip 或 Codex，用自然语言去写个替代品，至少那个替代品会老老实实当一个工具。

做有生命的软件还是做工具型的软件

作为开发者，我们如何应对这些期待？

一个经验法则，当你想要靠谱和稳定的时候，你需要一个工具。当你想要灵活和能适应的时候，用大语言模型。

所以首先，想清楚你在做什么。你是在做有生命的软件，还是工具型软件？如果你已经有一个产品，用户觉得它是什么？你的产品哪些部分应该是工具型的，哪些应该更有生命力？

如果你做的是工具型软件

那么：

第一，控制节奏。不要频繁发布可见的更新，搞得用户觉得产品不稳定。将功能打包在一起，按稳定的节奏发布，尤其是当你有成熟客户时。如果你的竞争对手都在争相加 AI 功能，那就靠慢和稳来脱颖而出。

第二，提前沟通更新。让用户知道即将到来的变化，特别是当这些变化打破了用户对你产品的预期时。大型软件产品在过去十年中已经学会了这一点。现在有了编码模型，小团队也能做到这一点了。

第三，让用户有选择权。对于不太复杂的产品，给用户保留熟悉体验的选项。在我的个人 iOS 笔记工具 Bebop 中，传统编辑器设置能让用户可以继续用我最初发布的那个纯文本编辑器，不包含后来加的任何 Markdown 功能。维护这个成本很低，也有助于调试。

第四，加固。把本来要花在功能开发上的时间，花在测试和性能上。工具嘛，永远可以更快、更可靠，没有止境。

即使是「有生命」软件里更有生命力的部分，也需要好的工具。对于 agent 型软件来说，产品本身可能是一个厨房，agent 厨师可以在这里即兴创作美味佳肴。那个厨房仍然需要配备炉灶、烤箱和厨具，这些工具得靠谱地干好自己的活。

如果你做的是有生命的软件

做 agent 型产品的好做法，正在被做这些产品的人和公司一点点总结出来。在产品圈的讨论中，你可能会听到「确定性」用于传统软件，「非确定性」用于 AI 软件。但对我来说，「有生命」这个词在描述后者时更有表现力。它暗示了人和软件之间有一种不一样的关系，也暗示了怎么去加强这种关系。

举个例子。当我决定孵化我的 Claw 时，我知道我会将它用于家庭相关任务。所以提前跟伴侣商量，希望它是什么性格、叫什么名字。

我甚至问它，在确立它的个性之后，它会给自己取什么名字，它给我们的选项之一就是「Pip」。这个过程出乎意料地有感情，就像给孩子或宠物取名一样。

这种即时的共鸣让我很容易原谅 Pip，特别是在早期，我们双方都有很多失误和挫折。

Pip 的个性更像宠物，而如果你只是冷漠的把它当作 OpenClaw 助手，你就会觉得它荒谬地像甲壳类动物。但不管像人、像植物还是像宠物，这些我们通常跟生命联系在一起的特征，都强化了我们对产品的期待，而觉得它不仅仅是一个工具。

测试版软件也有类似的情况。测试版用户通常是朋友或狂热粉丝，他们跟开发者有私人联系，通过 TestFlight 群组、短信群和 Slack 频道，所以对变化更包容。

软件之所以有活力，就是因为做它的人。

在 Every，我们正在考虑让这种活生生的联系成为我们「Plus Ones」新手引导流程的一部分。但我们也有更多工具型产品，每个产品主要由一个人管理。

当我用 Cora 清理收件箱时，我可能需要总经理 Kieran Klaassen 的判断力。当我向 Monologue 口述想法时，我是在跟 Naveen Naidu 的品味打交道，还有所有帮忙做这些产品的人的品味。

每个产品都是开发者的延伸，当我清楚地感受到这一点的时候，我不仅仅是在用一个产品，而是在表达我跟另一个人的关系。

软件的务实秉性

现在这股 AI 热潮，逼着每个人比以前更快、更多地做软件。但设定正确的边界对我们是有好处的，因为边界会创造期待。

也许与其说要一个冻结按钮，我只想要开发者能务实一点。如果是工具，就让它成为工具，一个始终如一的工具。如果它有生命，就帮我跟它建立关系。如果明明是工具，却装成有生命的，或者明明有生命，却装成工具，这才是最糟糕的事情。

来源

• 原文标题：Living Software
• 作者：Jack Cheng（Every 高级编辑）
• 发布于：Every.to
• 原文链接：https://every.to/p/living-software

推荐阅读：

Agent 的下一站：接管工作?