装好 Claude Code 的第一件事，大多数人直接就开始用了。

我也是。然后我用了三周，一直觉得"还行，但感觉差点什么"——响应有时候莫名其妙跑偏，上下文动不动就失控，同一类需求每次描述方式不一样结果就不一样。

后来我花了整整一个月，系统性地把所有配置项翻了一遍，做了大量对比测试。

这篇文章是结果。不是官方文档的翻译，是我真正在用的那套配置，以及每个配置背后"为什么这样设"的判断逻辑。

为什么配置比你想象的重要得多

先说一个很多人没意识到的事：Claude Code 的默认配置，是为"通用用户"设计的，不是为你设计的。

如果你是做出海 Web 开发的，你的场景有很强的特殊性——多语言、Stripe 支付、UTC 时区、Next.js 技术栈……这些背景信息如果每次都靠你在对话里手动补充，不仅效率低，而且容易忘，一忘 Claude Code 就开始给你生成"通用版"代码。

好的配置，是让 Claude Code 在开口之前就已经了解你。

一、CLAUDE.md：最被低估的配置文件

这是整套配置里投入产出比最高的一项，但我见过很多人根本不知道它的存在。

CLAUDE.md 是放在项目根目录的一个 Markdown 文件。Claude Code 每次启动时会自动读取它，把里面的内容当作项目级的"系统提示词"。

说人话就是：你在这里写的一切，Claude Code 都会默默记住，不需要你每次对话都重复交代。

我的 CLAUDE.md 模板

下面是我在出海项目里实际使用的模板，直接复制后按你的项目修改：

# 项目背景

这是一个面向全球用户的 SaaS 产品，主要市场为北美和欧洲。
技术栈：Next.js 14 (App Router) + TypeScript + Prisma + PostgreSQL + Tailwind CSS
支付：Stripe（订阅制 + 一次性付款）
部署：Vercel + Railway

# 开发规范

## 代码风格
- 所有注释和变量命名使用英文
- 组件使用函数式写法，不用 class 组件
- 优先使用 async/await，不用 .then() 链式调用
- 类型定义放在 types/ 目录，不内联在组件里

## 出海特殊要求
- 所有时间存储和计算使用 UTC，展示层再转本地时区
- 涉及金额的变量必须用整数（分为单位），不用浮点数
- 文案字符串全部走 i18n，不硬编码中文或英文
- 用户数据处理需符合 GDPR，敏感操作需有审计日志

## 数据库规范
- 表名使用 snake_case
- 每张表必须有 created_at 和 updated_at 字段
- 软删除使用 deleted_at 字段，不物理删除用户数据

# 常用命令

- 本地开发：`npm run dev`
- 数据库迁移：`npx prisma migrate dev`
- 类型生成：`npx prisma generate`
- 部署：`git push origin main`（自动触发 Vercel CI）

# 注意事项

- Stripe Webhook 的签名验证不能跳过，即使是测试环境
- 不要在客户端组件里直接调用数据库，必须走 API Route 或 Server Action
- 环境变量命名：客户端可用的加 NEXT_PUBLIC_ 前缀，其他不加

这个文件建好之后，你会发现 Claude Code 给的代码质量有明显提升——因为它知道你在用 App Router，就不会给你生成 Pages Router 的写法；它知道金额要用整数，就不会给你写出浮点数的 Bug。

一个大多数教程没提到的细节：CLAUDE.md 支持嵌套。你可以在子目录里再放一个 CLAUDE.md，专门描述那个模块的特殊规则。比如我在 app/api/webhooks/ 目录下放了一个单独的，专门写 Webhook 处理的安全规范，Claude Code 在那个目录里工作时会叠加读取。

二、模型选择：别默认用 Opus

这个问题我测试过，结论很明确，但和很多人的直觉相反：

日常编码任务，Sonnet 比 Opus 更适合。

不是因为 Sonnet 更强，而是因为 Opus 在编码任务上有一个明显的问题：它想太多。

给它一个明确的需求，它会开始考虑各种边界情况、提出你没问的架构问题、给你三个方案让你选。这在做技术决策的时候很有价值，但在你只是想快速实现一个功能的时候，它是在浪费你的时间和 Token。

Sonnet 的策略是：你说什么，我做什么，做完告诉你。干净利落。

我现在的配置是：

• 日常功能开发、Debug、写测试：Sonnet

• 系统架构设计、技术选型讨论、复杂业务逻辑拆解：Opus

• 快速生成样板代码、写注释、改格式：Haiku

这样分配之后，我的月账单下降了大约 40%，同时产出效率没有下降。

三、上下文管理：最容易被忽视的效率杀手

用 Claude Code 久了，你一定遇到过这个问题：聊到后面，它开始"记错事"——明明前面说过用 TypeScript，它给你生成了 JavaScript；明明确认过用 App Router，它给你写了 getServerSideProps。

这不是 Bug，这是上下文窗口满了之后的正常退化。

我的上下文管理策略

策略一：任务拆小，不要一次塞太多

一个常见的错误是把整个功能需求一次性扔给 Claude Code："帮我实现用户注册、登录、OAuth、忘记密码、邮件验证这一套"。

