AI-Native 软件工程(8):Verify Layer——AI 生成的代码为什么必须被验证
上一篇写 Planner 的时候我用了一个比喻：Intent 是方向盘，Planner 是导航，Verify 是刹车。
很多人在用 AI 写代码的时候，心里有一个隐含假设：AI 生成的代码，大概率是对的。
这个假设在简单任务上确实成立。写一个排序函数、写一个正则表达式、写一个 React 组件——这类任务 AI 的正确率可以到 90% 以上。用过 Copilot 的人都有这个体感：大部分时候 Tab 一按就能用。
我自己踩过一个坑。让 AI 给一个已有的 API 加一个字段，需求很简单。AI 很快给了代码，看起来完全正确。我 review 了一下，没问题，合了。
上线后发现：新字段在老数据上会返回 null，而前端对这个字段的处理逻辑里没有做 null check。页面直接白屏了。
AI 犯了错吗？严格来说没有。它做的事情——加一个字段——完全正确。但它没有考虑老数据的兼容性，因为我的 Intent 里也没提这件事。它也不知道前端代码对这个字段有强依赖，因为那段前端代码不在它的上下文里。
这就是问题本质：AI 输出只是候选答案，不是最终答案。
传统软件工程里，代码质量靠两道防线：工程师自己的经验，加上 code review。
第一，AI 生成代码的速度远超人类 review 的速度。以前一天写 200 行代码，review 起来还算轻松。现在 AI 一天可以生成 2000 行，你还有精力逐行 review 吗？即使你看了，在 2000 行里发现一个隐藏的兼容性问题，概率有多大？
第二，AI 生成的代码长得像”正确的代码”。语法无误、结构清晰、甚至还有注释。它不像新手写的代码——一眼就能看出问题。AI 的错误往往藏在语义层面：逻辑对了但边界没处理，接口对了但数据类型有微妙差异，功能对了但和现有系统有冲突。
所以 Verify 层不是可选项。在 AI-Native 工程里，它是必需品。
第一层：语法和类型。代码能不能编译通过，类型系统有没有报错。这是最基础的，也是最容易自动化的。TypeScript 的 tsc、Go 的 go vet、Rust 的 cargo check——跑一遍就行。这层过不了的代码，连进入下一步的资格都没有。
第二层：逻辑验证。代码能编译，但逻辑对不对？这就需要测试。单元测试验证单个函数的行为，集成测试验证模块之间的协作，端到端测试验证完整的用户流程。AI 生成代码的同时应该生成对应的测试，或者由专门的 Test Skill 基于实现代码生成测试。
第三层：规范检查。代码逻辑对了，但符不符合项目的规范？lint 规则有没有违反？代码风格是不是一致？命名有没有遵循约定？安全规则有没有触犯——比如 SQL 拼接、未转义的用户输入、硬编码的密钥？这些看起来是小事，但在生产系统里每一个都可能是定时炸弹。
第四层：系统兼容性。这段代码在隔离环境里完全正确，但放进现有系统会不会出问题？有没有破坏已有的测试？有没有引入不兼容的 API 变更？有没有和其他模块的数据契约冲突？这层最难自动化，但也最重要——因为 AI 生成代码时通常只看到局部上下文，看不到全局。
四层验证，由浅到深。每一层都是一张安全网。AI 生成的代码要通过所有四层，才有资格进入 Delivery 环节。
这里有一个关键设计决策：Verify 不是最后做一次，而是每一步都做。
很多团队的做法是：AI 生成所有代码 → 最后跑一次测试 → 没过就全部重来。
这个策略在小任务上可以接受，但在复杂任务上是灾难。如果 Planner 拆了 8 个子任务，你在第 8 个任务完成后才验证，发现第 3 个任务的输出就有问题——那第 4 到第 8 个任务全白做了。
正确的做法是：每个子任务完成后立即验证。过了才进入下一步，没过就立即重试。这样问题被限制在局部，不会污染后续步骤。
这也是为什么 Planner 和 Verify 必须配合。Planner 拆出细粒度的子任务，Verify 在每个子任务的出口设卡。两者结合，形成一个”步步为营”的推进策略。
验证没过怎么办？最简单的做法是把错误信息反馈给 AI，让它修。
但这个”反馈”的质量很关键。你把一个 test failure 的完整报错扔给 AI，和你只告诉它”测试没过”——效果完全不同。好的 Retry 机制应该包含：
每一轮 Retry 都是一个 Generate → Run → Verify 的小循环。循环次数应该有上限——我一般设 3 次。超过 3 次还没修好，说明问题可能不在代码层面，需要人介入检查 Intent 或 Plan 是否有误。
没有 Verify 的工作流：AI 生成代码 → 人 review → 发现问题 → 人改或者让 AI 改 → 人再 review → 反复几轮 → 合进去 → 上线后可能还有问题。
有 Verify 的工作流：AI 生成代码 → 自动跑测试、类型检查、lint、兼容性校验 → 没过自动 Retry → 过了自动进入 Delivery → 人只审核最终结果。
前者的人力消耗随代码量线性增长。后者的人力消耗几乎是常量。
当你的 AI 系统每天产出的代码量从几百行增长到几千行、几万行的时候，这个差距会变成天壤之别。
Verify 不只是质量保障。它还是 AI 系统获得信任的唯一路径。
人类之所以不敢把 AI 生成的代码直接推上生产，不是因为 AI 真的那么差，而是因为没有系统化的方式来证明”这段代码确实可以用”。
当你有一套完整的 Verify 体系——类型检查通过、测试全绿、lint 无警告、兼容性校验 OK——你就有了底气。不是盲目信任 AI，而是系统地验证了 AI 的输出。
当 Intent、Planner、Execution、Verify 这些层全部就位之后，一个新的东西开始浮现——我把它叫做 AI DevOS。
它不是一个工具，不是一个框架，甚至不是一个产品。它是软件工程进入 AI 时代之后，必然会出现的一套新基础设施。
夜雨聆风
