1. 模型选择：为什么 Opus 4 是唯一答案

如果你真的想把 Claude Code 当作一个严肃的编程伙伴，而不是一个偶尔问问题的玩具，那么模型选择就是你绕不开的第一个、也是最重要的决定。我见过不少朋友为了省点预算，退而求其次选择了 Sonnet 或者 Haiku，结果就是编程体验大打折扣，最后要么是项目进度受阻，要么是带着一肚子火气回来升级到 Opus。这中间的折腾，浪费的时间和精力，早就超过了那点差价。

为什么我敢说 Opus 4 是唯一答案？这得从 AI 编程的核心需求说起。我们让 AI 写代码，要的不是它能“跑通”，而是要它能“写好”。Sonnet 和 Haiku 在处理简单、模式化的任务时，比如生成一个基础的 CRUD 接口，确实能完成任务。但一旦你进入复杂逻辑、需要深度理解项目架构、或者处理一些“模糊”需求时，它们的短板就暴露无遗。Opus 4 的“聪明”体现在它能真正理解你的意图，而不是机械地匹配关键词。举个例子，有一次我需要重构一个复杂的异步数据处理流水线，我告诉 Opus 4：“这个模块的耦合度太高了，我想引入一个中间件模式来解耦，同时保持错误处理的健壮性。” 它不仅能给出重构后的代码，还会在注释里详细解释为什么选择这种设计模式，每个中间件的职责是什么，以及如何优雅地处理各个阶段的异常。而用 Sonnet 试过同样的指令，它给出的方案更像是把旧代码打散重排，缺乏那种对问题本质的洞察力。

这种理解力的差距，直接决定了你的开发效率。用 Opus 4，你感觉是在和一个经验丰富的架构师结对编程，它能预判你的下一步，能指出你设计中的潜在风险。而用次级模型，你更像是在给一个刚入行的程序员下达非常具体的指令，一旦指令不够精确，结果就可能跑偏，你需要花更多的时间去 review 和修正。对于追求极致体验的我们来说，这种心智负担是完全不能接受的。预算紧张？我的建议是，宁可减少使用频率，把 Token 用在刀刃上，也绝不在模型质量上妥协。一次高质量、直达目标的对话，其价值远胜于十次来回拉扯的低效沟通。

1.1 超越“能用”：Opus 4 的推理深度与代码质量

很多人对模型的理解停留在“生成文本”的层面，但对于编程，尤其是 Claude Code 所倡导的“思考-规划-执行”模式，模型的推理深度才是关键。Opus 4 的 ultrathink 能力不是营销噱头，而是实打实的工作模式切换。当你开启 plan mode 并附上 please keep ultrathink! 的指令时，你能明显感觉到 Claude 的“思考节奏”变了。

它不是急于给你抛出一段代码，而是会先拆解问题，列出可能的技术方案，评估各自的优劣，甚至主动询问一些它认为模糊的边界条件。我最近在开发一个需要与多个第三方 API 集成的服务时，深有体会。我给了它一个大致的需求，它没有直接开始写 HTTP 客户端，而是先反问我：“我们需要考虑这几个 API 的速率限制策略分别是什么？它们的错误响应格式是否统一？服务是否需要具备降级熔断机制？” 这些问题恰恰是我在初期规划时忽略的细节。这种主动的、结构化的思考，极大地弥补了人类开发者可能存在的思维盲区。

在代码质量上，Opus 4 的表现也更像是一个有洁癖的资深工程师。它生成的代码，命名规范、结构清晰、异常处理完备。更重要的是，它具有很强的“上下文一致性”。比如，当你在项目中已经定义了一套自己的工具函数库或设计模式后，Opus 4 在后续的代码生成中会主动复用和遵循这些约定。而次级模型可能会“忘记”之前的约定，生成风格迥异的代码，导致项目中出现“精神分裂”的代码库。维护一个风格统一、逻辑自洽的代码库，其长期价值是无法用 Token 单价来衡量的。因此，选择 Opus 4，本质上是在为你未来的代码可维护性和团队协作效率投资。

2. 文档驱动开发：让 CLAUDE.md 成为项目大脑

如果说 Opus 4 是强大引擎，那么 CLAUDE.md 就是你为这具引擎精心绘制的高清地图。没有地图，再强的引擎也可能在项目迷宫里兜圈子。我最初也犯过错误，以为把所有需求文档、API 说明一股脑塞进一个巨大的 CLAUDE.md 文件就行了，结果就是 Claude 的反应开始变慢，有时甚至会抓不到重点。后来我才明白，CLAUDE.md 的核心价值不是“存储”，而是“索引”和“连接”。

