为什么你每天都在用 Claude Code，工作流却毫无变化
"我记得我运行过 /init。但我不知道上次更新是什么时候。"
听起来像你吗？你安装了 Claude Code，头几天花时间配置，然后每天和它聊天。然而，和三个月前相比，你工作的结构几乎没有变化。
这不是使用频率的问题，而是定位问题。
如果你一直把 Claude Code 当作一个"有问必答的工具"，你就会每天早上输入同样的指令，得到类似的回复，然后复制粘贴到你的工作中。你可能效率更高了，但工作的推进方式并没有根本改变。
改变发生在你开始把 Claude Code 当作一个"设计对象"的时候。谁在什么上下文中知道什么？哪些任务委派给谁？即使没有人在场，什么也在运转？当你开始以设计的思维来思考这个问题，Claude Code 的行为就会完全不同。
@sairahul1 发布的 27 项功能 (https://x.com/sairahul1/status/2070428662080618607) 系统地列出了应该从这种设计角度使用的功能。Swarm 通过 Agent 设计的视角解读了这些功能，并将它们组织成适用于实际业务场景的格式。
27 项看起来很多，但核心原则只有三个。我们将从下一章开始按顺序解释这个结构。
连接 27 项功能的三个核心原则
看这 27 项功能，它们可能看起来零散。有快捷键、文件设置、语音输入和测试执行。但解码后，它们可以组织成回答三个问题的组。
原则 1：上下文设计（功能 1–5）
创建一个状态，让 Claude 知道"这是谁的项目、目的是什么、目前理解了多少"。如果这个坏了，你每次都得从头解释一切。
原则 2：委派设计（功能 6–14）
将任务和权限结构性地交给 Claude。不是简单说"修复错误"，而是组织和交付"什么坏了以及有什么约束"，这能改变一次性解决的概率。
原则 3：自主设计（功能 15–27）
设计一个机制，让 Claude 无需人类持续指令就能持续运转。
这三个阶段也是你应该使用的顺序。如果上下文没设好，委派就会变得马虎。如果委派没设计好，自主运行就会失控。
这里你需要意识到的是，如何改变"我每天早上指示 Claude"这个结构。如果你每天早上都在聊天里扔同样的任务，那人类仍然是主体。当设计切换到让 Claude 运转的结构时，你早上的行为就变了。
首先，我们来看看上下文设计的五个功能。
上下文设计基础
上下文设计的目标是给 Claude 提供"这个项目的上下文"。没有上下文，每次对话都从空白开始。
第一件要运行的事是 `/init`。
当你第一次打开一个项目时，先运行这个。Claude 会扫描代码库结构、依赖和构建命令，自动生成 CLAUDE.md。这个文件成为项目的"蓝图"。
很多人就在这里停下了。他们记得运行过 /init，但不知道上次更新是什么时候。如果保持原样生成，CLAUDE.md 的内容会随着项目变化而偏离现实。通过每周更新的前提，Claude 总能在最新的上下文中运转。
接下来，设置 `/statusline` 很有用。
屏幕底部会显示一个状态行。你可以直观地看到正在运行什么以及哪些进程是活跃的。它还可以与 Vim 或 Neovim 中的自定义状态行集成，让你根据自己的编辑器环境进行设置。
第三个是语音输入。
你可以使用 Mac 上的 ⌃⌘Space 或 iOS 和 Android 上的原生语音输入，通过说话来传递复杂的需求。你可以传递很长的指令，比如"我希望这个组件因为这个原因以这种方式移动，但不要更改现有的样式"，而无需打字。由于可以随着思路流动传递想法，节省了打字时组织语言的时间。
使用 `/context` 检查上下文状态。
你可以实时看到当前在对话中的内容以及上下文窗口的使用情况。在长时间的会话中，最初的蓝图内容往往会淡化。这个命令可以让你监控这一点。
相应的重置操作是 `/compact` 和 `/clear`。
/compact 将整个上下文压缩成摘要。/clear 是完全重置。如果你持续一个长会话，Claude 的回答可能会变得模糊。这是上下文堵塞的信号。通过定期使用 /compact，你可以保持输出质量。
之前：在长会话的后半段，即使说"按照之前讨论的设计策略"，Claude 也会给出偏离的回答。
之后：在继续之前用 /compact 压缩，可以保持输出与策略一致。
这五个功能做一件事：维持 Claude "知道"的状态作为设计。这成为下一步委派设计的基础。
传递问题的艺术
一旦上下文设置好了，下一步就是如何传递问题。说"修复错误"和以结构化的方式传递问题，回答的准确性完全不同。
首先，使用计划模式（`Shift+Tab`）。
在重大更改之前，这种模式只输出"计划"而不执行。你可以提前检查 Claude 打算更改什么以及以什么顺序更改。
不用等到出错后再修复，你可以在计划阶段指出"那不对"。将这一步融入设计，会显著改变意外更改的频率。随着你持续使用，你会意识到它减少了事后检查"为什么这个文件被重写了？"的工作量。
第二是问题、约束和上下文的结构化。
如果你只说"修复错误"，Claude 会自己填补假设。如果那些假设错了，解决方案也会错。
官方推荐的格式是：第一行写"出了什么问题"，从第二行开始写"尝试过什么、约束条件、以及期望的输出格式"。只是以这种格式传递，就能改变一次性解决率。传递问题的方式本身就成为了一种技能。
第三是 `AskUserQuestion`。
这是当 Claude 遇到模糊需求时可以主动要求澄清的功能。由于需求不明确而导致实施后返工的情况，往往是在这个功能未被使用时发生的。这是一种在实施前付出确认成本的设计。
第四是自我验证步骤。
在任务结束时，告诉它"在完成前运行测试并确认构建通过"。与其每次都手动添加，不如将其写入 CLAUDE.md，确保每个任务结束时自动运行。这样，更改后不会停在"东西不工作"的状态，而是将包括验证的循环作为一个完整任务完成。
主动使用计划模式，被动通过自我验证自动化。当这两者融入设计时，开发流程的结构就改变了。
在下一章，我们将探讨将持续任务委派给 Claude 的设计。
设计委派
在前几章中，我们整理了如何与 Claude 沟通以及如何让它保留记忆。接下来是关于改变"谁是主体"的问题。
10. 子 Agent
如果在长任务中由人类管理流程，不可避免地会卡住。不断说"接下来做这个，做完后做那个"意味着人类在处理协调，而不是 Claude。
使用 TodoWrite 或 Task 工具，Claude 将任务分解为子任务并并行执行。在官方术语中，这就是"并发子 Agent 执行"——多个子 Claude 同时运转。不同的 Claude 同时运行研究、实现和测试。人类不需要持有流程。
11. 自定义技能（工作流模板文件）
将 Markdown 文件放入 .claude/commands/ 目录中，就可以通过 /命令名 来调用指令集。用 Swarm 的语境来说，将其视为"SKILL.md（工作流模板文件）"更容易理解。
之前：每次写"请进行竞争对手调查。步骤是 1、2、3……"。
之后：只需输入一行 /competitive-research。
重复写同样指令的时间消失了。如果与团队共享，它就成为了一个任何人都能获得相同质量输出的模板。
12. 模型选择
你可以在会话中按 Alt+P 切换模型。一个现实的三阶段用法是：设计和概念阶段使用高推理模型，简单实现使用轻量模型，调试使用中端模型。
将模型的性能与流程的权重匹配，同时提高了成本效率和响应速度。
13. 自动更新 CLAUDE.md
如果你告诉 Claude"把你在本项目中学到的添加到 CLAUDE.md"，Claude 就会自己更新 CLAUDE.md。这是一个蓝图自动成长的结构。
每周添加一次这个命令，CLAUDE.md 就成为了一个"活文档"。即使人类不写反思，Claude 也会积累它学到的东西。
14. 外部文件链接
你可以使用 @{文件路径} 将文件、URL 或 Issue 作为上下文传递。这是一种在一行内完成"在工作前阅读这个文件"的机制。
之前：复制粘贴文件内容到提示中。
之后：只需写"参考 @src/config.yaml 检查设置"。
设计委派意味着创建一个将主体交给 Claude 的系统。当流程、模板、参考和记忆都到位后，人类只需要思考"要创造什么"。
然而，随着委派增加，"Claude 朝着与意图不同的方向前进"的风险也会增加。在下一章，我们将看看如何尽早阻止这种偏离。
尽早阻止偏离
随着向 Claude 的委派增加，一个问题更容易出现：意识到它已经朝着完全不同的方向偏离了意图。我们称之为偏离。
偏离不是事后修复的，而是可以通过主动设计步骤来预防的。
15. 立即停止
如果你感觉输出明显走错了方向，你可以用 Escape 键立即停止。"等它完成后再修复"是个错误。生成进行得越远，修正成本就越高。中途停止并修改提示可以节省时间和 token。
如果你直觉觉得有问题，毫不犹豫地停止。这种判断的速度直接影响准确性。
16. 请求首个输出作为证据
一种主动设计是在开始工作前说"先给我看第一个输出，我决定是否继续"。
与其让它花 10 分钟在错误方向上，不如在让它运行前先用第一个输出确认。这是把偏离扼杀在萌芽状态的想法。对于长时间任务或方向模糊的工作来说至关重要。
在说"剩下的交给你"之前，插入"让我先看看开头"。只是一步，但这个主动动作会改变结果。
17. 通知钩子
盯着屏幕等待长任务结束是浪费时间。通过在 ~/.claude/hooks/ 中放置脚本，你可以在任务完成时收到桌面通知。
设置一次。之后，即使你在做其他工作，Claude 完成后也会通知你。这是一种消除等待行为的设计。
18. 传递截图
用语言解释 UI 错误出奇地困难。与其用嘴说"左上角出现了一个红色错误，按钮按不了"，传递截图更快。
Claude 接收图像并直接返回错误内容、原因和修复建议。用"看这个屏幕"就完成了。
到目前为止介绍的 18 项功能都基于一人操作的假设。在下一章，我们进入"作为团队使用"的结构，多个 Claude 并行运行并整合。
并行运行与整合
把 Claude Code 当作聊天工具使用时，在完成一个任务之前无法开始下一个。但通过改变设计，你可以创建多个 Claude 同时运行的结构。
从 Chrome DevTools 集成开始。因为你可以将浏览器错误日志和网络日志直接传递给 Claude Code，所以不再需要用语言解释"控制台有个红色错误但我不知道发生了什么"这类情况。官方文档为此有专门的页面，将其定位为调试的门户。
会话管理也发生了变化。你可以用 claude --continue 原样恢复最新会话，或用 claude --resume 从会话列表中选择。此外，通过 /rename 命名会话，你可以像管理 Git 分支一样管理多个并行任务。通过使用名为"Auth"、"Payment"和"Dashboard"的会话，切换上下文的成本几乎为零。
而并行运行的核心是与 git worktrees 的结合。输入 claude --worktree feature-auth 将启动一个会话，其中分支被 worktree 完全隔离。如果你在单独的 worktree 中运行 Auth、Payment 和 Dashboard，三个 Claude 将并行推进开发。由于每个都在独立的工作空间中，不会发生冲突。一周的开发量一天完成的结构就在这里作为设计确立。
也需要整理关于 MCP 的思考。MCP 服务器并不总是最优解。官方文档指出"CLI 工具是与外部服务交互时上下文效率最高的方式"，并且像 gh 或 aws 这样的 CLI 工具被认为具有高上下文效率，不太容易遇到速率限制。仅凭 gh 命令，Claude Code 就能自主创建、更新和关闭 GitHub Issue。在添加 MCP 之前先检查是否可以使用 CLI 工具的判断轴，可以让设计保持简洁。
当并行设计成为可能，人类不再需要管理顺序。这是因为设计切换到了同时将多个主体交给 Claude。接下来，我们将把这种设计好的并行处理进化成一个即使你离开办公桌也能持续运转的系统。
自主运行
并行设计之后的下一个问题是"在那段时间我需要在哪里？"当自主运行被设计好时，就会创建一种即使没有人类在场工作也在推进的状态。
/loop 是一个在会话内运行自动轮询的功能。官方解释是"在会话打开时快速轮询"，它在会话打开时重复指定的操作。使用 --resume 或 --continue 可以恢复未过期的会话，根据原文中的体验报告，已经报告了长达三天的无人操作案例。虽然我们没有直接从官方来源确认那个天数，但它确实作为长时自主运行的入口在运作。
于 2026 年第一季度新增的远程控制（Remote Control），是一项从智能手机或 PC 浏览器操作本地运行的 Claude Code 会话的功能。代码保持本地，只有消息通过加密通道交换。它于 2026 年 2 月作为研究预览版发布。一个场景是：在外出时，只需从智能手机发送"检查测试是否通过了"，本地 Claude Code 就会继续运转。
对数据库的自然语言查询也可以融入设计。通过 MCP 连接到 SQLite、PostgreSQL 或 MySQL，你可以使用中文（或英文）检索数据，比如"告诉我上周注册的用户"。官方指南建议运行 claude mcp add 来连接外部工具（如你的数据库），从而在不写 SQL 的情况下将数据确认例程委派给 Claude。
还有四个控制思考深度的功能。ultrathink 只需在提示中包含这个关键词，就能触发最长 31,999 个 token 的扩展思考。存在一个层次结构：think 是 4,000 token，megathink 是 10,000 token，ultrathink 是 31,999 token。正确的用法是只用于真正困难的 10% 问题，例如复杂的架构决策、安全实现、性能优化和大规模重构。对每个查询都使用它会徒增成本。
/effort ultracode 是一个设置，用于在整个会话中启用 xhigh 推理和动态工作流。ultrathink 是一个单轮关键词，而 ultracode 在整个会话中保持激活。它适合"会话级重工作"，例如审计整个代码库、迁移数百个文件或高风险任务。但 token 成本会显著增加，因此判断使用场景决定了效果。
Claude Code 从在聊天中输入文字来驱动它开始，已经到达了检测事件并自主运行的系统门槛。不是人类驱动它，而是设计驱动 Claude。接下来，我们将通过所有这些功能来确认生产力差异的根本所在。
为何使用同样的 Claude Code，结果却不同
开发快的人不一定有特殊能力。他们只是更系统化地进行设计。
例如，考虑运行 /init 的情况。即使输入了相同的命令，几个月后的输出质量也会完全不同：一个每周更新的 CLAUDE.md 和一个自设置以来从未更新过的。这是因为 Claude 读取的上下文的时效性和准确性直接影响输出质量。
用厨房做类比，烹饪的水平更多地取决于厨房本身如何组织，而不是使用了哪些食材。Claude 的模型性能对所有用户是平等提供的。区别在于这三个点的准确性：上下文如何组织、指令如何系统化、自主运行如何设计。
在讨论"用哪个模型"之前，先检查一下你当前的 CLAUDE.md 上次更新是什么时候。这将告诉你当前设计的状态。
那么，实际上应该从哪里开始？在下一章，我们将整理一个分步引入指南。
从哪里开始：分步引入指南
你不必试图记住全部 27 项。
第一周，把它缩小到四个。
- 用
/init创建项目地图。 - 用
/compact定期压缩上下文。 - 用计划模式（
Shift+Tab）分离探索和执行。 - 将自我验证步骤（测试、构建）交给 Claude。
仅这四个，会话的质量就会发生根本改变。由于 Claude 在准确掌握"应该做什么"的状态下开始运转，返工的量会明显减少。
从第二周开始，在这个基础上添加委派设计。用自定义技能将指令总结为可复用的格式，用模型选择（Alt+P）调整处理的权重和速度，并养成每周更新 CLAUDE.md 的习惯。这个阶段是将指令从"每次都要写的东西"转变为"不断积累的东西"。
一个月后，进入子 Agent、git worktrees 和并行会话。你将拥有一个系统，可以在同时开发多个功能时专注于设计和确认。
ultrathink 和 ultracode 是当你遇到"真正困难的问题"时在流程中首次使用的工具。它们不是为每个问题都拿出来的工具。
通过采取这些步骤，你将从经验中理解"为什么每个功能是必要的"。请从第一周的四个项目开始。
当你把它当作设计对象时，一切都会改变
当你开始把 Claude Code 当作一个设计对象的那一刻，会话的质量就会发生根本改变。
我将本文介绍的内容总结成你可以保存和回看的形式。
/init+/compact+ 计划模式 + 自我验证这四项是最基本的基础设计。- 用自定义技能系统化指令的复用，并将
CLAUDE.md发展为每周更新的"活蓝图"。 - 当你开始使用子 Agent，生产力从加法变为乘法。
- 尽早发现偏离并立即停止是铁律。始终在第一个输出中请求证据。
- 你可以用
git worktrees+ 并行会话同时开发多个功能。 - 用
/loop设置自主运行，用远程控制从智能手机确认或指示。 ultrathink是专用于"真正困难的 10%"的工具。不是每个问题都用的。
如果你尝试了本文中提到的哪怕一个功能，你与 Claude Code 的关系就会逐渐开始改变。
对 AI Agent 感兴趣的人
Swarm (@swarm_japan) 分享关于 Agent 的重要设计理念和商业用例。
关注我们，获取 AI Agent 时代必备的商业知识 👇
★ 从独特视角解释最新 AI Agent 信息
★ 介绍 Agent 的商业用例
★ 发布原创知识
如果你感兴趣，请关注并查看我们！👀
