企业官网建设流程全解析

我见过太多在终端里运行 Claude Code 的人，用法基本停留在一个模式——把需求丢给它，等它改完代码，再手动 review。这个用法没错，但坦白说，只用到这个工具最表层的那一部分。Claude Code 的深层能力，大部分藏在斜杠命令、配置文件、环境变量和钩子事件里，这些功能 90% 的人确实没见过，不是因为它们不存在，而是因为它们从不写在最显眼的界面上。如果你已经在用 Claude Code 写代码、做重构、跑自动化脚本，这篇内容对你应该很有用；如果你还没开始用，建议先跑通基础流程再回来读，很多细节需要真实语境才能体会。

1. 隐藏功能都藏在哪里：先搞懂 Claude Code 的功能分层

1.1 表层交互：为什么大多数人只发挥了一半战力

先聊一个观察：大多数用户和 Claude Code 的交互，本质上只有三种——输入自然语言需求、查看输出、复制代码。三个动作循环往复，看起来挺顺，实际上丢掉了大量效率。

原因在于，Claude Code 并不是一个简单的“对话框 + 代码生成器”，它更像一个运行在终端里的开发代理。它能调用你的文件系统、执行终端命令、修改代码、跑测试，甚至能自己启动子代理来处理任务。这些能力如果不主动去配置，默认只开放了一小部分。

举一个最典型的例子：权限模式。默认情况下，Claude Code 每做一件有副作用的事（改文件、跑命令）都要先征求你的同意，这是安全设计。但如果你在处理一个已经明确边界的小任务，比如“把某个目录下所有 Python 文件的 import 排序”，每次都点确认就很浪费。你完全可以用--permission-mode参数一次性放宽权限，让工具自动完成整个流程。这个参数躺在文档里，但官方首页不会告诉你，因为它涉及安全取舍。

还有一个被严重忽略的是会话生命周期管理。很多人打开终端就输入claude，也不看会话 ID，用完直接退出。下次再开又是一个全新上下文，之前聊的需求、改过的代码、确认过的偏好全部丢失。这种用法等于让一个结对程序员每次见面都失忆一次。

1.2 功能入口的入口：斜杠命令、settings.json 与 .claude 目录

Claude Code 的隐藏功能不是堆在某个菜单里的，它们分散在三个地方，搞清楚这三个入口，基本上就拿到了 80% 的隐藏玩法。

第一个入口是斜杠命令。在对话里输入/就能看到命令列表，但很多人从来没往下翻过。/compact用于压缩上下文、/model用于切换模型、/cost用于查看开销、/vim甚至能切换成 vim 编辑模式。这些命令中的每一个都是独立的“隐藏功能单元”，而且你可以写自定义斜杠命令放进项目配置里。自定义命令本质上是把一段经常用的提示词固化成快捷指令，比如我给自己配了一个/review，输入后自动按照团队规范检查当前分支的代码改动，省掉每次手打一大段要求的功夫。

第二个入口是settings.json 配置文件。它分为用户级和项目级，用户级在~/.claude/settings.json，项目级在<项目根目录>/.claude/settings.json。两级的配置会做合并，项目级优先。权限规则、钩子脚本、模型偏好、环境变量都写在里面。我见过很多开发者改完配置发现不生效，原因就是文件位置放错了，一直改的是用户级，但项目级有同名配置直接覆盖了它。

第三个入口是.claude/项目目录。这个目录不仅可以放 settings.json，还能放CLAUDE.md，也就是给 Claude Code 看的“项目说明书”，以及存放会话存档、自定义命令的目录。它本身就是一个完整的配置空间，不只是单文件。理解了这个目录结构，你才会明白为什么说这是个“可编程工具”，而不是聊天玩具。

1.3 为什么官方把功能“藏起来”：设计取舍的思考

