序言：当 AI 代理开始直接参与软件构建时，软件团队最需要重估的不是某个工具，而是“我们一直以来是怎样组织开发流程、评估成本和判断速度”的底层假设。 原文出处：Software Is Liquid | Jamie Thingelstad（作者：Jamie Thingelstad，发布日期：2026-04-20）

---

这篇文章最初来自我在公司内部面对一群技术领导者的一次分享。我将其中与公司特定背景相关的内容删去后整理成文，因为核心观点并不只适用于某一家组织。

我想抛出一些我对行业变化的看法。接下来我要讲的，是我二十多年技术职业生涯里见过的变化最快、动态性最强的一次变革之一。我相信，当下正在发生的一些变化，会从根本上重定义我们如何实践这门手艺。

我们所处的位置

先给当下做个定位。代理已经成为现实。我亲眼看到，一个代理从零开始 - 没有代码、没有设计 - 在大约五周内就做出了可运行的 alpha 版本，并且已有真实用户在上面做真实决策。一年前，这还只是一个想法。现在，生产环境里的代理已经在运行。

代理化（Agentification）是我们行业正在经历的下一个重要里程碑。

我年纪已经足够大，可以这样说：有“Web 之前”和“Web 之后”；有“移动之前”和“移动之后”；有“云之前”和“云之后”。而现在，又有了“AI 与代理之前”和“AI 与代理之后”。

我认为，这次转变将会比前面这些都更具颠覆性。

我们必须承认当前的一个悖论：我们正在于最佳实践尚未存在之前就开始构建它们。

我们以前也经历过。经历过云转型的人会记得：当时我们走在行业前面，摸索这种短暂性算力到底该如何工作、如何真正跑起来。当时行业并没有沉淀出稳定模式。今天我们也处在同样的位置。代理化该如何发生，还没有清晰范式。我们将一边构建这些模式，一边与行业共同学习。

这没问题。你只需要清楚自己所处的位置。走在曲线前沿并不坏，但你必须始终知道自己正处于前沿，因为那是高风险区域。你不应该离主流太远。

来点哲学：软件正在变成液体

我想聊点更底层的。

过去两个月，我把自己投入到了一个长期来看可能并不健康的 AI 使用强度里。说实话，如果你去问我家人，他们会同意这个判断。但我这么做，是为了真正吃透那些我认为会改变我们工作方式的核心概念。

把这件事放回历史转型里看。当我们进入移动时代时，大家都知道：要领导移动转型，你必须先成为移动用户。一个从没用过手机的人，能做出优秀移动应用吗？显然不能。所以，要引领 AI 代理化，我们也必须离它非常近。我一直在强迫自己这么做，因为随着经验增长，重构自己的思维方式会越来越难。

我最近一直在想一件事：做错的成本到底是什么？ 我们又该怎样把这个变量折叠进我们的创造过程？

先退一步，想想我们一直怎样做软件。假设我们在构建软件。我们会投入时间做 discovery，会写 stories，会让设计师去画线框，会做很多事情，以确保真正开始开发时，我们在做的是正确的事。

为什么？因为构建软件这件事一直极其昂贵。过去二十年，我职业生涯的主轴，就是如何更有效地把想法变成可工作的软件，以及如何确保我们不会做错 - 确保产出的是有价值的能力。全世界技术团队都在做这件事。做得好的团队，只是比做得差的团队更擅长这套方法。

我后来这样理解它：软件在历史上是一种固体。 你像在花岗岩上凿刻东西。我们带着想法坐下来，过程艰难、工作量大、挑战重重，然后一点点把它从花岗岩里凿出来。

但我认为这正在改变。最早我在网上听到这个说法时并不认同，我当时想这不合理。但越想越觉得准确。那个判断是：软件正在变成液体。

过去二十年，我们一直运行在“软件是难以塑形固体”的世界里。随着 AI 与代理式开发（自动化编程）的出现，软件开始变得可塑。如果你已经用代理做过开发，你应该体验过这种感觉：我重构这段代码的速度，甚至快过我当初为了避免做错决策而做那些防护工作的速度。

当你所从事工作的经济结构发生这种量级的变化时，你必须质疑一切。

建立在“软件昂贵”之上的每种范式都需要重新审视

再往前看。我们大多数人职业早期都经历过敏捷流程。在那之前，大家都做瀑布。为什么？难道他们不够聪明吗？不是 - 他们是在另一组前提上工作。你在 C 代码里犯一个错误，回滚和修复都非常困难。你的领域模型出错并体现在 C 代码里，可能要花几个月才能重构回来。

后来我们有了 Python、PHP、解释型环境、持续集成。范式变了。突然之间，如果我错了怎么办？没关系，我重构。重构 Python 的成本就是比重构 C 低，这是事实。

