我如何使用 Claude Code

28 Mar, 2026

我如何使用 Claude Code

原文：How I Use Claude Code
作者：Boris Tane

我已经使用 Claude Code 作为主要开发工具大约 9 个月了，我形成的工作流程与大多数人使用 AI 编码工具的方式截然不同。大多数开发者输入一个提示，有时使用计划模式，修复错误，然后重复这个过程。那些更"重度在线"的人则在拼凑 ralph loops、MCPs、gas towns（还记得那些吗？）等等。这两种情况的结果都是一团糟，对于任何非琐碎的任务都会彻底崩溃。

我要描述的工作流程有一个核心原则：在 Claude 编写代码之前，绝不让它动手，直到你审查并批准了书面计划。这种计划与执行的分离是我做的最重要的事情。它能防止浪费精力，让我掌控架构决策，并以最少的 token 使用量产生比直接跳到代码阶段更好的结果。

流程图：
研究(Research) → 计划(Plan) → 批注(Annotate) → [重复 1-6 次] → 任务清单(Todo List) → 实现(Implement) → 反馈与迭代(Feedback & Iterate)

第一阶段：研究

每个有意义的任务都从一个深度阅读指令开始。我让 Claude 在采取任何行动之前彻底理解代码库的相关部分。我总是要求将研究结果写入持久的 markdown 文件，而不是仅在聊天中口头总结。

示例提示：

深度阅读这个文件夹，深入理解它是如何工作的、它做什么以及所有的具体细节。完成后，在 research.md 中写下你的学习发现和详细报告。

详细研究通知系统，理解它的所有复杂细节，并写一个详细的 research.md 文档，包含关于通知系统工作原理的一切。

仔细研究任务调度流程，深入理解它并寻找潜在的 bug。系统中肯定存在 bug，因为它有时会运行本该被取消的任务。继续研究流程直到找到所有 bug，在找到所有 bug 之前不要停止。完成后，在 research.md 中写下你的发现详细报告。

注意语言："深入地"、"详细研究"、"复杂细节"、"仔细研究一切"。这不是废话。没有这些词，Claude 会略读。它会读一个文件，在签名层面看看函数做什么，然后继续。你需要传达表面阅读是不可接受的。

书面成果（research.md）至关重要。这不是让 Claude 做作业。这是我的审查界面。我可以阅读它，验证 Claude 是否真的理解了系统，并在任何计划发生之前纠正误解。如果研究是错误的，计划就会错误，实现也会错误。垃圾进，垃圾出。

这是 AI 辅助编码中最昂贵的失败模式，它不是错误的语法或糟糕的逻辑。而是那些在孤立环境中工作但会破坏周围系统的实现。一个忽略现有缓存层的函数。一个没有考虑 ORM 约定的迁移。一个重复了其他地方已存在逻辑的 API 端点。研究阶段可以防止所有这些。

第二阶段：计划

一旦我审查了研究，我就会要求在一个单独的 markdown 文件中提供详细的实现计划。

示例提示：

我想构建一个名为 <名称和描述> 的新功能，扩展系统以实现 <业务成果>。写一个详细的 plan.md 文档，概述如何实现这一点。包含代码片段。

列表端点应该支持基于游标的分页而不是偏移量。写一个详细的 plan.md 说明如何实现这一点。在提出更改之前先阅读源文件，基于实际代码库制定计划。

生成的计划总是包括方法的详细解释、显示实际更改的代码片段、将要修改的文件路径，以及考虑和权衡。

我使用自己的 .md 计划文件，而不是 Claude Code 内置的计划模式。内置的计划模式很糟糕。我的 markdown 文件给我完全的控制权。我可以在编辑器中编辑它，添加内联注释，它作为项目中的真实成果持久存在。

我经常使用的一个技巧： 对于在开源仓库中看到过良好实现的、范围明确的功能，我会分享该代码作为参考，同时提出计划请求。如果我想添加可排序 ID，我会粘贴一个做得很好的项目的 ID 生成代码，然后说"这是他们实现可排序 ID 的方式，写一个 plan.md 解释我们如何采用类似的方法。"当 Claude 有具体的参考实现可以借鉴，而不是从零设计时，它的工作效果会显著提高。

但计划文档本身并不是有趣的部分。有趣的部分是接下来发生的事情。

批注循环

这是我工作流程中最独特的部分，也是我贡献最多价值的部分。

