完成宣称

Completion Claim

也常被叫作：已完成做好了搞定了

验收与证据通常止于「概念」约 2 分钟读完

你可能会这么说

「他说「已完成，功能正常运行」，我该信吗？」

完成宣称 Completion Claim

「做完了」是一句待验证的宣称，不是一个已成立的事实。

这是全站第一条，因为它是所有麻烦的起点。

AI 说「已完成」时，多数时候它没撒谎——它对完成的判断标准和你不一样。你说的完成是「用户能用」；它说的完成往往是「我按你的话生成了内容」。中间隔着构建、运行、真实入口、线上环境四道门，它可能一道都没走。

讲个真事。2026 年 8 月，我们往家用机器打包一个视频生成工具的便携包。打包完我说「拷完了，没问题」——听起来像完成宣称吧？后来做哈希复验，8 个文件和源不一致：打包那几分钟里，另一个同事还在往源仓库里加功能。包是旧的，我的「拷完了」是真的，但这句真话毫无用处，因为它验证的是「我执行过复制」，不是「包是最新的」。

这就是关键：完成宣称的问题不在真假，在于它说的那件事和你以为的那件事经常不是同一件。语言模型输出的确信程度和事实正确程度也不挂钩——没跑过的代码和跑通过的代码，它交给你时语气一样笃定。

所以别问「你做完了吗」，问「我怎么自己看到」。前一个问题只能换来语言，后一个问题必须拿现实来答。上面那次事故的解药也简单：复验脚本跑一遍哈希比对，8 个 DIFF 当场现形，谁也不用争。

最后提醒一句：别因为被骗过几次就不信所有交付。默认要证据，证据给足了就痛快收货。

长什么样真实可交互，不是截图

✕ 宣称已完成，功能正常运行
已修复该问题
应该可以了
已按最佳实践优化

✓ 证据改了 src/x.ts 第 12-30 行
命令原始输出：3 passed
打开 localhost:3000/login 能看到
这一段我没验证过

语气笃定和事实正确之间没有必然关系

右边四句都可以被你当场核对，左边四句一句都不行。区别不在礼貌，在可核对性。

拆开看，里面有这几块

1
动作描述 What was done
改了哪些文件、加了什么。这是最容易给出、也最容易含糊的一部分。
2
执行证据 Raw output
真正跑过的命令和它的原始输出。复述不算，转述不算。
3
复现路径 How to see it
你打开哪个地址、点哪一步、预期看到什么。这一条最能拆穿假完成。
4
未验证声明 Known gaps
哪部分他没有真的验证过。愿意写出这一条的合作者，才值得信。

常见的有哪几种

空宣称Bare claim

只有「已完成」三个字，没有任何可核对的内容。

用在：直接要证据，别追问感受

推测型宣称Speculative

出现「应该」「理论上」「一般来说」，说明他在推理而不是在看结果。

用在：回一句「应该不算，你实际看到了什么」

偷换层级Level swap

用低层证据宣称高层结果，比如用「测试通过」宣称「线上好了」。

用在：追问真实入口和线上地址

带证据宣称Evidenced

主动给出文件、输出、复现路径和未验证项。

用在：这种可以直接进入验收，不用盘问

容易搞混？这样区分

完成宣称 ≠ 完成层级 Evidence Level

完成宣称是他说的那句话；完成层级是这句话实际站在第几层。判断方法：先接住宣称，再用层级去量它。

看完成层级

完成宣称 ≠ 验收标准 Acceptance Criteria

验收标准是开工前你写下的清单，完成宣称是收工时他给的说法。前者是尺子，后者是被量的东西。没有尺子，就只能靠感觉吵架。

看验收标准

什么时候用得上

他说「已完成」

别回「好的」。回「我打开哪个地址、点哪一步能看到？」这一句几乎不会失手。

他说「已修复」

用原来那个操作复现一次。修复类任务的唯一验证方式是「原问题不再出现」。

他说「应该可以了」

「应该」就是「我没验证」的礼貌说法。直接问他实际看到了什么。

你可以这样跟 AI 说

直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。

从现在开始，你汇报完成时不要只说"已完成"，按这个格式：

1. 改了哪些文件，每个文件改了什么
2. 实际执行的命令 + 原始输出（贴出来，不要复述结论）
3. 我怎么自己看到效果：打开哪个地址、点哪一步、预期看到什么
4. 这次改动可能影响什么，怎么退回去
5. 哪些部分你**没有**真正验证过

第 5 条很重要：没验证就直接写"未验证"，不要用"应该可以""理论上没问题"填上。我更看重你诚实，而不是看起来全部完成。

把这段话放在长任务的开头，比每次事后盘问有效得多。你不是在防他，你是在提前对齐「完成」的定义。

它说「做好了」，你怎么自己验

这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「概念」这层：只是说清了要做什么，还没有任何东西在跑。

