企业官网建设流程全解析

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 输出经过验证后才算完成”的工作流程：

1. 明确需求。
2. 定义验收标准。
3. AI 生成实现。
4. 机器自动验证，例如运行测试、静态检查。
5. 开发者人工复核关键变更。
6. 把发现的问题反馈给 AI 修复。
7. 全部通过后，才算任务完成。

在传统开发中，我们自己写代码，自己测试，问题相对可控。但用 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_URL="https://your-gateway.example.com" export ANTHROPIC_AUTH_TOKEN="your-token" export ANTHROPIC_MODEL="your-model-name" claude

需要注意，模型名必须能被当前 Claude Code 版本识别。网上经常遇到类似这样的报错：

"deepseek-v4-pro" is not a model this version of claude code recognizes

这类问题的本质是模型名与版本支持的模型列表不匹配。解决思路是先确认当前版本支持哪些模型，再确认网关端的模型名是否正确。

2.3 最小可用配置：CLAUDE.md 与 settings.json

Claude 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但发现模型没有接入成功，通常需要检查三点：

1. 文件路径是否正确，项目级配置一般放在项目的.claude/目录下。
2. 字段名是否与当前版本一致。
3. 是否重启了会话，配置修改后需要重新读取。

这里也提醒一下：涉及账号授权、登录配置的内容，请务必走官方渠道。不要使用来路不明的“免登录配置”或“破解方案”，否则容易造成密钥泄露和账号风险。

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 像人一样工作：

1. 先理解需求。
2. 列出实现步骤。
3. 逐步完成。
4. 每步做完后验证。

你可以直接在提示词中要求 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.py

from 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(days=days)).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.py

import 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 path通常不是 Claude Code 本身坏了，而是终端找不到可执行文件。你可以用下面命令确认：

which claude

如果没有输出，说明claude不在 PATH 中。此时可以找到 npm 全局目录：

npm prefix -g

然后把该目录加入 PATH。macOS 和 Linux 下一般是：

export PATH="$(npm prefix -g)/bin:$PATH"

Windows 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 稳定地产出正确代码”。这套自我验收闭环，就是把这个能力落到实地的第一步。