How I Use Claude Code | 我是如何使用 Claude Code 的

引言

原文： I've been using Claude Code as my primary development tool for approx 9 months, and the workflow I've settled into is radically different from what most people do with AI coding tools. Most developers type a prompt, sometimes use plan mode, fix the errors, repeat. The more terminally online are stitching together ralph loops, mcps, gas towns (remember those?), etc. The results in both cases are a mess that completely falls apart for anything non-trivial.

翻译： 我使用 Claude Code 作为主要开发工具已经大约 9 个月了，我形成的工作流程与大多数人使用 AI 编码工具的方式截然不同。大多数开发者输入一个提示词，有时使用计划模式，修复错误，然后重复。那些更加深度上网的人会拼凑各种循环、MCP、Gas Towns（还记得那些吗？）等等。这两种方式的结果都是一团糟，对于任何非平凡的任务都会彻底崩溃。

原文： The workflow I'm going to describe has one core principle: never let Claude write code until you've reviewed and approved a written plan. This separation of planning and execution is the single most important thing I do. It prevents wasted effort, keeps me in control of architecture decisions, and produces significantly better results with minimal token usage than jumping straight to code.

翻译： 我要描述的工作流程有一个核心原则：在你审查并批准书面计划之前，永远不要让 Claude 写代码。这种计划与执行的分离是我做的最重大的事情。它可以防止浪费精力，让我掌控架构决策，并且与直接跳入编码相比，能够以更少的 token 消耗产生显著更好的结果。

完整工作流程图

Phase 1: Research | 第一阶段：研究

原文： Every meaningful task starts with a deep-read directive. I ask Claude to thoroughly understand the relevant part of the codebase before doing anything else. And I always require the findings to be written into a persistent markdown file, never just a verbal summary in the chat.

翻译： 每个有意义的任务都从一个深度阅读指令开始。我要求 Claude 在做其他任何事情之前彻底理解代码库的相关部分。而且我总是要求将发现写入一个持久的 markdown 文件中，而不仅仅是在聊天中进行口头总结。

原文（示例指令）： read this folder in depth, understand how it works deeply, what it does and all its specificities. when that's done, write a detailed report of your learnings and findings in research.md

翻译： 深入阅读这个文件夹，深入理解它是如何工作的、它做什么以及它的所有特性。完成后，将你的学习和发现写成一份详细的报告，保存在 research.md 中。

原文（示例指令）： study the notification system in great details, understand the intricacies of it and write a detailed research.md document with everything there is to know about how notifications work

翻译： 超级详细地研究通知系统，理解其中的复杂性，并写一份详细的 research.md 文档，包含关于通知如何工作的一切知识。

原文（示例指令）： go through the task scheduling flow, understand it deeply and look for potential bugs. there definitely are bugs in the system as it sometimes runs tasks that should have been cancelled. keep researching the flow until you find all the bugs, don't stop until all the bugs are found. when you're done, write a detailed report of your findings in research.md

翻译： 仔细检查任务调度流程，深入理解它并寻找潜在的 bug。系统中肯定存在 bug，由于它有时会运行应该被撤销的任务。持续研究这个流程直到找到所有 bug，在找到所有 bug 之前不要停止。完成后，将你的发现写成一份详细的报告，保存在 research.md 中。

原文： Notice the language: “deeply”, “in great details”, “intricacies”, “go through everything”. This isn't fluff. Without these words, Claude will skim. It'll read a file, see what a function does at the signature level, and move on. You need to signal that surface-level reading is not acceptable.

翻译： 注意这些措辞：“深入”、“超级详细”、“复杂性”、“检查所有东西”。这不是废话。没有这些词，Claude 会浅尝辄止。它会读取一个文件，在签名级别看看函数做什么，然后继续。你需要表明表面级别的阅读是不可接受的。

原文： The written artifact (research.md) is critical. It's not about making Claude do homework. It's my review surface. I can read it, verify Claude actually understood the system, and correct misunderstandings before any planning happens. If the research is wrong, the plan will be wrong, and the implementation will be wrong. Garbage in, garbage out.

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

原文： This is the most expensive failure mode with AI-assisted coding, and it's not wrong syntax or bad logic. It's implementations that work in isolation but break the surrounding system. A function that ignores an existing caching layer. A migration that doesn't account for the ORM's conventions. An API endpoint that duplicates logic that already exists elsewhere. The research phase prevents all of this.

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

Phase 2: Planning | 第二阶段：计划

原文： Once I've reviewed the research, I ask for a detailed implementation plan in a separate markdown file.

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

