confidence

置信度评估

评估当前工作完全满足既定要求的置信度。

多信号评估。 单个 LLM 置信度数值不可靠，不能单独作为门槛（令牌概率 ≠ 正确性）。此技能将 LLM 的维度评分与 Agent 必须同时运行的确定性规则检查结合起来。最终得分取决于两者是否都通过。

目录

• 模式检测
• 评估维度
  • 对于 plan 模式 — 多信号：LLM 评分 + 规则检查（失败时上限为 89%）
  • 对于 code 模式
  • 对于 analysis 模式
• 输出格式
• 分数阈值
• 迭代流程（plan 模式）
• 自动修复（仅修复模式）

---

模式检测

检查参数：$ARGUMENTS

参数	默认值	验证内容	使用时机
plan		实施计划的完整性	第 1 阶段规划完成后、自主执行前
code	是	代码实现的正确性	编写代码后、提交 PR 前
analysis		分析准确性（根本原因、重构依据或技能缺口）	调查期间，在提出修复、重构或技能源代码差异之前
bug-analysis		analysis 的弃用别名 — 行为完全相同	为保持向后兼容；在报告标题中输出一行弃用说明

如果未提供参数，默认使用 code。

别名处理。 bug-analysis 可作为已弃用的别名接受，并解析为 analysis，使用相同的维度、权重、阈值和修复模式行为。使用此别名时，在报告标题前添加一行：> Note: \bug-analysis` is a deprecated alias for `analysis`. Update the caller when convenient.` 此别名可确保现有工作流和记录在过渡期间继续正常运行；待调用方迁移后将其移除。

如果参数中包含 "fix"（例如 code fix、plan fix、analysis fix），则进入修复模式——审查后自动修复发现的所有问题。

---

评估维度

对于 plan 模式

计划模式采用多信号评估：LLM 维度评分 + 确定性规则检查。 两者都必须通过才能解除门槛。

第 1 步 — 大模型维度评分

维度	权重	评估内容
完整性	40%	是否记录了所有 Phase 0 要求？核心章节是否已填写（且任务需要时包含扩展章节）？新会话能否仅凭此计划执行？如果某个扩展章节因其 Include when 触发条件不适用而合理省略（例如，仅修改计划中没有现有代码调查），则不要扣分。如果现有代码调查中的“搜索内容”一栏含糊不清（“看了看”），或 BUILD NEW 判定未显示任何搜索，则应扣分——规则 #10 检查是否存在，本维度检查搜索质量。
可行性	30%	技术方案是否可靠？所用模式是否与代码库一致？是否在适用时识别了风险？
无歧义性	30%	实施步骤是否足够具体，能够直接执行而无需自行解读？是否在适用时考虑了边界情况？

第 2 步 — 确定性规则检查（通过 Bash 运行）

对于计划模式，以下每项检查都必须通过。任何一条规则未通过，都会将关卡上限限制为 89%（无论大模型评分如何）——Agent 必须指出未通过的规则，并修复计划或向用户升级处理。规则 #10 和 #11 为有条件适用（其触发条件属于规则的一部分）；条件不成立时，视为通过并记录说明——不得静默跳过。

