超越入门指南

你以为你在使用的机器

大多数开发者带着一种心智模型来到 Claude Code，这个模型继承自多年的聊天机器人和自动补全工具：输入问题，接收答案。这种心智模型把工具的能力低估了一个数量级，并且塑造了他们使用它的一切方式。

Claude Code 是一个循环。不是请求-响应对。是一个循环。其架构如下：读取上下文，形成计划，采取行动，验证结果。然后再来一次。再再来一次。你的一条提示可能会触发这个循环的三十或四十次迭代，每一次读取文件、编写代码、运行命令、检查输出，并决定下一步做什么。

350 行代码中的智能体循环

运行这个循环的框架出奇地简单。一个最小实现——社区开发者为了揭秘智能体系统而构建的那种教学原型——大约是 350 行代码。核心模式是三个函数：调用模型，处理响应中的工具调用，然后循环。如果有工具结果，将它们追加到消息中并再次调用模型。如果没有，任务就完成了。

response = callApi(messages, systemPrompt)
toolResults = processToolCalls(response.content)
if toolResults.length == 0: return // done
messages.append(response, toolResults)
// loop again

工具注册在一个映射表中——读取文件、写入文件、运行命令——模型发出的每个工具调用都会被分派到相应的处理器。模型推理下一步该调用什么工具。框架执行工具并将结果反馈回去。这就是整个架构。

在生产环境的 Claude Code 中，每一步都包裹着权限检查、上下文管理、hook 评估、subagent 编排和安全约束。但核心仍然是那个循环。理解这一点很重要，因为它改变了"提示"的含义。你不是在写查询。你是在向一位可以访问你整个代码库、终端、测试套件和构建系统的同事做简报。那位同事会去探索、制定计划、实施，然后在完成或卡住时回来。你初始简报的质量决定了一切。

Context Window：唯一重要的资源

Claude Code 的每一个功能、每一个架构决策、每一个最佳实践都可以追溯到一个约束：context window。

把它想象成对话的 RAM。Claude 读取的每个文件、捕获的每个命令输出、处理的每个工具结果、你交换的每条消息——所有这些都在这个固定大小的缓冲区中累积。当它填满时，性能不会优雅地下降。它会断崖式下跌。指令被遗忘。工作被丢弃。Claude 开始重新解决它已经解决过的问题。

这不是理论上的担忧。它在每个长会话中都会发生。当窗口几乎满了时，auto-compaction 会启动，总结较旧的内容以腾出空间——但总结是有损的。第 3 章涵盖了压缩机制以及如何在其中存活。

实际后果是每次交互都有以上下文空间衡量的成本，你需要像考虑计算预算或内存分配一样考虑这个成本。读取一个 2,000 行的文件是昂贵的。将冗长的测试输出倾倒到对话中是昂贵的。让 Claude 搜索它本可以用有针对性的 glob 找到的东西是昂贵的。

从 Claude Code 中获得最多收益的开发者是那些将上下文视为稀缺资源的人。他们使用 subagent 来隔离冗长的操作（第 4 章）。他们保持 CLAUDE.md 文件简洁——不超过 500 行（第 3 章）。他们主动进行压缩，而不是等待 auto-compaction 在最糟糕的时刻粗暴地处理他们的上下文。

四阶段工作流

如果你一直在直接向 Claude Code 输入实现请求，你一直在跳过最重要的步骤。

始终如一地产出最佳结果的工作流有四个阶段：探索、计划、实现、提交。跳过探索是最常见的错误，它导致 Claude 自信地用技术上正确的代码解决错误的问题。

探索。 在计划模式下开始。让 Claude 阅读你的代码库。指向相关目录。让它理解现有的模式、约定、架构。这很廉价——计划模式将 Claude 限制为只读操作，因此它不会在了解全局时意外修改任何东西。

计划。 仍在计划模式下。要求 Claude 概述其方法。审查计划。反驳与你心智模型不符的部分。这是误解浮现的地方，在计划中修复误解的成本为零。在实现中修复它的成本是一次回滚和一个被烧毁的 context window。

实现。 切换到正常模式。Claude 现在拥有了探索中的上下文和经过审查的计划。实现质量显著提高，因为 Claude 是基于理解而非假设在工作。让它运行。

提交。 Claude 会在实现完成时提议提交。审查差异。如果你做得好，差异应该不会令人意外。频繁提交。小型提交是廉价的保险。本章稍后讨论的 checkpoint 与回滚策略依赖于有干净的提交边界可以回退。

