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

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

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

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

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

理解。

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

不是自动补全。

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

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

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

这段经历非常有意思。

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

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

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

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

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

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

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

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

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

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

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

它也是学习系统的过程。

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

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

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

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

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

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

人
-> 描述目标
AI
-> 生成实现
人
-> 审查结果

这很强大。

但真正的变化并不显眼。

实现层被压缩了。

我们能看到结果。

也能验证系统的行为。

可大脑里未必真正形成了系统内部的完整模型。

于是，我们操作这些系统时，越来越像是在面对接手而来的代码库。

不是因为代码一定写得差。

而是因为形成理解的过程也被一并交了出去。

验证框架解决了正确性，却没有带来理解 链接到标题

我对这个问题的应对方式，是开始引入约束。

不再让 AI 毫无限制地生成软件，而是采用这样的流程：

SPEC
-> 功能门控
-> 验证框架
-> 实现
-> 评估

效果出乎意料地好。

验证框架把正确性外部化。

我们不再依赖这样的主观判断：

我相信这个实现是正确的。

而是转向：

系统行为满足明确写出的约束。

例如：

输入
-> 预期输出

负载测试
-> 预期延迟

故障
-> 预期恢复方式

功能
-> 验收标准

这样做大幅提高了可靠性。

但大量使用这套工作流之后，我意识到一件重要的事：

验证框架可以证明系统的行为。

验证框架无法让人形成理解。

真正的问题不是失去编程能力 链接到标题

一开始，我担心的是：

我是不是正在变得依赖 AI？

现在看来，这个问题问偏了。

真正该问的是：

当实现工作交给 AI 之后，
人要怎样建立系统的心智模型？

因为现在的 AI 可以：

  • 修改 20 个文件
  • 引入新的抽象
  • 重新组织模块
  • 迁移框架

而且速度远远超过人理解和消化这些变化的速度。

写代码不再是瓶颈。

理解才是。

一种新能力：协作式深潜 链接到标题

我不再认为答案是：

人必须理解每一行代码。

项目一大，这种要求就不现实。

更合理的要求是：

人在需要时，必须仍然能够一路深入到实现细节。

可以把这种能力称为“协作式深潜”。

系统正常运行时，我们关注：

行为
-> 架构
-> 约束

发生故障时，则一路向下追查：

故障
-> 运行时轨迹
-> 代码路径
-> 具体实现
-> 根本原因

AI 成为探索引擎。

人则始终把握认知闭环。

不再只是：

人 -> 代码

而是：

人
-> 提出问题
AI
-> 展开上下文
人
-> 建立模型
AI
-> 检查细节
人
-> 作出判断

让系统便于层层深入 链接到标题

这也改变了我设计系统的方式。

现在，我不太在意自己能否手写所有东西。

我更在意的是：自己能否在任何一层重新进入理解状态。

对于每一项功能，我现在都希望了解这些内容：

缘由
它为什么存在？

不变量
什么绝对不能被破坏？

流程
数据如何流动？

风险
故障可能发生在哪里？

调试入口
应该从哪里开始排查？

这不是文档。

也不是代码注释。

它们是供人理解系统的接口。

结语 链接到标题

AI 降低了实现成本。

但它没有让软件工程消失。

它只是转移了瓶颈。

过去的问题是：

你能把它做出来吗？

现在的问题是：

你能理解做出来的东西吗？

验证框架负责检验。

智能体负责执行。

但心智模型仍然需要有人建立。

而且，这个过程很可能会越来越多地由人和 AI 协作完成。

工程并没有因此变少。

它只是换了一种形态。