原文（示例指令）： I want to build a new feature that extends the system to perform . write a detailed plan.md document outlining how to implement this. include code snippets

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

原文（示例指令）： the list endpoint should support cursor-based pagination instead of offset. write a detailed plan.md for how to achieve this. read source files before suggesting changes, base the plan on the actual codebase

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

原文： The generated plan always includes a detailed explanation of the approach, code snippets showing the actual changes, file paths that will be modified, and considerations and trade-offs.

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

原文： I use my own .md plan files rather than Claude Code's built-in plan mode. The built-in plan mode sucks. My markdown file gives me full control. I can edit it in my editor, add inline notes, and it persists as a real artifact in the project.

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

原文： One trick I use constantly: for well-contained features where I've seen a good implementation in an open source repo, I'll share that code as a reference alongside the plan request. If I want to add sortable IDs, I paste the ID generation code from a project that does it well and say “this is how they do sortable IDs, write a plan.md explaining how we can adopt a similar approach.” Claude works dramatically better when it has a concrete reference implementation to work from rather than designing from scratch.

翻译： 我常常使用的一个技巧： 对于那些我在开源仓库中看到过良好实现的良好封装功能，我会分享那段代码作为参考，与计划请求一起提供。如果我想添加可排序的 ID，我会粘贴一个做得好的项目中的 ID 生成代码，然后说”这就是他们做可排序 ID 的方式，写一份 plan.md 解释我们如何采用类似的方法。”当 Claude 有一个具体的参考实现可以借鉴，而不是从头设计时，它的表现会显著更好。

原文： But the plan document itself isn't the interesting part. The interesting part is what happens next.

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

The Annotation Cycle | 标注循环

原文： This is the most distinctive part of my workflow, and the part where I add the most value.

翻译： 这是我工作流程中最独特的部分，也是我创造最多价值的部分。

标注循环流程图

原文： After Claude writes the plan, I open it in my editor and add inline notes directly into the document. These notes correct assumptions, reject approaches, add constraints, or provide domain knowledge that Claude doesn't have.

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

原文： The notes vary wildly in length. Sometimes a note is two words: “not optional” next to a parameter Claude marked as optional. Other times it's a paragraph explaining a business constraint or pasting a code snippet showing the data shape I expect.

翻译： 注释的长度差异很大。有时注释只有两个词：”不可选”，放在 Claude 标记为可选的参数旁边。有时是一段解释业务约束的文字，或粘贴一段代码片段展示我期望的数据结构。

原文（真实注释示例）： “use drizzle:generate for migrations, not raw SQL”

翻译： “使用 drizzle:generate 进行迁移，不要使用原始 SQL”

说明： 这是 Claude 没有的领域知识。

原文（真实注释示例）： “no — this should be a PATCH, not a PUT”

翻译： “不——这应该是 PATCH，不是 PUT”

说明： 纠正错误的假设。

原文（真实注释示例）： “remove this section entirely, we don't need caching here”

翻译： “完全删除这一部分，我们这里不需要缓存”

说明： 拒绝提议的方法。

原文（真实注释示例）： “the queue consumer already handles retries, so this retry logic is redundant. remove it and just let it fail”

翻译： “队列消费者已经处理重试，所以这个重试逻辑是多余的。删除它，让它失败就好”

说明： 解释为什么应该更改。

原文（真实注释示例）： “this is wrong, the visibility field needs to be on the list itself, not on individual items. when a list is public, all items are public. restructure the schema section accordingly”

翻译： “这错了，可见性字段应该在列表本身上，而不是在单个项目上。当列表公开时，所有项目都是公开的。相应地重构模式部分”

说明： 重定向计划的整个部分。

原文： Then I send Claude back to the document: “I added a few notes to the document, address all the notes and update the document accordingly. don't implement yet”

翻译： 然后我让 Claude 回到文档：”我在文档中添加了一些注释，处理所有注释并相应更新文档。先不要实现”

原文： This cycle repeats 1 to 6 times. The explicit “don't implement yet” guard is essential. Without it, Claude will jump to code the moment it thinks the plan is good enough. It's not good enough until I say it is.

翻译： 这个循环重复 1 到 6 次。 明确的 “先不要实现” 保护至关重大。没有它，Claude 一旦认为计划足够好就会跳入编码。直到我说足够好，才是真的足够好。

Why This Works So Well | 为什么这样效果这么好

原文： The markdown file acts as shared mutable state between me and Claude. I can think at my own pace, annotate precisely where something is wrong, and re-engage without losing context. I'm not trying to explain everything in a chat message. I'm pointing at the exact spot in the document where the issue is and writing my correction right there.