于是敏捷出现了。我们可以换一种方式，可以变得更有响应性。

云是这段故事的第二部分。云告诉我们，硬件层面也可以这样做 - 我们不用再过度纠结服务器到底放在哪个机房。以前如果服务器放错数据中心，纠正成本很高；在云里，这可能只是几条命令。

我们现在又站在了同样的位置。

AI 正在以一种方式改变软件创造成本，这种改变足以让我们重新审视每一个建立在“做软件很贵”这个前提上的流程。

我甚至认为，PoC 这个概念可能已经不再成立。 过去所谓的 PoC，现在更像 discovery。那 discovery 怎么做？我认为直接在代码里做。你的 discovery 过程可以完全发生在代码中。那代码做完要不要丢？不用。为什么要丢？它是液体。你可以弯它、挪它、重塑它，直到变成你想要的形态。

通过“边创造边发现”来工作，会在根本上改变很多事情。这个范式我们还需要一些时间去吸收。我非常希望你认真审视：在你当前系统里，哪些东西在隐含地假定“做软件非常昂贵”。而且我说的“成本”不只是钱，也包括组织成本。

这就是第一个判断：软件正在变成液体。

管理者应该走进代码

第二个判断，给所有带人团队的管理者。

我过去有一个非常坚定的信念：当我看到一个人员管理者 - 无论是总监还是经理 - 跑去写代码，这通常是警讯。大多数时候，这意味着他在回避本该处理的更困难问题。比如：“你在做具体开发？我猜你有人员问题没处理。”

我现在不再这么看。代理式工程从根本上改变了这件事。

历史上的问题很简单：上下文窗口。作为管理者，你无法真正掌握代码库，因为它太复杂了。那是一块固态资产，由工程手艺人持续打磨。你必须把注意力放在人和系统上。你很难同时在脑子里高质量容纳两件事。

代理完全改变了这个范式。作为总监或经理，没有理由不与代理对话，去询问你所负责资产的质量。而作为人员管理者，你本来就要对团队产出的资产负责。 那你为什么不直接对话这个资产？

为什么我要先问工程师“这个大概要多久”？我本应先和 Claude Code 对话 - 看源码，问它：这是大规模重构吗？如果走这个方向，形态会怎样？

当我们进一步讨论代理化，这件事会更颠覆。因为我们越来越多是在为代理创造软件，而不是只为人创造软件。你想想这个循环：你和一个代理共同创建软件；另一个代理使用它；使用代理给你反馈效果；你把反馈交回编码代理，让它继续迭代。

在这个循环里，你扮演什么角色？我也说不准 - 也许是产品经理。

我今天在家里多个项目上就这么做：让代理彼此给反馈。这种速度和范式变化，是我们必须调整思维方式的基础。

重新思考速度

最后我想让你重点思考：作为一个行业，我们需要在“速度”认知上发生一次台阶式变化。

“这件事要多久？”我认为你现在所有回答这个问题的范式都坏掉了。成本理解坏掉了，复杂度理解坏掉了，全部都坏掉了。

真正评估它的唯一方法，是我前面说的第二点：更接近你负责的资产，更接近代码和产品本身。

就像移动时代一样 - 你没有真实体验过移动应用，就不可能真正理解如何构建它 - 你没有亲身经历代理式转型，就不可能真正理解它。

不要害怕靠近代码。也不要害怕对团队说：“嘿，怎么把那段代码从 Git 里拉出来？我想自己看一眼并做些分析。”

这些是超能力。我们每个人都可以披上斗篷。以前你没有这些能力。现在你有了。我觉得这非常惊人。整个行业都会经历这次转型。

变化曲线与变化速度

最后我想用“变化”本身来收尾。

有个模型叫 Satir 变化曲线。我们每个人现在都处在曲线的不同位置。但和过去每次转型一样，你前进的速度，取决于你自己的投入程度 - 取决于你是否愿意重新思考你掌握的这门手艺，是否愿意放下那些过去二十年很重要、但现在可能不再重要的东西。

我邀请你走上这条路。

就我个人而言，这并不容易。难的地方在于变化速度。想想看：移动时代我们有两三年甚至四年来摸索；云时代我们有半个十年；Web 更久，因为它是第一波。而这一次，我们试图在大约一年内完成。

为什么？因为它建立在此前所有能力之上，并且潜在收益巨大。一旦我们识别出有效路径，投资回报周期是按“周”或“月”计算，而不是“年”。这和此前任何一次转型都不同。

希望你在这里听到的内容，能给你一个更稳的锚点。

软件是液体。底层经济范式已经变了。你有能力带领团队穿过这次变化。