Claude Code团队5个底层习惯：用自我验收闭环打造可靠AI编程工作流

这篇文章想聊的是 Claude Code 团队负责人 Boris 最近公开分享的 5 个底层习惯。它的关键词不是“怎么更花哨地使用 AI”，而是一个看起来朴素、实际工程价值很高的概念：构建自我验收闭环。站在一线开发者的角度看，很多团队用 AI 编程工具时都会遇到“代码能生成，但没人敢合入”的尴尬局面，这套习惯恰好提供了一套可以复用的解法。

本文会把这 5 个习惯逐一拆开，讲清楚背后原理，再结合 Claude Code 的 CLAUDE.md、settings.json、自动测试、skills 等实际玩法，落到一个可运行的完整项目中。无论你是刚接触 Claude Code 的新手，还是正在团队里推行 AI 编程规范的 Tech Lead，都可以对照这篇文章搭建自己的闭环流程。

1. 背景与核心概念

1.1 Claude Code 是什么

Claude Code 是 Anthropic 推出的终端 AI 编程工具，可以理解为跑在命令行里的 AI 结对编程助手。和普通聊天式 AI 不同，Claude Code 不是一个只会给建议的对话框，而是一个具备行动能力的智能体：它能读取项目目录、分析代码结构、编辑文件、执行 shell 命令，然后把运行结果继续反馈给模型本身，形成“思考-行动-观察-再行动”的工作循环。

这个差异非常关键。普通 AI 助手帮你“写”代码，但它看不到代码真实运行的情况；Claude Code 则可以帮你“跑”代码，再把测试输出、构建日志、报错堆栈拿回来继续修正。换句话说，Claude Code 更像一个能实际干活的实习生，而不是一个只动嘴的顾问。

既然它能动文件、能跑命令，就带来一个现实问题：如果模型写完了代码却没人验证，项目可能被“自信地改坏”。因此，团队内部格外强调“自我验收闭环”——让每次产出都经过可自动验证的检查，验证通过才算真正完成。

1.2 什么是自我验收闭环

自我验收闭环，用一句大白话说就是：AI 写的每一段代码，都必须能自己证明它是好的。

拆开来看，闭环包含三个环节：

• 验收标准：在动手之前，先定义“完成”到底是什么。例如“所有 pytest 用例通过”“构建无报错”“接口返回状态码符合预期”“lint 检查零错误”。
• 验证动作：真实去执行验证命令，而不是靠模型“觉得没问题”。常见动作包括运行单测、跑构建、执行静态检查。
• 结果闭环：验证失败后，模型要能看到报错信息、分析根因、修改代码，然后重新验证，直到全部通过，或主动上报阻塞点。

这个闭环和传统开发的“写完自测”非常相似，只不过把验证的责任也交给了 AI 工具。人工不再需要每一步都盯着，而是把重点放在定义标准、评审结果和兜底拦截上。

1.3 为什么这个闭环必须被认真对待

人写代码时，天然承担了验证责任。写完会编译、会跑一下、会看报错。但大语言模型生成代码时，本质上是在做概率预测：它并不知道生成的代码在你的环境里能否跑通，也不知道它改的 A 函数会不会破坏 B 模块。

没有闭环约束时，常见翻车场景包括：

• 模型生成了结构完整的代码，但依赖没装、字段名对不上、函数未定义；
• 模型只盯着当前任务，改完一个接口后，另一个模块的测试挂了但毫无感知；
• 模型第一次测试失败后，给出了一个“看起来合理但没有跑过”的修复；
• 多轮对话后，项目目录里多出大量无关改动，最终需要人工大返工。

Boris 公开的 5 个底层习惯，本质上就是为了避免这些问题。它不追求让 AI 一次写对，而是追求让 AI 在一个可验证的闭环里迭代。这个思路对个人开发者和团队协作都有很强的现实意义。

2. 环境准备与版本说明

2.1 操作系统与运行环境

Claude Code 主要面向开发终端场景，支持 Windows、macOS、Linux 三大主流平台。本文示例以常见终端环境为主，重点演示配置思路，具体版本请以你当前安装的 Claude Code 版本为准。

因为 Claude Code 更新节奏比较快，不同版本对配置项的支持可能有细微差异。所以下面所有配置代码，我都会标注“示例思路”，你在使用前最好先确认当前版本的帮助信息，避免照搬后不生效。

2.2 安装 Claude Code 与核心依赖

安装方式以官方文档为准。社区里常见的方式是使用 npm 全局安装 Claude Code 对应的 CLI 包，也可能是官方提供的安装脚本，macOS 和 Linux 还能通过包管理工具处理。在 Windows 上安装时，建议提前确认 Node.js 环境变量和终端权限配置。

