### [AI 代码评审提示词怎么写：从需求核对到风险清单的实战模板](https://alyyhw.com/article/4682)

**Published:** 2026-07-30T08:18:53

**Author:** AI菜鸟网

**Excerpt:** 用一套可复用的 AI 代码评审提示词，完成需求核对、缺陷排查、测试建议和修复优先级排序。

把代码贴给 AI，再问一句“有没有问题”，通常只能得到零散建议。真正能进入日常开发流程的做法，是先把**评审目标、上下文和输出格式**约定清楚，让每一条建议都能回到具体文件、行号和验证步骤。

![AI 代码评审提示词与检查清单示意图](https://login.alyyhw.com/wp-content/uploads/2026/07/ai-code-review-prompt.jpg)

## 先定义 AI 不该替你做的事

AI 可以帮助发现命名混乱、边界遗漏、异常分支和潜在安全问题；但它不能替代运行测试、阅读业务规则或对线上数据负责。提交前请先删掉密钥、用户隐私和生产配置，并明确它只能基于你提供的上下文判断。

## 评审输入要包含四块信息

| 输入块 | 要写什么 | 作用  |
| --- | --- | --- |
| 目标  | 这段代码要解决的业务问题 | 避免只按语法挑刺 |
| 约束  | 语言、框架、性能或兼容要求 | 让建议符合项目现实 |
| 代码范围 | 文件、函数和调用入口 | 减少脱离上下文的结论 |
| 验收标准 | 必须通过的场景与测试 | 把建议变成可验证任务 |

## 可直接复用的评审提示词

```
你是项目的代码评审协作者。请只基于我提供的需求和代码判断，
不要假设未给出的接口或数据。

评审目标：检查正确性、异常处理、可维护性、性能与安全边界。
输出要求：
1. 先列出你理解的业务规则；
2. 按“高 / 中 / 低”标记问题；
3. 每项说明位置、触发条件、影响和最小修改建议；
4. 给出需要补充的测试用例；
5. 不确定时写“需要确认”，不要编造结论。

需求：
[粘贴业务目标与边界]

代码：
[粘贴最小可评审片段]
```

## 把输出变成真正的修复清单

拿到结果后，先过滤没有定位依据的笼统意见。高优先级问题应当有复现路径；中优先级问题要能对应重构收益；低优先级建议放进技术债列表。每改一项，都让 AI 根据修改后的代码重新检查一次，重点看原问题是否消失、是否引入了新分支。

## 三个容易失效的写法

-   一次贴整个仓库：上下文太杂，结论容易漏掉关键调用链。
-   只问“有没有 bug”：没有验收规则，回答会停留在通用建议。
-   直接采纳补丁：先在本地测试，再由人工确认业务语义和权限边界。

当团队已经有固定规范时，可把命名、日志、错误码和测试要求作为附录加入模板。这样 AI 输出会越来越接近团队的评审语言，而不是每次从零开始。

**Tags:** AI提示词, AI编程

**Categories:** AI编程

---