Claude Code 负责人 Boris 在公开分享里反复提到过一个团队内部很在意的东西：自我验收闭环。简单说，就是每个任务不能只做到“代码跑起来”就结束，而要有一套明确的验收机制，让 AI 和开发者都能确认“这个事真的按要求做完了”。我看到的很多讨论都集中在 Claude Code 怎么安装、怎么在 VSCode 里配置、怎么接入不同模型，这些确实是入口问题，但长期用下来真正拉开效率差距的，不是启动得顺不顺，而是任务有没有进入验收闭环。这篇文章就把我理解到的 5 个底层习惯拆开讲，并结合实际落地场景补充一些可执行的配置、步骤和排查思路。
先说明一点：我没有拿到 Boris 那份分享的完整逐字稿，下面讲的不是原话复述，而是从公开观点和实操经验里提炼出的工作方法。如果你正在用 Claude Code 做实际项目，或者打算把这类 AI 编程工具接入日常工作流，这篇内容可以直接当成一份“如何用 Claude Code 构建自我验收闭环”的操作参考。
1. 先搞懂“自我验收闭环”到底在解决什么问题
1.1 代码能跑不等于任务完成
很多 AI 编程工具会给人一种“活已经干完了”的错觉。模型根据你的描述生成一段代码，终端里没有报错，文件也写出来了，看起来一切正常。但真正用起来之后，问题才会暴露：输出文件是空的，字段格式不对，处理到一半遇到异常输入直接退出，重复运行一次结果不一样，甚至只是路径写死导致换台机器就崩。
这些情况都不算“任务完成”。Boris 强调的自我验收闭环，核心就是把“完成”重新定义成“验证通过”。所谓验证通过，至少包括几个层面：
- 输入明确，并且处理了边界情况。
- 输出存在，内容完整，格式符合预期。
- 关键路径上没有报错，异常输入有明确反馈。
- 同样的输入重复执行，结果稳定一致。
- 修改后的代码没有破坏原有功能。
如果缺少这套标准，AI 生成的代码很容易停在“看起来能用”这个阶段。尤其当任务比较复杂时，模型会基于上下文补全答案，它不会像人一样主动意识到“我没有处理空文件”“我没有检查写入权限”“我没有验证结果是不是乱码”。这时候就需要外部定义一套验收规则，让 AI 在每个环节都能对照判断。
1.2 为什么 Claude Code 这类工具特别需要验收闭环
Claude Code 不是一个普通的聊天窗口，它可以被配置成真正参与项目开发的工具：读取文件、修改代码、执行命令、调用脚本、处理批量任务。它的能力越强，越需要明确的验收边界。如果你只说一句“帮我处理这些文件”，它会按照模型自己的理解去生成结果，但这个理解未必是你的验收标准。
实际使用中，最有价值的做法是把验收标准提前写进任务描述里。比如“处理完成之后，输出一个 summary.csv，并确保每条记录都有 id 和 status 字段，失败记录不能静默跳过”。这样 Claude Code 在开工前就会知道自己要交付什么，过程也会向着这个标准靠近。
另一个现实问题是，很多人的使用场景并不是单次会话，而是长期、批量、反复运行的任务。比如每天生成一批报告，定期整理一批文档，批量转换一批文件。这种场景下，如果没有自我验收闭环，第一次成功不代表第二次成功，一个文件成功也不代表所有文件都成功。日志、输出状态、失败重试、结果核对，这些平时容易被忽略的东西，恰恰是闭环能否成立的关键。
所以我的判断是：安装 Claude Code、配置 VSCode 插件、接入模型，都只是工具准备阶段；真正的技术含量在任务定义和验收机制设计上。下面这 5 个习惯，就是围绕这个核心展开的。
2. 习惯一：启动任务前先写可勾选的验收清单
2.1 把验收标准写进任务描述和 CLAUDE.md
如果你让一个经验不足的工程师去改代码，他大概率会问：“改到什么程度算完成？需不需要处理异常？输出格式是什么？”AI 也一样。你不给验收标准，它就按自己的默认逻辑发挥。更麻烦的是，它可能还会很有礼貌地告诉你“已完成”，但实际结果经不起验证。
所以第一步是养成“写验收清单”的习惯。在每一次任务开始前，不要急着让 Claude Code 动手，而是先列出几条可勾选的标准。比如：
任务：将 input/ 目录下的 Markdown 文件批量转为 HTML。 验收清单： 1. 每个 .md 文件都生成对应的 .html 文件。 2. 输出文件命名与输入文件保持一致，仅在扩展名上不同。 3. 生成的 HTML 可以在浏览器中正常打开，包含标题和正文。 4. 转换失败的文件必须记录到 errors.log，不能静默跳过。 5. 重复运行不会重复生成文件，也不会覆盖已有成功结果。这种描述比“帮我把 Markdown 转成 HTML”清楚得多。Claude Code 在执行时就能知道自己每一步有没有偏离目标。
更长期的做法是把它固化到项目里。Claude Code 支持通过配置文件或项目级说明文件（比如 CLAUDE.md）来注入项目规范和约束。可以在里面固定一个“完成标准”小节，长期告诉模型：你在这个项目里干活，必须遵守这套验收逻辑。
项目级验收规则： - 每次修改后必须运行项目自带的测试命令。 - 测试通过后才能标记任务完成。 - 所有输出文件必须写入 outputs/ 目录，并按日期归档。 - 遇到无法处理的情况，要输出原因和上下文，不能只给结论。这样每次会话开始，模型都会把这些规则当成默认行为来理解。
2.2 验收清单要包含输入、输出、边界和失败条件
验收清单不是简单写一句“结果要正确”，而是要把范围收紧到能判断、能勾选的程度。我一般建议至少覆盖四类信息：
| 类型 | 要写清楚的点 | 示例 |
|---|---|---|
| 输入 | 处理什么文件、什么格式、放哪里 | 处理 input/ 下所有 .csv 文件，UTF-8 编码 |
| 输出 | 输出什么、命名规则、保存位置 | 每个输入对应一个 .json 文件，写入 output/ |
| 边界 | 空文件、超大文件、异常字符怎么处理 | 空文件跳过并记录，超过 10MB 的文件单独标记 |
| 失败条件 | 什么情况算失败，失败后怎么办 | 解析失败时写入 errors.log，退出码为 1 |
这看起来是工程管理的事，但对 AI 工具特别有效。因为模型在生成代码时，如果你明确了空文件要跳过，它就会在代码里写对应的判断；如果你没写，它大概率会假设输入都是正常的。
我自己的经验是，验收清单越具体，后期排查越省力。很多看起来“模型不行”的情况，追根到底其实是任务描述里没有定义好边界条件。比如结果乱码，可能是编码没写清楚；输出文件缺失，可能是目录权限不对；处理到一半卡住，可能是有个文件格式特殊导致脚本进入了死循环。这些在验收清单里只要多写一句，就能少踩一个坑。
3. 习惯二：让 AI 先输出自测计划，再动手改代码
3.1 从“直接生成结果”改成“先生成验证方案”
Claude Code 这类工具执行任务时，通常会自动拆解步骤。但默认状态下，它更关注“怎么把功能写出来”，而不是“怎么证明功能是对的”。打破这个局面最简单的办法，就是在任务开头加一个要求：先给自测计划。
我常用的方式是，在任务描述最后追加一句：
开始之前，先输出你的验证方案。你要用什么数据、什么命令、什么指标来判断改动成功了？确认方案可行后再动代码。这一步非常有用。它强制模型把注意力从“实现”拉回到“验证”。比如你要它修改一个数据清洗脚本，它如果先说出“我会用包含空值和重复值的小样例文件跑一遍，检查输出行数和字段值”，那么后续实现就会围绕这个验证方案展开。
反过来，如果模型说不出验证方案，或者方案非常空泛，那说明它对任务的理解还不够。这时候继续让它写代码，大概率会写出一个没有验证依据的东西。宁可多花几十秒把验证方案想清楚，也不要让一个无法验收的改动进入代码库。
3.2 用最小样例验证，不要一上来开并发
在自测计划里，最优先做的一定是最小样例验证。也就是先拿一条数据、一个文件、一个用户请求，把整条链路跑通。这一步通过之后，再考虑批量、并发、长耗时的完整场景。
为什么要把这一步放得这么靠前？因为小样例能最快暴露基础问题：路径不存在、编码不对、依赖没装、配置项名字错了、模型不认识当前参数。这些问题在大规模运行前发现，成本最低。
我一般会这样安排验证顺序：
- 先用一个最小输入跑一遍，确认能启动、能输出、日志正常。
- 检查输出内容是否符合验收清单里的字段和格式要求。
- 手动制造一两个异常输入，确认失败路径也有反馈。
- 所有单条验证通过后，再开始批量任务。
不要一上来就开最大并发。很多工具给你设置了并发参数，看起来能加速，但一旦输入文件有问题，并发越高，失败扩散得越快。日志混乱，输出文件互相覆盖，排查起来极其痛苦。正确做法是先用小规模验证稳定性，再逐步提高并发。
注意：如果输出为空，先看输入格式和日志，不要急着调整模型参数或并发数。大部分空输出问题来自文件路径、权限、编码或输入内容本身。
4. 习惯三：每个改动都留日志和可复现证据
4.1 日志不是写给用户看的，是给验收闭环用的
如果你只让 Claude Code 生成一段代码，然后看它“没有报错”就觉得成功，那等于放弃了验收依据。真正稳定的工作流，必须留下可复现的证据。日志就是最直接的证据。
我建议每个任务都要求模型或脚本记录以下信息：
- 任务开始时间和结束时间。
- 输入文件路径、数量、大小。
- 每个文件的处理结果：成功、失败、跳过。
- 失败原因和上下文。
- 输出文件路径和校验方式。
- 如果做了批量处理，还要记录当前进度。
这段信息不需要很复杂，但必须统一格式。比如每一行日志都带时间戳、任务 ID、状态码和消息内容。这样一旦出现问题，你可以直接翻日志定位是哪一批任务、哪一个文件、在哪一步失败的。
Claude Code 本身在执行任务时会输出过程信息，但如果你在脚本或 Skill 里加入自己的日志逻辑，信息会更贴合你的业务场景。尤其是批量任务，只有统一的业务日志，才能回答“这一百个文件里哪几个失败了、为什么失败、输出是否完整”这类问题。
4.2 输出命名、目录结构和错误码要统一
日志之外，输出物本身也要有规则。最常见的问题就是输出文件命名混乱。第一次运行生成 result.csv，第二次运行生成 result_final.csv，第三次又生成 result_final_v2.csv。最后根本分不清哪个是有效结果，哪个是中间产物。
在自我验收闭环里，输出文件必须是可追踪的。我建议至少做到：
- 使用固定命名规则，比如“任务ID_批次号_文件名”。
- 每次运行写入独立的输出目录，避免覆盖历史结果。
- 成功结果和失败结果分开存放。
- 使用统一的错误码，比如 0 表示成功，1 表示输入错误，2 表示运行时异常。
这里可以做一个简单对比：
| 混乱做法 | 闭环做法 |
|---|---|
| 输出到当前目录，文件名随意 | 输出到 outputs/日期/，文件名包含任务 ID |
| 失败时直接退出，没有日志 | 失败时写 errors.log，并标记该任务为 failed |
| 重复运行覆盖旧结果 | 每次运行创建新批次目录，保留历史记录 |
| 报错信息是一段英文堆栈 | 统一记录错误码、文件路径、失败阶段 |
这些做法看起来基础，但真正坚持下来的人不多。很多人到了排查问题时才发现，连“哪次运行产生了这个文件”都说不清楚。到这个时候，模型能力再强也帮不了你，因为现场已经被破坏掉了。
我自己的习惯是，在任务描述里就把输出规则写死。比如：“所有输出文件必须写入 outputs/task_20250101/ 目录，成功文件后面加 _ok，失败文件加 _failed，并保留原始文件名。”这样 Claude Code 生成的代码也会自动遵循这套规则，后续核对就非常轻松。
5. 习惯四：修复问题后必须重新跑一遍完整验证
5.1 修一个 Bug 容易引入另一个 Bug
AI 生成代码和人类写代码有一个共同点：修一个 Bug 的时候，很容易在另外一个地方引入新问题。尤其是当任务涉及多个文件、多条处理路径时，局部修改可能影响全局行为。
很多人拿到 Claude Code 改完的代码，看到最初那个报错消失了，就认为任务完成。但报错消失不等于验证通过。更稳妥的做法是，在修复完成后，把验收清单重新执行一遍，确认原来的功能没有被破坏。
我一般把这种验证分成两层：
- 最小回归：跑一遍上次失败的那条路径，确认问题被修复。
- 完整回归：把验收清单里的所有标准重新过一遍，确认没有引入新的偏差。
如果项目有自动化测试，这个步骤可以靠测试命令解决。如果项目没有测试，至少要把验收清单手工执行一遍。对于批量任务，还要额外检查之前已经成功的文件有没有被这次修复影响。
5.2 用回归清单守住边界
回归验证的核心，是维护一份“已经确认过没问题”的清单。这份清单不是上线前才写，而是随着任务推进不断累积。
举个例子。你让 Claude Code 写一个图片批量压缩工具。第一轮它输出一张压缩图，尺寸和大小都符合预期，你验收通过。第二轮修复了文件名乱码问题，这时不仅要检查乱码问题是否解决，还要再检查第一轮的压缩图是否仍然能正确生成。因为修复可能改动了公共逻辑，导致原本通过的路径也变了。
回归清单可以很简单，就是几条可以反复执行的用例：
回归用例： 1. 输入单张 JPG 图片，输出格式为 WebP，大小减少至少 50%。 2. 输入 PNG 透明图片，保留透明通道。 3. 输入文件名为中文和空格，输出文件名保持可读且不报错。 4. 批量处理 100 张图片，中途有一张损坏图片失败，整体任务不中断。每次修改后跑一遍，只要能全部通过，这次改动才算真正完成。如果有一项失败，那就说明修复还不完备，需要继续迭代。
这里要特别提醒一点：如果任务里涉及批量队列、断点续跑或失败重试，回归验证一定要包含“中断恢复”的场景。也就是模拟任务跑到一半，人为终止，再重新启动，看看它能不能跳过已经成功的部分，只处理未完成的部分。这个场景最容易出问题，但也是批量任务里最常用的能力。
6. 习惯五：把验收闭环固化成自动化流程
6.1 用 Skill、脚本或自定义指令固化
临时写验收清单，还是靠人的自觉；只有把验收逻辑固化到工具链里，才真正算形成了闭环。Claude Code 支持 Skill、项目配置、命令行调用和自定义脚本，这些能力都可以用来承载验收流程。
我最建议的方向是：把“任务启动前输出验收清单”“任务结束后检查输出证据”变成一个固定流程，每次会话开始自动加载。比如在项目的 CLAUDE.md 里写上：
工作流程： 1. 收到任务后，先根据任务类型创建验收清单。 2. 在动代码前，把验收清单展示给用户确认。 3. 实现过程中按清单逐项检查。 4. 任务完成后，执行验收清单中的每一条验证命令。 5. 所有验证通过，才允许报告完成。如果你愿意做更多定制，可以写一个验收检查脚本：
# 示例：验收检查脚本，实际内容按项目调整 python scripts/validate.py --input outputs/task_20250101 --check-manifest manifest.json脚本的作用不是搞得很复杂，而是把“人肉验收”变成“代码验收”。比如检查文件是否存在、文件大小是否超过阈值、行数是否匹配、是否有错误日志生成。这些规则一旦写成脚本，每次任务结束都能自动跑一遍。
6.2 批量任务要单独设计失败重试和断点续跑
最后这个习惯，针对的是“看起来支持批量，但实际跑不稳定”的常见困境。很多人发现，Claude Code 单条任务处理得很好，一旦进入批量模式，可能出现：某个文件格式特殊导致整个队列中断、失败后没有记录、重新启动后从头再来、输出文件被覆盖等问题。
这不是说明工具不行，而是批量任务本身需要额外设计。我建议至少做好三件事：
第一，每个子任务都要有独立状态记录。处理前标记 pending，成功标记 done，失败标记 failed。这样即使任务中断，也能快速知道哪些文件还没处理。
第二，失败任务不能静默跳过。要么记录到独立日志，要么在最后生成失败报告，方便你决定是重试还是人工介入。
第三，重新运行时支持断点续跑。判断逻辑很简单：如果输出文件已存在并且状态为 done，就跳过；否则重新处理。
这里还要提一个和模型接入相关的细节。如果你在使用 Claude Code 时配置了第三方模型，或者切换了模型版本，可能会遇到“某个模型名不被当前版本识别”这类报错。这类问题看起来像模型配置错了，实际上很多是版本兼容问题。先确认 CLI 版本，再检查配置里的模型名是否和当前版本支持的模型列表匹配。不要一报错就去改模型参数，很多问题改完也没有变化，因为根因根本不在这里。
我曾经在批量任务里遇过类似情况：任务跑完前 100 个文件都很正常，第 101 个文件开始全部报错。当时第一反应是数据有问题，后来看日志才发现是输出目录已经写满，磁盘空间不足。这类问题只有靠日志和状态记录才能快速定位。如果当时没有统一的状态文件，根本不知道是从哪个文件开始失败的。
注意：批量任务不能只验证“能不能跑”，还要验证“失败后能不能恢复”。把断点续跑和失败重试纳入验收标准，远比单纯提高并发数更重要。
7. 落地时会踩的坑和排查顺序
7.1 先看现象，再看输入和环境
自我验收闭环建立起来后，依然会遇到各种报错和异常。这时候最忌讳的是直接找模型要答案，或者凭感觉调参数。更稳妥的做法是走一遍固定排查顺序。
我通常按这个顺序查：
- 先看现象：是报错、卡住、无输出，还是输出内容不对。
- 再看输入：文件是否存在、路径是否正确、编码是否符合要求、内容是否完整。
- 再看环境：依赖版本、权限、磁盘空间、网络、端口冲突。
- 再看配置：模型名、参数、输出目录、并发数、超时时间。
- 最后看工具本身：是不是版本太旧、功能是否支持当前输入、是否需要对配置文件做调整。
这套顺序看起来简单，但能解决大部分问题。比如 Claude Code 运行时提示找不到 CLI，很多是安装后 PATH 没有刷新，或者终端没有重新打开。VSCode 里配置插件后无法调用命令，很多时候是插件配置的 shell 环境不对，而不是模型问题。输出结果乱码，优先检查输入编码和终端编码，而不是急着调整模型温度。
7.2 配置、路径、权限和日志是重灾区
如果把所有坑按出现频率排序，配置、路径、权限和日志绝对排在前几名。
路径问题最隐蔽。比如 Windows 下路径包含反斜杠，在脚本里如果没有正确转义，就会导致文件找不到。目录名含空格或中文，也会在某些脚本中引发奇怪的报错。解决办法很简单：路径统一用正斜杠，或者在脚本里先解析成绝对路径，然后在日志里打印出来确认。
权限问题通常在写入阶段暴露。比如输出目录不存在、没有写入权限、磁盘满了等。这些问题往往要到任务跑到一半才出现。如果验收清单里明确写入“执行前检查输出目录是否可写”，就能提前拦截。
日志问题，则是“平时不觉得重要，排查时才知道救命”。我强烈建议在每一次任务里都保留一份“原始过程日志”。不要只给 Claude Code 一个“最终结果”，过程中哪一步执行了什么命令、输出是什么、有没有报错，都要有记录。这些日志不仅是验收证据，也是模型调试的依据。
如果实在不知道怎么入手，可以先从一次小任务开始练：选择一个真实的小文件，写一份包含输入、输出、边界、失败条件的验收清单，然后让 Claude Code 完成任务，并在结束后检查日志和输出文件。能把这个小闭环跑通，再逐步放大到批量和长期任务。
最后回到 Bori s 强调的那句话给我的感受：真正厉害的团队，不是让 AI 一次生成很多代码，而是让 AI 每次交付都经得起验证。工具会变，模型会升级，但“先定义完成标准，再执行，再验证”这套底层习惯不会过时。如果你正在用 Claude Code，或者准备用，我建议先从这 5 个习惯里挑一个开始落地。先让“验收”这两个字出现在你的任务描述里，比换任何模型、调任何参数都更有效。
