企业官网建设流程全解析

你有没有遇到过这种情况——

CLAUDE.md 写了 300 多行，把团队的编码规范、命名规则、部署流程全塞进去了，结果 Claude Code 执行的时候该忘还是忘。换个复杂点的任务，它甚至开始自相矛盾。

我之前也是这么干的。直到某天在 Anthropic 官方文档里看到一句话，大意是：「CLAUDE.md 只是 7 种自定义方式之一，不是唯一的。」

7 种？我数了数自己用过的，只有 CLAUDE.md 和.claude/commands/两种。剩下 5 种听都没听过。

后来我花了一周把这 7 种方式全部摸透，发现一个扎心的事实：大多数人把所有规则一股脑塞进 CLAUDE.md，就像把所有衣服扔进一个抽屉——看起来都在，找的时候全乱。

这篇文章不是再做一遍「7 种方式逐一介绍」的平铺结构——那种文章已经有不少了。我要做的是：先给你 5 个真实场景，让你对号入座；再给你一个决策框架，帮你以后自己判断；最后逐一拆解每种方式的原理、用法和反模式。

说白了，「什么时候不该用」比「怎么用」更重要。

先看 5 个场景：你中了几个？

在讲「怎么用」之前，先对号入座。以下 5 个场景，如果你踩过任何一个，说明你可能用错了方式。

场景一：CLAUDE.md 膨胀症

你的 CLAUDE.md 已经超过 200 行。编码规范 50 行、架构说明 80 行、部署流程 60 行、各种零碎规则 40 行。每次开会后还要往里加。结果 Claude 的遵从率越来越低——它不是不想遵守，是上下文窗口就那么大，塞太多规则它根本「看不过来」。

场景二：每次都要手敲同一段指令

每次让 Claude Code 做 Code Review，你都要粘贴同一段话：「按照我们团队的规范检查……重点关注这几个维度……输出格式是……」粘了 20 次之后你开始怀疑人生。

场景三：Claude 总是忘记「有些目录不能碰」

你在 CLAUDE.md 里写了「不要修改 legacy/ 目录的代码」，但 Claude 偶尔还是会手痒去改。不是它故意违规，是 CLAUDE.md 的规则是「建议」性质的，不是强制的。

场景四：需要 Claude 访问外部系统

你想让 Claude 直接查 Jira 看 ticket 描述、查 Sentry 看线上报错、查数据库看表结构。但 Claude Code 原生不支持这些，你只能手动复制粘贴。

场景五：复杂任务耗尽上下文

一个大重构任务，Claude 需要同时参考 10 个文件、跑测试、改代码。聊到一半发现上下文被压缩了，之前讨论的架构决策全忘了。

如果你中了 2 个以上，接下来的内容对你很有价值。

一张表：7 种方式速览

先给一张全局图，后面逐一展开。

关键区分：CLAUDE.md/Skills/Rules 是「建议」——Claude 会看到这些内容，但可以自行判断是否遵守。Hooks/Sub-agents/MCP/Settings 是「规则」——违反就会被阻断或无法执行。

图：7 种自定义方式的强制力和作用域对比——「建议」和「规则」的本质区别

决策框架：该用哪个？

拿到一个自定义需求时，按以下 3 个问题走决策树：

问题 1：这条规则需要「每次会话都生效」还是「特定场景才需要」？

• 每次都要 → 问题 2A

• 特定场景 → 问题 2B

问题 2A：规则是「告诉 Claude 怎么做」还是「强制 Claude 不能做某事」？

• 告诉怎么做 →CLAUDE.md（编码规范、命名习惯、项目架构）

• 强制不能做 →Hooks（禁止执行rm -rf、自动格式化）或Settings（权限 deny 规则）

问题 2B：这个场景是「一个可复用的工作流」还是「连接外部工具」？

• 可复用工作流 →Skills（Code Review 流程、发布检查清单、文档生成）

• 连接外部工具 →MCP Servers（Jira、Sentry、数据库、Figma）

问题 3：规则只适用于代码库的某个子目录吗？

• 是 →Rules（.claude/rules/配合paths字段）

• 不是 → 回到问题 2A/2B

额外判断：

• 需要隔离上下文、并行执行、限制工具权限 →Sub-agents

• 需要配置模型、权限白名单、环境变量 →Settings