很多人会问：功能既然这么好用，为什么不全部摆在默认界面里？我的理解是，Claude Code 的定位更像一个开发基础设施，而不是消费级应用。它默认只开放最安全、最保守的交互路径，高级功能需要你主动表达“我懂我在做什么”，才会放出来。

举一个例子：--dangerously-skip-permissions这个参数，看名字就知道它是“跳过所有权限检查”。官方不可能默认开启，但它在 CI 自动化场景里几乎是必需品。类似的还有钩子系统，它可以拦截每一次工具调用。让普通用户一开始就面对这些能力，结果只有两个：要么误操作，要么产生安全风险。

所以“隐藏”并不是故意藏，而是一种分级开放策略。你越往深处探索，权限越大，承担的责任也越大。这其实也是这类工具该有的态度。理解了这个底层逻辑，后面所有功能接受起来就顺理成章了。

2. 会话与任务编排：恢复、分支与并行，效率差距在这里拉开

2.1 丢失上下文是最大的隐形浪费：会话恢复参数

先说一个我踩了很久的坑：早期我用 Claude Code 做重构，一次会话动辄一两个小时，中间可能因为电脑重启、终端误关、网络波动导致会话中断。重新打开又是全新对话，还得花二十分钟把背景讲一遍。后来我才注意到启动参数里有一组专门管会话恢复的命令。

claude --continue是继续最近一次会话，这个最常用。claude --resume <session-id>则是从历史会话列表里挑一个指定恢复。配合claude --list-sessions可以查看历史会话 ID，三个命令配合起来，基本上可以把任何一个进行中的任务重新拉起来，上下文、对话历史、未完成的代码修改，全都在。

我现在的习惯是：每个任务开着独立会话，改到一半要去做别的事，就记录下当前的 session ID。回来后直接--resume，完全无缝衔接。这套操作的好处不仅仅是省时间，更重要的是保持上下文稳定。Claude Code 的上下文窗口是连续对话累积出来的，越聊它越懂你的项目，频繁开新会话等于把记忆清零重来。用会话恢复，就相当于让同一个“结对程序员”持续跟进同一个任务，认知不中断。

注意：claude --continue恢复的会话依旧受上下文窗口限制。如果聊得太久已经compact过多次，恢复后建议主动手动compact一次，把冗余压缩掉。

2.2 一个会话同时干三件事：Task 工具与多智能体协作

初次用 Claude Code 的人，几乎不会主动触发它的**子代理（Subagent）**机制。这个能力的入口不在配置里，而在提示词用法中。你可以直接对 Claude 说：“启动一个子代理去检查src/utils目录下的代码规范问题，另一个子代理去跑测试，主线程继续跟我讨论架构调整。”它内部会通过 Task 工具创建出多个并行执行的子代理，每个子代理有独立的上下文窗口，最后把结果汇总回来。

这个功能的厉害之处在于让一个会话同时处理多线程的事。比如重构一个大型模块时，我经常会要求主代理去思考整体方案，同时派一个子代理去读旧代码并输出“哪些函数被废弃”、再派一个去检查现有测试覆盖。子代理返回的结果是结构化的，主代理会基于这些结果做判断。你不需要自己手动切来切去。

在输出里你会看到类似Task这样的工具调用记录，每个记录都有对应的子代理 ID。如果某个子代理需要更长时间，它还会返回“还在运行、稍后继续处理”这样的中间结果。理解了这套机制，你就知道为什么 Claude Code 能在大型项目里表现不错——它本质上是一个能自我编排多角色协作者的系统。

2.3 让 Claude 自己去跑：自动接受编辑与批量处理

再往下走，就是很多人既心动又谨慎的领域：自动化执行。使用--permission-mode acceptEdits可以让 Claude Code 自动接受对文件内容的修改，不需要每一步确认，但执行终端命令仍然会询问。这个模式适合你已经明确授权“你可以直接改我的代码文件”的场景，比如批量替换、格式化、处理 TODO 注释等。

如果你想连命令执行也一并放行，那就是--dangerously-skip-permissions。我自己的使用建议是：

