企业官网建设流程全解析

CLAUDE.md 是 Claude Code 启动时第一个读的文件。写在里面的东西，Claude 在每一次对话里自动遵守。全局 CLAUDE.md 的精简模板：

## 沟通方式 - 默认中文回复；代码、命令、变量名、文件路径保持英文 - 结论先行，简洁直接，不先铺垫背景 - 不谄媚，不夸"这是个很好的问题"，不以"当然可以"开头 - 给真实判断——方案有问题直接指出，发现更好做法主动说明 ## Git - 不自动 `git commit` 或 `git push`，除非我明确要求 - 提交前先展示将要提交的变更摘要 - commit message 使用简洁英文 ## 红线操作 以下操作即使在 auto-accept 模式下也必须先问我： - 删除文件、目录或 git 历史 - 修改 `.env`、密钥、token、证书、CI/CD 配置 - `git push`、`git rebase`、`git reset --hard`、强制推送 - 公开发布（`npm publish`、生产部署等）

项目级的 CLAUDE.md 再加一层：技术栈、目录结构、commit 格式、禁区（如不要碰 migrations/ 目录）。两个文件叠加，Claude 第一次打开项目就知道——跑测试是pnpm vitest run而不是npm test，数据库操作全在src/lib/services/里。

维护策略：每被 Claude 坑一次，立刻加一条到 CLAUDE.md。过时的规则删掉，内容保持精炼。三个月下来，这个文件就是"这个项目 Claude 犯过的所有错误的预防清单"。最有生产力的一句话是："更新 CLAUDE.md，让这件事不再发生"。

3.6.3 第二个文件：settings.json

用 Claude Code 最烦的就是弹窗。这个文件把"该放行的放行、该锁住的锁住"写死：

{ "permissions": { "allow": [ "Read", "Glob", "Grep", "Edit", "MultiEdit", "Write(src/**)", "Write(tests/**)", "Bash(npm *)", "Bash(pnpm *)", "Bash(git status)", "Bash(git diff *)", "Bash(git log *)", "Bash(git add *)", "Bash(git commit *)", "Bash(cat *)", "Bash(head *)", "Bash(tail *)", "Bash(find *)" ], "deny": [ "Read(**/.env*)", "Read(**/*.pem)", "Read(**/*.key)", "Read(**/secrets/**)", "Read(**/credentials/**)", "Write(**/.env*)", "Write(**/secrets/**)", "Write(package-lock.json)", "Write(.github/workflows/*)", "Bash(rm -rf *)", "Bash(sudo *)", "Bash(git push *)", "Bash(git merge *)", "Bash(git rebase *)", "Bash(docker *)", "Bash(curl * | sh)", "Bash(chmod *)" ], "defaultMode": "acceptEdits" } }

allow 白名单：日常安全操作，不应该每次都问——读文件、写源码、跑测试、git 日常命令。

deny 黑名单：安全红线——读 .env、读密钥、rm -rf、sudo、git push。

配完之后：日常操作零弹窗，危险操作自动封堵。

注意：allow 按你的工具链改——用 yarn 就加Bash(yarn *)，用 bun 就加Bash(bun *)。deny 那几行建议原样留着，它们是安全底线。

3.6.4 第三个文件：.gitignore

除了常规忽略，多加几行保护 AI 工具配置和密钥不被提交到 git：

# AI 工具本地配置 .claude/settings.local.json .cursor/ .aider* .continue/ .cody/ # 密钥和凭证 *.pem *.key credentials.json .npmrc .aws/ .ssh/

注意一个细节：.claude/settings.local.json被 gitignore 了，但.claude/settings.json和.claude/skills/没有。意思是——项目配置团队共享，个人偏好（含 API key）自己留着。

3.6.5 第四个：9 个 Slash Command（Skills）

Skills 把你上线前的心理检查清单变成命令——不用再临时想"还有什么没查"，敲个/，它按你的规矩跑完。每个 Skill 就是一个 Markdown 文件放在.claude/skills/[名字]/SKILL.md。