安装完成后，在终端执行：

claude --version

如果命令能正常输出版本号，说明 CLI 已经可用。如果提示claude: command not found，说明安装目录没有加入系统的 PATH，需要手动配置环境变量。

2.3 配置文件位置与版本差异

Claude Code 的配置分为用户级和项目级。用户级配置通常写在用户主目录下，例如~/.claude/settings.json；项目级配置则放在当前项目目录下，例如.claude/settings.json。项目级配置更适合团队共享，可以把团队规则提交到 Git 仓库中。

另外，Claude Code 还会读取项目根目录的CLAUDE.md文件，把它作为项目的背景规则。这篇文章后面会大量使用CLAUDE.md来实现“自我验收闭环”，这也是 Boris 团队习惯中的关键落地工具。

需要特别提醒：不同版本的 Claude Code 对配置文件的位置、字段命名可能不同。建议在修改配置前先查看当前版本的文档或帮助命令，确认字段是否仍然有效。

3. 五个底层习惯的整体框架

3.1 一张表看全五个习惯

在展开细节前，先用一张表把五个习惯串联起来。这张表可以直接贴到团队文档里作为 AI 编程规范参考。

整体来看，习惯 1 解决“目标不清”，习惯 2 解决“验证缺失”，习惯 3 解决“问题发散”，习惯 4 解决“改动失控”，习惯 5 解决“重复踩坑”。五个习惯合起来，就是一个可以在团队中复制的自我验收工作流。

3.2 核心逻辑：把验收前置

这五个习惯里，最容易被忽略也最值得强调的是“验收前置”。很多开发者使用 AI 编程工具时，惯性思维是先给任务，让模型写，写完再人工检查。但 Boris 团队的做法正好相反：先明确验收标准，再让模型动手。

为什么先写验收标准更有效？因为大模型是目标驱动的。你给它的验收标准越具体，它生成代码时就越有约束。比如你说“请完成用户登录接口”，模型可能写出各种风格、各种边界处理的版本；但如果你说“完成登录接口，要求使用 POST /api/login，参数为 username 和 password，返回 JSON 格式的 token，并用 pytest 覆盖正常登录、密码错误、用户不存在、参数缺失四种场景”，模型的产出就会明显收敛。

这种差异不是模型突然变聪明了，而是你把“验收闭环”的起点提前了。后面四个习惯，都是在保障这个闭环能够真正跑起来。

4. 习惯一与习惯二：验收前置与自动验证

4.1 验收标准要具体到可自动判断

在 Claude Code 里直接说“帮我优化登录模块”，模型根本不知道怎样算“优化完成”。你需要给它一份能自动判断的完成条件。这里推荐一种格式：

任务目标：修复用户登录模块的密码校验 bug。 验收标准： 1. 密码错误时，接口返回 401，错误码为 PASSWORD_ERROR； 2. 用户不存在时，返回 404，错误码为 USER_NOT_FOUND； 3. 参数缺失时，返回 400，错误码为 PARAM_MISSING； 4. 上述场景都有对应的 pytest 用例； 5. 运行 pytest 后所有用例通过。

你可以直接在对话中把这份验收标准粘贴给 Claude Code，也可以写入项目的 CLAUDE.md，让模型每次启动项目后都能读到。

这种写法的好处在于，每一条标准都能被脚本检查。模型不是靠“感觉”告诉你完成了，而是必须通过运行测试来证明自己完成。如果测试没过，它就不能声称任务结束。

4.2 让模型自己跑测试，别只写不跑

第二个习惯是让 AI 自己执行测试命令。很多初用 Claude Code 的人只把它当成代码生成器：模型写完代码，人拿去跑，跑挂了再粘贴报错回来。这种方式虽然也能形成闭环，但把最关键的一环留给了人工，效率很低，还会打断模型的上下文。

Claude Code 的定位是 agent，它可以在授权下直接执行命令。让模型自己跑测试，最大的价值在于：它能看到真实的失败信息、真实堆栈、真实测试输出，从而基于证据修正代码，而不是基于概率修正代码。

一个合理的循环是：

1. 模型修改代码；
2. 模型执行测试命令，例如pytest -v；
3. 测试通过，进入下一步；
4. 测试失败，模型查看报错并继续修改；
5. 重复执行，直到全部通过。

4.3 配置 Bash 权限，让验证命令可以顺利执行