• 快速自定义命令（团队已有历史存量） →Commands（.claude/commands/，已合并入 Skills 生态）

用一句大白话总结：CLAUDE.md 管「是什么」，Skills 管「怎么做」，Hooks 管「不能做」，Rules 管「哪里适用」，Sub-agents 管「谁来做」，MCP 管「能连什么」，Settings 管「全局开关」。

“

💬 你目前用得最多的是哪种自定义方式？

• A. 只用 CLAUDE.md，所有规则都往里塞

• B. 用过 Skills 或 Commands，但没深入配置

• C. Hooks / MCP / Sub-agents 都配过，已经是进阶玩家

• D. 还没开始自定义，Claude Code 开箱即用就够了

评论区说说，码哥猜选 A 的最多 😂

图：3 个问题走完决策树——拿到自定义需求时按这个流程选方式

逐一拆解：每种方式的原理 + 用法 + 反模式

1. CLAUDE.md：记忆系统

原理

CLAUDE.md 是 Claude Code 的「长期记忆」。每次会话启动时，Claude 会自动加载这些文件的内容到上下文窗口。它不是一次性指令，而是贯穿整个会话的持久化上下文。

加载顺序（从广到窄，内容拼接而非覆盖）：

1. 组织级（最高优先级）：macOS 在/Library/Application Support/ClaudeCode/CLAUDE.md，Linux 在/etc/claude-code/CLAUDE.md

2. 用户级：~/.claude/CLAUDE.md

3. 项目级：./CLAUDE.md或./.claude/CLAUDE.md

4. 本地个人级：./CLAUDE.local.md（gitignore 掉，不提交）

同一层级的CLAUDE.md和CLAUDE.local.md会拼接，不会互相覆盖。子目录下的 CLAUDE.md 文件在 Claude 读取该目录文件时按需加载。

支持@path/to/file语法导入其他文件内容，最多 4 层跳转。这个功能很实用——你可以把不同主题的规则拆成独立文件，用@引入，避免单文件过大。

用法示例

# CLAUDE.md ## 项目架构 本项目是 Spring Boot 3.2 单体，Java 17。 模块结构：api/（接口层）、service/（业务层）、dao/（数据层） ## 编码规范 - 使用 2 空格缩进 - 命名规范：类名 PascalCase，方法名 camelCase，常量 UPPER_SNAKE_CASE - Controller 不放业务逻辑，只做参数校验和路由 ## 构建与测试 - 构建：`./gradlew build` - 测试：`./gradlew test` - Lint：`./gradlew spotlessCheck` ## 引入子规则 @docs/database-conventions.md @api/rest-standards.md

反模式

反模式 1：文件超过 200 行

CLAUDE.md 的内容每次会话都会注入上下文窗口。文件越大，留给实际任务的上下文空间越小。超过 200 行之后，Claude 的遵从率会明显下降——不是它不想遵守，是注意力被稀释了。

解法：拆分。把长规则移到.claude/rules/里用paths字段做路径级匹配，或用@语法引入子文件。

反模式 2：写模糊指令

# 差的写法 格式化代码，保持风格统一。 # 好的写法 使用 2 空格缩进。行宽 120 字符。导入顺序：java.* → javax.* → 第三方 → 本项目。

Claude 不怕长指令，怕模糊指令。「格式化代码」这种话它理解不了你具体要什么格式。

反模式 3：在 CLAUDE.md 里写流程步骤

如果你发现自己在 CLAUDE.md 里写了「第一步做 X，第二步做 Y，第三步做 Z」——这不是 CLAUDE.md 该干的事。流程步骤应该用 Skills 封装，按需调用，不占日常上下文。

2. Skills：可复用工作流

原理

Skills 是 Claude Code 的「剧本」。把一个可重复执行的工作流打包成一个 Skill，需要的时候调用，不需要的时候不占上下文。

这是和 CLAUDE.md 最关键的区别：CLAUDE.md 的内容每次会话都在上下文里，Skills 的内容只有被调用时才加载。Skill 的描述（description）会一直留在上下文中供 Claude 判断是否需要调用，但完整内容按需加载。

配置格式

.claude/skills/ └── code-review/ └── SKILL.md

SKILL.md 由 YAML frontmatter + Markdown body 组成：