9 个 Skill 的完整写法见第五部分。这里快速看三个最核心的：

/review— 审代码。不看风格，按严重程度排：

• CRITICAL：逻辑错误、空指针、竞态条件、安全漏洞
• WARNING：N+1 查询、缺少错误处理、性能隐患
• INFO：命名、垃圾代码、TODO
• 输出 checklist，结尾总结 "X critical, Y warnings, Z info"

/commit— 提交代码。自动跑git status和git diff --stat，把改动按逻辑分组，格式遵循type(scope): description。

/deploy-check— 上线前检查。按顺序跑：类型检查 → 测试 → lint → 构建 → 搜console.log→ 检查 .env 引用 → 确认没有未提交的改动。全绿才上线。

另外 6 个：/test、/pr、/debug、/refactor、/docs、/security。套路相同——frontmatter 声明 name、description、allowed-tools，后面写检查步骤。

核心价值：写一次，以后每次都是它替你查。详见第四部分完整教程。

3.6.6 三种安装方式

推荐做法：settings.json 和 skills 放全局，CLAUDE.md 每个项目单独写。权限和命令不用每个项目配一遍，但项目上下文是独立的。

3.6.7 这套配置是活的

模板最大的意义不是"直接用"，是"以此为起点，让它越长越像你的项目"：

• CLAUDE.md 是活的：Claude 每犯一次错就加一条。记住这句话："更新 CLAUDE.md，让这件事不再发生"
• settings.json 跟着项目长大：新工具来了加 allow，发现新的危险操作加 deny
• Skills 长出自己的版本：/review里加你代码库特有的常见问题，/commit里写团队的 scope 命名规范
• .gitignore 持续更新：每用一个新工具，看它会不会在本地生成配置文件

三个月后回头看，最初的模板已经被使用习惯磨成了不同的形状。这个变化本身就是价值——你的项目越来越像你，Claude 也越来越懂你。

3.7 Claude Code 常见问题与排查（FAQ）

3.7.1 安装类问题

Q1：安装时报ENOENT: no such file or directory

• 原因：npm 缓存损坏
• 解决：运行npm cache clean --force，然后重新安装

Q2：安装成功但claude命令找不到

• 原因：npm 全局安装路径未加入系统 PATH
• 解决：运行npm config get prefix，将输出的路径加入系统 PATH 环境变量

Q3：Windows 上报"无法加载文件，因为在此系统上禁止运行脚本"

• 原因：PowerShell 执行策略限制
• 解决：以管理员身份打开 PowerShell，运行Set-ExecutionPolicy RemoteSigned

3.7.2 连接/API 类问题

Q4：启动后提示Invalid API Key

• 原因：API Key 配置错误或过期
• 解决：检查环境变量ANTHROPIC_API_KEY是否正确设置。用echo $ANTHROPIC_API_KEY（macOS）或echo $env:ANTHROPIC_API_KEY（PowerShell）验证

Q5：中转服务配置后连接超时

• 原因：中转服务地址错误或服务不可用
• 解决：1. 检查ANTHROPIC_BASE_URL是否正确 2. 用浏览器访问中转服务网站确认其正常运行 3. 尝试用 curl 直接测试API连通性

Q6：提示Rate limit exceeded

• 原因：短时间内发送了太多请求
• 解决：等待 1 分钟后重试。如果频繁出现，考虑升级 API 套餐

3.7.3 使用类问题

Q7：AI 修改了不该改的文件

• 原因：需求描述不够明确，AI自行判断需要修改
• 解决：1. 用git checkout .撤销修改 2. 重新描述需求，明确指定"只修改 xxx 文件" 3. 在 CLAUDE.md 中注明"不要修改的文件"

Q8：AI 陷入"改A坏B、改B坏A"的循环

• 原因：AI缺乏全局视角，修复一个问题引入新问题
• 解决：1. 用git checkout .回退到稳定版本 2. 用/clear清空对话 3. 重新描述完整的需求，让 AI 一次性考虑所有约束

Q9：对话太长后 AI 开始"遗忘"早期内容

