Test Maintainability Skill 设计剖析如何用评估驱动法打磨 .NET 测试维护性 Skill【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills导读skills17/skills仓库中的 exp-test-maintainability 设计笔记 记录了测试可维护性Skill 从第一轮到第四轮的真实评估迭代过程基线 LLM 在重构建议上已经接近满分Skill 的真正价值集中在判断力——识别已维护良好的测试、校准何时不该建议修改、为不直观的参数推荐 DisplayName。本文以该文档为主线结合仓库中 SKILL.md、评估配置 与评估工具的源码实现完整还原这一按数据裁剪 Skill的方法论帮助读者理解一个实验性 Skill 如何被反复打磨以及为什么克制比覆盖更多场景更重要。一、Skill 定位一个只做分析、不做修改的维护性体检工具exp-test-maintainability是dotnet-experimental插件见 plugin.json下的实验性 Skill。它的核心任务在 SKILL.md 开头便写得很明确Analyze .NET test code for maintainability issues: duplicated boilerplate, copy-paste test methods, and structural repetition across test methods and classes. Produce a report of refactoring opportunities with concrete before/after suggestions. The goal is analysis only — do not modify any files.也就是说这个 Skill只输出分析与重构建议不直接修改任何文件。这与仓库中其他 Skill 形成明确的分工边界在 SKILL.md 的 frontmatter 的description与 When Not to Use 小节中都有声明需求类型应使用的 Skill从零编写新测试writing-mstest-tests见 plugins/dotnet-test/skills/writing-mstest-tests/SKILL.md检测反模式 / 代码坏味道test-anti-patterns深度 Mock 审计exp-mock-usage-analysis见 plugins/dotnet-experimental/skills/exp-mock-usage-analysis/SKILL.md测试可维护性分析exp-test-maintainabilitySkill 支持 MSTest、xUnit、NUnit、TUnit 四种测试框架在 Step 1 通过框架标记识别测试文件框架测试类标记测试方法标记MSTest[TestClass][TestMethod]、[DataTestMethod]xUnit无约定式[Fact]、[Theory]NUnit[TestFixture][Test]、[TestCase]、[TestCaseSource]TUnit无约定式[Test]二、检测框架五大维护性问题类别与重构方向SKILL.md 的 Step 2 定义了五类可维护性问题每一类都有明确指标Indicators和候选重构Potential refactorings这是文档的核心知识资产类别 1重复的对象构造Repeated object construction指标同一个new ClassName(...)以相同或几乎相同的参数出现在 3 个测试方法中多个测试用相似配置创建同一个被测系统SUT重复的 mock/fake/stub 创建。候选重构抽取工厂方法或测试辅助方法如CreateSut()、CreateDefaultOrder()使用[TestInitialize]/构造函数/[SetUp]共享构造对多变化复杂对象引入 builder 模式。Before两个测试重复 4 行构造代码[TestMethod] public void Process_ValidOrder_Succeeds() { var logger new FakeLogger(); var email new FakeEmailService(); var inventory new FakeInventory(stock: 100); var processor new OrderProcessor(logger, email, inventory); // ... } [TestMethod] public void Process_EmptyItems_Fails() { var logger new FakeLogger(); var email new FakeEmailService(); var inventory new FakeInventory(stock: 100); var processor new OrderProcessor(logger, email, inventory); // ... }After — 抽取工厂private static OrderProcessor CreateProcessor(int stock 100) { return new OrderProcessor(new FakeLogger(), new FakeEmailService(), new FakeInventory(stock)); }类别 2重复的断言模式Repeated assertion patterns指标多个测试对结果对象断言同一组属性重复的先判 null 再判值序列多个方法中相同的Assert.AreEqual集合。候选重构抽取自定义断言辅助方法如AssertValidOrder(order, expectedTotal, expectedStatus)使用框架特定的断言扩展引入校验一组标准属性的Verify方法。类别 3复制粘贴型测试方法Copy-paste test methods指标方法体几乎相同、仅输入值或单个参数不同的 3 个方法可被折叠为[DataRow]/[Theory]/[TestCase]的方法命名呈Method_Input1_Result、Method_Input2_Result模式的方法。候选重构转换为带[DataRow]/[InlineData]/[TestCase]的参数化测试复杂输入用[DynamicData]/[MemberData]/[TestCaseSource]同时包含一条关键校准规则Prefer[DataRow]withDisplayNameover[DynamicData]when all values are compile-time constants. Reserve[DynamicData]for computed or complex values. AddDisplayNamefor non-obvious parameter values.[DataRow(Gold, 100.0, 90.0)]is self-explanatory;[DataRow(3, 7, 42)]is not.这条规则不是凭空而来的——它正是设计笔记 Round 2 中一次回归Regression的直接产物后文会详述。类别 4重复的 setup/teardown 逻辑指标多个测试类中出现相似的[TestInitialize]/[SetUp]方法体重复的数据库 seeding、文件创建或 HTTP 客户端配置跨类相同的using/IDisposable清理模式。候选重构抽取共享测试基类或 fixture用组合共享辅助类替代继承创建测试上下文工厂。类别 5重复的测试基础设施Repeated test infrastructure指标多个类中相同配置的 mock 接口重复的带相似DelegatingHandler模式的HttpClient配置跨类相同的日志/配置脚手架。候选重构抽取共享测试 fixture 或辅助库创建可复用 fake 实现引入测试工具类test harness。三、校准规则这个 Skill 真正的价值所在SKILL.md 的 Step 3 是全篇的灵魂也是设计笔记反复强调的judgment calls落点。六条校准规则原文如下只在 3 处重复时报告。两处相似 setup 不构成样板代码——它们可能是刻意的清晰表达。不要标记简单构造函数。new Calculator()或new Listint()不是有意义的样板也不要为new User(1, Alice)推荐 builder。尊重刻意的冗余。如果每个测试自包含且单独阅读清晰那么每个测试显式 setup 是合理选择——可以提及但不要当作问题标记。区分结构相似与真实重复。遵循 AAAArrange-Act-Assert的测试天然看起来相似只有当实际代码而非结构重复时才标记。考虑重构的影响半径blast radius。被 20 个测试共享的辅助方法会引入耦合需要注明这个权衡。如果测试已经维护良好就直说。一份只发现次要机会的报告完全有效先肯定已经做对的部分。这六条规则共同回答了同一个问题什么时候不重构才是正确答案。这正是文档 Key Insight 的核心结论——基线 LLM 已经擅长提出重构建议抽 builder、拆分超大测试Skill 的独特增量全部在判断层面识别维护良好的测试、校准何时不该推荐修改、为不直观的值推荐 DisplayName。四、评估迭代实录四轮打磨如何塑造这个 Skill设计笔记exp-test-maintainability-design-notes.md记录了 2026 年 3 月进行的四轮评估。理解这套数据需要先了解仓库评估工具的评分机制。4.1 评分机制质量提升 vs. Token 开销的加权博弈评估采用 Baseline无 Skill/ Isolated有 Skill/ Plugin插件模式三种运行形态对比。Comparator.cs 中定义了七维指标分解而 Models.cs 的DefaultWeights给出了默认权重指标权重TokenReduction0.05ToolCallReduction0.025TaskCompletionImprovement0.15TimeReduction0.025QualityImprovement0.40OverallJudgmentImprovement0.30ErrorReduction0.05可见质量类指标Quality Judgment合计权重高达 0.70但 Token/时间/工具调用开销仍会以合计 0.10 的权重拉低加权分。文档表格中的脚注Quality matched or improved but weighted score penalized by token overhead正是这种机制的体现当基线质量已满分时Skill 引入的任何 Token 开销都会让加权分为负——这是后续几轮删场景决策的数学根源。此外Comparator.cs 还实现了 Hake (1998) 的归一化增益公式g (post - pre) / (1 - pre)用于控制天花板效应ceiling effect当基线pre已接近 1 时即使post小幅提升增益也会被放大审视。4.2 Round 1原版 Skill 的初次评估场景BaselineIsolatedPlugin结论有选择地推荐修改4.7/55.0/55.0/5❌ ¹数据驱动模式 DisplayName4.0/55.0/54.7/5✅识别维护良好的测试4.0/55.0/55.0/5✅超大测试5.0/55.0/55.0/5❌ ¹¹ 质量持平或提升但加权分被 Token 开销拖累。第一轮透露了两个信号Skill 在数据驱动 DisplayName和识别良好测试上带来了真实质量提升而超大测试场景基线已满分Skill 无增量可贡献。4.3 Round 2裁剪后出现回归裁剪内容移除 Steps 4-5、pitfalls、验证清单。场景BaselineIsolatedPlugin结论有选择地推荐修改5.0/55.0/55.0/5❌ ²数据驱动模式 DisplayName4.0/54.6/54.4/5❌ ³识别维护良好的测试4.6/55.0/55.0/5✅² 基线触顶——与超大测试同样的问题。 ³回归——裁剪把关于DataRowDisplayName的隐性强化删掉了Skill 把模型引向[DynamicData]而非带DisplayName的[DataRow]被 rubric 扣分。这是全篇最有价值的教训裁剪 Skill 时被删内容恰恰可能是决定某些场景通过的关键隐性提示。修复方式是加一条显式校准规则当值是编译期常量时优先[DataRow]DisplayName而非[DynamicData]——即前文 Step 3 中的那条规则。4.4 Round 3加回校准规则后质量上去了但加权仍负场景BaselineIsolatedPlugin结论有选择地推荐修改5.0/55.0/55.0/5❌ ⁴数据驱动模式 DisplayName4.0/54.3/54.3/5❌ ⁵识别维护良好的测试4.7/55.0/55.0/5❌ ⁶⁴ 质量不变加权 -11.0%tokens 13388 → 35555工具调用 0 → 2耗时 16.9s → 34.6s。 ⁵ 质量提升 4.0→4.3但加权 -4.2%tokens 13148 → 30114工具调用 0 → 1耗时 15.7s → 33.6s。 ⁶ 质量提升 4.7→5.0但加权 -15.0%tokens 12736 → 37977工具调用 0 → 2耗时 17.3s → 30.4s。第三轮的数字非常直观加回的规则确实把数据驱动 DisplayName从回归拉回正增长4.0→4.3识别良好测试也到了 5.0 满分但 Skill 激活后 Token 消耗暴涨 2~3 倍、多出 1~2 次工具调用、耗时翻倍加权分全部转负。这为第四轮的激进裁剪提供了全部理由。4.5 Round 4激进裁剪为仅校准规则裁剪内容移除 When to Use / When Not to Use由 frontmatter 描述覆盖、Inputs 表、Step 1收集代码、Step 2 检测表模型原生检测已达天花板质量、Step 4报告格式。只保留标题、一行工作流和 6 条校准规则——即编码了 Skill 独特判断价值的部分。裁剪约 75% 的 Skill Token。场景BaselineIsolatedPlugin结论有选择地推荐修改5.0/55.0/55.0/5❌ ⁷数据驱动模式 DisplayName4.0/55.0/54.0/5❌ ⁸识别维护良好的测试4.3/55.0/55.0/5✅⁷ 基线触顶——与超大测试同样的问题移出评估。 ⁸ Isolated 提升但 Plugin 未提升加权 -9.4%Token 开销。四轮迭代形成了清晰结论当基线已满分时任何 Token 开销都必然使加权分为负此类场景无论怎样裁剪都无法通过只能删除。五、依据数据做出的决策与不值得添加的场景5.1 删除的评估场景超大测试场景基线 5.0/5Skill 零质量增量任何非零 Token 开销都会使加权为负无论怎么裁剪都无法通过。有选择地推荐修改场景Round 2 裁剪后基线触顶 5.0/5与超大测试同理。5.2 裁剪的 SKILL.md 输出格式与陷阱部分移除了 Steps 4-5详细报告结构、show-refactored-code 指令、验证清单和常见陷阱表。理由它们要么与 Step 3 校准规则重复要么教授的是模型原生已会的行为before/after 代码、量化收益。此举削减约 25% 的 Skill Token同时保留驱动通过场景的核心检测表与校准指引。5.3 明确不值得添加的场景以下重构任务经评估后被认为基线模型已在或接近天花板质量不值得投入 Skill 篇幅识别超大 / 多关注点测试——模型可靠地发现 50 行以上、含多个 arrange-act-assert 循环的测试并建议拆分抽取重复 setup 到辅助方法——模型识别 3 个重复 setup 块并建议TestInitialize、辅助方法或工厂模式推荐 builder 模式——模型识别散布的复杂对象构造并在适当时提出 builder。Skill 因此把全部篇幅集中在基线模型表现挣扎的判断密集型场景克制识别代码已足够好与DisplayName 校准。六、从源码与评估夹具验证设计决策6.1 当前 SKILL.md 的实际形态与设计笔记的对应值得注意当前仓库中的 SKILL.md 仍保留完整的四步工作流Gather → Identify → Calibrate → Report以及 Validation / Common Pitfalls 章节。从设计笔记 Round 4 的裁剪为仅校准规则结论看这暗示当前 SKILL.md 是迭代中途的形态或设计笔记记录的是实验性裁剪实验而非最终落地。读者应以 SKILL.md 的实际内容为可运行依据把设计笔记当作为什么这些内容值得保留/裁剪的决策史料——例如文档明确说 Round 2 删掉 Step 4-5 与 pitfalls 曾引发回归而当前 SKILL.md 完整保留了这些章节这本身就是一个值得注意的反差。6.2 评估夹具四个场景与四套测试工程评估配置 定义了四个场景每个场景配有真实 fixture场景Prompt 要点FixtureRubric 核心推荐数据驱动模式 DisplayName每次新用例都要新方法求更好结构data-driven-candidate合并无效/有效输入用例、给参数化用例加标签、承认其余部分结构良好识别维护良好的测试审查可维护性well-maintained承认无需大改、肯定CreateTokenService辅助方法、不过度设计检测重复对象构造与 setup感觉大量复制粘贴heavy-boilerplate指出 FakeLogger/FakeEmailService/FakeInventoryService 三行构造块重复、建议抽取 helper/factory、给出 before/after识别几乎无样板、无需重构的测试检查重复代码模式minimal-boilerplate认可已有参数化测试、小改进而非批判性重构、不过度推荐基类这些夹具与 SKILL.md 中的五类问题一一对应并且验证了校准规则尊重刻意的冗余例如 well-maintained 场景的 TokenServiceTests.cs 中CreateTokenService(TimeSpan? clockOffset null)辅助方法被 rubric 明确肯定为 good patternminimal-boilerplate 的 CalculatorTests.cs 中[DataRow(..., DisplayName ...)]的写法则是DataRow DisplayName校准规则的正面教材。有趣的是当前 eval.yaml 中的四个场景与设计笔记 Round 1 的四个场景有选择地推荐修改 / 数据驱动DisplayName / 识别维护良好 / 超大测试并不完全一致——eval.yaml 里的场景名更贴近数据驱动 DisplayName、识别维护良好、检测重复构造、识别少样板测试。这印证了设计笔记记录的迭代被删除的超大测试有选择地推荐修改场景确实退出了评估集而检测重复对象构造对应笔记中不值得添加讨论但最终被加入与识别少样板测试构成了新的评估面。这也提醒读者设计笔记记录的是决策过程eval.yaml 与 SKILL.md 才是当前生效的事实。6.3 指标采集与激活检测的源码印证评估指标由 MetricsCollector.cs 采集通过assistant.usage事件累加输入/输出 Token无真实计数时按content.Length / 4估算统计tool.execution_start得到工具调用次数与分布assistant.message计轮次runner.timeout/session.error/runner.error计错误。设计笔记 Round 3 中tokens、tool calls、time三列数据正是这套采集管线的产物。激活检测则由 MetricsCollector.cs 的ExtractSkillActivation负责当指定targetSkillName时只有目标 Skill 被检出才算激活避免插件模式下兄弟 Skill如test-anti-patterns抢先触发造成假阳性——这正解释了笔记中NOT ACTIVATED类问题如 Round 4 中冗余 mock 场景加载了 Skill 但模型选择不使用是如何被诊断出来的。七、方法论总结给 Skill 作者的五个可迁移经验质量天花板 场景删除信号。基线 LLM 在重构建议类任务上常已接近满分此时 Skill 的任何 Token 开销都会让加权分为负。识别这类无增量空间场景并果断删除比继续优化 Skill 更有效。裁剪必须逐场景验证小心隐性提示。Round 2 的回归证明删除的内容里可能藏着某些场景的关键隐性强化。裁剪后必须重跑全部场景而不是只看 Token 总量。把独特判断编码为显式校准规则。Skill 的价值不应是重复模型已会的检测百科而应是把何时不要做的判断标准写成规则——6 条校准规则全部是克制型指令。用加权分数审视质量与开销的平衡。质量 4.0→5.0 的提升可能被 Token 翻倍的代价完全抵消评估决策要同时看原始质量分、Token/时间/工具调用指标和加权后的总分。让 Skill 保持精简。笔记中反复出现的主题是~200 行的反模式大全在消耗模型的注意力预算最终形态聚焦标题 一行工作流 校准规则可裁剪约 75% 的 Token。结语exp-test-maintainability的四轮评估史是一个减法的典范从完整的四步工作流、五类检测表、验证清单与陷阱表收敛到以 6 条校准规则为灵魂的克制型 Skill。其设计笔记与 SKILL.md、eval.yaml 及 Comparator.cs 一起构成了一份完整的如何用评估数据驱动 Skill 设计的案例研究。对于正在为 .NET 测试套件做维护性分析的用户实际使用该 Skill 时建议遵循其 frontmatter 场景约束分析重复样板、复制粘贴测试与结构性问题时激活编写新测试或深度 Mock 审计时则交给专门的 Skill。【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Test Maintainability Skill 设计剖析：如何用评估驱动法打磨 .NET 测试维护性 Skill
Test Maintainability Skill 设计剖析如何用评估驱动法打磨 .NET 测试维护性 Skill【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills导读skills17/skills仓库中的 exp-test-maintainability 设计笔记 记录了测试可维护性Skill 从第一轮到第四轮的真实评估迭代过程基线 LLM 在重构建议上已经接近满分Skill 的真正价值集中在判断力——识别已维护良好的测试、校准何时不该建议修改、为不直观的参数推荐 DisplayName。本文以该文档为主线结合仓库中 SKILL.md、评估配置 与评估工具的源码实现完整还原这一按数据裁剪 Skill的方法论帮助读者理解一个实验性 Skill 如何被反复打磨以及为什么克制比覆盖更多场景更重要。一、Skill 定位一个只做分析、不做修改的维护性体检工具exp-test-maintainability是dotnet-experimental插件见 plugin.json下的实验性 Skill。它的核心任务在 SKILL.md 开头便写得很明确Analyze .NET test code for maintainability issues: duplicated boilerplate, copy-paste test methods, and structural repetition across test methods and classes. Produce a report of refactoring opportunities with concrete before/after suggestions. The goal is analysis only — do not modify any files.也就是说这个 Skill只输出分析与重构建议不直接修改任何文件。这与仓库中其他 Skill 形成明确的分工边界在 SKILL.md 的 frontmatter 的description与 When Not to Use 小节中都有声明需求类型应使用的 Skill从零编写新测试writing-mstest-tests见 plugins/dotnet-test/skills/writing-mstest-tests/SKILL.md检测反模式 / 代码坏味道test-anti-patterns深度 Mock 审计exp-mock-usage-analysis见 plugins/dotnet-experimental/skills/exp-mock-usage-analysis/SKILL.md测试可维护性分析exp-test-maintainabilitySkill 支持 MSTest、xUnit、NUnit、TUnit 四种测试框架在 Step 1 通过框架标记识别测试文件框架测试类标记测试方法标记MSTest[TestClass][TestMethod]、[DataTestMethod]xUnit无约定式[Fact]、[Theory]NUnit[TestFixture][Test]、[TestCase]、[TestCaseSource]TUnit无约定式[Test]二、检测框架五大维护性问题类别与重构方向SKILL.md 的 Step 2 定义了五类可维护性问题每一类都有明确指标Indicators和候选重构Potential refactorings这是文档的核心知识资产类别 1重复的对象构造Repeated object construction指标同一个new ClassName(...)以相同或几乎相同的参数出现在 3 个测试方法中多个测试用相似配置创建同一个被测系统SUT重复的 mock/fake/stub 创建。候选重构抽取工厂方法或测试辅助方法如CreateSut()、CreateDefaultOrder()使用[TestInitialize]/构造函数/[SetUp]共享构造对多变化复杂对象引入 builder 模式。Before两个测试重复 4 行构造代码[TestMethod] public void Process_ValidOrder_Succeeds() { var logger new FakeLogger(); var email new FakeEmailService(); var inventory new FakeInventory(stock: 100); var processor new OrderProcessor(logger, email, inventory); // ... } [TestMethod] public void Process_EmptyItems_Fails() { var logger new FakeLogger(); var email new FakeEmailService(); var inventory new FakeInventory(stock: 100); var processor new OrderProcessor(logger, email, inventory); // ... }After — 抽取工厂private static OrderProcessor CreateProcessor(int stock 100) { return new OrderProcessor(new FakeLogger(), new FakeEmailService(), new FakeInventory(stock)); }类别 2重复的断言模式Repeated assertion patterns指标多个测试对结果对象断言同一组属性重复的先判 null 再判值序列多个方法中相同的Assert.AreEqual集合。候选重构抽取自定义断言辅助方法如AssertValidOrder(order, expectedTotal, expectedStatus)使用框架特定的断言扩展引入校验一组标准属性的Verify方法。类别 3复制粘贴型测试方法Copy-paste test methods指标方法体几乎相同、仅输入值或单个参数不同的 3 个方法可被折叠为[DataRow]/[Theory]/[TestCase]的方法命名呈Method_Input1_Result、Method_Input2_Result模式的方法。候选重构转换为带[DataRow]/[InlineData]/[TestCase]的参数化测试复杂输入用[DynamicData]/[MemberData]/[TestCaseSource]同时包含一条关键校准规则Prefer[DataRow]withDisplayNameover[DynamicData]when all values are compile-time constants. Reserve[DynamicData]for computed or complex values. AddDisplayNamefor non-obvious parameter values.[DataRow(Gold, 100.0, 90.0)]is self-explanatory;[DataRow(3, 7, 42)]is not.这条规则不是凭空而来的——它正是设计笔记 Round 2 中一次回归Regression的直接产物后文会详述。类别 4重复的 setup/teardown 逻辑指标多个测试类中出现相似的[TestInitialize]/[SetUp]方法体重复的数据库 seeding、文件创建或 HTTP 客户端配置跨类相同的using/IDisposable清理模式。候选重构抽取共享测试基类或 fixture用组合共享辅助类替代继承创建测试上下文工厂。类别 5重复的测试基础设施Repeated test infrastructure指标多个类中相同配置的 mock 接口重复的带相似DelegatingHandler模式的HttpClient配置跨类相同的日志/配置脚手架。候选重构抽取共享测试 fixture 或辅助库创建可复用 fake 实现引入测试工具类test harness。三、校准规则这个 Skill 真正的价值所在SKILL.md 的 Step 3 是全篇的灵魂也是设计笔记反复强调的judgment calls落点。六条校准规则原文如下只在 3 处重复时报告。两处相似 setup 不构成样板代码——它们可能是刻意的清晰表达。不要标记简单构造函数。new Calculator()或new Listint()不是有意义的样板也不要为new User(1, Alice)推荐 builder。尊重刻意的冗余。如果每个测试自包含且单独阅读清晰那么每个测试显式 setup 是合理选择——可以提及但不要当作问题标记。区分结构相似与真实重复。遵循 AAAArrange-Act-Assert的测试天然看起来相似只有当实际代码而非结构重复时才标记。考虑重构的影响半径blast radius。被 20 个测试共享的辅助方法会引入耦合需要注明这个权衡。如果测试已经维护良好就直说。一份只发现次要机会的报告完全有效先肯定已经做对的部分。这六条规则共同回答了同一个问题什么时候不重构才是正确答案。这正是文档 Key Insight 的核心结论——基线 LLM 已经擅长提出重构建议抽 builder、拆分超大测试Skill 的独特增量全部在判断层面识别维护良好的测试、校准何时不该推荐修改、为不直观的值推荐 DisplayName。四、评估迭代实录四轮打磨如何塑造这个 Skill设计笔记exp-test-maintainability-design-notes.md记录了 2026 年 3 月进行的四轮评估。理解这套数据需要先了解仓库评估工具的评分机制。4.1 评分机制质量提升 vs. Token 开销的加权博弈评估采用 Baseline无 Skill/ Isolated有 Skill/ Plugin插件模式三种运行形态对比。Comparator.cs 中定义了七维指标分解而 Models.cs 的DefaultWeights给出了默认权重指标权重TokenReduction0.05ToolCallReduction0.025TaskCompletionImprovement0.15TimeReduction0.025QualityImprovement0.40OverallJudgmentImprovement0.30ErrorReduction0.05可见质量类指标Quality Judgment合计权重高达 0.70但 Token/时间/工具调用开销仍会以合计 0.10 的权重拉低加权分。文档表格中的脚注Quality matched or improved but weighted score penalized by token overhead正是这种机制的体现当基线质量已满分时Skill 引入的任何 Token 开销都会让加权分为负——这是后续几轮删场景决策的数学根源。此外Comparator.cs 还实现了 Hake (1998) 的归一化增益公式g (post - pre) / (1 - pre)用于控制天花板效应ceiling effect当基线pre已接近 1 时即使post小幅提升增益也会被放大审视。4.2 Round 1原版 Skill 的初次评估场景BaselineIsolatedPlugin结论有选择地推荐修改4.7/55.0/55.0/5❌ ¹数据驱动模式 DisplayName4.0/55.0/54.7/5✅识别维护良好的测试4.0/55.0/55.0/5✅超大测试5.0/55.0/55.0/5❌ ¹¹ 质量持平或提升但加权分被 Token 开销拖累。第一轮透露了两个信号Skill 在数据驱动 DisplayName和识别良好测试上带来了真实质量提升而超大测试场景基线已满分Skill 无增量可贡献。4.3 Round 2裁剪后出现回归裁剪内容移除 Steps 4-5、pitfalls、验证清单。场景BaselineIsolatedPlugin结论有选择地推荐修改5.0/55.0/55.0/5❌ ²数据驱动模式 DisplayName4.0/54.6/54.4/5❌ ³识别维护良好的测试4.6/55.0/55.0/5✅² 基线触顶——与超大测试同样的问题。 ³回归——裁剪把关于DataRowDisplayName的隐性强化删掉了Skill 把模型引向[DynamicData]而非带DisplayName的[DataRow]被 rubric 扣分。这是全篇最有价值的教训裁剪 Skill 时被删内容恰恰可能是决定某些场景通过的关键隐性提示。修复方式是加一条显式校准规则当值是编译期常量时优先[DataRow]DisplayName而非[DynamicData]——即前文 Step 3 中的那条规则。4.4 Round 3加回校准规则后质量上去了但加权仍负场景BaselineIsolatedPlugin结论有选择地推荐修改5.0/55.0/55.0/5❌ ⁴数据驱动模式 DisplayName4.0/54.3/54.3/5❌ ⁵识别维护良好的测试4.7/55.0/55.0/5❌ ⁶⁴ 质量不变加权 -11.0%tokens 13388 → 35555工具调用 0 → 2耗时 16.9s → 34.6s。 ⁵ 质量提升 4.0→4.3但加权 -4.2%tokens 13148 → 30114工具调用 0 → 1耗时 15.7s → 33.6s。 ⁶ 质量提升 4.7→5.0但加权 -15.0%tokens 12736 → 37977工具调用 0 → 2耗时 17.3s → 30.4s。第三轮的数字非常直观加回的规则确实把数据驱动 DisplayName从回归拉回正增长4.0→4.3识别良好测试也到了 5.0 满分但 Skill 激活后 Token 消耗暴涨 2~3 倍、多出 1~2 次工具调用、耗时翻倍加权分全部转负。这为第四轮的激进裁剪提供了全部理由。4.5 Round 4激进裁剪为仅校准规则裁剪内容移除 When to Use / When Not to Use由 frontmatter 描述覆盖、Inputs 表、Step 1收集代码、Step 2 检测表模型原生检测已达天花板质量、Step 4报告格式。只保留标题、一行工作流和 6 条校准规则——即编码了 Skill 独特判断价值的部分。裁剪约 75% 的 Skill Token。场景BaselineIsolatedPlugin结论有选择地推荐修改5.0/55.0/55.0/5❌ ⁷数据驱动模式 DisplayName4.0/55.0/54.0/5❌ ⁸识别维护良好的测试4.3/55.0/55.0/5✅⁷ 基线触顶——与超大测试同样的问题移出评估。 ⁸ Isolated 提升但 Plugin 未提升加权 -9.4%Token 开销。四轮迭代形成了清晰结论当基线已满分时任何 Token 开销都必然使加权分为负此类场景无论怎样裁剪都无法通过只能删除。五、依据数据做出的决策与不值得添加的场景5.1 删除的评估场景超大测试场景基线 5.0/5Skill 零质量增量任何非零 Token 开销都会使加权为负无论怎么裁剪都无法通过。有选择地推荐修改场景Round 2 裁剪后基线触顶 5.0/5与超大测试同理。5.2 裁剪的 SKILL.md 输出格式与陷阱部分移除了 Steps 4-5详细报告结构、show-refactored-code 指令、验证清单和常见陷阱表。理由它们要么与 Step 3 校准规则重复要么教授的是模型原生已会的行为before/after 代码、量化收益。此举削减约 25% 的 Skill Token同时保留驱动通过场景的核心检测表与校准指引。5.3 明确不值得添加的场景以下重构任务经评估后被认为基线模型已在或接近天花板质量不值得投入 Skill 篇幅识别超大 / 多关注点测试——模型可靠地发现 50 行以上、含多个 arrange-act-assert 循环的测试并建议拆分抽取重复 setup 到辅助方法——模型识别 3 个重复 setup 块并建议TestInitialize、辅助方法或工厂模式推荐 builder 模式——模型识别散布的复杂对象构造并在适当时提出 builder。Skill 因此把全部篇幅集中在基线模型表现挣扎的判断密集型场景克制识别代码已足够好与DisplayName 校准。六、从源码与评估夹具验证设计决策6.1 当前 SKILL.md 的实际形态与设计笔记的对应值得注意当前仓库中的 SKILL.md 仍保留完整的四步工作流Gather → Identify → Calibrate → Report以及 Validation / Common Pitfalls 章节。从设计笔记 Round 4 的裁剪为仅校准规则结论看这暗示当前 SKILL.md 是迭代中途的形态或设计笔记记录的是实验性裁剪实验而非最终落地。读者应以 SKILL.md 的实际内容为可运行依据把设计笔记当作为什么这些内容值得保留/裁剪的决策史料——例如文档明确说 Round 2 删掉 Step 4-5 与 pitfalls 曾引发回归而当前 SKILL.md 完整保留了这些章节这本身就是一个值得注意的反差。6.2 评估夹具四个场景与四套测试工程评估配置 定义了四个场景每个场景配有真实 fixture场景Prompt 要点FixtureRubric 核心推荐数据驱动模式 DisplayName每次新用例都要新方法求更好结构data-driven-candidate合并无效/有效输入用例、给参数化用例加标签、承认其余部分结构良好识别维护良好的测试审查可维护性well-maintained承认无需大改、肯定CreateTokenService辅助方法、不过度设计检测重复对象构造与 setup感觉大量复制粘贴heavy-boilerplate指出 FakeLogger/FakeEmailService/FakeInventoryService 三行构造块重复、建议抽取 helper/factory、给出 before/after识别几乎无样板、无需重构的测试检查重复代码模式minimal-boilerplate认可已有参数化测试、小改进而非批判性重构、不过度推荐基类这些夹具与 SKILL.md 中的五类问题一一对应并且验证了校准规则尊重刻意的冗余例如 well-maintained 场景的 TokenServiceTests.cs 中CreateTokenService(TimeSpan? clockOffset null)辅助方法被 rubric 明确肯定为 good patternminimal-boilerplate 的 CalculatorTests.cs 中[DataRow(..., DisplayName ...)]的写法则是DataRow DisplayName校准规则的正面教材。有趣的是当前 eval.yaml 中的四个场景与设计笔记 Round 1 的四个场景有选择地推荐修改 / 数据驱动DisplayName / 识别维护良好 / 超大测试并不完全一致——eval.yaml 里的场景名更贴近数据驱动 DisplayName、识别维护良好、检测重复构造、识别少样板测试。这印证了设计笔记记录的迭代被删除的超大测试有选择地推荐修改场景确实退出了评估集而检测重复对象构造对应笔记中不值得添加讨论但最终被加入与识别少样板测试构成了新的评估面。这也提醒读者设计笔记记录的是决策过程eval.yaml 与 SKILL.md 才是当前生效的事实。6.3 指标采集与激活检测的源码印证评估指标由 MetricsCollector.cs 采集通过assistant.usage事件累加输入/输出 Token无真实计数时按content.Length / 4估算统计tool.execution_start得到工具调用次数与分布assistant.message计轮次runner.timeout/session.error/runner.error计错误。设计笔记 Round 3 中tokens、tool calls、time三列数据正是这套采集管线的产物。激活检测则由 MetricsCollector.cs 的ExtractSkillActivation负责当指定targetSkillName时只有目标 Skill 被检出才算激活避免插件模式下兄弟 Skill如test-anti-patterns抢先触发造成假阳性——这正解释了笔记中NOT ACTIVATED类问题如 Round 4 中冗余 mock 场景加载了 Skill 但模型选择不使用是如何被诊断出来的。七、方法论总结给 Skill 作者的五个可迁移经验质量天花板 场景删除信号。基线 LLM 在重构建议类任务上常已接近满分此时 Skill 的任何 Token 开销都会让加权分为负。识别这类无增量空间场景并果断删除比继续优化 Skill 更有效。裁剪必须逐场景验证小心隐性提示。Round 2 的回归证明删除的内容里可能藏着某些场景的关键隐性强化。裁剪后必须重跑全部场景而不是只看 Token 总量。把独特判断编码为显式校准规则。Skill 的价值不应是重复模型已会的检测百科而应是把何时不要做的判断标准写成规则——6 条校准规则全部是克制型指令。用加权分数审视质量与开销的平衡。质量 4.0→5.0 的提升可能被 Token 翻倍的代价完全抵消评估决策要同时看原始质量分、Token/时间/工具调用指标和加权后的总分。让 Skill 保持精简。笔记中反复出现的主题是~200 行的反模式大全在消耗模型的注意力预算最终形态聚焦标题 一行工作流 校准规则可裁剪约 75% 的 Token。结语exp-test-maintainability的四轮评估史是一个减法的典范从完整的四步工作流、五类检测表、验证清单与陷阱表收敛到以 6 条校准规则为灵魂的克制型 Skill。其设计笔记与 SKILL.md、eval.yaml 及 Comparator.cs 一起构成了一份完整的如何用评估数据驱动 Skill 设计的案例研究。对于正在为 .NET 测试套件做维护性分析的用户实际使用该 Skill 时建议遵循其 frontmatter 场景约束分析重复样板、复制粘贴测试与结构性问题时激活编写新测试或深度 Mock 审计时则交给专门的 Skill。【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考