这个四阶段工作流不是关于谨慎。它是关于效率。探索和计划是廉价的。实现和调试是昂贵的。前置廉价工作以减少昂贵工作不是谨慎。这是工程。

首站工作流规划

Anthropic 的一个团队采用了一个听起来简单得微不足道但却改变了他们工作方式的实践：他们把 Claude Code 作为每项任务的第一站。在手动阅读代码之前，在搜索仓库之前，在询问同事之前——他们打开 Claude Code，让它识别与他们正在做的任何事情相关的文件。Bug 修复、功能开发、分析——都一样。

这取代了传统上在开始工作之前手动导航代码库和收集上下文的耗时过程。Claude 可以扫描整个仓库结构，识别相关文件，解释模块之间的复杂交互，并揭示人类需要十五分钟目录浏览才能发现的依赖关系。该团队报告说，这个单一习惯——总是从 Claude Code 开始，而不是将其视为可选的加速器——是他们日常工作流中最大的转变。

权限模式是工作流选择器

大多数人将权限模式视为一个安全旋钮。调高表示危险，调低表示信任。这种框架错过了要点。

权限模式塑造工作如何发生。它们是工作流选择器，而不仅仅是护栏。

计划模式将 Claude 限制为只读操作。将其用于探索和研究。你不是在谨慎；你是在有意识地确定你处于工作流的哪个阶段。

默认模式对每次写操作请求权限。将其用于需要批准每次编辑的精细更改。

自动接受编辑模式让 Claude 在不询问的情况下写入文件，但仍会提示确认 shell 命令。这是实现阶段的最佳平衡点——你信任计划但想监督系统级操作。

完全自动接受模式让 Claude 不间断地运行。当你有强有力的验证措施时使用它——好的测试套件、严格的 linter、强制执行标准的 pre-commit hook。权限模型（第 2 章）管辖 Claude Code 无需询问即可执行的全部范围。

在会话中途使用 Shift+Tab 在这些模式之间切换不是犹豫不决的表现。这是经验丰富的用户在不启动新会话的情况下完成探索-计划-实现-提交工作流的方式。你在计划模式下探索，审查计划，切换到自动接受，然后让 Claude 执行。

自主循环与 80% 交接

Anthropic 的产品开发团队将自动接受工作流推得更远。他们的工程师启用完全自动接受模式，并设置自主循环，让 Claude 编写代码、运行测试套件、阅读失败信息并持续迭代。他们交给 Claude 他们不熟悉的抽象问题，让它自主工作，然后在达到大约 80% 完成度时审查结果。最后的 20%——判断决策、设计精调、需要领域知识的边缘情况——他们自己完成。

这个工作流依赖两件事：从干净的 git 状态开始，这样当事情走向歧途时你可以回滚整个运行；以及随着 Claude 的工作进行提交，这样你就有中间的 checkpoint。Anthropic 的安全工程团队将其提炼成一条在自主会话开始时给 Claude 的单一指令："一边工作一边提交。"他们不再针对代码片段提出有针对性的问题，而是让 Claude 自主工作并进行定期检查，增量提交创建了他们可以审查、挑选或回滚的轨迹。

协作悖论

这里有一个令人不安的数字：研究表明开发者大约在百分之六十的工作中使用 AI 辅助工具。他们可以完全委托的比例——交出问题然后离开——在零到百分之二十之间。

这不是工具的失败。这是工作的特征。

软件工程是一项判断密集型活动。即使 Claude Code 处理了实现，人类仍然需要正确定义问题、评估解决方案是否合适、决定可接受的权衡，并捕捉技术上正确但在战略上错误的代码。百分之六十的使用率意味着 Claude 在一天的大部分时间中都在场且有用。这并不意味着百分之六十的工作被自动化了。AI 作为一个持续的协作者，但有效使用它需要深思熟虑的设置、主动的监督、验证和人类的判断——尤其是对于高风险工作。

最挣扎的从业者是完全期望委托并获得沮丧的人。最成功的从业者拥抱迭代伙伴模型的人：Claude 提议，你回应，Claude 调整，你批准。这是一个对话，不是一个交接。

这甚至适用于单个任务内部。你可能委托初始实现，然后监督调试，然后接手一个棘手的边缘情况，再把它交回去做测试覆盖。人类工作和机器工作之间的边界不是一条干净的线。它是一个持续的协商，而协商本身就是工作的一部分。

