AI 原生时代的软件工程：从「写代码」到「约束代码」

AI 已经把「写代码」变成一件低门槛、高吞吐的事。过去团队比的是谁写得更快，今天真正拉开差距的，是谁能让系统在 AI 高强度参与下依然稳定、可控、可演进。

这意味着软件工程的重心变了。瓶颈不再是语法实现，也不再是人肉敲键盘的速度，而是架构意图是否清晰、系统边界是否刚性、反馈回路是否够快、重构是否有纪律。缺了这些约束，AI 带来的不是研发提效，而是系统膨胀、逻辑漂移、测试污染和技术债失控——它能在几分钟内生成几千行代码，也能在几分钟内把一个系统推向不可维护。

所以人类开发者的角色必须升级：从「微观代码实现者」变成「宏观系统设计师」，核心任务只有一个——用确定性的工程围栏，约束 AI 近乎无限的代码生成能力。这套围栏可以归结为五件事。

一、别再迷信覆盖率，要追的是行为对齐

用测试覆盖率衡量工程质量，这个指标在 AI 时代已经开始失效。原因很简单：AI 太擅长刷指标了。

你让它把覆盖率从 80% 拉到 100%，它会非常配合地生成大量测试，把各种边缘分支、低价值异常、几乎不可能出现的错误路径全部补齐。报表很好看，代码库却更臃肿，测试更嘈杂，团队反而更难分辨哪些才是真正重要的行为约束。最典型的浪费，是 AI 会认真地为「随机数生成器损坏」这类几乎没有调试价值的底层异常写测试——测试文件越来越厚，真正该关注的业务边界、架构契约和安全问题被淹没在里面。

替代目标是行为对齐：建立一个可执行的「行为神谕」（oracle），让它来定义什么叫正确。

重构已有系统时，最可靠的神谕不是文档，而是真实系统本身。围绕真实外部依赖建立高频行为回归测试，把关键行为边界锁死——比如对着一个 S3 兼容系统跑上千个高频行为测试，确保重构前后行为完全一致。

开发新系统时，先写一个单线程、性能很差、但逻辑绝对简单正确的「玩具版本」。它不需要快，也不需要优雅，它唯一的任务是定义正确行为。之后无论怎么做并发优化、架构升级、模块拆分，都必须持续对齐这个最初的神谕。

本质上是一句话：不要让文档定义系统，要让可执行的行为定义系统。文档会过时、会有歧义、会遗漏细节，能跑起来的行为测试不会。

二、能交给类型系统的问题，不要留到运行时

代码量暴增之后，运行时问题会被放大，尤其是权限、状态流转和并发安全。这类问题最麻烦的地方在于，它们通常不是「功能错了」，而是「在极少数时刻、极复杂的上下文里错了」——比如经典的 TOCTOU：检查时是安全的，真正执行时条件已经变了。靠运行时测试兜这种问题，成本高，覆盖还不完整。

更有效的思路不是继续堆测试，而是把安全约束直接做成类型约束。

比如在 Rust 里定义一个业务上不可伪造的 AuthorizedRequest 类型，然后把所有核心底层 API 的入参统一收紧：只接受这个类型，不接受普通请求对象。任何未经授权的调用根本进不了函数边界，编译阶段就被拦下。

这和「加一堆 if 做权限校验」不是一回事。前者是物理隔离，后者是逻辑提醒；前者由编译器强制执行，后者依赖人和 AI 每次都别忘记写对。差别非常大。关键路径一旦由类型系统承载，很多运行时安全测试就不必反复写、反复维护，很多漏洞根本没有进入系统的机会。

这套方法在强静态类型语言里杠杆最大，Rust 效果最强，Go 和严格模式下的 TypeScript 也能发挥很大作用。动态语言做不到同等级的约束，只能靠更多运行时断言和测试去补。

三、零闪烁，以及 2 分钟的反馈回路

AI 协作开发效率高有个前提：反馈必须极快，结果必须稳定。一旦测试系统开始闪烁（flaky），AI 会迅速学坏。

这不是因为模型「偷懒」，而是它的训练数据里充满了人类长期形成的坏习惯：测试偶尔失败没关系，多跑一次；断言不稳，改松一点；结果不一致，先跳过再说。AI 会天然继承这套模式，并且放大它。

所以团队必须立一条硬规则：零闪烁。任何不稳定的测试都不能留在主干。因为一旦允许「偶尔失败」，AI 和人都会逐步失去对反馈系统的信任，最后大家开始凭感觉改代码，而不是基于确定性信号做决策。

配套的第二条规则，是把完整测试回路压到 2 分钟以内。这是一条很实用的分界线：能在 2 分钟内跑完全量测试，开发者和 AI 就能维持高频试错、快速修复、持续重构的节奏，一晚上能跑很多轮实验，能快速定位偶发竞态。要是测试得跑十几二十分钟，整个工程行为就会变形——提交频率下降，AI 验证次数减少，问题更晚暴露，定位成本迅速上升。