• 本地开发环境：用acceptEdits就够，保留命令执行的校验环节；
• CI/自动化环境：才考虑完全跳过权限，前提是 CI 运行在临时环境里，不涉及生产数据；
• 请务必不要：在任何有持久化数据、支付逻辑或生产密钥的环境里使用完全跳过权限模式。

用自动化模式跑大任务还有一个附带好处：你能把“写需求 → 让工具执行 → 人工 review”变成标准流水线。我现在很多日常小任务已经不用手动交互，写好一段需求文本，直接claude --print传进去，让它自动完成并输出结果，适合写脚本、生成文档、数据转换这类边界清晰的任务。

3. 上下文与记忆管理：让 Claude Code 真正“记住你”

3.1 CLAUDE.md：项目记忆与个人风格的最佳实践

聊一个熟悉度极高的文件：CLAUDE.md。很多人知道这个文件是给 Claude Code 看的“说明文档”，但几乎没人把它用到位。实际上，它是我认为 Claude Code 最有价值的自定义入口，因为它是唯一能持续穿透会话边界的长效记忆。

Claude Code 每次启动会话都会主动读取两个位置的CLAUDE.md：用户级在~/.claude/CLAUDE.md，项目级在项目根目录。用户级适合写个人偏好，比如你希望它默认用 ZSH、不要修改某些文件、代码风格偏好；项目级适合写项目事实，比如框架选型、目录结构、命名规范、常见坑位。

我举个实际片段，某项目里的CLAUDE.md的写法是这样的：

# 项目说明：某跨平台控制台 ## 技术栈 - React 17 + TypeScript - 构建工具：Vite - 测试框架：Vitest ## 代码约定 - 所有导出的接口函数必须写 JSDoc - 不允许使用 any，类型定义放在 types/ 目录 - 文件命名使用 camelCase，组件使用 PascalCase ## 已知坑位 - 修改 vite.config.ts 后不需要重启 dev server，会热更新 - mock 数据统一放在 __mocks__ 目录，禁止在业务代码里内联 mock ## 常用命令 - 构建：npm run build - 单测：npm run test -- --run

为什么这个文件对性能影响那么大？因为省掉了大量“重新解释背景”的过程。它相当于一个压缩后的项目认知，每次新会话都能立刻加载。换句话说，设置好这个文件之后，Claude Code 每次开工都相当于一个已经熟悉项目一个月的老手，而不需要你从头给它做入职培训。

使用经验：CLAUDE.md不是越长越好。太长会导致每次请求都要消耗大量 token。我建议控制在一屏左右，只写“必须遵守”和“项目特有的关键信息”，其余通用规范交给模型常识。

3.2 上下文窗口爆了怎么办：compact、clear 与会话存档

上下文窗口是所有大模型工具绕不开的天花板。Claude Code 默认会在接近窗口上限时给出提示，但很多人不知道如何处理。更常见的情况是：你让它读了一堆大文件、改了一堆代码之后，它开始答非所问、表现变笨，这大概率不是模型变傻了，而是上下文塞太满，注意力被稀释了。

这个时候就该compact出手。输入/compact，Claude Code 会把当前对话的核心内容（任务目标、已完成修改、待办事项）压缩成一段摘要，然后基于摘要开始新的一轮。这个命令我几乎每个长会话都要用两三次。使用时机有讲究：不要在任务进行到一半、需要精确定位某个细节时compact，压缩后部分细节会失真；比较稳妥的时机是“当前阶段已完成、下一步是一个能独立描述的新任务”时。

如果你想要更强的清理效果，可以用/clear清空整个上下文，相当于开新会话但不退出。但/clear不推荐在长任务中途用，它会把所有记忆包括关键的背景信息全部清掉。如果确实需要彻底清空，我更建议用claude --continue重新拉起最近会话，配合/compact做一次温和压缩，这样至少还保留任务目标。

