go-code-reviewer Skill 评审报告¶

评估框架: skill-creator 评估日期: 2026-03-11 评估对象: go-code-reviewer

go-code-reviewer 是一个面向 Go 代码与 PR 的 defect-first 审查 skill，重点识别真实缺陷、回归风险和项目规范偏离，而不是泛泛而谈代码风格。它最突出的三个亮点是：触发准确率高，且在复杂灰区场景下能显著压低误报、提升信噪比；审查流程带有模式选择、强制门禁和按需加载的领域参考资料，能把审查深度与风险等级对齐；同时提供 Residual Risk、抑制理由和结构化输出，让评审结果更可执行、更适合团队协作闭环。

一、评估概览¶

本次评估从触发准确率和实际任务表现以及token效费比三个维度对 go-code-reviewer skill 进行全面评审。实际任务表现覆盖两个难度梯度：4 个教科书级场景（典型常见缺陷）和 4 个微妙场景（灰区判断、领域特定模式、多文件分析），共 8 个场景 × 2 配置（with-skill / without-skill）= 16 次独立 subagent 运行。

二、触发准确率¶

2.1 测试方法¶

设计 20 条测试查询（10 条应触发 / 10 条不应触发），覆盖中英文、多种审查场景和近似但不应触发的边缘任务。使用独立 subagent 模拟 Cursor 的 <agent_skills> 触发路径，对每条查询做出 TRIGGER / NO_TRIGGER 判断。

2.2 结果¶

总准确率:  20/20 (100%)
Recall:    10/10 (100%) — 所有正例查询全部正确触发
Precision: 10/10 (100%) — 所有负例查询均正确排除

2.3 正例查询（全部正确触发）¶

2.4 负例查询（全部正确排除）¶

2.5 结论¶

Description 覆盖了中英文常用审查表达（"审查"/"review"/"看看有没有问题"/"security review" 等），明确说明了差异化价值（origin classification, SLA, suppression rationale），并添加了"Even for seemingly simple Go review requests, prefer this skill"的推力。触发准确率达到 100%，无漏触发、无误触发。

三、实际任务表现 — 教科书级场景¶

3.1 测试方法¶

创建 4 个包含已知典型缺陷的 Go 代码文件：

每个场景各运行 1 个 with-skill + 1 个 without-skill subagent，共 8 次运行。

3.2 缺陷检测完整性¶

在教科书级缺陷上，两者的检测能力完全一致。Claude 的通用 Go 知识已足够识别这些典型模式。

3.3 质量维度对比¶

教科书级场景中 Skill 的价值主要体现在：

• 误报控制透明度 (+1.75) — With-skill 有显式 Suppressed Items（如 json.Marshal 对安全结构体的 error 忽略、Mutex vs RWMutex 作为优化建议而非缺陷）。Without-skill 没有抑制说明，读者无法区分"有意忽略"和"审查盲区"。
• 结构一致性 (+1.0) — With-skill 每个 finding 统一使用 REV-ID / Origin / Baseline / Evidence / Action 模板，并包含 Execution Status、SLA 表、Residual Risk。Without-skill 格式在不同场景间不一致。
• Origin 分类 (Eval 4) — With-skill 在每个 finding 上标注 introduced → must-fix 或 pre-existing → follow-up issue，Summary 包含 origin 统计（"5 introduced / 4 pre-existing / 0 uncertain"）。Without-skill 通过 section 分组实现了类似效果，但缺少 per-finding 粒度标注和 SLA 对照。

四、实际任务表现 — 微妙场景¶

4.1 测试方法¶

设计 4 个需要深层判断力的场景，每个都包含"陷阱"——不用 Skill 容易误报或漏报的微妙模式：

每个场景各运行 1 个 with-skill + 1 个 without-skill subagent，共 8 次运行。

4.2 总览¶

4.3 Eval 5: 灰区误报陷阱¶

代码中包含 6 个灰区模式：同包 err == ErrNotFound、只读 defer f.Close()、init 中 context.Background()、长 switch 函数、interface{} → any 纯 cosmetic、json.Marshal 安全结构体 error 忽略。另有 1 个真实 bug（变量遮蔽）。

关键差异: Skill 精准聚焦于 2 个真正有价值的 finding（validation error 遮蔽 + dead code），零噪音。Without-skill 也识别了灰区，但多报了 3 个低价值 finding。Skill 额外将 configStore 并发风险放入 Residual Risk（"Medium | uncertain | test_code.go:38 | mutable package-level map without sync"），既不作为 finding 干扰开发者，也不完全丢失这条信息。