很多团队嘴上重视测试，实际的测试体系慢得根本支撑不了工程节奏。这种系统在 AI 时代崩得更快，因为 AI 输出太快，慢反馈接不住。

守住 2 分钟红线，就必须做强隔离：外部慢 IO 能 mock 就 mock，网络依赖能替换就替换，数据库能本地化就本地化。测试不是越贴近生产越好——它首先要足够快、足够稳，才能承担约束 AI 的任务。

四、没有可读轨迹，AI 调试只会变成盲改

一个已经被普遍感受到的现象：AI 写代码很快，改 Bug 也很快，但一遇到并发问题、偶发异常、复杂链路问题，质量就明显下降。

核心原因不是 AI 不会分析，而是输入太差。你只给它一句「这里偶尔报错」，或者一段模糊的错误日志，它没有足够的运行事实，就只能猜。猜的结果往往是开始修改一堆看起来相关、实际并不关键的代码，Bug 没修掉，反而引入新的技术债。

这类问题换个提示词是解决不了的，只能靠工程手段：尽早建立一套轻量级的 Trace 机制。

不是那种庞大昂贵、只有线上生产系统才用得起的观测平台，而是开发期就能用、能快速捕捉关键事件链路的诊断工具。它至少要能记录关键事件、时间戳、状态变化、锁竞争和请求流转路径。

rare failure 一旦出现，你交给 AI 的就不再是「报错描述」，而是一条完整的运行轨迹。有了轨迹，AI 的行为会完全不同：它不需要猜哪里可能有问题，而是沿着具体事件链去推断——哪个状态先发生、哪个锁拿晚了、哪一步没有同步、哪次重试把系统推到了错误状态。调试从黑盒碰运气，变成沿着物理足迹做推理。在这个场景下，AI 的定位效率确实可以远超人工，前提只有一个：轨迹得先准备好。

Trace 本身也要克制。采集开销过重会反过来污染系统行为，尤其在性能测试和高并发测试阶段。原则很明确：够用即可，只记录能支撑因果推断的最小信息集。

五、大规模重构会变成日常，但行为边界不能破

代码生成成本被打到极低之后，重构不再是季度工程，而会变成高频动作。

以前很多团队不敢动大重构，不是因为不知道问题在哪，而是改不起、测不起、回归不起。AI 介入后这三件事的成本都下降了。只要行为边界已经锁定，过去不敢碰的地方现在可以快速拆、快速换、快速验证。

于是会出现一个很现实的新常态：单周增删十几万行代码、把数万行的单体文件拆成模块、替换整层抽象、统一接口边界，这些都会越来越常见。人类负责定义方向、约束边界和验收标准，AI 负责高吞吐执行。

这不是冒险，前提是有纪律，而这个纪律只有一句话：可以大改结构，不能破坏行为神谕。只要行为测试没有退化、核心契约没有被打穿，大规模重构就是健康演化；反过来，没有神谕托底的 AI 驱动大重构极容易失控——看起来改得飞快，实际上系统已经悄悄偏离了原本正确的逻辑。

在这个基础上，AI 还能补上一层静态审计能力。它非常适合做合并请求级别的结构化审查，尤其擅长发现人类 review 里反复出现的盲区：边界校验遗漏、权限路径不一致、危险默认值、错误传播不完整、资源释放不对称。它未必能替代资深工程师的判断，但足够胜任第一层高频安全筛查，能提前抓出相当比例的真实问题，减少大量后置返工。

核心已经从「写代码」变成「约束代码」

AI 不会自动带来稳定性，它只会放大现有工程体系的真实水平。系统边界清晰，它就放大效率；工程纪律松散，它就放大混乱。

所以 AI 原生时代的软件工程，不该继续围绕「怎么写更多代码」展开，而该围绕「怎么让更多代码仍然可控」展开。方法并不复杂，但都很硬：

• 用可执行的行为神谕，替代好看但失真的覆盖率数字；
• 用静态类型做物理隔离，把安全约束前移到编译期；
• 用零闪烁纪律和 2 分钟反馈回路，保证 AI 始终工作在高质量闭环里；
• 用轻量 Trace 让调试建立在运行事实之上，而不是猜测之上；
• 用高频重构持续清理系统，但任何改动都不能突破行为边界。

这背后是一个更深的判断：AI 时代的软件稳定性，不是靠更聪明的提示词换来的，而是靠更硬的系统约束做出来的。谁先建立这套约束，谁才真正接得住 AI 带来的研发吞吐量；谁还停留在「让 AI 多写点代码」的层面，谁就会更快被系统复杂性反噬。

白泽明理做的正是这件事：把围栏设计清楚——行为边界、类型契约、反馈回路、诊断轨迹、重构纪律，让 AI 的吞吐量落在可控的结构里，而不是变成下一轮技术债。