思维伙伴模型

还有另一种思考 Claude Code 所做之事的方式，一种超越编写代码的方式。考虑一个人的经历，他使用 Claude Code 不是为了构建软件，而是为了制定一个财务计划。他输入了多个账户的电子表格导出数据，描述了目标和约束，并在多个会话中与之迭代合作，产出了一个分阶段优化计划——包括税务影响分析、基金推荐和前后对比的配置网格。那种你会花钱请专业顾问制作的交付物。

交互模式不是"输入问题，获取答案"。它更像是与一位拥有所有数据但没有与这些账户共同生活过的分析师合作。你澄清、重新定义约束，Claude 实时更新每个计算、表格和建议。这是应用于分析而非代码的迭代思维伙伴关系。

这个模型——Claude 作为迭代分析师，而非一次性先知——适用于任何涉及处理数据、应用约束和通过反馈完善输出的工作领域。代码是最常见的用例，但心智模型直接转移到数据分析、技术写作、基础设施规划以及输出质量取决于对话质量的任何其他领域。

关键洞察：最好的从业者给 Claude 一个粗略的提案作为起点，而不是一张白纸。一个方法的草稿、一个稻草人架构，甚至一个半成形的想法。Claude 完善一个提案比从零开始生成一个更快、更准确。如果你有观点，就陈述它。如果你有预感，就分享它。输出质量直接追踪输入的具体性。

70-80% 覆盖率缺口

Claude Code 今天可以构建大约 70-80% 的生产栈。剩下的 20-30% 是有经验的开发者发挥价值的地方。

组件级评估

开发者犯的错误是抽象地思考这个缺口。它不是抽象的。它是特定于组件的，适用程度因你构建的内容而大不相同。

考虑一个具有典型前端、后端和基础设施层的生产应用程序。在组件级别，情况大致如下：

Claude Code 擅长的领域（现在构建，投入生产）：

• 前端脚手架——组件架构、表单、仪表板、状态管理。具有成熟约定的标准模式。
• API 脚手架——CRUD 端点、路由定义、中间件、请求验证。模式可预测且可验证。
• 数据库模式设计——迁移、模型、索引策略、关系定义。Claude 生成具有适当约束和不可变模式的模式。
• 测试生成——单元测试、集成测试、测试固件。明确的成功标准使其成为智能体循环的理想选择。
• DevOps 配置——容器定义、CI 流水线定义、部署脚本。模板驱动的工作，具有可验证的输出。
• 文档——API 文档、README 文件、代码注释、变更日志条目。Claude 阅读代码并描述其功能。

Claude Code 需要人类伙伴的领域（混合方法）：

• 具有连接管理的实时系统——Claude 搭建结构，但你审查连接生命周期、反压处理和故障转移逻辑。
• 性能关键路径——Claude 生成正确的代码，但针对紧张延迟预算的优化需要从人类判断中受益的测量和迭代。
• 安全敏感逻辑——认证流程、加密、访问控制。Claude 处理样板代码，但安全审查是你的。
• 领域特定协议和标准——专业协议需要 Claude 可能近似但不能保证的领域专业知识。

需要谨慎推进的领域：

• 没有成熟模式的新颖算法。Claude 会产出一些东西，但如果没有参考实现，它可能会在细微之处出错。
• 微秒级至关重要的超低延迟组件。Claude 不会做性能分析。你会。
• 任何失败模式是"它能运行，但在以后以昂贵的方式发现它错了"的情况。

快速决策矩阵

在评估是否使用 Claude Code 构建特定组件时，过一遍这个清单：

• 它有明确的成功标准吗？ 测试通过、类型检查通过、linter 满意？现在就构建它。
• 它需要实时数据处理吗？ Claude 构建组件；你负责连接管理。
• 延迟预算紧张吗？ Claude 搭建脚手架；你做性能分析和优化。
• 有成熟的模式吗？ Claude 表现出色。没有成熟模式？谨慎推进。
• 正确性不可妥协且难以验证吗？ 人工审查是必须的，不是可选的。

知道自己面对的是哪个类别本身就是一种技能。建立了这种分类直觉的开发者交付更快，因为他们不会在人类判断不可或缺的任务上与 Claude 较劲浪费时间，也不会在 Claude 可以在几秒内生成的代码上手写浪费时间。

现在构建 vs. 等待改进

