AI写完不等于做完，省下的检查，最后谁来还？ “这个是 AI 写的，我也不清楚。”工作中真正麻烦的不是用了 AI，而是有人把没核完的东西当成成品交出去，上游省下的检查，会变成下游的查证、返工和责任。这期聊聊什么是“验证债务”，普通团队又该怎样把生成、自检和最终放行拆开。 #AI提效 #ai债务 #FDE #团队管理 #工作方法

这个东西是AI写的，我也不清楚。你是不是也听到过这句话呢？ 你问他：“这个是什么情况？这个数字是哪来的？这个结论有没有核实过？”对方一摊手：“这是AI写的，我也不知道啊。”这句话最让人难受的不是“AI写的”，而是你都不清楚，它为什么交到了我的手里呢？ 比如你明天要拿着一个PPT去见客户，这个PPT中间写了一个很明确的数字：这个市场今年增长了百分之三十七。做这个PPT的人可能十分钟就交了，可你不知道这百分之三十七从哪里来的，又不敢拿着假数据出去见客户，你只能自己去查。 从这一刻起，他省掉的检查工作，就变成了你的工作。 这也不算夸张，现实里真的有人为了查清楚别人交来的AI资料，花了7.6个小时。而产出那份资料的人，前后可能只花了几分钟。去年美国路易斯安那州有一个案子，一名律师签字提交的资料里，出现了虚构判例、错误引文，还有对真实案例的错误概括。 团队后来解释，他们不是没有检查，也用过搜索引擎、ChatGPT这类工具互相核对，可材料交出去以后，另一方律师在法律数据库和法院的网站都找不到这些判例。他们不可能搜一次就说这个东西是假的，得先排除编号和名字写错的可能，再联系法院确认，检查下来还发现了别的问题。 最后写真实的回应和制裁动力，在工作前后加起来花了7.6个小时。 签字律师还真变过，查一个判例几秒不就够了吗？ 可下游接到的从来不是几行引用而已，上游丢下来的是几行引用，下游接到的就是一项调查任务了。 纽约那边有个更出名的假判例案，这个事件的人链讲得更清楚：一个律师用GBT做了实质性的研究和起草，另一个律师主要看了新闻和预议法，没去核对判例是不是真的，就签字交出去了。 最后由对方的律师和法院把问题查了出来，结果两名律师和律所一起被罚了5千美元。 法院不会去问GBT为什么撒谎，他问的是谁签的字，谁把材料交出去的，谁在对别人说“这是真的，我负责”。 所以说，AI会胡说只是第一层，最深的问题是一份没有验证的东西，为什么能带着完成品的样子进入到下一环。 我把里面没有做完的工作，叫做验证债务。 讲得直白一点，你审调的那步检查从来就不会消失，它只是把这个任务交给了下一个人而已。 你没查的数据、没合适的来源、没跑的测试、没有说清楚的假设，那些都是债。文件每转发一次，债不会消失，只是换了债主而已。 而链条越长，这个债力会变得越重，会越来越重，越来越贵，越来越难。 最早生成的人最清楚自己问过什么、参考过什么、改过什么，可这些上下文如果没有留下来。 到了第二个人手里，只剩下一份看似很完整的文件。再到最后那个要签字上线、发给客户的人的手里，他知道得最少，却不能让他出错，于是就会出现一个很反常识的情况：越往后的人知道的越少，承担的却越多。 你可能会说，那就规定AI的内容都让人审查一遍不就好了吗？可问题不是没有人看过，而是他到底看了什么。前面那个律师案里，签字的律师确实审过了，他查了行文和语法，却没有打开那些材料，去确认它们到底是不是真的存在。 这件事就有名有姓地写在了法院的记录里，所以要分两个动作：一个是看句子读不读得通顺，格式对不对，逻辑顺不顺，说白了就是改字改句的那种活，通常比较简单、比较快，有时可能十几分钟就扫完了。另一种是打开原始材料，确认来源是不是存在，数字是不是对得上，引用是不是真的支持结论，这种事情一般就麻烦很多。因为你要去找原文、核对数字，而不是只看成品的表面样子。这两种事情，人和工具都是可以做的。 但是只做前面一种，文件可以像真的；做了后一种，文件才有可能真的就是真的。从澳大利亚公开说明里也能看到另一面：他们为政府做报告，在交付前也改掉了一些错误，但是他们没有发现全部问题。外部媒体就几个引用追问了之后，他们又做了一次更全面的复核。 又找出了更多不准确的输出，最后还得准备更正版本。 你看流程上写着需要review，规定等于错误就能全部识别。 “审核过”这三字要拆开看：谁审的？审的什么？按什么标准审的？ 另一边，著名的开源项目L的维护者说。 2025年，大约五分之一的安全报告被团队归为低质的AI报告。 一份报告通常要牵扯到三到四名安全员，每个人可能要花半个小时，也有可能是三个小时。所以如果解决办法只是让所有人都从头看一遍，验证债务没有消失，你只是新建了一个专门还债的部门罢了。 所以那到底要怎么办呢？我去找了几家真正在做这件事情的公司，比如说像GitHub、SRPQ、OpenAI、微软、AWS。 这些公司他们用的词可能不一样，但是方向都非常接近了：就是AI生成的先算了后选结果，不算已完成，机器先做能自动做的检查，高风险和待判的问题再交给人来放行。 这和所有内容都人工重新审一遍、同做一遍不是一回事。 它在生成和交付之间加了一道看得见、留得下证据、也有人负责的门。 其实程序员早就有一个待整合区，叫做pre-request，简称PR。你不懂这个词没关系，它就像一个透明的、带权限的文件夹。 里面包含了改了什么、测试过没有、谁提交的、谁审的，都能看得见。如果没有通过，就不能进入正式的版本。 GitHub对口牌的Coding Agent的设计就很具体。 AI可以单独在分身上写代码，还提个PR，也会做安全检查，并留下会话日志。 它不能自己审自己的PR，不能批准也不能合并。 仓库如果要求独立批准，叫AI来干活的那个人也不能用自己的批准来凑数。 翻成大白话就是，AI可以交作业，也可以先自检，但是不能给自己100分，更不能自己宣布这份作业我已经正式完成生效了。 SRP的官方最佳实践里也有一个很关键的判断：如果没给Claude配置能运行的检查，比如说测试、构建或者前后的截图，那它只能在看起来做完的时候停下来，而你就会变成那个做验证验收的人。 所以他建议让AI跑检查、读取结果、继续修改，最后交出测试和截图证据。 重要的任务还可以让一个独立的新审查者尝试推翻原有的结论。 OpenAI的官方指南则建议按照风险分级，超过失败次数、遇到敏感、不确定的高风险动作，就把控制权交回给人。 你会发现这些公司不是更相信AI，他们只是更早地承认AI的答案需要进入一套验证系统，而不是直接交给下一位同事。 普通公司不需要照搬程序员的那一套术语，但可以照搬这条边界：第一，AI生产的东西默认就叫草稿，或者叫候选结果，不能叫完成品。 从脑风报找方向，列一些选项，可以轻量使用。但对外的材料、财务数据、法律内容、生产代码这些高风险的成果，必须经过明确的放行才行。 第二，不要只交一份文件，要让这些证据跟着结果一起走。将来源原始数据、测试结果，哪些核对过、哪些还不是很确定的，都应该放在一起交。下游检查证据，而不是重新考古上游到底做过什么。 第三，把生成和批准拆开。谁借助了AI生成，谁先还了第一轮验证的债务，风险越高，最后放行的人越要独立。还要说清楚谁生成的、谁批准的，真正出错了谁来修。用一句话就是：AI可以先自检，但不能自批。 结果和证据一起交，风险越高，放行越独立。这也不只是员工个人自觉的问题。如果公司只讲一味追求最快交出第一版，却不记录返工核验和最后承担风险的人，那把债务往下甩反而变得很合理了。真正要改的是交接表、验收标准和绩效机制里面，对“完成”这两个字的定义。 所以下次再收到一份AI材料，别只问“这是不是AI写的”，你可以问三件事：这是草稿还是正式交付的东西？证据在哪里？哪些没有核对过？没基准的话，出了错谁来修？这三件事答不出来，它不是不能看，它应该叫草稿，它不应该叫完成品。 AI真正倒逼每个组织重新回答的，不是东西能不能写得更快，而是到底谁有资格说这件事情已经完成了。 所以下次再有人跟你说，这个是AI写的，我也不清楚。你可以这样反问他一句：你都不清楚，那这个东西为什么到我这里呢？不知道你们在工作中有没有碰到过类似这样的情况，就是他用了AI省了事，最后却变成了你来查的情况。欢迎大家一起交流一下。