Back to Details

check

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Check: Review Before You Ship

检查清单：发布前评审

Read the diff, find the problems, fix what can be fixed safely, ask about the rest. Do not claim done until verification has run in this session.
阅读diff，找出问题，修复可安全修改的内容，其余问题咨询相关人员。在本次会话中完成验证前，不得宣称任务完成。

Get the Diff

获取Diff

bash
git fetch origin
git diff origin/main
If the base branch is not 
main
, ask before running. Already on the base branch? Stop and ask which commits to review.
bash
git fetch origin
git diff origin/main
如果基分支不是
main
，运行前请先咨询。已经在基分支上？停止操作，咨询需要评审哪些提交。

Did We Build What Was Asked?

我们是否实现了需求？

Before reading the code, check for scope drift:
  • Pull up recent commit messages and any task files
  • Does the diff match the stated goal? Flag anything outside that scope: unrelated files, voluntary additions, missing requirements
  • Label it: on target / drift / incomplete and note it, but do not block on it
在阅读代码前，先检查是否存在范围漂移：
  • 调出最近的提交信息和所有任务相关文件
  • Diff与既定目标是否匹配？标记所有超出范围的内容：无关文件、主动新增的非需求内容、缺失的需求项
  • 标记为：符合目标 / 范围漂移 / 未完成并备注，但不要因此阻塞流程

What to Look For

需要检查的内容

Hard stops (fix before merging)

硬阻断问题（合并前必须修复）

These are not negotiable:
  • Destructive auto-execution: any task flagged as "safe" or "auto-run" that modifies user-visible state (history files, config files, stored preferences, installed software, cache entries the user can inspect) must require explicit confirmation. "Safe" means no side effects, not "probably harmless." If a task deletes or rewrites something the user can see, it is not safe by default.
  • Release artifacts missing: a GitHub release with an empty body, missing assets, or unuploaded build files is not a completed release. Verify every artifact listed in the release template exists as a local file and has been uploaded before declaring done.
  • Translated file naming collision: when placing a file in a language-specific directory (e.g., 
    _posts_en/
    , 
    en/
    ), the file name must not repeat the language suffix. Check the naming convention of existing files in the same directory first.
  • GitHub issue or PR number mismatch: before commenting on, closing, or acting on a GitHub issue or PR, verify the number matches the one discussed in this session. Do not rely on memory. Run 
    gh issue view N
    or 
    gh pr view N
    to confirm the title matches before writing.
  • GitHub comment style: PR review comments and issue replies must be brief (1-2 sentences), natural-sounding, and friendly. Not verbose. Not formatted like a report. Not AI-sounding. If a comment needs more than 2 sentences, it should be structured as a list, not a paragraph.
  • Injection and validation: SQL, command, path injection; inputs that bypass validation at system entry points
  • Shared state: unsynchronized writes, check-then-act races, missing locks
  • External trust: output from LLMs, APIs, or user input fed into commands or queries without sanitization; credentials hardcoded or logged
  • Missing cases: enum or match exhaustiveness; use grep on sibling values outside the diff to confirm
  • Dependency changes: unexpected additions or version bumps in 
    package.json
    , 
    Cargo.toml
    , 
    go.mod
    , or 
    requirements.txt
    . Flag any new dependency not obviously required by the diff.
以下问题无协商空间：
  • 破坏性自动执行：任何标记为「安全」或「自动运行」的任务如果会修改用户可见状态（历史文件、配置文件、存储的偏好设置、已安装软件、用户可查看的缓存条目），必须要求用户显式确认。「安全」指无副作用，而非「可能无害」。如果任务会删除或改写用户可见的内容，默认不属于安全范畴。
  • 缺失发布产物：GitHub Release正文为空、缺失资源、未上传构建文件都不属于完成发布。在宣称完成前，需验证发布模板中列出的所有产物都已生成本地文件且已成功上传。
  • 翻译文件命名冲突：将文件放入特定语言目录（例如
    _posts_en/
    、
    en/
    ）时，文件名不得重复携带语言后缀。请先参考同目录下已有文件的命名规范。
  • GitHub Issue或PR编号不匹配：在评论、关闭或操作GitHub Issue/PR前，需验证编号与本次会话讨论的编号一致。不要依赖记忆，操作前请运行
    gh issue view N
    或
    gh pr view N
    确认标题匹配。
  • GitHub评论规范：PR评审评论和Issue回复需简洁（1-2句话）、自然友好。不要冗长，不要写成报告格式，不要有AI生成感。如果评论需要超过2句话，应使用列表结构而非段落。
  • 注入与校验问题：SQL、命令、路径注入；系统入口处绕过校验的输入
  • 共享状态问题：未同步的写操作、检查后执行的竞态条件、缺失锁
  • 外部信任问题：LLM、API输出或用户输入未经过清洗就传入命令或查询；硬编码或日志中泄露凭证
  • 缺失分支处理：枚举或match语句未覆盖所有情况；可通过grep搜索diff外的同类型值确认
  • 依赖变更问题：
    package.json
    、
    Cargo.toml
    、
    go.mod
    、
    requirements.txt
    中出现意外的新增依赖或版本升级。标记所有不是diff明确需要的新增依赖。

Soft signals (flag, do not block)

软提示（仅标记，不阻塞合并）

Worth noting but not merge-blocking:
  • Side effects that are not obvious from the function signature
  • Magic literals that should be named constants
  • Dead code, stale comments, style gaps relative to the surrounding code
  • Untested new paths
  • Loop queries, missing indexes, unbounded growth
