Cursor · Practical Tutorial

Run Cursor Agent Review before you commit local changes

Review your whole local diff against the base branch, choose quick or deep review deliberately, fix only confirmed findings and rerun the review.

Reviewed September 20, 2026Independent tutorialFeatures may vary

Not official support. AI Learn is an independent education site. Check the provider’s current documentation for plan-specific limits, pricing and feature availability.

Before you start

Agent Review is a second-pass reviewer, not a substitute for tests or human judgment. It is most useful after the code works and before you commit, when the diff is still small enough to understand.

1. Clean up unrelated local changes so the review scope is meaningful

Clean the working tree so the review contains only changes that belong to one logical task. Unrelated generated files and formatting noise make findings harder to trust and increase the chance of reviewing the wrong behavior.

2. Choose Quick for small low-risk diffs or Deep for complex/security-sensitive changes

Use Quick Review for small, low-risk diffs and Deep Review for changes with cross-file behavior, security implications or subtle regressions. Review depth should follow risk, not habit.

3. Run Agent Review across the intended local diff or base-branch comparison

Choose the intended comparison—working changes, a commit or a base branch—and read the summary first. Confirm the reviewer is looking at the same scope you plan to commit or open as a PR.

4. Validate each finding against code and tests before accepting a fix

For every high-severity finding, open the cited lines and reproduce the scenario with a test or a concrete execution path. Treat the reviewer as a hypothesis generator, not an authority that automatically rewrites code.

5. Apply confirmed fixes, rerun tests and review once more before commit

Apply only confirmed fixes, run the project test suite and review the new diff again. This second pass is important because a review-driven fix can introduce a different regression.

Try this prompt

Review my current branch against [base branch]. Focus on correctness, regressions, security boundaries and missing tests. Rank findings by impact. Do not modify files during the first pass. For each finding, point to the exact code path and explain a minimal verification step.

Common mistakes

Reviewing a dirty working tree full of unrelated changes; treating every AI finding as true; running Deep on trivial formatting noise; applying fixes before reading the explanation; skipping tests after review fixes.

Finish check

You understand every remaining diff, every accepted finding was verified, tests still pass, and the commit contains only the intended behavior change.

开始之前

Agent Review 是第二道代码审查，不是测试和人工判断的替代品。最适合在代码已经能跑、准备提交之前使用，此时 diff 还足够小，能逐项理解。

1. 先清理和本任务无关的本地修改，让审查范围有意义

先清理 Working Tree，让一次 Review 只包含一个逻辑任务的修改。无关生成文件和格式化噪声会降低发现项的可信度，也容易让 Reviewer 看错真正要提交的行为。

2. 小型低风险改动用 Quick；复杂逻辑或安全敏感改动用 Deep

小而低风险的 Diff 用 Quick Review；跨文件行为、安全敏感或容易产生隐性回归的修改用 Deep Review。Review 深度应该跟风险走，而不是固定一种模式。

3. 针对目标本地 diff 或基准分支比较执行 Agent Review

明确比较范围：当前改动、某个 Commit，还是相对 Base Branch。先看 Review 摘要，确认它审的范围和你准备提交或开 PR 的范围完全一致。

4. 每个发现都要回到代码和测试验证，再决定是否修复

每个高严重度 Finding 都要打开对应行，并通过测试或明确执行路径复现。把 Reviewer 当成“提出可验证假设”的工具，而不是自动替你改代码的权威。

5. 处理已确认问题后重新跑测试，再审查一次再提交

只修确认过的问题，运行项目测试，然后对新 Diff 再 Review 一次。第二轮很重要，因为“为了修 Review 发现的问题”本身也可能引入新的回归。

可以直接套用的提示词

审查当前分支相对 [base branch] 的改动。重点看正确性、回归、安全边界和缺失测试。按影响排序。第一轮不要改文件；每条发现都指向具体代码路径，并给出一个最小验证方法。

常见错误

工作区混着大量无关改动也直接审查；把所有 AI 发现都当成真的；格式小改也用 Deep；没读懂理由就自动修复；审查修复后不重新测试。

完成检查

你能解释剩下的每一处 diff，采纳的发现都经过验证，测试仍然通过，而且提交只包含目标行为变化。

開始之前

Agent Review 是第二道程式碼審查，不是測試和人工判斷的替代品。最適合在程式碼已經能跑、準備提交之前使用，此時 diff 還足夠小，能逐項理解。

1. 先清理和本任務無關的本地修改，讓審查範圍有意義

先清理 Working Tree，讓一次 Review 只包含一個邏輯任務的修改。無關生成檔案和格式化噪聲會降低發現項的可信度，也容易讓 Reviewer 看錯真正要提交的行為。

2. 小型低風險改動用 Quick；複雜邏輯或安全敏感改動用 Deep

小而低風險的 Diff 用 Quick Review；跨檔案行為、安全敏感或容易產生隱性回歸的修改用 Deep Review。Review 深度應該跟風險走，而不是固定一種模式。

3. 針對目標本地 diff 或基準分支比較執行 Agent Review

明確比較範圍：當前改動、某個 Commit，還是相對 Base Branch。先看 Review 摘要，確認它審的範圍和你準備提交或開 PR 的範圍完全一致。

4. 每個發現都要回到程式碼和測試驗證，再決定是否修復

每個高嚴重度 Finding 都要打開對應行，並通過測試或明確執行路徑復現。把 Reviewer 當成“提出可驗證假設”的工具，而不是自動替你改代碼的權威。

5. 處理已確認問題後重新跑測試，再審查一次再提交

只修確認過的問題，運行項目測試，然後對新 Diff 再 Review 一次。第二輪很重要，因為“為了修 Review 發現的問題”本身也可能引入新的回歸。

可以直接套用的提示詞

審查當前分支相對 [base branch] 的改動。重點看正確性、回歸、安全邊界和缺失測試。按影響排序。第一輪不要改檔案；每條發現都指向具體程式碼路徑，並給出一個最小驗證方法。

常見錯誤

工作區混著大量無關改動也直接審查；把所有 AI 發現都當成真的；格式小改也用 Deep；沒讀懂理由就自動修復；審查修復後不重新測試。

完成檢查

你能解釋剩下的每一處 diff，採納的發現都經過驗證，測試仍然通過，而且提交只包含目標行為變化。

Official references

Check current product details at the source

Cursor Docs: Agent Review↗