verify

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Verify

验证

A verifier's job is to distrust the shape of a claim and go look at the thing.

This is not code review. Code review asks is this change any good. Verification asks is the statement made about this change true — and it applies just as much when there is no diff to read at all. A backfill that reports 40,000 rows, a migration described as reversible, a deploy announced as live: each is a claim with an artifact behind it and nothing for a reviewer to read.

The output is a verdict someone else can act on without redoing your work.

验证者的职责是不采信声明的表述，而是直接查看实际成果物。

这不是代码评审。代码评审关注的是「这项变更是否优质」，而验证关注的是「关于这项变更的陈述是否属实」——即使没有差异内容可供查看，验证同样适用。比如报告已回填40000行数据的任务、描述为可回滚的迁移、宣布已上线的部署：这些都是带有成果物支撑的声明，但没有可供评审者查看的差异内容。

验证的输出是一份结论，其他人无需重复你的工作即可据此采取行动。

The one rule

核心规则

Check the effect, not the report of the effect.

Almost every bad verification is some version of accepting the report. The command exited 0. The function is defined. The follow-up ticket exists. The log says success. None of those are the thing being claimed; they are artifacts that would also be produced if the claim were false.

Before accepting any piece of evidence, ask: what would look identical if the claim were wrong? If the answer is "this exact output", the evidence is not evidence and you need a different instrument.

检查实际效果，而非效果报告。

几乎所有不合格的验证都是采信了效果报告的变体。比如命令执行返回0、函数已定义、后续工单已创建、日志显示成功——这些都不是声明所指向的实际结果；即使声明为假，这些报告类成果物也依然会产生。

在采信任何证据之前，请先问自己：**如果声明为假，这个证据会看起来完全一样吗？**如果答案是「是的，输出完全相同」，那这个证据根本不算证据，你需要换一种验证方式。

Procedure

验证流程

Extract the claim into separate assertions. "Backfilled the table and made it idempotent" is two claims. Grade each on its own. A single verdict over a bundle lets one false thing launder through on the strength of the true ones.
Name the artifact for each assertion. Not the description, not the done-result, not the author's summary — the rows in the table, the running process, the response from the live endpoint, the committed file. Write down which one you looked at.
Check that the artifact you read is the artifact that shipped. A local working tree, a stale branch, a staging database and the deployed thing are different objects. Confirm they are the same, or say which one you graded.
Try to make each assertion false. Find the input, the ordering, or the environment where it breaks. A verification that only confirms is a re-reading.
Emit a verdict per assertion, with the instrument named.

将声明拆分为独立的断言。「已回填表格并实现幂等性」包含两个声明，需分别评估。对一组声明给出单一结论会导致错误内容借助正确内容的可信度蒙混过关。
为每个断言指定对应的成果物。不是描述、不是完成结果、不是作者的总结——而是表格中的行、运行中的进程、线上端点的响应、已提交的文件。记录你查看的具体成果物。
确认你查看的成果物是已发布的版本。本地工作区、过时分支、 staging数据库与已部署的版本是不同的对象。请确认它们一致，或明确说明你评估的是哪个版本。
尝试让每个断言不成立。找到能让断言失效的输入、顺序或环境。仅能确认断言成立的验证只是重复阅读而已。
为每个断言输出结论，并注明验证方式。

Three states, not two

三种状态，而非两种

PASS

FAIL

· NOT-REACHED

The third one is the one people drop, and dropping it is how a broken check reads as a passing one. If the probe did not run — no fixture, no credentials, the environment was missing, the code path was never entered — that is not a pass. It is an absence of information, and it must render differently from a clean result.

Unmeasured and measured-clean must never look the same. If your report cannot distinguish "I checked and it was fine" from "I could not check", the report is broken regardless of the verdict.

Composition rule: an overall verdict cannot be
PASS
if any assertion is
NOT-REACHED
. A headline PASS printed above a NOT-REACHED line reproduces the exact collapse this section exists to prevent. Say "PASS on 2 of 3" and let the third stay visible.

