skill-validator改进分如何计算指标权重表完全解读质量占70%【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skillsskill-validator是 .NET/C# AI 编码技能仓库中的评估工具它把同一个 AI Agent「带着技能」和「不带技能」各跑一遍再用指标权重表算出一个 0~1 的改进分improvement score判断这个 skill 值不值得保留。其中最关键的一点是质量类指标合计占 70% 权重——输出质量好的技能哪怕多花 token 也能通过。项目定位为 AI coding agent 编写 .NET 与 C# 技能skills的仓库skill-validator负责回答「这个技能到底有没有帮上忙」。工具文档见 eng/skill-validator/src/README.md。一、先看懂改进分的整体逻辑 计算过程可以概括为 4 步跑两遍对每个测试场景tests/插件/技能/eval.yaml中定义先跑无技能的基线baseline再跑加载技能的版本算 7 项差值对比 token 消耗、工具调用次数、错误数、耗时、任务是否完成、以及 LLM 评委打的质量分加权求和每项差值乘以它的固定权重相加得到该场景的改进分场景平均 门槛判定所有场景改进分的平均值达到阈值默认 10%才算通过。加权求和的源码只有几十行位于 Comparator.cs逐项value × weight累加权重则统一存放在 Models.cs 的DefaultWeights表中。二、指标权重表完全解读核心下表是改进分权重表的完整内容合计恰好 1.0指标权重衡量什么属于哪一类Qualityrubric 逐条评分0.40评委按 rubric 评分标准逐条比较两份输出 质量类Qualityoverall 综合判断0.30评委对整体输出质量的对比结论 质量类任务完成Task completion0.15硬性断言是否全部通过1 / -1 / 0✅ 结果类Token 减少0.05比基线少用多少 token越省越好⚡ 效率类错误减少0.05比基线少多少错误/重试⚡ 效率类工具调用减少0.025工具调用次数是否更少⚡ 效率类耗时减少0.025完成速度是否更快⚡ 效率类一眼就能看出的设计意图质量类0.40 0.30 0.70占绝对大头标题里的「质量占70%」由此而来结果类0.15任务必须真的做完防止「漂亮但没干活」效率类合计 0.15token、错误、工具调用、耗时都是次要加分项——效率再高也救不了质量差。三、为什么质量要占 70%工具文档给出了明确理由质量被重度优先——一个提升输出质量的技能即使用掉更多 token 也会通过验证见 README 中 Metrics scoring 一节。背后的逻辑对新手很友好skill 的本质是「教 Agent 把事做得更好」而不是「把事做得更省」效率类指标如果权重过高Agent 可能学会「少干活骗分」质量分由 LLM 评委成对比较pairwise judging得出评委同时看到基线和技能版两份输出直接判断谁更好、好多少。四、计算过程中的 5 个关键细节 效率指标被钳制在 [-1, 1]所有效率类差值token、耗时、错误、工具调用都会先被Math.Max(-1, Math.Min(1, ...))夹住Comparator.cs极端变化不会淹没质量收益质量分来自 5 分制独立评分模式下评委按 1~5 分打分差值除以 2.5 再钳制到 [-1, 1] 后参与加权成对比较模式下则用「好很多1 / 好一点0.4 / 平局0 / 略差-0.4 / 差很多-1」的映射Models.cs防位置偏差成对比较会交换两份输出的顺序各跑一次两次结论一致才采信不一致按平局处理10% 是及格线改进分平均分 ≥ 0.1 才通过可用--min-improvement调整若任务完成度回退则直接判失败--require-completion默认开启还有显著性检验多次运行默认 5 次会做 bootstrap 置信区间95% 区间跨零只算「可能是噪声」g归一化增益则控制「基线本来就强」带来的天花板效应。✓ my-skill 18.5% [8.2%, 28.8%] significant (g24.3%) ✗ other-skill 6.3% [-2.1%, 14.7%] not significant (g8.1%)五、在真实评估报告里看到分数 分数最终会汇总进 PR 上的「Skill Evaluation Results」报告每行一个技能含 Δ Preference、W/T/L、Quality、Baseline 等列复杂场景比较失败、高过拟合、部分场景未激活技能下报告还会展开每个场景的明细与列含义说明各列含义与故障排查的完整说明见 eng/vally-adapter/README.md字段级解读见 InvestigatingResults.md。六、想深入源码文件导航 ️想了解去哪里看权重数值0.40/0.30/0.15/…Models.csDefaultWeights加权求和与判定逻辑Comparator.cs各指标怎么从事件流里采集MetricsCollector.cs分数如何写进报告与贡献度分析Reporter.cs权重与计算行为的测试ComparatorTests.cs测试场景如何写rubric/断言tests 下各 eval.yaml七、常见疑问 ⚡Q技能省了一半 token但质量没提升能过吗不能。token 减少最多只贡献 0.05 × 1 0.05远够不到 10% 的及格线——质量才是决定性因素。Q为什么工具调用和耗时权重只有 0.025因为它们是「锦上添花」指标。若 Agent 为了质量多调用几次工具、多花几秒完全合理权重设太低正是为了不惩罚这种行为。Q权重可以改吗DefaultWeights是内置默认值报告中的贡献度分析Reporter.cs也复用同一张表避免权重在多处硬编码不一致——想调整评分策略应从这里统一修改。一句话总结skill-validator 的改进分 70% 看质量rubric 40% 综合判断 30%、15% 看任务是否完成、15% 看效率token 5% 错误 5% 工具调用 2.5% 耗时 2.5%平均分过 10% 即通过验证。【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 skill-validator改进分如何计算：指标权重表完全解读（质量占70%）
skill-validator改进分如何计算指标权重表完全解读质量占70%【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skillsskill-validator是 .NET/C# AI 编码技能仓库中的评估工具它把同一个 AI Agent「带着技能」和「不带技能」各跑一遍再用指标权重表算出一个 0~1 的改进分improvement score判断这个 skill 值不值得保留。其中最关键的一点是质量类指标合计占 70% 权重——输出质量好的技能哪怕多花 token 也能通过。项目定位为 AI coding agent 编写 .NET 与 C# 技能skills的仓库skill-validator负责回答「这个技能到底有没有帮上忙」。工具文档见 eng/skill-validator/src/README.md。一、先看懂改进分的整体逻辑 计算过程可以概括为 4 步跑两遍对每个测试场景tests/插件/技能/eval.yaml中定义先跑无技能的基线baseline再跑加载技能的版本算 7 项差值对比 token 消耗、工具调用次数、错误数、耗时、任务是否完成、以及 LLM 评委打的质量分加权求和每项差值乘以它的固定权重相加得到该场景的改进分场景平均 门槛判定所有场景改进分的平均值达到阈值默认 10%才算通过。加权求和的源码只有几十行位于 Comparator.cs逐项value × weight累加权重则统一存放在 Models.cs 的DefaultWeights表中。二、指标权重表完全解读核心下表是改进分权重表的完整内容合计恰好 1.0指标权重衡量什么属于哪一类Qualityrubric 逐条评分0.40评委按 rubric 评分标准逐条比较两份输出 质量类Qualityoverall 综合判断0.30评委对整体输出质量的对比结论 质量类任务完成Task completion0.15硬性断言是否全部通过1 / -1 / 0✅ 结果类Token 减少0.05比基线少用多少 token越省越好⚡ 效率类错误减少0.05比基线少多少错误/重试⚡ 效率类工具调用减少0.025工具调用次数是否更少⚡ 效率类耗时减少0.025完成速度是否更快⚡ 效率类一眼就能看出的设计意图质量类0.40 0.30 0.70占绝对大头标题里的「质量占70%」由此而来结果类0.15任务必须真的做完防止「漂亮但没干活」效率类合计 0.15token、错误、工具调用、耗时都是次要加分项——效率再高也救不了质量差。三、为什么质量要占 70%工具文档给出了明确理由质量被重度优先——一个提升输出质量的技能即使用掉更多 token 也会通过验证见 README 中 Metrics scoring 一节。背后的逻辑对新手很友好skill 的本质是「教 Agent 把事做得更好」而不是「把事做得更省」效率类指标如果权重过高Agent 可能学会「少干活骗分」质量分由 LLM 评委成对比较pairwise judging得出评委同时看到基线和技能版两份输出直接判断谁更好、好多少。四、计算过程中的 5 个关键细节 效率指标被钳制在 [-1, 1]所有效率类差值token、耗时、错误、工具调用都会先被Math.Max(-1, Math.Min(1, ...))夹住Comparator.cs极端变化不会淹没质量收益质量分来自 5 分制独立评分模式下评委按 1~5 分打分差值除以 2.5 再钳制到 [-1, 1] 后参与加权成对比较模式下则用「好很多1 / 好一点0.4 / 平局0 / 略差-0.4 / 差很多-1」的映射Models.cs防位置偏差成对比较会交换两份输出的顺序各跑一次两次结论一致才采信不一致按平局处理10% 是及格线改进分平均分 ≥ 0.1 才通过可用--min-improvement调整若任务完成度回退则直接判失败--require-completion默认开启还有显著性检验多次运行默认 5 次会做 bootstrap 置信区间95% 区间跨零只算「可能是噪声」g归一化增益则控制「基线本来就强」带来的天花板效应。✓ my-skill 18.5% [8.2%, 28.8%] significant (g24.3%) ✗ other-skill 6.3% [-2.1%, 14.7%] not significant (g8.1%)五、在真实评估报告里看到分数 分数最终会汇总进 PR 上的「Skill Evaluation Results」报告每行一个技能含 Δ Preference、W/T/L、Quality、Baseline 等列复杂场景比较失败、高过拟合、部分场景未激活技能下报告还会展开每个场景的明细与列含义说明各列含义与故障排查的完整说明见 eng/vally-adapter/README.md字段级解读见 InvestigatingResults.md。六、想深入源码文件导航 ️想了解去哪里看权重数值0.40/0.30/0.15/…Models.csDefaultWeights加权求和与判定逻辑Comparator.cs各指标怎么从事件流里采集MetricsCollector.cs分数如何写进报告与贡献度分析Reporter.cs权重与计算行为的测试ComparatorTests.cs测试场景如何写rubric/断言tests 下各 eval.yaml七、常见疑问 ⚡Q技能省了一半 token但质量没提升能过吗不能。token 减少最多只贡献 0.05 × 1 0.05远够不到 10% 的及格线——质量才是决定性因素。Q为什么工具调用和耗时权重只有 0.025因为它们是「锦上添花」指标。若 Agent 为了质量多调用几次工具、多花几秒完全合理权重设太低正是为了不惩罚这种行为。Q权重可以改吗DefaultWeights是内置默认值报告中的贡献度分析Reporter.cs也复用同一张表避免权重在多处硬编码不一致——想调整评分策略应从这里统一修改。一句话总结skill-validator 的改进分 70% 看质量rubric 40% 综合判断 30%、15% 看任务是否完成、15% 看效率token 5% 错误 5% 工具调用 2.5% 耗时 2.5%平均分过 10% 即通过验证。【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考