摘要 AI 编码助手能以惊人速度生成代码，但逐行审查的速度完全无法匹配。本文提出一套策略框架：重新定义人机分工，建立”审文档→写代码→审代码→更新文档”的协作循环，将质量保证从”审查实现细节”升维为”审查规则与验证覆盖”。

一、困境：我们为何无法继续用旧地图导航

全栈项目天生跨越多个层次：前端交互、后端逻辑、数据库、缓存、部署。复杂度呈指数级增长，而 AI 偏偏擅长在单点上快速产出大量代码。当我们把整个功能扔给 AI，它很可能会：

  • 写出功能看似正常、但状态机缺失的订单流转逻辑；
  • 在处理支付回调时忘记幂等，或吞掉关键异常；
  • 生成无法维护的”意大利面条式”代码，因为没有人给它划定结构。

而如果我们试图逐行理解并审查这些代码，我们很快就会陷入疲劳——用人类的阅读速度去追赶机器的生成速度，注定失败。于是，我们需要一套新的协作范式：一种既不用事必躬亲，又能牢牢守住质量底线的工作方法。

二、基石：重新定义人机分工

这不是简单的”AI写代码，人审代码”，而是基于认知优势的重新分配。

人负责”定义与判定”——回答”什么是对的”。 AI 负责”生成与填充”——完成”把它做出来”。

这一原则可以细化到全栈开发的各个层面：

层面人的核心职责AI 的核心职责
架构与设计技术选型、服务拆分、接口契约、数据模型、关键约束方案比较、生成样板代码、发现设计漏洞
需求细化将模糊需求转化为可验证的验收条件，明确边界与异常场景自动生成验收条件草稿、边界值列表
编码实现决定核心算法、并发模型、状态机；审查关键路径在既定契约和约束下，生成具体实现
测试策略定义测试策略，审核关键用例，确认边界覆盖批量生成测试代码，执行并报告
性能与安全定义性能基线和安全策略，最终决策缓存/索引等架构取舍集成性能分析，生成合规代码模板

记住这个口诀：你是船长，定义目的地和航线规则；AI 是轮机舱，提供动力并执行航行指令。

三、细节掌控：从”知道全部细节”到”按图索骥”

你不需要知道 AI 生成的每一行代码在做什么，但必须拥有一份能随时定位问题的”认知地图”。这需要三件东西：

1. 清晰的架构蓝图（你画的）

你必须能随时回答：一个请求从入口到数据库经过了哪些层？哪些模块有状态，哪些是纯函数？数据一致性的边界在哪里？这张图不需要精确到类名，但要足以让你在 AI 偏离时立刻感觉到”味道不对”。

2. 可执行的规格书（Spec）

在让 AI 写任何代码之前，先花时间共同拟定一份规格书——核心功能（涉及状态机、并发、外部集成）可投入 20-30% 的开发时间，简单 CRUD 功能降到 10% 即可。比例本身不重要，重要的是”先想清楚再动手”这个动作。规格书包含：

  • 接口契约：路径、方法、请求体/响应体结构、错误码。
  • 显式边界条件（这是你关注的焦点）：
    • 数值范围、字符串长度、空值处理；
    • 并发冲突处理（如乐观锁重试策略）；
    • 外部依赖的超时、熔断与降级；
    • 权限边界（不同角色能看到哪些字段）。
  • 非功能性要求：目标 QPS、p99 延迟、安全合规。

然后，让 AI 先用自己的话复述一遍它理解的需求，确认无误后再开始生成。这一步能消灭掉大部分理解偏差。

3. 可审查的”局部放大镜”

当你怀疑某个模块时，不必阅读全部代码，只需对 AI 下达精确指令：

“解释这个支付回调处理器在收到重复通知、金额不一致和签名失败时分别做了什么。” “为这个函数生成覆盖所有边界值的单元测试，包括 null、空字符串、超大数值、负数。”

你审查的不再是代码，而是 AI 对业务逻辑的认知。与你的蓝图吻合，即通过；否则调整。

四、边界准确性的四重保障

