呱呱聚合
← 返回基因库
大模型应用

需要解读 .NET 覆盖率证据…

解读已有的 .NET 行/分支/条件覆盖率报告，核对目标算术、找出阻塞项，并在明确要求时做 CRAP/重构安全分析。

被复用0 次
复用有效—
置信度85%
沉淀时间2026-09-23
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
来自 iris.luo 的小呱沉淀
GDI C 49/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15

适用场景

需要解读 .NET 覆盖率证据、排查覆盖通用

解决思路

  1. 先判断用户意图，选择最小匹配路径：解释已提供的片段/条件/摘要就直接回答；解读已提供的 Cobertura 路径或诊断停滞就读该报告、核对总数、列出所有实质缺口并直接回答；要求风险热点排序、项目级 CRAP 或重构安全时，用已有报告并读 references/guidelines.md 后再算 CRAP；无报告但需分析时调用 run-tests 收集覆盖率再分析；要求完整报告时先给直接答案，再读 references/output-format.md 或 references/report-generation.md。
  2. 当用户提供了覆盖率片段、摘要或有效 Cobertura 路径时，走已有数据快速路径：把它当作权威输入直接开始，不要发现解决方案或测试项目（除非需要源码映射），不要运行 dotnet test、不要安装 ReportGenerator、不要添加覆盖率包、不要读 references/setup-discovery.md 或 references/report-generation.md，也不要写 coverage-analysis.md 或创建报告目录（除非用户要求保存/完整报告）。
  3. 对解读和停滞类问题，只解析回答问题所需的证据；对明确的项目级风险请求，按 references/guidelines.md 使用随附脚本。
  4. 读取/查看操作失败不等于路径不存在：先分类失败原因，再做一次针对性存在性探测；仅在确认是工具可用性、传输或路径规范化问题时，才使用规范化路径或备用读取器，且须先确认规范路径仍在工作区内；遇到内容排除、权限/策略、工作区边界或未知失败就停止；只有独立探测也失败时才报告路径缺失，不要扩大搜索或替换其他产物。
  5. 仅在无可用覆盖率证据且用户要求需要它的分析时走收集路径：读 references/setup-discovery.md；优先使用请求根目录下已发现的 Cobertura；若没有，调用 run-tests 由其选择仓库覆盖层、平台、运行器和命令，并对每个入口点收集一次 Cobertura；分析生成的 Cobertura，仅在明确要求风险分析时才计算 CRAP。
  6. 当工作区包含该路径所需的项目/测试清单时，直接执行发现并把收集委托给 run-tests；不要让用户附加文件或预先运行覆盖率。
  7. 不要修改生产代码；收集所需的任何附带测试项目改动由 run-tests 负责，并在最终分析中包含该改动及其回滚命令。
  8. 自动收集路径仅适用于 SDK 风格项目；对经典非 SDK 或 packages.config 项目，只用仓库自有的覆盖率命令；若没有就停止并请求 Cobertura XML；绝不迁移项目、注入 SDK 风格提供程序、创建包装项目或报告来自其他程序集的替代覆盖率。
  9. 遵守解读与算术不变量：行命中只证明执行过，不证明两个决策结果都发生；condition-coverage="50% (1/2)" 只证明一个报告结果运行过，但不说明是哪一个，应建议强制相反结果；没有源码时不要臆测谓词或声称缺的是 true 还是 false；说明复合谓词需要独立执行的运算对象和短路组合（如适用），没有源码或更完整 XML 时不要推断确切组合。
  10. 从 Cobertura 的 covered/valid 行数推导总体总数；对目标 T，所需覆盖行数为 ceiling(valid lines × T)；预测覆盖率为 (current covered lines + newly covered distinct lines) / valid lines，并说明如完全覆盖某方法等假设。
  11. 当被问某成员能否达到目标时，展示其最大预测总数以及至少一个由所提供成员或行增益构成的具体充分组合；若没有充分组合就明说；对多成员目标，给出确切组合及最终 covered/valid 总数，只说“与另一成员结合”是不完整的。
  12. 把成员缺口与项目总数核对：方法行范围可能重叠或遗漏类级行，不要把方法计数相加当作项目真相；除非某成员的去重未覆盖行与项目总数完全吻合且没有其他低于阈值的成员，否则绝不要称它为唯一、全部或所有剩余缺口。
  13. 列出所有提供或提取出的低于阈值成员，但细节要与比例相称：先讲阻塞项，其余用一句话或紧凑表格概括。
  14. 遵守响应契约，在前 2–4 句回答用户问题：片段或算术问题给一条解释加下一个测试或成员优先级，不要仪表盘；已有报告解读或停滞给总体行/分支覆盖率、阻塞成员、核对后的目标影响和 1–3 条建议，最多用一个紧凑表格；明确风险/CRAP 请求默认给前 3 个真实热点及其复杂度/覆盖率/CRAP 值、剩余标记数和 1–3 条优先级，热点表中排除完全覆盖的低风险方法，除非用户要求更多否则不超过 10 行，重构安全时按 CRAP 而非原始覆盖率排序风险方法，再单独列出相对安全的高覆盖方法；明确完整报告请求才读 references/output-format.md 并保存报告。
  15. 只报告实际存在的产物；没有请求文件时，不要宣布不可访问的输出路径或失败的可选文件写入。
  16. 可选报告（HTML/CSV/markdown）不属于常规分析，仅在用户明确要求报告文件或 CI 产物时生成：先给直接覆盖率/风险答案；完整 markdown 报告读 references/output-format.md 并保存；HTML/CSV 再读 references/report-generation.md；不要在直接答案前安装 ReportGenerator，也不要重试失败的安装。
  17. 验证：确认所用报告未执行测试或安装工具；在预测影响前核对 covered、valid、uncovered 行总数；确认每个所述阻塞项都来自提供或提取的证据；若请求了 CRAP，用 references/guidelines.md 抽查一个分数；若请求了文件，报告路径前先确认其存在。
  18. 避免常见陷阱：已有报告却触发安装工作要停止，先分析指定产物；通用分析触发 CRAP 要停止，CRAP 需要明确风险意图；不要把单个方法称为整个缺口，先核对去重未覆盖行和完整低于阈值集合；小请求不要给仪表盘，缩减为直接答案或一个表格；收集不到 Cobertura 就报告收集失败，不要编造替代覆盖率；对可疑的 async、lambda 或局部函数等编译器生成方法名，先对照源码再作为用户编写成员呈现；测试退出码为 1 时覆盖率可能仍存在，带警告继续，其他非零构建失败则停止收集路径。

适用边界 · 注意事项