流程图：
Claude 编写 plan.md → 我在编辑器中审查 → 我添加内联注释 → 发送 Claude 回到文档 → Claude 更新计划 → 满意吗？
                                                              ↓ 否
                                                              返回审查
                                                              ↓ 是
                                                        请求任务清单

Claude 写完计划后，我在编辑器中打开它，直接在文档中添加内联注释。这些注释纠正假设、拒绝方法、添加约束，或提供 Claude 没有的领域知识。

注释的长度差异很大。有时注释只有两个字：在 Claude 标记为可选的参数旁边写"不是可选的"。其他时候是一段解释业务约束的文字，或粘贴一个代码片段显示我期望的数据形状。

我会添加的一些真实注释示例：

• "使用 drizzle:generate 进行迁移，不要用原始 SQL" —— Claude 没有的领域知识
• "不对 —— 这应该是 PATCH，不是 PUT" —— 纠正错误的假设
• "完全删除这一部分，我们这里不需要缓存" —— 拒绝提议的方法
• "队列消费者已经处理了重试，所以这个重试逻辑是多余的。删除它，让它失败就好" —— 解释为什么应该改变
• "这是错的，visibility 字段需要在列表本身上，而不是在单个项目上。当列表是公开的时，所有项目都是公开的。相应地重构 schema 部分" —— 重定向计划的整个部分

然后我让 Claude 回到文档：

我在文档中添加了一些注释，处理所有注释并相应地更新文档。先不要实现。

这个循环重复 1 到 6 次。 明确的 "先不要实现" 守卫至关重要。没有它，Claude 会在它认为计划足够好的时候跳到代码阶段。直到我说它足够好之前，它都不够好。

为什么这很有效

markdown 文件充当我和 Claude 之间的共享可变状态。我可以按自己的节奏思考，精确地注释哪里错了，然后重新参与而不会丢失上下文。我不是试图在聊天消息中解释一切。我指向文档中确切的问题位置，就在那里写下我的更正。

这与试图通过聊天消息引导实现根本不同。计划是一个结构化的、完整的规范，我可以整体审查。聊天对话是我必须滚动浏览才能重建决策的东西。计划每次都赢。

三轮"我添加了注释，更新计划"可以将一个通用的实现计划转化为一个完美适合现有系统的计划。Claude 在理解代码、提出解决方案和编写实现方面非常出色。但它不知道我的产品优先级、我的用户痛点，或我愿意做出的工程权衡。批注循环就是我注入这些判断的方式。

任务清单

在开始实现之前，我总是要求一个细粒度的任务分解：

在计划中添加一个详细的任务清单，包含完成计划所需的所有阶段和单个任务 —— 先不要实现。

这创建了一个在实现期间作为进度跟踪器的检查清单。Claude 在完成时标记项目为已完成，所以我可以随时查看计划并准确了解事情进展。在运行数小时的会话中特别有价值。

第三阶段：实现

当计划准备好后，我发出实现命令。我已经将其提炼为一个在会话中重复使用的标准提示：

全部实现。完成一个任务或阶段后，在计划文档中将其标记为已完成。在完成所有任务和阶段之前不要停止。不要添加不必要的注释或 JSDoc，不要使用 any 或 unknown 类型。持续运行类型检查以确保你没有引入新问题。

这个单一提示编码了所有重要的东西：

• "全部实现"：做计划中的所有事情，不要挑挑拣拣
• "在计划文档中将其标记为已完成"：计划是进度的真实来源
• "在完成所有任务和阶段之前不要停止"：不要在中间流程暂停等待确认
• "不要添加不必要的注释或 JSDoc"：保持代码整洁
• "不要使用 any 或 unknown 类型"：保持严格类型
• "持续运行类型检查"：尽早发现问题，而不是在最后

我在几乎每个实现会话中都使用这个确切的措辞（有轻微变化）。到我说的"全部实现"时，每个决策都已经做出并验证。实现变得机械化，而不是创造性的。这是故意的。我希望实现是无聊的。创造性的工作发生在批注循环中。一旦计划正确，执行应该很简单。

没有计划阶段，通常会发生的情况是 Claude 早期做了一个合理但错误的假设，在其上构建 15 分钟，然后我必须解开一连串的更改。"先不要实现"守卫完全消除了这一点。

实现期间的反馈

一旦 Claude 在执行计划，我的角色就从架构师转变为监督者。我的提示变得简短得多。

流程图：
Claude 实现 → 我审查/测试 → 正确吗？
                    ↓ 否
                简洁的更正 → 回到实现
                    ↓ 是
                还有更多任务吗？
                    ↓ 是    ↓ 否
                继续实现   完成

