内容来源：Marmelab。https://marmelab.com/blog/2026/04/24/claude-code-tips-i-wish-id-had-from-day-one.html
原题：Claude Code Tips I Wish I’d Had From Day One
原发布时间：2026-04-24
Marmelab 团队连续数月每天使用 Claude Code 后总结出的工作流、最佳实践和常见陷阱。
兼容性说明（核查于 2026-07-21）：Claude Code 目前默认启用自动记忆，不过每场对话仍会从全新的上下文窗口开始。当前命令名称和作用范围也有所不同：
/review是只读的 GitHub PR 审查；/code-review审查当前差异；/simplify只负责清理；/security-review取代了文中的/security；/batch会协调 5～30 个 Worktree、子智能体和 PR 工作单元，而不是执行一般意义上的批量指令，详情请参阅命令文档。用于文件改动的/rewind存在检查点限制，预览工作流则需要按照文档完成 Claude in Chrome 配置。MCP Tool Search 目前会延迟加载完整工具 Schema，从而降低启动时的上下文成本。最后，40 万 Token 后性能下降是作者的个人体验，并非官方阈值，参见模型配置。下文保留原始措辞。
几个月来，我们一直在 Marmelab 每天使用 Claude Code，从客户项目到自己的开源框架 Atomic CRM 和 react-admin 都离不开它。刚开始时，这更像是在照看一个过分热情的实习生。如今，它却更像是与一位服用了兴奋剂的高级开发者结对编程——我本人当然不认识任何服用兴奋剂的高级开发者，不过你明白我的意思 ;)。其中的差别是什么？几乎完全取决于你怎样使用它。
和任何工具一样，Claude Code 也有学习曲线。真正能够带来差异的，往往是一些细小的工作习惯，只有积累足够多的实践经验后才会发现。本文总结了我们连续数月每天使用后得到的经验，基本囊括了那些希望自己第一天就知道的事情。
真正有效的工作流
经过大量试错，下面这套工作流终于让我们获得了真正的生产力。单独来看，其中没有任何一项堪称革命性创举；恰恰是这种组合，把 Claude 的使用体验提升到了全新层次。
1、复杂任务一律使用计划模式。 在 Claude 写下第一行代码之前，先让它列出处理方案。这样会迫使它端到端思考，也让你能在实施开始前发现错误假设。纠正一份计划，远比拆掉一项做到一半的功能容易。
2、一次只要求完成第一步。 如果你说“实现整项功能”，Claude 很可能偏离轨道。应该只要求第一步，审查无误后，再让它执行第二步。这样做很烦琐吗？是的。值得吗？绝对值得。它让工作始终便于审查，也能让 Claude 保持正确方向。
3、Claude 走错方向时使用 /rewind 和 /clear。 你可能很想通过继续提示，让智能体修正错误，但这会把错误回答留在上下文中，污染后续尝试。应该使用 /rewind（或按两次 ESC）回到最近的正确状态，或者使用 /clear 从头开始。这是我们最常使用的两条命令。
4、使用预览。 很多人没有意识到，预览功能（或者 CLI 中的 Chrome 扩展）不只是给你看的，它还能让 Claude 从用户角度测试自己的改动，在你报告之前就发现错误。随后，Claude 会修复自己找到的问题，也就是说，预览能让 Claude 更加自主。
5、不要亲自修复 Bug。 Claude 引入了 Bug，却没有检测出来时，你很容易顺手自己补上。但不要这样做：Claude 可能遗漏了某些重要控制措施或指导原则。应该要求 Claude 调查 Bug、更新项目文档并说明哪里出了问题，最后再修复 Bug。即使它无法在会话间保留记忆，文档也会持续存在。下次 Claude 读取文档后，便会避开这项错误，不再重复产生同一个 Bug。
6、人工审查前先运行 /simplify 和 /review。 使用 /simplify 清除 Claude 容易加入的过度设计，例如额外抽象、不必要的泛型和想当然的错误处理。使用 /review 让 Claude 自己发现问题，再要求它修复。等你开始审查时，代码会更加干净，审查速度也会更快。
7、每次会话结束时进行复盘。 我们经常询问 Claude：“你在这次会话中学到了什么？”并保存其回答。难点在于把每项经验放到正确位置：通用项目概念写入 CLAUDE.md；良好实践和编码约定写入规则；技术能力写入 Skill 文件；项目细节写入 Markdown 文档；架构选择写入 ADR。别忘了让这些文件相互链接，以便 Claude 下次找到正确指令。这是积累组织知识的好办法，例如“Atomic CRM 的 deals 表使用软删除”，或者“react-admin 的 useListContext 必须在 ListBase 内部调用”。
最佳实践
除了工作流本身，以下实践也会显著影响 Claude 的表现。
• 在提示词中使用 @ 直接引用文件。 输入 @path/to/file.ts 后，Claude 会把所引用的文件直接载入上下文。否则，它必须先找到文件，再分块读取，速度更慢。
• 使用 ! 执行 Shell 命令。 需要启动测试或类型检查时，直接输入 CLI 命令比要求 Claude 执行更快。
• 把 CLAUDE.md 控制在 200 行以内。 CLAUDE.md 应当包含 Claude 原本不了解的业务上下文和领域知识，例如数据模型、命名约定和内部规则。确保内容简短、重点突出。
• 创建 AGENTS.md 文件。 AGENTS.md 正在成为 Copilot、Codex 和其他编程智能体读取的社区标准，但 Claude 专门读取 CLAUDE.md。一种干净的解决方案是把真实内容写入 AGENTS.md，使其能够跨智能体移植，再用简短的 CLAUDE.md 通过 @AGENTS.md 导入。
• 为重复工作流创建 Skills。 如果发现自己不止一次向 Claude 提供相同指令，就应该为其创建 Skill。以后可以直接调用，无需重复说明。下一步自然是教 Claude 自主使用这项 Skill，方法是为它编写准确的描述。
最后，还应偶尔运行用于安全审查的 /security 命令。但我们不会指望它发现所有漏洞，保证代码安全仍是我们自己的责任。
赋予 Claude Code 超能力
Claude 开箱即用时已经很好；配合正确的插件和工具后，它会变得非常出色。
• 使用 Context7 插件，不要让 Claude 自行搜索在线文档。否则，Claude 必须获取、解析内容，再判断哪些信息相关。Context7 会按照精确版本索引库文档，只向 Claude 提供它真正需要的页面。我们经常使用 Atomic CRM 和 react-admin，只需一次工具调用就能获得它们的文档后，Claude 就不会再根据两个大版本前的知识虚构 API 签名。
• 使用 superpowers Skills。从测试驱动开发到子智能体驱动开发，这些 Skills 实现了各种最佳实践和工作流，只需一条简单命令即可调用。
• 安装 gh（GitHub CLI），让 Claude 可以直接与 GitHub 交互，例如创建 Pull Request、评论 Issue、读取 CI 日志等。这让我的工作流顺畅了很多。
• 使用 rtk 减少 Claude 消耗的 Token。这款 CLI 工具会在命令输出进入大语言模型上下文前对其进行筛选和压缩。
• 使用 Snyk MCP Server，让 Claude 检查代码安全问题和依赖漏洞。
总体而言，不妨多浏览 MCP 或 Skill 仓库，寻找适合自身需求的工具。智能体生态发展迅速，每周都会涌现新工具。我们首选的仓库是 Tessl.io，它提供经过真实编码问题评估的 Skills。
最好避免的做法：我们吃过亏才明白
并非所有可用功能都是好主意。我们尝试过一些最初看起来前景很好、实际却很快变成一团乱麻的方法。
小心不要添加太多工具。 每项工具都会增加需要管理的复杂性和上下文，因此只应添加那些真正能改善工作流的工具。精心选择的少数工具，远比十几个半用不用的工具有效。
不要默认使用具有 100 万上下文的 Opus。 大约超过 40 万 Token 后，智能体的回答相关性会下降，因此额外上下文只对非常具体的任务有意义。对我所做的 95% 工作来说，默认上下文大小已经足够。
注意并行运行过多任务的成本。 例如，允许一次批量运行指令的 /batch 优化了错误目标。等到某处出错时，你已经失去了足够的粒度，无法判断是哪一步导致问题。
我们的团队对 Worktrees 也看法不一。 对一些人来说，它是并行运行多个 Claude 会话的好方法；但要跟踪的东西可能太多。你很容易被三个对话、三种差异状态和三组待决事项之间持续不断的上下文切换压垮。吞吐量在纸面上可能很漂亮，质量却未必如此。
Addy Osmani 说得最好：
“人类瓶颈是一项功能，而不是缺陷。以人类速度工作时，错误积累缓慢，痛苦也会迫使我们尽早纠正。拥有一支智能体大军后，小错误积累的速度会超过你发现它们的能力。”
结论
连续数月每天使用后，我们与 Claude Code 的关系已经从“令人印象深刻的演示”变成“不可或缺的工具”，但这只是因为我们学会了正确使用它。
规律始终一致：你提供的结构越多，输出就越好。编码前先规划，逐步审查，连接正确的工具，并克制让智能体在无人监督下自行运行的冲动。
Claude 不会取代开发者，而是放大你已经拥有的领域知识和架构知识。说真的，这正是它如此强大的原因。
除了本文介绍的工作流，还可以通过调整代码本身来提高编程智能体的生产力，我们把这种方法称为改善 Agent Experience。详情请阅读有关 Agent Experience 的文章。
