最近一个月我陆续在几套内部项目的 CI 流程里接入了基于 Skill 的缺陷检测效果比我预想的好。以前我们做 Code Review靠几个人肉眼看漏检率一直压不下来严重的时候一个涉及权限判断的改动要反复 review 三遍还是会把“未校验当前用户”这类业务缺陷放过去。现在定义好检测 Skill 之后进 CI 的代码会先过一遍 AI 扫描再交给人工复核团队里那种“老师傅一走代码质量就塌一半”的焦虑感明显缓解了不少。这不是在吹 AI 能替代人而是换了个思路不把大模型当聊天框用而是把它包装成一套有输入、有规则、有输出的标准化检测工具也就是现在社区里很热的 Skill 机制。很多人第一次听 Skill以为只是个“高级提示词”或者“插件”其实没那么简单。这篇文章我把这套东西从概念到落地完整拆一遍重点讲清楚研发怎么用 Skill 驱动业务缺陷检测以及我们自己踩过的坑希望能给正在做同样尝试的团队一点参考。1. 先搞懂 Skill 是什么再看它怎么帮研发做检测1.1 Skill 的本质把一次检测变成可复用的标准流程Skill 在 Claude Code、Codex、OpenClaw 这类 Agent 工具里本质上是一个“能力包”把某个特定任务的提示词、脚本、上下文收集逻辑、输出格式封装成一个可以被 Agent 自动加载和调用的独立单元。拿缺陷检测来说我定义一个business-bug-detector的 Skill里面写清楚“你要做什么检测、按什么顺序读文件、读到什么模式要标记、最终输出什么格式的结果”Agent 在执行代码审查任务时就会自动加载这个 Skill而不是靠每次对话临时拼提示词。这里有个关键区别普通提示词是一次性的换个项目、换个人效果就飘忽不定Skill 是结构化的它有明确的入口文件、配置项、脚本和输出约定相当于把“一个合格审查者的工作方法”固化成了代码。我经常打一个比方提示词是给实习生口头交代“你帮我看看这段代码有啥问题”而 Skill 是给一个新人一本带标注的操作手册手册里连“先看哪几个文件、重点查哪几类问题、遇到什么情况要标记高优”都写得清清楚楚。从落地形式看一个 Skill 通常包含这几类要素声明文件描述能力范围和使用条件、规则库检测策略和权重、执行脚本扫描、提取上下文、调用模型、输出模板统一报告格式。这些东西单独拆开都不复杂但组合起来就变成了一套可以放进 CI、可以团队共享、可以不断迭代的资产。这也是为什么现在很多人说 Skill 是“把个人经验工程化”的最佳载体之一。1.2 Skill 和 Agent 的分工一个管编排一个管干活社区里关于“Skill 和 Agent 的区别”一直讨论很多。我自己的理解是Agent 是生产线上的调度系统负责拆解任务、决定先干什么后干什么、在什么条件下调用什么工具Skill 则是生产线上的专用工位负责把某一道工序做到位。以缺陷检测为例Agent 负责“接收一个代码变更 → 判断需要做哪些检查 → 决定调用哪个 Skill → 汇总多轮结果”而 Skill 负责“对某一块代码执行具体的检测逻辑”并返回结构化结果。你可以理解为Agent 是“大脑皮层”Skill 是“小脑反射弧”。如果把全部细节都塞给 Agent 的主提示词模型很容易在处理长上下文时把检测规则忘掉或者在多任务穿插时出现“角色混乱”但把规则封装进 Skill 之后Agent 只保留调度逻辑检测规则在需要时才加载既节省 token 又降低误差。我们在实际项目中测试过同一个仓库、同样的模型用 Skill 方式做缺陷检测的准确率比纯提示词方式高出大概 20% 到 30%而且输出格式稳定得多。这个分工对研发团队还有一个隐形好处调度逻辑和检测逻辑解耦后不同人可以做不同事。擅长设计流程的同学负责搭 Agent 层熟悉业务规则的同事专门维护检测 Skill 里的规则库而不用硬啃整套 Agent 框架。所以现在很多团队配置“Skill 开发”这个岗位我觉得本质上是把检测专家的经验转化成数字资产的岗位而不是单纯写代码的岗位。1.3 为什么研发不能只靠“写代码”来提升质量“不止是写代码”这个标题其实点出了研发角色的一个变化以前我们提升代码质量的手段基本就是多写测试、多写 review 文档、多上静态检查工具但这些都是“人力密集型”的。一个人一天能 review 的代码量有限一套静态规则能覆盖的场景也有限真正难抓的都是需要结合业务上下文才能判断的缺陷比如越权、资源泄漏、状态流转错误、日志泄露敏感信息等。Skill 出现之后研发的核心交付物不再只是“业务代码”本身还包括“如何让 AI 帮我们审查业务代码”的方法沉淀。你把某个业务模块的越权风险规则写进 Skill下一次所有涉及权限的改动都会自动按这个标准过一遍你发现某种资源泄漏模式补一条规则进 Skill后续类似问题就能被提前拦截。这相当于把团队里最优秀的审查者的“手感”复制到了每次代码提交里而且不会疲惫、不会漏看、不会因情绪波动而松紧不一。我不是说写代码不重要了恰恰相反越是能写出清晰代码的工程师越能把检测逻辑抽象成规则和流程。Skill 不会让研发变成“配置员”而是让研发的杠杆效应更大——写一次规则库每天都能重复使用。这正是我想在这篇里反复强调的研发用 Skill 驱动缺陷检测本质上是在用工程手段解决质量管理问题。2. 为什么业务缺陷检测最先吃到 Skill 红利2.1 检测这件事天生适合“规则 大模型”的组合业务缺陷检测和 Skill 的契合度比很多人想象中要高得多。我分析下来有三点原因。第一缺陷检测有明确的输入输出边界——输入是一段代码或一个变更集合输出是一份带风险等级和定位信息的报告这种结构化任务正好是 Skill 最擅长的场景。第二检测规则具有很强的可沉淀性——一个团队踩过的坑、积累的经验完全可以抽象成“模式 A 属于高危、模式 B 属于中危”的规则集合。第三检测流程需要反复执行每次跑出的结果还要和前一轮对比这天然要求“流程可复现”而 Skill 恰好是复现流程的最小单元。举个例子我们在做支付模块的代码审查时最关心的是越权操作。以前纯靠人眼要从一个几百行的 controller 里判断当前登录用户是否被正确传递到 service 层非常费劲。后来我把这个场景抽象成一条 Skill 规则先定位入口方法再向上追踪用户身份对象的传递路径最后检查目标方法是否有当前用户的断言。这个规则看起来简单但它把“老师傅看代码的思维路径”完整数字化了而且每次都能稳定执行。还有一点容易被忽略Skill 的运行机制允许“规则和大模型配合”。纯规则引擎能精确匹配已知模式但对没见过的缺陷形态无能为力纯大模型能理解语义但输出不可控。Skill 可以把两者结合起来规则负责缩小扫描范围大模型负责对可疑点做深度判断。这种“粗筛 精判”的组合在工程上非常实用也直接提升了检测的性价比。2.2 传统静态扫描和 AI 检测的真实差距团队里一开始也有人质疑说我们已经有 SonarQube、CodeQL 这类静态扫描工具了为什么还要再上 Skill 检测我的回答是它们的定位完全不同。传统静态扫描更擅长处理确定性问题比如明显的空指针、未使用的变量、简单的安全函数误用这些基于语法树和已知规则就能准确识别。但一旦遇到需要理解业务语义才能判断的缺陷比如“这个接口是不是应该限制为管理员可访问”“这笔退款操作是不是应该校验金额上限”传统工具的准确率会断崖式下降。我用一个具体的对比来说明。SonarQube 能告诉你“第 87 行调用了executeQuery可能存在 SQL 注入风险”但它很难告诉你“这个查询语句拼接了orderBy参数而orderBy来自前端请求且没有白名单校验所以这里是一个可利用的注入点”。后者需要模型理解数据流的来源和业务判断而 Skill 恰恰可以把这个“理解过程”标准化。我们做了一组对比测试在同一个内部项目里传统静态工具检出了 23 个问题其中 80% 是低风险或误报而基于 Skill 的 AI 检测检出了 41 个问题其中 15 个是人工复核确认的真实业务缺陷这 15 个里有 11 个传统工具完全没有提示。我不建议把 Skill 检测定位成“替代 SonarQube”更合理的做法是让它们互补静态工具负责快速过滤常规问题Skill 负责深入分析需要业务上下文的缺陷。两者的规则体系也可以互相借鉴比如把 SonarQube 的规则输出作为 Skill 的上下文素材让大模型在分析时参考检测结果会更稳。2.3 团队经验资产化把老师傅的想法装进文件做工程的人都知道大部分团队的技术债务不是来自“不知道最佳实践”而是来自“知道但没时间落实”。一个资深工程师清楚某个模块最容易出错的地方在哪但他不可能把每个知识点都写进文档更不可能每次 review 都亲自盯着。Skill 提供了一个很自然的解决方案把老师傅的判断逻辑拆解成规则、检查点和权重变成一个可以在团队内共享和复用的资产。我们团队做这件事时第一步不是写代码而是组织了一场“缺陷案例分析会”把过去半年的线上故障和漏检案例全部翻出来总结成 5 大类、17 条高频缺陷模式每条模式都附上“如何识别、风险等级、可参考的修复方案”。这些内容最终变成了 Skill 里的规则库而老师傅在这个过程中贡献的经验比任何一份 review 文档都更有生命力因为它可以被 Agent 自动执行而不再只是躺在 wiki 里吃灰。这件事对团队的意义非常大。以前新人上手一个模块至少要踩两三个月的坑才能具备基本的 review 能力现在有了带规则库的 Skill新人可以先把规则跑一遍再结合报告去理解代码逻辑上手速度快了很多。而且规则库本身是活的团队每次发现问题都可以往里面补充新规则形成“发现 → 沉淀 → 复用”的良性循环。3. 手把手写一个缺陷检测 Skill 的完整过程3.1 先圈定检测目标不要一口气吃成胖子刚开始写检测 Skill 的团队最容易犯的错是“想一次覆盖所有缺陷类型”。我见过有人第一天就想让 AI 同时检测越权、注入、资源泄漏、日志泄露、并发问题、状态机异常结果 Skill 输出混乱到没法看。我的建议是从最痛的那一类问题开始先把一条链路跑通再逐步扩展。拿我们自己的案例来说第一个生产级 Skill 只做一件事检测接口层是否存在“越权访问”风险。选择这个目标是因为它在我们的业务里发生频率高、危害大、传统工具检测不了而且判断逻辑相对清晰适合作为第一个试验田。确定目标之后要写一份简单的检测范围说明包含三部分内容。第一输入是什么我们要扫描的代码路径、语言类型、是否需要拉取全量上下文。第二输出是什么一份风险报告标明文件路径、行号、风险等级、问题描述、修复建议。第三判断标准是什么哪些情况算高危、哪些算中危、哪些只是提示。这些内容不需要写得很长但一定要明确因为它是后续规则库设计的骨架。这里还要注意Skill 的设计要和团队现有的开发流程匹配。如果团队提交代码的频率很高检测 Skill 就必须能在几分钟内跑完单次变更如果团队有固定的 release 节奏则可以做全量扫描。我们在设计时就是考虑到了这一点把 Skill 拆成两个模式quick模式针对单次变更做快速检查full模式针对整个模块做深度扫描。3.2 设计 Skill 的文件结构与规则体系一个标准的检测 Skill 文件结构大致是这样的以常见的 SKILL.md 为入口business-bug-detector/ ├── SKILL.md # Skill 的入口说明含名称、描述、触发条件 ├── config.yaml # 模型参数、扫描范围、超时设置 ├── rules/ │ ├── authorization.yaml # 越权检测规则 │ ├── resource-leak.yaml # 资源泄漏检测规则 │ ├── injection.yaml # 注入类检测规则 │ └── logging.yaml # 日志泄露检测规则 ├── scripts/ │ ├── collect_context.py # 收集代码上下文 │ ├── run_scan.py # 执行规则扫描 │ └── format_report.py # 格式化输出报告 └── examples/ ├── sample_vuln.java # 缺陷样例 └── sample_report.md # 样例报告SKILL.md 是整个 Skill 的“门面”Agent 在决定是否加载这个 Skill 时会先读这个文件。所以它的描述字段要写得直白一些避免模糊表达。比如我们写的是“检测 Java/Go 代码中的业务逻辑缺陷包括越权访问、资源未释放、非法参数透传、敏感信息泄露。适用于代码审查、CI 准入检查、迭代验收等场景。”这样的描述让 Agent 在收到“帮我看看这个 pull request 有没有安全问题”这类请求时能自动匹配到这个 Skill。规则文件是核心我以越权检测规则为例说明怎么设计。先定义风险等级和权重风险类型权重规则编号说明接口未校验当前用户10AUTH-01入口方法缺少用户身份获取/校验逻辑用户身份传递断裂8AUTH-02Controller 层获取身份但 Service 层未使用越权修改他人数据10AUTH-03更新/删除操作未校验资源归属管理员接口暴露7AUTH-04管理接口未加角色限制弱身份校验逻辑5AUTH-05仅依赖前端传参判断身份每条规则要给出可操作的检测提示。比如 AUTH-01 的检测提示是“从入口方法开始追踪 request 中的用户信息token、session、用户 ID是否在方法内部被解析并用于后续业务判断如果整个方法都没有获取当前用户身份则标记为高危”。这些提示就是给大模型看的“思维模板”写得越具体检测结果越稳定。3.3 触发、扫描、输出一次真实运行的完整链路当 Skill 的文件结构搭好后Agent 的执行流程大致是收到审查请求 → 读取 SKILL.md → 按需加载规则文件 → 调用 collect_context.py 获取相关代码片段 → 结合规则逐条检查 → 输出结构化报告。我用我们的实际案例拆解一下。假设有一个支付系统的 Pull Request改动涉及OrderController里的一个退款接口。collect_context.py 会先把这个接口的完整调用链抓出来包括 Controller 方法体、Service 层实现、相关的工具类和参数对象全部生成上下文快照。然后 run_scan.py 会基于 AUTH 规则进行粗筛确定哪些位置需要模型深入分析比如它会标记“这个退款接口没有看到用户身份参数需要进一步确认”。这个时候Agent 会把规则提示和上下文一起发给大模型让模型判断是否存在越权风险。如果模型返回“该接口通过RequestParam(userId)接收用户标识但未校验该标识与当前登录用户是否一致存在越权风险”规则引擎就会把这条结果按 AUTH-03 处理权重 10输出为高危问题。最后 format_report.py 会生成一份干净的报告## 缺陷检测报告 项目payment-service 分支feature/refund-optimize 检测范围OrderController.java 的 refund 方法 ### 高危问题 | ID | 文件 | 行号 | 风险类型 | 问题描述 | 修复建议 | | --- | --- | --- | --- | --- | --- | | AUTH-03 | OrderController.java | 102 | 越权修改他人数据 | 退款接口使用前端传入的 userId 查询订单未校验该订单是否属于当前登录用户 | 从 Session/Token 中获取当前用户 ID与订单所属用户比对后再执行退款 |这份报告可以直接贴到 PR 的评论里也可以作为 CI 准入判断的依据。我们设定的规则是如果检测出高危问题CI 直接阻塞合并需要开发修复后重新跑一遍 Skill 才能通过。这个闭环跑起来之后团队里“带病上线”的情况少了很多因为这类越权问题在代码提交阶段就被拦住了。3.4 让 Skill 学会分场景单次变更和全量扫描的差异同一个 Skill在不同场景下需要调整策略这个细节在做的时候容易漏。针对单次变更的quick模式我们只扫描变更涉及的文件和直接相关的调用链超时控制在 3 分钟内针对全量模块的full模式则会对整个目录做逐文件扫描再按模块聚合结果超时放宽到 30 分钟。两种模式共用一套规则库只是上下文收集深度和执行范围不同。为什么一定要区分因为一次全量扫描会产生大量候选问题如果全部交给大模型分析token 消耗和耗时都会爆炸。我们的做法是先用规则脚本做快速过滤把明显的非问题排除掉只对真正可疑的点调用大模型判断。以 AUTH-01 为例脚本会扫描所有 Controller 类的入口方法如果发现某个方法完全没有涉及“用户身份”相关的操作就会被列为可疑点如果发现方法里有getCurrentUser()调用脚本直接放行不再浪费模型调用。这样一轮全量扫描下来大模型的调用量能减少 60% 以上但检测覆盖率没有明显下降。分场景设计还有个额外好处可以在不影响日常开发流程的前提下对历史代码做定期巡检。我们每两周跑一次full模式把历史模块的存量风险也逐步清理掉而不是只盯着新代码。这样做了一段时间后团队对代码质量的信心明显增强了因为不仅新代码在受控范围内存量风险也在持续下降。4. 效果怎么度量精度、召回率和误报率一个都不能少4.1 用试用集跑出关键指标Skill 开发完了不能直接上生产先得用历史数据验证效果。我们准备了一个包含 100 个代码样本的试用集其中 60 个是带真实缺陷的代码片段来自历史故障案例40 个是干净代码。然后让 Skill 逐个检测记录检出结果。这里引入三个指标来度量精确率 检出且真实缺陷数 / 检出数召回率 检出且真实缺陷数 / 真实缺陷总数误报率 误报数 / 检出数。假设我们的试用集结果是检出了 70 个问题其中 55 个是真实缺陷15 个是误报而真实缺陷总数是 60 个那么精确率 55 / 70 ≈ 78.6%召回率 55 / 60 ≈ 91.7%误报率 15 / 70 ≈ 21.4%。这个结果说明一个问题Skill 能找到大部分已知缺陷但误报率偏高会在实际使用中消耗开发者的信任度。针对误报率偏高的问题需要调整规则和提示。我们的做法是把误报案例整理成反例加到 Skill 的规则文件里明确标注“如果满足以下条件不算缺陷”。比如 AUTH-01 刚出来的时候会把“公开的资讯接口”误报为“未校验用户身份”于是我们在规则里加了排除条件只对涉及用户私有数据的接口启用这条规则公开接口直接跳过。加入反例后误报率明显下降第二轮的精确率到了 87% 左右。指标不要只看一轮建议做成持续度量。每次规则变更后都跑一遍试用集确认精确率和召回率没有发生退化。我们会把每次的实验结果记录在一个简单的表格里包括版本号、规则变更内容、精确率、召回率、误报率。这样后续做优化时能快速定位是哪条规则影响了效果。4.2 误报和漏报的迭代闭环检测类工具永远面临两个方向的压力误报多了开发觉得“狼来了”开始无视报告漏报多了安全隐患悄悄溜走。所以迭代闭环的核心是每次检测结果都要有反馈机制让人工复核的结论能回流到规则库里。我们在实施时给每条检测结果都加了一个“确认”按钮集成在内部工单系统里开发可以标记“已确认修复”或“误报”。这些标记会定期汇总由技术负责人逐条查看确定误报原因后再更新 Skill 规则。这个过程看起来简单但坚持下来很有价值因为它让 Skill 变成了一个越用越聪明的系统而不是一个写死之后就再也不动的静态脚本。漏报的处理要复杂一些。漏报意味着“Skill 没发现但人发现了”的真实缺陷这类缺陷是提升召回率的关键样本。我们会定期收集漏报案例分析为什么 Skill 没有识别出来是因为上下文收集不够还是规则里没有覆盖这类模式还是模型理解出现了偏差针对具体原因做改进通常这种修复比调参数更有效。我特别想提醒的一点是不要追求完美。缺陷检测 Skill 的召回率能做到 85% 到 90%就已经能在工程上发挥很大作用了剩下 10% 到 15% 的缺陷继续靠人工 review 和线上监控兜底。如果把目标定成 100%很容易在规则库里堆入大量边界条件导致规则复杂到难以维护反而影响整体效果。4.3 和人工 Code Review 形成互补而不是替代Skill 检测上线的初期我们团队内部的讨论比较激烈有人说“以后不用人工 review 了吧”。我的态度很明确Skill 是给人工 review 减负的不是替代人工 review 的。人工 review 最核心的价值在于理解业务意图比如“这个接口为什么要加这个参数”“这次改动是否符合产品预期”这些是 Skill 无法替代的。实际跑下来之后效果也确实符合预期。Skill 承担了 80% 左右的规律性重复判断比如越权、资源泄漏、日志泄露这些有明确模式的问题人工 review 集中精力看业务逻辑、设计合理性和扩展性。团队反馈普遍积极因为 review 的工作量下降了但每个人的注意力更集中在真正需要人的地方了。我觉得这种互补关系未来会越来越明显。Skill 可以做“雷达”负责大范围扫描和标记人是“指挥官”负责对雷达信号做最终判断和决策。两者协同代码质量管理的效率才会真正提升。5. Skill 用起来之后踩过的坑与排查思路5.1 上下文过大导致输出答非所问刚开始用 Skill 检测大文件时我们经常遇到一个奇怪的现象模型分析到一半突然给出一个完全不相关的结论比如“这段代码有一个拼写错误”。后来排查发现是因为请求上下文太长超过了模型的有效注意力窗口导致模型在长文本里“迷失”了重点。解决思路是对代码做切分。我们写了一个切片脚本把超过 800 行的文件按函数或方法块切分成多个分析单元每个单元单独调用模型然后再汇总结果。这个做法确实有效分析质量明显提升但要注意切片后的上下文要有必要的“粘合信息”比如类名、方法签名、当前切片在整个文件中的位置否则模型很难理解切片之间的逻辑关系。还有一个相关问题是“上下文不够”。有些缺陷必须看跨文件的调用链才能判断只给一个文件的内容根本不够。我们后来在 collect_context.py 里增加了调用链追踪功能可以顺着方法调用关系拉取关联文件的代码然后把调用链相关的部分合并成一份精简上下文。为了保证精简后的信息不丢失重点我们用了 PPLPage-Per-Line式的分段摘要先让模型对每个关联文件做一层摘要再把摘要和核心代码一起送入最终检测。5.2 模型输出格式不稳定报告没法直接当 CI 依据另一个高频问题是模型输出的报告格式不稳定。有时它输出的是 Markdown 表格有时是 JSON有时是一段散文这给 CI 解析带来了很大麻烦。我们最初是让模型“自由发挥”结果下游脚本要为三种格式分别写解析逻辑还经常解析失败。解决办法是在 Skill 里加入严格的输出约束。我们在 system prompt 和 Skill 配置中同时指定了输出为固定 JSON 结构并提供了两个示例输出让模型严格模仿格式。同时在 format_report.py 里增加了格式校验如果输出不符合预期就触发一次重试重试时把“格式要求”再强调一遍。这样调整后输出格式的稳定性从 70% 提升到了接近 100%。这个经验让我意识到Skill 开发不能只关注“检测逻辑”本身还要关注“输出契约”。检测质量再高如果输出不能被下游消费一切都是白搭。所以在设计 Skill 时一开始就应该把输出格式当成一等公民来设计和检测规则一样重要。5.3 高频误报磨掉开发者耐心怎么办Skill 上线两周后我们的内部群出现了一些抱怨说检测报告“老报一些无关紧要的问题”比如“变量命名不够直观”“注释太少”这些都是大模型的“幻觉”产物和业务缺陷无关。团队的开发人员开始对报告失去耐心有些人甚至直接不看报告就关闭 CI。这个问题的根因在于Skill 的 prompt 在强调“发现所有问题”时模型容易把普通代码风格问题也当成缺陷输出。后来我们在规则库里明确限制了检测范围只检测会导致线上故障、数据安全或性能问题的缺陷类型风格问题一律不报。同时在 Skill 的入口描述里写清楚“这是业务缺陷检测工具不是代码风格检查工具”。调整之后误报率显著下降开发者对报告的信任度也逐渐恢复。这件事给我们一个教训检测类 Skill 的定位必须极度清晰不要试图做一个“万能检查器”。宁可漏掉一些风格类小问题也要保证输出内容每一句都和业务风险相关。只有报告足够精准开发者才愿意长期依赖它。5.4 老仓库历史债务太多报告太脏不想看当我们把全量扫描模式用到老仓库时问题更大。一个维护了三年的模块跑完 Skill 之后输出了一百多个问题其中大部分是积压许久的历史债务。开发者看到这么长的报告第一反应是“这没法搞”根本不知道从哪里下手。应对策略是把报告按“新增问题”和“存量问题”分组。CI 上只展示本次新增的问题阻塞新增高危项存量问题单独生成一份“技术债务清单”由技术负责人排期处理不打到日常开发流程里。这样既维持了“新代码不放水”的底线又不会让团队被历史债务压垮。实际操作中“新增问题”的判断可以通过对比上一次检测的基线来实现。我们在每次全量扫描后会把问题指纹文件路径 行号 规则编号存成基线文件下一次运行时对比基线新增的才进入反馈流程。这个机制很实用推荐给同样有老仓库治理需求的团队。5.5 Skill 运行耗时过长CI 卡到被投诉还有个问题常被忽略Skill 的检测耗时。我们的full模式跑一个大模块曾经需要 40 分钟这在 CI 里完全不可接受。后来做了两个改动耗时就降到了 8 分钟左右。第一增加规则预处理先用轻量级脚本把明显不存在风险的大文件排除掉第二把大模型调用改成并发执行对多个可疑点并行分析。并发要注意控制节奏不然会对模型 API 的速率限制造成冲击。我们可以通过限制最大并发数比如同时 5 个请求来平衡速度和稳定性。另外把耗时的结果做缓存也可以提速同一个文件在内容没有变化的情况下直接复用上一次的分析结果避免重复计算。我们团队现在把 Skill 驱动的缺陷检测当成一项常态化基础设施来维护不再是一次性的“AI 尝鲜”项目。每周都会花一到两个小时更新规则库、复盘检测结果、查看误报反馈。我个人最大的体会是Skill 真正改变的不是工具链而是研发的心智模式以前做质量靠“人海战术”现在靠“策略设计 自动化执行”。最后分享一个小技巧如果你想在团队里推这件事别急着追求完美覆盖先挑一个让所有人头疼的缺陷类型比如越权、重复支付、超卖做出一个能真实拦截问题的 Skill把“从发现到修复”的完整闭环跑通。只要有一次“Skill 帮我们拦住了一个线上事故”的经历团队推广的阻力就会小很多。后面再扩展其他规则就只是时间和耐心的问题了。