• 原因：上下文窗口接近满载
• 解决：使用/compact压缩上下文，或开新会话

Q10：AI 生成了一个不存在的npm包或API

• 原因：AI "幻觉"（编造不存在的东西）
• 解决：在使用 AI 推荐的包之前，先到 npmjs.com 搜索确认它是否存在

3.8 自定义斜杠命令（Custom Slash Commands）

你可以创建自己的斜杠命令，将常用操作封装成快捷方式。

在项目根目录创建.claude/commands/目录，然后添加 Markdown 文件：

<!-- .claude/commands/deploy.md --> # 部署检查清单 请执行以下部署前检查： 1. 运行所有测试：npm test 2. 检查是否有 lint 错误：npm run lint 3. 确认 .env.example 已更新（如果添加了新的环境变量） 4. 构建项目：npm run build 5. 报告所有检查结果

使用方式：

> /deploy

Claude Code 就会按照你定义的步骤执行部署检查。

3.9 Claude Code 使用模式：Plan Mode 与三种权限模式

初学者常问：“用 Claude Code 是应该先让它规划整个项目再执行，还是自己分模块逐步让它做？”

答案：Claude Code 原生提供了Plan Mode（规划模式）。它不是“一种提示词技巧”，而是官方内置的一个只读运行模式，在该模式下 AI 只能分析不能修改，有专门的快捷键与命令可随时切入。

3.9.1 三种运行模式（官方）

Claude Code 内置三种互斥的运行模式：

3.9.2 Plan Mode 能做什么、不能做什么

在 Plan Mode 下，AI 只能调用这些只读工具：

严格禁止：写入文件、修改文件、运行 shell 命令、运行测试、任何改动项目的动作。这保证你在看到 AI 计划之前，它不会动你项目中的任何一行代码。

提示：Plan Mode 的重点是先探索和规划，暂不修改文件。不同版本可能会用不同的内部检索或子任务机制来辅助调研，不建议把某个内部实现细节当成稳定接口来记。

3.9.3 四种进入 Plan Mode 的方式（重点！）

进入 Plan Mode 的 4 种方式

① 快捷键：Shift+Tab ×2
（Windows 某些终端用 Alt+M）

② 斜杠命令：/plan
（Claude Code v2.1.0+）

③ 启动参数：claude --permission-mode plan

④ 默认配置：.claude/settings.json
permissions.defaultMode = 'plan'

图：进入 Plan Mode 的四种方式，从临时到永久

方式一：键盘快捷键 Shift+Tab（最常用）

在 Claude Code 会话中连按两次Shift + Tab：

第一次 Shift+Tab → 切到 Auto-Accept Mode（状态栏： accept edits on） 第二次 Shift+Tab → 切到 Plan Mode （状态栏： plan mode on） 第三次 Shift+Tab → 切回 Normal Mode

注意：Windows 用户注意：某些 Windows 终端（如部分 PowerShell 配置）上Shift+Tab只能在 Normal/Auto-Accept 间切换，跳过了 Plan Mode。请改用Alt + M切入 Plan Mode；该问题在官方 Issue 中已标记为已知问题。

方式二：会话中输入/plan命令（v2.1.0+）

Claude Code v2.1.0 之后支持直接在提示符中输入斜杠命令：

> /plan

会话会立即切入 Plan Mode。特别适合“继续聊到一半发现需要规划”的场景。

方式三：启动时直接进 Plan Mode

如果你明确知道本次是复杂任务，可以从启动就进入 Plan Mode：

# 交互式 claude --permission-mode plan # 无头模式（可用于 CI / 脚本） claude --permission-mode plan -p "分析认证模块并提出优化建议"

方式四：设为项目默认模式

如果某个项目你一直希望默认“先规划后执行”，可以在项目根的.claude/settings.json中配置：

{ "permissions": { "defaultMode": "plan" } }

以后只要在该项目目录下运行claude，就会默认进 Plan Mode。

3.9.4 推荐的完整工作流

推荐的使用顺序：