fuzzing-test Skill 评审报告¶

评估框架: skill-creator 评估日期: 2026-03-12 评估对象: fuzzing-test

fuzzing-test 是一个专门为 Go 代码生成高信号 fuzz 测试的 skill，适合用于 parser、编解码、状态转换和其他具备明确不变量的目标，同时也适用于判断某个目标是否根本不值得做 fuzz。它最突出的三个亮点是：先执行 Applicability Gate，再决定是否进入生成流程，避免“见函数就写 fuzz”；对于不适合 fuzz 的目标会明确拒绝并给出替代方案，而不是勉强产出低价值代码；同时内置目标优先级、成本分级和结构化输出，能把 fuzz 测试做得更可控、更有性价比。

一、评估概览¶

本次评估从实际任务表现和 Token 效费比两个维度对 fuzzing-test skill 进行全面评审。设计 3 个覆盖不同场景的 fuzz test 生成任务（适合的 parser 目标、不适合的网络依赖目标、多候选函数的包级评估），每个场景分别运行 with-skill 和 without-skill 配置，共 3 场景 × 2 配置 = 6 次独立 subagent 运行，对照 35 条 assertion 进行评分。

二、测试方法¶

2.1 场景设计¶

2.2 执行方式¶

• 以 issue2md 项目为基础，为每个场景创建独立副本（/tmp/fuzz-eval-*）
• With-skill 运行先读取 SKILL.md 及其引用的参考资料
• Without-skill 运行不读取任何 skill，按模型默认行为处理
• 所有运行在独立 subagent 中并行执行

2.3 场景详情¶

Eval 1 — parser.Parse（适合目标）

Parse(rawURL string) (ResourceRef, error) 是一个经典的 Tier 1 fuzz 目标： - 接受 string 输入（Go fuzz 原生类型） - 纯函数，无 IO/网络/状态依赖 - 有多个可验证的不变量（Owner 非空、Number > 0、Type ∈ 有效集、canonical URL 一致性、重解析幂等性） - 快速执行（亚微秒级）

Eval 2 — fetcher.Fetch（不适合目标）

Fetch(ctx, ref, opts) (IssueData, error) 是一个经典的不适合 fuzz 的目标： - 所有代码路径都发起真实 HTTP 请求 - 依赖 GitHub API token 认证 - 包含 retry + backoff 逻辑 - 有趣的输入空间是 API 响应，而非方法参数

Eval 3 — converter 包（多候选）

包含 5 个候选函数，其中 4 个适合、1 个不适合： - ✅ yamlQuote(string) string — YAML 转义，有 round-trip 不变量 - ✅ normalizeSummaryJSON(string) (string, error) — JSON 提取器，有 json.Valid 不变量 - ✅ detectSummaryLanguage(string) string — Unicode 分析，有有限返回值集不变量 - ✅ capSummarySourceLength(string) string — rune 截断，有长度上界不变量 - ❌ Summarize(ctx, data, lang) — OpenAI HTTP 调用，网络依赖

三、Assertion 通过率¶

3.1 总览¶

3.2 逐场景 Assertion 详情¶

Eval 1: parser-fuzz (15 条)¶

Eval 2: fetch-reject (7 条)¶

Eval 3: converter-multi (13 条)¶

3.3 Without-Skill 失败的 19 条 Assertion 归类¶

3.4 关键发现：Eval 2 的 +100pp Delta¶

这是所有已评估 skill 中单场景最大差异。原因分析：

With-Skill 行为： - 运行 5 项 Applicability Gate - 标记 Check 1/3/4/5 为 Fail（尤其 Check 3 — 无 oracle — 触发 Hard Stop） - 产出 "Not suitable" 判定 - 推荐 4 种替代策略，包括"fuzz 该包中的纯映射函数"

Without-Skill 行为： - 未运行 gate，直接分析如何让 fuzz 工作 - 创造性地构建了 fuzzRoundTripper（自定义 http.RoundTripper）来 stub HTTP 层 - 实际上 fuzz 的是 GraphQL JSON 解析路径，而非 Fetch 方法本身 - 唯一的 oracle 是 "no panic"

评价：Baseline 的方案有实际价值（能发现 JSON 解析中的 panic），但从 fuzz 测试最佳实践角度看存在问题： 1. Oracle 仅为 "no panic"，无法发现逻辑 bug（invariant violation） 2. 测试的实际是 JSON parsing 路径，而非请求的 Fetch 方法 3. 未告知用户"这不是最优策略"，错过了引导用户 fuzz 纯函数的机会

Skill 的 gate 机制确保了诚实的工程决策：不适合就不做，推荐更好的替代方案。

四、逐维度对比分析¶

4.1 Applicability Gate（适用性判断）¶

这是 skill 最核心的差异化能力，在全部 3 个场景中都产生了直接影响。

实际价值： - Applicability Gate 防止了无效 fuzz test 的生成（Eval 2 节省了写 + 维护无价值测试的成本） - 结构化 checklist 使决策过程可审计、可复现 - 在 Eval 3 中确保了"先评估、再编码"的工作流

4.2 Size Guard 系统性覆盖¶

分析：Skill 的 "Size guard present" 规则（SKILL.md Template A/B/C/D 中均有示范）确保了所有 string/[]byte 参数的 harness 都有边界保护。Without-skill 在 Eval 1 中甚至更多 seed（29 vs 19），但缺少 size guard，在长时间 fuzz 运行中可能遭遇 OOM。