--- name: code-review description: "按团队规范执行 Code Review，检查安全、性能、可读性" when_to_use: "用户要求 review 代码或提交 PR 前" argument-hint: "[file-or-pr]" model: sonnet effort: high paths: ["src/**/*.ts"] allowed-tools: Read, Grep, Glob, Bash(git *) --- ## Code Review 清单 1. 安全检查：SQL 注入、XSS、硬编码密钥 2. 性能检查：N+1 查询、大对象循环创建 3. 可读性：方法不超过 30 行、命名自解释 $ARGUMENTS 指定要 review 的文件或 PR。

几个实用的 frontmatter 字段：

• context: fork— 在隔离的子智能体中运行，不污染主对话上下文

• disable-model-invocation: true— 只能用户手动/skill-name调用，Claude 不会自动触发

• user-invocable: false— 反过来，只有 Claude 能自动调用，用户不能手动触发

• model: haiku— 用更快更便宜的模型执行这个 Skill（适合搜索、探索类任务）

动态上下文注入：在 SKILL.md 中用!`git diff HEAD`语法，Claude 看到内容前会先执行 shell 命令，把输出注入上下文。这个功能非常强大——你可以让 Skill 在执行时自动获取当前 git 状态、最近的变更、测试结果等实时信息。

反模式

反模式 1：把所有 Skill 都设成disable-model-invocation: true

你可能觉得「我不想让 Claude 自动调用 Skill，万一调错了怎么办」。但如果你全部禁用了自动调用，Claude 永远不知道你有这些 Skill——description 虽然在上下文里，但 Claude 判断「用户没明确要求，我不应该自动调用」。结果就是你的 Skills 库变成了摆设。

解法：大部分 Skill 保持默认（允许自动调用），只对有副作用的 Skill（如部署、删除）设disable-model-invocation: true。

反模式 2：Skill body 太长

Skill 的完整内容在调用后会留在上下文中。如果你写了一个 5000 token 的 Skill，每次调用后这 5000 token 就一直占着上下文窗口。Compaction 之后会重新附加，但有上限（单个 Skill 最多 5000 token，总计 25000 token）。

解法：把参考材料放在 Skill 目录的辅助文件里，SKILL.md 只放核心流程。用@references/xxx.md引入。

反模式 3：用context: fork跑纯指南类 Skill

context: fork会创建一个隔离的子智能体来执行 Skill。如果你的 Skill 只是「告诉 Claude 某些规范」而不是「让 Claude 执行一系列操作」，fork 出来的子智能体会拿到指南但没有明确的执行 prompt，效果反而不如不 fork。

3. Hooks：生命周期钩子

原理

Hooks 是 Claude Code 的「自动执行器」。它在特定生命周期事件发生时，自动运行你配置的脚本、HTTP 请求、甚至 LLM 提示。和 CLAUDE.md 最大的区别：Hooks 是强制执行的——exit code 2 会直接阻断操作，不是建议。

配置位置：settings.json的hooks字段（用户级或项目级）。

支持 30+ 种事件，最常用的几种：

5 种 Hook 类型：command（Shell 命令）、http（POST 请求）、mcp_tool（调用 MCP 工具）、prompt（单轮 LLM 评估）、agent（子智能体评估）。

用法示例：在文件编辑后自动运行 Prettier 格式化

{ "hooks": { "PostToolUse": [ { "matcher": "Edit|Write", "hooks": [ { "type": "command", "command": "npx prettier --write", "args": ["${CLAUDE_FILE_PATH}"], "timeout": 30 } ] } ] } }

exit code 的含义（这是最容易搞错的）：

• exit 0：成功，继续执行

• exit 1：非阻断性错误（记录日志，不影响主流程）

• exit 2：阻断性错误（直接阻止操作）

反模式

反模式 1：用 exit 1 以为能阻止操作

这是最常见的误解。你在 Hook 脚本里检测到危险命令，exit 1退出——结果 Claude 照样执行了。原因很简单：exit 1 只是非阻断性错误，Claude 收到一个「Hook 报了个错」的提示，但它可以选择忽略。

解法：要阻止操作，必须exit 2。或者在 stdout 输出 JSON：{"decision": "block", "reason": "不允许执行 rm -rf"}。

反模式 2：不加if过滤器，每个工具调用都触发 Hook

{ "matcher": "*", "hooks": [{ "type": "command", "command": "my-script.sh" }] }

