技能介绍

审查 Python 代码时遇到的痛点

在 Code Review 中，审查 Python 代码往往依赖个人经验。不同审查者关注的点差异很大——有人只看命名和格式，有人偏重异常处理和安全漏洞。缺乏统一标准时，同一段代码可能被一位审查者放行、被另一位打回重写。尤其当团队快速迭代时，review 意见容易流于「感觉不对」式的判断，缺少可量化的反馈。

八维度系统化审查

这个技能将审查流程拆为八个固定维度，按顺序逐项检查：

命名规范：检查 snakecase / PascalCase / UPPERSNAKE_CASE 的适用场景、布尔前缀、私有成员标记，以及是否与内置名称冲突。
函数设计：评估单一职责、函数长度（超过 50 行建议拆分）、参数数量（超过 5 个建议封装）和返回值类型一致性。
复杂度与可读性：关注嵌套深度、分支数量、列表推导式复杂度，以及重复代码和「神奇数字」。
类型安全：检查类型注解的完整性和准确性，以 mypy --strict 为基准衡量。
异常处理：禁止裸 except 和吞异常，要求资源用 with 管理，自定义异常继承 Exception。
文档与注释：docstring 遵循 Google / NumPy 风格，注释解释「为什么」而非「做什么」。
安全性：排查硬编码密钥、路径遍历、非参数化 SQL，以及 eval / pickle 的不当使用。
性能与最佳实践：检查循环内重复计算、容器选型、字符串拼接方式，以及 import 卫生。

每个维度完成后用 ✅ / ⚠️ / ❌ 标注结果，最终给出星级评分。

适用边界

这套流程适合作为 PR 审查或本地 pre-commit 的标准化检查项，但它不是静态分析工具的替代品。类型检查、lint 和安全扫描仍需配合 mypy、ruff、bandit 等工具运行。技能输出的是人工 review 风格的结构化建议，无法感知代码运行上下文——比如一个在文档中约定俗成的 tmp 变量名，在特定场景下可能被误判为无意义命名。