默认情况下，Claude Code 遇到需要执行命令的操作时，会向用户请求授权。如果你希望模型自主完成“写代码-跑测试-改代码-再验证”的循环，可以提前把安全、验证类的命令加入 permissions 的 allow 列表，减少不必要的打断。

下面是一份 settings.json 示例，展示的是配置思路：

{ "permissions": { "allow": [ "Bash(pytest *)", "Bash(npm test)", "Bash(npm run build)", "Bash(git status)", "Bash(git diff)" ], "deny": [ "Bash(rm -rf *)", "Bash(git push *)" ] } }

强调一下：不同版本 Claude Code 的 settings.json 字段可能有差异，示例字段名仅供参考。配置前记得查看当前版本的帮助文档。

这里的核心原则是：鼓励模型执行验证类命令，但严格限制高风险命令。删除文件、强制推送、生产环境操作等命令必须保留人工确认，不能全放开。

5. 习惯三与习惯四：最小案例与回归确认

5.1 用最小可复现案例收敛问题

第三个习惯是“用最小可复现案例收敛问题”。当遇到复杂 bug 时，模型很容易陷入大规模排查、大规模修改的状态。它可能一边查 A 模块，一边改 B 模块，最后连它自己都不清楚项目被改成了什么样。

更稳妥的做法是让模型先构造一个最小可复现案例，把问题从复杂业务依赖中剥离出来，定位到根因，再动手修复。所谓最小复现，就是只保留触发问题所需的最少代码和依赖，去掉所有无关逻辑。

你可以这样约束 Claude Code：

不要直接修改项目代码。请先尝试构造一个最小可复现案例， 确保它能稳定复现当前问题。复现成功后再定位根因， 最后给出修复方案。修复时尽量小步改动，避免无关重构。

为什么这个习惯重要？因为很多隐藏 bug 都是被复杂业务逻辑包裹的。模型面对完整项目时，容易在多个模块之间反复跳转，改动的范围越来越大，最后花了很大成本却什么问题都没解决。而最小案例往往能帮模型快速看清问题本质，修复方案自然就收敛了。

5.2 回归确认：每次改动都要重新验证

第四个习惯是“回归确认”。当模型针对一个问题做了修复，不能只看目标用例是否通过，还要确认项目里其他已有测试是否仍然通过。

很多开发者都遇到过这种场景：模型修复了一个 bug，但顺带破坏了另一个功能。原因很简单：修复时模型只盯着目标用例，没有跑全量回归。它以为修好了，其实制造了新的问题。

在 Claude Code 中，可以这样要求模型：

修改完成后，请运行全量测试： - 运行项目全部 pytest 用例； - 如果有 lint 脚本，同时运行 lint 检查； - 确认旧有用例没有被破坏； - 如果回归失败，说明破坏原因并回退或修复。

你还可以把这个要求写进 CLAUDE.md，模型每次进入项目都会读取，不需要在每次对话里重复强调。

5.3 结合 TDD 的实践思路

如果把习惯三和习惯四放到一起理解，其实就是 AI 编程版的 TDD（测试驱动开发）：

1. 先用一个最小失败用例描述期望行为；
2. 运行测试，确认失败；
3. 让模型实现最小改动让测试通过；
4. 运行全量回归，确认没有破坏其他功能。

这种思路特别适合修复类任务和功能迭代。它不是一个测试工程师的替代方案，而是让 AI 在开发过程中自动承担“验证自己产出”的责任。谁能证明代码能跑？答案不是模型的口头承诺，而是测试命令的实际输出。

6. 习惯五：把经验固化为规则文件

6.1 CLAUDE.md 是团队规则的核心载体

第五个习惯是“把经验固化”。个人和团队踩过的坑，如果只靠口头提醒，下次大概率还会踩。Claude Code 为此提供了 CLAUDE.md 文件。

CLAUDE.md 放在项目根目录后，Claude Code 启动时会读取它，把它作为项目的背景规则。你可以在这个文件里写入项目结构说明、编码规范、测试命令、验收标准模板、禁止事项等。它相当于给模型的一份“项目入职手册”。

一个简化的 CLAUDE.md 示例如下：

# 项目规则 ## 目标 这是一个基于 FastAPI 的任务管理后端项目。 ## 常用命令 - 安装依赖：pip install -r requirements.txt - 运行测试：pytest - 启动服务：uvicorn app.main:app --reload ## 开发约束 1. 每次修改代码后，必须运行 pytest 全量测试； 2. 所有测试通过前，不得声明“完成”； 3. 所有用户输入必须做参数校验； 4. 不得在代码中硬编码密钥。 ## 验收标准模板 任务开始前，先输出验收标准，包括功能行为、边界情况、验证方式。

