第 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 只需要关注“逻辑对不对”，而不需要花大量时间纠正风格问题。

4. 实际落地建议

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

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

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

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