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 编程规范参考。序号习惯核心动作对应 Claude Code 能力1验收前置先写验收标准再写实现CLAUDE.md 规则 对话约束2自动验证让模型自己跑测试和构建Bash 工具、权限配置3最小案例收敛用最小复现案例定位问题权限限制 提问模板4回归确认每次改动都跑全量回归hooks、自定义命令5经验固化把踩坑沉淀为规则文件CLAUDE.md、skills整体来看习惯 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它可以在授权下直接执行命令。让模型自己跑测试最大的价值在于它能看到真实的失败信息、真实堆栈、真实测试输出从而基于证据修正代码而不是基于概率修正代码。一个合理的循环是模型修改代码模型执行测试命令例如pytest -v测试通过进入下一步测试失败模型查看报错并继续修改重复执行直到全部通过。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测试驱动开发先用一个最小失败用例描述期望行为运行测试确认失败让模型实现最小改动让测试通过运行全量回归确认没有破坏其他功能。这种思路特别适合修复类任务和功能迭代。它不是一个测试工程师的替代方案而是让 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.mdClaude 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_modelRegisterResponse, status_code201) async def register(req: RegisterRequest): # 简单校验用户名长度至少 3 位 if len(req.username) 3: raise HTTPException(status_code422, detailusername too short) # 生产环境应使用密码哈希这里仅用于演示 user_id 1001 return RegisterResponse(user_iduser_id, usernamereq.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: aliceexample.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: aliceexample.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 搭建自我验收闭环时难免遇到各种环境问题。下面整理几个高频场景。问题现象常见原因解决思路启动时报 “could not locate the claude cli on path”CLI 未安装或 PATH 未配置重新安装 CLI检查 PATH 环境变量settings.json 修改后不生效配置文件路径错误或未重启确认文件位置重启 Claude Code配置的模型名不被识别模型名拼写错误或版本过旧查看当前版本支持的模型列表模型声称完成但测试未通过没有配置强制验证规则在 CLAUDE.md 中写明“测试通过前不算完成”命令执行权限频繁提示权限配置过严在 settings.json 中为安全命令配置 allow 规则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 从最小闭环开始如果团队刚开始推进这套方法不要一口气实现所有习惯。建议按以下顺序逐步落地先约定“每次任务必须运行测试”再维护一份最小 CLAUDE.md加入回归测试要求最后把验收标准模板推广到团队。一步步来规则才能真正被执行而不是变成一份没人看的文档。项目的复杂度会变工具版本会变但“先定义完成再让 AI 证明完成”的逻辑始终是 AI 编程时代最值得保留的工程习惯。如果你最近刚开始用 Claude Code可以从一件事做起把“测试通过前不能声称完成”写进项目 CLAUDE.md。这句话看起来简单却是整个自我验收闭环里最关键的地基。有了它模型才会从“写代码的助手”变成“对自己产出负责的协作者”。