它的最佳实践是作为一个轻量的中央导航文件。它的内容应该精炼，主要作用是告诉 Claude：“关于这个项目，你需要知道的核心信息在这里，更详细的内容请去查阅以下链接。” 这通过 @path/to/file 语法来实现。比如，你的项目根目录下的 CLAUDE.md 可能长这样：

# 项目核心上下文

本项目是一个基于 Next.js 14 的电商后台管理系统。

## 快速入口
- 查看项目整体目标和功能范围：@README.md
- 了解技术栈和启动命令：@package.json
- 数据库 Schema 定义：@prisma/schema.prisma

## 开发规范
- **代码风格**：严格遵循本项目中的 ESLint 配置和 Prettier 规则。
- **API 设计**：所有 RESTful 端点必须遵循 `@docs/api-conventions.md` 中的约定。
- **状态管理**：全局状态使用 Zustand，模块内状态使用 React hooks，详见 `@docs/state-management.md`。

## 当前重点任务
我们正在重构用户订单模块，目标是解耦支付处理和物流跟踪。相关详细需求见 `@features/order-refactor/SPEC.md`。

这样的结构清晰明了。Claude 在分析任务时，会首先读取这个导航文件，然后根据需要去“查阅”被引用的详细文档。这模拟了人类开发者接手新项目时的学习过程：先看总览，再深入细节。这种方法极大地减轻了单次对话的上下文负担，让 Claude 能把有限的“注意力”集中在当前要解决的具体问题上。

2.1 构建你的文档体系：从全局配置到模块化

文档驱动不能只停留在项目层面。一个高效的 Claude Code 使用者，会建立两层文档体系：全局级和项目级。

全局级 (~/.claude/CLAUDE.md): 这是你的个人开发偏好和通用知识的沉淀池。这里的内容必须“少而精”，每一条都应该是经过千锤百炼、对你至关重要的指令。我的全局配置大概是这样：

# 全局开发偏好

- **语言**：所有对话和生成的代码注释请使用中文。
- **思考模式**：在开始任何实质性编码前，请务必进行深入思考（ultrathink）。分析需求，权衡方案，并给出简要计划。
- **代码生成风格**：
  - 优先使用 async/await，避免回调地狱。
  - 错误处理要具体，不能简单 `console.log` 或 `throw Error`，必须包含可追溯的上下文信息。
  - 生成的函数和方法必须包含 JSDoc 类型注释。
- **文档生成要求**：为我创建的任何技术文档，请杜绝任何形容词和自夸性语言。只需清晰、直接、完整地描述事实、逻辑和实现细节，必要时附上代码示例。

这个文件像是我和 Claude 之间的“合作章程”，确保无论我在哪个项目里，它都能以我熟悉和期待的方式与我协作。

项目级 (/project-root/CLAUDE.md): 如前所述，这是项目导航文件。但更高级的用法是配合一个 docs/ 目录，实现文档的模块化管理。例如：

• docs/api-conventions.md: 定义所有 API 的响应格式、错误码、认证方式。
• docs/db-transaction-guide.md: 说明复杂业务中如何使用数据库事务。
• docs/deployment-checklist.md: 上线前需要检查的事项。

当你在对话中，想让 Claude 依据某个规范工作时，只需在 CLAUDE.md 中引用它。比如你正在开发一个新 API，你可以说：“请按照 @docs/api-conventions.md 的规范，创建用户注册的端点。” Claude 会自动去查阅那份文档，并确保生成的代码符合要求。这种工作流将你的项目知识体系化了，也让 Claude 变成了一个真正理解你项目规则的“内部开发者”。

3. 主动内存管理：驯服上下文这头“巨兽”

Claude Code 最迷人的地方，也是它最容易失控的地方，就是那个不断增长的对话上下文。每一次问答、每一段生成的代码，都会成为历史，挤占着宝贵的上下文窗口。很多人会有一种“囤积癖”，觉得辛辛苦苦讨论出来的东西，用 /compact 压缩掉太可惜了。这种心态我完全理解，但我们必须克服它，因为这是保持对话“健康”的关键。

你可以把对话上下文想象成你的电脑内存。打开无数个网页和软件不关，电脑就会变卡，甚至崩溃。Claude 也一样，当上下文里塞满了过时的讨论、失败的尝试、已经被重构掉的代码片段时，它的“思考”就会受到干扰。它可能会引用一个早已被修改的函数，或者纠结于一个已经否决的方案。/compact 命令，就是你主动进行“内存清理”和“碎片整理”的过程。

这个命令不是简单的删除，而是智能摘要。Claude 会回顾之前的对话，提取出最重要的决策、达成的共识、以及当前的项目状态，然后用一段高度凝练的文字来代表之前可能长达几十轮的讨论。例如，一段关于“如何选择前端图表库”的冗长争论，可能被压缩成：“【已确认】决定使用 Recharts 而非 Chart.js，因其与 React 集成度更高且类型支持完善。已在本项目 package.json 中安装。”