一些能力即将到来但在当前工具中还不足以投入生产。务实的做法是了解区别：

现在就用 Claude Code 构建： 仓库范围的重构、API 脚手架、测试生成、数据库迁移、部署配置、文档、组件架构，以及任何验证可自动化的任务。

暂时使用混合工具链： 输入时的内联代码建议（用 IDE 集成的自动补全工具补充 Claude Code）、基于浏览器的端到端测试（Claude Code 编写测试脚本，你运行和验证它们），以及需要更成熟 UI 的复杂多智能体协调。

等待改进： 原生 CI 自动修复流水线（集成即将到来）、自动化 issue 到 pull request 的机器人（工作流零散存在但尚未完全打磨），以及更丰富的多智能体协调 UI，让你可以可视化地管理并行智能体工作。

交付最快的开发者是那些在 Claude Code 今天处理得很好的任务上大胆使用它、用其他工具补充当前缺口、并避免为将在几个月内成为原生功能的能力构建脆弱变通方案的人。

任务分类：异步 vs. 同步

不是每个任务都值得同等程度的关注。经验丰富的团队对哪些任务应该异步运行——发了就忘——哪些需要同步监督发展出了直觉。

异步候选。 为现有代码生成测试。文档更新。样板脚手架。具有清晰模式的迁移脚本。依赖更新。代码格式化和 lint 修复。这些任务具有明确的成功标准和低微妙的错误风险。让 Claude 在自动接受模式下运行，完成时检查结果。

同步候选。 核心业务逻辑。安全敏感的更改。架构决策。性能优化。任何失败模式是静默的情况——代码运行但产生错误结果。这些任务需要你实时观察、反应和纠偏。

产品团队的分类标准

Anthropic 的产品开发团队将这种直觉形式化为一个标准。产品外围的任务——一个新的设置面板、一个原型功能、一个外围 UI 组件——进入自动接受模式。开发者不熟悉的抽象问题也是好的候选，因为 Claude 在自主模式下的探索性尝试通常比人类猜测更快地浮现出正确方法。

涉及核心业务逻辑、关键面向用户功能或任何风格指南合规性和架构一致性重要的任务？同步监督。开发者观察，需要时打断，保持 Claude 与更广泛的设计意图一致。

分类不是固定的。一个从异步开始的任务可能会在 Claude 遇到意外的边缘情况时变为同步。一个从同步开始的任务可能会在你对方法满意并只需要在多个文件中应用时变为异步。在你自己的注意力和 Claude 的权限设置之间切换这些模式的能力，正是让工作流流畅的原因。

先尝试一次完成，再协作

Anthropic 的强化学习工程团队将他们的工作流提炼成一个简单的升级模式：给 Claude 一个快速提示，让它先尝试完整实现。如果成功了——大约三分之一的时间——你节省了大量时间。如果没有，切换到更协作、更引导的方式。

这听起来很显而易见，但许多开发者的默认本能恰恰相反：过度指定提示，试图预见每个边缘情况，前置加载过多的细节。一次完成再协作的模式效果更好，因为它让你发现 Claude 实际上在哪些方面挣扎，而不是猜测。第一次尝试产生了数据——你看到 Claude 的理解在哪里崩溃，你随后的指导就是有针对性的而非推测性的。

三分之一成功率不是质量指标。它是工作流的一个特性。当一次完成成功时，你节省了三十分钟的规划。当它失败时，你花了两分钟并获得了关于关注协作方向的信息。两种情况下的期望值都是强烈正面的。

会话策略

会话不是持久化的环境。每个新会话都以一个全新的 context window 开始。Claude 学到的关于你的代码库、你的偏好、你项目特点的一切——都没了。

这不是 bug。这是一个塑造你应该如何工作的设计约束。

继续。 在当前目录中恢复上一次会话。当你被打断并需要从离开的地方继续时使用。完整的对话历史被恢复到 context window 中。

按 ID 或名称恢复。 对于具有多个并行工作流的长期项目很有用。为会话取有意义的名称，以便以后能找到它们。

分叉。 创建一个新会话，以现有会话的完整历史开始但从该点分歧。原始会话被保留。当你想探索替代方法而不丢失当前进展时使用。

全新会话。 从头开始。当你上一次会话的上下文主要花在不再相关的探索上时，这通常是正确的选择。持久化的知识放在 CLAUDE.md（第 3 章）和项目的任务系统中，而不是会话历史中。

