让 AI 修改一份文档、修复一个 Bug 或整理一组资料后我们经常会收到一段令人安心的总结已经完成修改已经运行检查没有发现问题。这段话很像工作的终点。它结构清楚语气肯定还会列出改了什么、验证了什么。于是人很容易看完总结就直接进入下一项任务。问题在于“AI 说完成了”只是一条状态声明不是任务已经完成的证据。AI 未必是在故意夸大。更常见的情况是它只能根据自己看见的文件、命令输出和局部反馈判断状态而我们真正关心的目标可能存在于它没有观察到的地方页面是否真的恢复正常引用是否真的支持结论消息是否发给了正确的人迁移后的数据是否仍然完整。“完成”其实有四层含义很多误解来自我们把不同层次的“完成”都压缩成了同一个词。层次实际发生的事它能证明什么还不能证明什么已生成AI 产出了一段文本、代码或方案已经有可供检查的产物内容正确、可用已执行文件被修改命令或工具被调用指定动作确实发生动作产生了预期效果已验证测试、检查或人工复核通过某组验收条件得到满足验收条件覆盖了全部目标已实现目标用户关心的问题已经解决任务在真实场景中成立是否适合长期维持、是否还有新风险例如AI 修改了登录模块这是“已执行”认证测试通过这是“已验证”用户刷新页面后仍能保持登录而且其他登录方式没有受到影响才更接近“已实现目标”。这四层并不是每次都要走得同样复杂。改一个错别字查看 Diff 可能就足够修改生产数据则需要备份、试运行、结果核对和明确授权。验证的强度应当与出错后的代价相匹配。为什么一句完成声明不够AI 对任务状态的判断通常来自当前上下文中的可见信号。它看见命令返回成功就可能判断“运行正常”看见测试全部通过就可能判断“问题已经修复”看见文件里出现了参考文献就可能判断“引用已经补全”。这些判断都可能有依据却只覆盖了任务的一部分。命令返回成功可能只说明程序没有立即报错测试通过可能是因为测试没有覆盖真正的故障路径参考文献存在也不等于原文支持当前这句话。问题不在于这些信号毫无价值而在于我们常常给了它们超出自身范围的解释。因此可靠协作的关键不是要求 AI “更自信地检查一遍”而是提前把目标翻译成可以观察的验收信号。否是真实目标可观察的验收条件AI 执行任务产生文件、日志或测试结果证据是否支持目标定位缺口并继续修改人工接受或进入下一步图中最重要的一步是从“真实目标”到“可观察的验收条件”。如果这一层没有定义清楚后面的测试再多也可能只是在认真检查一个没有回答原问题的指标。三类任务需要看三种不同证据同一句“已经完成”放在不同任务中需要完全不同的证据。代码修改要回到行为和测试研究写作要回到来源外部操作则要回到系统中的实际状态。任务属于哪一类代码修改研究写作外部操作复现问题 → 查看 Diff → 针对性测试 → 真实场景检查定位来源 → 核对原文 → 区分事实与判断 → 标明缺口执行前预览 → 调用工具 → 回读状态 → 核对接收方与关键字段修改代码不要只看“文件已经改了”假设任务是修复“刷新页面后登录态丢失”。一份有用的完成证据至少应回答问题是否可以稳定复现修改集中在哪些文件什么测试覆盖了原来的失败路径以及刷新后的真实行为是否符合预期。仅仅展示一段 Diff只能证明代码发生了变化仅仅运行整个测试套件也不能保证目标场景包含在其中。更可靠的顺序是先复现再修改然后运行针对性测试最后回到原场景检查问题是否消失。整理研究材料不要只看“文章很完整”AI 很容易生成结构完整的调研稿但一篇文章有标题、表格和参考资料并不等于事实链已经闭合。此时需要检查的不是文字是否流畅而是关键结论能否对应到原始材料来源是否真实存在原文是否真的支持这句话事实、作者主张和自己的判断是否被混在一起以及没有找到依据的部分是否被明确标出。对于研究任务“看起来像一篇报告”属于已生成“核心论断都能回到证据”才接近已验证。调用外部工具不要只看“请求成功”发送消息、创建日程、写入数据库或发布文档会把影响带出当前对话。工具返回成功可能只说明请求被系统接收并不能自动证明接收人、正文、附件、时间和权限都正确。这类任务需要结果回读重新读取已经创建的内容核对实际收件人和关键字段并明确区分“已提交请求”“系统已保存”和“对方已经收到”。外部状态越重要越不能只依赖执行工具自己的成功提示。证据要与风险相匹配并非所有任务都值得建立一套沉重的审计流程。真正实用的做法是按影响范围逐步增加验证强度。任务影响例子合理的验证方式低改错别字、调整局部格式查看目标段落或 Diff中改页面、修 Bug、重组文档针对性测试、截图、链接和结构检查高数据迁移、批量删除、权限修改试运行、备份、抽样核对、完整回读和人工确认外部影响发消息、发布内容、创建审批执行前预览执行后核对接收方、正文和系统状态这里没有一套适用于所有场景的固定清单。原则只有一个错误越难撤销、影响的人越多、涉及的数据越敏感就越需要独立于完成声明的证据。让 AI 报告证据而不是只报告结论与其在任务末尾只问“完成了吗”不如要求它按下面的结构说明1. 实际修改或执行了什么 2. 用什么方法验证 3. 验证产生了什么可查看的结果 4. 哪些部分没有验证为什么 5. 我怎样可以独立复现或抽查这种问法不会让 AI 自动变得正确但会迫使任务状态变得更具体。它也让人能够区分哪些是已经观察到的事实哪些是根据局部信号作出的解释哪些仍然只是合理猜测。采用结果前的 30 秒检查当 AI 再次说“已经完成”时可以快速问自己五个问题它完成的是一个动作还是我真正关心的目标它提供了原始结果还是只提供了自己的总结验证是否覆盖了最初出现问题的场景有没有明确写出未检查的部分和结论边界如果这次判断错了是否能够恢复谁会受到影响“完成”不是一句结束语而是目标与证据之间已经建立了可检查的联系。AI 可以帮助执行也可以帮助验证但接受结果的那一步仍然需要人的判断。下一次看到“任务已完成”不必立刻怀疑也不要立刻相信。先看看它留下了什么证据。
与 AI 一起工作 | 3. AI 说“完成了”，为什么你还不能相信它？
让 AI 修改一份文档、修复一个 Bug 或整理一组资料后我们经常会收到一段令人安心的总结已经完成修改已经运行检查没有发现问题。这段话很像工作的终点。它结构清楚语气肯定还会列出改了什么、验证了什么。于是人很容易看完总结就直接进入下一项任务。问题在于“AI 说完成了”只是一条状态声明不是任务已经完成的证据。AI 未必是在故意夸大。更常见的情况是它只能根据自己看见的文件、命令输出和局部反馈判断状态而我们真正关心的目标可能存在于它没有观察到的地方页面是否真的恢复正常引用是否真的支持结论消息是否发给了正确的人迁移后的数据是否仍然完整。“完成”其实有四层含义很多误解来自我们把不同层次的“完成”都压缩成了同一个词。层次实际发生的事它能证明什么还不能证明什么已生成AI 产出了一段文本、代码或方案已经有可供检查的产物内容正确、可用已执行文件被修改命令或工具被调用指定动作确实发生动作产生了预期效果已验证测试、检查或人工复核通过某组验收条件得到满足验收条件覆盖了全部目标已实现目标用户关心的问题已经解决任务在真实场景中成立是否适合长期维持、是否还有新风险例如AI 修改了登录模块这是“已执行”认证测试通过这是“已验证”用户刷新页面后仍能保持登录而且其他登录方式没有受到影响才更接近“已实现目标”。这四层并不是每次都要走得同样复杂。改一个错别字查看 Diff 可能就足够修改生产数据则需要备份、试运行、结果核对和明确授权。验证的强度应当与出错后的代价相匹配。为什么一句完成声明不够AI 对任务状态的判断通常来自当前上下文中的可见信号。它看见命令返回成功就可能判断“运行正常”看见测试全部通过就可能判断“问题已经修复”看见文件里出现了参考文献就可能判断“引用已经补全”。这些判断都可能有依据却只覆盖了任务的一部分。命令返回成功可能只说明程序没有立即报错测试通过可能是因为测试没有覆盖真正的故障路径参考文献存在也不等于原文支持当前这句话。问题不在于这些信号毫无价值而在于我们常常给了它们超出自身范围的解释。因此可靠协作的关键不是要求 AI “更自信地检查一遍”而是提前把目标翻译成可以观察的验收信号。否是真实目标可观察的验收条件AI 执行任务产生文件、日志或测试结果证据是否支持目标定位缺口并继续修改人工接受或进入下一步图中最重要的一步是从“真实目标”到“可观察的验收条件”。如果这一层没有定义清楚后面的测试再多也可能只是在认真检查一个没有回答原问题的指标。三类任务需要看三种不同证据同一句“已经完成”放在不同任务中需要完全不同的证据。代码修改要回到行为和测试研究写作要回到来源外部操作则要回到系统中的实际状态。任务属于哪一类代码修改研究写作外部操作复现问题 → 查看 Diff → 针对性测试 → 真实场景检查定位来源 → 核对原文 → 区分事实与判断 → 标明缺口执行前预览 → 调用工具 → 回读状态 → 核对接收方与关键字段修改代码不要只看“文件已经改了”假设任务是修复“刷新页面后登录态丢失”。一份有用的完成证据至少应回答问题是否可以稳定复现修改集中在哪些文件什么测试覆盖了原来的失败路径以及刷新后的真实行为是否符合预期。仅仅展示一段 Diff只能证明代码发生了变化仅仅运行整个测试套件也不能保证目标场景包含在其中。更可靠的顺序是先复现再修改然后运行针对性测试最后回到原场景检查问题是否消失。整理研究材料不要只看“文章很完整”AI 很容易生成结构完整的调研稿但一篇文章有标题、表格和参考资料并不等于事实链已经闭合。此时需要检查的不是文字是否流畅而是关键结论能否对应到原始材料来源是否真实存在原文是否真的支持这句话事实、作者主张和自己的判断是否被混在一起以及没有找到依据的部分是否被明确标出。对于研究任务“看起来像一篇报告”属于已生成“核心论断都能回到证据”才接近已验证。调用外部工具不要只看“请求成功”发送消息、创建日程、写入数据库或发布文档会把影响带出当前对话。工具返回成功可能只说明请求被系统接收并不能自动证明接收人、正文、附件、时间和权限都正确。这类任务需要结果回读重新读取已经创建的内容核对实际收件人和关键字段并明确区分“已提交请求”“系统已保存”和“对方已经收到”。外部状态越重要越不能只依赖执行工具自己的成功提示。证据要与风险相匹配并非所有任务都值得建立一套沉重的审计流程。真正实用的做法是按影响范围逐步增加验证强度。任务影响例子合理的验证方式低改错别字、调整局部格式查看目标段落或 Diff中改页面、修 Bug、重组文档针对性测试、截图、链接和结构检查高数据迁移、批量删除、权限修改试运行、备份、抽样核对、完整回读和人工确认外部影响发消息、发布内容、创建审批执行前预览执行后核对接收方、正文和系统状态这里没有一套适用于所有场景的固定清单。原则只有一个错误越难撤销、影响的人越多、涉及的数据越敏感就越需要独立于完成声明的证据。让 AI 报告证据而不是只报告结论与其在任务末尾只问“完成了吗”不如要求它按下面的结构说明1. 实际修改或执行了什么 2. 用什么方法验证 3. 验证产生了什么可查看的结果 4. 哪些部分没有验证为什么 5. 我怎样可以独立复现或抽查这种问法不会让 AI 自动变得正确但会迫使任务状态变得更具体。它也让人能够区分哪些是已经观察到的事实哪些是根据局部信号作出的解释哪些仍然只是合理猜测。采用结果前的 30 秒检查当 AI 再次说“已经完成”时可以快速问自己五个问题它完成的是一个动作还是我真正关心的目标它提供了原始结果还是只提供了自己的总结验证是否覆盖了最初出现问题的场景有没有明确写出未检查的部分和结论边界如果这次判断错了是否能够恢复谁会受到影响“完成”不是一句结束语而是目标与证据之间已经建立了可检查的联系。AI 可以帮助执行也可以帮助验证但接受结果的那一步仍然需要人的判断。下一次看到“任务已完成”不必立刻怀疑也不要立刻相信。先看看它留下了什么证据。