3.1 /compact 的最佳使用时机与心理建设

那么，什么时候该使用 /compact 呢？我的经验法则是：在完成一个相对独立的开发阶段或解决一个核心问题之后。比如，你们刚刚一起设计并实现了一个完整的用户认证模块，从数据库表设计到 API 路由，再到前端登录组件。在开始下一个模块（比如商品管理）之前，果断地输入 /compact。这相当于给对话画上一个清晰的章节符，告诉 Claude：“之前关于认证的讨论已经闭环，现在我们进入下一章。”

使用它需要一点“心理脱敏练习”。你得告诉自己，被压缩掉的不是“宝贵资料”，而是“过程草稿”。所有真正有价值的产出——最终确定的代码、写入 CLAUDE.md 的规范、存入 docs/ 目录的设计文档——都已经沉淀到项目文件里了。对话历史里的，只是达到这些产出的“思考路径”。这条路径本身并不需要永久保存，只要关键结论被记住了就行。

一个更激进但也更高效的做法是：勇于开启新对话。对于全新的、关联性不强的功能需求，直接开一个新对话窗口，并利用 CLAUDE.md 和项目现有代码为 Claude 提供上下文。这样，它从一开始就能在一个“干净”的环境里聚焦新问题。很多人舍不得旧对话，是因为里面有一些零散的上下文。但只要你把项目结构化和文档化做好了（也就是第二节做的事），Claude 在新对话中重新“上手”的速度会快得超乎你想象。这种“随时重启”的勇气，是保持长期高效协作的秘诀。

4. 实战工作流：从思考到交付的无缝衔接

掌握了模型、文档和内存管理这三板斧，我们来看看如何把它们串成一个流畅的日常开发工作流。这个工作流的核心是 “思考 -> 规划 -> 执行 -> 沉淀” 的循环。

假设我现在要为一个数据分析平台添加一个“数据导出为PDF报告”的功能。我不会直接说：“Claude，给我写个导出PDF的代码。” 那样太粗糙了。我的对话会是这样开始的：

第一步：激活深度思考 “我们需要为平台添加一个将图表和数据表格导出为 PDF 报告的功能。请先进行深入思考（ultrathink），我们需要考虑哪些方面？比如前端触发方式、后端生成 PDF 的技术选型（是服务端生成还是客户端生成？）、数据如何传递、样式如何保证、以及性能影响。”

这时，Claude Opus 4 会在 plan mode 下工作，给我列出一个思考清单：

1. 技术选型评估：对比服务端生成（如 Node.js 的 Puppeteer）与客户端生成（如 jsPDF + html2canvas）的优劣。考虑到我们的图表是动态的且需要保持高保真，建议采用服务端无头浏览器方案。
2. API设计：设计一个异步任务端点。用户发起请求，后端生成任务队列，完成后通过 WebSocket 或轮询通知前端下载。
3. 样式与布局：需要一套独立的 PDF 模板系统，可能与现有前端样式分离。
4. 性能与缓存：相同的报告参数应考虑缓存生成的 PDF 文件，避免重复渲染。

第二步：基于规划，细化并执行 看到这个规划，我很满意。我会说：“很好，我们采用服务端 Puppeteer 方案。请先参考我们项目中 @docs/api-conventions.md 的规范，设计这个导出任务相关的 RESTful API 端点（包括发起、查询状态、下载）。然后，请创建对应的后端服务层代码。”

在这个过程中，我会不断把讨论中确定的、具有长期价值的内容，即时沉淀到文档中。比如，当 API 设计确定后，我可能会让 Claude 直接帮我生成一份 docs/pdf-export-api.md 文档，然后更新根目录的 CLAUDE.md，在“API 设计”部分加上对新文档的引用。

第三步：阶段清理与迭代 当 PDF 导出功能的后端核心逻辑和 API 都实现完毕，准备开始写前端调用逻辑前，我会毫不犹豫地输入 /compact。把之前关于技术选型辩论、API 细节讨论的历史压缩成几句话。然后在一个清爽的上下文中，开始前端部分的工作：“现在，请基于我们刚刚确定的 API（详情见 @docs/pdf-export-api.md），在 React 组件中实现发起导出、轮询状态和下载文件的功能。”

这个工作流之所以高效，是因为它让每个环节都各司其职：ultrathink 负责深度谋划，避免方向错误；CLAUDE.md 和项目文档负责持久化知识，提供稳定上下文；/compact 负责清理工作现场，保持思维聚焦。如此循环，你能感觉到 Claude 不是一个一问一答的机器，而是一个真正融入你项目开发节奏的智能体。它记得住规矩（靠文档），跟得上思路（靠清理后的上下文），并且总能给出在点子上的建议（靠顶级模型）。这才是 Claude Code 所能带来的、极致的编程体验。