PASS

FAIL

· NOT-REACHED

第三种状态常被忽略，而忽略它会导致失效的检查被误判为通过。如果验证探针未运行——没有测试环境、没有权限、环境缺失、代码路径从未进入——这不是通过。这是信息缺失，必须与正常通过的结果区分开。

未测量与测量正常的结果绝不能看起来一样。如果你的报告无法区分「我检查过了，没问题」和「我无法检查」，无论结论如何，这份报告都是无效的。

组合规则：只要有一个断言是
NOT-REACHED
，整体结论就不能是
PASS
。在

NOT-REACHED

的行上方标注整体通过，正是本节要避免的错误。应该标注「3项断言中2项通过」，并保留第三项的状态可见。

Failure modes that survive a careless check

能躲过粗心检查的失败模式

These are the ones that get past people who are genuinely paying attention.

Trap	What it looks like	The actual question
Defined is not called	Grep finds the guard function, 17 matching lines.	Is there a call site? A never-invoked function matches every grep.
Absent is not forbidden	"It didn't happen in the test run."	Is it prevented, or did it merely not occur this time?
Consistent-with is not evidence-for	The run did X, so the cause must be Y.	Would something else also produce X? Usually yes.
Succeeding in appearance	Exit 0, "success" in the log.	Did the operation do anything? A no-op exits 0 too.
Right number, wrong subject	The arithmetic checks out.	What noun does this number describe? Reproducing it proves nothing.
A failed read is not an absence	Query returned empty → "there are none."	Did the probe run to completion? Empty, errored, and never-finished are three different results, and only the first is evidence of absence.
The instrument is the anomaly	Every row looks wrong.	What fraction of the population reads the same way? If everything is broken, suspect the tool before the subject.
The caveat beside the payload	A warning printed next to the misleading list.	Readers act on the payload. Don't emit the payload.
Self-reported identifiers	A run ID or job ID pasted in the description.	Is it checkable against a record the claimant did not write?

这些模式甚至能骗过真正在认真检查的人。

陷阱	表象	实际要问的问题
已定义但未调用	Grep找到防护函数，有17条匹配行。	是否存在调用位点？从未被调用的函数也能被Grep匹配到。
未发生不等于被禁止	"测试运行中未出现该问题。"	是被阻止了，还是只是这次没发生？
符合不等于证据	运行结果是X，所以原因肯定是Y。	有没有其他因素也会导致X？通常答案是肯定的。
表面成功	返回0，日志显示"success"。	操作真的产生了实际效果吗？空操作也会返回0。
数量正确但对象错误	数值计算无误。	这个数值描述的是什么对象？重复计算数值并不能证明任何问题。
查询结果为空不等于不存在	查询返回空 → "不存在相关内容。"	探针是否完整运行？空结果、错误结果、未完成运行是三种不同的情况，只有空结果能作为不存在的证据。
验证工具本身异常	所有行看起来都有问题。	有多少比例的对象结果一致？如果所有内容都显示异常，先怀疑工具而非验证对象。
提示信息与结果分离	误导性列表旁附有警告信息。	读者只会关注结果内容。不要输出带有误导性的结果。
自我报告的标识符	描述中粘贴了运行ID或任务ID。	能否对照声明者未编写的记录进行验证？

Grade the premise, not just the work

评估前提，而非仅评估工作成果

Sometimes the change is correctly built on something that cannot hold — a privilege boundary that does not exist in the environment, an ordering guarantee nothing enforces, a file that another process rewrites. The work is fine and the claim still fails.

When you reject on a premise, say which premise and what measurement killed it. "This relies on X being true; I measured X and it is false" is actionable. "Doesn't look right" is not.

