那原本是一次再普通不过的对话我让AI助手审查一个项目的安全性它认真读完代码之后给出了整体质量良好未发现明显高危问题建议补充输入校验与日志记录的结论。作为在安全审计这行摸爬滚打多年的人我一眼就看出了问题——它根本没有在审计它只是在通读代码并发表读后感。它不知道安全审计要先从依赖清单和配置信息开始不知道硬编码密钥和CORS配置意味着什么更不会在SQL注入、越权、反序列化这些方向上有条理地追查。后来我把自己脑子里的那套审计SOP做成了security-audit-skill一个让AI编程助手Codex、OpenCode这类Agent能够真正按审计流程工作的技能包。做完之后效果变化非常明显AI开始主动声明审计范围、按阶段执行检查、给每个发现标注风险等级并且附上代码行号作为证据链条。这篇文章我就把这个技能包从设计、实现、实测到调优的完整过程拆开讲清楚。适合想给AI Agent扩展专业能力的开发者、想用AI做代码安全初筛的工程团队以及本身做安全审计、正在研究LLM能帮上什么忙的安全工程师参考。1. 安全审计为什么是最适合做成Skill的场景1.1 一次复读式审计现场模型不是不懂安全是没在审先还原那次对话。我问Agent这个项目有没有安全问题它回答很客气从代码结构上看项目职责划分清晰整体设计较好。但建议关注输入验证、依赖更新和日志记录。我再追问具体在哪一行它翻了一遍才指出config.js第47行附近用了字符串拼接HTML。我继续问这是XSS吗它说是的建议做输出编码。整个过程里我不问它不说我问一句它挤一点。这就像你去医院做体检医生看完你的全部病历后说整体情况不错建议多锻炼身体注意饮食但你不主动问他就不告诉你血压已经偏高、血脂有异常指标。问题不在模型能力而在流程缺失。专业安全审计人员拿到一个项目时脑子里有一套固定的检查序列先看依赖和供应链再看部署配置和环境变量然后才是代码层面的漏洞模式最后还要专门检查认证授权和业务逻辑。每一个环节都有明确检查项、判定条件和风险定级标准。AI没有这套SOP它就只能凭语感回答安全相关问题而不是执行一次安全审计。1.2 Skill、Plugin、Agent先把三个概念摆清楚这几个词最近讨论度很高但很多人确实没分清楚。我的理解很简单Agent是干活的主体Plugin是主体能调用的工具Skill是主体做某类任务时遵循的专业工作方法。三者不是同一个维度的东西不能互相替代。用新来的实习生做类比Agent就是实习生本人Plugin是他手里的电钻、水平仪、测量尺Skill则是一本施工流程手册——墙砌到什么高度要留线管、水电验收要看哪几个点位、材料进场要不要做强度抽检。没有手册实习生拿着最好的工具也可能自由发挥出错有了手册他才知道先做什么、后做什么、什么算异常、异常该怎么上报。Skill不会给Agent新增能力它给的是把事情做对的方法论。安全审计恰好是一个非常依赖SOP的领域所以用它来做第一个Skill实验性价比极高。1.3 审计方法论的结构化机会为什么选安全审计而不是别的安全审计比其他领域更适合做成Skill有三个原因。第一知识边界清晰。OWASP Top 10、CWE Top 25、密钥正则、常见错误配置项这些都是现成的公开清单可以被结构化地写进规则文件。相比帮你写一个漂亮的前端页面或者分析用户增长趋势这类开放性问题安全审计的应该查什么是可以枚举完的。第二流程高度标准化。清点资产、梳理攻击面、逐项检查、验证利用条件、汇总报告这个流程在安全行业已经成熟到了可以照抄的地步。标准流程意味着可以建模可以建模就意味着可以固化到Skill里。第三有明确的交付物。审计报告就是标准输出里面包含风险等级、问题描述、复现步骤、修复建议。这种有固定输出格式的任务恰好能让Skill的输出约束机制发挥作用。2. security-audit-skill的骨架目录、SKILL.md与规则文件2.1 一分钟看懂目录结构五个部分各有分工我设计这个Skill时参考了当前主流的Skill目录约定结构是这样的security-audit-skill/ ├── SKILL.md ├── rules/ │ ├── dependency-risk.md │ ├── config-security.md │ ├── injection-and-xss.md │ ├── auth-and-access-control.md │ ├── sensitive-data.md │ └── business-logic.md ├── references/ │ ├── owasp-top10-2021.md │ ├── cwe-top25.md │ └── secret-patterns.md ├── scripts/ │ ├── extract_dependencies.py │ └── scan_secrets.py └── examples/ ├── report-template.md └── sample-findings.jsonSKILL.md是入口文件。Agent加载技能时通常优先读取它决定自己该以什么身份、按什么流程工作。rules/目录是整个技能的核心按漏洞类别拆成独立规则文件每个文件解决一类问题。references/目录是参考资料供模型在犹豫这个模式到底算不算漏洞时查阅。scripts/目录放辅助脚本比如自动提取依赖清单、基于正则批量扫密钥的工具。examples/目录放报告模板和样例发现作用是约束最终输出风格。我在实测中发现一个规律rules/目录里的文件数量控制在6到8个每个文件10到20条规则时模型执行得最稳定。文件太多会让模型在长上下文中丢失前面的规则约束太少则覆盖不全。六个文件分别对应依赖、配置、注入/XSS、认证会话、敏感数据、业务逻辑基本覆盖了日常Web项目能被静态审计发现的大部分问题。2.2 SKILL.md写在最前面的三件事角色、范围、流程SKILL.md是写给人看还是写给模型看的我一开始把它当成技术文档写后来发现效果很差。它本质上是给模型看的岗前培训手册所以内容要直接、明确、可执行。我最终使用的SKILL.md开头是这样# Security Audit Skill 你是一名具有15年经验的Web应用安全审计工程师。你的任务是对给定的代码库执行系统性安全审计最终产出一份结构化审计报告。 ## 执行前 1. 先读取 rules/ 目录下全部规则文件。 2. 主动向用户确认审计范围默认纳入 src/, config/, Dockerfile, docker-compose.yml排除 node_modules/, dist/, build/, test/fixtures/, docs/。 3. 如果用户给出的审计目标不是代码目录明确拒绝并说明原因。 ## 执行中 按以下阶段顺序执行每个阶段结束时先输出该阶段的发现摘要再进入下一阶段 - 阶段一依赖与供应链风险排查 - 阶段二配置与环境信息审计 - 阶段三代码层漏洞模式扫描 - 阶段四认证授权与业务逻辑检查 - 阶段五汇总并输出格式化报告 ## 执行后 严格按 examples/report-template.md 的格式输出报告。这里的每一条都不是废话。先读取全部规则文件是为了让模型在动手前建立规则基线避免巡到一半才发现还有规则没加载。主动确认审计范围特别重要不确认范围的话模型会把node_modules、dist这类第三方目录也拿进来扫瞬间产生上千条噪音。每个阶段结束先输出摘要则是把长任务切成短任务缓解模型在后半段的规则遗忘问题。最后用15年经验的审计工程师做身份设定是为了让模型进入审计负责人的角色状态——它输出时的判断尺度和语气都会更克制、更专业。2.3 规则文件每个漏洞类别都是一个触发-确认-定级决策流程如果说什么决定了Skill的真实水平那一定是规则文件的质量。普通安全文档写的是SQL注入是严重漏洞规则文件写的却是当用户输入拼接进入数据库执行接口时你该怎么一步步确认、如何定级。前者是知识点后者是可执行决策流程。以injection-and-xss.md中的SQL注入规则为例## SQL注入JavaScript/SQL - 触发模式 - SQL字符串模板中包含 ${...} 或字符串 拼接的用户可控变量 - 拼接结果进入 db.query / sequelize.query / knex.raw / mysql.query 等执行接口 - 确认步骤 1. 向上追踪变量来源确认是否来自 req.query / req.body / headers / URL 参数 2. 检查执行接口是否使用参数化查询、预编译语句或 ORM 绑定参数 3. 已参数化的标注【安全】附上参数绑定代码作为证据 4. 未参数化的继续检查数据库驱动是否开启 multipleStatements - 定级 - 用户可控 拼接执行 multipleStatementstrue → 严重 - 用户可控 拼接执行 → 高危 - 用户可控 拼接进入 ORDER BY / LIMIT 类语句 → 中危 - 仅出现在测试代码或示例代码 → 低危看到区别了吗模型拿到这条规则后判断路径是确定的找到拼接模式追数据来源确认执行接口再按条件定级。没有规则时它看到字符串拼接就报SQL注入看到参数化查询就报安全完全凭感觉。规则的本质是替模型预先搭好了从代码特征到风险结论的推理桥梁。3. 按五个阶段执行审计AI从通读代码变成按流程办事3.1 第一阶段依赖与供应链风险让AI先看弹药库安全圈有句话叫你依赖了什么就暴露了什么。供应链风险是近几年大量真实攻击事件的入口所以审计的第一步不是翻业务代码而是盘点依赖清单。Skill会引导AI先找项目里的依赖声明文件——package.json、requirements.txt、go.mod、Gemfile、Pipfile等然后做两件事。第一件事让AI调用外部漏洞扫描工具比如osv-scanner、npm audit、pip-audit跑一遍依赖清单这一步必须用外部工具因为模型的训练数据无法覆盖最新披露的CVE。第二件事AI负责做语义分析——被扫出来的这个漏洞在当前代码库里是否真的被使用了影响哪个调用链这才是LLM在供应链审计里最有价值的部分它不只是报一串CVE编号而是帮团队判断哪些漏洞值得立刻投入人力修复。这里还有一个容易漏掉的检查点依赖版本基线一致性。开发环境、生产环境、Docker镜像里声明的同一个依赖版本是否一致锁文件与直接依赖声明是否对得上。DIFF这些信息对人力审计来说很枯燥但AI做起来很快而且经常能发现本地正常、生产环境被锁定在旧版本这类隐蔽问题。3.2 第二阶段配置与密钥最容易被漏掉但风险最高的一层很多开发团队会把大量精力放在业务代码审计上却对配置文件视而不见。但实际上真实安全事件中硬编码密钥泄露、云厂商凭证外泄、默认配置被利用的比例非常高。第二阶段专门盯着环境与配置检查清单包括硬编码密钥与Token扫.env、settings、application.yml、config目录下所有文件用正则匹配常见密钥格式AWS密钥、GitHub Token、MySQL密码、私钥块、JWT Secret等。调试开关搜索debugtrue、show_stacktrace、verboseLogging这类配置。错误信息泄露检查全局异常处理是否把堆栈信息和数据库报错直接返回给客户端。CORS配置重点看Access-Control-Allow-Origin是否允许通配符且Access-Control-Allow-Credentials同时为true这个组合等于允许任意网站带着用户Cookie发请求。Cookie与通信安全检查Cookie是否缺少Secure、HttpOnly、SameSite属性TLS配置版本HSTS头是否开启。容器与部署配置Dockerfile是否以root用户运行、是否把敏感端口暴露给公网、Kubernetes容器是否启用privileged、是否挂载了宿主机敏感目录。配置类问题的特点是发现速度快、定级容易、修复简单但对AI来说反而容易漏——因为模型往往盯着核心代码文件看把.env和Dockerfile当作不重要的边角料。Skill的作用就是强制把配置目录列入审计范围让AI不允许跳过。3.3 第三阶段代码漏洞模式让AI按规则反向检索而不是自由发挥第三阶段是最核心也最容易水过去的环节。如果只给模型一句检查项目里的漏洞它一定会按自己习惯把所有源码读一遍然后挑印象深刻的几个点说事。正确的做法是反向检索针对rules/目录里的每一条规则先在代码库中定位候选位置再逐个执行确认步骤。以常见的Web漏洞为例代码层重点覆盖这些模式注入类SQL注入、命令注入、模板注入、LDAP注入。文件与路径类路径穿越、任意文件读取、不安全的文件上传与解析。服务端漏洞SSRF、不安全的反序列化、XML外部实体注入。前端安全DOM型XSS、反射型XSS、存储型XSS、危险的内联事件。加密与随机数弱随机数、硬编码加密密钥、弱哈希算法。实操时我有一个建议项目代码量大时让AI把代码库按目录切片每个切片的体量控制在模型能稳定处理的范围内逐片跑完规则集最后在汇总阶段按文件路径去重合并。切片过大模型读到后半段已经把前半段的规则忘得差不多了切片过小重复发现增多。我的经验是单个切片控制在5000行以内报告合并时以文件路径漏洞类型作为去重键。3.4 第四阶段认证授权与业务逻辑AI的短板要标记待人工确认这一阶段是AI审计能力分水岭。认证和授权的检查相对好做因为存在固定的代码模式。Skill会引导AI完成下面这些动作枚举认证相关端点登录、注册、刷新令牌、重置密码、验证码发送接口检查是否有速率限制密码重置Token是否可预测会话令牌是否被放进localStorage存在被XSS直接读取的风险。检查授权层是否覆盖全部受保护路由找到鉴权中间件、装饰器、过滤器的注册位置再对照路由表找出哪些接口没有经过鉴权。搜索水平越权模式比如一个查询订单接口直接从URL参数拿orderId查不到任何这个订单是否属于当前用户的归属校验。水平越权这类问题AI能发现代码模式存在风险但很难判断这究竟是漏洞还是业务刻意设计。比如管理员后台的查看任意用户详情功能代码层面看起来就是典型的越权查询但可能它本来就设计为仅供内部系统调用。因此我在Skill里强制要求凡是涉及业务逻辑判断的发现必须标记需人工确认不允许AI直接定高危。我说这是AI的短板并不等同于它没用。它能很快把所有接口和权限关系列成一张对照表把候选问题筛出来把哪些地方需要人来决策标出来这就已经帮工程师省了一大半时间。3.5 第五阶段报告汇总与风险定级前面四个阶段跑完后AI需要把发现汇总成一份可读、可追踪、可复核的审计报告。我用的报告模板长这样# 安全审计报告 ## 1. 审计范围与方法 - 纳入审计的目录/文件 - 排除目录及原因 - 使用的规则集版本与扫描工具 ## 2. 风险概览 | 风险等级 | 数量 | 关键发现摘要 | | 严重 | ... | ... | | 高危 | ... | ... | | 中危 | ... | ... | | 低危 | ... | ... | ## 3. 详细发现 ### 3.1 [严重] SQL注入 — src/routes/user.js:87 - 风险描述 - 证据链代码行摘录 触发路径 攻击场景 - 复现步骤 - 修复建议 ## 4. 待确认问题需人工复核 - 低置信度发现汇总 ## 5. 自动化扫描原始输出附报告模板不是锦上添花它是输出约束机制的核心。一旦模型知道最终报告必须包含证据链、复现步骤、修复建议它在执行前面的审计时就会更克制地收集证据而不是天马行空地乱报。另外风险概览的表格还有一个作用它把已确认问题和待确认问题分开避免所有发现混在一起让阅读者对项目的真实安全水位产生误判。4. 接入Codex/OpenCode跑实测一个Node.js项目审出什么4.1 Skill安装与激活全局目录和项目目录两条路把技能接入Agent主要有两种方式。第一种是把Skill放在Agent的全局技能目录。不同的平台有各自的约定路径比如Claude Code系约定在~/.claude/skills/Codex类平台通常配置在~/.codex下的prompts或skills目录OpenCode及其衍生版本一般支持全局skills目录或项目下的.opencode/skills/。具体目录名以你实际使用平台的文档为准但思路是共通的把整个security-audit-skill目录放进技能加载路径然后在对话里直接说使用security-audit-skill审计当前项目激活它。第二种方式是把Skill目录直接放到项目仓库的约定目录下让Agent在启动扫描项目上下文时自动发现。这种方式的好处是技能跟着项目走团队成员克隆代码库后不需要额外配置就能复用。需要注意的是放进仓库的技能目录不要混入无关的大文件保持技能包体积小、结构清晰Agent加载时才不会浪费上下文空间。还有一个通用建议如果平台支持自动读取技能目录SKILL.md主文件尽量控制在5KB以内详细内容放进rules/和references/子文件。因为Agent上下文资源有限主文件太长容易被截断而子文件是按需读取的更节省空间。4.2 实测项目预埋的六个问题为了验证效果可靠性我在一个约15个文件的ExpressMySQL演示项目里预埋了六个问题。这六个问题覆盖了从供应链到业务逻辑的多个层次问题Apackage.json依赖lodash4.17.14存在已知原型污染漏洞。问题B.env文件包含明文MySQL数据库密码。问题C登录接口通过字符串拼接构造SQL查询。问题DGET /api/order/:id返回订单详情时不校验订单归属。问题ECORS中间件配置为origin: *且credentials: true。问题F前端代码把会话令牌放进URL参数中传递服务器access日志可能泄露会话身份。我运行审计时Skill引导AI输出的过程比预想中顺畅。AI先输出了范围声明明确纳入src、config、Dockerfile排除node_modules和test目录然后按阶段推进。第一阶段里它调用依赖扫描发现lodash版本问题并附带说明这个漏洞的实际利用条件第二阶段通过正则命中了.env里的明文密码和CORS配置第三阶段在src/routes/user.js准确定位到了SQL拼接代码并给出了证据链。整个过程用时几分钟而同样的项目让我人工审计至少需要两三个小时。4.3 实测结果AI审出五个半漏了一个跨层问题审计结果整理如下预埋问题Skill是否发现定级备注依赖lodash过旧发现高危工具扫描语义判断.env明文密码发现严重正则规则双重命中SQL注入发现高危规则路径匹配完整订单越权发现标记待确认中危无法确认业务归属CORS通配credentials发现中危配置规则命中会话令牌放URL漏报—需要跨前端、会话、日志联判可以看到六个问题里它有把握地发现了五个剩下一个标记待确认还有一个完全漏报。漏报的会话令牌问题很有代表性它跨了前端代码、会话管理和服务器访问日志三层单看任何一层都不构成漏洞组合起来才是风险。这种需要全局视角的关联推理正是当前LLM的薄弱环节。同时这次审计还产生了两个低质量误报测试目录里的一个伪装secret字符串被当成了硬编码密钥一个Base64编码的示例数据被当成可疑Token。这两个误报在十几条发现里不算多但如果项目规模翻十倍、代码文件翻几十倍这种噪音会被急剧放大所以后面我把误报治理放到了优先级最高的位置。5. 调优实录把误报从满天飞压到可接受5.1 误报的三个主要来源规则漂移、锚定效应、目录不分误报不会凭空消失必须先搞清楚它从哪里来。我在调优过程中总结出三个最常见来源。第一个是长上下文导致的规则漂移。模型在连续巡查几百个文件后越到后面越容易忘记规则里必须满足什么条件才算问题的约束只凭代码形态上的相似就开报。第二个是锚定效应。如果前几个发现集中在某一类问题上模型后续会倾向于把相似模式的文件全都翻出来报一遍形成扎堆误报。第三个是目录不区分。测试代码、示例代码、fixtures目录里的故意写得不安全的代码经常被当成生产漏洞报出来——测试目录里常常会有为了测试而构造的漏洞代码模型识别不了这个语境全都当成真雷报了上来。这三个来源其实都不是模型能力问题而是Skill编写时的流程缺陷。规则没有强调每个阶段都在内存中加载完整约束没有对目录语义做区分也没有给模型一个把可疑但不确定的问题放到一边的出口。5.2 在SKILL.md里加两道闸门范围声明与置信度分级解决误报我用了两个改动效果立竿见影。第一道闸门是强制范围声明。在SKILL.md中增加一段指令要求AI在正式审计前必须输出本次审计的范围声明包括纳入的目录和文件、排除的目录和文件、排除理由。如果用户没指定默认执行## 范围声明强制 正式开始审计前你必须输出本次审计的【范围声明】包含 - 纳入目录/文件 - 排除目录/文件 - 排除理由测试代码、第三方依赖、生成文件等 如用户未指定默认按上述清单执行。这招最大的作用不是处理技术问题而是逼模型在开始就建立目录边界意识。它一旦明确知道test和fixtures被排除后面就不会浪费上下文在测试代码里找漏洞。第二道闸门是置信度分级。要求每个发现标注高、中、低三档置信度并且所有低置信度问题自动归入报告第四节的待确认问题不计入风险概览的统计## 置信度标注 每个发现必须标注置信度高/中/低 - 高可直接定位到具体代码行且有明确的攻击路径 - 中代码模式与已知漏洞类型一致但缺少部分攻击前提 - 低存在可疑模式无法确认是否构成实际风险 低置信度发现一律归入报告第4节【待确认问题】不计入风险统计。加入这两段之后报告的已确认问题数量明显变少但每一条的含金量变高了。原因很简单低置信度问题有了一个合法的去处模型不必再拿一堆模棱两可的发现去填高危清单。5.3 证据链门槛没有复现路径的发现不许判高危如果说前面两招是减量证据链门槛就是提质。我在规则里加了一条硬性规定## 高危定级门槛 凡定级为高危或严重的问题必须同时满足 1. 提供问题代码行摘录文件行号代码内容 2. 说明攻击者从哪个入口能够触达问题点 3. 说明利用后产生的实际影响 任一项缺失只能定级为中危或低危。这条约束的本质是用输出门槛倒逼推理质量。当模型知道拿不出完整攻击链路就不能报高危时它在追踪数据流时会更仔细不会看到一个eval就条件反射式地定级高危。实测下来这条规则还顺带解决了问题描述过于宽泛的毛病——AI写出来的发现从存在注入风险变成了用户输入从/login接口进入经username字段拼接SQL后最终在db.query中执行可导致攻击者绕过登录。6. 从个人技能到团队基建把Skill嵌进日常研发流程6.1 接入CI的节奏与边界Skill在本地验证稳定后很自然会被想到接入CI。但我建议先想清楚节奏和边界不要让LLM审计变成每次push都跑的重刑任务。我推荐的节奏是每日定时对主干分支全量跑一次审计MR阶段只针对增量变更做轻量审查大版本发布前做一次完整全量审计。这样既能及时发现问题又不会因为每次push都消耗大量token而让团队崩溃。同时要明确边界CI里没有运行环境无法做动态验证Skill的产出本质上属于静态审计语义分析的结合不等同于渗透测试。它更适合作为安全初筛辅助工具帮助团队在让安全工程师介入前就把明显问题清掉。另外LLM输出本身带有随机性同一批代码跑两次可能结果略有差异所以CI产物必须加上LLM辅助审计结果需人工复核的标签不能把它当作唯一的安全放行依据。6.2 与传统SAST的分工各自干擅长的事很多人会问有了基于LLM的Skill审计传统的Semgrep、CodeQL这类静态分析工具还需要吗我的答案是两者是互补关系不是替代关系。维度传统SASTSemgrep/CodeQL等LLMSkill规则确定性高同一条规则每次结果一致低模型输出有波动语义理解弱依赖人工配置数据流规则强能理解大致的业务意图输出可读性差以堆栈与规则名为主好接近人工编写的报告误报控制可控但规则维护成本高需要主动调优如第5节覆盖范围能扫全库海量文件受上下文限制适合重点路径实际落地时我建议让传统SAST先拉出全量候选问题再用Skill对高价值路径做深度审计。换句话说SAST负责广覆盖Skill负责深理解。两条生产线出来的结果放到一起做人工复核比任何单一方案都稳妥。6.3 把复盘经验沉淀回rules/让Skill越用越懂你的业务Skill的规则文件不是写一次就完事的它是一个可以持续演进的知识库。我在团队里推过一个很简单的机制每处理完一个真实漏洞就把发现问题的方式绕过手法修复验证方法追加到rules/目录的对应文件里。这样Skill会越来越贴合自家技术栈和业务场景。举个具体例子我们的团队经常写Excel上传导入功能早期在解析不可信Excel时踩过路径穿越的坑。于是我在文件处理规则里新增了一条文件上传解析链检查要求AI在发现multipart上传后追踪文件名是否被直接拼接到服务器路径。下次审计时这条规则就自动生效了。这种复利式积累是普通静态扫描工具不具备的。后续想扩展的话方向也很明确适配更多语言Java、Go、C#的规则文件、对接内部漏洞情报平台、把报告JSON化后自动写入缺陷管理系统。但我的建议是不要一上来就搞全套——先把最小闭环跑通把误报压到可接受的范围再一个文件一个文件地扩充规则。这个Skill在本地反复迭代了很多轮之后我最大的体会是不要把Skill当成让AI变聪明的魔法要把它当成给AI做的岗前培训。security-audit-skill真正解决的并不是模型不懂安全而是模型不知道如何按审计流程把懂的东西系统化输出。它的价值也不只停留在安全审计本身你完全可以用同样的思路给Agent做代码评审技能、做漏洞复盘技能、做架构巡检技能。底层逻辑都是一样的把老手脑子里的SOP显性化成模型可加载、可执行的规则包。最后分享一个我踩出来的教训起步时别贪全。第一版我试图一次性覆盖几十类漏洞结果模型在长上下文里直接迷失输出又长又虚。后来砍到六个核心模块、每条规则都严格走触发—确认—定级三步效果立刻稳定下来。先跑两三轮真实项目把误报率压下去再逐步扩展覆盖面——这条路比一开始就追求大而全要靠谱得多。