边界条件是全栈项目中最容易出错、也最难以手工验证的部分。我们将它从代码细节中抽离，变成可自动验证的层层关卡：

第一重：编译时防御

  • 尽可能使用 TypeScript、Rust、Java 等强类型语言，类型定义本身就是第一道防线。
  • 在关键函数入口使用断言库或校验框架，让非法输入直接倒在开发阶段。

以 Java 为例：使用 Jakarta Bean Validation（如 @NotNull、@Size、@Pattern）进行声明式校验，要求 AI 生成代码时强制加入校验——“所有 Controller 请求参数都必须经过 @Valid 校验，否则不允许提交。“

第二重：测试即契约

颠覆传统流程：

  1. 人给出规格书和边界清单；
  2. AI 生成接口契约（方法签名 + 输入输出类型，无实现）；
  3. AI 基于契约生成测试代码（此时测试编译失败，因为实现不存在）；
  4. 人审核测试用例是否真的体现了所有边界——审测试用例的认知负担远低于审实现代码：你只需要判断”这个边界有没有被测到”，而不需要追踪实现里的每一层调用链。审核时只需问三个问题：
    • 规格书里列出的每个边界值，是否都有对应的测试用例？
    • 异常路径（超时、空值、重复请求）是否有测试？
    • 正常路径的测试是否覆盖了所有分支？
  5. AI 生成实现代码，直到全部测试通过；
  6. 人检查测试覆盖率报告，补漏。 此时，信任的基座已经改变：只要测试是你审核通过的，且测试全部绿灯，那么边界安全就已经得到证明。你不再需要逐行寻找实现中的 if-else。

这套流程在实践中需要注意三个问题：① AI 生成的接口定义本身可能有遗漏，人审接口契约时要重点关注类型和字段完整性；② AI 生成的测试代码可能有语法或逻辑错误，可以先让 AI 生成测试框架，人确认结构后再填充具体用例；③ 如果测试本身有 bug，AI 可能生成”通过测试但逻辑错误”的实现，因此测试全部通过后，建议人工走查一条关键路径作为冒烟验证。

这套流程最适合新功能开发。对于存量代码改造，可以降级使用：先让 AI 为待修改的模块生成测试（基于当前行为），人审核确认这些测试反映了现有行为后，再让 AI 重构实现，确保所有存量测试仍然通过。本质不变——你审的始终是测试，不是实现。

第三重：集成契约验证

前后端之间、微服务之间，让 AI 帮助你维护消费者驱动的契约测试（如 Pact）。一旦一方的返回字段、类型或错误码发生变更，测试立即报警。边界遗漏问题会在集成层被快速捕获。

第四重：自动化静态分析

前三重都是正向验证——检查”代码应该做什么”。但 AI 生成的代码中可能存在死代码、资源泄漏、不安全的第三方依赖、硬编码密钥等问题，这些不会被测试覆盖到。在 AI 生成代码后自动运行 linter、静态分析工具、安全扫描，作为负向验证防线。

五、核心引擎：文档与代码的协作循环

第四节回答了”边界怎么守住”——那是静态的防线。但全栈开发不是一次性工程，文档和代码会持续演化。本节回答一个更关键的问题：文档和代码之间，怎么形成互相推动的闭环？

文档不是写完就扔的产物，而是和代码一起持续进化的活体。这个循环由四个环节组成：

环节 1：审文档（让 AI 帮你审 Spec）

在让 AI 写任何代码之前，先把文档交给 AI 审查。不是让你自己反复检查，而是让 AI 做第一轮扫描。注意，AI 审查自己参与生成的文档可能存在自我确认偏差，可以用三个技巧规避：

  • 开启新会话，不要让 AI 带着生成文档的上下文来审查它；
  • 换一个模型来审查，比如用 Claude 生成的文档让 GPT 审；
  • 让 AI 生成反例，不直接问”有没有问题”，而是问”根据这份规格书，列出所有可能被攻破的边界”。

审查时让 AI 逐条对照规格书中的边界条件清单检查，而不是笼统地提问。例如：

