fuzzing-test skill 解析¶

fuzzing-test 是一套面向 Go fuzz 测试的高信号决策与生成框架。它的核心设计思想是：fuzz 的关键在于先判断目标是否值得 fuzz、是否能被 fuzz 驱动、有没有明确 oracle、成本是否可控，然后再决定是否进入生成流程。 因此它把适用性门禁、目标优先级、风险与成本、执行真实性、崩溃处理和结构化输出串成一条明确的工程路径。

1. 定义¶

fuzzing-test 用于 Go 代码中的以下场景：

• 为 parser、decoder、protocol handler 生成 fuzz 测试
• 为 round-trip codec、validator、state transition 目标设计 property/oracle
• 在多个候选目标之间做优先级判断
• 明确拒绝不适合 fuzz 的目标，并给出替代方案
• 在发现 crash 后保留 corpus、补回归、说明根因
• 为 fuzz 测试设计本地与 CI 的成本策略

它输出的不只是 fuzz 代码，还包括：

• Applicability Verdict
• 适用性判断依据
• Action（继续实现、停止、或转向其他测试策略）

当目标适合 fuzz 并进入实现流程时，高质量交付通常还会补充：

• 成本等级与建议的 fuzz 时间预算
• 执行状态与命令
• 质量评分与 corpus 策略

从设计上看，它更接近“fuzz 工程决策框架”，而不是一个只负责生成 testing.F 样板的提示词。

2. 背景与问题¶

这个 skill 要解决的，不是“大家不会写 f.Fuzz(...)”，而是 Go fuzzing 在真实项目里经常出现两个极端：

• 明明目标不适合 fuzz，却仍强行写 harness
• 明明目标适合 fuzz，却只写出一个能跑但 bug-finding yield 很低的基础版本

如果没有清晰框架，常见问题通常集中在 8 类：

fuzzing-test 的设计逻辑，就是先把“要不要 fuzz”判断清楚，再把“怎么 fuzz 才有价值”系统化。

3. 与常见替代方案的对比¶

先看它与几种常见做法的区别：

它的价值，不只是“能生成 fuzz code”，而是把 fuzzing 从一次性的代码补丁，提升成可决策、可审计、可治理的测试工作流。

4. 核心设计逻辑¶

4.1 适用性门禁 必须放在最前面¶

fuzzing-test 的第一原则是：在写任何 fuzz 代码之前，必须先做 适用性门禁。

它要求逐项判断 5 个条件：

1. 是否有 meaningful input space
2. 是否能被 Go fuzz 支持的参数类型驱动
3. 是否有 clear oracle / invariant
4. 是否足够 deterministic / local
5. 是否足够快，适合高迭代 fuzz

这层设计非常关键，因为 fuzz 的最大浪费，不是“写得不够漂亮”，而是从一开始就选错目标。评估报告里 Eval 2 的巨大差异，正是由这一层带来的：with-skill 会明确拒绝 network-dependent target，而 without-skill 会创造性地构造 workaround，结果虽然“能跑”，但方向已经偏离最佳 bug-finding 路径。

4.2 Check 2 和 Check 3 要作为 Hard Stop¶

适用性门禁 里最重要的两项是：

• Check 2：目标能否被 Go fuzz 原生参数类型有效驱动
• Check 3：目标是否存在明确 oracle

skill 把这两项设为 Hard Stop，不通过就直接停止。这是一个非常强的设计决策，因为：

• 没有 fuzz-compatible type，说明 native fuzz harness 根本抓不住输入空间
• 没有 oracle，说明就算跑了很多轮，也无法判断逻辑错误

这也是很多“看似有 fuzz test，实际上只有 no panic smoke test”的根源。fuzzing-test 明确拒绝这种表面化 fuzz。

4.3 强调“先判断是否该拒绝” vs 默认尽量凑一个 workaround¶

这个 skill 最有辨识度的地方，不是生成能力，而是拒绝能力。

面对不适合 fuzz 的目标，很多模型会倾向于：

• stub 一层 HTTP / DB
• 修改输入边界，勉强造一个 harness
• 把目标拆到只剩一个弱化后的 no-panic path

这些做法不是完全没价值，但它们很容易掩盖一个更重要的工程事实：当前请求的这个目标，并不一定是最值得 fuzz 的对象。

fuzzing-test 的当前契约是：当 Check 2 或 Check 3 失败时，直接 Hard Stop；当目标主要受外部依赖影响时，优先提醒风险、建议改测更纯的层，只有在 fully stubbed 且仍有强 oracle 的前提下才保留继续的空间。也正因为如此，它会先把适用性事实说清楚，再推荐更合适的替代策略，比如：

