用OpenCode做Code Review的几个技巧和模板示例（19）

内容分享3小时前发布

0 0 0

全能 AI 聚合平台免费

一站式接入主流 AI 大模型，支持对话 · 生图 · 生视频，即开即用

ChatGPT Claude Gemini Grok DeepSeek 通义千问 Ollama

AI对话 AI生图 AI视频

免费使用 →

用OpenCode做Code Review：效率提升3倍的技巧

AI编程工具的确让写代码变快了。一个任务以前干一天，目前可能两小时就写完了。

但问题来了——你写得快了，review的负担可没变轻。

以前一天出一个PR，目前一天能出三个。代码量翻倍，review时间却还是那些。更糟糕的是，AI生成的代码有时候看起来很美，但细节经不起推敲——边界条件没处理、命名自相矛盾、注释和实现对不上。

所以我的观点是：用AI写代码，用另一个AI来审核，这个思路没问题。但最后必定需要人工把关。AI能扫出风格问题、扫出潜在bug，但架构怎么选、业务这样设计合不合理、这个技术债值不值得目前还——这些没有标准答案的事，必须人来拍板。

AI做前哨，人工做守门员。这才是健康的流程。

今天就讲讲怎么用OpenCode的Plan模式，做高效有质量的Code Review。

用OpenCode做Code Review的几个技巧和模板示例（19）

为什么OpenCode天然适合Code Review

许多人用OpenCode来写代码，实则它的Plan模式天然适合做Code Review。

先说第一个特点：只读不改。Plan模式的设计就是”只读不写”，AI不会由于理解偏差改坏你的代码。你可以放心让它扫描全库，不会产生任何副作用。

第二个特点是全局视角。人工review往往是增量视角——这个PR改了什么。但AI可以看到完整上下文——这个改动影响了什么。跨文件的逻辑问题，业务流程的一致性问题，人工容易遗漏，AI不容易。

第三个是一致性。你第一次说”变量命名要清晰”，第100次还是这个标准。不会由于心情不好就放过一个混命名，也不会由于太累了就开始抠格式细节。

第四个是速度。300行代码，人工review大约需要15到20分钟。AI可以在30秒内完成基础扫描，剩下的时间你专注在高价值的架构讨论和业务逻辑审核上。

标准Code Review流程

用OpenCode做Code Review，核心流程分五步：

第一步，切换到Plan模式。按Tab键或输入/plan，确保AI只读不改。

第二步，提供审查范围。你可以直接粘贴PR链接，也可以用@引用改动的文件，或者直接描述审查重点。

第三步，AI做分层扫描。这里分为四层：

安全层检查注入、越权、敏感信息。逻辑层检查空指针、边界条件、异常处理。风格层检查命名、注释、格式化。性能层检查循环、查询、缓存。

第四步，汇总问题，生成审查报告。第五步，人工复核，确认真正需要关注的问题。

整个流程下来，你从”大海捞针”变成了”按图索骥”。

五个高效提示词模板

光讲流程不够，你肯定想要直接能用的模板。我给你五个场景的提示词，拿去就能用。

第一个模板是安全漏洞扫描，适用于你怀疑代码可能有安全隐患的时候。

请在Plan模式下审查这个PR的安全性：
@src/api/user.ts
@src/api/order.ts

重点检查：
1. 是否有SQL注入风险（拼接查询、参数未校验）
2. 是否有越权漏洞（用户A能否访问用户B的数据）
3. 是否有敏感信息泄露（密码、日志、token打印）
4. 是否有文件上传漏洞（路径遍历、类型校验）

第二个模板是业务逻辑检查，适用于PR涉及核心业务逻辑的时候。

请审查这个PR的业务逻辑：
@src/services/order.ts

检查要点：
1. 订单状态流转是否完整（创建→支付→发货→完成/撤销）
2. 边界条件处理（库存为0、超时、重复下单）
3. 异常情况处理（支付失败、退款逻辑）
4. 数据一致性（库存、余额、订单状态的同步）

第三个模板是性能问题识别，适用于涉及数据库查询或者有性能担忧的时候。

请分析这个PR的性能影响：
@src/routes/*.ts

关注点：
1. 是否有N+1查询问题（循环内查数据库）
2. 是否有不必要的全表扫描
3. 是否有大对象未释放（内存泄漏）
4. 是否有同步阻塞主线程的操作
5. 缓存使用是否合理

第四个模板是代码风格一致性，适用于新人PR或者团队规范需要统一的时候。

请检查这个PR是否符合团队的代码规范：
@src/utils/helper.ts

规范检查：
1. 命名是否与现有代码一致（camelCase vs snake_case）
2. 错误处理方式是否统一（throw vs callback vs Promise.reject）
3. 注释风格是否匹配
4. 是否有明显的重复代码可以抽取

第五个模板是测试覆盖率评估，适用于需要评估测试质量的时候。

请评估这个PR的测试质量：
@src/hooks/useAuth.ts
@tests/hooks/useAuth.test.ts

检查项：
1. 核心逻辑是否都有测试覆盖
2. 边界条件是否测试（空值、异常值）
3. 测试用例描述是否清晰
4. 是否有遗漏的测试场景

这五个模板覆盖了Code Review最常见的场景。你不需要每次都全部检查，根据PR的性质选择合适的模板就好。

团队协作技巧

一个人用叫效率提升，团队都在用才叫真正的生产力飞跃。

第一是审查结果的导出。让AI生成Markdown格式的报告，直接复制到PR评论区。格式大致是这样：

## AI Code Review 报告

###  严重问题（需修复后合并）
- [ ] L47: 潜在空指针风险，提议增加判空
- [ ] L112: SQL参数未校验，有注入风险

###  提议优化
- [ ] L89: 变量命名不够清晰，提议改为 userId
- [ ] L203: 魔法数字提议提取为常量

###  代码亮点
- L123: 异常处理逻辑很完善
- L267: 缓存策略使用得当

这样reviewer只需要看报告就知道重点在哪里，不用自己再翻一遍代码。

然后是明确AI和人工的分工。AI负责格式检查、风格扫描、安全漏洞识别、明显的bug。这些机械性的工作交给AI，把人的精力解放出来。

人工负责什么呢？架构设计的合理性、业务逻辑的正确性、团队规范的灵活应用、代码评审的最终决策。

最后，提议团队沉淀自己的审查清单。不同类型的项目用不同的模板。前端项目可以加一个UI一致性检查，后端服务可以加一个接口规范检查。把这些模板沉淀成团队文档，新人来了也能快速上手。

用OpenCode做Code Review的几个技巧和模板示例（19）