Claude Code 最近在 AI 编程工具里的讨论热度很高。从“负责人 Boris 团队公开 5 个底层习惯”这个话题就能看出来大家已经不只是关心“怎么把 Claude Code 装起来”而是开始关注一个更关键的问题AI 把代码写出来了我们怎么验收怎么确保它不是“看起来很对跑起来就崩”本文围绕“自我验收闭环”这个核心把团队习惯拆解成可落地的工程方法并结合 Claude Code 的安装配置、CLAUDE.md 规则、测试驱动提示词、常见报错和工程建议整理成一份可以直接照着用的实战教程。无论你是刚接触 Claude Code 的新手还是已经用它写过几个需求的开发者这篇文章都会有用。1. 背景与核心概念1.1 Claude Code 是什么Claude Code 是 Anthropic 推出的命令行 AI 编程工具。它的使用方式和传统聊天式 AI 不太一样你不是在网页里复制粘贴代码而是在终端里直接和它对话让它读取项目文件、生成代码、执行命令、运行测试甚至完成一次小型的开发任务。简单来说Claude Code 更像一个坐在你终端里的“结对程序员”。你可以让它分析现有项目结构。按需求生成函数、类、配置、测试。执行测试命令并读取结果。根据报错信息自动修复代码。把任务拆分成多个步骤逐步完成。它解决的核心问题是AI 编程不能只停留在“生成代码片段”而要进入“真正参与工程开发”的阶段。想让 AI 高效、稳定地参与项目就必须有一套验收机制。这正好引出我们这篇文章的核心概念自我验收闭环。1.2 什么是自我验收闭环自我验收闭环可以理解成一套“让 AI 输出经过验证后才算完成”的工作流程明确需求。定义验收标准。AI 生成实现。机器自动验证例如运行测试、静态检查。开发者人工复核关键变更。把发现的问题反馈给 AI 修复。全部通过后才算任务完成。在传统开发中我们自己写代码自己测试问题相对可控。但用 AI 编程时代码是模型生成的开发者并没有逐行敲过所以“验收”这一步就变得非常重要。如果缺少闭环就会出现下面这些场景AI 说“功能已完成”但测试根本没跑过。AI 生成了看似完整的代码却忽略了异常边界。AI 把密钥写进了配置文件自己完全没有察觉。AI 修了一个 Bug却引入了另一个回归问题。所以自我验收闭环不是流程束缚而是对 AI 输出质量的基本保护。Boris 团队提到的“5 个底层习惯”本质上就是围绕这个闭环展开的。1.3 本文适合谁本文适合这几类读者刚接触 Claude Code想了解它能做什么的开发者。已经在用 Claude Code但总觉得 AI 输出质量不稳定的开发者。想把 AI 编程接入团队协作流程的研发管理者。准备用 Claude Code 处理真实业务需求而不是停留在“聊天生成代码”的开发者。读完本文后你会掌握Claude Code 的基础环境搭建、CLAUDE.md 配置方法、5 个可落地的团队习惯、一个完整的带测试实战案例以及常见报错的排查方案。2. 环境准备三步把 Claude Code 跑起来在讨论“自我验收闭环”之前先把工具装好。环境准备这部分涉及 Claude Code 安装、模型接入和最小配置。很多新手卡在最开始的安装环节所以这里单独拿出来讲。2.1 安装前置条件Claude Code 通常依赖 Node.js 环境。你需要先确认本机已经安装 Node.js 和 npm。在终端中执行node -v npm -v如果你的环境中没有 Node.js需要先安装。建议安装 Node.js 18 及以上版本。不同版本对 Node.js 的兼容要求会有差异具体以官方文档为准。当前终端环境建议使用 macOS、Linux 或 Windows 上的 PowerShell。Windows 用户使用时如果遇到 PATH 问题可以尝试在终端中重新加载环境变量或者重启终端。2.2 安装 Claude Code 并接入模型Claude Code 的安装方式一般是通过 npm 全局安装npm install -g anthropic-ai/claude-code安装完成后验证命令是否可用claude --version如果命令提示找不到可能是 npm 的全局 bin 目录没有加入 PATH。你可以先执行npm bin -g查看全局 bin 路径再把它加入系统 PATH。如果你的网络环境无法直接安装也可以考虑使用镜像源。常见做法是把 npm 源切换为国内镜像例如npm config set registry https://registry.npmmirror.com然后重新执行安装命令。安装完成后启动 Claude Code 时通常需要配置 API 访问权限。最常见的方式是设置环境变量。以 Anthropic 官方 API 为例export ANTHROPIC_API_KEY你的 API Key claude如果团队使用的是第三方兼容网关比如某些模型服务商提供的 OpenAI 兼容接口通常需要配置网关地址、Token 和模型名称。由于各家网关的变量名并不完全一致下面只给出一套参考思路export ANTHROPIC_BASE_URLhttps://your-gateway.example.com export ANTHROPIC_AUTH_TOKENyour-token export ANTHROPIC_MODELyour-model-name claude需要注意模型名必须能被当前 Claude Code 版本识别。网上经常遇到类似这样的报错deepseek-v4-pro is not a model this version of claude code recognizes这类问题的本质是模型名与版本支持的模型列表不匹配。解决思路是先确认当前版本支持哪些模型再确认网关端的模型名是否正确。2.3 最小可用配置CLAUDE.md 与 settings.jsonClaude Code 在启动时会读取项目上下文文件。最常见的文件是CLAUDE.md它用来告诉 Claude Code 这个项目的背景规则。比如一个 Python 项目可以在CLAUDE.md中写# 项目开发规则 ## 技术栈 - Python 3.11 - pytest 作为测试框架 ## 完成标准 - 每个功能必须包含测试。 - pytest 必须全部通过。 - 不允许在代码中硬编码 API Key。 - 代码提交前必须运行 python -m pytest tests/ -q。有了这个文件Claude Code 在生成代码时会更倾向于遵守项目的测试和提交规范。settings.json则用于配置 Claude Code 的行为比如默认权限、模型选项等。如果新建了settings.json但发现模型没有接入成功通常需要检查三点文件路径是否正确项目级配置一般放在项目的.claude/目录下。字段名是否与当前版本一致。是否重启了会话配置修改后需要重新读取。这里也提醒一下涉及账号授权、登录配置的内容请务必走官方渠道。不要使用来路不明的“免登录配置”或“破解方案”否则容易造成密钥泄露和账号风险。3. 五个底层习惯拆解把“验收闭环”落到日常开发下面进入全文最核心的部分。网上讨论较多的是“Boris 团队公开 5 个底层习惯”但很多讨论停留在观点层面。我们需要把它转换成可执行的工程习惯。结合 Claude Code 的实际玩法我梳理出五个可以立刻上手的底层习惯。它们不是某种秘密技巧而是一套让 AI 输出从“不可信”变成“可控”的工程方法。3.1 习惯一先写验收标准再写实现大部分 AI 编程返工问题都出在需求没有定义清楚。我们经常在对话里直接说“帮我写一个日期解析函数。”然后 Claude Code 生成了一段看似正常的代码。但“正常”不等于“正确”因为你没有告诉它什么算完成什么算通过。正确的做法是在提问之前先把验收标准写出来。比如输入today返回今天的 ISO 日期。输入3d返回三天后的 ISO 日期。支持YYYY-MM-DD和YYYY/MM/DD两种格式。非法输入抛出异常。这些验收标准应该放在对话提示词里最好是放在CLAUDE.md里作为项目级规则。这样每次 Claude Code 生成代码时都会先读到这些标准而不是凭概率猜。为什么这个习惯很重要因为 AI 模型的输出是概率性的。你不定义边界它就可能忽略边界你定义了验收标准它才能在生成过程中主动对齐。3.2 习惯二把大需求拆成可追踪任务清单第二个习惯是任务拆解。AI 编程最怕的一件事是让模型“一口气完成一个复杂功能”。需求越大生成结果越不可控后续调试也越困难。更稳定的做法是让 Claude Code 像人一样工作先理解需求。列出实现步骤。逐步完成。每步做完后验证。你可以直接在提示词中要求 Claude Code 使用 TODO 清单请按下面步骤完成日期解析功能 1. 列出验收标准。 2. 创建实现文件。 3. 编写测试文件。 4. 运行测试。 5. 修复测试失败。当任务被拆成一个个小步骤后你可以随时中断、检查、纠偏。AI 不会因为“前面理解错了”而在后面越跑越偏。这个习惯对应了“自我验收闭环”中的任务分解环节把大目标拆成小验收单元每个单元都能独立验证。3.3 习惯三让 AI 跑测试而不是“觉得没问题”AI 编程中有一个很常见的陷阱模型在对话里告诉你“代码没问题”但它并没有真正执行过。它只是根据训练数据“推测”这段代码能跑。所以第三个习惯是对可执行的任务必须让 AI 真正运行命令并读取输出。例如在 Claude Code 的会话中如果你的项目有 pytest 测试就让 Claude Code 执行python -m pytest tests/ -q然后让它读取输出把结果反馈到对话中。如果测试失败就继续让它修如果测试通过才继续下一步。这样做的价值在于把“主观判断”变成“客观验证”。运行结果是真实可信的而不是模型预测出来的。对于没有测试的项目也要先让 Claude Code 运行一段最小命令比如python -c from module import function; print(function(today))用真实输出来验证行为。3.4 习惯四关键 diff 必须人工复核不管 AI 多强大最终对代码负责的都是开发者自己。我不建议把 Claude Code 生成的代码直接提交尤其是关键业务逻辑、权限相关代码和数据库操作。习惯四是每次生成结果后先看 diff再提交。在 Claude Code 中你可以让它在完成修改后输出变更摘要请列出你修改的文件和每个文件的关键变化。然后自己打开 Git diff 检查git diff人工复核时重点关注是否引入了无关改动。是否硬编码了敏感信息。是否正确处理异常和边界条件。是否符合团队既有命名规范。是否有多余的调试代码。这个习惯是自我验收闭环中最不可替代的一环。机器负责执行力人负责判断力。3.5 习惯五把失败经验沉淀回上下文最后一个习惯是复盘沉淀。团队中的 AI 编程能力提升不应该只靠每个人“这次让 AI 改对了”而是要把失败经验固化下来。假设你发现 Claude Code 经常在日期格式处理上漏掉异常分支那就在CLAUDE.md中补充一条规则## 日期处理要求 - 所有日期解析函数必须处理非法输入。 - 日期解析函数必须返回 ISO 格式字符串。 - 必须为每个解析规则编写测试用例。如果你的团队使用了 Claude Code 的 extended skills 或自定义指令也可以把领域规则、验收模板沉淀成可复用的 skill。这样下一次 Claude Code 生成代码时就不需要你反复在会话中提醒而是自动遵循团队的验收标准。这个习惯本质上是“闭环”的最后一环将反馈写入规则用规则影响下一次生成。3.6 五个习惯如何组成闭环简单总结一下五个习惯的串联关系习惯一解决“目标不清”的问题。习惯二解决“过程不可控”的问题。习惯三解决“结果不可信”的问题。习惯四解决“责任没人担”的问题。习惯五解决“经验不积累”的问题。合在一起就是一条完整的自我验收闭环标准先行、任务拆解、自动验证、人工复核、经验沉淀。4. 完整实战用 Claude Code 完成一个带自测的小功能这一节我们做一个完整的小案例把上面的习惯串起来。这个案例不需要公司内部系统权限也不需要数据库适合每个人立即动手验证。4.1 需求与验收标准假设我们要实现一个函数parse_due_date用于把自然语言式的到期时间转成 ISO 日期字符串。需求描述如下输入today返回今天的日期。输入3d返回今天加 3 天的日期。输入2025-06-01返回2025-06-01。输入2025/06/01返回2025-06-01。非法输入抛出DueDateError异常。这是我们的验收标准也是后面 Claude Code 生成代码的依据。4.2 在 CLAUDE.md 中写入完成标准在项目根目录创建CLAUDE.md内容如下# 日期工具项目 ## 技术栈 - Python 3.11 - pytest ## 完成标准 1. 所有日期函数必须处理非法输入。 2. 日期输出统一为 ISO 格式字符串。 3. 每个公开函数必须编写 pytest 测试。 4. 测试命令python -m pytest tests/ -q 5. 测试不通过不提交代码。这样写的目的是让 Claude Code 在读取项目时自然对齐这些规则。4.3 向 Claude Code 发起任务然后在 Claude Code 会话中输入下面这段提示词请按照 CLAUDE.md 中的完成标准实现 parse_due_date 函数。 要求 1. 先列出验收标准。 2. 拆分 TODO 清单。 3. 编写实现代码。 4. 编写 pytest 测试。 5. 运行测试并反馈结果。这里刻意要求它“先列出验收标准”是为了复现习惯一和习惯二确保它在动手写代码前先对齐目标。4.4 核心代码与测试参考下面给出这套功能可能最终生成的参考代码。你需要结合 Claude Code 的生成结果进行 diff 复核。核心实现文件路径src/due_date.pyfrom datetime import date, timedelta import re class DueDateError(ValueError): pass def parse_due_date(value: str, today: date | None None) - str: today today or date.today() value value.strip() if value today: return today.isoformat() m re.fullmatch(r\(\d)d, value) if m: days int(m.group(1)) return (today timedelta(daysdays)).isoformat() for fmt in (%Y-%m-%d, %Y/%m/%d): try: return date.strptime(value, fmt).isoformat() except ValueError: continue raise DueDateError(f无法识别的日期格式: {value})对应的测试文件文件路径tests/test_due_date.pyimport pytest from datetime import date from src.due_date import parse_due_date, DueDateError def test_today(): # 使用固定日期保证测试稳定 assert parse_due_date(today, date(2025, 6, 1)) 2025-06-01 def test_plus_days(): assert parse_due_date(3d, date(2025, 6, 1)) 2025-06-04 def test_iso_formats(): assert parse_due_date(2025-06-01) 2025-06-01 assert parse_due_date(2025/06/01) 2025-06-01 def test_invalid_format(): with pytest.raises(DueDateError): parse_due_date(next month)这里我加了today参数是为了让测试结果不依赖系统当前日期。如果测试里直接调用date.today()某一天可能通过换一天可能就有边界问题。用固定日期传入测试结果才是稳定的。4.5 运行与验证在项目根目录运行测试命令python -m pytest tests/ -q预期输出4 passed in 0.02s如果 Claude Code 生成的代码没有通过测试让它读取失败信息继续修复。只有测试全部通过这个功能才算真正完成。整个流程下来你应该能感受到“自我验收闭环”的作用不是让 AI 告诉你“做完了”而是让测试数据和人工复核告诉你“做完了”。5. 常见问题与排查思路Claude Code 的使用过程中不少问题发生在安装、模型接入和配置环节。下面整理几个高频问题和排查思路。问题现象常见原因解决思路安装后提示could not locate the claude cli on pathnpm 全局目录未加入 PATH或安装未成功重新执行安装命令检查npm bin -g路径重启终端临时可用npx anthropic-ai/claude-code启动提示some-model is not a model this version recognizes模型名写错或当前 Claude Code 版本不支持该模型查看当前版本支持的模型列表确认网关端模型名必要时升级 Claude Code修改settings.json后没生效文件路径放错、字段名写错、会话未重启核对配置文件路径和字段名重启会话后再测试中文输出乱码终端编码不是 UTF-8或系统语言环境不正确将终端编码切换为 UTF-8检查LANG和LC_ALL环境变量执行命令权限被拒绝Claude Code 权限配置过严在权限配置中添加必要的允许项但遵循最小权限原则针对第一个问题还值得多说一句。could not locate the claude cli on path通常不是 Claude Code 本身坏了而是终端找不到可执行文件。你可以用下面命令确认which claude如果没有输出说明claude不在 PATH 中。此时可以找到 npm 全局目录npm prefix -g然后把该目录加入 PATH。macOS 和 Linux 下一般是export PATH$(npm prefix -g)/bin:$PATHWindows PowerShell 下可以修改用户环境变量 PATH再把新的 Terminal 窗口打开。排查时建议遵循“先看命令行输出再查配置文件最后升级版本”的顺序。日志信息往往比猜测更可靠。6. 工程建议让 AI 编码闭环真正稳定最后一个章节我们跳出具体命令谈谈工程层面怎么把这套闭环落地得更好。6.1 上下文文件不要贪多CLAUDE.md不宜写成长篇大论。模型读取上下文时内容太杂反而削弱关键规则。建议用清晰的分段维护技术栈。目录结构。完成标准。禁止事项。常用命令。每个项目只维护一份精简的CLAUDE.md团队公共规则可以放进用户级配置项目独有规则放到项目级配置。6.2 权限与安全边界使用 Claude Code 时它会经常请求执行命令。请记住最小权限原则只允许模型运行必要的命令。不要直接在对话里粘贴生产环境连接串。不要把 API Key 写入代码仓库或CLAUDE.md。涉及数据库删除、表结构修改、生产配置变更时先在测试环境验证并做好备份和回滚方案。模型生成代码时可能会在测试中写print调试输出也可能会引入不必要的网络请求。人工复核时要特别关注这些边界。6.3 团队协作与代码评审AI 生成的代码也是代码必须走团队评审流程。建议在代码提交信息中标注哪些代码是 AI 生成的方便 reviewer 重点检查。例如feat: 支持到期时间解析 - Claude Code 生成核心实现 - 人工补充非法输入测试 - 已运行 pytest 验证这样的提交说明能让评审者快速判断代码风险点也能让团队积累 AI 协作经验。在 CI 流程中同样要跑测试和静态检查。不要因为“Claude Code 本地测试通过”就跳过 CI。本地通过和线上验证是两个层级CI 是最后一道机器防线。6.4 用复盘驱动闭环优化团队可以定期把“AI 生成的失败案例”收集起来作为规则沉淀的输入。比如AI 经常忽略空值输入。AI 经常生成没有边界检查的日期函数。AI 在修改测试时喜欢“把断言改宽松”而不是去修业务代码。一旦发现某个问题反复出现就把它写进CLAUDE.md或 skill 规则中。这样一来闭环不是一次性的而是持续进化的。7. 总结与下一步回到文章最开始的问题AI 把代码写出来了我们怎么验收答案是构建自己的“自我验收闭环”。这套闭环不依赖某个神奇模型也不依赖某种高级配置而是依赖 5 个朴素习惯先定标准、拆任务、跑测试、人工复核、沉淀经验。这些习惯落到 Claude Code 上就是一套完整的操作方式用CLAUDE.md写项目规则用 TODO 清单管理任务用真实命令验证结果用 diff 检查变更用复盘更新上下文。如果你还没用过 Claude Code可以先花一个下午把环境搭好用本文的日期解析案例走一遍闭环。如果你已经在用 Claude Code不妨把你最近一次需求重新审视一下当时有没有先写验收标准有没有让 AI 真的跑测试有没有在提交前看过 diff在 AI 编程工具越来越强的时代编码能力不再只是“写出正确的代码”还包括“让 AI 稳定地产出正确代码”。这套自我验收闭环就是把这个能力落到实地的第一步。