Limin Ge

11

上一章下一章

第 11 章：Convention 与开发规范——让 AI 带着镣铐跳舞

Convention、开发规范的重要性，对于 AI-Native 团队的重要性，只会更高，因为它们是延缓熵增最好的手段。项目起步时一定要尽可能地设计好尽可能多地束缚。让 AI 带着镣铐跳舞。

Cover Image for 第 11 章：Convention 与开发规范——让 AI 带着镣铐跳舞

"Convention、开发规范的重要性，对于 AI-Native 团队的重要性，只会更高，因为它们是延缓熵增最好的手段。项目起步时一定要尽可能地设计好尽可能多地束缚。让 AI 带着镣铐跳舞。"

延伸阅读：为什么规范对小团队尤其关键，参见AI-Native 小团队的结构性优势。规范如何与 AI-Native 工作流集成，参见AI-Native 工作流：Plan–Act、Test–Code、Doc–Code–Doc。

1. 为什么 Convention 在 AI-Native 时代更重要

在传统软件工程里，convention 和开发规范已经很重要了，但在 AI-Native 的背景下，它们的重要性会进一步提升。

原因在于：

  • AI 写代码的速度太快了
    如果没有任何约束，AI 会在很短的时间里产生大量风格不一致、结构不统一的代码。
    人脑根本 review 不过来，更不要说长期维护了。

  • AI 本身是“无状态”的
    每一次新的 AI session 都是“新来的团队成员”，它不会自动记住你上次定的那些约定。
    只有把这些约定显式地写进代码库、写进 prompt、写进测试框架，AI 才能持续遵守。

  • 熵增的速度被放大了
    代码量增长越快，如果没有强约束，系统混乱度上升的速度也会越快。
    Convention 是延缓熵增最直接、最有效的手段。

2. 项目起步时就要设计尽可能多的束缚

一个常见的误区是：

"我们先快速开发，等代码多了再定规范。"

在 AI-Native 团队里，这个思路是行不通的。原因在于：

  • AI 的产能太高，等你“觉得该定规范了”的时候，代码库可能已经大到“定规范的成本比推倒重来还高”
  • AI 会参考已有的代码风格，如果早期代码就是混乱的，后续 AI 生成的代码也会延续这种混乱

正确的做法是：

项目起步时，就要尽可能多地设计好约束。

这些约束包括：

  1. 代码风格和命名约定

    • 函数命名、变量命名、文件组织方式
    • 让 AI 在写代码时，参考已有的、符合约定的代码

  2. 测试框架和测试 convention

    • 测试文件的组织方式、测试用例的写法
    • 这样 AI 在生成新测试时，会自动参考已有的测试模式

  3. 架构边界和模块职责

    • 哪些代码应该放在哪里、哪些模块之间不能直接调用
    • 通过文档和代码结构，让 AI 理解这些边界

  4. 文档和代码的同步规则

    • 什么时候该写文档、文档应该写什么、什么时候该删文档
    • 避免 AI 生成大量过程性、历史性的文档垃圾

3. Convention 如何“延缓熵增”

熵增的本质是：系统会自发地变得更混乱、更无序。

在代码库里，熵增的表现是：

  • 代码风格越来越不一致
  • 模块边界越来越模糊
  • 测试覆盖率越来越低
  • 文档和代码越来越不同步

Convention 通过以下方式延缓熵增：

  1. 给 AI 一个“标准答案”
    当 AI 不知道该怎么写的时候，它会参考已有的、符合约定的代码。
    如果这些“参考代码”本身就是规范的，AI 生成的代码也会更规范。

  2. 减少“自由发挥”的空间
    约束越多，AI 能“乱写”的地方就越少。
    虽然听起来有点“限制创造力”，但在 AI-Native 时代，可控性比灵活性更重要。

  3. 让 review 变得更简单
    如果所有代码都遵循同一套约定，人类 reviewer 只需要关注“逻辑对不对”，而不需要花大量时间纠正风格问题。

The same garden with and without fence rails

4. 实际落地建议

在一个两人小团队、强依赖 AI 的前提下，可以这样落地 convention：

  1. 在项目最开始，花 1–5 天定好基础约定

    • 代码风格（ESLint/Prettier 配置）
    • 测试框架和测试组织方式
    • 文档的 scope 和格式

  2. 把这些约定写进 prompt 和 cursor rules

    • 让 AI 在每次写代码时，都能“看到”这些约定
    • 定期 review 这些规则，确保它们和实际代码库保持一致

  3. 用测试和 lint 工具强制执行

    • 不符合约定的代码，直接 fail CI
    • 不要指望“人肉 review 来纠正”，人脑根本 review 不过来

  4. 定期回顾和更新约定

    • 如果发现某个约定在实际使用中“总是被违反”，可能是约定本身有问题，需要调整
    • 但调整要非常谨慎，因为每一次调整，都可能让 AI 产生一批不符合新约定的代码

5. 小结

在 AI-Native 时代，convention 和开发规范不再是“nice to have”，而是“must have”。

让 AI 带着镣铐跳舞，这些镣铐就是你的 convention。
没有镣铐，AI 会跳得很快，但也会跳得很乱，最终整个系统会失控。
有了镣铐，AI 虽然不能“自由发挥”，但能持续产出可控、可维护的代码。

项目起步时，花时间设计好这些“镣铐”，是 AI-Native 团队最重要的投资之一。