企业官网建设流程全解析

1. 为什么你的 Claude Code 每次都要重新问一遍权限

刚上手 Claude Code 的人，大概率都经历过这个场景：让它跑个npm run build，弹一次确认；让它git commit，又弹一次；换个会话，同样的命令还得再点一遍。一天下来，手指点「允许」点到发酸，心里还犯嘀咕——这玩意儿到底能不能记住我的偏好？

问题不在 Claude Code 本身，而在于它的默认设计哲学：low-level、unopinionated。官方刻意把权限收得很紧，任何可能改动系统的操作——文件写入、大部分 bash 命令、MCP 工具调用——默认都要你点头。这是安全优先的取舍，但对已经上手、想把它当日常生产力工具的开发者来说，就变成了重复劳动。

真正让 Claude Code 从「能用」变成「顺手」的，是三个东西的协同：CLAUDE.md（告诉它项目上下文和规范）、settings.json（告诉它哪些工具可以放手用）、gh CLI（让它能原生操作 GitHub）。这三者配好了，你的工具链才是稳定可复现的——换台机器、换个队友，拉下代码就能得到一致的行为。

这篇就聚焦官方最佳实践里的工具配置环节，把可直接复制的配置片段和逐项验证动作交给你。适合已经跑通 Claude Code 基础流程、想进一步把权限和上下文管起来的开发者。下面从 CLAUDE.md 开始，一路配到 gh CLI 调用确认。

2. CLAUDE.md 与 settings.json 前置准备：把上下文和权限分开管

在动手写配置之前，得先理清一个容易混淆的点：CLAUDE.md 和 settings.json 管的是两件不同的事，别混在一起。

CLAUDE.md 是上下文文件。Claude 在开始对话时会自动把它拉进 prompt，所以它消耗的是 token，内容要精炼、人类可读。它记录的是「这个项目是什么样」——常用命令、代码风格、测试策略、目录约定。写得越啰嗦，每次对话的上下文开销越大，反而拖慢响应。

settings.json 是权限与行为配置。它不进入 prompt，而是控制 Claude Code 这个工具本身的行为——哪些命令免确认、哪些工具禁用、环境变量怎么设。它管的是「这个工具能做什么」。

我试过把权限规则写进 CLAUDE.md，结果 Claude 只是「知道」有这么条规则，但该弹的确认还是弹——因为权限判定根本不读 CLAUDE.md。这个坑踩过一次就记住了：上下文归 CLAUDE.md，权限归 settings.json。

2.1 CLAUDE.md 的四个放置位置与优先级

CLAUDE.md 不是只能放一个地方，它有作用域层级，从大到小大致是这样：

实际用下来，最常见的组合是：全局放个人通用偏好（比如「回答用中文」「优先给可运行代码」），项目根目录放团队共享规范，本地覆盖放自己机器的临时说明（比如本地数据库端口、私有环境变量名）。

如果你懒得从零写，直接在项目里跑/init，Claude Code 会自动扫描项目结构生成一个 CLAUDE.md 起点，再手动改就行。

2.2 一份可直接复制的 CLAUDE.md 模板

下面这份是我在多个 Node/TS 项目里沉淀下来的，简洁、可读、不啰嗦。你可以直接复制到项目根目录的CLAUDE.md：

# 项目概览 这是一个 TypeScript + Node.js 的后端服务，使用 pnpm 管理依赖。 # 常用命令 - `pnpm install`：安装依赖 - `pnpm run build`：构建项目 - `pnpm run typecheck`：运行类型检查 - `pnpm run test:unit`：运行单元测试 - `pnpm run lint`：代码检查 # 代码风格 - 使用 ES 模块（import/export），不要用 CommonJS（require） - 尽量使用解构导入，例如 `import { foo } from "bar"` - 提交前必须通过 typecheck 和 lint # 工作流程 - 审查完一系列代码更改后，先跑 typecheck - 为了性能，优先跑单元测试，而不是完整测试套件 - 分支命名用 `feat/xxx`、`fix/xxx` # 注意事项 - 不要直接修改 `src/generated/` 下的文件，它们是自动生成的 - 数据库迁移文件放在 `migrations/`，改动前先确认

这份文件的关键在于「命令 + 规范 + 禁忌」三段式。Claude 读完之后，你不用每次重复「用 pnpm 不用 npm」「别碰 generated 目录」。

2.3 用 # 键动态补充，让 CLAUDE.md 自己长起来

CLAUDE.md 不是一次写完就锁死的。官方推荐的做法是：在编码过程中，随时用#键给 Claude 一条指令，它会自动把这条指令纳入相关的 CLAUDE.md。