当这份文件被团队维护好后，每个成员在项目里使用 Claude Code，都会带着同样一套规则工作。这就实现了“团队级自我验收闭环”，而不是靠某一个人反复提醒。

6.2 使用 skills 进一步封装流程

除了 CLAUDE.md，Claude Code 还支持以 skills 的方式封装更细粒度的能力。简单理解，一个 skill 就是一段带说明的指令模板，用来教会模型处理某类特定任务。

例如，你可以创建一个“测试驱动修复”的 skill，要求模型在收到 bug 修复任务时，按固定流程执行：先写失败用例，再最小修复，最后回归。这样团队内就不再依赖每个人都会写高质量 prompt，而是把好的经验封装成了可复用资产。

如果你刚接触 skills，建议从小处入手：先维护好 CLAUDE.md，确认规则能稳定生效，再逐步尝试把常用任务流程封装成 skill。稳定的简单规则，比花哨的复杂封装更有价值。

7. 完整实战：搭建一个自我验收闭环项目

7.1 项目结构

下面把前面五个习惯合成一个完整示例。假设我们要实现一个简单的用户注册接口，要求 Claude Code 按自我验收闭环完成开发。

项目结构如下：

user-service/ ├── app/ │ └── main.py ├── tests/ │ └── test_register.py ├── requirements.txt └── CLAUDE.md

项目使用 FastAPI 构建，测试使用 pytest，通过 TestClient 模拟接口请求。这个例子足够小，你可以直接复制运行。

7.2 编写 CLAUDE.md

在项目根目录创建 CLAUDE.md，写入团队规则：

# user-service 项目规则 ## 项目说明 这是一个用户注册接口的最小示例项目，使用 FastAPI 构建。 ## 环境 - Python 3.10+ - FastAPI - pytest - httpx ## 命令 - 安装依赖：pip install -r requirements.txt - 运行测试：pytest -v - 启动服务：uvicorn app.main:app --port 8000 ## 强制规则 1. 开始任何开发任务前，先输出验收标准； 2. 修改代码后必须运行 pytest -v； 3. 所有测试通过前，不能声称任务完成； 4. 参数校验错误时返回 422，不返回 200； 5. 成功注册返回 201，同时返回 user_id； 6. 不允许出现硬编码密钥。

这里最重要的一条是规则 3：所有测试通过前，不能声称任务完成。这句话直接约束了模型的“完工判断”，是自我验收闭环的地基。

7.3 实现功能代码

在app/main.py中写入：

from fastapi import FastAPI, HTTPException from pydantic import BaseModel, EmailStr app = FastAPI() class RegisterRequest(BaseModel): username: str email: EmailStr password: str class RegisterResponse(BaseModel): user_id: int username: str @app.post("/register", response_model=RegisterResponse, status_code=201) async def register(req: RegisterRequest): # 简单校验：用户名长度至少 3 位 if len(req.username) < 3: raise HTTPException(status_code=422, detail="username too short") # 生产环境应使用密码哈希，这里仅用于演示 user_id = 1001 return RegisterResponse(user_id=user_id, username=req.username)

需要注意的是，这段代码是核心功能片段，不是完整生产实现。真实的注册接口必须对密码做哈希处理，这里仅用于演示闭环流程。

7.4 编写测试代码

在tests/test_register.py中写入：

from fastapi.testclient import TestClient from app.main import app client = TestClient(app) def test_register_success(): resp = client.post("/register", json={ "username": "alice", "email": "alice@example.com", "password": "123456" }) assert resp.status_code == 201 assert resp.json()["username"] == "alice" assert "user_id" in resp.json() def test_register_short_username(): resp = client.post("/register", json={ "username": "ab", "email": "alice@example.com", "password": "123456" }) assert resp.status_code == 422

这两个测试覆盖了正常注册和参数校验失败两种场景。当模型尝试修改接口行为时，只要跑一次 pytest，就能立刻判断改动是否符合验收标准。

7.5 让 Claude Code 按闭环执行任务

启动 Claude Code 后，在项目目录中发送如下任务：

请完成用户注册接口开发： 1. 先输出你的验收标准； 2. 确认验收标准后再查看现有代码； 3. 补齐缺失实现； 4. 运行 pytest -v 验证； 5. 只有所有测试通过才算完成。

按照 CLAUDE.md 的规则，模型会先输出验收清单，再检查代码、补全实现，然后执行测试命令。如果测试失败，它会根据报错修正代码并重新运行。整个过程就是“自我验收闭环”的实战形态。

7.6 运行与验证

你也可以手动运行验证：

