当实现变得唾手可得，工程就不再那么像建造，而更像导航。
这是“AI 原生软件工程”系列的第三篇。
本文承接上一篇：AI 原生软件工程（二）：验证框架工程与正确性。
第一篇追问：
当实现工作交给 AI 后，理解从何而来？
第二篇追问：
当生成的成本变得低廉，如何保证正确性？
这一篇要问：
如果实现越来越便宜，
工程师究竟在做什么？
在这里，约束的含义发生了变化。
第二篇谈约束，是为了保证正确性。
这一篇谈约束，是为了界定搜索范围：
如何划定可接受实现的范围？
纵观软件发展史的大部分时期，开发软件就意味着把它建造出来。
先有一个想法。
然后设计架构。
接着编写实现。
最后测试结果。
瓶颈显而易见：
写代码。
我们对工程能力的理解，也一直建立在这个前提之上。
人们眼中的优秀工程师，往往能够：
- 更快写出实现
- 更快完成调试
- 熟记更多 API
- 精通更多框架
- 交付更多可以运行的代码
AI 正在动摇这个前提。
不是因为它会取代工程师。
而是因为它让实现成本骤降。
一旦实现变得便宜，软件开发的方式也会随之改变。
它开始变得像一场搜索。
传统工程：在实现稀缺时做建造 链接到标题
传统的软件开发大致遵循这条路径：
想法
-> 架构
-> 实现
-> 验证
实现的代价很高。
每个决定都要付出成本。
每一层抽象都至关重要。
改变方向非常痛苦，因此人们会在动手之前优化方案。
工程就是建造。
AI 让建造变成探索 链接到标题
有了现代编程智能体，实现不再稀缺。
短短几分钟，你就可以得到：
- 五种架构
- 三套重构方案
- 两种数据库模型
- 多套 API 设计
于是，工作流程变成了：
意图
-> 生成
-> 评估
-> 重复
这已经不太像建造。
更像搜索。
搜索其实无处不在 链接到标题
这种说法听起来或许陌生。
但我们早就在使用各种搜索系统。
编译器：
程序
-> 优化空间
-> 二进制文件
数据库查询规划器：
查询
-> 执行计划
-> 结果
机器学习训练：
目标
-> 参数搜索
-> 模型
现代 AI 编程或许会变成：
约束
-> 实现搜索
-> 系统
代码成了输出。
不再是过程本身。
搜索需要目标函数 链接到标题
没有评估的搜索，只会失控。
许多 AI 工作流的问题就出在这里。
人们只写下一句：
帮我做一个博客。
AI 开始生成。
接着，人们毫无章法地东改西改。
最终，某个方案奏效了。
但这不是工程。
这只是漫无目的地乱走。
只有存在目标函数时，搜索才会奏效。
例如：
延迟
可靠性
成本
正确性
开发者体验
故障恢复
没有目标函数：
生成过程永远无法收敛。
约束划定可能性的边界 链接到标题
可以这样理解软件：
实现负责探索。
约束负责定界。
假设你只提出一句要求：
做一个图片上传系统。
可选方案几乎无穷无尽。
现在加上约束：
响应时间 <500ms
文件大小 <50MB
支持重试
不得重复写入
部署在 Cloud Run 上
每月成本 <$100
搜索空间立刻大幅收窄。
生成结果也会随之改善。
这不是在扼杀创造力。
这就是工程。
工程师成为搜索空间的设计者 链接到标题
认识到这一点后，我看待软件的方式也变了。
也许，工程师的角色正在逐渐从：
系统建造者
转向：
搜索空间设计者
职责也会随之改变。
过去是：
设计
写代码
调试
正在出现的新职责是：
明确意图
定义约束
评估结果
实现成为基础设施。
新的技术能力 链接到标题
如果这个判断成立，未来衡量技术深度的标准也许会改变。
重要性可能降低的是：
- 记忆语法
- 编写样板代码
- 精通特定框架
重要性可能上升的是：
- 定义不变量
- 搭建验证框架
- 理解各种取舍
- 设计评估循环
- 驭复杂性
关键问题将从：
你能把它做出来吗？
变成：
你能说清楚什么才算成功吗？
结语 链接到标题
软件不会消失。
编程也不会消失。
但实现的稀缺性，或许正在消失。
当实现变得充裕：
工程变成搜索。
搜索变成约束。
工程师负责决定，搜索可以走到哪里。