• fuzz 纯 parser / mapping 函数
• 用表驱动单元测试覆盖 trivial path
• 用 integration test 覆盖真实 DB / network 依赖
• 用 property-based testing 处理复杂生成器约束

这让它更像一个测试决策助手，而不是一个“永远想办法给你产出代码”的代码生成器。

4.4 “目标优先级门禁”要单独保留¶

当包内有多个候选目标时，fuzzing-test 不会默认“全都 fuzz 一遍”，而是要求按 bug-finding yield 排序：

1. Tier 1：parsers / decoders / protocol handlers / compression / encoding
2. Tier 2：round-trip encode / decode、validators / sanitizers、strict invariant state transitions
3. Tier 3：differential comparison、formatters / renderers、普通 configuration loaders

这种排序很有工程价值，因为 fuzz 预算总是有限的。优先级机制解决的不是“哪个函数更好看”，而是“哪个函数最可能在有限预算里找到真正的 bug”。

这也是 references/target-priority.md 会被单独拆出来的原因。它不是补充说明，而是成本分配依据。

4.5 size guard 被当成硬性质量要求¶

当前 skill 的 质量评分卡 把 size guard 列在 Critical 项里，要求所有 []byte / string harness 都有边界控制。

这是一个特别实用的设计。很多 baseline fuzz 代码在 oracle 和 seed 上看起来没问题，但缺少：

• len(data) > N
• t.Skip() 跳过不可能组合
• 对重型 payload 的上界限制

短时间运行可能没问题，但一旦进入长时间 fuzz、CI 定时任务或多 worker 并发，OOM 和 allocation blow-up 风险就会迅速放大。评估也很清楚地表明，with-skill 在这一项上是系统覆盖，而 without-skill 经常遗漏。

4.6 seed mining 被设计成“先挖真实数据，再写 f.Add(...)”¶

fuzzing-test 明确要求在写 f.Add(...) 前先做 seed mining：

• 从现有单测里提取真实输入
• 从 testdata/、fixtures、samples、golden 文件里找代表性数据
• 从真实配置或生产近似数据文件里抽取 payload

这个设计非常重要，因为 seed 并不是“随手写几个例子”那么简单。真实 seed 的价值在于：

• 帮助 mutator 更快进入有意义的结构空间
• 降低 skip rate
• 提升初始覆盖深度

skill 甚至要求每个 target 的 seed 至少覆盖 3 类结构，这说明它关注的不只是“有 seed”，而是“seed 是否真的有探索价值”。

4.7 “风险与成本门禁”要把 fuzz 时间预算显式化¶

fuzzing-test 要求先给 target 分成 Low / Medium / High 三档，并对应不同预算策略：

• Low: 本地 30-60s
• Medium: 本地 15-45s + 更严格 guard
• High: PR 只跑 corpus replay，真正 fuzz 留到 nightly / scheduled

这是一个成熟的设计，因为 fuzz 不是越久越好，而是要看：

• target 每次调用的成本
• skip rate
• memory profile
• CI 能否承受持续开销

把成本分级做成显式输出，能帮助团队把 fuzz 从“个人实验”转成“可规划的测试资产”。

4.8 把 native fuzzing 和 property-based testing 的边界讲清楚¶

fuzzing-test 明确区分：

• 适合 native fuzz 的：字节、字符串、parser、crash discovery
• 适合 property-based testing 的：复杂生成器、强 domain constraint、过高 skip rate

这层边界非常重要，因为很多 Go 测试问题并不是“该不该做生成式测试”，而是“该选 fuzz 还是 property-based”。

skill 的做法不是争论哪种方法更先进，而是按目标结构选择更合适的工具。这也是它比“只会写 fuzz harness”的提示词更成熟的地方。

4.9 “崩溃处理”要求保留 corpus 并补 deterministic regression¶

当 fuzz 找到 crash 时，fuzzing-test 要求做完整闭环：

1. 记录最小复现命令
2. 保留 crashing corpus
3. 标记 failure type
4. 用最小代码修复
5. 回放 corpus + 短时间 fuzz 重跑
6. 说明 root cause 和 prevention guard

这一层非常有价值，因为 fuzzing 最大的收益通常不是“跑了多久”，而是“找到 bug 以后有没有真的沉淀下来”。如果 crash input 没进 testdata/fuzz/FuzzXxx/，那这次发现很容易在以后重新出现。

4.10 references 采用选择性加载 vs 每次全量展开¶

fuzzing-test 的 references 结构很克制：

• applicability-checklist.md 只在边界场景加载
• target-priority.md 只在有 3 个及以上候选目标需要排序时加载
• crash-handling.md 只在发现 crash 后加载
• ci-strategy.md 只在用户要求接入 CI 时加载
• advanced-tuning.md 只在调性能、OOM、leak、flaky run 时加载

