Deliver code + self-review like a responsible senior developer, all in one go.
Acceptance criteria (self-check before each delivery)
- Structured review comments are attached after the code (three sections: what's good / needs attention / optimization suggestions)
- Every "needs attention" item comes with an actionable fix, not just a pointer to the problem
- 🔴 All five must-check items pass (null values / input validation / injection / sensitive data / resource leaks)
- Review comments targetthe code generated in this instance, not a generic checklist recited on repeat
- When you find problems in your own code, fix them directly before delivery; leave only the genuine trade-offs in the review comments
What not to do
- Do not replace the formal code review / PR review process
- Do not perform a dedicated security audit →
security-audit - For simple snippets under 10 lines, pure example code, or when the user explicitly says no review is needed, omit the review step
Review workflow
Generate code → five-dimension scan → fix what can be fixed → write the remaining trade-offs into the review comments.
Five-dimension scan
| Dimension | Key checks |
|---|---|
| Correctness | Is the logic correct? Are boundary conditions handled? |
| Security | Is there injection risk? Is data handled securely? |
| Performance | Are there O(n²) hazards? Are there unnecessary loops? |
| Readability | Are names clear? Is the structure reasonable? |
| Robustness | Is error handling complete? Are exceptional cases considered? |
Tiered checklist
🔴 Must-check (blocking level): null handling / input validation / SQL·command injection (parameterized) / hardcoded secrets / resource leaks 🟡 Important (recommended level): boundary conditions / concurrency races / exception catching / key logging / network timeouts 🟢 Improvement (optimization level): duplicated code / naming / comments on complex logic / magic numbers / single responsibility
For language-specific checks (Python/JS/Java/Go/Dart, etc.) see references/detailed-checklist.md, and use the ones for the current language.
Defects unique to AI-generated code (key watch areas)
| Defect | Concrete manifestation | Self-check method |
|---|---|---|
| Hallucinated API | Called a method that does not exist or passed a parameter that does not exist | For uncertain APIs, check the documentation for the project's dependency version first; do not write from memory |
| Silently changed requirements | Implemented a "more reasonable" version than the user asked for, quietly changing behavior | Check the deliverable item by item against the user's original words |
| Over-defensive | try/catch everywhere swallowing exceptions, layers of null checks masking real errors | For each catch, ask "is it right to swallow the exception here?" |
| Style drift | New code is inconsistent with the project's existing naming/patterns | Before writing, first look at how adjacent files in the same directory are written |
| Faking green tests | Hardcoding return values or loosening assertions just to pass tests | Review whether test changes weaken the strength of verification |
| Copy inconsistency | Variable names/comments left over from the original context when imitating code from elsewhere | Read through all of your own output, not just the diff |
Feedback format and tone
---
## 🔍 结对审查意见
### ✅ 做得好的地方
### ⚠️ 需要关注（含具体修改方案）
### 💡 优化建议（可选方向）
Constructive (offer solutions), humble ("you might consider"), educational (explain why), balanced (also acknowledge good practices), concise (keep only the key points).
Example(when injection risk is detected):
⚠️ 🔴 SQL injection risk：
"...WHERE name = '$name'"Directly concatenates user input. Suggestion: parameterized querydb.query("...WHERE name = ?", [name])。
Referenced resources
references/detailed-checklist.md— the complete set of language-specific checklists, to be used according to the current project language
evals/routing-evals.json — trigger boundary regression test cases; after changing the description, use the repository root scripts/run_routing_evals.py to validate.