Martin Fowler 在谈到 AI 对软件工程的影响时，给过一个很重的判断：这是他职业生涯中最重要的变革。这个判断容易被理解成对 AI 写代码能力的肯定。但更关键的变化，其实发生在软件工程的底层假设上。过去的软件工程长期建立在确定性之上。相同输入应得到相同输出，Bug 可以复现，测试结果应当稳定，构建过程可以追踪。编译器、测试、类型系统、CI/CD、代码审查，都是围绕这种确定性建立起来的。LLM 把非确定性引入了编码过程。同样的 Prompt，可能生成不同代码；同一个 Agent，在不同上下文下可能选择不同路径；同一个需求描述，可能被模型解释成多个实现方案。AI 提高了代码生成速度，也把质量波动、路径漂移和验证压力带进了研发现场。所以，AI 给软件工程带来的变化，表层是代码生成加速，深层是验证体系重建。真正的问题已经不只是“AI 能不能写代码”。更重要的是：团队能不能判断这些代码是否正确，能不能约束 AI 少犯错，能不能让错误被系统发现，能不能把一次纠偏沉淀成后续能力。
AI写代码越快，工程约束越重要
AI 已经可以生成代码、补测试、解释报错、改造旧代码、搭建原型。这些能力会显著提高开发速度。但软件工程关心的不只是“写出来”。产品代码需要维护、扩展、调试、回滚、审查和交接。企业系统还要面对安全、权限、性能、合规、可观测和架构一致性。AI 生成速度越快，工程约束越重要。缺少约束时，代码会快速增长，系统理解却不断下降。功能交付看起来更快，架构边界可能更模糊。Bug 修复看起来更高效，新问题也会同步增加。这正是 Fowler 反复强调的风险：AI 可以降低实验门槛，但团队不能绕过软件开发中的学习循环。编程的学习循环，是“想法—代码—反馈—修正”的持续过程。开发者在这个过程中理解系统结构、边界和变化影响。人如果不读代码、不理解代码、不验证代码，只接受 AI 生成结果，长期系统很容易变成黑盒。AI 可以参与实现，系统理解不能丢。
到这一层，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 持续写对代码、少犯重复错误、可被验证、可被审计、可被持续改进的工程环境。
夜雨聆风