这种设计非常合理，因为 fuzz 任务差异很大。大多数普通生成任务，只需要 适用性门禁 和模板；只有在 crash / CI / tuning 这些重场景里，才需要额外上下文。

这是一种很典型的生产级 skill 结构：默认上下文保持紧凑，高成本细则按需加载。

4.11 Go 版本门禁、race、parallelism 都被纳入同一套框架¶

当前 skill 不只讨论 testing.F 写法，还额外纳入了：

• Go 版本门禁
• race detection + fuzz
• fuzz worker parallelism
• go-fuzz-headers bridge
• fuzz performance baseline

这说明它设计上的目标已经超出“生成基础 harness”，而是试图覆盖 fuzz 生命周期里的真实工程问题：

• 当前 Go 版本是否支持或适合某种写法
• 并发路径要不要加 -race
• worker 数量会不会掩盖 determinism 问题
• struct-aware 输入该不该从 []byte 反序列化
• 当前 execs/sec 是否足以支持更长 fuzz 时间

这让它更像一套 fuzz engineering handbook，而不是单次代码生成模板。

5. 这个设计解决了哪些具体问题¶

结合当前 SKILL.md、references 和评估报告，可以把它解决的问题归纳为：

6. 主要亮点¶

6.1 “先判断该不该 fuzz” 是整个 skill 的核心¶

这也是 fuzzing-test 最大的差异化来源。评估里最明显的收益，不是 fuzz 代码写得更复杂，而是它知道什么时候应该停。

6.2 对不适合目标的拒绝非常坚决¶

很多模型在面对不适合目标时仍会尽量拼出代码。fuzzing-test 选择先保护工程决策质量，再保护代码产出数量。

6.3 把 size guard、cost class、quick commands 都制度化了¶

这些内容单看都不复杂，但组合起来，能显著提升 fuzz 的长期可运行性和团队可用性。

6.4 很重视真实 seed 和真实结构¶

它没有把 f.Add(...) 当成装饰，而是把 seed 质量视为探索效果的关键因素。

6.5 crash 处理有完整闭环¶

从保留 corpus 到回归验证再到说明 prevention guard，这让 fuzz 结果不会停留在“一次偶然发现”。

6.6 当前版本比评估快照更强调运行工程化¶

评估报告最强地验证了它在 适用性门禁、拒绝能力、size guard 和结构化输出上的价值。与此同时，当前 SKILL.md 还进一步补充了 Go 版本门禁、-race、worker parallelism、go-fuzz-headers bridge 和 performance baseline。也就是说，评估验证了核心方向，而当前 skill 已把这套设计扩展到了更完整的 fuzz 工程实践。

7. 什么时候适合用，什么时候不该硬用¶

8. 结论¶

fuzzing-test 的真正亮点，不是它能写出一个 FuzzXxx 模板，而是它把 fuzz 测试里最容易被忽略的工程判断系统化了：先通过 适用性门禁 判断值不值得做，再用优先级和成本分级决定先做什么、做多深，随后用 size guard、真实 seed、强 oracle 和 crash 闭环来保证生成物既有 bug-finding yield，也有长期维护价值。

从设计上看，这个 skill 非常清楚地体现了一条原则：高质量 fuzzing 的关键，不是多跑，而是先选对目标、设对 oracle、控好成本，并把发现沉淀成可回放的资产。 这也是它特别适合 parser、codec、validator 和多候选目标筛选场景的原因。

9. 文档维护¶

当以下内容发生变化时，这份文档应该同步更新：

• skills/fuzzing-test/SKILL.md 中的适用性门禁、风险与成本门禁、输出契约、质量评分卡或防护约束发生变化。
• skills/fuzzing-test/references/applicability-checklist.md、target-priority.md、crash-handling.md、ci-strategy.md 或 advanced-tuning.md 中的关键规则发生变化。
• skill 对 Go 版本、-race、parallelism 或 corpus policy 的建议发生明显调整。
• evaluate/fuzzing-test-skill-eval-report.zh-CN.md 中支撑本文判断的核心结果发生变化。
• skill 再次演进，导致评估快照与当前实现差异继续扩大。

建议按季度复查一次；如果 fuzzing-test 的 gate、guardrail 或 crash/CI 策略有明显重构，则应立即复查。

10. 相关阅读¶

• skills/fuzzing-test/SKILL.md
• skills/fuzzing-test/references/applicability-checklist.md
• skills/fuzzing-test/references/target-priority.md
• skills/fuzzing-test/references/crash-handling.md
• skills/fuzzing-test/references/ci-strategy.md
• skills/fuzzing-test/references/advanced-tuning.md
• evaluate/fuzzing-test-skill-eval-report.zh-CN.md