这样做表面上省事，实际上它会在后半段开始出问题，因为上下文被前面的对话占满了，后面的需求处理质量会明显下降。

更好的做法是拆开：先做注册，验收通过，开新对话做登录，以此类推。每个对话聚焦一个功能点。

策略二：用"摘要接力"保留关键上下文

当一个对话快到上下文上限时，在开新对话之前，让 Claude Code 做一个摘要：

请用200字以内总结我们这个对话里确定的所有技术决策和已完成的实现细节，我会把这段摘要带到下一个对话继续。

然后把它生成的摘要贴到新对话的开头。这个习惯养成之后，上下文丢失的问题基本消失了。

策略三：敏感配置单独声明

每次涉及 Stripe、数据库、第三方 API 的对话，我都会在开头加一行：

当前项目使用 Stripe，金额单位为分（整数），所有涉及支付的代码必须做幂等性处理。

不要假设它从 CLAUDE.md 里记住了这些——在关键任务开始前主动声明，是防止出错的保险。

四、Permission 设置：哪些操作让它自动做，哪些必须你确认

Claude Code 在执行某些操作时会询问你是否允许，这个机制本身很好，但默认配置太保守，会频繁打断你的节奏。

我花了一周调整出了这套权限策略：

设置为"总是允许"（不每次询问）：

• 读取任何文件

• 在项目目录内创建新文件

• 运行 npm run 类的脚本命令

• 运行 git status / git diff / git log（只读操作）

设置为"每次确认"（保持询问）：

• 删除文件

• git commit / git push

• 运行数据库迁移命令

• 安装新的 npm 包

设置为"总是拒绝"：

• 访问项目目录之外的文件系统

• 发起网络请求（除非我明确要求）

这个配置的逻辑是：读和创建是低风险的，删和推送是不可逆的。低风险操作自动执行提高效率，高风险操作保留人工确认保证安全。

五、出海项目专项配置

这部分是我花时间最多的地方，也是和国内项目差异最大的地方。

Stripe 相关

在 CLAUDE.md 里加上这段，能避免大量低级错误：

# Stripe 规范
- 金额统一用最小货币单位（USD 用分，JPY 直接用整数日元）
- 所有 Stripe API 调用必须有错误处理，不能裸调用
- Webhook 处理必须先验证签名，再处理事件
- 退款、取消订阅等操作需要在数据库里记录操作日志
- 测试环境用 stripe.com/docs/testing 里的测试卡号，不用真实卡

多语言相关

# i18n 规范
- 使用 next-intl，locale 文件放在 messages/ 目录
- 新增文案必须同时在 en.json 和 zh.json 里添加（哪怕中文是占位符）
- 日期格式使用 Intl.DateTimeFormat，不硬编码格式字符串
- RTL 语言（阿拉伯语、希伯来语）的布局需要用 logical properties

GDPR 相关

# 隐私合规
- 用户数据的采集必须有明确的法律依据（同意/合同/合法利益）
- 删除账号操作必须真正删除或匿名化个人数据
- 日志里不能出现用户的真实邮箱、姓名、IP（需要脱敏）
- Cookie 分类：必要 Cookie 不需同意，分析/营销 Cookie 需要明确同意

踩坑环节

坑一：CLAUDE.md 写太长，反而变差

我第一版 CLAUDE.md 写了将近 800 字，把所有能想到的规范都塞进去了。

结果发现 Claude Code 开始"选择性遗忘"——它不是不读，而是上下文里规则太多，优先级模糊，遇到冲突时它自己选了一个，不一定是我想要的那个。

后来我把它精简到 300 字以内，只保留最核心的、不说就一定会出错的规则。次要规则移到了子目录的 CLAUDE.md 里。精简之后，遵守率明显提升。

教训：CLAUDE.md 不是越全越好，是越精准越好。

坑二：以为配置一次就永久生效

折腾了一晚上配置，第二天打开发现有些设置没了。

研究了一下才发现，部分配置是会话级的，不是持久化的。Claude Code 本身的配置（模型选择、权限设置）在每次安装更新后可能会重置，需要重新确认。

我现在的做法是把关键配置截图存档，每次大版本更新后对照检查一遍。麻烦但值得。

我的完整配置清单（可直接对照检查）

✅ CLAUDE.md 已创建，字数控制在 300 字以内
✅ 日常任务默认使用 Sonnet，架构讨论切换 Opus  
✅ Permission 已按"读写分级"原则配置
✅ 上下文管理：任务拆小 + 摘要接力
✅ 出海专项：Stripe规范 + i18n规范 + GDPR规范已写入 CLAUDE.md
✅ 子目录 CLAUDE.md 已为高风险模块单独配置
✅ 配置截图存档，更新后对照检查

配置的本质，是把你的判断固化成规则，让 Claude Code 不需要猜你的意图。

猜对了是运气，猜错了是返工。花两小时做好配置，省的是之后每天的反复纠偏。

---

你现在的 Claude Code 项目，有没有 CLAUDE.md？如果有，你在里面写的最有效的一条规则是什么？