“逐条检查这份规格书中的边界条件：每个数值范围是否有对应的校验规则？每个异常场景是否有明确的处理策略？接口定义之间是否存在矛盾？”

AI 擅长从大量文本中找出不一致的地方——比如 Spec 里写了”订单超时自动取消”，但状态机里却没有”超时”这个触发条件。文档的 bug 比代码的 bug 修复成本低得多，先审文档再写代码。

这一步是”写代码前审文档”——发现文档问题后直接修改文档，确保进入编码环节的规格书是干净的。

环节 2：写代码（文档驱动生成）

AI 根据经过审查的文档生成代码。关键在于强制引用文档，而不是凭空生成：

“根据 docs/order-state-machine.md 中的状态流转规则实现 OrderService，严格按照 Spec 中的接口契约生成代码。”

把 Spec 拆成机器可读的片段（如 OpenAPI、数据库 DDL、状态机描述），AI 直接消费这些片段。文档更新了，代码就应该跟着变——而不是代码写完之后，文档就过时了。

环节 3：审代码（人只审高风险点）

第三节说的是”不需要逐行阅读全部代码”，但高风险模块需要深入审查。两者的关系是：用架构蓝图快速定位高风险模块，只对这些模块做深度审查，其余模块靠测试覆盖来保证。 你不是不读代码，而是不再无差别地读所有代码。

代码生成后，聚焦四个高风险点：

  1. 接口契约一致性：返回字段、类型、错误码是否与 Spec 一致？
  2. 核心逻辑正确性：状态流转、计算逻辑、业务规则是否正确？
  3. 异常处理：外部调用失败时，是重试、降级还是快速失败？是否吞掉了关键异常？
  4. 数据安全与一致性：并发场景下是否有竞态条件？事务边界是否正确？是否存在注入、越权、敏感信息泄露？

除了这四个高风险点，还有一些问题靠人工审查很难发现——你不知道你不知道什么。这部分需要靠自动化工具来覆盖，即第四节第四重提到的静态分析和安全扫描。

审查时发现的问题，区分两种情况处理：

  • 设计层面的问题（接口定义不合理、边界遗漏、状态流转缺失）：先记录下来，作为下一环节更新文档的输入，再让 AI 根据更新后的文档重新生成。
  • 实现层面的 bug（空指针、SQL 注入、资源泄漏）：直接让 AI 修复，不需要先走一轮文档更新。

环节 4：更新文档（代码反哺文档）

环节 1 是”写代码前审文档”——在编码前确保规格书是干净的。而这一步是”写代码后反哺文档”——根据实际实现中暴露的问题，反向更新规格书，让文档反映代码的真实行为。

“根据 OrderService.java 的实际实现，更新 docs/order-api-spec.md：补充实现中处理的异常场景，修正与实际不一致的描述。”

“对比测试覆盖率和规格书中的边界清单，找出规格书中遗漏的边界并补充。”

这一步经常被忽略，但它恰恰是循环能持续转动的关键——如果文档不跟着代码更新，下一轮循环的”审文档”就会基于过时的信息，整个闭环就断了。

循环的节奏

审文档 → 写代码 → 审代码 → 更新文档 → 审文档 → ...

每一轮循环，文档和代码都更接近真实——前提是每一轮审代码发现的问题都如实反哺到文档中。这不是一次性流程，而是日常开发的呼吸节奏。你会发现，随着循环的推进，文档越来越精确，代码越来越可预测，你需要”救火”的次数越来越少。

六、植入习惯：让 AI 带着你的”基因”工作

“基因”的本质是可遗传、可复用的经验。本节回答一个问题：怎么把你在开发中积累的经验，变成 AI 可以持续消费的”基因”，并在项目之间传递？

1. 经验沉淀：把踩过的坑变成 AI 的规则

每次审代码发现问题，不要只修代码——提炼成一条规则。比如：

  • “支付回调必须做幂等处理，使用唯一流水号去重”
  • “状态流转禁止跳步，必须经过中间态”
  • “所有外部调用必须设置超时，禁止无限等待”