要亲眼看到这些，才算数

这句宣称里有没有至少一个你能当场核对的具体项（文件名、命令输出、可访问地址）？没有就等于什么都没说。
把他汇报的层级和你要的层级对一遍：他说的是「代码写了」，你要的是「用户能用」吗？
问一句「我怎么自己看到」，看他能不能给出具体路径。给不出，说明他也没看到过。
问一句「哪部分你没验证过」，看他会不会承认边界。全部声称已验证的回答，可信度反而更低。

它常这么糊弄你

「已完成，功能正常运行」——最常见的一句，信息量为零。「正常运行」是谁看到的？
「已按最佳实践实现」——用一个无法反驳的词替代了可验证的结果。
「已修复该问题」——但没有复现过原问题。改了相似代码不等于修好了根因。
「测试全部通过」——测试可能根本没覆盖你在意的那条路径。
你说「不对啊」，他立刻说「你说得对，我马上修复」，然后又给一句「已完成」。这个循环可以无限进行，直到你开始要证据。

这一条本身停在「概念」层：它是一个思维习惯，不是一个可运行的东西。但它决定了你后面每一层能不能验准。

考考你选一个你觉得对的

AI 说「已完成登录功能的修改，功能正常运行」。哪一句追问最有效？

想再深挖一点靠谱出处

Definition of done（完成的定义）Wikipedia ↗Scrum Guide（Scrum 指南）Scrum Guides ↗

# 完成宣称 (Completion Claim)

> 「做完了」是一句待验证的宣称，不是一个已成立的事实。

**你可能会这么说**：他说「已完成，功能正常运行」，我该信吗？

这是全站第一条，因为它是所有麻烦的起点。 AI 说「已完成」时，多数时候它没撒谎——它对完成的判断标准和你不一样。你说的完成是「用户能用」；它说的完成往往是「我按你的话生成了内容」。中间隔着构建、运行、真实入口、线上环境四道门，它可能一道都没走。 讲个真事。2026 年 8 月，我们往家用机器打包一个视频生成工具的便携包。打包完我说「拷完了，没问题」——听起来像完成宣称吧？后来做哈希复验，8 个文件和源不一致：打包那几分钟里，另一个同事还在往源仓库里加功能。包是旧的，我的「拷完了」是真的，但这句真话毫无用处，因为它验证的是「我执行过复制」，不是「包是最新的」。 这就是关键：完成宣称的问题不在真假，在于**它说的那件事和你以为的那件事经常不是同一件**。语言模型输出的确信程度和事实正确程度也不挂钩——没跑过的代码和跑通过的代码，它交给你时语气一样笃定。 所以别问「你做完了吗」，问「我怎么自己看到」。前一个问题只能换来语言，后一个问题必须拿现实来答。上面那次事故的解药也简单：复验脚本跑一遍哈希比对，8 个 DIFF 当场现形，谁也不用争。 最后提醒一句：别因为被骗过几次就不信所有交付。默认要证据，证据给足了就痛快收货。

**也叫**：已完成、做好了、搞定了

## 你可以这样告诉 AI

```text
从现在开始，你汇报完成时不要只说"已完成"，按这个格式：

1. 改了哪些文件，每个文件改了什么
2. 实际执行的命令 + 原始输出（贴出来，不要复述结论）
3. 我怎么自己看到效果：打开哪个地址、点哪一步、预期看到什么
4. 这次改动可能影响什么，怎么退回去
5. 哪些部分你**没有**真正验证过

第 5 条很重要：没验证就直接写"未验证"，不要用"应该可以""理论上没问题"填上。我更看重你诚实，而不是看起来全部完成。
```

## 怎么验证他真的做到了

通常止于层级：**概念** — 只是说清了要做什么，还没有任何东西在跑

- [ ] 这句宣称里有没有至少一个你能当场核对的具体项（文件名、命令输出、可访问地址）？没有就等于什么都没说。
- [ ] 把他汇报的层级和你要的层级对一遍：他说的是「代码写了」，你要的是「用户能用」吗？
- [ ] 问一句「我怎么自己看到」，看他能不能给出具体路径。给不出，说明他也没看到过。
- [ ] 问一句「哪部分你没验证过」，看他会不会承认边界。全部声称已验证的回答，可信度反而更低。

常见糊弄：
- 「已完成，功能正常运行」——最常见的一句，信息量为零。「正常运行」是谁看到的？
- 「已按最佳实践实现」——用一个无法反驳的词替代了可验证的结果。
- 「已修复该问题」——但没有复现过原问题。改了相似代码不等于修好了根因。
- 「测试全部通过」——测试可能根本没覆盖你在意的那条路径。
- 你说「不对啊」，他立刻说「你说得对，我马上修复」，然后又给一句「已完成」。这个循环可以无限进行，直到你开始要证据。

来源：https://mickerbook.com/reference/t/completion-claim/