AI 输出完成了，怎样判断可以交付？用五项检查收尾 - AIPlan

判断标准只有一条：输出里每一个可被外部核查的点，你都能指出它出自哪里。做不到这一条，它还是草稿。五项检查按顺序过一遍，通常 10 到 30 分钟能筛掉大部分不能交付的内容。较短的交付物约 2000 到 3000 字，一轮完整核对大约 15 分钟；超过 10000 字的材料，至少要留 40 分钟。 第一项：事实能不能指回来源 把输出里所有数字、日期、人名、专有名词圈出来，每个都问一句“这个数从哪来”。能指回官方页面、原始文件、你自己提供的材料，算过关；只能指回“模型说的”，算未验证。 这一项最容易漏的是看起来最普通的数字。模型写“支持 512 MB 上传”，这个数字有出处；写“大多数用户三秒内得到回复”，这个数字没有出处。 做这项工作有省力的方法：让模型自己把每个引用标出来，再逐个核对。核对是可以抽样做的，但抽样的比例不能低于 30%，且必须包含全部数字类断言。 第二项：完整性有没有缺口 列一份交付清单，逐条对照。文章类看：标题、导语、每个小节的结论、表格、结尾动作。代码类看：功能、错误分支、日志、测试。表格类看：行数、列名、合计、空值处理。 缺口有两种。一种是少了一块，肉眼可见；另一种是“看起来完整但错位”，比如小节标题写“价格对比”，内容讲的是功能差异，这种只有逐节读标题与内容才能发现。一份 6 个小节的稿子，逐节比对大约 5 分钟。 判断阈值：如果交付物要给别人用，缺口数为 0；如果只是自己下一步的输入，允许 1 到 2 处待补，但要在文件里显式标注，不要留在脑子里。 第三项：格式和约束有没有守住 格式问题看着小，返工成本高。常见的四类： 字数或长度不达标，交上去被打回；结构化字段缺失，下游程序解析失败；单位不统一，同一张表里既有美元又有人民币却没有换算列；标点与排版不一致，中英混排时引号与空格乱掉。 AI 生成内容在这四项上的失效率不低。稳妥做法是把约束写成可执行的检查：字数用脚本数一遍，JSON 用解析器验一遍，单位在表头写清币种。以一篇 3000 字的稿子为例，脚本校验 3 秒出结果，人工通读要 8 到 12 分钟。 这一步能自动化的就自动化。人工肉眼数 3,000 字，比写一行命令慢得多，也更容易出错。 第四项：权限与敏感信息 交付前问三个问题：这份内容里有没有超出接收范围的信息？接收方有没有权限看？有没有把凭据、内部链接、个人邮箱带出去？ 具体要扫的东西：API key 形态的字符串（sk- 开头的一长串）、Session JSON 里的 accessToken 与 sessionToken、内部系统地址、真实用户手机号与邮箱、未公开的价格表。 这一项没有“差不多”的余地。一旦带出去，撤回的成本远高于事前检查。做法很简单：交付前全文搜索 sk-、token、@、http 四类字符串，逐个确认。 第五项：能不能复用 最后一项决定的不是这次能不能交，而是下次要不要重做。 可复用的标志是：输入有模板、判断有阈值、步骤有顺序、失败有兜底。四项齐了，下一次同类任务可以直接套；缺两项以上，说明这次是靠临场发挥做完的，下次还得从头来。 举个具体例子。让模型整理会议录音，如果只得到一份纪要，那是交付。如果同时得到“录音 → 转写 → 按议题分段 → 每段提取决议与待办 → 输出表格”这套固定步骤，下次换一段录音仍能照做，那才是可复用。 三项状态要分清：草稿、已验证、可交付 很多返工来自把三者混为一谈。 草稿是模型刚生成的版本，允许有缺口和未核实数字。已验证是事实核对过、格式检查过，但还没经过使用者确认。可交付是可以直接发出去、出了错要负责的版本。 只有第三态才需要签字式的自查。第一态花 30 分钟做完整核对，是浪费；第三态跳过核对，是事故。 一个实用的做法是在文件名或版本号上体现状态，例如 -draft、-checked、-final。团队里三个人协作时，这个约定能省掉大量“这是最终版吗”的对话。 把五项做成一张可打勾的表 检查项 通过标准 常见失败 事实 每个数字有出处 引用模型自述 完整性 清单缺口为 0 标题与内容错位 格式 脚本校验通过 单位不统一 权限 敏感串为 0 带出 key 或邮箱 复用 四项模板齐备 只交结果不交步骤 五项全过，交付；过 4 项，按缺口性质决定是当天补齐还是次日补；过 3 项及以下，退回重做往往比修补更快。 一个具体的代码场景 假设模型给你改完了一个函数。事实层要核对：调用的函数名真的存在吗，参数顺序对吗。完整性层：错误分支处理了吗，空输入会怎样。格式层：gofmt 过了吗，go vet 干净吗。权限层：有没有把测试环境的密钥写进代码。复用层：这次的修法能不能抽成工具函数。 这五层里，事实与格式两层几乎必须靠工具验证，肉眼看不出来。跑 go vet ./... 和 go test ./... 是几分钟的事，跳过的代价可能是上线后才发现。 关于让模型写测试的顺序，可以参考 先写测试再让 Codex 改代码；事实核对的通用方法在 回答里的事实怎么核。 收尾时只做一件事 把交付物和五项检查表一起存档。不是为了留痕，是为了下一次同类任务能直接复用这张表：哪一项在这类内容上最容易失败，下次就把它放在最前面检查。 表里的阈值与检查项按 2026 年 10 月 18 日的实践整理，模型能力变化后，某些项目的失败率会变，阈值也应随之调整。 如果你打算把日常的高频任务固定下来，Plus 月卡 ¥115.50 对应的档位包含 Projects、Scheduled tasks 与 Codex 额度，适合把流程沉淀成可重复的模板；注意它只能给没有生效中 Plus 的账号充值，到期后再下单续。 参考资料资料核对日期：2026-10-17 • Text generation • Data analysis with ChatGPT | OpenAI Help Center • Code review 延伸阅读• 怎样检查 ChatGPT 回答是否可靠？先查最影响决定的三句话 • 用 ChatGPT 画数据图：先确定这张图要回答什么 • 让 Codex 写测试：先问这条测试能发现什么错误 • AI 幻觉核查:ChatGPT 给的信息如何验证:官方+第三方对齐方法