Back to Details

pre-flight

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Pre-production code review

预生产代码审查

Look for reasons this branch should not ship. Verify each finding before giving a verdict.
寻找该分支不应发布的理由。给出结论前需验证每一项发现。

Phase 1: Pin the healthy point

阶段1：锁定健康基准点

The user gives you the healthy point: a commit 
SHA
, 
branch
, 
tag
, 
main
, 
HEAD~5
, anything naming a moment when the app worked (production). If they didn't specify one, use 
main
.
Before going further:
  1. Confirm it resolves: 
    git rev-parse <healthy-point>
    .
  2. Write the diff command once and reuse it everywhere: 
    git diff <healthy-point>...HEAD
    . Three dots, so git compares against the merge-base.
  3. Confirm the diff is non-empty. A bad ref or empty diff should fail here, not mid-review.
用户会提供健康基准点：可以是提交
SHA
、
branch
、
tag
、
main
、
HEAD~5
等任何代表应用正常运行时刻（生产环境状态）的标识。如果用户未指定，则使用
main
分支。
继续下一步前，请完成：
  1. 确认基准点可解析：
    git rev-parse <healthy-point>
    。
  2. 编写一次diff命令并复用：
    git diff <healthy-point>...HEAD
    。使用三个点，让git基于合并基准进行对比。
  3. 确认diff内容非空。无效引用或空diff应在此阶段终止审查，而非中途失败。

Phase 2: Read the diff and its context

阶段2：阅读diff及上下文

  1. Run the captured diff command for the full changeset.
  2. For every changed file, read enough surrounding code to understand the original contract and what changed.
  3. Check related code for auth, data models, API contracts, config, migrations, shared utilities, error handling, and logging.
  4. If something is unclear, inspect the codebase before asking a question. Ask only when the code cannot answer it.
  1. 执行已确定的diff命令获取完整变更集。
  2. 对于每个变更文件，阅读足够的周边代码以理解原有约定及变更内容。
  3. 检查相关代码的权限控制、数据模型、API约定、配置、迁移脚本、共享工具、错误处理及日志记录。
  4. 若有内容不明确，先检查代码库再提问。仅当代码无法解答时才发起询问。

Phase 3: Classify the risks

阶段3：风险分类

Give every change one label:
LabelMeaning
🔴 BreakingChanges observable behavior or an API contract
🟡 IncompleteCovers only the happy path, or leaves TODOs or dead branches
🟠 ConflictContradicts the system spec or project conventions
🟢 SafeHas no side effects outside its module
为每一项变更标注一个标签：
标签含义
🔴 Breaking变更可观测行为或API约定
🟡 Incomplete仅覆盖正常流程，或遗留TODO注释、无效分支
🟠 Conflict与系统规范或项目约定冲突
🟢 Safe变更仅在自身模块内，无外部副作用

Phase 4: Adversarial Interview

阶段4：反向质询

Work through every implicit decision, unclear behavior, and non-obvious tradeoff in the diff.
  • One question at a time; wait for a response before continuing.
  • Include your recommended answer with each question.
  • Resolve dependencies in order.
  • Check the codebase before asking. Only raise questions the code cannot answer.
  • Stop when no implicit assumptions remain.
梳理diff中所有隐含决策、不明确行为及非显而易见的权衡点。
  • 一次提出一个问题；得到回复后再继续。
  • 每个问题附上你的建议答案。
  • 按依赖顺序逐一解决。
  • 提问前先检查代码库。仅提出代码无法解答的问题。
  • 当无隐含假设遗留时停止。

Phase 5: Decide whether it ships (Go / No-Go)

阶段5：决定是否发布（发布/不发布）

Only after all Phase 4 questions are resolved.
  • ✅ SHIP. Every risk is safe 🟢, or every finding has a confirmed fix in this branch.
  • ❌ DO NOT SHIP. List every blocking action. Include the file path, line number, and relevant snippet for each item.
仅在阶段4的所有问题解决后进行。
  • ✅ 发布。所有风险均为安全🟢级别，或每一项问题都已在当前分支中确认修复。
  • ❌ 不发布。列出所有阻塞项，包含每个项的文件路径、行号及相关代码片段。