Agent Skills
返回列表
💻

五轴代码评审

开发编程 更新于 2026.08.30

将以下提示词粘贴到你的 AI 对话框中：

请根据 https://skillhub.cn/install/skillhub.md，安装 @kunlungrowth/kg-code-review-and-quality。

技能介绍

代码评审中的“形式化”与“模糊反馈”问题

在快节奏的工程团队中，PR 评审往往陷入两种极端：要么像走形式一样点个 LGTM 直接通过，要么抛出“这段代码太复杂”“这里可能有点慢”等模糊评论。这两种方式都无法真正把控代码质量，前者放过了隐藏的竞态和安全漏洞，后者则让作者无所适从，不知道如何下手重构。此外，多数评审只关注“代码能不能跑”（正确性），却忽略了架构边界、依赖方向、UI 重渲染等长期影响代码健康的因素。

五轴评审模型与结构化输出

为解决上述问题，该技能建立了一套严格的五轴评审工作流，覆盖 正确性、可读与简洁、架构、安全 和 性能。评审时不只走读实现，而是先看测试是否测对了行为与边界，再按五轴逐项排查。例如，在性能轴上，它会明确指出 N+1 查询或热路径上的大对象创建；在架构轴上，它会质疑随意 any 或特性逻辑泄漏进共享模块。

发现的问题会被强制分级标注，确保作者分清必改与可选：无前缀为必改项，Critical 阻断合并，Nit 和 Optional:/Consider: 则为非必须的轻量建议。针对“太复杂”这类无效反馈，技能要求给出有名字的结构化整改方案，如用类型模型替换条件链、抽 helper 分离编排逻辑，优先“减少活动部件”。最终输出自然语言结论与 ReviewReport 工件，交由下游工具链继续落实简化或安全加固。

适用边界与工程纪律

该技能适用于任何 PR 合并前、功能实现、重构及 bug 修复的评审，但不适用于纯文档修改或一次性私人草稿。它对改动规模有明确感知：约 100 行的改动最易获得好评，单文件超过 1000 行会被视为预警信号。此外，技能内置了严格的依赖与死代码纪律：新增依赖前需评估体积与漏洞，升级依赖必须查看 lockfile diff 且绝不手改；清理死代码时必须“先问再删”，绝不静默删除。

使用场景

  • 提交包含状态过滤逻辑的 PR 前，需要检查新分支是否破坏了原有边界条件并补齐单测。
  • 重构核心模块后，需要评估改动是否引入了循环依赖，并清理重构产生的孤立死代码。
  • 合并涉及外部 API 数据流转的改动时，需排查 SQL 拼接风险及未授权的敏感信息日志记录。
  • 升级核心依赖库时，需验证 changelog 中的破坏性更新，并确认 lockfile diff 无异常手改。

适合人员

  • 负责核心业务重构的后端工程师，诉求是确保架构调整不破坏既有模块边界且无循环依赖。
  • 把控开源项目合并流的维护者，诉求是在合并大量社区 PR 前拦截安全漏洞与性能退化。
  • 刚接手遗留系统并需快速交付修复的敏捷开发者，诉求是获得结构化的整改建议以降低改动风险。
  • 负责 CI/CD 流水线质量卡点的技术负责人，诉求是将五轴评审规则固化为自动化的 PR 门禁。