比如你发现 Claude 老是用npm，就在对话里输入：

# 本项目统一使用 pnpm，不要用 npm

Claude 会把这条规则写进 CLAUDE.md。团队协作时，很多人就是靠频繁用#记录命令和风格，然后一起提交 CLAUDE.md 的改动，让所有人都受益。

一个提升遵循度的小技巧：在关键指令上加「重要」「必须」这类强调词。官方内部团队会定期用提示词改进器过一遍 CLAUDE.md，实测下来，加了强调的规则被遵守的概率明显更高。

3. settings.json 权限配置：permissions 与 allow/deny 的可复制片段

上下文配好了，接下来解决「每次都要点允许」的问题。核心就是 settings.json 里的permissions对象。

3.1 三个 settings.json 的生效范围

先搞清楚文件放哪，这决定了配置影响谁：

团队协作的推荐做法：把.claude/settings.json检入版本控制，让所有人共享一套安全基线；个人临时放宽的规则写进settings.local.json，它会被 gitignore 掉，不会污染团队配置。

3.2 一份可直接复制的 settings.json

下面这份配置覆盖了日常最常用的免确认场景，同时把危险操作挡在外面。复制到.claude/settings.json：

{ "permissions": { "allow": [ "Bash(ls:*)", "Bash(cat:*)", "Bash(git status:*)", "Bash(git diff:*)", "Bash(git log:*)", "Bash(git commit:*)", "Bash(pnpm run build:*)", "Bash(pnpm run typecheck:*)", "Bash(pnpm run test:unit:*)", "Edit", "Read" ], "deny": [ "Bash(rm -rf:*)", "Bash(git push --force:*)", "Bash(curl:*)" ] } }

逐项解释一下：

allow里的Bash(ls:*)表示授权所有以ls开头的命令，:*是通配后缀。Edit和Read是工具名，直接写工具名表示允许该工具的所有调用。deny里的规则优先级高于allow，即使某个命令被 allow 了，只要命中 deny 也会被拦。

注意Bash(git commit:*)这种写法——它允许提交，但不允许git push --force，因为后者在 deny 里。这种「放行常规、拦截危险」的组合，是权限配置的核心思路。

3.3 用 /permissions 命令交互式管理

不想手写 JSON 也行。在 Claude Code 会话里输入/permissions，会进入交互界面，四个选项对应四种策略：

• Allow：永久信任，不再询问。适合ls、cat这类安全高频命令。
• Ask：默认策略，每次弹确认。适合文件写入、网络请求等有风险的操作。
• Deny：永久禁止，即使模型生成了调用也会被拦截。适合封锁危险工具。
• Workspace：范围限制，通常限定在当前项目工作区内执行，防止误操作其他目录。

选完之后，界面会问你保存到哪个作用域（Project settings 还是 User settings）。选 Project settings 就会写进.claude/settings.json或settings.local.json。

3.4 手动编辑后的验证动作

改完 settings.json，别急着信它生效了。做两个验证：

第一，检查 JSON 语法。一个多余的逗号就会让整个配置失效，而且 Claude Code 不一定报错，只是静默忽略。用jq过一遍：

jq . .claude/settings.json

如果输出格式化后的 JSON，说明语法没问题；如果报 parse error，就回去改。

第二，重启会话后测试。开一个新会话，让它跑一条你 allow 过的命令，比如git status。如果不再弹确认，说明权限生效了。再跑一条 deny 里的命令，比如curl https://example.com，应该被直接拦截。

4. gh CLI 安装与验证：让 Claude 原生操作 GitHub

权限配好了，最后一块拼图是 gh CLI。Claude Code 有和 GitHub 交互的原生能力，但依赖 GitHub 官方的命令行工具gh。装上它，Claude 才能帮你创建 Issue、开 PR、读评论，而且权限管理比走 API 或 MCP 更直观。

4.1 安装 gh CLI

macOS 用 Homebrew：

brew install gh

Windows 用 winget：

winget install --id GitHub.cli

装完重启终端，让环境变量生效。然后验证：

gh --version

返回版本号就说明装好了。如果提示 command not found，多半是 PATH 没更新，重开终端或手动 source 一下 shell 配置。

4.2 gh auth login 授权流程

安装只是第一步，还得授权，Claude 才能代表你操作 GitHub：

gh auth login

交互过程大致是：选择GitHub.com→ 选择HTTPS→ 问你是否用 Git 凭证认证，选Y→ 选择用浏览器登录 → 浏览器打开后按提示登录，最后会给你一个一次性验证码，把它填回终端。

