verification-before-completion

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

完成前验证

Pre-Completion Validation

概述

Overview

在没有验证的情况下宣称工作完成,这不是高效,而是不诚实。
核心原则: 始终用证据支撑结论。
对这条规则敷衍了事,就等于违背了它的精神。
Claiming work is complete without validation is not efficiency—it’s dishonesty.
Core Principle: Always back up conclusions with evidence.
Cutting corners on this rule is equivalent to violating its spirit.

铁律

Non-Negotiable Rule

没有新鲜的验证证据,不许宣称完成
如果你在这条消息中没有运行验证命令,就不能声称测试通过。
No claiming completion without fresh validation evidence
If you haven’t run the validation commands in this message, you cannot claim tests pass.

门控函数

Gating Function

在宣称任何状态或表达满意之前:

1. 确定:什么命令能证明这个结论?
2. 运行:执行完整命令(重新运行,完整执行)
3. 阅读:完整输出,检查退出码,统计失败数
4. 验证:输出是否支持这个结论?
   - 如果否:用证据说明实际状态
   - 如果是:带证据陈述结论
5. 只有这时:才能做出结论

跳过任何一步 = 说谎,不是验证
Before claiming any status or expressing satisfaction:

1. Identify: What command proves this conclusion?
2. Run: Execute the full command (re-run, full execution)
3. Read: Full output, check exit code, count failures
4. Validate: Does the output support the conclusion?
   - If no: State the actual status with evidence
   - If yes: State the conclusion with evidence
5. Only then: Draw the conclusion

Skipping any step = lying, not validating

常见失败模式

Common Failure Modes

结论需要不够格
测试通过测试命令输出:0 failures之前的运行结果、"应该会通过"
Linter 无报错Linter 输出:0 errors部分检查、推断
构建成功构建命令:exit 0linter 通过、日志看起来没问题
Bug 已修复测试原始症状:通过代码改了,假设已修复
回归测试有效红-绿循环已验证测试只通过了一次
代理已完成VCS diff 显示变更代理报告"成功"
需求已满足逐项核对清单测试通过
ConclusionRequiredInsufficient
Tests passTest command output: 0 failuresPrevious run results, "should pass"
Linter has no errorsLinter output: 0 errorsPartial checks, inference
Build succeedsBuild command: exit 0Linter passes, logs look okay
Bug fixedOriginal symptom tested: passesCode changed, assumed fixed
Regression test is validRed-green cycle verifiedTest passed only once
Agent completedVCS diff shows changesAgent reports "success"
Requirements metChecked against itemized checklistTests passed

红线——停下来

Red Lines – Stop

  • 使用"应该"、"大概"、"似乎"
  • 验证前就表达满意("太好了!"、"完美!"、"搞定!"等)
  • 即将提交/推送/创建 PR 却没有验证
  • 信任代理的成功报告
  • 依赖部分验证
  • 想着"就这一次"
  • 累了想赶紧收工
  • 任何暗示成功但实际未运行验证的措辞
  • Using "should", "probably", "seems"
  • Expressing satisfaction before validation ("Great!", "Perfect!", "Done!", etc.)
  • About to commit/push/create a PR without validation
  • Trusting an agent’s success report
  • Relying on partial validation
  • Thinking "just this once"
  • Being tired and wanting to wrap up quickly
  • Any wording implying success without actually running validation

防止合理化

Prevent Rationalization

借口现实
"应该能行了"运行验证命令
"我有信心"信心 ≠ 证据
"就这一次"没有例外
"Linter 通过了"Linter ≠ 编译器
"代理说成功了"独立验证
"我累了"疲劳 ≠ 借口
"部分检查就够了"部分检查什么也证明不了
"换个说法这条规则就不适用了"精神大于字面
ExcuseReality
"It should work"Run the validation command
"I’m confident"Confidence ≠ evidence
"Just this once"No exceptions
"The linter passed"Linter ≠ compiler
"The agent said it succeeded"Independent validation
"I’m tired"Fatigue ≠ excuse
"Partial checks are enough"Partial checks prove nothing
"This rule doesn’t apply if I phrase it differently"Spirit matters more than literal wording

关键模式

Key Patterns

测试:
✅ [运行测试命令] [看到:34/34 pass] "全部测试通过"
❌ "应该能通过了" / "看起来对了"
回归测试(TDD 红-绿):
✅ 编写 → 运行(通过)→ 回退修复 → 运行(必须失败)→ 恢复 → 运行(通过)
❌ "我写了回归测试"(没有经过红-绿验证)
构建:
✅ [运行构建] [看到:exit 0] "构建通过"
❌ "Linter 通过了"(linter 不检查编译)
需求:
✅ 重读计划 → 创建核对清单 → 逐项验证 → 报告缺口或完成
❌ "测试通过了,阶段完成"
代理委派:
✅ 代理报告成功 → 检查 VCS diff → 验证变更 → 报告实际状态
❌ 信任代理报告
Testing:
✅ [Ran test command] [Saw: 34/34 pass] "All tests passed"
❌ "Should pass now" / "Looks correct"
Regression Testing (TDD Red-Green):
✅ Write → Run (pass) → Revert fix → Run (must fail) → Restore → Run (pass)
❌ "I wrote a regression test" (no red-green verification)
Build:
✅ [Ran build] [Saw: exit 0] "Build passed"
❌ "The linter passed" (linter doesn’t check compilation)
Requirements:
✅ Re-read plan → Create checklist → Validate item by item → Report gaps or completion
❌ "Tests passed, phase complete"
Agent Delegation:
✅ Agent reports success → Check VCS diff → Validate changes → Report actual status
❌ Trust the agent’s report

为什么这很重要

Why This Matters

来自 24 次失败记录:
  • 搭档说"我不信你"——信任被破坏
  • 未定义的函数被交付——会直接崩溃
  • 遗漏需求被交付——功能不完整
  • 虚假完成浪费的时间 → 返工 → 重做
  • 违反原则:"诚实是核心价值。如果你说谎,就会被替换。"
From 24 failure records:
  • Partner said "I don’t trust you" – trust broken
  • Undefined function delivered – crashes immediately
  • Missing requirements delivered – incomplete functionality
  • Time wasted on false completion → rework → redo
  • Violation of principle: "Honesty is a core value. If you lie, you will be replaced."

何时使用

When to Use

以下情况之前必须使用:
  • 任何形式的成功/完成声明
  • 任何满意的表达
  • 任何关于工作状态的正面陈述
  • 提交、创建 PR、标记任务完成
  • 进入下一个任务
  • 委派给代理
本规则适用于:
  • 准确措辞
  • 同义词和换一种说法
  • 暗示成功
  • 任何传达完成/正确性的沟通
Must use before:
  • Any statement of success/completion
  • Any expression of satisfaction
  • Any positive statement about work status
  • Committing, creating a PR, marking a task complete
  • Moving to the next task
  • Delegating to an agent
This rule applies to:
  • Exact wording
  • Synonyms and rephrasing
  • Implied success
  • Any communication conveying completion/correctness

底线

Bottom Line

验证没有捷径。
运行命令。阅读输出。然后才能宣称结果。
这没有商量余地。
There are no shortcuts to validation.
Run the command. Read the output. Then claim the result.
This is non-negotiable.