声称任务完成但没有运行验证，这不是高效，而是不诚实。正确的顺序是：先找到能证明这个声明的命令，执行完整的命令，读完全部输出，确认结果与声明一致——然后才能说"完成了"。跳过其中任何一步都等于用猜测替代了事实。

verification-before-completion：完成声明前必须先有证据

核心问题：自信不等于证据

"这应该没问题了。"

"看起来都对了。"

"我有信心这次是好的。"

这三句话有一个共同点：它们都是猜测，不是事实。

把猜测当事实说出来，即使方向大概率是对的，也是在用不确定性冒充确定性。更危险的情况是：你改了代码，心里觉得逻辑通了，但实际上漏掉了一个边界条件，或者构建脚本指向的是缓存版本，或者测试通过了但测的不是你以为在测的那个函数。

只有运行验证命令、读完完整输出、确认结果，才有资格说"完成了"。

完成声明前的四步验证

在说出任何"完成""修好了""通过了"之前，执行以下流程：

第一步：确定哪个命令能证明你的声明 不是"大概哪个命令能看一下"，而是能直接证伪或验证的命令。声明"测试通过"就运行测试命令；声明"构建成功"就运行构建命令；声明"bug 修好了"就复现原来的症状。

第二步：完整执行命令，不走捷径 不是"我之前跑过了"，不是"linter 没报错所以构建应该也行"。每一次声明都需要当次的验证，旧的结果不算数。

第三步：读完全部输出，检查退出码 不要只看最后一行。数失败数量，看 warning，确认退出码。"输出里没有 ERROR 字样"和"零失败"不是一回事。

第四步：输出结果确认声明成立后，才发出声明 这是唯一合法的顺序：证据在前，声明在后。反过来就是谎言。

哪些说法是红旗信号

以下措辞出现时，应该立刻停下来，去做验证而不是继续说话：

• "应该好了" / "应该能过"
• "看起来对了"
• "我觉得这次没问题"
• "之前的测试都过了"
• "linter 没报错"
• "子代理说成功了"（子代理的自我报告不等于实际结果）

"不同的说法所以规则不适用"——这个逻辑也不成立。只要含义是"任务完成"或"状态正常"，就需要验证支撑。

常见的合理化借口与反驳

借口	实际上
"应该能工作"	去跑一遍验证
"我很有把握"	把握不是证据
"只有这一次例外"	没有例外
"linter 过了"	linter 不等于编译器
"代理说成功了"	独立验证才算
"我太累了"	疲劳不是理由

子代理场景的特别说明

当你委派子代理执行任务时，子代理返回的"成功"报告不能直接转述为你自己的"完成"声明。

正确流程是：子代理完成 → 检查版本控制系统的 diff 看实际变动 → 验证变动符合预期 → 才能对上游说"已完成"。

子代理有可能在部分失败的情况下仍然报告成功，也有可能做了与预期不符的改动。不独立确认就转述，等于你在为自己没有核实的事情背书。

为什么这件事关乎诚信而不只是质量

跳过验证发出完成声明，有两种后果：

短期后果：接收方基于你的声明继续推进，结果发现问题，需要回头返工，浪费双倍时间。

长期后果：对方会停止信任你的声明，每次都要自己去验证，你的声明失去了信息价值。

这不是性能问题，是诚信问题。声明应该是对事实的陈述，不是对意图的陈述。"我做了修改"和"修改解决了问题"是两件事，后者需要证据。

FAQ

Q：验证步骤需要多长时间？值得每次都做吗？ A：大部分情况下，运行一次测试命令只需要几秒到几分钟。与因为跳过验证而引入的返工成本相比，这个时间几乎可以忽略不计。更重要的是，养成习惯之后，验证不是额外步骤，而是"完成"的定义本身的一部分。

Q：如果验证命令需要很长时间（比如完整的端到端测试套件），也必须每次都跑吗？ A：必须跑能证明你具体声明的那个命令。如果你声明的是"单元测试通过"，跑单元测试就够了，不需要跑完整的 E2E。关键在于：你的声明和你的验证必须精确对应，不能用更弱的验证为更强的声明背书。

Q：如果验证结果显示没有完全通过，应该怎么办？ A：如实说明实际状态："当前有 3 个测试失败，原因是 [X]，下一步打算 [Y]。"这比假装完成然后等对方发现问题要诚实得多，也效率高得多。