看到Logged in as <你的用户名>就成功了。回到终端确认一下：

gh auth status

会显示当前登录账号和 token 的权限范围。

4.3 让 Claude 调用 gh 完成一次提交

授权完成后，可以直接给 Claude 下指令。比如让它把本地项目推到 GitHub：

使用 gh 命令创建一个仓库，把当前项目 commit 并 push 上去

Claude 会依次执行git init（如果还没初始化）、git add、git commit，然后用gh repo create建远程仓库并推送。整个过程你可以在会话里看到它调用的每条命令。

如果它卡在权限确认上，说明Bash(gh:*)没在 allow 列表里，回去补上就行。

4.4 三件套齐活：Base URL + Key + Model ID

如果你是通过 API 方式接入 Claude Code（比如用 TaoToken 这类兼容 Anthropic 协议的服务），配置里需要写全三件套，缺一不可：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-你的密钥", "ANTHROPIC_MODEL": "claude-sonnet-4-20250514" } }

Base URL 指向 API 端点，Key 是你的凭证，Model ID 指定用哪个模型。这三个写进~/.claude/settings.json的env字段，Claude Code 启动时会自动读取。Key 的获取入口在 API Keys 页面，接入细节可以对照接入文档。

5. 常见报错排查：401、local proxy failed、reading choices

配置过程中最容易撞上的几个报错，这里逐个拆。

5.1 401 Unauthorized

最常见的原因是 Key 没配对，或者 Base URL 和 Key 不匹配。检查顺序：

先确认ANTHROPIC_API_KEY有没有多余空格或换行——从网页复制时经常带上。再确认ANTHROPIC_BASE_URL结尾没有多余的斜杠，正确写法是https://taotoken.net/api，不要写成https://taotoken.net/api/。

如果 Key 是从别处复制的老 key，可能已经失效，去 API Keys 页面重新生成一个。

5.2 local proxy failed

这个报错通常出现在网络层。Claude Code 尝试连接 Base URL 时失败了。先确认你的网络能正常访问该域名，用 curl 测一下：

curl -I https://taotoken.net/api

如果返回 4xx 或 5xx，说明服务端可达但请求有问题；如果直接超时，就是网络连通性问题。注意不要配置任何系统级代理指向不明服务，保持直连即可。

5.3 reading choices 相关报错

这类报错一般出现在模型返回格式不符合预期时，比如流式响应被中途截断。常见诱因是 Model ID 写错了——写了一个不存在的模型名，服务端返回的错误体解析不出来。

确认ANTHROPIC_MODEL的值是有效的模型 ID。如果你不确定当前支持哪些，可以在模型对话页面先手动测一下，确认模型可用再写进配置。

5.4 OAuth 相关报错

如果你用的是 Claude Code 官方账号登录（OAuth 流程），报错通常和 token 过期有关。重新跑一次登录流程即可。但如果你走的是 API Key 方式，就不该出现 OAuth 报错——如果出现了，说明配置里混入了两套认证方式，检查 settings.json 里是不是同时有 OAuth 相关字段和 API Key 字段，删掉不需要的那套。

5.5 权限配置不生效

改完 settings.json 发现该弹的确认还是弹。三个检查点：

JSON 语法是否合法（用jq .验证）；文件路径是否放对（项目级还是用户级）；命令模式是否写对（Bash(git commit:*)里的冒号和星号不能少）。还有一个容易忽略的：deny 规则会覆盖 allow，如果你 allow 了Bash(git:*)但 deny 了Bash(git push --force:*)，那 force push 依然会被拦，这是预期行为。

6. 把工具链固化下来：从一次性配置到可复现

配置这件事，做一次不难，难的是让它稳定复现。我的做法是把三样东西都纳入版本控制：.claude/settings.json提交，让团队共享权限基线；CLAUDE.md提交，让上下文一致；gh的安装和授权写进项目的 onboarding 文档，新成员照着跑一遍就行。

个人机器特有的东西——本地路径、私有 Key、临时放宽的权限——全部塞进settings.local.json和CLAUDE.local.md，这两个文件进.gitignore，不污染团队仓库。

这样一套下来，换台机器 clone 项目，跑一遍gh auth login，Claude Code 的行为就和队友完全一致了。权限不用重新点，上下文不用重新讲，工具链是复现的，不是每次靠记忆重建的。

如果你还在用默认权限一条条点确认，建议今天就花十分钟把 settings.json 配了。长期做编码和 Agent 任务的，可以看看 Coding Plan，把额度的事也一并解决。配置入口在 Console，需要对照官方说明的翻文档。