go-benchmark Skill 评估报告¶

评估框架: skill-creator 评估日期: 2026-04-11 评估对象: go-benchmark

go-benchmark 是一个专注于 Go 性能基准测试与 pprof 分析的专项 skill。评估横跨三个场景（从源码写基准 / 审查有缺陷的基准 / 分析 benchstat 数据），共 24 项断言，With-Skill 全部通过（24/24，100%），Without-Skill 通过率 46%（11/24），总体提升 +54 百分点。三个最突出的差距：第一，With-Skill 始终声明 var sinkString / var sinkErr 并解释为何 _ = result 会导致编译器消除整个调用，Without-Skill 在场景 1 完全未使用 sink 变量，在场景 2 则明确说 _ = data 是"safe here"；第二，Evidence Gate 驱动的 mode / data_basis 声明和 Auto Scorecard 块在三个场景的 Without-Skill 输出中均不存在（0/3）；第三，场景 3（benchstat 数据分析）Without-Skill 得分意外偏高（6/8，75%）——这一发现揭示了 skill 对统计分析型任务的增量价值有限，真正的杠杆在于基准代码的写作和审查。

1. Skill 概述¶

go-benchmark 定义了 5 条 Hard Rules（静默腐化防护）、3 个 Mandatory Gates（Evidence / Applicability / Scope）、三阶段工作流（Write → Run & Profile → Analyze & Optimize）、4 字段 Output Contract、以及 Auto Scorecard 三层门禁（Critical / Standard / Hygiene）。

核心组件:

回归测试总量：96 项（65 contract + 30 golden + 1 integrity），所有关键维度覆盖率 100%。

2. 测试设计¶

2.1 场景定义¶

三个场景对应 SKILL.md 定义的三种工作模式，取自真实用户会话原型：

2.2 断言矩阵（24 项）¶

场景 1 — Phase 1: 从源码写基准（9 项）

*A5 注：Without-Skill 提供了 7 个独立的 Encode 基准函数覆盖不同输入，但使用的是平铺式顶层函数而非 b.Run() 形式的 size sweep，PASS（实质覆盖了多种尺寸，形式不同）。

场景 2 — Phase 1+2: 审查有缺陷的基准（7 项）

场景 3 — Phase 3: 分析 benchstat 噪声数据（8 项）

2.3 触发准确率分析¶

当前 description 采用双层触发策略：

Go performance benchmarking and pprof profiling specialist. ALWAYS use when
writing benchmark functions (testing.B), generating or reading pprof profiles,
interpreting flame graphs, finding memory allocation hotspots, comparing
implementations with benchstat, or measuring ns/op / B/op / allocs/op.
In Go code contexts, also trigger when the user says "it's slow", "too many
allocations", "find the bottleneck", or "profile this Go code".

• 显式触发词（确定性高）：testing.B、pprof profiles、flame graphs、benchstat、ns/op、B/op、allocs/op
• 隐式触发词（上下文感知）："it's slow"、"too many allocations"、"find the bottleneck"——通过「In Go code contexts」限定词防止非 Go 场景误触发

Should-Trigger 场景（10 个）

Should-Not-Trigger 场景（8 个）

触发准确率估算：F1 ≈ 88%（should-trigger 10/10 覆盖；should-not-trigger 6/8 精准拒绝，N7/N8 属于合理触发边界）

3. 通过率对比¶

3.1 总体通过率¶

通过率提升：+54 百分点

3.2 按场景通过率¶

重要发现：场景 3 的 Without-Skill 得分（75%）显著高于场景 1（22%）和场景 2（43%）。这揭示了一个非对称价值分布：基线 Claude 在统计概念理解（p 值、CV 阈值）方面已相当能干，skill 对「分析型任务」的增量价值有限（+25pp）；真正的杠杆在于「代码写作/审查型任务」，这是基线最容易犯隐性错误的领域（+57–78pp）。

3.3 实质性维度（去除结构性流程断言，12 项）¶

实质性通过率（严格）：With-Skill 12/12 (100%) vs Without-Skill 7/12 (58%)，提升 +42pp。

4. 关键差异分析¶

4.1 With-Skill 独有的行为（Without-Skill 完全缺失）¶

4.2 Without-Skill 能做到但质量较低的行为¶

4.3 场景级关键发现¶

场景 1（从源码写基准）: - With-Skill：Evidence Gate 声明 write / static analysis only；Scope Gate 选择多 size 子基准（64B/1KB/64KB/1MB）；声明 var sinkString string + var sinkErr error（附编译器消除解释）；所有 Decode 调用使用 sinkString, sinkErr = Decode(...)；run 命令：-benchmem -count=5（探索）和 -count=10（对比）；Auto Scorecard：Critical ✅✅✅ Standard 5/5 Hygiene 4/4。 - Without-Skill：使用 for b.Loop() 新语法（Go 1.24+）并解释其优势。提供了 7 个平铺 Encode 基准覆盖不同输入特征（空/单字符/无重复/短重复/长重复/混合）——覆盖思路清晰。但：基准函数内完全没有使用 sink 变量，结果直接被 b.Loop() 抛弃；Decode 结果同样未捕获；run 命令缺 -count；无 Evidence Gate / Scorecard / Output Contract。值得注意的是，Without-Skill 在注释中提到「assign the return to package-level sink variables if you observe suspiciously fast numbers」——将 sink 定性为可选的后备手段，而非必须的预防规则。