这会每次工具调用都 spawn 一个新进程。Claude 一次对话可能调用几十次工具，你的脚本就跑几十次。轻则浪费时间，重则拖慢整个对话。

解法：用matcher精确匹配工具名（如"Bash"、"Edit|Write"），用if字段进一步缩小范围（如"if": "Bash(rm *)"）。

反模式 3：在 Hook 里做复杂逻辑

Hook 的设计初衷是「短平快」的自动化操作。如果你发现自己在 Hook 脚本里写了 200 行 Python——停下来，这应该是 Skills 或 Sub-agents 干的事。

4. Rules：路径级规则

原理

Rules 是 CLAUDE.md 系统的子功能，解决一个具体问题：不同目录需要不同的规则。

在单体仓库（monorepo）里，前端目录和后端目录的编码规范可能完全不同。用一个 CLAUDE.md 写两套规则会很混乱。Rules 允许你为不同路径配置不同规则，只有 Claude 访问到对应目录时才加载。

配置方式：在.claude/rules/目录下创建.md文件，用 YAML frontmatter 的paths字段指定适用路径。

--- paths: ["src/api/**", "tests/api/**"] --- ## API 层规范 - Controller 方法必须有 @Validated 注解 - 返回值统一用 ResponseEntity 包装 - 异常用 @RestControllerAdvice 全局处理

--- paths: ["src/dao/**", "resources/mapper/**"] --- ## 数据层规范 - 禁止在 DAO 层拼接 SQL，必须用 MyBatis XML - 分页用 PageHelper，不要手写 LIMIT

反模式

反模式 1：Rules 和 CLAUDE.md 写了重复甚至矛盾的规则

Rules 在 CLAUDE.md 之后追加加载，如果两边写了矛盾的内容，Claude 的行为会不可预测。

解法：CLAUDE.md 只写全局规则，Rules 写路径特化规则。全局和局部不要有交集。

反模式 2：paths写得太宽泛

paths: ["**"]等于没写——这和直接放 CLAUDE.md 里没区别。Rules 的价值就在于精准匹配。

5. Sub-agents：子智能体

原理

Sub-agents 是 Claude Code 的「分身术」。当你有一个复杂任务时，可以创建一个专用的子智能体来处理。它有自己独立的上下文窗口，不会污染主对话。执行完毕后把结果返回主智能体。

核心价值：

• 上下文隔离：子智能体的执行过程不会撑大主对话的上下文

• 工具限制：可以限制子智能体只能用 Read/Grep 等只读工具，防止它乱改代码

• 并行执行：多个子智能体可以同时跑（最多 5 层嵌套深度）

• 模型路由：可以让探索任务用便宜快速的 Haiku，深度任务用 Sonnet/Opus

配置方式：在.claude/agents/目录下创建.md文件。

--- name: code-reviewer description: "审查代码质量、安全性和最佳实践" tools: Read, Glob, Grep, Bash disallowedTools: Write, Edit model: sonnet maxTurns: 50 isolation: worktree --- 你是一个代码审查专家。分析代码并提供具体、可执行的反馈。 重点关注：安全性、性能、可维护性。

三种调用方式：

1. 自然语言：在对话中描述任务，Claude 自行判断是否委派给子智能体

2. @提及：@code-reviewer 看看 auth 模块的改动，保证运行一次

3. 会话级：--agent code-reviewer，整个会话使用该子智能体

内置子智能体（不需要你创建）：

• Explore：Haiku 模型，只读，用于快速搜索和探索（跳过 CLAUDE.md 和 git status 加载，速度最快）

• Plan：继承当前模型，只读，用于规划和研究

• general-purpose：所有工具，用于复杂多步任务

反模式

反模式 1：description 字段写得太模糊

# 差的写法 description: "帮我处理一些任务" # 好的写法 description: "审查 TypeScript 代码的质量、安全性和性能问题，输出结构化的 review 意见"

Claude 靠 description 判断什么时候该委派任务给这个子智能体。写得模糊，它就不知道什么时候用。

反模式 2：复制内置子智能体的功能

你不需要创建一个「explorer」子智能体来做搜索——内置的 Explore 已经做了，而且用了更便宜的 Haiku 模型。自定义子智能体应该做内置子智能体做不了的事。

反模式 3：子智能体嵌套太深

子智能体可以生成子智能体，最多 5 层。但每多一层就多一个上下文窗口的开销。除非确实需要，否则 1-2 层就够了。