pip install -r requirements.txt pytest -v

预期输出类似：

test_register.py::test_register_success PASSED test_register.py::test_register_short_username PASSED

如果看到两个用例都 PASSED，说明闭环的验证环节已经打通。后续你可以在这个基础上增加更多用例，例如密码过短、邮箱格式错误、请求方法错误等场景。

8. 常见问题与排查思路

使用 Claude Code 搭建自我验收闭环时，难免遇到各种环境问题。下面整理几个高频场景。

8.1 “could not locate the claude cli on path”

这个报错通常发生在命令行环境无法找到 claude 可执行文件时。先确认 Claude Code 是否安装成功，然后在终端执行claude --version。如果命令找不到，说明安装目录没有加入 PATH。Windows、macOS、Linux 的 PATH 配置方式各不相同，但排查思路一致：先确认可执行文件存在，再确认 PATH 配置正确。

8.2 配置的模型名不被识别

社区里使用 Claude Code 接入第三方模型时，经常出现类似报错：

xxx is not a model this version of claude code recognizes

报错含义很明确：当前版本 Claude Code 不识别你配置的模型名。可能原因包括模型名拼写错误、版本不支持、或接入的模型名称与官方列表不一致。

遇到这种问题，先查看当前 Claude Code 版本支持的模型列表，再排查配置中的 model 字段是否完全一致。如果你使用的第三方接口，还需要确认 base URL 与模型名是否匹配。涉及自定义模型接入时，建议先在测试环境验证，不要在核心生产项目中反复试验。

8.3 输出中文乱码

某些终端里 Claude Code 输出中文可能出现乱码，通常和终端编码、字体、locale 设置有关。优先检查终端是否使用 UTF-8 编码，再确认系统 locale 环境变量。这个问题不影响业务代码逻辑，但会影响阅读体验，建议在团队内统一终端配置。

8.4 项目被模型“改乱”了怎么办

这是新手最容易遇到的情况：模型完成一个小功能后，项目里多了一大堆无关改动。要避免这个问题，需要综合使用前面提到的几个习惯：

• 任务开始时明确“只修改哪些文件”；
• 修改后检查git diff，确认改动范围；
• 把“避免无关重构”写进 CLAUDE.md；
• 如果改动失控，使用 git 回退，重新用更小粒度的任务驱动模型。

9. 最佳实践与工程建议

9.1 验收标准要可自动判断

写验收标准时，尽量避开“体验更好”“性能提升”这类无法自动判断的描述，改为“接口响应时间小于 500ms”“所有 pytest 用例通过”“构建产物体积小于 1MB”。只有能被脚本验证的标准，模型才能真正完成自我验收，人工也才能靠证据评审结果。

9.2 最小权限与安全边界

Claude Code 能执行命令、修改文件，因此权限配置要遵循最小权限原则。允许列表只放验证和构建类命令，删除、推送、生产环境操作等高风险命令一律保持人工确认。尤其不要在团队项目里放开所有命令，否则一旦模型理解偏差，可能造成代码仓库和环境的不可控变更。

9.3 规则文件要持续维护

CLAUDE.md 不是写一次就结束的。每次遇到模型反复犯错、踩坑或理解歧义，都应该把应对措施补充进规则文件。把规则文件当成团队知识库来维护，定期评审，删掉过时内容，保留仍然有效的约束。规则越具体，AI 的表现越稳定。

9.4 让闭环跑在 CI 里

本地让模型跑测试只是第一层闭环，更可靠的第二层闭环是 CI。把 pytest、lint、构建等检查接入 CI 流水线后，模型再怎么“自信”，只要测试不过就不能合入主分支。这样就算团队里有人忘了配置 CLAUDE.md 规则，CI 也会兜底拦截。

9.5 从最小闭环开始

如果团队刚开始推进这套方法，不要一口气实现所有习惯。建议按以下顺序逐步落地：

1. 先约定“每次任务必须运行测试”；
2. 再维护一份最小 CLAUDE.md；
3. 加入回归测试要求；
4. 最后把验收标准模板推广到团队。

一步步来，规则才能真正被执行，而不是变成一份没人看的文档。项目的复杂度会变，工具版本会变，但“先定义完成，再让 AI 证明完成”的逻辑始终是 AI 编程时代最值得保留的工程习惯。

如果你最近刚开始用 Claude Code，可以从一件事做起：把“测试通过前不能声称完成”写进项目 CLAUDE.md。这句话看起来简单，却是整个自我验收闭环里最关键的地基。有了它，模型才会从“写代码的助手”变成“对自己产出负责的协作者”。