目录
为什么 AI 审代码比人稳
在 WorkBuddy 里怎么做
核心提示词长这样
实跑结果：6 个坑一个没跑掉
审查报告长什么样
几个边界要说清楚
WorkBuddy 支持接本地模型
支持原理
🛠️ 主流接入方式
⚙️ 配置步骤（以 Ollama 为例）
💡 实用建议
WorkBuddy 默认支持的云端模型
🧠 WorkBuddy 默认支持的云端模型一览
💡 模型选择小贴士
你有没有过这种经历：周五下午提了个 PR，等到下周三才有人 review，回复就一句话"逻辑看着没问题，过"。结果上线当天炸了——一个空指针，review 的人根本没看那行。
不是同事不负责，是人 review 代码有天然的弱点：会疲劳、会漏看、会凭感觉。一个几百行的 PR，能认真看到第 50 行的人都不多。
我现在的做法是：PR 提给我之前，先让 WorkBuddy 过一遍。它不是替代人，是替人把那些"低级但致命"的坑先扫出来。人只需要看业务逻辑对不对。
为什么 AI 审代码比人稳
人 review 是抽样检查，看到哪算哪。AI 是全文扫描，而且每次标准一致——不会因为"今天心情好"就多看你两行。
更重要的是，AI 不怯场。你让 junior 去 review 架构师的代码，他不敢提意见。WorkBuddy 不管你是谁，代码有问题就标出来。
我做了个实测：一段我自己写的下单代码，故意埋了 6 个坑（SQL 注入、并发不安全、精度丢失、资源泄漏、吞异常、漏校验）。丢给 WorkBuddy，一次性全揪出来了，还给了修复代码。
下面说怎么在 WorkBuddy 里跑通这套流程。
在 WorkBuddy 里怎么做
不需要装任何插件，三步：
第一步，把要审的代码文件准备好。可以是一个 Java 文件，也可以是 `git diff` 导出的改动文本。
第二步，在对话里让 WorkBuddy 读文件并审查。直接说：
> 读取 demo_code_review 目录下的 OrderService.java，按以下维度帮我做代码审查：空指针风险、SQL 注入、资源是否关闭、并发安全、异常处理、入参校验。每个问题标出文件行号、严重程度、修复代码。
WorkBuddy 会用 Read 工具把代码读进来，然后逐行分析。
第三步，让它把审查报告存成文件。在提示词里加一句"保存为 review_OrderService.md"，它就自动 Write 到工作目录。
核心提示词长这样
这是我实际在用的审查提示词（可直接复制改路径）：
你是一名资深 Java 代码审查专家。请读取 {文件路径}，按以下维度逐行审查：
1. 空指针风险：所有对象调用前是否可能为空
2. SQL 注入：是否有字符串拼接 SQL
3. 资源关闭：Connection/Statement/ResultSet 是否在 finally 或用 try-with-resources 关闭
4. 并发安全：共享变量是否有竞态（++、非原子读写）
5. 异常处理：是否有 catch 空块、吞异常、printStackTrace
6. 数值精度：BigDecimal 是否用了 double 构造
7. 入参校验：公开方法是否校验了入参
输出要求：
- 按严重程度排序（🔴高危 / 🟡中危 / 🟢低危）
- 每条含：行号、问题、修复代码
- 最后给整体建议和"是否建议合并"
保存为 review_{文件名}.md
实跑结果：6 个坑一个没跑掉
这是我故意写的"问题代码"被 WorkBuddy 揪出来的部分：
// 修复后的安全版本（WorkBuddy 给出的建议之一）
public String createOrder(String userId, String productId, double amount) {
// 1. 入参统一校验
if (userId == null || productId == null || amount <= 0) {
throw new IllegalArgumentException("参数不合法");
}
// 2. BigDecimal 用 valueOf 避免精度丢失
BigDecimal price = BigDecimal.valueOf(amount);
// 3. PreparedStatement 防注入 + try-with-resources 自动关资源
String sql = "SELECT id FROM orders WHERE user_id = ? AND product_id = ?";
try (Connection conn = DataSourceHolder.getConn();
PreparedStatement ps = conn.prepareStatement(sql);
ResultSet rs = ps.executeQuery()) {
ps.setString(1, userId);
ps.setString(2, productId);
List<String> ids = new ArrayList<>();
while (rs.next()) {
ids.add(rs.getString("id"));
}
// 4. AtomicInteger 解决并发计数
orderCount.incrementAndGet();
return "ok:" + ids.size() + ":" + price;
} catch (SQLException e) {
// 5. 打日志 + 抛业务异常，不吞
log.error("创建订单失败 userId={}", userId, e);
throw new OrderCreateException("订单创建失败", e);
}
}
注意 `orderCount` 字段也要改成 `private final AtomicInteger orderCount = new AtomicInteger(0);`，否则 `incrementAndGet()` 编译不过。WorkBuddy 在报告里也标了这一点。
审查报告长什么样
WorkBuddy 生成的报告是结构化 Markdown，每个缺陷带行号、严重程度、修复代码，最后给一个"是否建议合并"的结论。我一般把它贴在 PR 评论里，或者存进资料库长期留档。
实测下来，低级缺陷（注入、空指针、资源泄漏）它抓得比人准。业务逻辑类的（这个方法到底该不该这么设计）它给不出好建议，那部分还得人来看。
几个边界要说清楚
第一，别让它审整个大仓库。一次审一个文件或一个小 diff，质量最高。丢个几千行的模块进去，它会抓大放小。
第二，它的修复代码要人工确认能编译。上面那个例子，如果只改方法不改字段，AtomicInteger 那行会报错。AI 给的代码是参考，不是直接能合。
第三，敏感代码注意。如果代码不能出内网，就别用云端模型审。WorkBuddy 支持接本地模型，那个场景更合适。
第四，可以做成定时任务。如果你每天提很多 PR，可以用 automation_update 建个定时任务，每天下午跑一遍当天改动的代码文件，自动出审查报告。
WorkBuddy 支持接本地模型
支持原理
WorkBuddy 底层兼容OpenAI API 标准协议（/v1/chat/completions格式）-2。因此，任何能提供该格式接口的本地推理服务（如 Ollama、LM Studio 等）都可以被 WorkBuddy 识别并接入-6。
🛠️ 主流接入方式
| 本地工具 | 说明 | 参考 |
|---|---|---|
| Ollama | 最主流的方式，通过http://localhost:11434/v1接入 | --2 |
| LM Studio | 同样提供 OpenAI 兼容 API，配置方式类似 | -1 |
| vLLM / SGLang | 适合显卡玩家，性能更高 | -18 |
⚙️ 配置步骤（以 Ollama 为例）
第一步：安装 Ollama 并下载模型
访问 ollama.com 下载安装-7，然后在命令行拉取模型（以 qwen3:4b 为例）：
ollama pull qwen3:4b中文用户首选 qwen3:4b（约 2.5GB 内存，8GB 内存可跑），中文理解能力最强-7。
第二步：在 WorkBuddy 中添加自定义模型
打开 WorkBuddy 客户端，点击左下角头像 →设置→模型-7
点击「+ 添加模型」或「配置自定义模型」-6
提供商选择「自定义 / Custom」-6
填写以下参数-2-6：
| 字段 | 填写内容 |
|---|---|
| 接口地址 | http://127.0.0.1:11434/v1/chat/completions |
| API Key | 任意非空字符串即可（如ollama） |
| 模型名称 | 与ollama list输出一致（如qwen3:4b） |
点击保存，模型会出现在 WorkBuddy 的模型选择器列表中，可直接使用-6。
💡 提示：配置信息仅保存在本地
~/.workbuddy/models.json文件中，不上传云端-6-14。
💡 实用建议
组合使用最省积分：本地模型处理日常简单任务（零消耗），云端模型处理复杂推理任务-7
硬件建议：模型大小控制在 GPU 共享内存的 80% 以内，预留 20% 给系统-1
故障排查：若配置后无法使用，检查接口地址是否遗漏
/v1后缀，以及防火墙是否放行 11434 端口-2
配置完成后，你就可以在 WorkBuddy 中自由切换本地模型，实现完全离线的 AI 辅助体验了。
WorkBuddy 默认支持的云端模型
WorkBuddy 默认内置了丰富的云端模型库，覆盖了从日常办公到专业编程等多种场景。根据官方信息，它内置了13 个主流大模型，主要来自混元 (Hunyuan)、DeepSeek、智谱 (GLM)、月之暗面 (Kimi)和MiniMax这五家厂商-。
下面是这些内置模型的清单，以及它们的核心特点和适用场景。
🧠 WorkBuddy 默认支持的云端模型一览
| 模型系列 | 具体模型 | 核心特点与适用场景 | 积分消耗系数 |
|---|---|---|---|
| Auto | Auto | 系统智能调度，根据任务自动选择最合适的模型。如果拿不准用哪个，选它就对了。 | 视调用的具体模型而定-11 |
| 混元 (Hunyuan) | Hy3 (Hy3 preview) | 腾讯自研，限时免费的思考模型，推理能力增强--2。 | 限时免费-11 |
| Hunyuan-2.0-Thinking | 同样是腾讯混元的思考模型，擅长逻辑推理--12。 | 需查看官方文档 | |
| DeepSeek | Deepseek-V4-Flash | 旗舰模型，速度优先，支持 1M 超长上下文，性价比高-11-2。 | x0.06-11 |
| Deepseek-V4-Pro | 旗舰模型，性能优先，同样支持 1M 超长上下文-11。 | x0.16-11 | |
| 智谱 (GLM) | GLM-5.2 | 支持1M 超长上下文，非常擅长处理长文档、长视频等长程任务--11。 | x0.79-11 |
| GLM-5.1 | 能力均衡，适合各类日常使用场景。 | x0.79-11 | |
| GLM-5v-Turbo | 原生多模态模型，支持图片理解。 | x0.95-11 | |
| 月之暗面 (Kimi) | Kimi-K3 | 擅长处理复杂的长程自主任务，前端开发能力突出，在科研推理上表现也很出色--11。 | x1.62-11 |
| Kimi-K2.7-Code | 面向编程场景优化的多模态模型--11。 | x0.57-11 | |
| Kimi-K2.6 | 多模态模型，适合处理各类日常任务-11。 | x0.52-11 | |
| MiniMax | MiniMax-M3 | 原生多模态，在代码编写和智能体任务方面表现优秀--11。 | x0.25-11 |
| MiniMax-M2.7 | 能力均衡，性价比高，适合日常使用--11。 | 需查看官方文档 |
补充说明：
列表中的“积分消耗系数”和“限时免费”信息来自社区分享-11-2，具体政策请以 WorkBuddy 官方最新公告为准。
除上表外，WorkBuddy 早期版本或部分文档中还曾提及
GLM-5.0、GLM-5.0-Turbo、GLM-4.7、MiniMax-M2.5、Kimi-K2.5等模型--12，它们可能已更新为表格中的新版本，使用时请以客户端内实际显示的模型列表为准。
💡 模型选择小贴士
这么多模型，该如何选择？这里有几个简单的原则供你参考：
不确定用哪个：选
Auto，让系统帮你做决定-12。日常任务：追求高性价比选
Deepseek-V4-Flash-2；追求性能均衡选GLM-5.1或MiniMax-M2.7-11。处理超长文档：选
GLM-5.2或Deepseek-V4系列-11。编程开发：优先考虑
Kimi-K2.7-Code-11。需要图片理解：选择带“视觉”标签的模型，如
GLM-5v-Turbo或MiniMax-M3-11。复杂推理任务：选择
Hy3或Hunyuan-2.0-Thinking等思考模型-12。