6. MCP Servers：外部工具连接

原理

MCP（Model Context Protocol）是 Anthropic 推出的开放协议，让 Claude Code 能连接外部工具、数据库和 API。它解决了 Claude Code 原生「只能操作本地文件和终端」的限制。

有了 MCP Server，Claude 可以直接查 Jira ticket、查 Sentry 报错、查数据库表结构、操作 Figma 设计稿——不需要你手动复制粘贴。

配置方式：

CLI 方式（推荐，一行命令搞定）：

# 远程 HTTP 服务 claude mcp add --transport http notion https://mcp.notion.com/mcp # 本地 stdio 进程 claude mcp add --transport stdio airtable -- npx -y airtable-mcp-server

JSON 方式（.mcp.json，可提交到仓库共享给团队）：

{ "mcpServers": { "github": { "type": "http", "url": "https://api.githubcopilot.com/mcp/", "headers": { "Authorization": "Bearer ${GITHUB_TOKEN}" } }, "database": { "command": "/path/to/db-server", "args": ["--config", "config.json"], "env": { "DB_URL": "${DB_URL}" } } } }

三种传输协议：

• http（推荐）：适合远程服务，自动重连，支持 OAuth

• stdio：适合本地进程，Claude 启动子进程通信

• ws（WebSocket）：适合需要推送事件的场景

反模式

反模式 1：在.mcp.json里硬编码 API Key

// 千万别这么写 "headers": { "Authorization": "Bearer sk-xxxxx" } // 用环境变量 "headers": { "Authorization": "Bearer ${GITHUB_TOKEN}" }

.mcp.json通常会提交到 Git 仓库。硬编码的密钥会被所有 clone 仓库的人看到。

反模式 2：不信任远程 MCP Server 的安全性

MCP Server 本质上是给 Claude 注入外部数据和工具。如果远程 Server 被攻击者控制，它可以往 Claude 的上下文里注入恶意指令（prompt injection）。企业环境里，用allowedMcpServers/deniedMcpServers做白名单控制。

反模式 3：用 SSE 传输（已废弃）

SSE（Server-Sent Events）已经被标记为 deprecated，官方推荐用http替代。如果你在文档里看到 SSE 的配置示例，直接换成 http。

7. Settings：配置系统

原理

Settings 是 Claude Code 的「控制面板」。它管理全局行为：权限规则、模型选择、环境变量、UI 偏好等。

配置层级（优先级从高到低）：

1. 组织级（managed settings）：管理员配置，个人无法覆盖

2. CLI 参数：命令行传入，临时生效

3. 本地项目级：.claude/settings.local.json（gitignore）

4. 项目级：.claude/settings.json（提交到仓库）

5. 用户级：~/.claude/settings.json（最广，优先级最低）

权限规则的特殊合并逻辑：其他设置是「高优先级覆盖低优先级」，但权限规则是跨层级合并的。也就是说，项目级的allow规则和用户级的allow规则会合并在一起，不会互相覆盖。

用法示例

{ "$schema": "https://json.schemastore.org/claude-code-settings.json", "permissions": { "allow": [ "Bash(npm run lint)", "Bash(npm run test *)", "Read(~/.zshrc)" ], "deny": [ "Bash(curl *)", "Read(./.env)", "Read(./secrets/**)" ] }, "model": "claude-sonnet-4-6", "language": "chinese", "autoCompactEnabled": true }

反模式

反模式 1：直接编辑~/.claude.json

这个文件是 Claude Code 内部管理的，手动编辑可能导致不可预期的行为。用户级设置应该改~/.claude/settings.json。

反模式 2：不用$schema做校验

Settings 是 JSON 格式，少一个逗号就解析失败。加上$schema字段后，编辑器会自动校验字段名和类型，提前发现错误。

反模式 3：在 Settings 里写行为指令

Settings 管的是「配置」——权限、模型、环境变量。如果你在 settings.json 里写了「请使用 2 空格缩进」这种行为指令，它不会生效。行为指令应该放 CLAUDE.md。

实战组合：一个真实项目的配置

光讲理论不够，给一个我实际在用的项目配置结构：