翻译： markdown 文件作为我和 Claude 之间的共享可变状态。我可以按照自己的节奏思考，准确标注出错的地方，并在不失上下文的情况下重新参与。我不是尝试在聊天消息中解释一切。我是指向文档中问题的确切位置，并在那里写下我的纠正。

原文： This is fundamentally different from trying to steer implementation through chat messages. The plan is a structured, complete specification I can review holistically. A chat conversation is something I'd have to scroll through to reconstruct decisions. The plan wins every time.

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

原文： Three rounds of “I added notes, update the plan” can transform a generic implementation plan into one that fits perfectly into the existing system. Claude is excellent at understanding code, proposing solutions, and writing implementations. But it doesn't know my product priorities, my users' pain points, or the engineering trade-offs I'm willing to make. The annotation cycle is how I inject that judgement.

翻译： 三轮”我添加了注释，更新计划”可以将一个通用的实施计划转变为一个完美融入现有系统的计划。Claude 超级擅长理解代码、提出解决方案和编写实现。但它不知道我的产品优先级、我的用户痛点，或我愿意做出的工程权衡。标注循环是我注入这些判断的方式。

The Todo List | 任务清单

原文： Before implementation starts, I always request a granular task breakdown: “add a detailed todo list to the plan, with all the phases and individual tasks necessary to complete the plan – don't implement yet”

翻译： 在实现开始之前，我总是请求一个细粒度的任务分解：”在计划中添加一个详细的待办事项清单，包含完成计划所需的所有阶段和单独任务——先不要实现”

原文： This creates a checklist that serves as a progress tracker during implementation. Claude marks items as completed as it goes, so I can glance at the plan at any point and see exactly where things stand. Especially valuable in sessions that run for hours.

翻译： 这创建了一个清单，作为实现过程中的进度跟踪器。Claude 会在进行时将项目标记为已完成，所以我可以在任何时候瞥一眼计划，准确了解进展情况。在持续数小时的会话中尤其有价值。

Phase 3: Implementation | 第三阶段：实现

原文： When the plan is ready, I issue the implementation command. I've refined this into a standard prompt I reuse across sessions:

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

原文（标准提示词）： implement it all. when you're done with a task or phase, mark it as completed in the plan document. do not stop until all tasks and phases are completed. do not add unnecessary comments or jsdocs, do not use any or unknown types. continuously run typecheck to make sure you're not introducing new issues.

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

原文： This single prompt encodes everything that matters:

“implement it all”: do everything in the plan, don't cherry-pick

“mark it as completed in the plan document”: the plan is the source of truth for progress

“do not stop until all tasks and phases are completed”: don't pause for confirmation mid-flow

“do not add unnecessary comments or jsdocs”: keep the code clean

“do not use any or unknown types”: maintain strict typing

“continuously run typecheck”: catch problems early, not at the end

翻译： 这个单一的提示词编码了所有重大的内容：

“全部实现”：做计划中的所有内容，不要挑挑拣拣

“在计划文档中标记为已完成”：计划是进度的真实来源

“在所有任务和阶段完成之前不要停止”：不要在流程中暂停等待确认

“不要添加不必要的注释或 jsdocs”：保持代码干净

“不要使用 any 或 unknown 类型”：保持严格类型

“持续运行类型检查”：尽早发现问题，而不是到最后

原文： I use this exact phrasing (with minor variations) in virtually every implementation session. By the time I say “implement it all,” every decision has been made and validated. The implementation becomes mechanical, not creative. This is deliberate. I want implementation to be boring. The creative work happened in the annotation cycles. Once the plan is right, execution should be straightforward.

翻译： 我几乎在每个实现会话中都使用完全一样的措辞（略有变化）。当我说”全部实现”时，每个决定都已经做出并验证。实现变得机械化，而不是创造性。这是故意的。我希望实现变得无趣。创造性工作发生在标注循环中。一旦计划正确，执行就应该简单直接。

原文： Without the planning phase, what typically happens is Claude makes a reasonable-but-wrong assumption early on, builds on top of it for 15 minutes, and then I have to unwind a chain of changes. The “don't implement yet” guard eliminates this entirely.

翻译： 没有计划阶段，一般会发生的是 Claude 早期做出一个合理但错误的假设，在此基础上构建 15 分钟，然后我不得不解开一连串的更改。”先不要实现”的保护完全消除了这种情况。

Feedback During Implementation | 实现过程中的反馈

