我不经常发表博文。当我这么做时，往往是因为我觉得某些重要的趋势还没有被足够多的人点破。
最近，我一直在从头开始构建一个产品。这里说的“从头开始”，可不是指“我启动了一个 Next.js 模板”那种。我的意思是从网络配置、产品设计再到定价决策，真正的端到端亲力亲为。在这个过程中，我大量使用了前沿的AI模型和编码代理，每天花费数小时，无论是为这个项目还是我的全职工作。我的目标一直是远离炒作，努力筛选出真正有价值的东西。
自 2025 年 12 月以来，事情发生了戏剧性的好转。很多人都注意到了这种进步，但似乎很少有人能准确地道出它意味着什么。
自动化编程
Antirez 喜欢称之为“自动化编程”，我真的很认同这个说法。它比“氛围编码”这类肤浅甚至带点轻蔑的标签更能抓住本质。回顾人类历史，自动化始终是推动工作和文化革命的核心。从印刷机、织布机到装配线，这一次并没有什么本质不同。
我的大部分核心工作依然没变。对于想要构建的东西，我仍然需要深入思考每一个重要环节——架构、权衡、产品决策，乃至那些凌晨三点还在反复琢磨的边缘情况。真正消失的，是那些需要逐行敲击代码的、令人精疲力竭的体力劳动。
在这个前提下，一个干净且配置良好的环境，搭配得力的模型和工具，确实能带来质变。我能成为建筑师，却不必亲手砌每一块砖、抹每一道灰。我能设计礼服，却不必裁剪缝制每一片布料。当然，这一切都源于过去二十年亲手“砌砖抹灰”所积累的经验。但最重要的是，当结果不合我意时，我能够深入底层，洞悉问题本质，按我的想法修正它，并永久性地调整系统设置，让它下次能按我的意愿行事。
尤其是，自动化编程让我能够快速打造自己需要的工具。历史上每一位铁匠如果看到这一幕，恐怕都会羡慕不已——终于能够将绝大部分精力，投入到他们心目中真正重要的“艺术创作”上，而非日复一日的“锻造汗水”中。
一个顿悟
这个念头在我脑海中已经酝酿了数月。它如此清晰，以至于我真心不明白为何世人还不把它大声说出来。
我们终于可以摆脱所有那些“中间层”工作了。 这些年来，我们几乎是在盲目接受的一堆“垃圾”。大量的框架、库和工具，彻底“污染”了软件工程，尤其是在 Web、移动和桌面开发领域。抽象层层堆叠，用一些本不该存在的抽象去解决本不该存在的问题，每解决一个旧问题，却常常创造出十个新问题。
想想发生了什么。作为一个行业，在见识到构建软件的真正复杂性后，我们没有选择去锤炼自己的思维，而是直接购买了别人的“思维”。我们用框架封装一切，就像用华丽的丝绸去包裹一条断腿。表面看起来不错，但腿依旧是断的。
框架解决（或声称解决）的三个问题
在我看来，除了它们自称的目标，框架主要解决了三个问题：其中两个被明确宣称，另一个则显而易见却从未被正式声明。
-
“简化”。很多软件工程师害怕自己设计东西。他们宁愿接受别人预设好的结构，哪怕需要强行适配到自己的产品中，也不愿花时间从目标出发，逆向设计出完美契合自身理念的解决方案。这就好比一个建筑师，盲目照搬另一个建筑师的蓝图，而完全不顾环境、实际需求、地形以及新的技术可能性。为了所谓的“消除复杂性”，我们决定购买一种“一刀切”的设计并到处套用。这不是简化，这是投机取巧。
-
自动化。实际上，这是我多少能够理解并接受的唯一一点。编写样板代码确实是件枯燥的苦差事。我讨厌那项工作。我尤其讨厌使用那些需要专门研究、持续更新、时刻警惕漏洞的库，仅仅是为了避免重复编写那些不可或缺的代码。想想 ORM、CRUD 管理、代码生成、API 文档等等。这些是没人想做但每个人都得完成的脏活累活。这一点，听起来有道理。不过别急，正是从这里开始，一切都将改变。
-
劳动力成本。这是从未被声明的那一点，没人会把它放在会议幻灯片上。对于企业来说，让谷歌、Meta、Vercel 帮你决定如何构建产品和发布代码，要“方便”得多。采用它们的框架，接受供应商锁定的代价。被它们的云管理方案所吸引，用于托管、部署、存储。你由此解锁了一个与工程无关的功能：你不再需要雇佣“软件工程师”。你雇佣一个“React 开发者”，无需培训，即插即用，易于替换。他们就像是别人设计的机器中的一个齿轮，维护着由别人架构的系统，解决着由别人定义的问题。这不是工程，这是运营。
软件工程，回归了
在我看来，真正的软件工程又回来了。
我这么说并非空穴来风。我已经用这种方式开发了两年多，实践效果近乎完美。但真正的革命性变化显然发生在去年，自 2025 年 12 月以来，对于任何关注此事的人来说，这一点都显而易见。而从现在起，它将更加明显。
我们再次获得了一个机会，可以摆脱那些无用的复杂性，继续专注于我们的想法、特性和产品中那些真正有价值、受欢迎的复杂性。那些重要的、真正属于你自己的复杂性。
自动化和样板代码的挑战，从未像今天这样能够被如此廉价地克服。基本上，同样的代码行我从未写过两次。我可以立即构建我需要的小工具，有目的地构建，完全围绕手头正在处理的问题。我不再需要任何花哨的单仓库（Monorepo）管理器。对于我 99% 的用例，一个简单的 Makefile 就可以满足全部需求。只有当事情变得真正复杂时（如果真的会），我才会考虑更复杂的工具。但绝不会提前一秒。这就是工程——你解决手头的问题，而不是解决某个会议上别人告诉你“未来可能会有”的问题。
在基本工具方面，编码代理已经准备得非常充分。这些工具已经存在了几十年，而不仅仅是几个月。Bash 诞生于 1989 年，比我还早两个月。如今，即便是最平庸的模型，也比世界上任何人都更了解 Bash。Bash 是通用适配器。编码代理从复杂昂贵的 MCP 配置，转向采用以 Bash 为交互方式的简单代理循环，这绝非偶然。最古老的工具，反而展现出最强的未来适应性。这其中的启示，值得我们深思。
认真想想
真的，请认真想想。
对于你能想到的大多数用例，你为什么还需要一个庞大、昂贵、有缺陷且往往容易受到攻击的框架，以及那些伴随而来、而你只用了其中 10% 功能的库？还有与之相关的所有成本，从“最不”昂贵的运营成本（比如不断更新所有库，因为在你使用的 Next.js 版本中又发现了一个关键漏洞），到最昂贵的设计选择成本——那种无形的成本，你每天都在支付却浑然不觉，只因你已支付了太久，以至于忘记了自由的感觉。
如果你继续接受这种权衡，不仅将错失软件工程领域数十年来最大的机遇，还可能因惰性而再次选择盲从那些超大规模云服务商为你做的决策。你正让谷歌、Meta 和 Vercel 成为你的架构师、设计师和思想者，而你换来的，不过是成为他们的操作员。
工具已经有了。模型已经有了。革命已经发生，而大多数人却仍在忙着装饰那栋老房子。
别再试图用丝绸去包裹断腿了。是时候开始构建真正属于你自己的东西了。
一些回响
文章作者的观点也引发了不少讨论。例如，一位名叫 Yuuki 的开发者评论道：
我完全同意你的观点。
我目前正在构建我自己的库，完全不需要使用那些背负着沉重历史包袱的高度复杂库。更重要的是，我相信这是一个创造的时代——我们可以参考像 Spec Kit 和 OpenClaw 这样的项目，但更重要的是要自主探索和实验。
相信自己的品味。最好的品味往往来自个人，而不是组织。
评论区另一位用户 AH 则留下了不同的看法：
感谢分享，这真是发人深省。我的第一反应有以下两点。
一、我不认为我们今天拥有的模型真的像框架那样解决了“简化”问题。我认为，对于顶级工程师来说，LLM 是真正的倍增器，但中低级工程师需要在这个新工程时代中用尽全力去提升自己的水平。
真正的危险在于，似乎没有人愿意解决这个问题。我们该如何开发提示技巧并培训新晋开发人员？例如，我来自第三世界国家，现在才刚开始将模型融入开发流程。使用框架时，我能立即获取操作指南和海量的应用示例。但 LLM 供应商提供的却只有玩具示例，整个生态系统的文档支持也严重不足。我最担忧的是，技术鸿沟只会越拉越大。
第二个不赞同的点是，我不相信模型可以自我改进，至少目前是这样。框架会随着时间的推移而演变，无论是功能、架构还是易用性的改进。LLM 会怎么做？我们会被困在用于训练模型的架构中吗？简而言之，我们确定 LLM 可以“思考”它们生成的结果里存在的问题，研究并改进它们的输出吗？
虽然你说工程学关乎解决你现在面临的问题，而不是我们明天可能遇到的问题，但我们仍然需要为明天的问题做准备。这将如何实现呢？
原文链接：
https://blog.alaindichiappari.dev/p/software-engineering-is-back
你对 AI 编程如何改变开发模式有什么看法？是时候回归工程本质，还是需要更完善的工具和培训体系？欢迎在 云栈社区 的开发者广场分享你的见解，一起聊聊这个正在发生的技术变革。
发表于 2 小时前
|
查看: 3|
回复: 0
