规范迭代审核
他山 Cursor Skill 体系 — 95个Skills + 32个Rules + 18个SubAgents,让AI在执行任务时能自主判断、按规范执行、并从经验中自我进化
npx -y skills add TashanGKD/tashan-cursor-skills --skill 规范迭代审核Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
对已有项目进行审核,对比产品定义与实际实现的差距,然后反思改进项目的开发规范.md。当用户说"做一次规范审核"、"审核这个项目"、"迭代规范"或"项目复盘"时触发。
SKILL.md
5.9 KB, as published. Nobody here has run it
规范迭代审核 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