规约驱动AI编程：提升协作效率的关键实践

1. 为什么我们需要规约驱动的AI编程工作流

在AI辅助编程的实践中，最令人头疼的不是代码写不出来，而是每次与AI的协作都像在开盲盒。上周明明调试好的提示词，这周用同样的输入却得到完全不同的输出；昨天还清晰的功能边界，今天AI就开始"自由发挥"添加额外功能。这种不可复现的对齐问题，已经成为影响开发效率的首要障碍。

传统软件开发中，我们通过PRD文档、技术方案和测试用例来确保需求一致性。但在AI coding时代，这些规约往往分散在聊天记录、临时笔记和开发者的脑海中。我曾在一个跨团队项目中统计过，约43%的返工是由于前期规约没有明确记录导致的。更糟糕的是，当AI基于模糊的上下文进行"脑补"时，产生的代码往往与真实需求南辕北辙。

2. 最小规约工作流设计

2.1 核心目录结构

经过多个项目的实践验证，我发现以下目录结构能以最小成本实现最大收益：

code复制changes/<issue_id>/
├── proposal.md   # 项目宪法：定义做什么&不做什么
├── design.md     # 技术决策日志（可选但强烈推荐）
└── tasks.md      # 可验证的行动清单（必须）

这个结构的美妙之处在于：

• 每个变更集都有独立目录，便于版本追溯
• 文件角色分工明确，避免信息混杂
• 与Git工作流天然契合，可随代码一起评审

2.2 Proposal.md：项目的宪法文件

这个文件的核心价值在于划定边界。以下是经过20+项目验证的模板：

markdown复制## 背景
- 问题现象：[用1-2句话描述观察到的具体问题]
- 影响范围：[受影响的模块/用户群体/业务场景]

## 目标（Goals）
- [ ] 主要目标1：[可量化的成功标准]
- [ ] 主要目标2：[例：性能提升30%]

## 非目标（Non-goals）
- [ ] 不解决的问题1：[明确排除范围]
- [ ] 不解决的问题2：[例：不重构相关模块]

## 验收标准（Acceptance Criteria）
- 功能层面：
  - [ ] 用例1：[具体输入→输出]
  - [ ] 用例2：[API调用示例]
- 质量层面：
  - [ ] 测试覆盖率≥80%
  - [ ] 通过静态代码扫描

## 硬约束（Con