团队中最危险的代码，往往并非那些写得杂乱无章的片段，而是 AI 审阅后一本正经地给出“整体结构清晰”的评价。当你让它“帮我看看这段代码”，它大概率像年会主持人一样，先夸三句才轻轻点出问题。一旦上线报错，责任依然落在开发者肩上——AI 不会陪你参加事故复盘会。

这个话题近期尤其值得重新探讨。2026 年 5 月 28 日，Anthropic 官方发布了 Claude Opus 4.8，重点强化了编码、Agentic 任务和专业知识工作能力；紧接着 5 月 29 日，OpenAI 在 Enterprise/Edu 更新中，将 Codex、Workspace Agents、GitHub Enterprise 等能力继续推向企业工作流。模型越来越像一个“能干活的同事”，但随之而来的问题是：你不能再用对待搜索引擎的方式敷衍它了。你需要像带新人一样，给标准、给边界、给交付物。

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

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

为什么要设置这样一个“看起来很高调”的角色？这并非虚荣，而是锚点。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 漏掉安全问题，还是担心它给出一堆看似专业的无效建议？