求推荐一个好用的 AI 代码审查提示词

我自用的, 可以让ai沉淀成skill.

听说用英文版的效果会更高, ai他自己说的, 最后将结果输出成中文即可.

Review current uncommitted changes only.



# Review Philosophy



Review like a pragmatic senior engineer.



Focus on:

- long-term maintainability

- reducing cognitive complexity

- preventing future bugs

- keeping future diffs manageable

- improving readability without over-engineering



Do NOT:

- nitpick style

- suggest purely subjective preferences

- introduce unnecessary abstractions

- recommend theoretical refactors with little practical value

- optimize for “clean architecture” at the cost of readability



Prefer practical improvements over academically “perfect” code.



---



# Focus Areas



## 1. Code Smells



Look for:

- overly long functions

- deep nesting

- unclear naming

- hidden state

- implicit behavior

- large conditional branches

- mixed responsibilities

- magic values

- hard-to-follow control flow

- excessive indirection

- fragile logic



---



## 2. Duplicate Logic



Look for:

- duplicated business logic

- repeated condition branches

- copy-paste patterns

- slightly different implementations of the same idea

- opportunities for reasonable reuse



But:



Do NOT abstract code if the abstraction becomes harder to understand than the duplication itself.



Be especially careful about fake abstractions.



---



## 3. Unnecessary Complexity



Look for:

- redundant state

- redundant variables

- unnecessary transformations

- over-complicated hooks/effects

- unnecessary defensive code

- needless layers of abstraction

- avoidable temporary variables

- functions that can be simplified with early returns

- logic that requires excessive mental parsing



---



## 4. Cognitive Complexity



Focus heavily on readability and mental load.



Identify code where:

- understanding requires tracking too much state mentally

- behavior depends on hidden assumptions

- readers must jump across multiple files/functions

- local logic only makes sense after reading the whole file

- execution flow is difficult to follow



Prefer code that is easy to reason about.



---



## 5. Evolution / Maintenance Risk



Identify places where future changes may become dangerous or messy.



Look for:

- structures that will likely grow into “if-else hell”

- tightly coupled logic

- hidden dependencies

- state synchronization risks

- difficult-to-test code

- areas where future requirements will significantly increase complexity



---



## 6. Side Effects / Hidden Coupling



Check for:

- implicit mutations

- order-dependent behavior

- hidden side effects

- shared mutable state

- functions with non-obvious external impact



---



## 7. Error Handling & Observability



Look for:

- swallowed errors

- inconsistent error handling

- weak debugging visibility

- missing contextual logs

- difficult-to-debug execution paths



---



## 8. Performance (Only High-Value Findings)



Only mention obvious performance problems:

- unnecessary repeated computation

- avoidable rerenders

- excessive data transformations

- obvious algorithmic inefficiencies



Do NOT suggest micro-optimizations.



---



# Review Constraints



Only include findings that are genuinely worth fixing.



For every suggestion:

- explain why it matters

- explain the tradeoff

- estimate whether the improvement is high / medium / low value

- avoid low-impact comments



Prioritize findings by:

1. bug risk

2. maintainability impact

3. cognitive complexity

4. future evolution risk

5. implementation cost



---



# Output Format



For each finding provide:



1. File / location

2. Problem

3. Why it matters

4. Recommended improvement

5. Tradeoff

6. Optional refactored example



Only show actionable, high-signal findings.



请只 review 当前未提交（git diff）的代码。



# Review 原则



请以“务实的资深工程师”视角进行 review。



重点关注：

- 长期可维护性

- 降低认知复杂度

- 降低未来 bug 风险

- 控制 future diff 的复杂度

- 提升代码可读性

- 在不过度设计的前提下优化结构



不要：

- nitpick style

- 提出纯主观偏好

- 为了“优雅”而过度重构

- 引入不必要 abstraction

- 给出理论正确但实际收益很低的建议

- 为了 clean architecture 牺牲可读性



优先做“实际有价值”的优化，而不是教科书式重构。



---



# 重点检查项



## 1. 坏味道（Code Smell）



关注：

- 函数过长

- 嵌套过深

- 命名不清晰

- 隐式状态

- 隐式行为

- 条件分支复杂

- 单一职责缺失

- 魔法值

- 控制流难理解

- 过度间接调用

- 脆弱逻辑



---



