Software-Engineering on Armstrong Yan

AI 原生软件工程（四）：氛围编程无法取代人的判断

Sat, 18 Jul 2026 23:53:44 +0800

实现可以自动化，评估也可以自动化。但判断，始终只能由人来做。

这是“AI 原生软件工程”系列的第四篇。

本文接续上一篇：AI 原生软件工程（三）：软件即搜索。

第一篇追问，我们如何形成理解。

第二篇追问，我们如何获得正确性。

第三篇提出，软件正在变成一种搜索过程。

但有一个危险的误解，必须说清楚：

只要有智能体、验证框架和约束，
软件就能自行生产出来。

事实并非如此。

在第二篇里，约束帮助我们获得正确性。

在第三篇里，约束塑造了实现方案的搜索过程。

这一篇要继续追问：谁来为约束本身负责？

谁来决定该优化什么，
该拒绝什么，
又有哪些东西从一开始就值得做？

开始采用 AI 辅助的软件开发流程后，我注意到一个出乎意料的现象。

实现能力越强，判断反而越有价值。

起初，我觉得这有些反常。

AI 越强，人的决策不应该越不重要吗？

结果恰恰相反。

实现不再是瓶颈。

方向才是。

氛围编程：好用，直到失控链接到标题

大多数开发者都经历过这样的过程。

一开始，你只有一个简单的想法：

把 X 做出来。

AI 生成代码。

你稍作调整。

跑通了。

于是继续往下做。

一个个小胜利不断累积。

项目也渐渐变大。

直到某个时刻，问题突然一股脑冒了出来：

架构渐渐偏离原来的方向
抽象层越堆越多
调试越来越慢
对系统的信心彻底崩塌

系统依然能运行。

但已经没人说得清，它为什么能运行。

项目陷入一种奇怪的状态：

好像一切都能推倒重来。

却没有任何东西真正处于掌控之中。

我把这叫作氛围编程。

并不是因为 AI 不好。

而是因为，每一步进展都不再对应一个经过认真权衡的决定。

测试通过带来的错觉链接到标题

面对这种问题，一个常见的回答是：

多加一些测试就好了。

我也这样做过。

AI 原生软件工程（三）：软件即搜索

Sat, 18 Jul 2026 23:37:09 +0800

当实现变得唾手可得，工程就不再那么像建造，而更像导航。

这是“AI 原生软件工程”系列的第三篇。

本文承接上一篇：AI 原生软件工程（二）：验证框架工程与正确性。

第一篇追问：

当实现工作交给 AI 后，理解从何而来？

第二篇追问：

当生成的成本变得低廉，如何保证正确性？

这一篇要问：

如果实现越来越便宜，
工程师究竟在做什么？

在这里，约束的含义发生了变化。

第二篇谈约束，是为了保证正确性。

这一篇谈约束，是为了界定搜索范围：

如何划定可接受实现的范围？

纵观软件发展史的大部分时期，开发软件就意味着把它建造出来。

先有一个想法。

然后设计架构。

接着编写实现。

最后测试结果。

瓶颈显而易见：

写代码。

我们对工程能力的理解，也一直建立在这个前提之上。

人们眼中的优秀工程师，往往能够：

更快写出实现
更快完成调试
熟记更多 API
精通更多框架
交付更多可以运行的代码

AI 正在动摇这个前提。

不是因为它会取代工程师。

而是因为它让实现成本骤降。

一旦实现变得便宜，软件开发的方式也会随之改变。

它开始变得像一场搜索。

传统工程：在实现稀缺时做建造链接到标题

传统的软件开发大致遵循这条路径：

想法
-> 架构
-> 实现
-> 验证

实现的代价很高。

每个决定都要付出成本。

每一层抽象都至关重要。

改变方向非常痛苦，因此人们会在动手之前优化方案。

工程就是建造。

AI 让建造变成探索链接到标题

有了现代编程智能体，实现不再稀缺。

短短几分钟，你就可以得到：

五种架构
三套重构方案
两种数据库模型
多套 API 设计

于是，工作流程变成了：

AI 原生软件工程（二）：验证框架工程与正确性

Sat, 18 Jul 2026 23:29:59 +0800

在 AI 原生软件工程中，最重要的也许不是生成，而是约束。

这是「AI 原生软件工程」系列的第二篇。

本文承接上一篇：AI 原生软件工程（一）：智能体编程中的心智模型。

上一篇讨论的问题是：

如果理解系统不再主要依靠亲手写代码，
人类要如何在智能体工作流中建立心智模型？

接下来的问题是：

如果实现工作交给了 AI，
正确性从何而来？

谈到 AI 辅助软件开发，人们往往只关心一件事：

我们能将软件产出提高多少？

编码更快。

上下文更长。

智能体可以自主运行。

一次改动多个文件。

工作流能够自我修复。

但用 AI 智能体做了一段时间项目后，我却得出了相反的结论：

最重要的工程问题，不是如何让 AI 更自主。

而是如何更严格地约束 AI。

因为毫无限制地生成代码，几乎从来不是瓶颈。

正确性才是。

