1. 从security-audit-skill这个名字说起它到底在解决什么问题第一次看到security-audit-skill这个命名我的直觉是这不是一个普通的脚本集合而是一个被封装成技能形态的安全审计能力单元。关键词里同时出现了skill、agent、findings.json、coverage-ledger.json这几个词放在一起基本可以勾勒出它的轮廓——一个面向 AI Agent 生态的安全审计技能包通过结构化的产物文件findings 和 coverage ledger来输出审计结果和覆盖度账本。为什么我这么判断因为findings.json是安全审计领域非常经典的输出格式几乎所有静态分析工具SAST、依赖扫描器、密钥检测工具都会把结果归一化成一份发现列表。而coverage-ledger.json这个词更有意思——ledger是账本的意思它暗示这个技能不只是告诉你发现了什么还要告诉你我检查了什么、没检查什么、检查到什么程度。这是安全审计里最容易被忽视、却最致命的一环漏报比误报更可怕而漏报往往源于覆盖度不透明。所以这篇内容我想聊的不是怎么调用一个现成工具而是把这个技能拆开来看它的设计逻辑是什么、产物文件为什么长这样、在 Agent 体系里它扮演什么角色、实际落地时会踩哪些坑。适合谁看如果你正在做 Agent 开发、在给团队搭安全审计流水线、或者单纯想理解skill 和 agent 到底怎么配合这篇应该能给你一些可以直接抄的作业。我先把结论摆前面security-audit-skill这类技能的核心价值不在于它用了多先进的检测算法而在于它把审计过程变成了可追溯、可复现、可审计的产物。这一点是它和传统一次性扫描脚本最大的区别。2. 拆解 security-audit-skill 的能力边界它能做什么不能做什么2.1 一个 skill 在 agent 体系里的真实定位很多人一上来就把 skill 和 agent 混为一谈这是最常见的认知偏差。我自己的理解是agent 是决策者skill 是执行单元。agent 负责理解任务、规划步骤、决定调用哪个 skillskill 负责在明确的输入输出契约下把一件事做扎实。放到security-audit-skill上它的定位就很清晰了agent 接到帮我审计这个仓库的安全性这样的任务后会把这个 skill 挂载进来由 skill 去执行具体的扫描、分析、结果归一化最后吐出findings.json和coverage-ledger.json。agent 拿到这两份产物后再决定要不要继续深挖、要不要生成修复建议、要不要触发下一轮审计。这个分工带来的好处是skill 可以被复用、被测试、被版本管理而 agent 的逻辑可以保持轻量。坏处是如果 skill 的输入输出契约设计得不好agent 就会看不懂结果整个链路就断了。这也是为什么findings.json和coverage-ledger.json的 schema 设计比检测逻辑本身还重要。2.2 findings.json 里应该装什么我见过太多团队把 findings 写成一个大杂烩什么字段都往里塞最后没人愿意看。一份合格的findings.json我建议至少包含这几类信息字段类别作用常见坑定位信息文件路径、行号、列号、代码片段只给行号不给上下文修复时找不到分类信息漏洞类型、CWE 编号、严重等级等级拍脑袋定没有统一标准证据信息触发条件、数据流路径、复现步骤只给结论不给证据无法验证修复信息建议方案、参考链接、修复优先级建议太泛等于没说元信息检测器名称、检测时间、置信度缺置信度误报无法过滤这里我要特别强调**置信度confidence**这个字段。安全审计里误报是常态如果 findings 里没有置信度agent 就没法做二次判断人也没法快速排序。我的经验是把置信度分成 high/medium/low 三档high 直接进修复队列medium 进人工复核队列low 只做记录不打扰人。这个简单的分级能省掉大量无效沟通。2.3 coverage-ledger.json 才是这个技能的灵魂如果说 findings 是我抓到了什么那 coverage ledger 就是我到底查了多少。这份账本我建议记录三类信息扫描范围哪些目录、哪些文件类型、哪些依赖被纳入了检查跳过原因哪些内容被跳过了为什么跳过二进制文件、生成代码、第三方库、显式排除规则检测器覆盖每个检测器实际运行了没有、覆盖了多少目标、有没有因为超时或报错而中断为什么这个账本这么重要举个我亲身经历的例子。有一次团队做安全审计findings 里干干净净大家以为万事大吉。结果上线后出了一个密钥泄露事故。回头查 coverage ledger 才发现那个存放密钥的配置文件因为后缀名不在白名单里被整个跳过了。findings 告诉你没有发现问题coverage ledger 才告诉你你根本没检查那里。这两者的区别就是安全审计专业与否的分水岭。提示coverage-ledger.json 一定要和 findings.json 一起产出、一起归档。只保留 findings 的审计记录等于把我没查的地方这个最关键的信息丢掉了。3. 把审计过程变成可复现的流水线我的实操拆解3.1 输入契约skill 需要 agent 喂什么一个设计良好的security-audit-skill输入不应该是一堆散乱的参数而应该是一份结构化的审计请求。我通常会把输入分成三层第一层是目标层明确审计对象是什么——是本地仓库路径、是某个 commit 范围、还是某个制品包。这一层决定了扫描的边界。第二层是策略层明确用什么规则集、什么严重等级阈值、要不要包含依赖扫描、要不要做密钥检测。这一层决定了扫描的深度和广度。第三层是上下文层比如这个项目是什么语言、用了什么框架、有没有已知的豁免清单。这一层决定了检测器怎么选、误报怎么压。我踩过的一个坑是早期我把这三层混在一个大 JSON 里传结果 agent 每次调用都要重新拼装很容易漏字段。后来改成三层嵌套结构并且给每一层都设了默认值agent 只需要传它关心的部分其余走默认。这个改动让调用成功率从大概七成提到了九成以上。3.2 执行阶段检测器怎么编排skill 内部通常不是一个检测器而是一组检测器。编排方式直接决定了效率和覆盖度。我见过两种典型做法一种是串行执行一个检测器跑完再跑下一个。优点是实现简单、资源占用低缺点是慢而且一个检测器卡住会拖垮整条链路。另一种是并行执行 超时熔断多个检测器同时跑每个都有独立的超时时间超时了就记录到 coverage ledger 里标记为未完成。优点是快、鲁棒缺点是实现复杂需要处理资源竞争。我的建议是默认并行但对资源敏感的检测器比如需要编译的、需要起服务的单独串行。同时每个检测器的执行结果都要写进 coverage ledger包括耗时、状态、覆盖目标数。这样即使某个检测器挂了你也能从账本里一眼看出来。这里有个细节值得说检测器的执行顺序其实会影响结果。比如密钥检测应该在代码压缩/混淆之前做依赖扫描应该在构建之后做。如果顺序错了要么漏报要么误报。我在实际项目里会把检测器分成几个阶段stage阶段内并行、阶段间串行用阶段来保证依赖关系。3.3 输出归一化为什么不能各写各的每个检测器天然有自己的输出格式有的吐 JSON有的吐 SARIF有的吐纯文本。如果直接把原始输出塞进 findings.jsonagent 根本没法统一处理。所以归一化层是这个技能里最不能省的部分。归一化的核心工作是把不同来源的发现映射到统一的 schema 上。我通常要求归一化层做到三件事字段对齐不管原始格式如何最终都要有统一的定位、分类、证据、修复、元信息字段去重合并同一个问题被多个检测器报出来要合并成一条并记录所有来源等级统一不同检测器的严重等级标准不一样要映射到统一的等级体系上去重这一步特别容易被低估。我做过统计在一个中等规模的 Java 项目里不做去重的话findings 数量会虚高 30% 到 50%。虚高的后果是 agent 和人都被淹没在重复信息里真正重要的问题反而被埋了。4. 落地时最容易翻车的几个地方4.1 覆盖度账本被当成可选项这是我最想强调的一点。很多团队做审计技能把 90% 的精力花在检测逻辑上coverage ledger 随便糊弄一下甚至干脆不做。结果就是审计报告看起来很漂亮但没人敢信。我的做法是把 coverage ledger 的完整性作为 skill 的验收硬指标。具体来说每次审计结束后要能回答这几个问题总共多少个文件被纳入候选多少个实际被扫描多少个被跳过跳过的原因分布是什么每个检测器的完成率是多少如果这些问题答不上来这次审计就不算完成。4.2 误报处理没有闭环安全审计的误报是躲不掉的。问题不在于有没有误报而在于误报有没有被系统性地处理。我见过两种极端一种是完全不管误报findings 越积越多最后没人看另一种是人工一条条标记效率极低还容易漏。我的经验是建一个误报豁免机制允许在配置里声明豁免规则比如某个路径、某个规则、某个指纹豁免规则本身也要进 coverage ledger记录这里被豁免了原因是某某。这样既压了误报又保持了透明度。关键是豁免要有有效期和复审机制不能一免了之。4.3 agent 和 skill 的契约漂移skill 是会迭代的schema 是会变的。如果 agent 那边还按老 schema 解析就会出问题。我踩过的坑是skill 升级后给 findings 加了一个字段结果 agent 的解析逻辑没跟上直接把整个结果判为无效。解决办法是给产物文件加版本号并且在 skill 的文档里明确标注 schema 的兼容性策略。agent 侧要做防御性解析——遇到不认识的字段忽略而不是报错遇到缺失的必需字段才报错。这个习惯能省掉大量联调时间。4.4 性能与覆盖度的取舍审计技能跑得慢是常态尤其是大仓库。我见过有人为了追求覆盖度把所有文件都扫一遍结果一次审计跑几个小时根本没法进 CI。也见过有人为了快只扫改动文件结果漏掉了历史遗留问题。我的折中方案是分层审计日常 CI 只扫改动范围增量保证快速反馈定期比如每天一次跑全量审计保证覆盖度发布前跑一次带依赖扫描和密钥检测的深度审计。三档审计用同一套 skill只是输入策略不同。这样既保证了速度又不牺牲覆盖度。5. 从 findings 到行动让审计结果真正被用起来5.1 结果分级与路由findings 产出后如果不做分级和路由就是一堆死数据。我的做法是按严重等级 × 置信度做一个二维矩阵把发现分成四类高置信度低置信度高严重立即修复阻断合并人工复核优先处理低严重排期修复记录观察这个矩阵的好处是它把要不要现在处理这个决策变成了查表agent 和人都不需要临场判断。我在实际项目里把这个矩阵写进了 skill 的输出里每条 finding 直接带上建议动作字段下游直接用。5.2 和修复流程的衔接审计的终点不是报告是修复。所以 findings 里必须包含足够支撑修复的信息。我特别看重两点一是代码上下文至少要给出问题行前后几行二是修复建议的可操作性最好能给出具体的改法而不是建议加强校验这种废话。如果 skill 能进一步生成修复补丁哪怕是草稿价值会大很多。我试过让 agent 基于 findings 生成修复建议效果取决于 findings 的质量——findings 里证据越充分生成的建议越靠谱。这也反过来印证了前面说的产物 schema 的设计决定了整个链路的上限。5.3 审计结果的历史追踪单次审计的结果价值有限把多次审计的结果串起来才有意思。我建议把每次的 findings 和 coverage ledger 都归档然后做趋势分析某类问题是在减少还是增加覆盖度是在提升还是下降某个检测器是不是一直没跑成功这些趋势信息比单次报告更能反映一个项目的安全健康状况。我在一个长期项目里就靠这个发现了一个规律每次大版本发布前密钥检测的覆盖率都会掉原因是新增的配置文件后缀没进白名单。发现这个规律后我们把它固化成了发布检查项问题就再没出现过。6. 关于 skill 设计的一点个人体会做security-audit-skill这类东西我最大的体会是它的难点从来不在检测算法而在工程契约。检测算法可以抄、可以买、可以用开源但输入输出契约、覆盖度账本、误报闭环、版本兼容这些脏活才是决定它能不能真正落地的关键。我见过太多团队把精力花在多接几个检测器上结果接了一堆产物格式五花八门agent 用不了人也不想看。反倒是那些老老实实把 schema 设计好、把 coverage ledger 做扎实的团队最后跑得最稳。还有一个反直觉的点skill 不是越全能越好。一个 skill 如果什么都想干最后往往什么都干不精。security-audit-skill就应该专注在审计这件事上把审计做深做透至于修复、至于报告美化、至于通知分发交给别的 skill 或者 agent 去做。职责单一契约清晰这才是 skill 生态能健康运转的前提。最后分享一个我一直在用的小技巧每次 skill 迭代后拿一个已知有问题的靶场仓库跑一遍对比 findings 和 coverage ledger 的变化。如果发现的问题变多了要确认是真发现了新问题还是误报增加了如果覆盖度掉了要查清楚是哪个检测器出了问题。这个回归测试的习惯帮我挡掉了好几次升级即翻车的事故。
1. 从security-audit-skill这个名字说起它到底在解决什么问题第一次看到security-audit-skill这个命名我的直觉是这不是一个普通的脚本集合而是一个被封装成技能形态的安全审计能力单元。关键词里同时出现了skill、agent、findings.json、coverage-ledger.json这几个词放在一起基本可以勾勒出它的轮廓——一个面向 AI Agent 生态的安全审计技能包通过结构化的产物文件findings 和 coverage ledger来输出审计结果和覆盖度账本。为什么我这么判断因为findings.json是安全审计领域非常经典的输出格式几乎所有静态分析工具SAST、依赖扫描器、密钥检测工具都会把结果归一化成一份发现列表。而coverage-ledger.json这个词更有意思——ledger是账本的意思它暗示这个技能不只是告诉你发现了什么还要告诉你我检查了什么、没检查什么、检查到什么程度。这是安全审计里最容易被忽视、却最致命的一环漏报比误报更可怕而漏报往往源于覆盖度不透明。所以这篇内容我想聊的不是怎么调用一个现成工具而是把这个技能拆开来看它的设计逻辑是什么、产物文件为什么长这样、在 Agent 体系里它扮演什么角色、实际落地时会踩哪些坑。适合谁看如果你正在做 Agent 开发、在给团队搭安全审计流水线、或者单纯想理解skill 和 agent 到底怎么配合这篇应该能给你一些可以直接抄的作业。我先把结论摆前面security-audit-skill这类技能的核心价值不在于它用了多先进的检测算法而在于它把审计过程变成了可追溯、可复现、可审计的产物。这一点是它和传统一次性扫描脚本最大的区别。2. 拆解 security-audit-skill 的能力边界它能做什么不能做什么2.1 一个 skill 在 agent 体系里的真实定位很多人一上来就把 skill 和 agent 混为一谈这是最常见的认知偏差。我自己的理解是agent 是决策者skill 是执行单元。agent 负责理解任务、规划步骤、决定调用哪个 skillskill 负责在明确的输入输出契约下把一件事做扎实。放到security-audit-skill上它的定位就很清晰了agent 接到帮我审计这个仓库的安全性这样的任务后会把这个 skill 挂载进来由 skill 去执行具体的扫描、分析、结果归一化最后吐出findings.json和coverage-ledger.json。agent 拿到这两份产物后再决定要不要继续深挖、要不要生成修复建议、要不要触发下一轮审计。这个分工带来的好处是skill 可以被复用、被测试、被版本管理而 agent 的逻辑可以保持轻量。坏处是如果 skill 的输入输出契约设计得不好agent 就会看不懂结果整个链路就断了。这也是为什么findings.json和coverage-ledger.json的 schema 设计比检测逻辑本身还重要。2.2 findings.json 里应该装什么我见过太多团队把 findings 写成一个大杂烩什么字段都往里塞最后没人愿意看。一份合格的findings.json我建议至少包含这几类信息字段类别作用常见坑定位信息文件路径、行号、列号、代码片段只给行号不给上下文修复时找不到分类信息漏洞类型、CWE 编号、严重等级等级拍脑袋定没有统一标准证据信息触发条件、数据流路径、复现步骤只给结论不给证据无法验证修复信息建议方案、参考链接、修复优先级建议太泛等于没说元信息检测器名称、检测时间、置信度缺置信度误报无法过滤这里我要特别强调**置信度confidence**这个字段。安全审计里误报是常态如果 findings 里没有置信度agent 就没法做二次判断人也没法快速排序。我的经验是把置信度分成 high/medium/low 三档high 直接进修复队列medium 进人工复核队列low 只做记录不打扰人。这个简单的分级能省掉大量无效沟通。2.3 coverage-ledger.json 才是这个技能的灵魂如果说 findings 是我抓到了什么那 coverage ledger 就是我到底查了多少。这份账本我建议记录三类信息扫描范围哪些目录、哪些文件类型、哪些依赖被纳入了检查跳过原因哪些内容被跳过了为什么跳过二进制文件、生成代码、第三方库、显式排除规则检测器覆盖每个检测器实际运行了没有、覆盖了多少目标、有没有因为超时或报错而中断为什么这个账本这么重要举个我亲身经历的例子。有一次团队做安全审计findings 里干干净净大家以为万事大吉。结果上线后出了一个密钥泄露事故。回头查 coverage ledger 才发现那个存放密钥的配置文件因为后缀名不在白名单里被整个跳过了。findings 告诉你没有发现问题coverage ledger 才告诉你你根本没检查那里。这两者的区别就是安全审计专业与否的分水岭。提示coverage-ledger.json 一定要和 findings.json 一起产出、一起归档。只保留 findings 的审计记录等于把我没查的地方这个最关键的信息丢掉了。3. 把审计过程变成可复现的流水线我的实操拆解3.1 输入契约skill 需要 agent 喂什么一个设计良好的security-audit-skill输入不应该是一堆散乱的参数而应该是一份结构化的审计请求。我通常会把输入分成三层第一层是目标层明确审计对象是什么——是本地仓库路径、是某个 commit 范围、还是某个制品包。这一层决定了扫描的边界。第二层是策略层明确用什么规则集、什么严重等级阈值、要不要包含依赖扫描、要不要做密钥检测。这一层决定了扫描的深度和广度。第三层是上下文层比如这个项目是什么语言、用了什么框架、有没有已知的豁免清单。这一层决定了检测器怎么选、误报怎么压。我踩过的一个坑是早期我把这三层混在一个大 JSON 里传结果 agent 每次调用都要重新拼装很容易漏字段。后来改成三层嵌套结构并且给每一层都设了默认值agent 只需要传它关心的部分其余走默认。这个改动让调用成功率从大概七成提到了九成以上。3.2 执行阶段检测器怎么编排skill 内部通常不是一个检测器而是一组检测器。编排方式直接决定了效率和覆盖度。我见过两种典型做法一种是串行执行一个检测器跑完再跑下一个。优点是实现简单、资源占用低缺点是慢而且一个检测器卡住会拖垮整条链路。另一种是并行执行 超时熔断多个检测器同时跑每个都有独立的超时时间超时了就记录到 coverage ledger 里标记为未完成。优点是快、鲁棒缺点是实现复杂需要处理资源竞争。我的建议是默认并行但对资源敏感的检测器比如需要编译的、需要起服务的单独串行。同时每个检测器的执行结果都要写进 coverage ledger包括耗时、状态、覆盖目标数。这样即使某个检测器挂了你也能从账本里一眼看出来。这里有个细节值得说检测器的执行顺序其实会影响结果。比如密钥检测应该在代码压缩/混淆之前做依赖扫描应该在构建之后做。如果顺序错了要么漏报要么误报。我在实际项目里会把检测器分成几个阶段stage阶段内并行、阶段间串行用阶段来保证依赖关系。3.3 输出归一化为什么不能各写各的每个检测器天然有自己的输出格式有的吐 JSON有的吐 SARIF有的吐纯文本。如果直接把原始输出塞进 findings.jsonagent 根本没法统一处理。所以归一化层是这个技能里最不能省的部分。归一化的核心工作是把不同来源的发现映射到统一的 schema 上。我通常要求归一化层做到三件事字段对齐不管原始格式如何最终都要有统一的定位、分类、证据、修复、元信息字段去重合并同一个问题被多个检测器报出来要合并成一条并记录所有来源等级统一不同检测器的严重等级标准不一样要映射到统一的等级体系上去重这一步特别容易被低估。我做过统计在一个中等规模的 Java 项目里不做去重的话findings 数量会虚高 30% 到 50%。虚高的后果是 agent 和人都被淹没在重复信息里真正重要的问题反而被埋了。4. 落地时最容易翻车的几个地方4.1 覆盖度账本被当成可选项这是我最想强调的一点。很多团队做审计技能把 90% 的精力花在检测逻辑上coverage ledger 随便糊弄一下甚至干脆不做。结果就是审计报告看起来很漂亮但没人敢信。我的做法是把 coverage ledger 的完整性作为 skill 的验收硬指标。具体来说每次审计结束后要能回答这几个问题总共多少个文件被纳入候选多少个实际被扫描多少个被跳过跳过的原因分布是什么每个检测器的完成率是多少如果这些问题答不上来这次审计就不算完成。4.2 误报处理没有闭环安全审计的误报是躲不掉的。问题不在于有没有误报而在于误报有没有被系统性地处理。我见过两种极端一种是完全不管误报findings 越积越多最后没人看另一种是人工一条条标记效率极低还容易漏。我的经验是建一个误报豁免机制允许在配置里声明豁免规则比如某个路径、某个规则、某个指纹豁免规则本身也要进 coverage ledger记录这里被豁免了原因是某某。这样既压了误报又保持了透明度。关键是豁免要有有效期和复审机制不能一免了之。4.3 agent 和 skill 的契约漂移skill 是会迭代的schema 是会变的。如果 agent 那边还按老 schema 解析就会出问题。我踩过的坑是skill 升级后给 findings 加了一个字段结果 agent 的解析逻辑没跟上直接把整个结果判为无效。解决办法是给产物文件加版本号并且在 skill 的文档里明确标注 schema 的兼容性策略。agent 侧要做防御性解析——遇到不认识的字段忽略而不是报错遇到缺失的必需字段才报错。这个习惯能省掉大量联调时间。4.4 性能与覆盖度的取舍审计技能跑得慢是常态尤其是大仓库。我见过有人为了追求覆盖度把所有文件都扫一遍结果一次审计跑几个小时根本没法进 CI。也见过有人为了快只扫改动文件结果漏掉了历史遗留问题。我的折中方案是分层审计日常 CI 只扫改动范围增量保证快速反馈定期比如每天一次跑全量审计保证覆盖度发布前跑一次带依赖扫描和密钥检测的深度审计。三档审计用同一套 skill只是输入策略不同。这样既保证了速度又不牺牲覆盖度。5. 从 findings 到行动让审计结果真正被用起来5.1 结果分级与路由findings 产出后如果不做分级和路由就是一堆死数据。我的做法是按严重等级 × 置信度做一个二维矩阵把发现分成四类高置信度低置信度高严重立即修复阻断合并人工复核优先处理低严重排期修复记录观察这个矩阵的好处是它把要不要现在处理这个决策变成了查表agent 和人都不需要临场判断。我在实际项目里把这个矩阵写进了 skill 的输出里每条 finding 直接带上建议动作字段下游直接用。5.2 和修复流程的衔接审计的终点不是报告是修复。所以 findings 里必须包含足够支撑修复的信息。我特别看重两点一是代码上下文至少要给出问题行前后几行二是修复建议的可操作性最好能给出具体的改法而不是建议加强校验这种废话。如果 skill 能进一步生成修复补丁哪怕是草稿价值会大很多。我试过让 agent 基于 findings 生成修复建议效果取决于 findings 的质量——findings 里证据越充分生成的建议越靠谱。这也反过来印证了前面说的产物 schema 的设计决定了整个链路的上限。5.3 审计结果的历史追踪单次审计的结果价值有限把多次审计的结果串起来才有意思。我建议把每次的 findings 和 coverage ledger 都归档然后做趋势分析某类问题是在减少还是增加覆盖度是在提升还是下降某个检测器是不是一直没跑成功这些趋势信息比单次报告更能反映一个项目的安全健康状况。我在一个长期项目里就靠这个发现了一个规律每次大版本发布前密钥检测的覆盖率都会掉原因是新增的配置文件后缀没进白名单。发现这个规律后我们把它固化成了发布检查项问题就再没出现过。6. 关于 skill 设计的一点个人体会做security-audit-skill这类东西我最大的体会是它的难点从来不在检测算法而在工程契约。检测算法可以抄、可以买、可以用开源但输入输出契约、覆盖度账本、误报闭环、版本兼容这些脏活才是决定它能不能真正落地的关键。我见过太多团队把精力花在多接几个检测器上结果接了一堆产物格式五花八门agent 用不了人也不想看。反倒是那些老老实实把 schema 设计好、把 coverage ledger 做扎实的团队最后跑得最稳。还有一个反直觉的点skill 不是越全能越好。一个 skill 如果什么都想干最后往往什么都干不精。security-audit-skill就应该专注在审计这件事上把审计做深做透至于修复、至于报告美化、至于通知分发交给别的 skill 或者 agent 去做。职责单一契约清晰这才是 skill 生态能健康运转的前提。最后分享一个我一直在用的小技巧每次 skill 迭代后拿一个已知有问题的靶场仓库跑一遍对比 findings 和 coverage ledger 的变化。如果发现的问题变多了要确认是真发现了新问题还是误报增加了如果覆盖度掉了要查清楚是哪个检测器出了问题。这个回归测试的习惯帮我挡掉了好几次升级即翻车的事故。
