团队里最危险的代码，不是写得丑的代码，而是 AI 一本正经地说“整体结构清晰”的代码。你让它“帮我看看”，它多半像年会主持人，先夸你三句，再轻轻摸一下问题。上线之后报错，锅还是开发背，AI 不会陪你开事故复盘会。

这事最近更值得聊。Anthropic 在 2026 年 5 月 28 日官方发布 Claude Opus 4.8，重点强调编码、Agentic 任务和专业知识工作能力；OpenAI 在 5 月 29 日的 Enterprise/Edu 更新里，也把 Codex、Workspace Agents、GitHub Enterprise 等能力继续往企业工作流里推进。模型越来越像“能干活的同事”，可问题也来了：你不能再把它当搜索框哄着用。你要像带新人一样，给标准、给边界、给交付物。

代码审查提示词的核心，不是把需求写成长作文，而是把审查标准压成一把锋利的尺子。

我建议直接用这套结构：

Role: Google Staff Engineer Level 的系统架构师Task: 请按生产级代码审查标准审查下面的代码Constraints:- 直言指出安全、性能、可读性、错误处理、可扩展性问题- 按 Design for Failure 和 Scalability 原则判断- 不只给建议，必须给可运行的重构版本- 标出风险等级：P0/P1/P2/P3Format:- 先列问题，再给原因，再给修改代码- 用 Markdown 输出- 涉及架构流转时使用 MermaidInput: 粘贴代码

为什么要把 Role 写得这么“装”？因为这不是装，是锚点。AI 不是人类同事，不会因为你说“专业一点”就自动知道你要什么。“Google Staff Engineer Level”这种高密度标签，就像你在会议室里喊了一句“按线上事故标准看”，模型会马上把注意力转向稳定性、边界条件、并发、可维护性这些方向。

 

普通提示词像“帮我看看这段代码有没有问题”。这句话的问题是太客气，客气到模型都不好意思批评你。工程世界里，客气不能防止空指针，温柔不能拦住 SQL 注入。你必须写清楚：请直言不讳，重点扫描安全漏洞、性能瓶颈、错误处理缺失、耦合过高。

这里有个很关键的点：约束比描述更重要。

不要花 500 字解释“我希望代码更好、更优雅、更健壮”。这话听起来很舒服，实际等于没说。你应该写：“拒绝只给理论建议，必须给 Production-Ready 重构代码。”这句话一下子把 AI 从评论区网友，拉回到交付现场。

我见过很多团队用 AI Review，容易变成“生成一份看起来很专业的废话”。比如它说“建议增强错误处理”。怎么增强？在哪里增强？会不会改变接口行为？有没有测试？一句没说。这种建议放进周报可以，放进生产系统不行。

更好的写法是要求三件事：问题定位、风险解释、修改方案。

问题定位，就是指出哪段代码危险。风险解释，是把“可能有问题”翻译成业务后果，比如“这里没有重试，支付回调抖动时会造成状态不一致”。修改方案，则要求它给出完整代码，不要伪代码。伪代码是技术会议里的塑料水果，看着像，吃不了。

 

如果你让 AI 先写代码，再让它审查自己，可以加一句：

Critique yourself: 写完后，请从安全、性能、边界条件三个角度审查你自己的代码，并修复问题。

这句话很好用。它相当于让同一个人先当开发，再换帽子当 Reviewer。虽然不能替代人工审查，但能提前筛掉一批明显问题。尤其是接口参数校验、异常兜底、重复逻辑、日志缺失这类低级坑，AI 自查通常能抓出来。

当然，别把 AI Code Review 神化。它不是“架构委员会成精”，它更像一个不知疲倦的初审同事。它能帮你扫一遍地面上的坑，但业务语义、权限边界、灰度策略、历史债务，仍然需要人拍板。

真正靠谱的用法，是把 AI 放在人工审查前面。让它先按固定标准打底，把低级问题拦住，人再集中精力看设计取舍和业务风险。这样 Review 才不是“多一个工具，多一层流程”，而是把人的注意力从琐碎里解放出来。

以后模型会越来越会写代码，甚至能开 PR、跑测试、修 Bug。但越是这样，审查提示词越不能随便写。你给它模糊指令，它就交付模糊结果；你给它生产标准，它才有机会像工程师一样工作。

AI 写代码的时代，提示词不是聊天话术，而是团队工程规范的一部分。

讨论：

---

1.你们团队现在会让 AI 参与 Code Review 吗？

2.你更担心 AI 漏掉安全问题，还是担心它给出一堆看似专业的无效建议？