Back to Details

evanflow-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

EvanFlow: Review

EvanFlow：评审

Vocabulary

术语说明

See 
evanflow
meta-skill.
参见
evanflow
元技能。

When to Use

使用场景

  • Completed work, want a review pass before integration
  • Reviewing someone else's PR
  • Received review feedback and need to process it (especially if you disagree)
  • 已完成工作，希望在集成前进行一轮评审
  • 评审他人的PR
  • 收到评审反馈并需要处理（尤其是当你持不同意见时）

Two Halves

两大环节

A. Requesting Review (giving work to be reviewed)

A. 请求评审（提交待评审工作）

1. Self-review first

1. 先进行自我评审

Before asking anyone to look:
  • Run the project's quality checks (
    tsc
    , 
    lint
    , 
    test
    )
  • Re-read the diff with fresh eyes
  • Check the diff matches the spec/plan — no scope creep
  • Look for: leftover console.logs, commented-out code, unused imports, secrets accidentally committed
  • Apply the deletion test to new modules: do they earn their existence?
在请求他人查看之前：
  • 运行项目的质量检查（
    tsc
    、
    lint
    、
    test
    ）
  • 以全新视角重新阅读代码差异
  • 检查代码差异是否符合需求规格/计划——无范围蔓延
  • 留意：遗留的console.logs、注释掉的代码、未使用的导入、意外提交的机密信息
  • 对新模块应用删除测试：它们是否有存在的必要？

2. Frame the review request

2. 构建评审请求

State explicitly:
  • Goal: what behavior changed
  • Approach: why this approach (link to spec/plan)
  • Risk areas: where you most want a critical eye
  • Verification done: what you tested locally; what's untested
  • Open questions: things you're unsure about
A reviewer can't help you find what you didn't flag.
明确说明：
  • 目标：哪些行为发生了变化
  • 方法：为何采用此方法（链接至需求规格/计划）
  • 风险区域：你最希望得到严格审视的地方
  • 已完成的验证：你在本地测试了什么；哪些未测试
  • 待解决问题：你不确定的事项
评审者无法帮你找出你未指出的问题。

B. Receiving Review

B. 接收评审反馈

1. Read all feedback first

1. 先阅读所有反馈

Don't start fixing the first comment until you've read every comment. Patterns matter — three comments on similar code might mean a structural issue, not three separate fixes.
在开始修复第一条评论前，先读完所有评论。模式很重要——针对相似代码的三条评论可能意味着结构性问题，而非三个独立的修复点。

2. Embedded Grill — Challenge feedback you disagree with

2. 深入质疑——挑战你不同意的反馈

For any feedback that feels wrong:
  • "Is the reviewer working from a wrong assumption? What context might they be missing?"
  • "Does the project's CLAUDE.md or 
    docs/adr/
    already address this?"
  • "Would the suggested change make a different test pass that currently doesn't exist?"
  • "Is this a stylistic preference or a correctness issue?"
If after grilling you still disagree, respond with reasoning, not capitulation. Performative agreement that ships bad code is worse than respectful disagreement.
对于任何你认为有误的反馈：
  • “评审者是否基于错误假设？他们可能缺少哪些上下文？”
  • “项目的CLAUDE.md或
    docs/adr/
    是否已解决此问题？”
  • “建议的更改是否能让当前未通过的某个测试通过？”
  • “这是风格偏好还是正确性问题？”
如果质疑后你仍然不同意，请给出理由而非妥协。表面认同却交付糟糕代码比有理有据的分歧更糟。

3. Group changes

3. 分组更改

Batch similar feedback into single edits. Don't make 17 separate one-line changes.
将相似的反馈批量处理为单次编辑。不要进行17次独立的单行更改。

4. Verify after each batch

4. 每批更改后验证

Run the quality checks. Don't push a "review fixes" commit that breaks the build.
运行质量检查。不要推送会破坏构建的“评审修复”提交。

Hard Rules

硬性规则

  • Verify before claiming a fix is done. Run the test that the reviewer flagged.
  • Don't capitulate to feedback you can't justify. If you can't articulate WHY the change is right, don't make it.
  • Don't agree-and-defer. "Good catch, will fix later" with no follow-up is debt.
  • Never auto-commit, never auto-stage, never auto-finish. When review fixes are done, report what was done and STOP. The user decides when to commit.
  • 在声称修复完成前先验证。运行评审者指出的测试。
  • 不要妥协于你无法证明合理性的反馈。如果你无法阐明更改为何正确，就不要进行更改。
  • 不要口头同意却拖延。“好发现，稍后修复”却没有后续跟进就是技术债务。
  • 永远不要自动提交、自动暂存、自动完成。评审修复完成后，报告已完成的工作并停止。由用户决定何时提交。

Hand-offs

后续处理

  • Review accepted, changes complete → report what was done and STOP. Await user direction.
  • Review surfaced a deeper issue → 
    evanflow-improve-architecture
    or 
    evanflow-debug
  • Review surfaced wrong assumptions about intent → 
    evanflow-brainstorming
    to realign
  • 评审通过，更改完成 → 报告已完成的工作并停止。等待用户指示。
  • 评审发现更深层次的问题 → 
    evanflow-improve-architecture
    或 
    evanflow-debug
  • 评审发现对意图的错误假设 → 
    evanflow-brainstorming
    重新对齐