关键洞察是会话管理就是上下文管理。运行了数小时的会话是一个 context window 已满的会话，意味着性能下降。带着一个好的 CLAUDE.md 文件从头开始通常比继续一个臃肿的会话更快，因为 Claude 以完全保真度获取你的关键指令，而不是通过 auto-compacted 摘要的迷雾。

迭代伙伴模型

一次性完成的期望是大多数对 Claude Code 沮丧的根源。你输入一个详细的提示，期望完美的输出，当结果是 80% 正确而不是 100% 时感到失望。

翻转期望。为迭代做计划。

第一遍是草稿。审查它。告诉 Claude 什么错了。告诉 Claude 什么对了。给它失败的测试输出。给它 linter 错误。智能体循环就是为此设计的。每次修正都锐化了 Claude 对你真正想要什么的理解，而且因为对话历史在 context window 中，Claude 在会话内不会重复它的错误。

多会话迭代以同样的方式工作，只是用 CLAUDE.md 作为持久化层而非对话历史。在一个富有成效的会话之后，让 Claude 总结它学到了什么并建议对你的 CLAUDE.md 文件进行更新。下一个会话从更聪明开始。经过五或十个会话，CLAUDE.md 文件积累了足够多的项目特定知识，首次通过的质量会显著提高。

自我批评提示（第 8 章）进一步加速了这个循环——要求 Claude 评估自己的输出会浮出初始生成遗漏的问题。

迭代模型也改变了你对失败的思考方式。错误的首次尝试不是失败。它是数据。它告诉 Claude 一些你的原始提示没有表达的关于你想要什么的信息。内化这一点的开发者不再因不完美的输出感到沮丧，而是开始感到高效，因为每次迭代都很快，每一次都更接近目标。

频繁提交，毫不犹豫地回滚

使用 Claude Code 时最重要的操作实践是：从干净的 git 状态开始并频繁提交。小型提交是廉价的保险，当 Claude 走上错误路径时给你回滚点。

为什么？因为回滚比纠正更便宜。当 Claude 走错方向时，你的本能是解释问题并让它修复自己的工作。通常，这会让事情变得更糟——每次修正尝试都消耗上下文，加速退化。回滚到最后一个好的提交并用一个新的提示重新开始几乎总是更快。第 10 章涵盖了完整的 checkpoint 与回滚恢复策略以及团队用来形式化这种实践的"老虎机"工作流。

三分之一现实

大约三分之一的任务在首次尝试时无需额外指导就能成功。这不是质量问题——它是迭代系统的预期行为。纠正与重试的循环是快速的，并且随着你的项目验证基础设施（测试、类型、linting）的成熟，首次尝试成功率会提高。第 10 章深入涵盖了这一统计数字及其对你应该如何构建工作流的含义。

提示建议：你正在忽视的线索

Claude 完成回复后，输出下方会出现灰色的后续建议。大多数开发者忽视了它们。这是一个错误。

这些建议不是随机的。它们是根据 Claude 对逻辑下一步应该是什么的评估生成的，考虑到当前的对话上下文和代码库的状态。它们浮出你可能想要但可能没想到要要求的操作：重构后运行测试、实现后检查边缘情况、修改共享接口后更新相关文件。

这些建议在会话早期尤其有价值，当你仍在适应问题时。它们充当 Claude 注意到但未主动执行的轻量级检查清单。按 Tab 接受建议比自己构思下一个提示更快，而且建议通常比你会输入的范围更精准，因为 Claude 拥有它刚刚做了什么的完整上下文。

反模式是盲目接受建议。它们是提示，不是命令。阅读它们。如果建议匹配你接下来会做的，接受它。如果不匹配，忽略它并自己指导 Claude。价值在于建议正确时节省的时间，而不是完全放弃你自己的判断。

当简洁胜过精巧

Claude 有一种过度工程的倾向——一个在第 10 章中详细讨论的失败模式。简短版本：告诉 Claude 保持简单，明确约束它采用直接的实现，并在你的 CLAUDE.md 文件中放入简洁性指令。

这连接到一个更广泛的原则：Claude Code 对约束的响应比对自由的响应更好。模糊的提示产生模糊的输出。带有具体约束的提示——要触碰哪些文件、遵循哪些模式、做哪些权衡、避免哪些框架——产生聚焦的、合适的代码。提示技巧章节（第 8 章）有更多内容。