这些规则写入项目的规则文件（如 CLAUDE.md、.cursorrules、TRAE 配置文件），AI 每次生成代码时都会自动遵循。新项目初始化时，直接复用这份规则文件——你过去踩过的坑，不会再踩第二次。随着项目推进，规则文件越来越厚，AI 的”基因”越来越强。

2. 任务拆分：永远不要给 AI 一个模糊的大任务

这是最容易犯的错误。反例和正例的对比：

  • ❌ “帮我写一个订单服务”
  • ✅ “根据 docs/order-spec.md 实现 OrderService.create() 方法，遵循项目规则文件中的异常处理规范，接口契约参考 docs/order-api.yaml”

每个任务必须明确三件事：输入（什么文档/接口）、约束（什么规则）、输出（什么产物）。任务越精确，AI 的输出越可控。

3. 规则文件是活文档，不是写完就锁的

每个迭代结束后，花十分钟回顾规则文件：

  • 哪些规则被频繁触发？说明它们真的重要，保留。
  • 哪些规则从未被引用？说明它们可能已经过时，考虑删除。
  • 这个迭代有没有发现新的坑？补充进去。

另外，规则文件需要控制规模。当规则超过 50 条时，AI 的上下文窗口会被挤占，反而影响生成质量。建议每两个迭代做一次规则清理：合并重复规则、删除已过时的、按优先级排序。规则文件的质量比数量重要。

这其实就是第五节”更新文档”在规则层面的落地——规则文件和代码一样，需要跟着项目一起进化。

七、从今天开始

回顾前面的内容，我们其实只说了一件事：在让 AI 写代码之前，先花几分钟想清楚”你要什么”和”什么是对的”。

第二节定义了人做什么、AI 做什么；第三节给了你认知工具——架构蓝图、规格书、局部放大镜；第四节建了四道质量防线；第五节让文档和代码形成互相推动的闭环；第六节让你踩过的坑变成可复用的规则。这些不是六个独立的方法，而是一套完整的工作方式——它的核心只有一个：把精力从”写代码”转移到”定义什么是正确的代码”上。

你可能会担心：每次都要写 Spec、审文档、更新文档，会不会太慢？实际上，你花在 Spec 和审文档上的每一分钟，都会省掉后期十倍的排查和返工。一个没有经过审查的 AI 生成模块，看起来五分钟就写完了，但后续排查状态机 bug、修补遗漏的边界条件、处理异常吞没引发的生产事故，可能要花你整整一个下午。前慢后快，才是真正的快。 而且这套方法的投入是递减的——随着规则文件的积累，新项目的初始化成本越来越低。

什么时候不用这套方法

这套流程最适合核心业务逻辑、安全敏感场景、涉及状态机和并发的功能。对于以下场景，可以简化或跳过：

  • 原型验证：快速验证想法时，直接让 AI 生成代码，不需要写 Spec
  • 一次性脚本：用完即弃的工具脚本，不需要文档和测试
  • 个人小工具：只有你自己用的功能，信任成本低，不需要完整流程

知道什么时候不用，比知道什么时候用更难。关键判断标准是：如果这个功能出错了，后果是什么？ 后果越严重，越值得投入完整流程。

从下一个任务开始

不需要一步到位。从你手头下一个任务开始，只做三件事：

  1. 写代码之前，先用几行文字描述你要什么、边界条件是什么；
  2. 让 AI 复述一遍，确认理解一致；
  3. 代码生成后，只审四个高风险点：接口契约一致性、核心逻辑正确性、异常处理、数据安全与一致性。

仅此而已。剩下的——规格书的模板、规则文件的积累、文档与代码的协作循环——会随着你踩的坑越来越多，自然而然地生长出来。

写作说明

本文由揉光入野、GLM 和 DeepSeek 共同完成。最初是作者与 AI 关于 AI 协作开发的讨论，整理成文后，经历多轮质疑与矫正——人和 AI 轮番上阵，从实操可行性和文章逻辑两个维度反复审查，才最终定稿。作者本人也在持续学习和实践文中所述策略，这篇文章本身即是人机协作的一次尝试。