驾驭工程就是软件工程:换个对象而已

工具变了，对象变了，但工程没有变

我们并没有进入一个“全新领域”

最近一段时间，“驾驭工程（Harness Engineering）”被反复提起，很多人把它描述成 AI 时代的一门新学科，甚至有点“不会这个就落后”的意味。

但如果把这层滤镜拿掉，你会发现一件很朴素的事实：我们并没有进入一个全新的领域，我们只是换了一个合作对象。

过去写代码的是人，现在写代码的是 AI。差别确实存在，但工程的核心问题，从来没有变过。

你以为在写 Prompt，其实在写“规格说明”

很多人刚开始用 AI 写代码，会觉得自己在“调 Prompt”。但用久了会发现，这件事越来越像在写一份规格说明。

比如你让 AI：

“帮我实现一个文件上传接口”

它可能会：

• • 直接保存文件
• • 忽略文件类型校验
• • 没有限制大小
• • 没有任何安全处理

这时候你会开始补充：

• • 只允许上传图片
• • 限制文件大小
• • 做 MIME 校验
• • 防止路径穿越
• • 返回统一结构

这一过程，如果换个说法，其实就是：把一句模糊的需求，逐步压缩成一份不可歧义的约束。

这和我们过去写接口文档、写设计说明，本质是同一件事。

所以所谓“Prompt 工程”，更准确的说法是：用另一种形式在写规格说明（Spec）。

AI 不会替你保证质量，反而更需要你兜底

很多人一开始会有个错觉：AI 很强，写代码很快，是不是可以少写测试？

现实往往是反过来的。

AI 的问题不在“写不出来”，而在于：

• • 会漏边界条件
• • 会误解语义
• • 会给出“看起来合理”的错误实现

比如你让它写一个“订单超时自动取消”的逻辑，它可能完全忽略：

• • 并发场景
• • 重复执行
• • 状态幂等
• • 定时任务漂移

这些问题，人类工程师也会犯，但 AI 更容易“系统性忽略”。

于是你很自然会开始做这些事：

• • 准备一组典型场景去验证输出
• • 在关键路径加断言
• • 记录 AI 的行为日志
• • 对异常结果做兜底处理

你会发现，这一整套东西，其实就是：测试 + 校验 + 监控。

也就是说：AI 没有让工程更简单，它只是让“工程约束”变得更重要了。

复杂度没有降低，只是换了表达方式

很多人会觉得，用了 AI 之后，很多复杂问题被“隐藏”了。

但实际情况是：复杂度没有减少，只是换了一种形态出现。

以前你在处理的是：

• • 线程安全
• • 内存管理
• • 分布式一致性

现在你在处理的是：

• • 上下文怎么拆分
• • 多个 Agent 怎么协作
• • 长尾输入如何覆盖
• • 输出如何保持稳定

比如一个简单的“自动生成接口文档”的需求，如果完全交给 AI，往往会出现：

• • 风格不一致
• • 字段解释缺失
• • 示例不完整

于是你开始：

• • 拆分步骤
• • 约束输出格式
• • 引入中间校验
• • 组合多个能力

换个说法，这就是：再做一遍模块化设计。

不确定性从来不是新问题

有人会说：

AI 是概率系统，软件工程是确定系统，这两者不一样

听起来很有道理，但其实有点误导。

因为软件工程从来就不“纯确定”。

现实世界里：

• • 请求会失败
• • 服务会超时
• • 数据会延迟
• • 系统会抖动

我们一直在做的事情，就是：用工程手段控制不确定性。

比如：

• • 重试机制
• • 超时控制
• • 降级策略
• • 熔断保护

现在面对 AI，只是换了另一套工具：

• • 多次生成取最优
• • 加规则过滤输出
• • 用评估集做打分
• • 控制生成参数

本质还是一样的：把一个不稳定的系统，限制在可接受范围内。

我们的工作，其实更接近“设计系统”

当代码可以由 AI 生成之后，工程师的重心自然发生了变化。

你不再需要花大量时间写实现细节，而是更多地在做：

• • 定义边界
• • 设计流程
• • 约束行为
• • 控制风险

换句话说，你不再是“写代码的人”，而更像是：设计系统如何运作的人。

你写的东西，也不再只是代码，而是：

• • 规则
• • 结构
• • 流程
• • 约束

这些东西组合在一起，本质上就是：一份“系统蓝图”。

名字可以变，问题没有变

“驾驭工程”这个名字本身没有问题，它确实描述了一种新的工作方式。

但如果因此觉得这是一个完全不同的领域，反而容易走偏。

因为从头到尾，我们解决的都是同一个问题：怎么构建一个可靠、可维护、能长期演进的系统。

过去我们约束的是人，现在我们约束的是模型。过去输入的是需求，现在输入的是上下文和规则。

但最终目标没有变：用工程的确定性，对抗系统的不确定性。

如果一定要总结成一句话，那就是：

驾驭工程，本质上还是软件工程。