#	规则检查	验证
1	plan.md 存在于预期路径	test -f .agent/$(git branch --show-current)/plan.md
2	所有 Core 部分均存在	grep -E '^## (TL;DR|Requirements|Decisions|Acceptance Criteria|Implementation Order|File Changes|Verification|Progress Log)' plan.md | wc -l ≥ 8 — 这些属于始终启用的 Core 层级。扩展部分（Background、Technical Approach、Patterns、Edge Cases、API、Tests、Dependencies、Risks）按需纳入，不计入此处。
3	Acceptance Criteria 部分非空	awk '/^## Acceptance Criteria/{f=1;next} /^###? /{f=0} f' plan.md | grep -c '^- |^[0-9]' ≥ 1
4	## File Changes 中的每个文件均可解析，或标记为 create	对每一行 modify/delete，git ls-files <path> 都会返回该路径。Create 行跳过此检查。
5	每项需求均标记为 [user-stated] 或 [inferred]	awk '/^## Requirements/{f=1;next} /^###? /{f=0} !f{next} /^[-0-9]/{n++} /\[user-stated\]/{t++} /\[inferred\]/{t++} END{exit n!=t}' plan.md 退出码为 0 — 标签数量必须等于需求数量（范围在 ### Out of Scope 处结束，因此不计入排除项）。这是一个不含 shell 管道的单条 awk 命令，因此表格行会原样执行。
6	每个决策行都填写了 Rationale 列	awk -F'[|]' '/^## Decisions/{f=1;next} /^###? /{f=0} !f{next} !/^[|]/{next} {r++} r<3{next} NF<5{bad=1} $4 ~ /^[ \t]*$/{bad=1} END{exit bad}' plan.md 退出码为 0 — Decisions 表格的 Rationale（第三）列没有缺失或空白单元格。字段分隔符和行匹配使用字符类 [|]，因此该命令无需 shell 管道即可原样执行。
7	所有时间戳均为带时间部分的 ISO 8601 格式	awk '/^## Progress Log/{f=1;next} /^###? /{f=0} !f{next} /^- /{n++} /^- \[20[0-9][0-9]-[0-9][0-9]-[0-9][0-9]T[0-9][0-9]:[0-9][0-9]:[0-9][0-9]Z\]/{t++} END{exit n!=t}' plan.md 退出码为 0 — 每条 Progress Log 条目都以 [YYYY-MM-DDTHH:MM:SSZ] 时间戳开头。这是一个不含 shell 管道的单条 awk 命令，因此表格行会原样执行。
8	Verification 命令不是模板	“After editing”和“Before PR”行不包含 { 或 } 占位符花括号
9	每项 [user-stated] 需求均由一条 Acceptance Criterion 覆盖	awk '/^## Requirements/ {rs=1; as=0; next} /^## Acceptance Criteria/ {as=1; rs=0; next} /^###? / {rs=0; as=0} rs && /^[-0-9]/ {n++; if (index($0,"[user-stated]")) us[n]=1} as {s=$0; while (match(s, /covers:[^)]*/)) {seg=substr(s,RSTART,RLENGTH); s=substr(s,RSTART+RLENGTH); while (match(seg,/R[0-9]+/)) {cov[substr(seg,RSTART+1,RLENGTH-1)]=1; seg=substr(seg,RSTART+RLENGTH)}}} END {for (i in us) if (!(i in cov)) exit 1; exit 0}' plan.md 退出码为 0 — 需求按列表位置编号（第一项 = R1；通过 ### 重置排除 Out of Scope 项）；每个标记为 [user-stated] 的位置都必须出现在 Acceptance Criteria 的 (covers: R…) 注释中。这是需求→标准的可追溯性关卡：计划不能悄然遗漏用户提出的需求。这是一个不含 shell 管道的单条 awk 命令，因此表格行会原样执行。
10	每个计划中的 create 都有 Existing Code Survey 结论	awk -F'[|]' '/^## File Changes/ {fc=1; es=0; next} /^## Existing Code Survey/ {es=1; fc=0; next} /^###? / {fc=0; es=0} fc && /^[|]/ && $2 ~ /create/ {creates++} es && /^[|]/ {if (index($0,"EXTEND") + index($0,"WRAP") + index($0,"BUILD NEW") > 0) rows++} END {if (creates == 0) exit 0; exit (rows < 1)}' plan.md 退出码为 0 — 当 File Changes 表格中至少有 1 行 create 时，## Existing Code Survey 部分必须存在，且至少有 1 行结论（EXTEND / WRAP / BUILD NEW）。仅修改的计划无需满足此条件（可合理省略此部分）。这是防止重复造轮子的关卡：新单元必须记录复用搜索结果。字段分隔符使用字符类 [|]，结论匹配使用不含管道的 index() 求和，因此该命令无需 shell 管道即可原样执行。
11	checks.yaml 存在，且其 ID 与计划同步	仅适用于 Acceptance Criteria 带有 AC-{n} ID 的情况（未带 ID 的计划，例如 /fix-bug 快速通道，可跳过并记录说明）。验证：test -f .agent/$(git branch --show-current)/checks.yaml，然后对计划的 Acceptance Criteria 部分中的每个 AC-{n}，grep -c "^- id: AC-{n}$" checks.yaml 均返回 ≥ 1，并且 checks.yaml 中的每个 id: 都能在计划中找到对应的 AC。任一方向出现孤立项都会导致失败。
运行每项检查，并在输出表中列出通过／未通过。未通过的规则是阻断项，门禁必须将其报告出来，即使 LLM 维度评分很高也不例外。

第 3 步 — 综合门禁

overall_score = min(weighted_LLM_score, max_allowed_by_rule_checks)
where max_allowed_by_rule_checks = 100% if all rules pass, else 89%