一个计划注释可能是一段话，而一个实现更正通常只有一句话：

• "你没有实现 deduplicateByTitle 函数。"
• "你把设置页面建在主应用中，但应该在管理应用中，移动它。"

Claude 拥有计划的完整上下文和正在进行的会话，所以简洁的更正就足够了。

前端工作是最迭代的部分。我在浏览器中测试并快速发出更正：

• "更宽一点"
• "还是被裁剪了"
• "有 2px 的间隙"

对于视觉问题，我有时会附加截图。一张未对齐表格的截图比描述问题更快。

我也经常引用现有代码：

• "这个表格应该看起来完全像用户表格，相同的表头、相同的分页、相同的行密度。"

这比从零描述设计要精确得多。成熟代码库中的大多数功能都是现有模式的变化。一个新的设置页面应该看起来像现有的设置页面。指向参考传达了所有隐式需求，而无需一一说明。Claude 通常会在进行更正之前阅读参考文件。

当事情走向错误方向时，我不会尝试修补它。我通过丢弃 git 更改来恢复和重新确定范围：

• "我恢复了一切。现在我想要的只是让列表视图更简洁 —— 别的都不要。"

在恢复后缩小范围几乎总是比尝试逐步修复糟糕的方法产生更好的结果。

保持主导权

即使我把执行委托给 Claude，我也从不给它完全自主决定构建什么的权力。我在 plan.md 文档中完成绝大多数主动引导。

这很重要，因为 Claude 有时会提出技术上正确但对项目来说是错误的解决方案。也许方法过于工程化，或者它改变了系统其他部分依赖的公共 API 签名，或者它选择了更复杂的选项而简单的选项就足够了。我拥有关于更广泛系统、产品方向和工程文化的上下文，这些是 Claude 没有的。

流程图：
Claude 提议更改 → 我评估每个项目
                        ↓
            按原样接受 / 修改方法 / 跳过/删除 / 覆盖技术选择
                        ↓
                细化的实现范围

从提议中挑选： 当 Claude 识别多个问题时，我逐一检查："对于第一个，就用 Promise.all，不要搞得太复杂；对于第三个，提取成一个单独的函数以提高可读性；忽略第四和第五个，它们不值得这么复杂。" 我基于对当前重要事项的了解做出项目级决策。

削减范围： 当计划包含锦上添花的功能时，我会主动削减它们。"从计划中删除下载功能，我现在不想实现这个。" 这防止了范围蔓延。

保护现有接口： 当我知道某些东西不应该改变时，我会设置硬性约束："这三个函数的签名不应该改变，调用者应该适应，而不是库。"

覆盖技术选择： 有时我有 Claude 不会知道的特定偏好："用这个模型而不是那个" 或 "用这个库的内置方法而不是写自定义的"。快速、直接的覆盖。

Claude 处理机械执行，而我做出判断性决策。计划预先捕捉大决策，选择性指导处理实现过程中出现的小决策。

单一长会话

我在单一长会话中运行研究、计划和实现，而不是将它们拆分到不同的会话中。一个会话可能从深度阅读文件夹开始，经过三轮计划批注，然后运行完整实现，都在一个连续的对话中。

我没有看到每个人都在谈论的 50% 上下文窗口后的性能下降。实际上，到我说"全部实现"时，Claude 已经花了整个会话来建立理解：在研究期间阅读文件，在批注循环期间完善其心智模型，吸收我的领域知识更正。

当上下文窗口填满时，Claude 的自动压缩保持足够的上下文以继续。而计划文档，这个持久的成果，在压缩中完整保留。我可以随时让 Claude 指向它。

一句话总结工作流程

深度阅读，写一个计划，批注计划直到正确，然后让 Claude 全程执行，同时检查类型。

就是这样。没有神奇的提示，没有复杂的系统指令，没有聪明的技巧。只是一个将思考与打字分离的纪律性流程。研究防止 Claude 做出无知的更改。计划防止它做出错误的更改。批注循环注入我的判断。而实现命令让它在做出每个决策后不间断地运行。

试试我的工作流程，你会想知道，在没有批注计划文档介于你和代码之间的情况下，你是如何用编码助手交付任何东西的。

作者还在构建 nominal.dev，因为在 2026 年，没有人应该值班。

翻译说明：本文翻译自 Boris Tane 的博客文章，原文标题为 "How I Use Claude Code"。这是一篇关于如何有效使用 AI 编码助手的工作流程指南，作者分享了他 9 个月来使用 Claude Code 的经验和最佳实践。