my-project/ ├── CLAUDE.md # 全局规则（< 100 行） ├── .claude/ │ ├── settings.json # 权限规则 + Hooks │ ├── rules/ │ │ ├── api-rules.md # API 层专用规则 │ │ └── dao-rules.md # 数据层专用规则 │ ├── skills/ │ │ ├── code-review/ │ │ │ └── SKILL.md # Code Review 工作流 │ │ └── deploy-check/ │ │ └── SKILL.md # 部署前检查清单 │ ├── agents/ │ │ └── security-auditor.md # 安全审计子智能体 │ └── mcp.json # MCP Server 配置 └── .claude/settings.local.json # 本地个人覆盖（gitignore）

CLAUDE.md 里只放全局的、简短的规则（< 100 行）。路径特化的规则拆到rules/里。可复用的工作流拆到skills/里。需要隔离执行的任务用agents/处理。外部工具用mcp.json连接。权限和 Hooks 放settings.json。

这样每个文件各司其职，不会出现一个 500 行的 CLAUDE.md 把所有东西塞在一起的情况。

常见问题

Q: CLAUDE.md 和.claude/CLAUDE.md有什么区别？放哪个位置更好？

A: 两个位置都会被加载，效果一样。区别在于文件系统的位置：项目根目录的CLAUDE.md更显眼，.claude/CLAUDE.md更整洁（不污染根目录）。如果你的项目根目录已经有 README.md、package.json 等一堆文件，建议放.claude/CLAUDE.md。两种都行，选一个团队统一就好。

Q: Skills 和.claude/commands/是什么关系？我之前的 commands 还能用吗？

A: Skills 是 commands 的升级版。Anthropic 已经把两者统一了——commands 文件仍然有效，但新功能（如context: fork、paths匹配、辅助文件）只在 Skills 里支持。如果你已有 commands，不需要迁移，它们会继续工作。但新的自定义命令建议用 Skills。

Q: Hooks 和 CLAUDE.md 的规则有什么本质区别？

A:CLAUDE.md 是「建议」，Hooks 是「规则」。CLAUDE.md 写「不要修改 legacy/ 目录」，Claude 会尽量遵守，但偶尔可能违反。Hook 配置PreToolUse检测到对legacy/目录的写操作时返回 exit 2，操作会被直接阻断——Claude 根本没有机会违反。

如果你的规则必须被严格遵守（安全、合规、防误操作），用 Hooks。如果是编码风格、偏好建议，用 CLAUDE.md。

Q: 我需要为每个项目都配置 MCP Server 吗？

A: 不一定。MCP Server 有三个作用域：本地（.mcp.json在项目目录，只对当前项目生效）、项目（.mcp.json提交到仓库，团队共享）、用户（~/.claude.json配置，所有项目通用）。像 GitHub MCP 这种通用的，放用户级；项目特定的数据库 Server，放项目级。

Q: 7 种方式会不会互相冲突？

A: 会，最常见的冲突有两种。一是 CLAUDE.md 和 Rules 写了矛盾的内容——解法是 CLAUDE.md 只写全局规则，Rules 写路径特化规则，不重叠。二是 Hooks 和 Settings 的权限规则冲突——Hooks 在 settings.json 里配置，如果项目级 Hook 阻止了某个操作，但用户级 Settings 的 allow 规则放行了，结果取决于合并逻辑。建议团队统一在一个层级配置，不要分散。

图：每种方式最常见的反模式——踩过才知道为什么不能这么干

说到底，Claude Code 的 7 种自定义方式不是「哪个更好」的问题，是「什么场景用什么」的问题。把所有规则塞进 CLAUDE.md，就像把所有衣服扔进一个抽屉——你当然能塞进去，但找的时候全乱。拆开来各司其职，Claude 的表现会好很多。

这篇文章把每种方式的原理、用法和反模式都拆了一遍，但最核心的其实是那个决策框架——下次遇到自定义需求，先问自己三个问题，答案自然就出来了。

下一篇打算拆 Claude Code 的 Hooks 实战——30 多种事件怎么选、5 种 hook 类型怎么搭配、真实的自动化工作流怎么搭。感兴趣的关注一下，说实话公众号算法越来越不按常理出牌了，把码哥字节设为星标至少保证你能收到更新，不会错过。如果你身边有同事在用 Claude Code 但还没搞清楚这些配置方式，这篇可以直接甩给他，省他踩一遍。

如果这篇对你有帮助，转发给你的程序员朋友— 大家都在摸索 Claude Code 的正确用法，你的分享可能帮他省很多时间。