还有一个容易被忽略的会话存档功能：在.claude/目录下有会话记录文件，你可以手动备份、归档这些文件。当项目告一段落，把关键会话存成一个“决策记录”文件，后续重启任务时直接让 Claude Code 读这个文件，相当于把一次大型任务的记忆固化成项目资产。

3.3 输出结构化：把 Claude Code 当成可编程工具

很多人不知道，Claude Code 不只是交互式对话工具，它还提供了非常干净的编程接口。启动时加上--output-format json，所有输出就是 JSON 流，每条消息有类型标记、内容片段、工具调用记录。加上--input-format stream-json则可以自己写程序来喂输入，实现完全编程化的调用。

我第一次玩这个模式时，在脚本里把一段需求文本通过管道喂给 Claude Code，然后让它在输出里带上“完成结果+修改文件列表+测试结果”的结构化数据。整个流程完全可以嵌入到 CI 或消息机器人里。这套机制的意义在于，让工具从“终端里的对话伙伴”变成了“可编程的代码处理服务”。

实际用法例子：我在一个批处理脚本里用 Claude Code 自动把某个旧接口的调用方从同步改成异步。脚本把这个任务用 JSON 格式传给工具，输出解析后自动生成变更摘要。整个过程不需要人去盯着每一步确认，等跑完再看结果。对经常处理重复性开发任务的团队，这种玩法价值巨大。

4. 钩子系统与无人值守：把 Claude Code 变成流程的一部分

4.1 钩子到底是什么：用事件驱动来干预工具行为

如果说配置文件和斜杠命令还只是“设定偏好”，那么钩子（Hooks）系统就是真正的开发级功能。Hooks 是一段脚本，当特定事件发生时自动运行。Claude Code 内部定义了多个事件节点，比如工具调用前、工具调用后、用户提交提示词后、会话结束时等等。你只需要在 settings.json 里把这些节点映射到本地脚本，就能在公司级需求下细粒度地控制工具行为。

我整理了一下常用的钩子事件：

理解这些事件的关键在于：它们让你在“AI 执行动作”和“AI 所需权限”之间加了一层自己的逻辑。比如你可以写一个 PreToolUse 钩子，当 Claude 试图读取.env文件时直接报错并停止执行。这个脚本是本地代码，不受 AI 的控制，因此是很可靠的边界手段，比单纯依赖模型的“自我约束”稳健得多。

4.2 一个实用的钩子例子：每次工具调用前自动做安全审查

直接上一个可以抄作业的例子。假设你想禁止 Claude Code 读取.env文件和任何密钥文件，同时想拦截包含“删除整个目录”的 bash 命令，可以这样配置：

先写一个检查脚本security-guard.py：

#!/usr/bin/env python3 import json import sys payload = json.loads(sys.stdin.read()) tool_name = payload.get("tool_name", "") tool_input = payload.get("tool_input", {}) DENY_PATTERNS = ["rm -rf", "DROP TABLE"] DENY_FILES = [".env", "id_rsa", ".npmrc"] if tool_name == "Read": file_path = tool_input.get("file_path", "") if any(d in file_path for d in DENY_FILES): print("ERROR: 禁止读取敏感文件: {}".format(file_path)) sys.exit(2) if tool_name == "Bash": command = tool_input.get("command", "") if any(p in command for p in DENY_PATTERNS): print("ERROR: 检测到危险命令，已拦截: {}".format(command)) sys.exit(2) print("OK")

然后在项目的.claude/settings.json里配置：

{ "hooks": { "PreToolUse": [ { "matcher": "Read|Bash", "hooks": [ { "type": "command", "command": "python3 /path/to/security-guard.py" } ] } ] } }

配置完成后，每次 Claude 想用 Read 或 Bash 工具，这个脚本都会先收到 JSON 输入，输出OK就放行，输出ERROR就拦截，退出码非 0 会直接终止操作。这个方案亲测在团队协作场景非常有效，作为最后一道工具防线，比等着 review 代码更早地发现风险。