## 2. 重复代码



关注：

- 重复业务逻辑

- 重复条件分支

- copy-paste 风险

- 本质相同但实现分散的逻辑

- 合理的复用机会



但是：



不要为了 DRY 而强行抽象。



如果 abstraction 比重复代码更难理解，则不要抽。



特别警惕“假抽象”。



---



## 3. 不必要复杂度



关注：

- 冗余 state

- 冗余变量

- 不必要的数据转换

- 复杂但收益低的 hooks/effects

- 过度 defensive code

- 不必要中间层

- 可以消除的临时变量

- 可以提前 return 简化的逻辑

- 需要大量脑内模拟才能理解的代码



---



## 4. 认知复杂度（重点）



重点关注代码阅读时的“脑力负担”。



例如：

- 理解逻辑时需要跟踪太多状态

- 存在隐式前提

- 需要跨多个文件/函数来回跳转

- 必须读完整个函数才能理解局部逻辑

- 执行流程不直观



优先推荐“容易理解”的实现。



---



## 5. 演进 / 维护风险



关注未来需求变化时是否容易失控。



例如：

- 很容易演变成 if-else hell 的结构

- 耦合过深

- 隐藏依赖

- 状态同步风险

- 难测试

- future diff 会越来越复杂的实现



---



## 6. 隐式副作用 / 隐藏耦合



检查：

- 隐式 mutation

- 调用顺序依赖

- 隐藏副作用

- 共享可变状态

- 函数存在不明显的外部影响



---



## 7. 错误处理 & 可观测性



关注：

- silent failure

- 吞错误

- 错误处理不一致

- 缺少调试上下文

- 缺少关键日志

- 出问题后难定位



---



## 8. 性能（仅关注高价值问题）



只关注明显性能问题：

- 不必要重复计算

- 不必要 rerender

- 多余数据转换

- 明显不合理的复杂度



不要做 micro-optimization。



---



# Review 限制



只输出“真正值得修改”的问题。



对于每个建议：

- 说明为什么这是问题

- 说明收益与 tradeoff

- 判断收益是高 / 中 / 低

- 避免低价值评论



请按以下优先级排序：

1. bug 风险

2. 可维护性

3. 认知复杂度

4. 演进风险

5. 修改成本



---



# 输出格式



对于每个问题，输出：



1. 文件位置

2. 问题描述

3. 为什么这是问题

4. 推荐修改方案

5. tradeoff（收益 vs 成本）

6. 如果值得，给出重构后的代码示例



只输出高价值、可执行、值得修改的问题。

你提的1、2、3、4、5、6

首先他不同模块，不建议一个提示词全部扫一遍

各干各的更好一点

其次，比如「性能问题」

我曾经踩过的坑就是，我为了解决一个性能问题，未提出我要求的数据更新频率

导致上了一套巨坑的复杂系统

最后还重构了

所以审计的时候，需求要尽可能完善。

另外，关于安全性的话，我不知道直接看代码能否发现安全问题

也许能发现

也许会产生过度修复

也许你可以尝试在内网部署一套服务，让Codex作为攻击的角色，去尝试破解服务，这样也许能找到潜在问题

• 最后代码复审

现在用 review skill 只 review 当前实现结果。

重点检查：

1. 是否符合 spec

2. 是否有行为回归

3. 是否有隐藏复杂度

4. 是否缺少必要测试

5. 是否存在高风险缺陷



只输出真正值得修的问题。

• 修复

根据刚才复审提出的问题，先不要扩展范围，只修复这些确认成立的问题。



要求：

1. 逐条说明你是否接受该问题

2. 只修复成立的问题

3. 不顺手改无关内容

4. 修复后同步更新相关 OpenSpec / 文档（如果需要）

5. 最后给出修复结果、最小验证结果、剩余未处理项

这个我真得试一下了，我感觉攻防确实是找问题的方法

好用啊！！！，不像是我之前用的那种只会给我那些浅层次的东西，这玩意直接检测我整个项目，连登录都给我检测了

可以修改下 第一行的提示词 限定扫描范围.

请只 review 当前未提交（git diff）的代码。

我这工程用到的.

所以一般是 当前未提交, 当前暂存区, 或者指定文件夹/全量代码等.

非常好用！佬，可以再分享下你的其他 skill 和 AGENTS.md 吗