4.3 Output Contract（结构化报告）¶

With-Skill 的每次运行产出包含以下内容的结构化报告：

Without-Skill 产出叙述性摘要，但无标准化结构。

4.4 Fuzz 代码质量对比¶

以 Eval 3 为例（最能体现代码质量差异的场景），对比 FuzzYamlQuote：

代码质量在 oracle 设计上高度相似，证明 Claude 基础模型对 fuzz 代码生成已有较强能力。Skill 的主要增量在于流程规范（gate、cost class、size guard、output contract）而非代码本身。

4.5 替代策略推荐能力¶

Eval 2 中 With-Skill 推荐了 4 种替代策略：

1. Integration tests with real GitHub token (gated) — 门控集成测试
2. Unit tests with HTTP stubbing — httptest.Server 桩测试
3. Fuzz the pure mapping functions instead — fuzz 纯映射函数（如 mapIssueTimelineNode）
4. Table-driven unit tests for the dispatcher — 表驱动单元测试

这些推荐不仅拒绝了不合适的方案，还引导用户找到更有价值的测试路径。Without-Skill 直接构建了 workaround（虽然有价值，但未告知用户存在更优选择）。

五、Token 效费比分析¶

5.1 Skill 体积¶

5.2 加载场景¶

5.3 Token 换取的质量提升¶

5.4 Token 分段效费比¶

5.5 高杠杆 vs 低杠杆指令¶

高杠杆（~930 tokens SKILL.md → 19 条 assertion 差值，占 SKILL.md 23%）: - Applicability Gate + Hard Stop 规则（400 tok → 9 条） - Output Contract 定义（200 tok → 3 条） - Cost Class + Quick Commands（100 tok → 3 条） - Templates 中的 size guard 示范（150 tok → 2 条） - Fuzz Mode 分类 + Target Priority（80+150 tok → 2 条）

中杠杆（~700 tokens → 间接贡献）: - Quality Scorecard（200 tok）— 驱动自检流程 - Anti-Examples（500 tok）— 避免常见错误

低杠杆（~950 tokens → 0 条差值）: - Coverage Feedback 区（400 tok）— 未在评估场景中使用 - Go Version Gate（200 tok）— 未在评估场景中使用 - Troubleshooting 区（350 tok）— 未在评估场景中使用

参考资料（~3,460 tokens → 间接贡献）: - applicability-checklist.md（1,250 tok）— 强化 gate 判断质量，提供具体示例 - target-priority.md（1,170 tok）— 提供 Tier 排序依据 - crash-handling.md + ci-strategy.md（1,040 tok）— 未在评估中直接贡献

5.6 Token 效率评级¶

5.7 与其他 Skill 的效费比对比¶

分析： - fuzzing-test 的 delta 最大（+54.3%），主要得益于 Eval 2 的 +100pp 极端差异 - SKILL.md 效费比（~75 tok/1%）处于中等水平，高于 create-pr（38）和 go-ci-workflow（45），但低于 go-makefile-writer（63） - 典型加载效费比（~120 tok/1%）优于 go-makefile-writer 和 go-ci-workflow，但低于 create-pr - SKILL.md 体积（679 行 / ~4,100 tokens）是所有已评估 skill 中最大的，但其 delta 也最大

六、与 Claude 基础模型能力的边界分析¶

6.1 基础模型已具备的能力（Skill 无增量）¶

6.2 基础模型的能力缺口（Skill 填补）¶

七、综合评分¶

7.1 分维度评分¶

7.2 加权总分¶

7.3 与其他 Skill 综合评分对比¶

分析： - fuzzing-test 的拒绝能力（+5.0 差值）是所有已评估维度中最大的单维度差异 - +54.3pp 的 delta 也是所有 skill 中最高的，证明了 Applicability Gate 的独特价值 - Token 效费比得分（6.0/10）偏低，主要因为 SKILL.md 体积较大（679 行）且含 ~950 tokens 低杠杆区

八、结论¶

fuzzing-test skill 在三个核心领域提供了显著价值：

1. Applicability Gate 的拒绝能力（+100pp 单场景 delta）：这是所有已评估 skill 中单场景最大差异，证明了 "何时不该做" 的工程决策能力是 Claude 基础模型最大的缺口。Baseline 面对不适合的目标时，会创造性地构建 workaround（虽然有价值），但未告知用户存在更优策略。

2. 系统性 Size Guard 覆盖（5/5 vs 0/5）：Skill 的模板和规则确保了所有 string/[]byte 参数 harness 都有长度边界保护，防止长时间 fuzz 运行中的 OOM。这是一个容易遗漏但在生产中影响巨大的实践。

3. 结构化 Output Contract：Quality Scorecard（Critical/Standard/Hygiene 三级检查）使 fuzz test 的质量可量化、可审计。

主要风险：SKILL.md 体积 (~4,100 tokens) 是所有已评估 skill 中最大的，其中 ~23%（~950 tokens）为低杠杆区域。通过精简 Coverage Feedback、Troubleshooting、Anti-Examples 和 Go Version Gate，可减少 ~29% 的 SKILL.md token 开销，将典型加载效费比从 ~120 tok/1% 改善至 ~76 tok/1%。

九、评估材料¶