其意图是：一个经 LLM 判断得分为 95% 的计划，如果未通过规则检查 #4（引用了不存在的文件路径），则最高只能得 89%——而且门禁会判定失败。这能捕捉到一种失效模式：模型很有把握，但计划却建立在幻觉生成的路径上。

对于 code 模式

维度	权重	评估内容
正确性	40%	逻辑是否确实解决了所述问题？
完整性	30%	是否涵盖所有情况、边缘情况和要求？
无回归问题	30%	是否可能破坏现有行为或引入副作用？

对于 analysis 模式

当被评估的内容是一项分析时，使用此模式——例如根因分析报告、重构理由、/create-skill diagnose 提案、陷入循环后进行的整体重新分析，或任何其他先于变更提案的推理内容。

维度	权重	评估内容
证据强度	40%	分析是否有具体证据支持（日志、跟踪记录、代码路径、文件:行引用、复现的行为）？
根因确定性	30%	这是根本原因，还是仅仅是症状？调查得有多深入？对于重构／诊断分析，应将“根因”理解为“实际的结构性原因”，而非字面意义上的故障成因。
结果信心度	30%	提议的操作（修复、重构、技能源差异）能否解决问题且不引入新问题？

---

输出格式

你必须严格按照以下格式输出：

## Confidence: X%

### LLM dimensional scoring

| Dimension | Score | Notes |
|-----------|-------|-------|
| <dim 1>   | X%    | ...   |
| <dim 2>   | X%    | ...   |
| <dim 3>   | X%    | ...   |

### Deterministic rule checks (plan mode only — omit for code/analysis)

| # | Rule                | Status      | Evidence                  |
|---|---------------------|-------------|---------------------------|
| 1 | <rule description>  | ✓ pass / ✗ fail | <command output snippet> |
| ... |                   |             |                           |

### Combined gate

- Weighted LLM score: X%
- Rule checks: <N pass> / <total> (cap: 100% if all pass, else 89%)
- **Final: X%**

根据上述维度权重，以加权平均值计算 LLM 加权得分。对于 plan 模式，最终得分为 min(LLM 加权得分, 规则检查上限)。对于 code 和 analysis 模式（包括通过已弃用的 bug-analysis 别名调用的情况），省略规则检查部分，并令 最终得分 = LLM 加权得分。

务必诚实且严格——不要虚抬分数。给出清晰理由的低分，比虚假的 95% 更有价值。规则检查未通过是不可妥协的——即使 LLM 得分很高，也必须将其报告出来。

---

评分阈值

得分	操作
90-100%	继续——工作已准备就绪
70-89%	列出具体问题以及提高信心的方法。如果处于修复模式，请应用修复。
低于 70%	建议验证或修复的具体后续步骤。不要继续自主执行。

---

迭代流程（plan 模式）

在自主执行前用作质量门禁时：

如果信心低于 90%，最多进行 2 轮迭代，以开展更多研究、分析并收集证据，从而提高得分。 每轮迭代后，重新进行信心评估。 如果经过 2 轮迭代后仍低于 90%，则向用户说明调查结果，并询问他们是继续执行还是进一步完善。

---

自动修复（仅修复模式）

如果不处于修复模式，请完全跳过本节。

在修复模式下运行时（plan fix、code fix、analysis fix——或已弃用的 bug-analysis fix 别名），自动处理所有导致评分降低的问题：

简单修复（立即应用）

无需询问即可修复以下问题——风险低且处理方式明确：

• 缺少明显可实现的边缘情况处理
• 缺少 null/undefined 检查
• 差一错误或边界条件不正确
• 字符串、注释或变量名中的拼写错误
• 类型明确但缺少返回类型或类型注解
• 可明确修正的小型逻辑错误
• （计划模式）缺少章节、需求不完整、实现步骤含糊

应用每项修复后，简要说明所做的更改（每项修复一行）。

复杂修复（先规划，再应用）

对于需要深入考虑的问题：

• 缺少对未覆盖路径的测试
• 实现不完整（缺少情况、未处理的状态）
• 架构问题或抽象不当
• （计划模式）根本性方案问题、缺少技术设计

对于每项，输出：

### [Issue title]
**Why:** [1-sentence explanation]
**Fix plan:**
1. [Step 1]
2. [Step 2]
**Files involved:** [list]

然后执行计划。

修复后重新评估

应用所有修复后：

1. 使用更新后的评分重新进行置信度评估
2. 列出修复内容，以及每项修复如何提高评分
3. 如果置信度仍低于 90%，列出无法自动修复的剩余问题