代码审查工具

解决的具体问题

日常代码审查中，人工Review常面临三个痛点：一是耗时——开发者需逐行核对逻辑，难以快速覆盖规范、可维护性、安全性等多维度；二是维度不统一——不同审查者关注重点差异大，比如有人侧重语法，有人侧重业务逻辑，导致审查结果零散；三是提交前难以快速预判——合并代码时，往往只能通过跑测试验证功能，缺少对“这段代码是否该合并”的结构化评分参考。此外，跨项目审查时，风格不统一也是常见难题——A项目的审查标准是“优先可读性”，B项目是“优先性能”，人工切换成本高。

技能如何工作

这个基于MCP（Model Context Protocol）的代码审查工具，核心逻辑是“大模型做路由层，工具负责构建提示词与对接API”，具体能力围绕三类审查场景与评分解析展开：

• 多场景审查提示词构建：提供三个核心工具，对应不同审查需求——scripts.tools.review_code 用于待提交的整段代码整体审查，可传入代码文本、可选的审查风格或提交信息；scripts.tools.review_diff 针对Git diff变更内容，聚焦“本次修改是否引入新问题”；scripts.tools.review_file 针对单个文件，需提供文件路径与内容，适合批量处理独立模块。三者均不直接调用LLM，而是生成适配API的审查提示词，确保审查维度标准化。
• 结构化评分解析：通过 scripts.tools.parse_review_score 从审查文本中提取“总分:XX分”格式的结果，将非结构化的审查内容转化为可量化的评分，方便快速判断代码质量等级。
• 关键工作步骤：大模型首先检查 scripts.config.settings.api_key 是否为空，若无密钥则通过 AskUserQuestion 询问用户，拿到后调用 scripts.config.set_api_key 保存；再根据用户意图选择对应工具，提取必填参数（如代码文本、diff内容、文件路径等），若参数不完整则进一步询问；最后调用工具函数获取 result["raw"] 原始数据，整理后展示给用户。

适用边界与注意点

• 必须配置API密钥：密钥是工具运行的前提，无密钥时无法调用API获取审查结果，且禁止自行搜索或编造数据。
• 不直接调用LLM：工具仅负责构建审查提示词，实际的审查与打分需通过API完成，结果准确性依赖API的LLM能力。
• 参数完整性要求：每个工具都有必填参数（如 review_diff 需提供 diff 内容），若参数缺失，需通过 AskUserQuestion 补全，否则无法构建有效提示词。
• 评分格式依赖：parse_review_score 仅能提取“总分:XX分”格式的评分，若审查文本未按此格式输出，可能无法正确解析。