# verification-before-completion

> 在声称任务完成之前使用 - 必须先验证结果，有证据才能声称完成

- Author: weidwonder
- Repository: weidwonder/general-task
- Version: 20260123120027
- Stars: 1
- Forks: 0
- Last Updated: 2026-02-06
- Source: https://github.com/weidwonder/general-task
- Web: https://mule.run/skillshub/@@weidwonder/general-task~verification-before-completion:20260123120027

---

---
name: verification-before-completion
description: "在声称任务完成之前使用 - 必须先验证结果，有证据才能声称完成"
---

# 完成前验证

## 概述

没有验证就声称完成，是不诚实，不是高效。

**核心原则:** 先有证据，再下结论。

**违反这条规则的字面意思，就是违反这条规则的精神。**

## 铁律

```
没有新鲜的验证证据，不得声称完成
```

如果你没有在当前消息中执行验证，你不能声称它通过了。

## 验证流程

```
在声称任何状态或表达满意之前：

1. 识别: 什么操作能证明这个声称？
2. 执行: 执行完整的验证操作
3. 阅读: 完整查看结果
4. 确认: 结果是否支持声称？
   - 否 → 说明实际状态和证据
   - 是 → 带着证据声称
5. 然后: 才能声称完成

跳过任何步骤 = 撒谎，不是验证
```

## 常见错误

| 声称 | 需要 | 不充分 |
|------|------|--------|
| 任务完成 | 验证所有验收标准 | "应该好了" |
| 文档正确 | 检查内容准确性 | 写完了就算 |
| 数据处理完成 | 检查输出结果 | 脚本跑完了 |
| 问题已解决 | 验证原问题消失 | 做了修改 |
| 格式正确 | 打开文件确认 | 用了正确的工具 |
| 备份成功 | 验证备份可恢复 | 复制命令执行了 |
| 需求满足 | 逐条对照检查 | 感觉差不多了 |

## 危险信号 - 立即停止

- 使用 "应该"、"可能"、"看起来"
- 验证前表达满意（"太好了！"、"完成！"、"搞定！"）
- 准备宣布完成但没有验证
- 依赖部分验证
- 想着 "就这一次"
- 累了想赶紧结束
- **任何暗示成功但没有执行验证的措辞**

## 防止自我合理化

| 借口 | 现实 |
|------|------|
| "应该没问题" | 执行验证 |
| "我很有信心" | 信心 ≠ 证据 |
| "就这一次" | 没有例外 |
| "我用了正确的方法" | 方法对 ≠ 结果对 |
| "子任务说成功了" | 独立验证 |
| "我累了" | 疲惫 ≠ 借口 |
| "部分检查够了" | 部分证明不了整体 |
| "换个说法规则就不适用" | 精神重于字面 |

## 关键模式

**任务完成:**
```
✅ [执行验证] [看到: 所有检查项通过] "任务完成"
❌ "应该完成了" / "看起来对"
```

**数据处理:**
```
✅ [检查输出文件] [看到: 100条记录，格式正确] "处理完成"
❌ "脚本跑完了" (没检查结果)
```

**文档更新:**
```
✅ [打开文档] [看到: 内容正确] "文档已更新"
❌ "保存了" (没打开确认)
```

**需求满足:**
```
✅ 重读需求 → 逐条检查 → 验证每项 → 报告差距或完成
❌ "主要功能好了，应该差不多"
```

**子任务委派:**
```
✅ 子任务报告成功 → 检查实际产出 → 验证变更 → 报告实际状态
❌ 信任子任务报告
```

## 为什么重要

- 用户会说 "我不相信你" - 信任被破坏
- 未完成的内容被当作完成 - 后续出错
- 缺失的需求被遗漏 - 功能不完整
- 在错误完成上浪费时间 → 返工

## 何时应用

**在以下情况之前必须验证：**
- 任何形式的成功/完成声称
- 任何满意的表达
- 任何关于工作状态的正面陈述
- 标记任务完成
- 进入下一个任务
- 委派给子任务

**规则适用于：**
- 精确措辞
- 转述和同义词
- 隐含的成功暗示
- 任何暗示完成/正确的沟通

## 底线

**验证没有捷径。**

执行验证。查看结果。然后才能声称。

这是不可协商的。