AI到底给软件工程带来了什么?

从代码生成加速，到验证体系重建

Martin Fowler 在谈到 AI 对软件工程的影响时，给过一个很重的判断：这是他职业生涯中最重要的变革。

这个判断容易被理解成对 AI 写代码能力的肯定。但更关键的变化，其实发生在软件工程的底层假设上。

过去的软件工程长期建立在确定性之上。相同输入应得到相同输出，Bug 可以复现，测试结果应当稳定，构建过程可以追踪。编译器、测试、类型系统、CI/CD、代码审查，都是围绕这种确定性建立起来的。

LLM 把非确定性引入了编码过程。

同样的 Prompt，可能生成不同代码；同一个 Agent，在不同上下文下可能选择不同路径；同一个需求描述，可能被模型解释成多个实现方案。AI 提高了代码生成速度，也把质量波动、路径漂移和验证压力带进了研发现场。

所以，AI 给软件工程带来的变化，表层是代码生成加速，深层是验证体系重建。

真正的问题已经不只是“AI 能不能写代码”。更重要的是：团队能不能判断这些代码是否正确，能不能约束 AI 少犯错，能不能让错误被系统发现，能不能把一次纠偏沉淀成后续能力。

AI写代码越快，工程约束越重要

AI 已经可以生成代码、补测试、解释报错、改造旧代码、搭建原型。这些能力会显著提高开发速度。

但软件工程关心的不只是“写出来”。

产品代码需要维护、扩展、调试、回滚、审查和交接。企业系统还要面对安全、权限、性能、合规、可观测和架构一致性。

AI 生成速度越快，工程约束越重要。

缺少约束时，代码会快速增长，系统理解却不断下降。功能交付看起来更快，架构边界可能更模糊。Bug 修复看起来更高效，新问题也会同步增加。

这正是 Fowler 反复强调的风险：AI 可以降低实验门槛，但团队不能绕过软件开发中的学习循环。

编程的学习循环，是“想法—代码—反馈—修正”的持续过程。开发者在这个过程中理解系统结构、边界和变化影响。人如果不读代码、不理解代码、不验证代码，只接受 AI 生成结果，长期系统很容易变成黑盒。

AI 可以参与实现，系统理解不能丢。

Vibe Coding适合探索，长期系统需要工程化

Vibe Coding 的价值很清楚。

一次性脚本、快速原型、临时工具、Demo 验证，这些场景不追求长期维护，代码生命周期很短。AI 生成得越快，试错成本越低。

问题出现在系统进入长期演进后。

当项目规模变大，模块开始依赖，数据结构开始稳定，业务规则持续增加，Vibe Coding 的风险会迅速上升。

AI 可能修复一个问题，同时引入新的问题；可能生成能运行的代码，却破坏原有边界；可能用复杂实现解决简单需求；也可能生成难以理解的黑盒逻辑。

更大的风险，是开发者失去对系统的理解。

不理解系统，就无法判断变更影响；无法判断影响，就只能继续依赖 AI 生成更多代码。系统越改越快，人的控制力越来越弱。

因此，Vibe Coding 可以用于探索，不能直接承载长期系统建设。

长期系统需要 Agentic Engineering：AI 可以生成代码，但必须在验证、约束和反馈机制中工作。

软件工程的重心正在转向验证体系

AI 生成代码之后，团队最先遇到的问题不是“产能不够”，而是“验证跟不上”。

过去，一个工程师一天写有限数量的代码，人工审查还能跟上。现在，一个 Agent 可以快速生成多个方案、修改多个文件、提交多个补丁。代码生产速度被放大后，人工逐行检查会成为瓶颈。

验证需要系统化。

它不应只依赖工程师亲自读每一行代码，还要包括测试、类型检查、Linter、静态分析、架构规则、CI 门禁、代码审查和运行时观测。

AI Coding 时代，团队要把更多工程判断沉淀到自动化验证体系里：

测试覆盖关键路径
类型系统捕获结构错误
Linter约束风格和基础规则
结构测试守住架构边界
CI/CD拦截低质量变更
人工审查聚焦高风险判断

验证体系越强，AI 生成越可用。验证体系越薄，AI 生成越容易成为新的技术债来源。

Harness Engineering：让AI在受控环境里工作

Fowler 相关讨论中，最值得放大的概念是 Harness Engineering。

可以用一个公式概括：

Agent = Model + Harness

模型负责推理和生成。Harness 是模型之外的工程环境，包括上下文、约束、工具、检索、测试、审查、门禁和反馈。

没有 Harness，AI 像一个聪明但不了解项目纪律的新成员。它能写很多代码，但不一定知道项目边界、历史约束、团队规范和质量红线。

