skill-validator 评估结果排查指南读懂 results.json、定位失败模式与修复评估场景【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills本指南源自 eng/skill-validator/src/docs/InvestigatingResults.md系统讲解 dotnet/skills 仓库中 skill-validator 工具现已迁移至 Vally harness评估失败后的完整排查流程如何下载结果产物、解读results.json的 schema 与指标、识别八大常见失败模式并按优先级修复。读者阅读后可掌握一套可复制的诊断方法论——无论你是 AI Agent 还是人类开发者都能据此分析一次技能评估为何失败、判断是技能本身的问题还是评估设计的问题并产出真正提升技能价值的修复方案。⚠️ 先读这里的现状说明legacy 与 Vally 的分野自 Vally 迁移之后仓库的 LLM 评估流水线evaluation.yml已不再调用skill-validator evaluate而是通过 eng/vally-adapter 运行 Vally并上传vally-results-*产物。排查当前评估失败请改用仓库根目录下的 eng/vally-adapter/InvestigatingResults.md。本文件描述的是 legacyskill-validator evaluate的 schema仅用于历史结果与参考。skill-validator checklinter不受影响仍通过skill-check.yml运行。当前 Vally 流程对 executor 的session.idle超时会在适配前做一次定向恢复尝试详见结果产物中的executor-retry-summary.json及当前指南中的有界重试与 fail-closed 规则。当前 Vally schema 以state为权威字段VALID_PASS、VALID_REGRESSION、VALID_NO_CHANGE、INVALID_INCONCLUSIVE机器可读原因请读取stateReason与errors[]preferenceRegressed仅是报告性的 LLM 偏好证据不代表客观完成度回退adapter-summary.json对账了精确的预期 eval 清单与实际观测/写入结果practicalSignificance引入了 20% 净胜下限。以下 legacy schema 中不存在这些字段。1. 本指南的使用方式给 AI Agent 的排查手册这份文档在设计上就是面向 AI 编码 Agent 编写的。当一次技能评估出现失败时PR 评论中会附带一条现成的提示词ready-to-use prompt——直接复制粘贴给你的 AI Agent 即可。Agent 会自行下载产物、阅读本指南、分析results.json并提出修复建议。如果你需要手动排查可以直接跳到下面的 Quick start。2. 排查的宏观思路无论手动还是交给 Agent排查的完整链路是一致的下载结果产物artifact拿到summary.md与results.json先读summary.md快速了解哪些场景通过、哪些失败再读results.json获取完整指标、agent 输出、断言与 judge 推理对照下文八大失败模式归类——大多数失败同时命中多个模式按先超时、再激活、最后质量/评分标准的优先级逐个修复应用修复后用/evaluate重新运行。3. Quick start 快速开始# 1. 下载结果产物 gh run download run-id --repo dotnet/skills --pattern skill-validator-results-* --dir path # 2. 先读 summary.md —— 快速总览各场景通过/失败情况 # 3. 再读 results.json —— 完整指标、agent 输出、断言与 judge 推理 # 4. 对照下文失败模式归类按优先级修复先 timeouts再 activation最后 quality/rubric # 5. 应用修复后用 /evaluate 重新运行注意--pattern参数至关重要不加它gh会尝试下载全部工作流产物包括非 zip 文件如.tar.gz导致解压报错并返回非零退出码——即使评估结果本身已经下载成功。4. 查找结果产物4.1 通过 CLI推荐 AI Agent 使用从 PR 评估评论中的Full results链接提取工作流运行 ID例如https://github.com/dotnet/skills/actions/runs/23520818616中的23520818616然后gh run download run-id --repo dotnet/skills --pattern skill-validator-results-* --dir ./eval-results该命令会把所有结果产物下载到子目录中每个子目录包含results.json和summary.md。4.2 通过浏览器从 PR 评论点击Full results链接打开 GitHub Actions 工作流页面然后点击任一 job例如evaluate (technology-selection)展开Upload results步骤在日志输出中找到Artifact download URL下载并解压。或者在页面底部找到Artifacts区块直接下载。5. 理解results.json的 schema每个results.json文件是包含如下顶层字段的对象字段说明model运行 agent 所用的模型judgeModel用于评分的模型timestamp结果写入时间UTCverdicts[]每个技能的评估结果数组5.1 Verdict技能级结构每个 verdict 包含字段说明skillName被评估的技能名passed总体通过/失败scenarios[]各场景对比结果数组overfittingResult过拟合分析如启用5.2 Scenario场景级结构每个场景包含两条必需的运行baseline isolated可能还有一条可选的 plugin 运行以及它们之间的对比字段说明scenarioName人类可读的场景名baseline不加载技能的运行skilledIsolated只加载该技能的运行skilledPlugin可选加载完整插件后的运行plugin 运行被禁用时为 nulltimedOut是否有任一运行超时isolatedImprovementScore加权改进分isolated vs baselinepluginImprovementScore加权改进分plugin vs baseline可选仅当存在 plugin 运行时有值isolatedBreakdown各指标对分数的贡献明细见下文pluginBreakdown各指标对分数的贡献明细可选仅当存在 plugin 运行时有值pairwiseResultjudge 按 rubric 逐条对比的结果perRunScores每次运行的改进分扁平数组存在 plugin 运行时每个值为该次运行的min(isolated, plugin)无 plugin 运行skilledPlugin为 null时每个值即 isolated 改进分注意场景没有passed字段。判断单个场景的通过/失败要看improvementScore 0。这是有效分数无 plugin 运行时等于isolatedImprovementScore有 plugin 运行时取 isolated 与 plugin 分数的最小值。passed字段只存在于 verdict 层按技能。从源码看这个有效分数与Comparator的权重计算完全对应Comparator.ComputeVerdict以comparisons.Average(c c.ImprovementScore)作为技能总体分并在requireCompletion默认开启时检查baseline 完成任务但 skilled 未完成的完成度回退命中则直接判定FailureKind.CompletionRegression失败见 Comparator.cs。ScenarioComparison中的SkillActivationIsolated/SkillActivationPlugin、PerRunScores、HighVariance等字段定义于 Models.cs。5.2.1 基线复用--baseline-from时的行为当运行带--baseline-from时baseline臂不再执行——其metrics与judgeResult来自之前用--baseline-out生成的共享基线文件一次性计算遵循--runs。这类场景会以baseline-reused会话阶段和reused基线状态上报。基线文件按--model与--judge-model为键且对每个场景额外使用提示词的 SHA-256与设置输入 评估标准的复合 SHA-256覆盖复制的测试文件、显式设置文件、设置命令以及 rubric、断言、expect/reject 工具、轮数/令牌/超时限制做身份匹配。如果 agent 模型、judge 模型或任何场景的提示词 设置 标准身份缺失复用会快速失败——因此你对比的基线永远是身份匹配的共享提示词但 fixture 或 rubric 不同的场景不可能交叉污染。因为同一文件被所有消费它的技能/Agent 使用基线充当了共享对照组消除了跨技能对比中基线每次运行带来的方差。5.2.2 解耦运行与评分--no-judgerejudgeevaluate --no-judge只运行 agent 臂并持久化sessions.db不执行任何评分也不需要基线文件因此 baseline 臂与 treatment 臂可以在同一个并行池中运行。每条持久化的会话记录带有baseline_key列——即上述用于基线复用的提示词 SHA 目标 SHA身份。之后用rejudge treatment-dir --baseline-dir baseline-dir按该 key 将每条 treatment 运行与基线运行配对优先匹配运行索引执行与内联evaluate相同的 judge 与门控--min-improvement、--require-completion等并把基线 judge/pairwise 结果写回基线库、treatment judge 结果写回 treatment 库。baseline 与 treatment 必须共享--modeljudge 模型按--judge-model→ treatment 库持久化的 judge 模型 → baseline 库的优先级解析两者持久化的 judge 模型不一致无显式覆盖时会被拒绝。5.3 Breakdown 字段各指标对改进分的贡献isolatedBreakdown与pluginBreakdown对象展示每个指标对改进分的贡献。每个字段都是原始差值尚未加权最终分数按加权和计算字段权重取值范围含义qualityImprovement0.40[-1, 1]基于 rubric 的质量差值overallJudgmentImprovement0.30[-1, 1]judge 整体评估差值taskCompletionImprovement0.15{-1, 0, 1}断言是否通过tokenReduction0.05[-1, 1]正数 更少 token更高效errorReduction0.05[-1, 1]正数 更少错误toolCallReduction0.025[-1, 1]正数 更少工具调用timeReduction0.025[-1, 1]正数 更快上述权重与 Models.cs 中DefaultWeights.Values逐一对应。Comparator.CompareScenario的具体计算逻辑见 Comparator.cstaskCompletionImprovement在两次运行完成状态相同时取 0否则完成则 1、未完成则 -1token/tool/time/error 的 reduction 使用(baseline - withSkill) / baseline并夹紧到 [-1, 1]基线为 0 时技能侧非 0 记为 -1质量类差值按 2.5 分制归一化。所有效率指标都被夹紧在 [-1, 1]因此极端变化不会压过质量增益。tokenReduction为 -1.0 表示技能侧运行使用了基线≥2 倍的 token。这在加载技能时很常见技能内容本身消耗 token但它只占最终分数的 -0.05很少单独导致失败。5.4 Run metrics单次运行的指标baseline、skilledIsolated、skilledPlugin三者都包含metrics对象字段说明timedOut该次运行是否超时wallTimeMs总墙钟时间taskCompleted断言是否通过tokenEstimate本次运行的总 token 估算。存在 usage 事件时按inputTokens outputTokens计算inputTokens为 0 但上报了缓存活动时改用cacheReadTokens outputTokens无 usage 事件时回退为字符数÷4inputTokens发给模型的输入 tokenoutputTokens模型生成的输出 tokencacheReadTokens从缓存读取的提示词 tokencacheWriteTokens写入缓存的提示词 tokenjudgeInputTokens本次运行中 LLM judge 消耗的输入 tokenjudgeOutputTokens本次运行中 LLM judge 生成的输出 tokenjudgeCacheReadTokensjudge 提示词从缓存读取的 tokenjudgeCacheWriteTokensjudge 提示词写入缓存的 tokenturnCountagent 轮数toolCallCount工具调用次数toolCallBreakdown按工具名统计的调用次数errorCount运行期间错误数assertionResults[]逐条断言的通过与失败及消息agentOutputagent 的最终文本输出这些字段的生成逻辑位于 MetricsCollector.csCollectMetrics遍历 agent 事件流tool.execution_start累加工具调用、assistant.message累加轮数、assistant.usage累加真实 token当 provider 上报缓存活动但未填充inputTokens时回退到cacheRead避免估算被清零见 L143、runner.timeout/session.error/runner.error累加错误没有任何 usage 事件时才走字符数÷4 的回退路径。技巧计算一个评估场景的总输入/输出 token 成本把 baseline 与 skilled 运行的 token 字段相加即可。例如场景总输入 token baseline.metrics.inputTokens skilledIsolated.metrics.inputTokens若存在 plugin 运行再加skilledPlugin.metrics.inputTokens。judge*字段单独追踪评分开销。注意summary 表格中的质量分数如 4.0/5来自baseline.judgeResult.overallScore、skilledIsolated.judgeResult.overallScore等——它们位于运行结果对象上不在metrics内。解析results.json时要在每次运行上同时找judgeResult.overallScore与metrics。5.5 eval.yaml 场景选项诊断失败时常用诊断失败时eval.yaml中几个场景级选项很关键选项说明timeout单次运行的最大墙钟时间秒。省略时默认 120 秒源码中EvalSchema.DefaultScenarioTimeoutSeconds 120见 EvalSchema.cs。技能运行超时时调大它reject_tools使用即判失败的工具名数组如[bash, edit]。这是由 validator 在运行后作为断言强制执行的不会沙箱或阻止调用用于迫使 agent 解释而非探索/构建拉平 baseline 与 skilled 运行的起跑线setup.files运行前创建的文件数组。给 agent 具体的代码可操作减少因脚手架策略不同带来的方差仓库中完整的 legacy eval.yaml 编写说明断言类型、setup 选项、约束、rubric、每 eval 并发配置见 eng/skill-validator/src/README.md。仓库实际使用的tests/目录已全面切换到 Vally 原生格式stimuli/graders/rubric例如 tests/dotnet-blazor/author-component/eval.yaml其中config.timeout: 3m、graders里的output-contains/output-matches/prompt类型与rubric列表可以对照理解EvalSchema.cs 中TryParseVallyEvalConfig会将 Vally 格式映射为内部场景结构供过拟合 judge 消费。6. 八大常见失败模式模式 1超时且输出为空症状timedOut: trueagentOutput为空或只有\n\n所有断言失败toolCallBreakdown显示bash使用原因模型把整个时间预算花在运行 shell 命令上如dotnet new、dotnet add package、探索 NuGet 内容从未产出面向用户的文本。修复在eval.yaml中调大timeout——涉及代码生成的场景 180s 常常不够试试 360s重构提示词阻止 bash 探索例如用给我代码代替创建一个项目若场景本应无需 shell 命令即可作答加reject_tools: [bash]。模式 2基线本身就差症状基线分数很低1.0–2.0/5技能分数也低质量改进为 0 或负值原因即使没有技能这个问题对模型也太难。技能无法修复模型本身做不到的事情。修复简化场景提示词检查baseline.metrics.agentOutput验证基线是否正常工作考虑该场景是否在测试正确的东西。模式 3各次运行间方差大症状perRunScores同时包含正负值如[0.07, -0.85, 0.04]最大值与最小值差超过约 0.3 提示方差有问题不同次评估运行之间结果在通过与失败间反复横跳isolated 与 plugin 分数不一致原因LLM 非确定性。模型在不同运行中采取不同策略。修复调大--runs提升统计稳定性默认 5嘈杂场景考虑 7–10收紧提示词压缩有效策略空间加setup.files给模型具体文件而不是让它从零搭建。从源码看ScenarioComparison上带有HighVariance标志与VarianceCV多次运行得分的变异系数且Comparator.ComputeVerdict会在失败原因中追加[high variance in: 场景名]见 Models.cs 与 Comparator.cs。模式 4质量未变但加权分为负症状脚注显示 Quality unchanged but weighted score is -X% due to: judgment, tokens, tool calls技能输出与基线大体相当原因技能引入了 token 开销技能内容本身消耗 token但质量提升不足以抵消。修复改进技能内容让它在该场景下产出明显更好的输出缩小技能体积——更短的技能 token 开销更小检查 rubric 是否与技能实际教授的内容匹配。模式 5技能未激活症状legacyskill-validator报告的 Skills Loaded 列显示⚠️ NOT ACTIVATED当前 Vally PR 评论以⚠️ N/total显示如⚠️ 1/2表示实际激活的技能数少于预期results.json中skillActivationIsolated和/或skillActivationPlugin字段显示activated: false或 legacy 别名skillActivationdetectedSkills为空或skillEventCount为 0技能运行指标与 baseline 相似agent 正常运行但没有技能指导原因agent 运行时没有为该提示词选中技能。技能的 frontmatterdescription不匹配。修复更新 SKILL.md frontmatter 中的description让它更好地匹配场景提示词确保描述包含场景中的关键词检查场景自身是否包含足够信息让 agent 推理出需要该技能场景不应作弊式地直接提示技能名。从源码看激活检测由 MetricsCollector.cs 的ExtractSkillActivation完成统计事件类型含skill/instruction的事件从skillName/name字段提取检测到的技能名当传入targetSkillName时只有目标技能被专门检测到才算激活大小写不敏感防止 plugin 运行中兄弟技能误触发——SDK 在技能加载时总是发出SkillInvokedEvent。Plugin 臂独有未激活skill-menu 预算溢出。如果技能在isolated臂稳定激活但在plugin臂持续不激活skillActivationIsolated.activated: true但skillActivationPlugin.activated: false且detectedSkills为空原因通常不是描述文本——它可能根本没被展示。Copilot CLI 在硬性 15,000 字符预算agent SDK 的SKILL_CHAR_BUDGET默认15e3下渲染模型可见的available_skills菜单。技能按名称字母序排列只有完整description在预算耗尽前被带出越过截断点的每个技能都坍缩为只有裸名称、没有描述无法再被模型可靠激活。在大插件中字母序靠后的技能如run-tests、test-*会静默丢失其在插件菜单中的描述尽管在 isolated 下表现正常。这种情况的修复调描述文本无效——文本根本不在菜单里给从不需要被用户提示词直接调用、仅由 reference/agent 编排的技能标注disable-model-invocation: true。CLI 会将其完全移出菜单为应被发现的技能腾出预算它们仍可按显式名称调用。缩小插件的整体 skill-menu 占用使其可模型调用的技能落入预算之内。check命令通过SkillProfiler.MaxRenderedSkillMenuLength15,000强制执行此约束计算每个可模型调用技能渲染后的skill块名称 描述 位置 标记经SkillProfiler.RenderedSkillMenuCost且只统计没有disable-model-invocation: true的技能——按渲染块统计使通过check成为能装进真实 CLI 菜单预算的忠实代理。最后手段合并重叠技能减少插件暴露的可模型调用条目。模式 6rubric 惩罚了有效的替代方案症状pairwise judge 在 baseline 与技能之间选择 baseline两个输出都正确但用了不同方法pairwiseResult.rubricResults显示 rubric 标准过窄原因rubric 条目偏向某一种特定方法如逐步 UI 操作演示而非同样有效的替代方案如单条 CLI 命令。修复放宽 rubric显式接受多种有效方法示例不用Shows step-by-step UI configuration改用Explains how to connect — either as a single CLI command or via the UI configuration。模式 7势均力敌时 judge 判定回退症状质量分数相近但overallJudgmentImprovement为 -0.4pairwise judge 在交换位置的两轮运行间不一致原因输出近乎相同时judge 的位置偏差可能占主导。位置交换缓解策略在结果不一致时默认判平局但加权计分仍会惩罚。修复这通常是噪声——重跑评估看是否持续若持续出现改进技能以产出明显有差异化的输出。从源码看位置交换缓解由 PairwiseJudge.cs 实现对同一场景同时发起 forwardbaseline 在前与 reverse技能在前两次 judge 调用比较OverallWinner一致性不一致时调用MergeInconsistentResults合并为平局并置PositionSwapConsistent false同时输出警告。模式 8基线已经很好没有提升空间症状基线分数高4.5–5.0/5技能分数相近或略低perRunScores持续为负如[-0.42, -0.73, -0.47]breakdown 显示负的tokenReduction与toolCallReduction技能开销但无质量增益原因模型从训练数据中已经精通该主题。技能无法在已经很好的答案上再改进而加载技能的额外开销多出的 token、工具调用导致净回退。修复加reject_tools约束如[bash, edit]让 baseline 或 skilled agent 使用这些工具即失败——把对比焦点拉回到答案质量而非工具诱导的开销把场景改难让基线吃力——加入需要技能特有知识的复杂度、边界情况或约束把提示词改写成纯诊断式如不要修改任何文件——只解释根因防止 agent 把时间花在工具调用上如果模型不用技能也稳定拿到 5.0/5就移除该场景——它没有在测试技能的价值。7. 多个模式同时命中时的处理优先级大多数失败场景同时命中 2–3 个模式如超时 token 开销 高方差。按以下优先级修复超时模式 1——模型完不成任务时其他都无从谈起。先调大 timeout。技能未激活模式 5——技能根本没加载先修 description 再调其他。基线本身就差模式 2——基线分数 ≤2.0/5 时场景可能无论如何都需要简化。基线已经很好模式 8——基线 ≥4.5/5 时考虑加reject_tools、把场景改难或移除。高方差模式 3——perRunScores不稳定时单次评估不可靠。先重跑再下技能坏了的结论。rubric/评分问题模式 6、7——运行稳定之后再调 rubric。token 开销模式 4——只有质量已好但加权分勉强为负时才优化。8. 改进技能 vs. 刷评估分数排查失败时目标是让技能对用户更有用——而不是单纯让评估分数涨上去。分数提升应当是技能变好的证据而非目的本身。正当修复改进技能更好的技能内容、结构或示例更好的 frontmatterdescription让技能在相关提示词下激活移除基线已完美得分的场景技能确实没有新增价值加setup.files让场景测试预期目标而非搭建能力。不正当修复刷评估放宽 rubric 标准让两边都少干活多得分把 rubric 条目改写为匹配技能碰巧产出的东西而非好答案应当包含的内容软化提示词预期回避暴露真实技能弱点加reject_tools掩盖 baseline 与 skilled 运行的行为分歧如 baseline 解释而 skilled 运行编辑文件——约束工具让分数收敛但没解决根本问题。灰色地带自行判断收紧提示词以降低歧义提示词确实含糊时是正当的刻意引导向技能优势时不正当放宽 rubric接受多种有效方法上文模式 6接受正确的替代方法正当接受错误方法不正当移除场景因为基线本来就满分是诚实的承认因为技能使其变差而移除则是掩盖问题。拿不准时问自己这个改动会让技能对真实用户更有用还是只是让数字变大9. 用 AI Agent 分析结果results.json设计为机器可读。AI Agent 可以做解析 JSON并提取每个场景的指标对比 baseline vs skilled 指标识别回退读agentOutput看模型实际产出了什么检查assertionResults看哪些断言失败读pairwiseResult.rubricResults获取 judge 逐条标准的推理检查perRunScores评估方差看toolCallBreakdown理解模型把时间花在哪交叉对照isolatedBreakdown看哪些指标驱动了分数检查overfittingResult若存在——看rubricAssessments中被分类为technique的条目rubric 在强制特定方法而非测试结果这些是放宽的候选同时检查crossScenarioIssues中关于评估设计的系统性问题。过拟合检测的完整设计分类体系、few-shot 提示、评分公式、--overfitting-fix生成eval.fixed.yaml见 OverfittingDetection.md。示例分析脚本注意保存为.py文件运行不要用python -c ...——f-string 字典访问中的嵌套引号在命令行中很难转义。import json def analyze(path): with open(path) as f: data json.load(f) for verdict in data[verdicts]: print(f {verdict[skillName]} (passed{verdict[passed]}) ) for scenario in verdict[scenarios]: name scenario[scenarioName] bl_metrics scenario[baseline][metrics] sk_metrics scenario[skilledIsolated][metrics] bl_quality scenario[baseline].get(judgeResult, {}).get(overallScore, ?) sk_quality scenario[skilledIsolated].get(judgeResult, {}).get(overallScore, ?) improvement scenario.get(improvementScore, 0) print(f\n--- {name} ---) print(f Quality: baseline{bl_quality}/5, skilled{sk_quality}/5) print(f Baseline: timedOut{bl_metrics[timedOut]}, tokens{bl_metrics.get(tokenEstimate, 0)}) print(f input{bl_metrics.get(inputTokens, 0)}, output{bl_metrics.get(outputTokens, 0)}) print(f Skilled: timedOut{sk_metrics[timedOut]}, tokens{sk_metrics.get(tokenEstimate, 0)}) print(f input{sk_metrics.get(inputTokens, 0)}, output{sk_metrics.get(outputTokens, 0)}) print(f Improvement: {improvement:.1%}) # perRunScores is a flat list of numbers (one per run) per_run scenario.get(perRunScores, []) if per_run: formatted , .join(f{s:.2f} for s in per_run) print(f Per-run scores: [{formatted}]) for a in sk_metrics.get(assertionResults, []): status PASS if a[passed] else FAIL print(f Assertion [{status}]: {a[message]}) analyze(results.json)10. 配套背景legacy 评估的整体工作方式为了更好地定位问题理解results.json在整个 legacy 评估链中的位置很有帮助详见 skill-validator README发现技能含SKILL.md的目录→读取每个技能的tests/eval.yaml场景→ 对每个场景运行不带技能baseline与带技能两次 agent → 采集 token、工具调用、时间、错误、任务完成度指标 →pairwise 对比评分LLM judge 并排看两个输出带位置交换偏差缓解→ 多次运行 bootstrap 计算置信区间→ 产出带统计显著性的 verdict → 把详细结果JSON markdown保存到.skill-validator-results/。关键 CLI 默认值与results.json中的字段一一对应--model默认claude-opus-4.6、--judge-model默认同--model、--min-improvement默认0.1、--runs默认5、--judge-timeout默认300秒、--require-completion默认开启、--judge-mode默认pairwise见 EvaluateCommand.cs。统计置信度结果显示 bootstrap 置信区间与归一化增益gHake 1998 公式(post - pre) / (1 - pre)用于控制天花板效应见 Comparator.cs 的ComputeNormalizedGain。significant 表示 95% CI 不跨越零——改进是真实的not significant 表示 CI 跨越零——可能是噪声。需要说明的是这些区间描述的是 legacy 运行池报告仓库当前的 Vally 门控不把重复运行当作独立任务样本——运行度量的是刺激内可靠性而统计投票来自不同的刺激。11. 延伸阅读skill-validator README —— CLI 用法、eval 文件格式、评分权重Overfitting detection —— 过拟合分数如何计算Vally 适配器现状指南 —— 当前 Vally harness 的排查入口vally-results-*产物、state权威字段、adapter-summary.json对账、20% 净胜与 p 值门控Vally 适配器总览 —— 端到端架构与决策策略真实评估场景示例tests/dotnet-blazor/author-component/eval.yaml【免费下载链接】skillsRepository for skills to assist AI coding agents with .NET and C#项目地址: https://gitcode.com/GitHub_Trending/skills17/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考