场景 2（审查有缺陷的基准）: - With-Skill：系统列出 4 处违规（3 Critical + 1 Standard），每处按 Hard Rule 编号、违规行、机制解释、修复代码：Violation 1 的解释明确点出「compiler is permitted to optimize away the entire json.Marshal call」；修正文件使用 var sinkBytes []byte; var sinkErr error，所有调用改为 sinkBytes, sinkErr = json.Marshal(u)；Scorecard 显示 Critical ❌❌❌（审查的是已违规代码，分显示原状态）。 - Without-Skill：在「Critical Bug」节正确识别了 b.ResetTimer() in loop；在「Minor」节提到 -benchmem 和建议 -count=5。关键缺失：_ = data 被描述为「safe here」因为 json.Marshal 不会失败——这混淆了错误处理安全性和编译器优化风险，导致修正文件仍保留了 _ = data，根本问题未被修复。

场景 3（分析 benchstat 数据）: - With-Skill：Evidence Gate 分类为 analyze / benchmark output；完整覆盖 C1-C6 的所有统计分析；额外提供 pprof diff 命令（-diff_base mem-old.prof mem-new.prof）和超线性分配增长的分析（allocs 比率：1×/3.7×/14.8× vs 输入 1×/4×/16×）；Auto Scorecard 标注 Standard 3/5（缺 -count=10 和 alloc 目标）。 - Without-Skill：同样正确覆盖了 C1-C6 的所有统计断言，质量和深度与 With-Skill 相当。提供了明确的 -count=20 -benchtime=3s 建议和统计功效估算（「需要约 15-20 个样本才能以 80% 功效检测 7% 的改进」）。唯一缺失：Auto Scorecard 和 Output Contract 字段。

5. Token 效费比分析¶

5.1 实测 Token 消耗（6 个评估代理）¶

With-Skill 均值：30,312 tokens，137.2s，7 tool uses/eval Without-Skill 均值：20,762 tokens，75.7s，5 tool uses/eval 额外 token 开销：+9,550 tokens/eval（+46%） 额外时间开销：+61.5s/eval（+81%）

5.2 Skill 上下文成本¶

5.3 效费比计算¶

5.4 与其他 Skill 效费比对比¶

go-benchmark 效费比低于 git-commit 的原因分析：

1. SKILL.md 更长（378 vs 169 行）：Anti-Examples 内联（3 组 BAD/GOOD）、Auto Scorecard 模板、Output Contract 表格占用约 100 行
2. 通过率提升绝对值较小（+54pp vs +77pp）：场景 3 的 Without-Skill 已达 75%，大幅拉低了整体提升幅度
3. 运行时开销更高（+46% tokens，+81% 时间）：3 个 Gates 的执行、4 字段 Output Contract 的声明、详细 Scorecard 输出均增加了 token 消耗

重要上下文：如果仅看 go-benchmark 真正擅长的场景（Phase 1 + Phase 2），对应提升为 +78pp 和 +57pp，效费比将接近 git-commit 水平。+54pp 的整体数字被场景 3 的低增量（+25pp）稀释。

6. 综合评分¶

6.1 分维度评分¶

6.2 加权总分¶

7. 结论¶

go-benchmark 在三个场景共 24 项断言中实现 100% 通过，与 Without-Skill（46%）相比提升 +54pp。评估揭示了一个非对称价值分布：

高价值区（Phase 1 + Phase 2，代码写作/审查）： - Phase 1 提升 +78pp：Without-Skill 在实际 benchmark 代码中完全未使用 sink 变量，或将其标注为可选后备手段；sink 的系统性缺失是静默的、无法从运行结果直接发现的错误 - Phase 2 提升 +57pp：Without-Skill 对 _ = data 的判断（「safe here」）在技术上具体而言并非完全错误，但导致整个修正文件的 sink 问题未被根治——展示了原则性理解 vs 场景性判断的差距

低价值区（Phase 3，统计分析）： - Phase 3 提升 +25pp：Without-Skill 在 p 值、CV 阈值、显著性判断方面表现相当，skill 主要增量来自 Scorecard 和 Output Contract 结构化输出，而非实质性分析能力

核心价值点: 1. 静默腐化防护：_ = encode(input) 看起来合法、编译通过、无报错，但编译器在特定优化 pass 可以完全消除该调用，benchmark 则变成测量循环开销。这是 Baseline 在高频易犯、难以自检的盲区，Hard Rule #1 是唯一可靠保障 2. Evidence Gate：在用户「什么都没提供」时（golden fixture BENCH-009），强制触发降级路径，阻止推测性分析 3. 输出一致性：Output Contract + Auto Scorecard 确保跨用户、跨会话的输出格式可预期，是 Baseline 完全缺失的结构化质量报告机制

改进建议: 1. 提高场景 3 增量价值：benchstat-guide.md 可增加「超线性分配增长」（allocs 与输入尺寸比例分析）和 pprof diff 工作流，使统计分析输出超出 Baseline 的自然上限 2. Auto Scorecard 可精简：将模板（约 40 行）移入 reference file，SKILL.md 保留指针，预计节省 ~200 tokens 改善效费比 3. 触发准确率：当前 F1≈88%，主要短板在隐式触发词（「my Go service has high memory usage」）的边界。可考虑在 description 中增加一条负向示例（「not for general Go debugging or unit testing」）以降低误触发