有时变更本身是正确的，但构建在不成立的前提之上——比如环境中不存在的权限边界、无任何机制保障的顺序要求、会被其他进程重写的文件。这种情况下，工作成果没问题，但声明依然不成立。

如果因前提不成立而拒绝，请说明具体是哪个前提，以及你的测量结果。「这依赖X为真；我测量了X，发现它是假的」是可执行的反馈，而「看起来不对」则不是。

Writing the verdict

撰写结论

State, in this order: the verdict, what you checked it against, and what the verdict does not extend to.

PASS on 2 of 3 intents, verified against the production table — not the migration script.
  1. backfill touched 40,312 rows — PASS. Counted rows with filled_at set against the
     pre-run snapshot. The job's own log said "40k", which was rounded, not measured.
  2. no existing values were overwritten — PASS. Checksum of the untouched column is
     unchanged from the snapshot.
  3. re-running is idempotent — NOT-REACHED. No safe way to re-run against production,
     and staging has 0 matching rows, so the staging run would have proved nothing.
THIS VERDICT DOES NOT EXTEND TO: rows created after the snapshot was taken.

Note what the third line does. Running it in staging would have produced a green — against zero matching rows. A check that cannot fail is not a check, and reporting it as NOT-REACHED is the honest result.

The scope line is not a confession and it is not optional. Frame it as what this verdict covers, which is answerable even when coverage was complete. A verdict that lists only what was confirmed reads as total coverage, and the next person will believe it.

按以下顺序陈述：结论、验证依据、结论不涵盖的范围。

PASS on 2 of 3 intents, verified against the production table — not the migration script.
  1. backfill touched 40,312 rows — PASS. Counted rows with filled_at set against the
     pre-run snapshot. The job's own log said "40k", which was rounded, not measured.
  2. no existing values were overwritten — PASS. Checksum of the untouched column is
     unchanged from the snapshot.
  3. re-running is idempotent — NOT-REACHED. No safe way to re-run against production,
     and staging has 0 matching rows, so the staging run would have proved nothing.
THIS VERDICT DOES NOT EXTEND TO: rows created after the snapshot was taken.

注意第三项的处理。在staging环境中运行会得到通过的结果——但匹配行数为0。无法失败的检查不能算作检查，如实报告为

NOT-REACHED

才是正确的结果。

范围说明不是免责声明，也不是可选内容。应该表述为「本结论涵盖的范围」，即使覆盖完整也需要说明。仅列出已确认内容的结论会被视为全面覆盖，下一个人会信以为真。

Bounce, or fix and hand back?

打回，还是修复后返还？

Bounce when the work is wrong, when the premise fails, or when the claim overstates what the artifact does. Give the reason and the measurement, not a vibe — the maker has to act on it.

Locate and post when the work is right and only the receipt is missing — the run happened but the log was left somewhere nobody else can read. Attaching the evidence is faster than a round trip and keeps the record honest.

打回适用于工作成果错误、前提不成立，或声明夸大成果物功能的情况。请给出原因和测量结果，而非主观感受——成果物的创作者需要据此采取行动。

定位并补充证据适用于工作成果正确，但缺少「凭证」的情况——比如运行已完成，但日志放在其他人无法访问的位置。附上证据比来回沟通更快，也能保证记录的真实性。

On verifying your own work

自我验证

Auditing your own claim before you publish it is worth doing, and this procedure applies to it. It lowers what a verifier finds.

It does not make you the verifier of record. If a process names a maker and a separate verifier, the point is that two different contexts looked at the artifact — grading your own work reproduces the reasoning that produced the mistake. Self-audit reduces the defect rate; it does not discharge the independent check.

在发布前自我审核自己的声明是值得做的，本流程同样适用。这能减少后续验证者发现的问题。

但这不能替代独立验证。如果流程要求分别指定创作者和验证者，核心目的是让两个不同视角的人查看成果物——自我评估会重复导致错误的思维逻辑。自我审核能降低缺陷率，但不能免除独立检查的要求。