灰区抑制逐项对比：

4.4 Eval 6: 微妙并发 bug¶

4 个真实并发 bug + 1 个 nil map panic：time.After 在 select 循环中的 timer 泄露、WaitGroup.Add 在 goroutine 内部的竞态、sync.Pool 容量丢失、mutex 持有期间 I/O 导致全局串行化、DataFetcher.cache nil map。另有 1 个 nil channel in select 陷阱（用于禁用 select case，是正确模式）。

关键差异: 缺陷覆盖完全一致。两者都正确处理了 nil channel 陷阱。Skill 的额外价值在于：

1. 严重性判断更准确: nil map write 在生产中会导致进程崩溃，Skill 正确评为 High，Without-skill 评为 Medium。
2. Residual Risk 补充: Skill 在 Residual Risk 中列出 3 项补充说明（FanOut error 聚合策略、Dispatch 背压丢弃、FormatRecord map 迭代顺序），为后续维护提供参考。
3. 结构化抑制: nil channel 作为 Suppressed Item 有明确理由引用 go-concurrency-patterns.md，而非简单标注"not a bug"。

4.5 Eval 7: gRPC + Database 领域特定模式¶

5 个领域特定 bug：gRPC interceptor 链顺序错误（auth 在 logging 之后）、gRPC deadline 未传递到 DB 查询（context.Background() 替代了 incoming ctx）、metadata 未传递到下游服务、N+1 查询、连接池未配置。另有 1 个 err == sql.ErrNoRows 灰区（QueryRow.Scan 返回未 wrap 的 sentinel，== 在此处正确）。

关键差异: Skill 的信噪比 100% vs Without-skill 的 67%。Without-skill 的 4 个噪音 finding：

Skill 正确抑制了 err == sql.ErrNoRows 直接比较（3 处），并引用了 grey-area guidance：QueryRow.Scan 返回 unwrapped sentinel。这是 reference loading 机制价值最直观的体现。

4.6 Eval 8: 多文件 Impact Radius 分析¶

PR 修改了接口文件 repository.go（FindByEmail 增加 opts ...QueryOption 参数、List 参数从 (limit, offset int) 改为 UserFilter、User 结构体 JSON tag 从 "updated" 改为 "updated_at"），影响了实现文件 postgres_repo.go 和调用文件 handler.go。

Skill 在 Residual Risk 中捕获了 4 个 medium pre-existing issues：

关键差异:

Skill 用 merge rule 将 5 个编译错误合并为 1 个 finding（包含 per-location origin breakdown），并通过 origin 分类 + Residual Risk 让开发者清楚哪些是自己的锅（must-fix）、哪些是历史债务（Residual Risk）。这是 Skill 差异化价值最大的场景。

五、Token 效费比分析¶

5.1 测试方法¶

基于 8 个评估场景的实际输入/输出数据，分析 with-skill 和 without-skill 的 token 消耗差异。Token 估算基于文件字节数（混合内容按 ~3 bytes/token 折算）。

Skill 输入开销构成:

5.2 总 Token 消耗对比¶

注意: 上述为隔离测量，仅包含测试代码 + Skill 上下文。实际 Cursor 会话中 base context（system prompt、对话历史、rules 等）约 20-30K tokens，Skill 增量相对于完整上下文的占比约 1.5-2x，非表中的 6x。

5.3 输出 Token 对比¶

关键观察: Eval 8（多文件影响）中 with-skill 输出 3,354 tokens vs without-skill 3,933 tokens。Skill 通过 finding merge（5 个编译错误 → 1 个 finding）产出更精简的输出。这表明 Skill 在复杂场景中并非总是更啰嗦 — 反而可能更精炼。

5.4 美元成本模型¶

基于 Claude Sonnet 定价（Input $3/M tokens, Output $15/M tokens）：

5.5 性价比核心指标¶

5.5.1 输出信号密度¶

在微妙场景中，without-skill 的输出中有 16% 是噪音（误报或低价值 finding），而 with-skill 为 0%。这意味着 without-skill 的 ~470 output tokens 是"浪费"的噪音 token（5 个 FP × ~94 tokens/FP）。

5.5.2 开发者时间 ROI¶

5.5.3 月度投资回报¶

5.6 Token 效费比结论¶

Skill 不是 token 高效的，但是极其"价值高效"的。

六、综合分析¶

6.1 Skill 的差异化价值地图¶