重要提示：钩子脚本的输出并不包含在 AI 的对话上下文里，它只会影响“是否放行”。所以脚本要做的事情是“拦截”，而不是“修改 AI 计划”。

4.3 无人值守运行：CI 里的 Claude Code 玩法

很多团队把 Claude Code 接进 CI 的自动化流水线后，才算真正把它的能力释放出来。无人值守模式最核心的诉求是：在没有人类交互的情况下，让它完成一系列任务，并且知道什么时候该停、什么时候该报错。

我实际的做法是：创建一个独立分支让 Claude Code 自动执行“生成变更 + 跑测试 + 提交代码”，然后人工触发时再 review 合入。具体流程是这样的：

1. 在 CI 里安装好 Claude Code 环境；
2. 使用--dangerously-skip-permissions或 hooks 白名单模式启动；
3. 喂给它一个明确的任务文本，比如“修复所有 TypeScript 编译错误，并补充缺失的测试用例，如果测试不通过则返回失败状态”；
4. 配合--output-format json解析最终状态。

这套流程跑起来的关键是任务指令要写得足够收敛。不要给模糊指令，比如“优化项目结构”，而是给出可验证的目标。任务输出最好也做结构化约定，让 CI 能直接读结果判断成功与否。如果你希望更保守，可以在 CI 中只允许Read和Edit工具被自动批准，所有 Bash 命令通过钩子逐个白名单化。这个折中方案既兼顾自动化，又把破坏性操作限制在人工确认范围内。

5. 花钱与限额：被忽视的成本控制与用量统计

5.1 每条指令多少钱：理解计费与上下文开销

Claude Code 不是免费的，这个很多人知道，但很少有人算过账。它的计费模型基于 token 消耗，包括输入的上下文 token 和生成的输出 token。一次长对话里，每轮请求都会把历史对话内容重新发送一次，所以对话越长、消耗越大。随着讨论深入、读取文件增多、代码修改频繁，单条消息的成本可能是刚开始几句的十几倍。

我见过有人开着超长会话刷任务，一个上午花掉大量额度。关键原因不是模型贵，而是他们没有成本控制意识。每轮请求的“输入 token”包含了所有历史消息。也就是说，哪怕你这条消息只写了“继续”两个字，计费时也要算上前面几万 token 的历史，开销非常快。

5.2 用内置统计功能看真实消耗

好在 Claude Code 内置了开销统计入口。在对话里输入/cost可以看到当前会话预估的 token 与费用，起止时间、模型名、输入输出 token 都有明细。对于做自动化批处理的开发者，也可以读取本地日志、配置解析统计字段，把多次会话的消耗汇总成报告。

建议开发者在每天结束工作前花十几秒看一眼/cost的统计结果。长期下来你能形成直觉：哪种任务耗 token 多，哪种任务性价比高。我自己的经验是：让 Claude Code 浏览大型目录树并逐文件分析时，token 消耗会像坐火箭一样飙升；而把任务明确限定为“只读某个文件、只改某个函数”时，成本小得多。这个认知会直接影响你如何设计任务描述。

5.3 省钱实操：减少无效 token 的几个习惯

基于上面的分析，几个省钱习惯非常有效：

• 控制上下文增量：在任务描述里写明“只需读取 X 文件，不要浏览整个目录”，避免它把无关文件塞进上下文；
• 及时 compact：长对话推进到新阶段时，主动/compact压缩历史；
• 细化任务边界：一次只让 Claude 完成一个明确的子任务，而不是笼统地说“看看这个项目哪里有问题”；
• 减少不必要的自动工具调用：权限放太宽时，Claude 有时会自动读取更多文件来“确认事实”，但这些读取大部分不是必需的。

这些习惯直接指向同一个原则：上下文即成本。你喂进去多少 token，决定了最终账单多大。让工具更精准地干活，不仅速度快，而且花得少，这个账很容易算。

