tdd-workflow Skill 评审报告¶

评估框架: skill-creator 评估日期: 2026-03-11 评估对象: tdd-workflow

tdd-workflow 是一个面向 Go 代码改动的端到端 TDD skill，用于把“先写失败测试、再最小实现、最后安全重构”真正落实到具体工作流中，特别适合功能新增、缺陷修复和安全敏感逻辑测试。它最突出的三个亮点是：要求 Defect Hypothesis 与测试用例一一映射，先明确“要抓什么 bug”再写测试；强制保留 Red → Green → Refactor 的证据链，保证 TDD 过程不是口头宣称；同时通过 Killer Case 和覆盖率 / 风险路径门禁，把测试从“能跑”提升到“能抓到关键缺陷”。

一、评估概览¶

本次评估从实际任务表现和 Token 效费比两个维度对 tdd-workflow skill 进行全面评审。设计 3 个场景（S-size yamlQuote 边界测试、M-size normalizeSummaryJSON 三函数测试、M-size IsPrivateIPLiteral 安全测试），每个场景分别运行 with-skill 和 without-skill 配置，共 3 场景 × 2 配置 = 6 次独立 subagent 运行，对照 39 条 assertion 进行评分。

二、测试方法¶

2.1 场景设计¶

2.2 目标选择理由¶

• 全部使用 stdlib 断言（项目 constitution 规定不用 testify）——测试 skill 对项目断言风格的适配
• 函数已存在但缺直接单元测试——测试 skill 处理"characterization testing"（对已有代码补测试）的能力
• 覆盖不同复杂度——从 4 LOC 纯函数到 12 LOC 多分支安全函数

2.3 执行方式¶

• With-skill 运行先读取 SKILL.md 及选择性加载参考资料
• Without-skill 运行不读取任何 skill，按模型默认行为
• 所有运行在独立 subagent 中并行执行

三、Assertion 通过率¶

3.1 总览¶

3.2 逐项 Assertion 详情¶

Eval 1: yamlQuote S-size (12 assertions)¶

Eval 2: normalizeSummaryJSON M-size (14 assertions)¶

Eval 3: IsPrivateIPLiteral M-size (13 assertions)¶

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

关键观察: 所有 18 条失败均为 TDD 方法论产物，而非测试代码质量问题。Without-skill 的测试代码本身质量不低（Eval 1 甚至产出了 15 个测试案例 vs With-skill 的 7 个），但缺乏 TDD 流程证据和结构化报告。

3.4 Delta 稳定性¶

三个场景的 delta 高度一致（+42.9% ~ +50.0%），说明 skill 的贡献不依赖特定任务类型，而是系统性地注入 6 类 TDD 方法论产物。

四、逐维度对比分析¶

4.1 Defect Hypothesis → Test Mapping（核心差异化）¶

这是 TDD skill 最独特的贡献——要求先列假设再写测试。

实际价值: Defect hypothesis 不只是报告装饰——它驱动了更有针对性的测试设计：

• Eval 3 的 H1（IPv4-mapped IPv6 bypass）是 Without-skill 完全缺失的测试角度。::ffff:127.0.0.1 和 ::ffff:10.0.0.1 是真实 SSRF 攻击向量，Without-skill 的 36 个测试无一涉及。
• Eval 2 的 DH5（nested braces 提取边界）是 Index/LastIndex 算法的关键测试，Without-skill 有该测试但无假设理由。

4.2 Red → Green 证据¶

关键差异: 对于已有代码的补测试场景（characterization testing），Skill 仍要求展示 Red evidence——Eval 1 通过 mutation 展示，Eval 2-3 通过 hypothesis 展示。Without-skill 只展示 "all pass"，无法证明测试真正验证了什么。

4.3 Killer Case 机制¶

With-skill 总共产出 6 个 killer cases，每个包含 4 部分结构：

1. Defect hypothesis — 要验证/证伪的具体缺陷假设
2. Fault injection — 如何触发该缺陷（mutation 或攻击输入）
3. Critical assertion — 必须成功的关键断言
4. Removal risk — 如果删除此测试的风险

Without-skill 的测试虽然覆盖了边界，但缺乏 SSRF 攻击视角（Eval 3）和缺乏 mutation 驱动的回归防护（Eval 1）。

4.4 测试代码质量（双方接近）¶

值得注意的是，Without-skill 的测试代码质量本身不低：

Without-skill 在 Eval 1 产出了更多测试案例（15 vs 7），甚至覆盖了 YAML metacharacters 这个 With-skill 未涉及的角度。但它缺乏方法论框架——没有假设、没有 red evidence、没有 coverage 报告、没有 killer case。

结论: Skill 的核心价值不在于生成更多/更好的测试代码，而在于注入TDD 方法论纪律和结构化交付物。

4.5 Residual Risks 分析（Eval 3 亮点）¶

With-skill 的 Eval 3 报告列出了 4 个 residual risks：

1. CGNAT (100.64.0.0/10) — 当前 returns false，如果威胁模型包含共享地址空间需扩展
2. IPv6 zone IDs — fe80::1%eth0 的上游处理不确定
3. DNS rebinding — hostname 解析绕过的设计限制
4. Octal/hex IP notation — 0177.0.0.1 的 TOCTOU 风险

这些风险分析是 Without-skill 完全缺失的，对安全敏感代码尤为重要。

五、Token 效费比分析¶

5.1 Skill 体积¶

5.2 实际加载场景¶

5.3 Token 换取的质量提升¶

5.4 与其他 Skill 效费比对比¶

分析:

• 绝对提升第二高 (+46.2%) — 仅次于 e2e-test 的 +48.7%
• 典型加载效费比优秀 (~78 tok/1%) — 全系列第三，仅次于 git-commit (~51) 和 thirdparty-api-integration-test (~62)
• SKILL.md 效费比良好 (~52 tok/1%) — 与 git-commit (~51) 接近
• 参考资料精简高效 — 4 个参考文件总计 ~2,800 tokens，每个文件都有明确的使用场景

5.5 Token 分段效费比¶

5.6 Token 效率评级¶

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

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

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

七、综合评分¶

7.1 分维度评分¶

7.2 加权总分¶

测试代码质量增量评分较低是因为 Without-skill 的测试代码本身质量不低——Skill 的核心价值在方法论纪律而非代码生成。

八、评估材料¶