Harness 的作用，是把工程环境提供给 AI。

它告诉 AI：

哪些目录可以改
哪些 API 不能破坏
项目架构边界在哪里
编码规范是什么
测试如何编写
失败后如何反馈
哪些规则必须通过

到这一层，AI 不再只是代码生成器，而是在工程约束中工作的执行者。

团队能力也随之变化。高级工程师的价值，不只体现在直接写代码，还体现在设计 Harness：让 AI 更少犯错，让错误更容易被发现，让成功路径更容易复用。

改一次代码，只解决一次问题。改进一次 Harness，可能让整个团队和后续 Agent 少犯同类错误。

Guides与Sensors：约束在前，校验在后

Harness 可以拆成两类能力：Guides 和 Sensors。

Guides 是行动前的约束。

系统提示词
AGENTS.md
项目约束文档
编码规范
架构说明
代码模板
目录规则
接口约定

它们让 AI 在开始行动前知道边界。

Sensors 是行动后的校验。

单元测试
集成测试
类型检查
Linter
静态分析
架构规则
代码审查
运行日志
AI代码审查

它们在 AI 生成结果后发现问题，并形成反馈。

成熟的 AI 工程体系需要两类机制同时存在。Guides 提高首次生成质量，Sensors 提供持续纠偏能力。

这里还有一个重要原则：能形式化的规则，优先进入计算型检查。

测试、类型检查、Linter、结构测试这类机制更稳定、更便宜、更可重复。LLM 适合处理语义判断和复杂审查，但不适合承担所有规则判断。

优秀团队会不断把高频错误从“人来提醒”“模型来判断”，下沉为“系统自动检查”。

这就是 AI Coding 时代的工程治理方向。

工程师的新角色：持续改进 AI 工作环境

AI Coding 没有让工程师消失，它改变了工程师的工作位置。

当 AI 反复犯同一类错误时，工程师要追问的不是“这次怎么修”，还要追问“为什么系统没有提前拦住”。

可能是缺少项目说明。

可能是上下文检索不到关键代码。

可能是没有结构测试。

可能是类型约束太弱。

可能是 Linter 规则缺失。

可能是 AGENTS.md 没有写清限制。

这种循环可以称为 Steering Loop：

问题出现

↓

诊断 Harness 缺口

↓

改进 Guide 或 Sensor

↓

减少后续同类问题

传统调试修的是系统缺陷。Steering Loop 修的是 AI 工作环境的缺口。

AI 可以参与这个过程：生成结构测试，提取约束规则，补充项目指南，生成 Linter 草案，分析失败模式。但最终判断仍然属于工程团队。

哪些规则值得固化。
哪些约束应进入 CI。
哪些场景需要人工审查。
哪些错误可以接受。
哪些质量红线必须守住。
这些是工程治理能力。

AI 越深入研发过程，工程师越需要从代码生产者，转向系统约束设计者、验证体系建设者和 AI 工作环境塑造者。

AI放大了工程基本功的差异

AI 改变了编码方式，但没有改变软件工程的核心任务：把业务中的 What，映射到计算系统中的 How。

业务表达目标、规则、流程和约束。代码表达数据结构、函数、接口、状态和执行路径。软件工程的价值，来自在两者之间建立稳定映射。

LLM 可以帮助生成实现，但需求澄清、抽象边界、领域建模、模块拆分、架构约束和长期演进路线，仍然需要工程判断。

一个 Prompt 可以解决一个当下场景，却很难自然形成适应未来变化的结构。长期系统需要清晰命名、稳定模块、明确边界和可验证设计。

在 AI 时代，代码可读性的价值更高。

好的函数名、类型、目录结构、测试名称、模块边界和文档，不只是给人读，也会影响 AI 对代码库的理解。

结构清晰的代码库，会让 AI 更容易生成正确变更。命名混乱、边界模糊、测试缺失的代码库，会让 AI 放大原有问题。

AI 没有降低工程基本功的重要性，它放大了工程基本功的差异。

结语：AI 带来的，是软件工程重心迁移

AI 到底给软件工程带来了什么？

第一层，是代码生成加速。第二层，是非确定性进入研发过程。第三层，是验证、约束、反馈和治理体系的重要性上升。

软件工程没有因为 AI 失效，它正在扩展自己的边界。

过去，工程体系主要约束人写代码。现在，工程体系还要约束 AI 生成代码、调用工具、修改系统和提交结果。

未来高水平研发团队的核心能力，不会只体现在“会不会用 AI 写代码”。

更关键的能力，是能否构建一个让 AI 持续写对代码、少犯重复错误、可被验证、可被审计、可被持续改进的工程环境。