代码审查器Skill：零令牌消耗的自动化代码质量扫描，把 Code Review 前置到提交之前
核心结论速览：
- 它是什么：一款名为 code-reviewer（中文名「代码审查器」）的 AI 技能，用正则表达式模式匹配的方式扫描源码，自动找出反模式、命名问题、安全风险和最佳实践违规。
- 最大亮点：零令牌消耗。整个扫描由本地 Python 脚本完成，不把代码喂给大模型分析，因此不产生任何 LLM 令牌费用，也不会把源码上传到外部模型。
- 三种模式开箱即用：全量扫描（scan）、命名约定检查（naming）、安全聚焦扫描（security），一条命令切换。
- 输出结构化 JSON：包含问题列表（issues）、按严重性统计与 A–F 质量评分（summary）、可执行修复建议（suggestions），方便人读也方便接入流水线。
- 适合谁用：想在提交代码前做一轮"低成本、高频次"体检的开发者、需要统一团队编码规范的技术负责人、以及希望快速摸底存量项目安全风险的项目维护者。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
技能名称信息
| 项目 | 内容 |
|---|---|
| 中文名 | 代码审查器Skill |
| 英文名 | code-reviewer |
| 技能ID | 12863 |
| 核心定位 | 基于模式分析的自动化代码质量审查 |
它解决什么问题？
日常开发中，代码审查通常卡在两个地方：一是人工 Review 成本高、周期长，同事没空看、看了也容易漏；二是用大模型做代码分析虽然聪明，但每次都要把代码片段粘贴进对话框，既消耗令牌，又存在源码外泄顾虑，还不适合每天高频跑。
代码审查器Skill 走的是另一条路：把"能靠规则判断的事情"交给本地脚本。它内置 review_rules.json 规则库，按类别组织检测规则，脚本用正则模式对源文件逐条比对，直接产出结构化报告。整个过程不调用大模型，因此零令牌消耗，可以随时跑、反复跑、放进任何自动化流程里跑。
一键安装的思路与步骤：
- 确认前置条件：需要本机具备 Python 运行环境，并确保所用 AI 技能框架已支持
.agent/skills/目录结构（具体支持情况以官方说明为准）。 - 获取技能：在技能市场或技能仓库中搜索中文名「代码审查器」或英文名
code-reviewer，也可以用技能ID 12863 精确定位。具体的下载入口、是否需要授权或付费，以官方说明为准。 - 确认安装路径：技能应落在项目根目录下的
.agent/skills/code-reviewer/路径中，该目录内需包含脚本scripts/reviewer.py与规则文件review_rules.json。如果下载后目录名不同，请手动改为code-reviewer，否则下文命令中的路径需要同步调整。 - 验证是否生效：在项目根目录执行一次全量扫描：
python .agent/skills/code-reviewer/scripts/reviewer.py --path "src/" --action scan
如果终端返回一段 JSON（含 issues、summary、suggestions 三个字段），说明技能已正常工作；若提示找不到文件，请检查 Python 版本、当前工作目录以及 .agent/skills/code-reviewer/scripts/reviewer.py 是否真实存在。
该技能的主要功能和特点
- 零令牌成本扫描：扫描逻辑完全由本地脚本执行，不消耗 LLM 令牌，源码不出本机，成本与数据安全两头都占优。
- 三种审查动作：
scan：全量扫描，覆盖面最广，一次性给出综合体检报告；naming：命名约定检查，聚焦变量、函数、类等命名是否规范统一；security：安全聚焦扫描，只关注安全风险类规则，适合上线前专项排查。
- 规则驱动、可扩展：所有检测规则集中在
review_rules.json中并按类别组织，团队可以按自己的编码规范增删规则，把"公司规范"沉淀成可执行的检查项。 - 结构化 JSON 输出：
issues逐条记录文件、行号、严重性、命中规则与描述；summary按严重性计数并给出 A–F 的整体质量评分；suggestions给出可落地的修复建议。机器可解析、人也能直接读。 - 定位明确的反模式检测：专治那些"人一眼能看出、但机器批量找起来更省事"的问题——重复代码套路、可疑写法、命名混乱、潜在安全风险与最佳实践偏离。
- 和普通工具比强在哪：相较于把代码丢给大模型对话分析，它更快、更便宜、更稳定（同一份代码每次结果一致），也更容易接入自动化；相较于重量级静态分析平台，它几乎零配置、单文件脚本即可运行，适合"随手跑一下"的轻量场景。
如何使用该技能？
步骤 1：确定扫描范围
用 --path 指定要检查的目录。建议先从小范围开始，例如单个模块：
python .agent/skills/code-reviewer/scripts/reviewer.py --path "src/user/" --action scan
步骤 2：选择审查动作
- 日常提交前自检、想全面了解质量状况 → 用
scan； - 团队刚统一命名规范，想批量找出不合规命名 → 用
naming； - 上线前安全专项排查、或接手他人项目想快速看风险面 → 用
security。
python .agent/skills/code-reviewer/scripts/reviewer.py --path "src/" --action naming
python .agent/skills/code-reviewer/scripts/reviewer.py --path "src/" --action security
步骤 3：阅读 JSON 报告
输出结构可理解为三段式（以下为字段示意，具体内容取决于实际扫描结果）：
{
"issues": [
{
"file": "src/xxx.py",
"line": 42,
"severity": "high",
"rule": "规则标识",
"description": "问题描述"
}
],
"summary": {
"按严重性计数": "高/中/低各多少条",
"quality_score": "A-F 等级"
},
"suggestions": ["可执行的修复建议"]
}
阅读顺序建议：先看 summary 的整体评分和严重性分布判断"要不要马上处理"，再按严重性从高到低逐条看 issues，最后对照 suggestions 动手改。
步骤 4：修复并复跑验证
改完代码后重跑同一条命令，对比 summary 中的严重性计数是否下降、评分是否提升。这种"扫描—修复—复跑"的短循环，是把它用出价值的关键。
步骤 5：固化到日常流程
在提交代码前、合并请求前、或每日构建时手动/自动执行一次扫描；如果团队有自己的脚本编排方式，把上面这条命令串进去即可（与具体 CI 系统的集成方式以官方说明为准）。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 代码审查器Skill（code-reviewer） | 规则驱动的轻量代码质量扫描 | 反模式、命名、安全、最佳实践检测；A–F 评分；修复建议 | 低：具备 Python 环境，放入 .agent/skills/ 目录即可运行一条命令 |
提交前自检、命名规范落地、快速安全摸底 | 优势：零令牌成本、源码不出本机、结果稳定、规则可自定义；不足：基于模式匹配，不理解语义，复杂逻辑问题需人工或语义级工具补位 |
| ESLint | 前端 JavaScript/TypeScript 代码规范检查 | 语法级规则检查、自动修复、插件生态 | 中：需 Node 环境、配置文件与插件选型 | 前端项目规范强约束、编辑器实时提示 | 优势：生态成熟、可自动修复、编辑器深度集成；不足：语言绑定明显，跨语言项目需另配工具 |
| SonarQube | 企业级代码质量与安全管理平台 | 质量门禁、技术债量化、漏洞与异味检测、可视化面板 | 高：需部署服务端、配置扫描器与项目接入 | 中大型团队质量度量、持续集成门禁 | 优势：度量体系完整、报告专业、可做长期趋势；不足：部署与维护成本高，轻量自检场景偏重 |
| Semgrep | 语义化静态分析工具 | 基于规则的跨语言模式匹配、安全规则库 | 中：需安装命令行工具并编写/引入规则 | 安全审计、自定义规则扫描 | 优势：跨语言、规则表达力强；不足：规则编写有学习曲线，无内置评分体系 |
| 直接让大模型对话式审查 | 通用 AI 辅助审查 | 语义理解强、能解释复杂逻辑 | 低：粘贴代码即可 | 疑难代码解读、局部深度分析 | 优势：理解语义、能给出解释；不足：消耗令牌、有成本、结果不稳定、大文件需切片 |
怎么选：日常高频、要省钱、要稳定的规范性检查，优先用代码审查器Skill；需要语法级自动修复选 ESLint；需要团队级质量门禁选 SonarQube；需要语义级深度解读再把大模型审查作为补充。它们不是替代关系，而是分层关系。
该技能的典型应用场景与实际体验情况
场景一：后端开发者的提交前自检
角色：独立开发者或小团队后端。痛点：没有专职 Reviewer，代码写完就直接提交，问题积累到线上才暴露。使用方式：提交前跑一次 scan，把高危问题清掉再 push。
实际体验：上手几乎零成本，会敲命令行就能用，单次扫描秒级返回，不打断编码节奏。注意点是首次在成熟项目上跑，issues 可能一次性涌出很多，建议先按严重性过滤，只处理高优先级项。
场景二：技术负责人推动命名规范落地
角色：团队 Tech Lead。痛点：规范写在文档里没人看，Review 时靠人肉记忆，标准不统一。使用方式：用 naming 动作对全仓扫描，把结果作为 Code Review 的客观依据；把团队特有命名约定补充进 review_rules.json。
实际体验：把"我觉得你命名不规范"变成"规则命中了这 30 处"，沟通成本明显下降。注意点是规则需要持续调优——规则太松会漏，太严会误报，建议每次补充规则后抽验一轮。
场景三：上线前的安全专项排查
角色：项目维护者。痛点：安全检查往往是上线前临时抱佛脚，人工翻代码效率低。使用方式：上线前用 security 动作聚焦扫描，只关心安全类规则命中。
实际体验：比全量 scan 更聚焦，报告噪声小、可读性好。需要清醒认识的是：它是模式匹配，不是渗透测试，能发现"常见写法风险"，但发现不了业务逻辑漏洞，安全结论仍需专业工具与人工复核。
场景四：接手存量项目的快速摸底
角色：新加入项目的工程师。痛点：面对几万行陌生代码，不知道从哪看起。使用方式：对整个 src/ 跑一遍 scan，通过 summary 里的 A–F 评分和严重性分布，快速判断项目质量水位与风险集中区。
实际体验：这是它被低估的用法——评分不追求绝对精确，但作为"项目健康度初筛"非常有效，能指出先看哪些文件。注意点是评分会因为规则集不同而变化，跨项目横向对比时应保证规则集一致。
该技能能为用户带来的价值
效率提升：一次全量扫描几秒钟出结果，替代人工逐文件翻阅。原本需要半小时起步的规范性检查，压缩到一条命令的时间；重复执行没有边际成本，"扫描—修复—复跑"可以无限次循环。
成本降低：零令牌消耗是它最实在的价值。用大模型审查代码，每次都要付费（或消耗额度），且代码越长成本越高；而代码审查器Skill 的每一次扫描都是本地计算，扫描一万次和一次的令牌成本相同。
安全合规：源码始终停留在本地磁盘，不经过任何外部模型服务，对金融、政企、涉及商业机密的项目尤为友好。
门槛降低：不需要写规则引擎、不需要搭服务端、不需要学复杂的查询语言，只要一条 python ... --action scan，新人第一天就能用。
长期价值：review_rules.json 让团队规范从"文档"变成"可执行资产"。随着规则库沉淀，代码审查从"依赖某个资深 Reviewer 的经验"转变为"依赖团队共识的规则集"，人员流动不再导致审查质量断崖式下滑。
常见问题 FAQ
Q1：这个技能怎么安装？需要什么前置条件？
在技能市场/仓库搜索「代码审查器」或 code-reviewer，或用技能ID 12863 定位，下载后放到项目的 .agent/skills/code-reviewer/ 目录，确认其中有 scripts/reviewer.py 和 review_rules.json。前置条件主要是 Python 运行环境。下载入口与授权方式以官方说明为准。装好后跑一次 --action scan，返回 JSON 即表示生效。
Q2：扫描需要消耗大模型令牌吗？要额外付费吗？
不需要。它的扫描由本地 Python 脚本完成，基于正则模式匹配，不调用大模型，因此零令牌消耗。至于技能本身的获取是否收费，以官方说明为准。
Q3：扫描没报问题，是不是说明代码没问题？
不是。它做的是模式匹配，能高效抓住"常见反模式、命名问题、安全风险与最佳实践偏离"，但无法理解业务语义，逻辑错误、架构设计和业务漏洞并不在其能力范围内。请把它当作高频低成本的体检工具，而不是最终的质量结论；关键模块仍需人工 Review 与语义级工具配合。
Q4：它支持哪些编程语言和文件类型？
扫描依靠正则规则，因此具体覆盖面取决于 review_rules.json 中配置的规则类别和匹配模式，不同规则集的覆盖范围可能不同。建议先小范围试跑，确认目标语言的命中情况，再按需补充规则。具体默认规则清单以官方说明与实际文件内容为准。
Q5：和 ESLint、SonarQube 这些工具比，该怎么选？
看你的诉求：要零成本、零配置、随手跑的跨语言规范性检查，选代码审查器Skill；要前端语法级自动修复，选 ESLint；要企业级质量门禁与长期度量看板，选 SonarQube。三者可以并存——用代码审查器Skill 做提交前的快速自检，用专业平台做周期性深度治理，成本与覆盖度最平衡。