Claude How To 代码审查检查清单实战指南以安全、性能、质量、测试四维清单驱动 AI 代码审查【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto导读代码审查最容易犯的错误是凭感觉走——看到哪算哪最终漏掉关键漏洞或性能隐患。claude-howto 仓库在code-review-specialist这个可自动触发的 Skill 中内置了一份结构化的代码审查检查清单将审查维度收敛为安全、性能、质量、测试四大类共 38 个可勾选项。本文将逐项拆解这份清单的含义、判断标准与修复思路并演示它与 Skill 主文件、问题记录模板和复杂度分析脚本的组合用法让你或 Claude Code 能在 Pull Request 审查中不遗漏任何类别。一、检查清单在项目中的定位在 claude-howto 仓库中代码审查能力被打包成一个名为code-review-specialist的 Skill它的核心结构如下03-skills/code-review-specialist/ ├── SKILL.md # Skill 主文件触发条件与审查输出要求 ├── scripts/ │ ├── analyze-metrics.py # 计算函数数、类数、平均行长、复杂度 │ └── compare-complexity.py # 对比重构前后圈复杂度/认知复杂度 └── templates/ ├── review-checklist.md # 本文讲解的检查清单 └── finding-template.md # 单个问题的记录模板根据 Skill 主文件 的 frontmatter该 Skill 在用户请求代码审查、代码质量评估、Pull Request 审查或提到安全分析和性能优化时被自动触发。它的审查能力被划分为四条主线安全分析身份验证 / 授权问题、数据泄露风险、注入漏洞、密码学弱点、敏感数据日志记录性能审查算法效率Big O 分析、内存优化、数据库查询优化、缓存机会、并发问题代码质量SOLID 原则、设计模式、命名规范、文档、测试覆盖率可维护性代码可读性、函数长度建议少于 50 行、圈复杂度、依赖管理、类型安全。英文版 SKILL.md 明确要求审查时读取检查清单文件并以其为指引确保审查过程不遗漏任何类别。也就是说这份清单是审查流程的防漏网机制——它是 Skill 的灵魂骨架。二、安全检查十道必答题守住底线清单的安全检查一节共 10 项全部围绕 OWASP 常见的注入、认证、授权与敏感信息泄露问题展开。逐项解读如下#检查项判断要点常见反例与修复方向1没有硬编码的凭据或密钥代码库、配置文件、注释、提交历史中是否有password、api_key、secret、token字面量使用环境变量或密钥管理服务如 Vault注入配合 .gitignore 排除.env2所有用户输入都做了校验每个外部输入表单、URL 参数、请求体、文件上传是否经过白名单校验服务端二次校验不依赖前端校验3使用参数化查询防止 SQL 注入所有 SQL 是否通过预编译占位符拼接将字符串拼接 SQL 改为?/$1参数绑定4所有会修改状态的操作都有 CSRF 防护POST/PUT/DELETE 等写操作是否带 CSRF Token框架内置 CSRF 中间件默认开启5使用正确的转义防止 XSS输出到 HTML 的内容是否按上下文转义React 默认转义、模板引擎{{ }}、禁止innerHTML拼接用户输入6受保护的端点有身份验证检查每个受保护路由/接口是否有认证中间件未认证请求返回 401 而非 2007资源访问有授权检查用户只能访问自己有权访问的资源越权/IDOR对象级授权校验而非仅登录即可8密码使用安全哈希算法bcrypt、argon2密码存储是否使用可调代价因子的哈希算法弃用 MD5/SHA1 明文哈希使用bcrypt或argon2id9日志中没有敏感数据日志是否打印令牌、密码、身份证号、信用卡号日志脱敏敏感字段打码或仅记录引用 ID10强制使用 HTTPS生产环境是否强制 TLS是否配置 HSTS全站 HTTPS 跳转禁用不安全的协议这 10 项与 Skill 主文件中数据泄露风险、注入漏洞、密码学弱点、敏感数据日志记录的能力描述一一对应构成安全审查的最小充分集。值得注意的是仓库还提供了独立的secure-reviewer子代理见 04-subagents/secure-reviewer.md以只读模式专注安全审查——在实际流程中安全检查可以由该子代理与 Skill 配合完成。三、性能检查把复杂度与查询次数作为硬指标性能问题的判定比安全问题更需要量化依据清单给出了 10 个可验证的性能检查点#检查项判断要点常见反例与修复方向1没有 N1 查询循环内是否有查询操作每个用户都发一次查询使用 JOIN 或批量查询检查 ORM 的预加载eager loading2索引使用合理查询条件列是否有索引是否出现全表扫描为 WHERE/JOIN/ORDER BY 列建立索引注意联合索引顺序3在有价值的地方做了缓存热点数据、重复计算结果是否有缓存层Redis 缓存、内存缓存、HTTP 缓存头注意失效策略4主线程上没有阻塞操作UI 线程/事件循环是否有同步 I/O、重计算移到异步或后台任务5正确使用 async/await是否有异步函数内部被同步阻塞、.Result/.Wait()死锁全链路 async避免 sync-over-async6大数据集已经分页列表接口是否一次性返回全量数据游标分页/偏移分页限制单页大小7数据库连接已做连接池是否每次请求都新建连接使用连接池并合理设置 max 连接数8正则表达式已优化是否存在灾难性回溯(a)$这类嵌套量词使用非贪婪匹配、原子组避免嵌套量词9没有不必要的对象创建循环内是否重复创建昂贵对象、字符串拼接是否用复用对象、使用 StringBuilder/join10没有内存泄漏事件监听器、全局引用、定时器是否被正确释放清理监听器、使用弱引用、检查闭包持有大对象性能审查的量化支撑来自 Skill 自带的 analyze-metrics.py 脚本。它从四个维度输出量化指标python3 scripts/analyze-metrics.py 被审查文件.py脚本内部通过正则统计def/class数量、平均行长度并用if/elif/else/for/while/and/or的出现次数估算复杂度分数见 analyze-metrics.py。这套先量化、后判断的思路正好对应清单中函数是否过大、复杂度是否可控的检查逻辑。四、质量检查可读性、可维护性与设计原则质量检查 10 项解决的是这段代码三个月后还有人看得懂吗的问题#检查项判断要点常见反例与修复方向1函数少于 50 行函数是否超出 50 行、职责是否单一拆分函数每函数只做一件事也与 SKILL.md 中函数长度建议少于 50 行一致2变量命名清晰命名是否表达意图而非data、tmp、x使用业务语义命名布尔变量用is/has前缀3没有重复代码相同逻辑是否出现多次DRY抽取公共函数/工具类警惕复制粘贴4错误处理合理异常是否被吞掉裸except/空 catch、错误是否有意义精确捕获、记录上下文、向上抛出可处理错误5注释解释的是 WHY而不是 WHAT注释是否解释为什么这样写而非逐行翻译代码用注释说明业务约束、权衡和陷阱6生产环境中没有 console.log是否有调试日志残留改用结构化日志库配合日志级别7有类型检查TypeScript / JSDoc是否利用静态类型或 JSDoc 标注补全类型定义开启严格模式8遵循 SOLID 原则单一职责、开闭、里氏替换、接口隔离、依赖倒置检查类是否职责过多、是否面向抽象编程9正确应用设计模式模式是否解决问题而非炫技评估模式引入的成本收益10代码具备自解释性不读注释能否大致读懂逻辑用清晰命名和结构替代注释质量问题的深度分析可借助仓库中的code-reviewer子代理04-subagents/code-reviewer.md完成综合质量评估审查者负责基于清单逐项判定即可。五、测试检查用边界与错误场景衡量覆盖质量测试检查 8 项重点不只是有没有测试而是测试有没有测到点子上#检查项判断要点1已编写单元测试核心逻辑是否有对应单测且可独立运行2覆盖了边界情况空集合、极值、临界值、null/undefined 是否被测试3测试了错误场景非法输入、超时、依赖失败时行为是否符合预期4有集成测试模块间、数据库、外部服务交互是否被覆盖5覆盖率大于 80%行/分支覆盖率是否达标80% 为清单设定的参考阈值6没有不稳定测试测试是否依赖时序、网络、共享状态导致偶发失败7外部依赖已做 mock网络、数据库、第三方 API 是否被隔离8测试名称清晰测试名是否描述行为如should_reject_negative_amount仓库本身也体现了这一测试标准scripts/tests/下包含针对 EPUB 构建、网站构建、交叉引用与 Markdown 渲染等脚本的 pytest 测试套件见 scripts/tests/并支持pytest --cov生成覆盖率报告。这说明清单中的覆盖率 80%测试名称清晰等条目在该仓库中是真实执行的规范而非纸面要求。六、从勾选到报告检查清单 记录模板 分析脚本的组合流程检查清单回答审什么而把发现的问题沉淀成可追踪的报告需要配合 Skill 中的另外两个组件。6.1 问题记录模板把每个发现结构化对清单中勾出的每一项问题使用问题记录模板逐个归档。模板要求每个发现必须包含严重性Critical阻塞发布/ High合并前应修复/ Medium尽快修复/ Low可选优化类别Security / Performance / Code Quality / Maintainability / Testing / Design Pattern / Documentation位置文件、行号、函数/方法问题描述是什么、为什么重要、当前行为、期望行为代码示例当前有问题的代码与建议修复代码影响分析以表格列出对性能、用户体验、可扩展性、可维护性的影响及严重性。模板中内置了一个 N1 查询的典型示例循环内对每个用户发起查询20 个用户产生 100 次查询修复方式为一次 JOIN 查询批量取回usersWithPosts。这个示例与清单没有 N1 查询条目直接呼应审查者可以直接复用为输出范例。6.2 复杂度对比脚本验证重构是否真正变简单当审查涉及重构类改动时Skill 提供了 compare-complexity.py 脚本对比重构前后两个版本的复杂度python3 scripts/compare-complexity.py 重构前.py 重构后.py脚本基于 McCabe 方法计算圈复杂度统计if、elif、for、while、except、and、or等判定点基数从 1 起算见 compare-complexity.py同时计算认知复杂度基于嵌套深度与控制流衡量代码理解难度和可维护性指数0–100大于 85 为优秀大于 65 为良好低于 50 为差见 compare-complexity.py。输出会给出前后对比与自动评估结论代码更易维护 / 复杂度降低等。这正是清单中函数少于 50 行代码具备自解释性等质量条目的量化验证工具。七、落地工作流如何在一次 PR 审查中跑完四维清单将上述组件串起来一次完整的审查可以按如下流程执行量化预热对变更文件运行analyze-metrics.py拿到函数数、复杂度分数等基线数据四维扫查打开检查清单按安全 → 性能 → 质量 → 测试的顺序逐项勾选任何一项不满足即记录问题归档对每个问题用记录模板填写严重性、位置、影响与修复示例重构验证若改动涉及重构用compare-complexity.py对比前后复杂度用数据支撑是否值得合入的结论汇总输出按照 SKILL.md 中审查模板的要求输出——先给整体质量评分1–5、关键发现数量与优先关注区域再按类别安全/性能/质量/可维护性列出发现关键问题标注文件与行号、影响、严重性并给出修复示例。需要提醒的是检查清单是最小完备集而非万能集它适合作为每个 PR 的默认兜底但针对特定领域如密码学协议、分布式一致性仍需结合专业子代理如secure-reviewer、performance-optimizer见 04-subagents/做纵深审查。安装该 Skill 到个人环境只需# 复制到个人 Skills 目录 cp -r 03-skills/code-review-specialist ~/.claude/skills/随后在 Claude Code 中提出请审查这段代码 / 评估这个 PRSkill 便会自动加载检查清单并按其框架输出结构化审查报告——四维清单从此成为你每次代码审查的固定流程而不是可选项。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Claude How To 代码审查检查清单实战指南：以安全、性能、质量、测试四维清单驱动 AI 代码审查
Claude How To 代码审查检查清单实战指南以安全、性能、质量、测试四维清单驱动 AI 代码审查【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto导读代码审查最容易犯的错误是凭感觉走——看到哪算哪最终漏掉关键漏洞或性能隐患。claude-howto 仓库在code-review-specialist这个可自动触发的 Skill 中内置了一份结构化的代码审查检查清单将审查维度收敛为安全、性能、质量、测试四大类共 38 个可勾选项。本文将逐项拆解这份清单的含义、判断标准与修复思路并演示它与 Skill 主文件、问题记录模板和复杂度分析脚本的组合用法让你或 Claude Code 能在 Pull Request 审查中不遗漏任何类别。一、检查清单在项目中的定位在 claude-howto 仓库中代码审查能力被打包成一个名为code-review-specialist的 Skill它的核心结构如下03-skills/code-review-specialist/ ├── SKILL.md # Skill 主文件触发条件与审查输出要求 ├── scripts/ │ ├── analyze-metrics.py # 计算函数数、类数、平均行长、复杂度 │ └── compare-complexity.py # 对比重构前后圈复杂度/认知复杂度 └── templates/ ├── review-checklist.md # 本文讲解的检查清单 └── finding-template.md # 单个问题的记录模板根据 Skill 主文件 的 frontmatter该 Skill 在用户请求代码审查、代码质量评估、Pull Request 审查或提到安全分析和性能优化时被自动触发。它的审查能力被划分为四条主线安全分析身份验证 / 授权问题、数据泄露风险、注入漏洞、密码学弱点、敏感数据日志记录性能审查算法效率Big O 分析、内存优化、数据库查询优化、缓存机会、并发问题代码质量SOLID 原则、设计模式、命名规范、文档、测试覆盖率可维护性代码可读性、函数长度建议少于 50 行、圈复杂度、依赖管理、类型安全。英文版 SKILL.md 明确要求审查时读取检查清单文件并以其为指引确保审查过程不遗漏任何类别。也就是说这份清单是审查流程的防漏网机制——它是 Skill 的灵魂骨架。二、安全检查十道必答题守住底线清单的安全检查一节共 10 项全部围绕 OWASP 常见的注入、认证、授权与敏感信息泄露问题展开。逐项解读如下#检查项判断要点常见反例与修复方向1没有硬编码的凭据或密钥代码库、配置文件、注释、提交历史中是否有password、api_key、secret、token字面量使用环境变量或密钥管理服务如 Vault注入配合 .gitignore 排除.env2所有用户输入都做了校验每个外部输入表单、URL 参数、请求体、文件上传是否经过白名单校验服务端二次校验不依赖前端校验3使用参数化查询防止 SQL 注入所有 SQL 是否通过预编译占位符拼接将字符串拼接 SQL 改为?/$1参数绑定4所有会修改状态的操作都有 CSRF 防护POST/PUT/DELETE 等写操作是否带 CSRF Token框架内置 CSRF 中间件默认开启5使用正确的转义防止 XSS输出到 HTML 的内容是否按上下文转义React 默认转义、模板引擎{{ }}、禁止innerHTML拼接用户输入6受保护的端点有身份验证检查每个受保护路由/接口是否有认证中间件未认证请求返回 401 而非 2007资源访问有授权检查用户只能访问自己有权访问的资源越权/IDOR对象级授权校验而非仅登录即可8密码使用安全哈希算法bcrypt、argon2密码存储是否使用可调代价因子的哈希算法弃用 MD5/SHA1 明文哈希使用bcrypt或argon2id9日志中没有敏感数据日志是否打印令牌、密码、身份证号、信用卡号日志脱敏敏感字段打码或仅记录引用 ID10强制使用 HTTPS生产环境是否强制 TLS是否配置 HSTS全站 HTTPS 跳转禁用不安全的协议这 10 项与 Skill 主文件中数据泄露风险、注入漏洞、密码学弱点、敏感数据日志记录的能力描述一一对应构成安全审查的最小充分集。值得注意的是仓库还提供了独立的secure-reviewer子代理见 04-subagents/secure-reviewer.md以只读模式专注安全审查——在实际流程中安全检查可以由该子代理与 Skill 配合完成。三、性能检查把复杂度与查询次数作为硬指标性能问题的判定比安全问题更需要量化依据清单给出了 10 个可验证的性能检查点#检查项判断要点常见反例与修复方向1没有 N1 查询循环内是否有查询操作每个用户都发一次查询使用 JOIN 或批量查询检查 ORM 的预加载eager loading2索引使用合理查询条件列是否有索引是否出现全表扫描为 WHERE/JOIN/ORDER BY 列建立索引注意联合索引顺序3在有价值的地方做了缓存热点数据、重复计算结果是否有缓存层Redis 缓存、内存缓存、HTTP 缓存头注意失效策略4主线程上没有阻塞操作UI 线程/事件循环是否有同步 I/O、重计算移到异步或后台任务5正确使用 async/await是否有异步函数内部被同步阻塞、.Result/.Wait()死锁全链路 async避免 sync-over-async6大数据集已经分页列表接口是否一次性返回全量数据游标分页/偏移分页限制单页大小7数据库连接已做连接池是否每次请求都新建连接使用连接池并合理设置 max 连接数8正则表达式已优化是否存在灾难性回溯(a)$这类嵌套量词使用非贪婪匹配、原子组避免嵌套量词9没有不必要的对象创建循环内是否重复创建昂贵对象、字符串拼接是否用复用对象、使用 StringBuilder/join10没有内存泄漏事件监听器、全局引用、定时器是否被正确释放清理监听器、使用弱引用、检查闭包持有大对象性能审查的量化支撑来自 Skill 自带的 analyze-metrics.py 脚本。它从四个维度输出量化指标python3 scripts/analyze-metrics.py 被审查文件.py脚本内部通过正则统计def/class数量、平均行长度并用if/elif/else/for/while/and/or的出现次数估算复杂度分数见 analyze-metrics.py。这套先量化、后判断的思路正好对应清单中函数是否过大、复杂度是否可控的检查逻辑。四、质量检查可读性、可维护性与设计原则质量检查 10 项解决的是这段代码三个月后还有人看得懂吗的问题#检查项判断要点常见反例与修复方向1函数少于 50 行函数是否超出 50 行、职责是否单一拆分函数每函数只做一件事也与 SKILL.md 中函数长度建议少于 50 行一致2变量命名清晰命名是否表达意图而非data、tmp、x使用业务语义命名布尔变量用is/has前缀3没有重复代码相同逻辑是否出现多次DRY抽取公共函数/工具类警惕复制粘贴4错误处理合理异常是否被吞掉裸except/空 catch、错误是否有意义精确捕获、记录上下文、向上抛出可处理错误5注释解释的是 WHY而不是 WHAT注释是否解释为什么这样写而非逐行翻译代码用注释说明业务约束、权衡和陷阱6生产环境中没有 console.log是否有调试日志残留改用结构化日志库配合日志级别7有类型检查TypeScript / JSDoc是否利用静态类型或 JSDoc 标注补全类型定义开启严格模式8遵循 SOLID 原则单一职责、开闭、里氏替换、接口隔离、依赖倒置检查类是否职责过多、是否面向抽象编程9正确应用设计模式模式是否解决问题而非炫技评估模式引入的成本收益10代码具备自解释性不读注释能否大致读懂逻辑用清晰命名和结构替代注释质量问题的深度分析可借助仓库中的code-reviewer子代理04-subagents/code-reviewer.md完成综合质量评估审查者负责基于清单逐项判定即可。五、测试检查用边界与错误场景衡量覆盖质量测试检查 8 项重点不只是有没有测试而是测试有没有测到点子上#检查项判断要点1已编写单元测试核心逻辑是否有对应单测且可独立运行2覆盖了边界情况空集合、极值、临界值、null/undefined 是否被测试3测试了错误场景非法输入、超时、依赖失败时行为是否符合预期4有集成测试模块间、数据库、外部服务交互是否被覆盖5覆盖率大于 80%行/分支覆盖率是否达标80% 为清单设定的参考阈值6没有不稳定测试测试是否依赖时序、网络、共享状态导致偶发失败7外部依赖已做 mock网络、数据库、第三方 API 是否被隔离8测试名称清晰测试名是否描述行为如should_reject_negative_amount仓库本身也体现了这一测试标准scripts/tests/下包含针对 EPUB 构建、网站构建、交叉引用与 Markdown 渲染等脚本的 pytest 测试套件见 scripts/tests/并支持pytest --cov生成覆盖率报告。这说明清单中的覆盖率 80%测试名称清晰等条目在该仓库中是真实执行的规范而非纸面要求。六、从勾选到报告检查清单 记录模板 分析脚本的组合流程检查清单回答审什么而把发现的问题沉淀成可追踪的报告需要配合 Skill 中的另外两个组件。6.1 问题记录模板把每个发现结构化对清单中勾出的每一项问题使用问题记录模板逐个归档。模板要求每个发现必须包含严重性Critical阻塞发布/ High合并前应修复/ Medium尽快修复/ Low可选优化类别Security / Performance / Code Quality / Maintainability / Testing / Design Pattern / Documentation位置文件、行号、函数/方法问题描述是什么、为什么重要、当前行为、期望行为代码示例当前有问题的代码与建议修复代码影响分析以表格列出对性能、用户体验、可扩展性、可维护性的影响及严重性。模板中内置了一个 N1 查询的典型示例循环内对每个用户发起查询20 个用户产生 100 次查询修复方式为一次 JOIN 查询批量取回usersWithPosts。这个示例与清单没有 N1 查询条目直接呼应审查者可以直接复用为输出范例。6.2 复杂度对比脚本验证重构是否真正变简单当审查涉及重构类改动时Skill 提供了 compare-complexity.py 脚本对比重构前后两个版本的复杂度python3 scripts/compare-complexity.py 重构前.py 重构后.py脚本基于 McCabe 方法计算圈复杂度统计if、elif、for、while、except、and、or等判定点基数从 1 起算见 compare-complexity.py同时计算认知复杂度基于嵌套深度与控制流衡量代码理解难度和可维护性指数0–100大于 85 为优秀大于 65 为良好低于 50 为差见 compare-complexity.py。输出会给出前后对比与自动评估结论代码更易维护 / 复杂度降低等。这正是清单中函数少于 50 行代码具备自解释性等质量条目的量化验证工具。七、落地工作流如何在一次 PR 审查中跑完四维清单将上述组件串起来一次完整的审查可以按如下流程执行量化预热对变更文件运行analyze-metrics.py拿到函数数、复杂度分数等基线数据四维扫查打开检查清单按安全 → 性能 → 质量 → 测试的顺序逐项勾选任何一项不满足即记录问题归档对每个问题用记录模板填写严重性、位置、影响与修复示例重构验证若改动涉及重构用compare-complexity.py对比前后复杂度用数据支撑是否值得合入的结论汇总输出按照 SKILL.md 中审查模板的要求输出——先给整体质量评分1–5、关键发现数量与优先关注区域再按类别安全/性能/质量/可维护性列出发现关键问题标注文件与行号、影响、严重性并给出修复示例。需要提醒的是检查清单是最小完备集而非万能集它适合作为每个 PR 的默认兜底但针对特定领域如密码学协议、分布式一致性仍需结合专业子代理如secure-reviewer、performance-optimizer见 04-subagents/做纵深审查。安装该 Skill 到个人环境只需# 复制到个人 Skills 目录 cp -r 03-skills/code-review-specialist ~/.claude/skills/随后在 Claude Code 中提出请审查这段代码 / 评估这个 PRSkill 便会自动加载检查清单并按其框架输出结构化审查报告——四维清单从此成为你每次代码审查的固定流程而不是可选项。【免费下载链接】claude-howtoA visual, example-driven guide to Claude Code — from basic concepts to advanced agents, with copy-paste templates that bring immediate value.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-howto创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考