代码审查与质量改进

代码审查不是走个流程——要发现隐患、给出可操作的审查意见、跟踪到修复完成。这个案例展示如何用 LanMate 把代码审查从“看一眼说没问题”变成结构化闭环，让问题不遗漏、修复可追溯。

用到的技能

• 内置技能（随 LanMate 安装，开箱即用）：LanMate 本身可读写代码文件，无需额外内置技能
• 技能商店：代码审查请求方法论——编写结构化审查请求，含变更摘要与自测清单；代码审查接收方法论——以接收者角色处理审查意见，建立分类到验证的闭环；代码质量审查器——扫描复杂度、重复代码、命名规范等质量问题；代码安全扫描器——扫描硬编码密钥、SQL 注入、XSS 等安全风险

场景痛点

• 审查请求没上下文：只丢一个变更链接，审查者不知道改了什么、为什么改、怎么测的
• 审查意见全靠感觉：“这里不太对”“建议优化”，没有严重程度和具体建议
• 质量问题反复出现：函数过长、魔法数字、重复代码，每次审查都提但每次都不改
• 安全风险被忽略：硬编码密钥、SQL 注入、XSS，靠人眼审查根本看不过来
• 修复没有闭环：提了意见就完事，改没改、改得对不对无人跟踪

推荐流程

提示词示例

提交审查前自查

我准备提交一个代码变更，请帮我生成结构化审查请求：
- 变更摘要：本次改了什么、为什么改（1-2 句话）
- 变更范围：涉及的文件列表和每个文件的改动类型（新增 / 修改 / 删除）
- 自测清单：我应该自测哪些场景
- 风险提示：哪些改动可能影响现有功能
- 回滚方案：如果出问题怎么回滚

读取 src/ 目录下的代码文件，根据最近的改动生成。
自测清单要具体到测试场景，不要写"全面测试"这种泛化表述。

接收他人代码变更进行审查

请审查 src/ 目录下的代码变更，逐文件生成审查意见：
1. 先分析变更范围：哪些文件改了、每个文件改了什么
2. 逐文件审查，每条意见包含：
   - 文件名和行号
   - 问题描述
   - 严重程度（阻断 / 重要 / 建议）
   - 修改建议（具体到怎么改）
3. 汇总变更中的亮点（值得学习的写法）

重点检查：
- 逻辑错误和边界条件（空值、越界、异常未处理）
- 是否引入不必要的复杂度
- 是否有硬编码值应该提取为配置

代码质量评估

请扫描 src/ 目录下的代码，生成质量审查报告：
1. 函数复杂度：标出圈复杂度过高的函数（建议阈值 15 以上标记）
2. 重复代码：标出重复出现的代码块
3. 命名规范：检查函数名、变量名是否表意清晰、是否符合约定
4. 代码异味：过长的函数、过深的嵌套、过大的类

每个问题输出：
- 文件名和位置
- 问题类型
- 严重程度（高 / 中 / 低）
- 重构建议

不要报告纯格式问题（如缩进、空格），聚焦影响可维护性的实质问题。

安全扫描

请扫描 src/ 目录下的代码，检测安全风险：
1. 硬编码密钥：检查是否有 API 密钥、密码、Token 写死在代码中
2. SQL 注入：检查是否有拼接 SQL 语句的写法
3. XSS：检查是否有未转义的用户输入直接输出到页面
4. 敏感信息泄露：检查日志中是否打印了敏感数据

每个风险输出：
- 文件名和行号
- 风险类型
- 严重程度（严重 / 高 / 中 / 低）
- 修复建议

无法确认是否为风险的位置标注"需人工确认"，不要自行判定。

生成审查报告

请汇总以上审查结果，生成一份代码审查报告：
- 问题列表（含文件、行号、问题描述、严重程度）
- 按严重程度分组统计（阻断 / 重要 / 建议）
- 每个问题的修复建议
- 责任人和建议修复期限
- 审查结论（通过 / 需修改后通过 / 不通过）

阻断级问题必须在报告中置顶，并说明不修复的后果。
输出 HTML 报告。

验收标准

• 审查请求含变更摘要、变更范围、自测清单，自测场景具体可执行
• 每条审查意见含文件名、行号、严重程度和具体修改建议
• 质量报告聚焦可维护性问题，不报告纯格式问题
• 安全风险按严重度分级，无法确认的标注“需人工确认”
• 审查报告含问题列表、修复建议、责任人和审查结论，阻断级问题置顶

常见错误