代码审查Skill：让每一次代码修改都自动获得专业级审查
- 核心定位：这是一个围绕「安全、性能、可维护性、可访问性」四大清单构建的代码审查技能，在代码修改后自动激活，把零散的"凭感觉 review"变成有标准、有分级、有模板的流程化审查。
- 关键机制：内置四份审查清单 + 三级问题严重性（关键 / 警告 / 建议）+ 四步审查流程（收集上下文 → 审查代码 → 分类发现 → 生成报告）。
- 输出可控：审查结论按统一报告模板生成，并归档到
docs/reviews/code-review-{session}.md，便于团队复盘与追溯。 - 使用门槛低：无需额外学习一套复杂工具链，只要在 AI 编程助手中启用该技能，正常改代码即可触发。
- 适配面广：后端关注 N+1 查询、缓存、分页与资源清理；前端额外覆盖语义化 HTML、ARIA、键盘导航、颜色对比与焦点管理。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 中文名 | 代码审查Skill |
| 英文名 | code-review |
| 技能ID | 11821 |
| 触发方式 | 在代码修改后自动激活 |
它解决什么问题
日常开发中最常见的三个痛点是：第一，代码评审高度依赖个人经验，不同评审人关注点不一致，安全项容易被跳过；第二，评审意见常常是"这里不太好"这类模糊表述，缺少可执行的修复建议；第三，评审结论散落在聊天记录和 PR 评论里，事后无法追溯。代码审查Skill 用一份标准化清单 + 分级机制 + 报告模板，把上述问题收敛成一条可重复执行的流程。
一键安装的思路与步骤
需要说明的是，具体安装命令、技能市场入口与配置项因平台而异，以下为通用流程，具体命令与入口请以官方说明为准。
- 确认前提：你所使用的 AI 编程助手/智能体环境需支持"技能（Skill）"或插件扩展机制，并具备读取项目文件与写入文档目录的权限。由于该技能会把报告保存到
docs/reviews/目录，建议确认项目内该路径可写。 - 找到技能入口：在技能市场、技能列表或插件管理页面搜索技能英文名
code-review或技能ID11821，也可直接搜索中文名"代码审查"。 - 一键启用：按官方提供的安装/启用入口完成添加（部分环境为一键添加，部分环境需要在配置文件中声明技能名称）。具体形式与命令以官方说明为准。
- 验证是否生效：完成任意一次小范围代码修改后，观察助手是否自动进入审查流程，并输出带"关键 / 警告 / 建议"分级结论的审查结果；同时检查项目内是否生成
docs/reviews/code-review-{session}.md报告文件。若能正常生成，说明技能已生效。 - 纳入团队规范：把
docs/reviews/目录纳入版本管理或 CI 归档范围，让每次审查都有据可查。
2. 该技能的主要功能和特点
- 四大审查清单，覆盖完整质量维度：安全清单（无硬编码秘密、输入验证、输出编码、身份验证、授权检查）、性能清单（无 N+1 查询、适当缓存、高效算法、资源清理、分页实现）、可维护性清单（代码可读、功能集中、类型完整、测试存在、文档存在）、可访问性清单（语义化 HTML、ARIA 标签、键盘导航、颜色对比、焦点管理）。前端项目会额外触发可访问性维度，这是多数通用代码检查工具不具备的角度。
- 三级严重性分级，避免"什么都重要"：关键级对应安全漏洞、数据丢失风险、生产中断、合规违规；警告级对应性能问题、缺少错误处理、类型不完整、缺少测试；建议级对应命名改进、重构机会、文档缺口、风格一致性。分级的意义在于让团队先修关键项，而不是被一堆风格意见淹没。
- 四步审查流程，防止"看两眼就下结论"：先收集上下文（理解变更目的、查看相关工单/需求、确认修改范围），再对照清单审查代码并校验业务逻辑，然后对发现的问题分类定级，最后套用报告模板生成可执行建议。
- 明确的"做与不做"边界：要求具体说明问题、提供修复建议、承认良好实践、对事不对人、不清楚时提问；禁止模糊表述、禁止因风格偏好阻塞合并、禁止跳过安全检查。这让 AI 的评审意见更接近一位成熟的资深工程师，而不是一个挑刺机器。
- 报告可落地、可追溯：统一使用报告模板，结论引用具体文件与行号，最终保存到
docs/reviews/code-review-{session}.md。 - 与普通工具相比强在哪：传统静态检查工具只能发现"规则可描述"的问题（如语法、圈复杂度、已知漏洞模式），而该技能还能结合变更目的判断业务逻辑是否被破坏、授权校验是否遗漏、分页与缓存是否合理，并用自然语言给出修复建议。
3. 如何使用该技能？
步骤一：启用技能并进入项目上下文
在支持技能机制的环境中启用 code-review（技能ID 11821），并确保助手当前工作目录指向你的代码仓库，以便它能读取相关文件。入口与命令以官方说明为准。
步骤二：完成一次代码修改
该技能在代码修改后自动激活。因此正常完成编码即可，无需额外"召唤"。改动可以是新增接口、修复缺陷、重构函数或调整前端组件。
步骤三：补充变更上下文（强烈建议）
为了让审查更准确，建议在触发时说明变更目的与影响范围。示例输入：
本次改动目的是为订单列表接口增加分页与筛选参数，关联需求单 ORD-1024，修改范围为
services/order.ts与api/order/list.ts，请按代码审查清单做一次完整审查。
这段说明直接对应技能流程中的"收集上下文"环节——理解变更目的、审查相关需求、检查修改范围。
步骤四：等待技能按清单审查
技能会依次应用安全、性能、可维护性（前端再加可访问性）清单，并检查项目内既有模式与业务逻辑是否一致。
步骤五：阅读分级报告
输出会按严重性分组呈现，例如：
- 关键：
api/order/list.ts第 42 行直接将请求参数拼入查询条件，存在注入风险，建议使用参数化查询。 - 警告：
services/order.ts第 88 行在循环内逐条查询用户信息，存在 N+1 查询问题，建议改为批量查询。 - 建议：
getOrderList函数已超过 80 行，可拆分为参数校验与查询构造两个函数。
步骤六：按优先级修复
先处理关键项（安全与数据风险），再处理警告项（性能与错误处理），最后酌情处理建议项。修复后可再次触发审查进行复核。
步骤七：归档报告
确认项目内已生成 docs/reviews/code-review-{session}.md，将其提交到仓库或纳入评审记录，形成可追溯的质量档案。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 代码审查Skill（code-review） | 面向 AI 编程助手的流程化审查技能 | 四大清单审查、三级严重性分级、报告模板、结论归档到 docs/reviews | 需支持技能机制的环境，启用后自动触发，门槛较低 | 日常提交前的自查、团队统一评审标准、前端可访问性检查 | 优势：维度全面、结论带分级与修复建议、有归档；不足：依赖 AI 环境，规则细致程度不及专业静态分析引擎 |
| 人工代码评审（Pull Request Review） | 传统团队协作评审 | 人工阅读 diff、评论、批准合并 | 无需安装，但需占用资深工程师时间 | 涉及架构决策、跨团队接口变更 | 优势：能理解复杂业务背景；不足：耗时长、标准不统一、安全检查常被跳过 |
| 静态分析工具（如 SonarQube、ESLint 一类） | 规则引擎驱动的自动化检查 | 语法规则、代码异味、已知漏洞模式、覆盖率统计 | 需配置规则集并接入 CI，初期配置成本较高 | 大规模代码库的持续质量门禁 | 优势：规则确定、可量化、可阻断流水线；不足：难以判断业务逻辑正确性，误报需人工处理 |
| AI 编程助手内置审查能力 | 通用助手附带的代码建议 | 解释代码、提示潜在问题 | 随助手直接可用 | 快速理解陌生代码、即时答疑 | 优势：上手零成本；不足：缺少固定清单与分级标准，输出随机性较大，通常不生成归档报告 |
选型建议：如果团队已有 SonarQube/ESLint 一类规则引擎，可把代码审查Skill 作为"规则之外"的补充，负责业务逻辑、清单式安全检查与前端可访问性；如果团队还没有任何自动化审查，这个技能可以作为低成本起点，先把评审标准立起来。
5. 该技能的典型应用场景与实际体验情况
场景一：后端工程师提交接口改动
角色为服务端开发，痛点是新增列表接口时容易写出 N+1 查询、忘记加分页、循环内未释放资源。使用方式是完成改动后附上需求单号触发审查。实际体验中，性能清单的"无 N+1 查询"“实现分页”"资源清理"三项命中率较高，报告会直接定位到具体函数与行号，修复方向明确。注意事项是：如果改动跨多个文件但未说明范围，审查可能只覆盖部分文件，建议主动说明修改范围。
场景二：前端组件开发与可访问性把关
角色为前端工程师，痛点是可访问性长期靠自觉，语义化标签、ARIA、键盘导航、颜色对比、焦点管理经常遗漏。使用方式是在改动表单或弹窗组件后触发审查。实际体验中，可访问性清单能把"用 div 模拟按钮""弹窗打开后焦点未管理"这类问题显性化，属于传统工具很难覆盖的部分。注意事项是：可访问性清单主要针对前端，纯后端项目不会触发该维度。
场景三：安全敏感模块的变更
角色为负责支付、账户或权限模块的开发者，痛点是硬编码密钥、输入验证缺失、鉴权绕过等风险隐蔽且后果严重。使用方式是把安全清单作为必过项，任何涉及鉴权逻辑的改动都触发一次审查。实际体验中，关键级问题会被单独置顶，避免与风格建议混在一起被忽略。注意事项是：审查结果应作为人工复核的输入，而非替代安全评审。
场景四：团队新人或开源贡献者提交代码
角色为刚加入项目的开发者，痛点是不知道团队规范、改动风格与既有代码不一致。使用方式是提交前先自查一轮。实际体验中，可维护性清单中的"代码可读"“功能集中”“类型完整”“测试存在”“文档存在"能快速指出与项目模式的偏离；同时技能要求"承认良好实践”“对事不对人”，反馈语气相对友好，新人接受度较高。
整体上手难度：低。无需学习新语法，启用后随代码修改自动触发。效果边界：它提供的是结构化的问题发现与建议，不保证覆盖所有缺陷；清单需要结合项目实际情况调整侧重点。注意事项：务必提供变更上下文，否则审查容易停留在表面；生成的报告建议纳入版本管理，避免结论流失。
6. 该技能能为用户带来的价值
- 效率层面：把评审中最耗时的"逐项对照检查"环节自动化。原本需要评审人逐条确认的安全、性能、可维护性、可访问性项，改为由技能在代码修改后自动跑一遍，人工只需复核关键级与警告级结论，评审时间从"通读全量 diff"压缩为"处理分级清单"。
- 门槛层面：让经验不足的开发者也能获得接近资深工程师视角的反馈。四大清单相当于把团队的最佳实践固化成可执行条目，新人不必靠"熬年头"积累评审直觉。
- 一致性层面：统一报告模板 + 统一严重性分级，让不同人、不同时间的评审产出结构一致，减少"这次评审严、下次评审松"的波动，也减少因个人风格偏好导致的无效争论。
- 可追溯层面：报告统一保存到
docs/reviews/code-review-{session}.md，形成按会话归集的质量档案，便于事后复盘、入职培训与合规举证。 - 长期价值：持续跑清单会反向影响编码习惯——开发者在写代码时就会预判"这条会不会被关键级标记"，从而在编码阶段规避硬编码密钥、N+1 查询等常见问题，缺陷右移的成本被显著降低。
7. 常见问题 FAQ
Q1：这个技能怎么安装？需要付费吗？
A：安装入口与具体命令取决于你所使用的 AI 编程助手平台，请在技能市场或插件管理中搜索英文名 code-review 或技能ID 11821 完成启用，具体命令、入口与是否收费请以官方说明为准。安装后可通过"修改代码是否自动触发审查""是否生成 docs/reviews 报告"两步验证是否生效。
Q2：它会自动运行吗？还是每次都要手动调用？
A：根据技能说明，它在代码修改后自动激活。如果你希望审查更精准，建议在触发时主动补充变更目的、关联需求与修改范围，这正好对应它审查流程中的"收集上下文"环节。
Q3：审查报告存在哪里？会不会被覆盖？
A：报告按报告模板生成后，保存到 docs/reviews/code-review-{session}.md。文件名中的 {session} 按会话区分，因此不同会话的报告相互独立。建议把该目录纳入版本管理，避免结论丢失。
Q4：它和 SonarQube、ESLint 这类静态分析工具冲突吗？
A：不冲突，定位不同。静态分析工具基于确定规则做质量门禁，适合接入 CI 阻断流水线；代码审查Skill 更侧重结合变更目的判断业务逻辑、执行清单式安全检查、覆盖前端可访问性，并用自然语言给出修复建议。两者组合使用，覆盖面最完整。
Q5：适合谁用？小团队有必要吗？
A：适合所有会提交代码的人——后端开发者关注安全与性能清单，前端开发者额外受益于可访问性清单，团队新人可用来做提交前自查，技术负责人可用它统一评审标准。小团队尤其值得尝试：在没有专职评审人、也没有预算搭建完整质量体系时，一份固定的审查清单 + 统一的报告模板，是性价比很高的起点。