值得备注但不会阻塞合并的问题：
  • 函数签名未明确标注的副作用
  • 应该定义为命名常量的魔法字面量
  • 死代码、过时注释、与周边代码不一致的代码风格
  • 未覆盖测试的新路径
  • 循环查询、缺失索引、无上限的容量增长

How to Handle Findings

如何处理发现的问题

Fix directly when the correct answer is unambiguous: clear bugs, null checks on crash paths, style inconsistencies matching the surrounding code, trivial test additions.
Batch everything else into a single AskUserQuestion when the fix involves behavior changes, architectural choices, or anything where "right" depends on intent:
[N items need a decision]

1. [hard stop / signal] What: ... Suggested fix: ... Keep / Skip?
2. ...
修复方案明确无歧义的问题可直接修复：明确的Bug、崩溃路径的空值检查、与周边代码匹配的风格不一致问题、简单的测试补充。
其他所有涉及行为变更、架构选择、或「正确方案」取决于业务意图的问题，统一整理为单个AskUserQuestion咨询：
[N items need a decision]

1. [hard stop / signal] What: ... Suggested fix: ... Keep / Skip?
2. ...

Judgment Quality

质量判断

Beyond correctness, ask three questions a senior reviewer would ask:
  • Right problem? Does the diff solve what was actually needed, or a slightly different version of it? A technically correct solution to the wrong problem is a bug with extra steps.
  • Mature approach? Is the implementation idiomatic for this codebase and language, or does it introduce a pattern that will confuse the next person? Clever code that nobody else can maintain is a liability.
  • Honest edge cases? Does the code handle failure modes and boundary conditions explicitly, or does it silently succeed in the happy path and silently corrupt in the others? Check what happens on nil, empty, zero, concurrent access, and upstream failure.
These do not block a merge on their own, but a "no" on any of them is worth flagging explicitly.
除了正确性之外，还需要思考资深评审者会关注的三个问题：
  • 是否解决了正确的问题？ Diff是否解决了实际需要解决的问题，还是只解决了近似问题？针对错误问题的技术正确方案，本质是多了几层实现的Bug。
  • 实现方式是否成熟？ 实现是否符合当前代码库和语言的惯用写法，还是引入了会让后续维护者困惑的模式？其他人无法维护的巧妙代码是技术负债。
  • 边界情况处理是否完善？ 代码是否显式处理了失败场景和边界条件，还是只在快乐路径下正常运行，其他场景下默默出错？检查空值、空内容、零值、并发访问、上游依赖失败时的表现。
这些问题本身不会阻塞合并，但任何一个问题的答案为「否」都值得明确标记。

Regression Coverage

回归覆盖

For every new code path: trace it, check if a test covers it. If this change fixes a bug, a test that fails on the old code must exist before this is done.
针对每一条新代码路径：追溯执行逻辑，检查是否有测试覆盖。如果本次变更修复了某个Bug，完成前必须存在一个在旧代码上会运行失败的测试用例。

Verification

验证

After all fixes are applied, detect and run the project's verification command:
bash
undefined
所有修复完成后，识别并运行项目的验证命令：
bash
undefined

Auto-detect: lint/typecheck first, then tests

Auto-detect: lint/typecheck first, then tests

if [ -f Cargo.toml ]; then cargo check && cargo test elif [ -f tsconfig.json ]; then npx tsc --noEmit && npm test elif [ -f package.json ] && grep -q '"test"' package.json; then npm test elif [ -f Makefile ] && grep -q '^test:' Makefile; then make test elif [ -f pytest.ini ] || [ -f pyproject.toml ] || find . -maxdepth 2 -name "test_*.py" | grep -q .; then pytest else echo "(no test command detected)"; fi

If nothing is detected, ask the user for the verification command before proceeding.

Paste the full output. Report exact numbers. Done means: the command ran in this session and passed.

If no verification command exists or the command fails: halt. Do not claim done. Ask the user how to verify before proceeding.

If the urge to skip this arises: "should work now" means run it. "I'm confident" is not evidence. "It's a trivial change" is how trivial changes break things.
if [ -f Cargo.toml ]; then cargo check && cargo test elif [ -f tsconfig.json ]; then npx tsc --noEmit && npm test elif [ -f package.json ] && grep -q '"test"' package.json; then npm test elif [ -f Makefile ] && grep -q '^test:' Makefile; then make test elif [ -f pytest.ini ] || [ -f pyproject.toml ] || find . -maxdepth 2 -name "test_*.py" | grep -q .; then pytest else echo "(no test command detected)"; fi

如果没有识别到可用命令，继续操作前先咨询用户验证命令是什么。

粘贴完整运行输出，上报准确的数字。完成意味着：命令在本次会话中运行且全部通过。

如果没有验证命令或命令运行失败：停止操作，不要宣称完成，继续操作前先咨询用户如何验证。

如果产生跳过验证的念头：「现在应该能运行」意味着需要实际运行验证，「我有把握」不算证据，「这只是个小改动」正是小改动引发故障的原因。

Sign-off

签核

files changed:    N (+X -Y)
scope:            on target / drift: [what]
hard stops:       N found, N fixed, N deferred
signals:          N noted
new tests:        N
verification:     [command] → pass / fail
files changed:    N (+X -Y)
scope:            on target / drift: [what]
hard stops:       N found, N fixed, N deferred
signals:          N noted
new tests:        N
verification:     [command] → pass / fail