6. 常见问题与排查技巧实录

6.1 改了配置不生效：三个最常见的翻车原因

配置不生效是所有配置型工具的通病，Claude Code 也不例外。我碰到最多的场景有三类：

第一类是文件路径放错。用户级和项目级配置并存时，项目级优先，但很多人只改了用户级的~/.claude/settings.json，项目里同名配置却覆盖了它。排查方法很简单：在对话里问 Claude Code 当前生效的配置是什么，它会直接输出从两个级别合并后的结果，一眼就能看出项目级覆盖了什么。

第二类是JSON 格式错误。settings.json 里任何一个多余逗号都会导致整个配置被静默丢弃。建议写完配置后用命令行工具先校验格式。

第三类是没有重启会话。配置文件的读取时机是启动时，如果会话已经开着，改配置不会实时生效。需要退出重进或使用特殊命令重新加载配置，否则一切都是无效操作。

6.2 hooks 脚本不触发：别忽略退出码和权限

钩子脚本不触发，先说结论：八成是退出码或文件权限问题。钩子脚本执行失败时，Claude Code 不会大张旗鼓地报错，而只是静默地把这个事件当作“未拦截”，工具照常执行。这意味着如果你的脚本里存在 import 错误或路径不存在，它可能压根没有正确运行。

排查路径如下：先看脚本本身在命令行下是否可执行，确认有执行权限，再确认脚本能正确读取 stdin 传入的 JSON。写一个简单调试脚本，先把 stdin 内容原样打印到日志文件，再逐步增加逻辑，就能定位问题。另一个容易被忽略的是 matcher 字段的大小写，如PreToolUse不能写成pretooluse，事件名是区分大小写的。

6.3 权限模式带来的安全隐患：如何优雅地“少确认”

权限模式放宽后，效率提升明显，但安全风险也随之上升。完全跳过权限时，AI 能执行任何终端命令，它的“判断能力”不构成安全保证。最安全的折中方案是 hooks 白名单机制：在 PreToolUse 阶段只放行明确允许的命令，其余全部拒绝。

我建议把权限策略分成三档：日常交互保持默认或acceptEdits；处理大规模批量修改用acceptEdits；只有 CI 或无人工值守场景才考虑跳过全部权限。每档对应明确的使用场景，不要混用。团队协作场景下，配置文件的钩子策略最好入库评审，因为这是真正的安全边界。

6.4 认证过期与密钥配置：自动化场景最容易翻车

自动化场景里，认证问题几乎是必踩。原因很简单：CI 环境不稳定、凭证可能过期。典型现象是：流程跑到一半突然跳出需要交互授权的提示，但此时根本没有人去点。或者本地开发环境登录状态过期后，脚本直接报错中断。

解决思路是把认证信息预先配置到环境变量里，让 Claude Code 能直接从环境读取。注意不要硬编码到代码仓库里，而是用 CI 平台的 secrets 机制注入。同时，自动化任务开始前建议先加一步“检查登录状态”的命令，状态不可用时提前失败，避免跑到一半才中断，恢复成本高得多。

7. 我的一点实践经验

玩了这么久的 Claude Code，最大的体会是：它的深度不是靠某一个花哨功能撑起来的，而是靠一堆底层能力组合出来的。CLAUDE.md 给了它记忆，hooks 给了它边界，会话恢复给了它连续性，JSON 输出给了它可编程性。这些能力单独拿出来都只是“不错”，组合在一起，就把一个聊天工具变成了真正能嵌入工作流的基础设施。

如果让我给一个最想分享的小技巧，那就是：花一个下午时间，认真读一遍配置文档、把.claude/目录按自己的需求搭好、配两个顺手的自定义斜杠命令。这一下午的投入，会在之后每次使用里持续放大回报。毕竟，工具的能力边界不取决于它有多少功能，而取决于你愿不愿意往深处多走一步。