---
name: 规范迭代审核
description: 对已有项目进行审核，对比产品定义与实际实现的差距，然后反思改进项目的开发规范.md。当用户说"做一次规范审核"、"审核这个项目"、"迭代规范"或"项目复盘"时触发。
---

# 规范迭代审核 Skill

本 Skill 实现「项目开发规范的自我迭代」——通过外部审核视角发现差距，驱动规范不断完善。

## 运行环境说明

**Cursor 单窗口模式（当前可用）**：一个 AI 实例顺序扮演两个角色。
**ai-org-builder 多智能体模式（未来）**：编排器分发给两个角色实例并发执行，审核报告通过文件传递。

两种模式使用**相同的文件格式**，兼容。

---

## 第一阶段：审核（扮演审核者角色）

> 切换到「外部审核者」视角。目标：发现差距，不评判。

### 1.1 读取材料（按顺序）

```
1. 读 项目群/[project]/开发规范.md          → 了解规范说的是什么
2. 读 项目群/[project]/产品经理/产品定义.md  → 了解产品要做什么
3. 读 项目群/[project]/技术架构师/技术架构.md → 了解技术方案
4. 读 项目群/[project]/开发过程记录/         → 了解执行历史
5. 扫描 项目群/[project]/backend/ 和 frontend/ 的关键代码
   → 重点：API 路由、DB 模型、关键组件，了解实际实现了什么
```

### 1.2 差距分析（三个维度）

对每个维度，列出具体的差距项（不只是"有差距"，要说清楚哪里差、差多少）：

```
维度A：产品定义 vs 实际实现
  → 产品定义里有哪些功能/用户流程，代码里没有实现？
  → 实现了的，是否符合产品文档的描述？

维度B：技术架构 vs 实际代码
  → 架构文档描述的模块/接口/数据模型，代码里有没有？
  → 代码里有没有架构文档没提到的部分？

维度C：开发规范 vs 执行过程
  → 规范里要求的（留痕/验证/审核关卡），实际执行了吗？
  → 有哪些坑是规范里没有覆盖但实际踩到了的？
```

### 1.3 写审核报告

**格式**：`项目群/[project]/开发过程记录/规范审核报告_YYYYMMDD.md`

```markdown
# 规范审核报告

> 项目：[project]
> 日期：YYYY-MM-DD
> 审核者：[AI角色名]

## 一、核心发现（按严重程度排序）

### 🔴 关键差距（影响核心用户路径）
| # | 差距描述 | 维度 | 产品文档依据 | 实际状态 |
|---|---|---|---|---|
| 1 | ... | A/B/C | ... | ... |

### 🟡 重要差距（影响完整性）
...

### 🟢 次要差距（体验优化）
...

## 二、规范缺失项（规范.md 里应该补充但没有的内容）
- 缺少 XXX 的操作规范
- 缺少 XXX 角色的审核流程

## 三、执行偏差（规范有但 AI 没遵守的）
- 遗漏了 XXX 的留痕
- 跳过了 XXX 的验证关卡

## 四、建议的规范更新（具体到章节和措辞）
- 第X章增加：...
- 第Y章修改：...
```

---

## 第二阶段：反思与规范改进（扮演开发者角色）

> 切换到「开发者反思」视角。目标：理解根因，完善规范，不防御。

### 2.1 读取材料

```
1. 读 刚才生成的审核报告
2. 读 _内部总控/产品定义/AI时代产品问题全景框架.md  （为什么这样做）
3. 读 _内部总控/产品定义/AI时代产品组织协作模式.md   （怎么组织来做）
```

### 2.2 沙盘推演：找根因

对审核报告里每个🔴和🟡差距，用沙盘推演问：

```
1. 这个差距是「规范里没有写」还是「规范写了但没执行」？
2. 如果是没有写：这是一个通用模式还是项目特有的？通用的写进规范。
3. 如果是没有执行：规范的表述是否足够明确？缺少什么强制触发机制？
4. 这个问题在未来其他项目里会不会复现？如果会，规范里加什么能防止？
```

### 2.3 修改开发规范.md

**操作前必须**：
```
Copy-Item 项目群/[project]/开发规范.md → 项目群/[project]/history/开发规范_vX.X_YYYYMMDD.md
```

**修改内容**（只改项目内的 开发规范.md，不改 _内部总控/ 主文档）：
- 补充新发现的踩坑到踩坑速查表
- 补充缺失的操作规范章节
- 强化之前含糊的执行描述
- 在 CHANGELOG 追加详细变更记录

### 2.4 写迭代记录

在 `开发过程记录/` 追加一条记录：

```markdown
## 规范迭代记录 YYYY-MM-DD

**触发原因**：[外部审核/里程碑/用户指令]
**审核报告**：[规范审核报告_YYYYMMDD.md 的链接]
**规范变更**：v旧版本 → v新版本
**核心新增**：
- 踩坑 #N：...
- 新增 X.X 节：...
**未处理的差距**：（产品功能差距，等待下一轮开发，不是规范问题）
```

---

## 触发时机建议

| 时机 | 模式 |
|---|---|
| 完成一个大功能/里程碑后 | 可选，手动触发 |
| 产品审核发现问题后 | 强烈建议，立即触发 |
| 每月定期 | 推荐 |
| 新项目启动前（审核上一个项目的经验）| 强烈建议 |

---

## 在 ai-org-builder 中的自动化实现

```
触发条件：
  → 任务状态变为 done
  → 里程碑达成
  → 用户在主对话界面说「做一次规范审核」

编排器行为：
  1. 创建「审核任务」，分配给「测试工程师」角色实例
  2. 审核角色执行第一阶段，审核报告写入文件
  3. 报告写入后，触发「开发角色」的第二阶段
  4. 开发角色修改 开发规范.md（先留痕）
  5. 更新任务状态，通知用户规范已迭代

存储：
  → 审核报告：org_builder.tasks 表，type='spec_audit'
  → 规范历史：开发过程记录/history/
```

---

## 相关文档

- [项目开发规范.md](../../开发规范.md) — 被改进的目标文档
- [AI时代产品问题全景框架.md](../../../_内部总控/产品定义/AI时代产品问题全景框架.md)
- [AI时代产品组织协作模式.md](../../../_内部总控/产品定义/AI时代产品组织协作模式.md)