confidence-check

# /confidence-check - 置信度检查

> **核心理念**: 决策质量不靠"感觉好不好"，而靠可量化的 5 维评估。

对当前项目状态进行 5 维置信度评估，识别薄弱环节，指导下一步行动。

---

## 角色定位

- **身份**: 质量评估员
- **目标**: 量化评估当前阶段的决策质量和完成度
- **原则**: 基于文件内容客观评分，不做主观判断
- **触发时机**: 阶段完成时（非每次编辑）

---

## 5 维置信度模型

### 立即执行以下评估：

### 1. 需求明确性 (25%)

**检查方式**: 读取 `memory-bank/progress.md` 和 `docs/requirements/` 目录

**评分标准**:

| 分数 | 条件                            |
| ---- | ------------------------------- |
| 100% | 无 "TBD"、"待确认"、"待定" 标记 |
| 75%  | ≤2 个待确认项                   |
| 50%  | 3-5 个待确认项                  |
| 25%  | >5 个待确认项                   |
| 0%   | 无需求文档                      |

**检查关键词**: `TBD`, `待确认`, `待定`, `TODO`, `FIXME`, `待澄清`, `低置信度`

### 2. 架构一致性 (25%)

**检查方式**: 读取 `memory-bank/architecture.md`，对比最近 git diff

**评分标准**:

| 分数 | 条件                                       |
| ---- | ------------------------------------------ |
| 100% | architecture.md 存在且最近 7 天内更新      |
| 75%  | architecture.md 存在但超过 7 天未更新      |
| 50%  | architecture.md 存在但与实际代码结构不一致 |
| 25%  | architecture.md 存在但内容过少（<100 字）  |
| 0%   | 无 architecture.md                         |

### 3. 实现完整性 (20%)

**检查方式**: 扫描变更文件中的 TODO/FIXME，检查测试文件存在性

**评分标准**:

| 分数 | 条件                                    |
| ---- | --------------------------------------- |
| 100% | 无 TODO/FIXME + 测试文件存在 + 测试通过 |
| 75%  | ≤2 个 TODO + 测试文件存在               |
| 50%  | >2 个 TODO 或缺少测试文件               |
| 25%  | >5 个 TODO 且无测试                     |
| 0%   | 核心功能未实现                          |

**扫描关键词**: `TODO`, `FIXME`, `HACK`, `XXX`, `TEMP`

### 4. 文档同步性 (15%)

**检查方式**: 检查 `memory-bank/progress.md` 的修改时间和决策表完整性

**评分标准**:

| 分数 | 条件                                          |
| ---- | --------------------------------------------- |
| 100% | progress.md 今日更新 + 决策表有完整记录       |
| 75%  | progress.md 今日更新 + 决策表有记录但缺置信度 |
| 50%  | progress.md 3 天内更新                        |
| 25%  | progress.md 超过 3 天未更新                   |
| 0%   | 无 progress.md                                |

**决策表检查**: 验证 `| 日期 | 角色 | 决策 | 依据 | 置信度 |` 表格的填写率

### 5. 验证通过率 (15%)

**检查方式**: 检查最近一次 `/cc-best:verify` 的结果

**评分标准**:

| 分数 | 条件                                     |
| ---- | ---------------------------------------- |
| 100% | 构建 + 类型 + Lint + 测试 + 安全全部通过 |
| 75%  | 4/5 通过                                 |
| 50%  | 3/5 通过                                 |
| 25%  | ≤2/5 通过                                |
| 0%   | 未执行验证                               |

---

## 输出规范

```
══════════════════════════════════
     CONFIDENCE CHECK
══════════════════════════════════

📊 Overall Confidence: [XX]%

1. 需求明确性  ████████░░  80%  (25%)
   → [具体说明]

2. 架构一致性  ██████████  100% (25%)
   → [具体说明]

3. 实现完整性  ██████░░░░  60%  (20%)
   → 发现 3 个 TODO

4. 文档同步性  ████████░░  75%  (15%)
   → 决策表缺少 1 条置信度记录

5. 验证通过率  ██████████  100% (15%)
   → 全部通过

══════════════════════════════════
  加权总分: [XX]%
  建议: [下一步行动]
══════════════════════════════════
```

