TashanGKD 规范迭代审核 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
# 规范审核报告
> 项目：[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 写迭代记录
在 开发过程记录/ 追加一条记录：
## 规范迭代记录 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 — 被改进的目标文档
- AI时代产品问题全景框架.md
- AI时代产品组织协作模式.md