作者 | Alain

译者 | 平川

策划 | Tina

本文最初发布于 Alain 的个人博客。

我不经常发表博文。当我这么做时，是因为我觉得还没大有人把我注意到的事情说出来。

我一直在从头开始构建一个产品。不是那种“我启动了一个 Next.js 模板”的从头开始。我的意思是从网络配置到产品设计再到定价决策。真正的端到端。我一直在使用比较前沿的模型和编码代理，每天花费数小时，无论是在这个项目上还是在我的全职工作中。我一直在努力远离混乱和炒作，努力筛选出真正有价值的东西。

自 2025 年 12 月以来，事情戏剧性地变好了。许多人都注意到了，但很少有人得出过正确的结论。

自动化编程

Antirez 喜欢称之为“自动化编程”，我真的很喜欢这种表述。与“氛围编码”这个肤浅、几乎带有轻蔑意味的标签相比，它更能抓住本质。在人类历史上，自动化一直是大多数工作和文化革命的核心所在。印刷机、织布机、装配线，这一次并没有太大的不同。

我的大部分工作还是那样。对于我想要构建的东西，我仍然需要深入地思考每一个重要的方面——架构、权衡、产品决策、凌晨 3 点反复思考的边缘情况。消失不见的是那些需要逐行敲击代码的令人精疲力竭的繁重体力劳动。

这个时候，在一个干净且经过良好设置的环境中，模型和工具确实可以带来差异。我能成为建筑师，却不必亲手砌每块砖、抹每道灰。我能设计礼服，却不必裁剪缝制每片布料。但这一切都源于二十年来亲手砌砖抹灰、裁剪缝纫的经验积淀。但如果遇到不合心意的地方，我也可以深入其中，洞悉本质，随心修正，并永久性地调整系统设置，让它下次按我的意愿行事。

尤其是，自动化编程让我可以快速构建我需要的工具，曾经存在于这个地球上的每一名铁匠都会非常地羡慕我。终于能够真正地专注于他们认为重要的事情了。终于能够将更多的时间投入到他们构想的艺术创作中，而不是锻造间的汗水中。

顿悟

这个念头在我的脑海中已经酝酿数月之久。它如此清晰明了，以至于我真心不明白为何世人都不向全世界呐喊宣传。

我们终于可以摆脱所有那些中间层工作了。这些年来，我们盲目接受的那层垃圾。大量的框架、库和工具，彻底污染了软件工程，特别是在 Web、移动和桌面开发中。抽象层层堆叠，用没有意义的抽象解决了本不应该有的问题，每解决一个问题，却创造了十个新问题。

想想发生的一切。作为一个行业，在看到了构建软件的真实复杂性之后，我们没有磨砺我们的思维，而是购买了别人的思维。我们用框架封装一切，就像用丝绸包裹一条断腿。看起来不错，但腿还是断的。

框架解决（或声称解决）的三个问题

在我看来，除了框架自称的目标之外，它们还解决了三个问题：两个明确的和一个明显但从未声明过的。

“简化”。软件工程师害怕自己设计东西。他们宁愿接受别人的结构，尽管不得不强行适配到他们的产品中，也不愿花时间从目标出发，倒推设计出完美契合自己理念的解决方案。就像一个建筑师盲目接受另一个建筑师的蓝图，不管环境、需求、地形、新的技术可能性如何，拿来就用。为了所谓的消除复杂性，我们决定购买一种适合所有人的设计并到处应用。这不是简化。这是投机取巧。

自动化。实际上，这是我或多或少能够理解并接受的唯一一点。编写样板代码是件无聊的工作。我讨厌那项工作。我尤其讨厌使用那些需要我专门研究、持续更新、时刻警惕漏洞的库，仅仅是为了避免重复编写那些不可或缺的代码。想想 ORM、CRUD 管理、代码生成、API 文档，等等。那些没有人想做但每个人都需要完成的苦差事。说得有道理。不过先别急着下结论，因为正是从这一刻起，一切都将改变。

劳动力成本。这是从未声明过的那一点。没有人把它放在会议幻灯片上。对于企业来说，让谷歌、Meta、Vercel 帮你决定如何构建产品和发布代码要好得多。采用他们的框架，支付供应商锁定的成本。为他们的云管理解决方案所吸引，用于托管、部署、存储你的东西。你解锁了一个与工程无关的功能：你不再需要雇佣软件工程师。你雇佣一个 React 开发者，不需要培训，即插即用，易于替换。一个由别人设计的机器中的齿轮，维护由别人架构的系统，解决由别人定义的问题。这不是工程。这是运营。