这里暂且不谈约束对创造力或搜索空间的影响，只谈正确性。

真正要回答的是：

怎样才能让 AI 生成的实现可以被放心信任？

传统软件开发的基本假设链接到标题

传统软件开发建立在一个简单的假设上：

人
-> 实现
-> 验证

写系统的人，也会在动手实现的过程中逐渐理解系统。

很多时候，验证并不会被单独提出来。

因为实现出自自己之手，你自然更愿意相信它。

在小团队中，这套做法出人意料地管用。

直到复杂度不断攀升。

AI 打破了这个假设链接到标题

智能体编程改变了原有结构。

现在，整个循环变成了：

人
-> 意图
AI
-> 实现
人
-> 审查

乍看之下，效率很高。

AI 原生软件工程（一）：智能体编程中的心智模型

Sat, 18 Jul 2026 22:57:49 +0800

AI 能生成代码。验证框架能检验行为。但理解由谁来建立？

这是“AI 原生软件工程”系列的第一篇。

这个系列想追问一个更大的问题：

当 AI 降低了实现成本，
软件工程中还有什么是稀缺的？

本文先从第一种稀缺资源谈起：

理解。

过去几个月，我一直在密集尝试 AI 辅助的软件开发方式。

不是自动补全。

也不只是把 AI 当作编程副驾驶。

而是一套由智能体主导执行的工作流：

SPEC
-> 约束
-> 验证框架
-> 智能体执行
-> 评估
-> 迭代

这段经历非常有意思。

借助它，我用自己并不十分熟悉的语言和框架交付了项目，开发速度也大幅提升。

做小项目时，简直像魔法。

可一到更大的项目，意想不到的情况发生了。

我发现，实现速度和系统理解并不是一回事。

最后，我不得不面对一个让人不太舒服的事实：

如果 AI 明天消失，
我可能很难继续开发自己系统里的某些部分。

这个认识改变了我看待软件工程的方式。

传统模式：在实现过程中形成理解链接到标题

过去的软件工程，大致是这样的：

人
-> 编写代码
-> 建立心智模型
-> 运行和维护系统

写代码不只是为了实现功能。

它也是学习系统的过程。

我们在这些事情中逐渐弄懂系统：

调试
重构
追踪执行过程
与各种约束周旋
犯错

亲手实现，自然会带来理解。

只是过去，我们未必意识到这一点。

智能体编程改变了路径链接到标题

有了 AI 编程，整个循环变了。

播客摘要工具让我明白：摘要不等于理解

Sat, 18 Jul 2026 12:13:29 +0800

有人看到我简历上的一个项目，问了我一个很简单的问题：

这个软件真的解决了你的问题吗？

这个问题问得很好。

那个项目是一款播客摘要工具。

源代码公开在这里：yanqian/podcast-summarizer。

最初的想法很直接。

听完一段长音频，要花不少时间。

如果能先把一期节目转成文字，再生成摘要，我也许只需读一遍摘要，不必花一个小时收听，就能理解整期内容。

当时的产品假设是这样的：

长内容
 -> 转写文本
 -> 摘要
 -> 理解

真正做完以后，我才意识到，这个假设并不成立。

倒也不是全错。

但它偏偏错在最关键的地方。

这个软件确实能生成摘要。

它也完整展示了一套 AI 工作流。

它能导入播客、处理音频、生成转写片段和摘要片段，还能显示两者之间的对应关系。

作为工程演示，它是成功的。

但作为帮助人理解内容的工具，它没有解决真正的问题。

最初的问题并不是内容太长链接到标题

一开始，我以为问题就在于内容太长。

一期播客很长。

一篇博客文章也可能很长。

会议转写同样可能很长。

于是，最自然的产品思路就是压缩：

把内容变短

摘要承诺的正是这件事。

它减少篇幅。

删去重复。

把散漫的对话梳理出结构。

看起来很高效。

但真正读过生成的摘要后，我发现了一件不太对劲的事。

摘要读完了，我还是不知道那场谈话究竟是怎样展开的。

我知道他们谈了什么。

知道大致结论。

也记住了几个要点。

但我并没有真正理解整段对话。

摘要丢掉了：

一个观点是怎样被引出来的
是什么问题触发了这个观点
哪些地方仍有疑问
有哪些例子支撑它
讨论过哪些取舍
哪些情绪或现实背景很重要
说话者在哪里改变了思路

摘要并没有说错。

它只是不够。

摘要会抹掉通往结论的过程链接到标题

好的摘要保留了终点。

却留不住抵达终点的那条路。

这正是问题的核心。

很多时候，我们恰恰要沿着这条路走一遍，才能真正理解一个观点。

Software-Engineering on Armstrong Yan

AI 原生软件工程（四）：氛围编程无法取代人的判断

氛围编程：好用，直到失控 链接到标题

测试通过带来的错觉 链接到标题

AI 原生软件工程（三）：软件即搜索

传统工程：在实现稀缺时做建造 链接到标题

AI 让建造变成探索 链接到标题

AI 原生软件工程（二）：验证框架工程与正确性

传统软件开发的基本假设 链接到标题

AI 打破了这个假设 链接到标题