### 进度条渲染

```
100%: ██████████
 75%: ████████░░
 50%: ██████░░░░
 25%: ████░░░░░░
  0%: ░░░░░░░░░░
```

---

## 建议映射

| 加权总分 | 建议                           |
| -------- | ------------------------------ |
| ≥90%     | 状态优秀，可继续推进           |
| 70-89%   | 基本达标，建议补齐薄弱项后继续 |
| 50-69%   | 需要关注，建议先修复低分维度   |
| <50%     | 建议暂停推进，先夯实基础       |

---

## 实现前置信度模式 | Pre-Implementation Mode

`/cc-best:confidence-check --pre`

在开始实现前评估准备充分度，与默认的"完成度评估"互补。

### 实现前 4 维模型

### 1. 重复实现检查 (30%)

**检查方式**: 是否执行了 search-first 流程

| 分数 | 条件                                    |
| ---- | --------------------------------------- |
| 100% | 搜索决策记录在 progress.md 且有明确理由 |
| 75%  | 搜索了但未记录决策                      |
| 50%  | 仅口头确认"没有现有方案"                |
| 0%   | 未搜索就开始实现                        |

### 2. 架构合规性 (25%)

**检查方式**: 方案是否符合项目技术栈和约定

| 分数 | 条件                                     |
| ---- | ---------------------------------------- |
| 100% | 完全符合 architecture.md + tech-stack.md |
| 75%  | 基本符合，有 1 处偏差但有理由            |
| 50%  | 引入了项目未使用的模式/框架              |
| 0%   | 与现有架构冲突                           |

### 3. 文档查证 (25%)

**检查方式**: 是否查阅了相关官方文档

| 分数 | 条件                       |
| ---- | -------------------------- |
| 100% | 查阅了 API 文档 + 示例代码 |
| 75%  | 查阅了 API 文档            |
| 50%  | 仅参考了第三方教程         |
| 0%   | 未查阅任何文档             |

### 4. 参考实现 (20%)

**检查方式**: 是否找到可参考的开源实现

| 分数 | 条件                         |
| ---- | ---------------------------- |
| 100% | 找到 ≥2 个参考实现并对比分析 |
| 75%  | 找到 1 个参考实现            |
| 50%  | 找到类似但不完全匹配的实现   |
| 0%   | 无参考实现（首创方案）       |

### 实现前建议映射

| 加权总分 | 建议           |
| -------- | -------------- |
| ≥90%     | 立即开始实现   |
| 70-89%   | 继续调查再开始 |
| <70%     | 停止，补充调查 |

---

## 使用时机

### 推荐使用

- 每个管线阶段完成时（PM→Lead, Lead→Dev, Dev→QA）
- 每完成 3 个任务后（可选）
- 提交 PR 之前

### 不推荐使用

- 每次小编辑后（会拖慢 iterate 模式）
- 初始化阶段（文档尚不完整，分数必然很低）

---

## 与 A2 原则的关系

A2 原则要求"记录决策的**依据**和**置信度**"。本命令是 A2 原则的机械化执行：

- 自动检查决策表中的置信度列是否填写
- 自动统计 TBD/待确认标记数量
- 将主观的"我觉得没问题"转化为可量化的百分比

> 📝 **命令格式说明**：本文档使用插件命令格式（`/cc-best:confidence-check`）。
> 如果你是直接 clone 到 `.claude/` 目录使用，请去掉 `cc-best:` 前缀。

> **记住**: 置信度是诚实的标尺，低置信度不是缺陷而是负责任的信号。标记 TBD 比错误假设更有价值。