软件工程回来了

在我看来，真正的软件工程又回来了。

我这么说并不是空穴来风。我已经用这种方式开发了两年多，几乎无懈可击。但真正的革命显然是去年发生的，自 2025 年 12 月以来，对于任何关注过的人来说，这一点都显而易见。从现在起，这一点将更加明显。

我们再次获得了一个机会，让我们可以摆脱无用的复杂性，继续致力于我们的想法、特性和产品中那些真正受欢迎的复杂性。那些重要的复杂性，那些真正属于你的复杂性。

自动化和样板代码的挑战从未如此廉价地被克服。基本上，同样的代码行我从未写过两次。我立即就可以构建我需要的小工具，有目的地构建，完全围绕手头正在处理的问题。我不需要任何花哨的单库管理器。对于我 99% 的用例，一个简单的 Makefile 就可以满足全部需求。当事情变得非常复杂时，如果真的变得非常复杂，我会考虑的。但也只有在那时，不会提前一秒。这就是工程。你解决你手头的问题，而不是某个人在会议上告诉你你最终会有的问题。

在基本工具方面，编码代理做了非常好的准备。这些工具已经存在了几十年，而不仅仅是几个月。Bash 诞生于 1989 年，比我出生早两个月。现在运行的最平庸的模型也比世界上任何人都更了解 Bash。Bash 是通用适配器。编码代理从复杂昂贵的 MCP 配置转向采用以 Bash 为交互方式的简单代理循环，这绝非偶然。最古老的工具反而展现出最强的未来适应性。其中蕴含的启示值得你认真领会。

想想吧

真的想想吧。

对于你能想到的大多数用例，为什么你需要一个无用、昂贵、有缺陷而且往往容易受到攻击的框架，而对于那些相伴而来的库，你可能只用了其中 10% 的功能？还有与之相关的所有成本。从“最不”昂贵的运营成本（比如保持所有库及时更新，因为他们再次在你使用的 Next.js 版本中发现了一个关键漏洞）到最昂贵的设计选择成本——无形的成本，你每天都在支付却没有意识到，因为你已经支付了这么久，忘记了自由的感觉。

如果你继续接受这种权衡，则不仅将错失软件工程领域数十年来最大的机遇，还可能无法察觉自己的惰性而再次选择盲从超大规模云服务商为你做的决策。你正让谷歌、Meta 和 Vercel 成为你的架构师、设计师和思想者，而你换来的，不过是成为他们的操作员。

工具已经有了。模型已经有了。革命已经发生，大多数人却仍然在装饰老房子。

不用再用丝绸包裹断腿了。开始构建属于你的东西。

对于作者的观点，Yuuki 表示：

我完全同意你的观点。

我目前正在构建我自己的库，完全不需要使用那些背负着陈旧包袱的高度复杂的库。更重要的是，我相信这是一个创造的时代——我们可以参考像 Spec Kit 和 OpenClaw 这样的项目，但更重要的是要自主探索和实验。

相信自己的品味。最好的品味往往来自个人，而不是组织。

评论区还有一位用户 AH 留下了自己不同的看法：

感谢分享，这真是发人深省。我的第一反应有以下两点。

一、我不认为我们今天拥有的模型真的像框架那样解决了“简化”问题。我认为，对于顶级工程师来说，LLM 是真正的倍增器，但中低级工程师需要在这个新工程时代中用尽全力去提升自己的水平。

真正的危险在于，似乎没有人愿意解决这个问题。我们该如何开发提示技巧并培训新晋开发人员？例如，我来自第三世界国家，现在才刚开始将模型融入开发流程。使用框架时，我能立即获取操作指南和海量的应用示例。但 LLM 供应商提供的却只有玩具示例，整个生态系统的文档支持也严重不足。我最担忧的是，技术鸿沟只会越拉越大。

第二个不赞同的点是，我不相信模型可以自我改进，至少目前是这样。框架会随着时间的推移而演变，无论是功能、架构还是易用性的改进。LLM 会怎么做？我们会被困在用于训练模型的架构中吗？简而言之，我们确定 LLM 可以“思考”它们生成的结果里存在的问题，研究并改进它们的输出吗？

虽然你说工程学关乎解决你现在面临的问题，而不是我们明天可能遇到的问题，但我们仍然需要为明天的问题做准备。这将如何实现呢？