Skill ⑥：规范审计（convention-audit）

以 .github/standards/ 13 条规范为唯一基线，扫描项目源码，输出偏差报告和组件提取建议到 reports/ 目录。

核心理念：规范是"标准"，代码必须对齐标准。本 Skill 只负责发现偏差并给出整改建议，不自动修复（修复由 code-fix Skill 完成）。

触发关键词

规范审计 / 规范检查 / 代码审计 / 对齐规范 / 规范偏差 / 接手新项目 / 存量代码分析 / 项目体检

适用场景

场景	说明
新项目导入 wl-skills-kit 后	扫描旧代码，输出整改清单，逐步迁移到标准模式
日常 Code Review 辅助	AI 比对单文件或目录，快速发现偏差
项目迁移/升级	老项目引入新架构，批量评估改造量
团队培训	新成员提交代码前，用审计验证是否符合规范
page-codegen 后置自检	页面生成完成后自动跑一次审计，确认合规

13 条审计维度（全覆盖）

编号	审计维度	严重度判定
01	工具链就绪	缺少 .prettierrc.js / eslint.config.ts / .husky/ → 🔴 严重
02	4 文件原则、三段式、9 段顺序	缺 data.ts / index.vue 含业务逻辑 → 🔴；段落顺序乱 → 🟡
03	注释规范	文件头缺失 → 🟡；显而易见的注释 → 🟢 提示
04	基础编码（13 条）	用 var / for...in / 字符串拼接 → 🟡
05	console 残留	src/ 下任何 console.log / warn / error → 🟡
06	安全规范	v-html 无注释 / import axios / eval → 🔴
07	配置管理	硬编码 http:// IP → 🔴；非 VITE_ 环境变量 → 🟡
08	Git 规范	（审计时不检测，由 husky 自动拦截）
09	TypeScript	滥用 any（>3 处/页）→ 🟡
10	Pinia	data.ts 内 import Store → 🔴
11	表单校验	FORM_ROUTE 缺 validate / resetFields → 🔴
12	BaseTable + cid	用 el-table / 缺 render-type / cid 缺失或重复 → 🔴；cid 使用旧格式 → 🟡
13	平台组件合规	用 el-form/el-table/el-date-picker 替代封装 → 🔴；3+ 复用 → 提取建议

执行流程

步骤 1：确定审计范围

用户输入	范围
"审计整个项目"	src/views/
"审计 produce/mmwr"	该子目录
"审计 mmwr-customer-archive 页面"	单页面 4 文件

步骤 2：加载规范基线

读取 standards/01 ~ 13 全部规范文件（审计场景必须全量加载）。

步骤 3：扫描源码

逐个文件检查 13 个维度，同时记录跨页面相同 el-* 模式（统计出现次数和位置）。

步骤 4：追加写入两份报告

报告 A：reports/规范审查报告.md（追加，最新章节在顶）

## 🕐 {YYYY-MM-DD HH:mm} | 范围：{范围} | 触发：{user / page-codegen}

### 概要

| 指标 | 值 |
|------|-----|
| 扫描页面 | 12 |
| 合规页面 | 8 |
| 偏差页面 | 4 |
| 🔴 严重 | 5 |
| 🟡 轻微 | 7 |

### 🔴 严重偏差（必须整改）

#### {页面路径} — 违反规范 13（平台组件合规）

- **现状**：使用 `<el-table>` 渲染数据
- **应为**：使用 `<BaseTable render-type="agGrid" cid="...">`
- **整改建议**：参考 templates/universal/TPL-LIST.md
- **修复标记**：🔧 待修复

### 🟡 轻微偏差（建议整改）
### ✅ 合规页面

报告 B：reports/组件提取建议.md（追加）

## 🕐 {YYYY-MM-DD HH:mm} | 范围：{范围}

### 📦 组件提取建议

| 建议组件名 | 出现次数 | 页面路径 | 模式描述 |
|-----------|---------|---------|---------|
| c_statusBadge | 5 处 | src/views/sale/.../多页面 | 状态枚举彩色标签 |
| c_priceFormat | 4 处 | src/views/... | 千分位金额显示 |

步骤 5：输出摘要

📦 审计完成
──────────────────────────────────────────────
✅ reports/规范审查报告.md  → 已追加章节（N 个偏差）
✅ reports/组件提取建议.md → 已追加 M 条提取建议
──────────────────────────────────────────────
📌 后续步骤：
   1. 人工 review 报告，标记需要修复的条目
   2. 严重偏差优先修复（用 page-codegen 重新生成）
   3. 触发 code-fix 自动整改 🟢/🟡 等级偏差
   4. 提取建议人工评审 → template-extract 或手动封装

偏差严重度定义

级别	标记	定义	示例
🔴	严重	架构性违反，影响可维护性 / 安全	不用 AbstractPageQueryHook、用 el-table、import axios
🟡	轻微	风格 / 命名不统一，不影响功能	for...in、目录名 camelCase、缺 api.md
🟢	提示	优化建议，可逐步改进	重复表达式可抽 computed、超长函数可拆分

与其他 Skill 的关系

Skill	关系
page-codegen	审计发现偏差后，可调用 page-codegen 重新生成合规代码
template-extract	审计输出的"组件提取建议"，确认后可触发 template-extract
code-fix	审计报告作为修复输入，自动整改 🟢🟡 等级偏差

注意事项

1. 规范基线唯一 — 以 standards/index.md 加载的 13 条文件为准，不接受"旧代码一直这么写"的辩解
2. 追加不覆盖 — 每次审计追加新章节，不删除历史，便于追溯整改进度
3. AI 生成代码必须合规 — 如出现偏差是 Skill 模板的 bug，需反馈修复

---

标准对话示例

示例 1：全量审计

你：帮我做一次全量规范审计，目录 src/views/mmwr/。
AI：[Pre-flight] 已读取 standards/ 13 条规范
    扫描 src/views/mmwr/ 共 23 个 Vue 文件...
    
    ⚠ 偏差汇总（本次）
    🔴 严重：3 项
      - customer-detail/index.vue 第 47 行：直接 import axios（违反安全规范 06）
    🟡 中等：12 项
      - 7 个文件缺 data.ts（违反规范 02）
    🟢 轻微：8 项
      - 3 个文件无文件头注释
    
    已写入 reports/CONVENTION_AUDIT_20260426.md

示例 2：接手新项目

你：我接手了一个老项目，先做个规范体检，看看改造量。
AI：[Pre-flight]
    ├─ 目录：src/（全量扫描）
    ├─ 模式：存量分析
    └─ 不自动修复，只输出报告
    扫描 src/ 共 156 个 .vue / .ts 文件...
    🔴 严重：19 项  🟡 中等：54 项  🟢 轻微：43 项
    改造优先级建议：先处理 🔴，再批量处理 🟡（可交给 code-fix Skill）

FAQ

Q：审计只针对 Vue 文件吗？
A：主要是 .vue 和 data.ts，也会检查 pages.ts（路由注册规范）和工具链配置。

Q：审计完能直接让 AI 修复吗？
A：审计完成后触发 code-fix Skill（说"修复偏差报告里的 🟢🟡 问题"），它会批量处理轻中级偏差，严重问题需人工介入。

Q：每次都要全量扫描吗？
A：不必。日常开发可只说"审计 src/views/mmwr/customer-archive/"，只扫当前改动目录。