原文： Once Claude is executing the plan, my role shifts from architect to supervisor. My prompts become dramatically shorter.

翻译： 一旦 Claude 开始执行计划，我的角色就从架构师转变为监督者。我的提示词变得显著更短。

反馈流程图

原文： Where a planning note might be a paragraph, an implementation correction is often a single sentence:

“You didn't implement the deduplicateByTitle function.”

“You built the settings page in the main app when it should be in the admin app, move it.”

翻译： 计划注释可能是一段话，而实现纠正一般只有一句话：

“你没有实现 deduplicateByTitle 函数。”

“你把设置页面建在主应用里了，它应该在管理应用里，把它移过去。”

原文： Claude has the full context of the plan and the ongoing session, so terse corrections are enough.

翻译： Claude 拥有计划和当前会话的完整上下文，所以简洁的纠正就足够了。

原文： Frontend work is the most iterative part. I test in the browser and fire off rapid corrections:

“wider”

“still cropped”

“there's a 2px gap”

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

“更宽一点”

“还是被裁剪了”

“有个 2 像素的间隙”

原文： For visual issues, I sometimes attach screenshots. A screenshot of a misaligned table communicates the problem faster than describing it.

翻译： 对于视觉问题，我有时会附上截图。一张表格未对齐的截图比描述它更快地传达问题。

原文： I also reference existing code constantly:

“this table should look exactly like the users table, same header, same pagination, same row density.”

翻译： 我还不断引用现有代码：

“这个表格应该看起来和 users 表格完全一样，一样的头部、一样的分页、一样的行密度。”

原文： This is far more precise than describing a design from scratch. Most features in a mature codebase are variations on existing patterns. A new settings page should look like the existing settings pages. Pointing to the reference communicates all the implicit requirements without spelling them out. Claude would typically read the reference file(s) before making the correction.

翻译： 这比从头描述设计要准确得多。成熟代码库中的大多数功能都是现有模式的变体。一个新的设置页面应该看起来像现有的设置页面。指向参考文件可以传达所有隐性需求，而无需一一说明。Claude 一般会在进行纠正之前阅读参考文件。

原文： When something goes in a wrong direction, I don't try to patch it. I revert and re-scope by discarding the git changes:

“I reverted everything. Now all I want is to make the list view more minimal — nothing else.”

翻译： 当某些内容走向错误方向时，我不会尝试修补它。我会通过丢弃 git 更改来撤销并重新调整范围：

“我撤销了所有内容。目前我想要的只是让列表视图更简洁——仅此而已。”

原文： Narrowing scope after a revert almost always produces better results than trying to incrementally fix a bad approach.

翻译： 撤销后缩小范围几乎总是比尝试逐步修复错误的方法产生更好的结果。

Staying in the Driver's Seat | 掌控方向盘

原文： Even though I delegate execution to Claude, I never give it total autonomy over what gets built. I do the vast majority of the active steering in the plan.md documents.

翻译： 即使我将执行委托给 Claude，我也从不给它对构建内容的完全自主权。我在 plan.md 文档中完成绝大多数的主动引导。

原文： This matters because Claude will sometimes propose solutions that are technically correct but wrong for the project. Maybe the approach is over-engineered, or it changes a public API signature that other parts of the system depend on, or it picks a more complex option when a simpler one would do. I have context about the broader system, the product direction, and the engineering culture that Claude doesn't.

翻译： 这很重大，由于 Claude 有时会提出技术上正确但对项目错误的解决方案。也许方法过度设计了，或者它更改了系统其他部分依赖的公共 API 签名，或者在更简单的选项可行时选择了更复杂的选项。我有关于更广泛系统、产品方向和工程文化的背景信息，而 Claude 没有。

决策流程图

原文： Cherry-picking from proposals: When Claude identifies multiple issues, I go through them one by one: “for the first one, just use Promise.all, don't make it overly complicated; for the third one, extract it into a separate function for readability; ignore the fourth and fifth ones, they're not worth the complexity.” I'm making item-level decisions based on my knowledge of what matters right now.

翻译： 从提议中精挑细选： 当 Claude 识别出多个问题时，我会逐一审查：”第一个，直接用 Promise.all，不要搞得太复杂；第三个，把它提取成一个单独的函数以提高可读性；忽略第四和第五个，它们不值得增加复杂度。”我基于当前什么重大的知识进行逐项决策。

原文： Trimming scope: When the plan includes nice-to-haves, I actively cut them. “remove the download feature from the plan, I don't want to implement this now.” This prevents scope creep.

