Back to Details

review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

review — refute the spec before build

审核——构建前驳斥规格说明书

Every finding cites evidence — file:line or a source. No evidence → flag 
[unverified]
. Default to refuted: a flaw you cannot prove is a flaw you note, not one you wave through.
An LLM cannot self-correct on its own judgment — left alone it drifts or degrades. Review fixes that the only way that works: a separate skeptic anchored to an external oracle — the code, §R, the test suite, the docs. "Looks good" is not a review. A refutation attempt is.
每一项发现都需引用证据——文件:行号或来源。无证据→标记
[unverified]
。默认判定为驳斥：无法证明的缺陷也需记录，而非忽略。
LLM无法仅凭自身判断进行自我修正——放任不管的话，它会偏离方向或性能下降。审核通过唯一有效的方式解决这一问题：一个锚定在外部基准（代码、§R、测试套件、文档）上的独立怀疑者。“看起来不错”不能算作审核。只有尝试驳斥的过程才算。

WHEN TO REVIEW

何时进行审核

  • Before 
    /build
    on a high-blast-radius change (shared module, auth, data, money, public API).
  • Spec touched §I or §V that other code depends on.
  • Right-sizing says the cost of a wrong build > the cost of one review pass.
Skip for a trivial, reversible, well-understood change. Adversarial review on a typo hallucinates flaws & wastes the budget — the self-critique paradox is real.
  • 在对影响范围广的变更（共享模块、权限认证、数据、资金、公开API）执行
    /build
    前。
  • 规格说明书涉及到其他代码依赖的§I或§V时。
  • 权衡判定显示，错误构建的成本高于一次审核的成本时。
对于微小、可回退、理解透彻的变更可跳过审核。对拼写错误进行对抗性审核会凭空捏造缺陷，浪费资源——自我批判悖论确实存在。

PHASE 0 — CAPTURE

阶段0——获取信息

Read the spec: §G §C §I §R §V §T. Hold the whole thing. You review the spec, not your memory of the conversation.
阅读规格说明书：§G §C §I §R §V §T。全面掌握内容。你审核的是规格说明书本身，而非对话记忆。

PHASE 1 — CONSTRUCT THE SENIOR

阶段1——构建资深审核者角色

Build a reviewer with real authority, not a generic critic:
  • Codebase — grep/read the modules this spec touches. What patterns, what invariants already hold?
  • §R — what did research establish? A spec decision that contradicts §R is a finding.
  • Live — for any best-practice claim you are unsure of, fetch it. An out-of-date assumption is a flaw.
A reviewer with no evidence is just an opinion. Earn the authority first.
打造一个具备真正权威性的审核者，而非泛泛的批评者：
  • 代码库——搜索/阅读规格说明书涉及的模块。已有的模式、不变量是什么？
  • §R——研究成果确立了什么？与§R相悖的规格决策属于一项发现。
  • 最新实践——对于任何不确定的最佳实践主张，去查证。过时的假设就是缺陷。
没有证据支撑的审核者只是在发表个人观点。首先要建立权威性。

PHASE 2 — REFUTE

阶段2——驳斥

Attack the spec on these axes. For each, try to find the case where it breaks:
  • Goal vs reality — does §G solve the actual problem, or a proxy?
  • Missing invariant — what can go wrong that no §V catches? (most findings live here)
  • Interface drift — does §I match what callers already expect? (cite the caller, file:line)
  • Constraint conflict — do two §C bullets contradict? does one fight §R?
  • Unowned edge — the input, ordering, failure, or concurrency case no §T covers.
  • Altitude — §T too vague to act on, or so granular it is just typing?
从以下维度攻击规格说明书。针对每个维度，尝试找出其失效的场景：
  • 目标与现实不符——§G是否解决了实际问题，还是只是一个替代指标？
  • 缺失的不变量——有哪些问题是§V未覆盖的？（多数发现出自此处）
  • 接口偏差——§I是否符合调用方的预期？（引用调用方，文件:行号）
  • 约束冲突——两个§C条目是否矛盾？是否与§R冲突？
  • 无人负责的边缘场景——§T未覆盖的输入、顺序、故障或并发场景。
  • 粒度问题——§T过于模糊无法执行，或过于精细只是重复代码？

PHASE 3 — CLASSIFY

阶段3——分类

Each finding: 
evidence → claim → severity
.
  • BLOCK — build on this spec ships a real defect. Must fix first.
  • HARDEN — add/sharpen a §V so the build cannot regress it.
  • NOTE — worth knowing, not blocking.
No evidence? Down-rank to NOTE & tag 
[unverified]
. ⊥ inflate a hunch to BLOCK.
每一项发现需包含：
证据 → 结论 → 严重程度
。
  • 阻止（BLOCK）——基于此规格构建会引入明确缺陷。必须先修复。
  • 强化（HARDEN）——添加/细化§V，确保构建不会出现回归。
  • 备注（NOTE）——值得关注，但不阻止构建。
无证据？降级为备注并标记
[unverified]
。禁止把直觉臆断为阻止项。

PHASE 4 — HARDEN §V & GATE

阶段4——强化§V & 最终决策

  • Each HARDEN finding → a draft §V line (testable, cites the §I/behavior it guards). Hand to spec to write.
  • End on an explicit gate:
undefined
  • 每个强化类发现→一条§V草稿（可测试，注明其保护的§I/行为）。交由规格编写者完成。
  • 最终给出明确的决策：
undefined

review verdict

review verdict

BLOCK: 1 — §I.api shape ≠ caller src/client.ts:40. fix §I before build. HARDEN: 2 — drafted V8 (idempotent refund), V9 (tx around dual write). NOTE: 1 — §T4 vague, split before /build. gate: NO-GO until BLOCK cleared. then /build §T after spec writes V8,V9.

GO or NO-GO, never a shrug. Review is the checkpoint that stops a confident wrong build.
BLOCK: 1 — §I.api shape ≠ caller src/client.ts:40. fix §I before build. HARDEN: 2 — drafted V8 (idempotent refund), V9 (tx around dual write). NOTE: 1 — §T4 vague, split before /build. gate: NO-GO until BLOCK cleared. then /build §T after spec writes V8,V9.

通过或不通过，绝不含糊。审核是阻止盲目错误构建的检查点。

BOUNDARIES

边界限制

  • ⊥ write SPEC.md. Draft §V & hand to spec.
  • ⊥ pass a finding with no evidence as fact. Flag 
    [unverified]
    .
  • ⊥ review trivia. Right-size or skip.
  • ⊥ rewrite the user's intent. You harden the spec, you do not replace its goal.
  • 禁止编写SPEC.md。起草§V并交由规格编写者完成。
  • 禁止将无证据的发现当作事实。标记
    [unverified]
    。
  • 禁止审核琐碎内容。合理判断或跳过。
  • 禁止改写用户意图。你要强化规格说明书，而非替换其目标。