核心结论: 场景越微妙，Skill 的差异化价值越大。

• 教科书级场景：Skill 提供的主要是流程层面的改善（统一格式、SLA 指导），缺陷检测能力无差异
• 微妙场景：Skill 同时提供检测能力（100% vs 100%）和判断层面的改善（信噪比 89% vs 53%），Residual Risk 确保不丢失任何已验证的 pre-existing issue

6.2 Skill 的真实价值定位¶

Skill 不是用来"发现更多 bug"的，而是用来"更好地组织和处理 bug，同时不遗漏任何高危问题"。

核心价值按重要性排序：

1. 信噪比控制 — 19 个精准 finding vs 32 个含噪音的 finding。在微妙场景中，Without-skill 多报的 13 个 finding 中有约 5 个是误报或噪音，增加开发者认知负担。
2. 零遗漏的 High 覆盖 — severity-tiered volume cap 确保所有 High 级别缺陷都被上报，不会因 volume cap 而丢弃高危 finding。
3. 误报管理透明化 — 9 个 Suppressed Items 每个都有结构化理由（引用 anti-example catalog 和 reference 文件），让团队知道什么被有意排除了、为什么排除。
4. Origin 分类 + Residual Risk — 让开发者不被历史债务阻塞，同时不丢失任何已验证的 pre-existing issue。"4 个问题要修 + 4 个已知债务已记录"比"10 个问题混在一起"对开发者更友好。
5. 审查流程标准化 — 统一模板（REV-ID / Origin / Evidence / Action）、mandatory gates、severity-tiered volume cap、SLA 表。
6. Reference Loading — 在 gRPC/database 等领域特定场景中确保审查时加载了正确的 checklist，避免遗漏领域最佳实践。

6.3 残留弱点¶

1. 教科书级场景差异化有限: 在典型常见缺陷上，Skill 不比通用 Claude 多发现任何 bug，差异仅在流程层面（+0.56/5.0）。
2. Severity 判断偶有偏差: Eval 6 中 Without-skill 将 nil map 评为 Medium，Skill 评为 High。虽然 Skill 更准确（nil map write = 进程崩溃），但这也说明两者在边界案例的严重性评估上可能不一致。
3. Eval 7 额外 Medium findings: Skill 在 Eval 7 中报了 3 个额外 Medium finding（error leak、error context、input validation），Without-skill 报了类似但更多的 findings。Skill 的额外 findings 全部有效，无噪音。

七、评分总结¶

7.1 分维度评分¶

7.2 加权总分¶

八、评估方法论¶

触发评估¶

• 方法: Subagent 模拟触发判断，将 description 呈现给独立 agent 对 20 条查询做 TRIGGER/NO_TRIGGER 判断
• 查询设计: 10 正例（涵盖中英文、多种审查场景）+ 10 负例（近似但不应触发的边缘任务）

任务评估¶

• 方法: 8 个场景 × 2 配置 = 16 个独立 subagent 运行
• 教科书场景: 22 个植入缺陷 + 22 个 semantic/structural assertions
• 微妙场景: 17 个真实缺陷 + 7 个灰区/陷阱模式
• 质量维度: 7 个维度 × 0-5 分
• 基线: 同样的提示词，不读取 SKILL.md

Token 效费比评估¶

• 方法: 基于 8 个场景的实际文件大小估算 token 消耗（混合内容按 ~3 bytes/token）
• 输入: SKILL.md (30,677 bytes) + 按场景触发的 reference 文件 (14-45K bytes)
• 输出: review.md 文件大小直接测量
• 成本模型: Claude Sonnet 定价 (Input $3/M, Output $15/M)
• 开发者时间估算: FP 鉴别 ~10 min/个, 结构化输出节省 ~5 min/次, 时薪 $100

评估材料¶

• 触发评估查询: go-code-reviewer-workspace/trigger-eval.json
• 教科书场景评分: go-code-reviewer-workspace/iteration-1/grading_results.json
• 教科书场景 Benchmark: go-code-reviewer-workspace/iteration-1/benchmark.json
• Eval Viewer: go-code-reviewer-workspace/iteration-1/eval_review.html
• 测试代码: go-code-reviewer-workspace/iteration-{1,2}/eval-*/test_code.go
• 微妙场景输出: go-code-reviewer-workspace/iteration-2/eval-{5,6,7,8}-*/with_skill/review.md 和 without_skill/review.md
• Token 分析数据: token_analysis.json, token_analysis.py