翻译： 削减范围： 当计划包含锦上添花的功能时，我会主动砍掉它们。”从计划中删除下载功能，我目前不想实现这个。”这可以防止范围蔓延。

原文： Protecting existing interfaces: I set hard constraints when I know something shouldn't change: “the signatures of these three functions should not change, the caller should adapt, not the library.”

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

原文： Overriding technical choices: Sometimes I have a specific preference Claude wouldn't know about: “use this model instead of that one” or “use this library's built-in method instead of writing a custom one.” Fast, direct overrides.

翻译： 覆盖技术选择： 有时我有 Claude 不知道的具体偏好：”用这个模型而不是那个”或”用这个库的内置方法而不是自己写一个。”快速、直接的覆盖。

原文： Claude handles the mechanical execution, while I make the judgement calls. The plan captures the big decisions upfront, and selective guidance handles the smaller ones that emerge during implementation.

翻译： Claude 处理机械执行，而我做判断。计划提前捕获重大决策，选择性指导处理实现过程中出现的较小决策。

Single Long Sessions | 单一长会话

原文： I run research, planning, and implementation in a single long session rather than splitting them across separate sessions. A single session might start with deep-reading a folder, go through three rounds of plan annotation, then run the full implementation, all in one continuous conversation.

翻译： 我在一个长会话中运行研究、计划和实现，而不是将它们分成多个会话。一个会话可能从深度阅读一个文件夹开始，经过三轮计划标注，然后运行完整的实现，全部在一个连续的对话中完成。

原文： I am not seeing the performance degradation everyone talks about after 50% context window. Actually, by the time I say “implement it all,” Claude has spent the entire session building understanding: reading files during research, refining its mental model during annotation cycles, absorbing my domain knowledge corrections.

翻译： 我没有看到大家谈论的在 50% 上下文窗口之后的性能下降。实际上，当我说”全部实现”时，Claude 已经花了整个会话建立理解：在研究期间阅读文件，在标注循环中完善其心智模型，吸收我的领域知识纠正。

原文： When the context window fills up, Claude's auto-compaction maintains enough context to keep going. And the plan document, the persistent artifact, survives compaction in full fidelity. I can point Claude to it at any point in time.

翻译： 当上下文窗口填满时，Claude 的自动压缩功能会保持足够的上下文以继续。而计划文档这个持久产物，在压缩后完整保留。我可以在任何时候让 Claude 参考它。

The Workflow in One Sentence | 一句话总结工作流程

原文： Read deeply, write a plan, annotate the plan until it's right, then let Claude execute the whole thing without stopping, checking types along the way.

翻译： 深入阅读，写一个计划，标注计划直到它正确，然后让 Claude 执行整个事情，中途不停止，同时进行类型检查。

原文： That's it. No magic prompts, no elaborate system instructions, no clever hacks. Just a disciplined pipeline that separates thinking from typing. The research prevents Claude from making ignorant changes. The plan prevents it from making wrong changes. The annotation cycle injects my judgement. And the implementation command lets it run without interruption once every decision has been made.

翻译： 就是这样。没有魔法提示词，没有复杂的系统指令，没有机智的技巧。只是一个将思考与打字分离的纪律化流程。研究防止 Claude 做出无知的更改。计划防止它做出错误的更改。标注循环注入我的判断。实现命令让它在每个决定都做出后无中断地运行。

原文： Try my workflow, you'll wonder how you ever shipped anything with coding agents without an annotated plan document sitting between you and the code.

翻译： 试试我的工作流程，你会想知道你以前没有一份带注释的计划文档挡在你和代码之间，是怎么用编码代理发布任何东西的。

原文（作者附注）： I'm also building nominal.dev, because nobody should be on-call in 2026.

翻译： 我也在构建 nominal.dev，由于在 2026 年没有人应该待命值班。

核心要点总结

阶段	关键做法	目的
研究	深度阅读，写入 research.md	防止无知的更改
计划	写 plan.md，包含代码片段	防止错误的更改
标注循环	内联注释，重复 1-6 轮	注入人的判断
任务清单	细粒度分解，进度跟踪	可视化进度
实现	标准提示词，持续类型检查	机械化执行
反馈	简洁纠正，引用现有代码	快速迭代

如果你觉得这篇文章有协助，欢迎分享给更多人！有兴趣也可以去看下原文。

作者： Boris Tane（Cloudflare Engineering Lead）

发布日期： 2026 年 2 月 10 日

原文链接： https://boristane.com/blog/how-i-use-claude-code