为什么你一直在用 Claude Code，却可能错过了它最值钱的功能 – Workflow

你大概率已经在用 Claude Code 写代码了。但你有没有这种感觉——让它干一个复杂任务，聊着聊着就跑偏了，或者明明要检查 50 个东西，它查了 30 个就说「搞定了」。

不是 Claude 不行，是默认模式下它只有一个脑子。

Claude Code 最近出了一个东西，就是来解决这个问题的。不是新模型，不是新界面，是一个叫 Workflow 的机制——让 Claude 自己写脚本，拆任务，同时派出几十个子助手干活，互相检查，最后把结果汇总交给你。

这篇文章就是告诉你：它到底能干什么，6 种最实用的模式拆开讲，以及什么时候该用它、什么时候别用。

先看它能干什么

以下是 Workflow 能直接处理的几类典型任务（复制提示词就能试）：

• 让多个理论互相竞争，解决那些时好时坏的 flaky tests（不稳定测试）
• 从你过往的聊天记录里，挖出反复出现的错误并纠正
• 在 Slack 的事故频道快速定位问题根源
• 为一份商业计划书，从多个不同角度收集批评意见
• 给简历排序并验证
• 用「锦标赛」方式，为一个命令行工具起最好的名字
• 对整个代码库进行大规模重构
• 检查博客草稿里的技术说法是否和实际代码一致

从写代码、做研究、审阅文档，到商业决策和问题排查——Workflow 能覆盖的面比想象中大得多。

为什么默认的 Claude Code 不够用？

默认模式下，Claude Code 在一个上下文窗口里同时规划和执行。问一个问题、改一个文件、跑一个命令——这种简单任务没问题。但任务规模一上来，三个问题会反复出现：

偷懒。 你让它审查 50 项安全问题，它可能做到第 35 项就说「搞定了」，剩下 15 项直接被跳过。不是故意的——是上下文太长，它管不住了。

自我偏袒。 自己写的结论自己检查，给高分是大概率事件。同一个脑子既当运动员又当裁判，查不出什么真正要命的问题。

目标漂移。 长对话跑到后面，最初的指令细节被越推越远。聊着聊着就忘了最开始到底要干什么。

Workflow 的解决思路是：不要让一个脑子干所有事。让 Claude 动态写一个脚本，把任务拆成独立子任务，每个子任务分配给一个独立的子助手（subagent）。每个子助手有自己的上下文空间，只专注一件事。最后汇总检查。

效率更高，质量更稳——而且不会漏。

Dynamic Workflow 和以前的 Static Workflow，差在哪？

在 Workflow 之前，如果你想做类似的多助手协作，需要自己提前写好一个固定的工作流脚本（static workflow）。每一步做什么、什么顺序、怎么判断分支——全是硬编码的。换一个任务，脚本就得重新写。

Dynamic Workflow 把这个过程倒过来了：你不用写脚本，你只需要描述任务。Claude 根据你当前的具体需求，现场生成一个定制脚本——怎么拆、怎么并行、怎么验证、什么时候停，它自己判断。

一句话说：以前是你给 AI 写操作手册，现在是 AI 给自己写操作手册。

这个差别直接决定了你愿不愿意用。Static workflow 需要学、需要维护、需要调试——大部分人不碰。Dynamic workflow 只需要一句话——门槛直接消失。

6 种核心模式

模式 1：分类并执行

先判断任务属于哪种类型，再自动派给最合适的子助手处理。

比如你丢给它一堆 issue——有的是 bug、有的是功能需求、有的是文档问题——Workflow 先分类，然后不同类型走不同的处理管道。你不需要自己筛。

模式 2：扇出并综合（最常用）

把一个大任务拆成多个小块，并行分给不同助手同时做，最后统一汇总。

典型场景：代码审查。不是让一个助手从头看到尾，而是同时派出「安全检查」「性能检查」「逻辑检查」「风格检查」四个助手，各自独立审查同一个文件，最后合并成一份报告。速度更快，每个维度的质量也更高——因为每个助手只盯一件事。

模式 3：对抗式验证

一个助手出结果，另一个助手专门挑刺——被设计成默认质疑前一个助手的结论。

这直接解决了默认模式的「自我偏袒」问题。一个助手说「这段代码没问题」，验证助手收到的提示是：「前面的结论可能是错的，尽量找出反例」。两个脑子互相制衡，置信度高了一个量级。

模式 4：生成并筛选

先生成大量想法或方案，再派另一个助手按标准筛选和排序。

适合「需要很多创意但不能每个都做」的场景——为一个产品起名、为一篇文章选标题、为一个架构选技术方案。先铺开数量，再用标准收敛质量。

模式 5：锦标赛模式

几个助手用不同方法独立解决同一个问题，最后比较结果，选最优方案。

和「生成并筛选」的区别：锦标赛的每个参赛者都在完整解决问题，而不只是给建议。适合答案高度依赖方法选择的任务——算法优化、架构设计、文案策略。

模式 6：循环至完成

不知道要跑多少轮，就一直跑——直到没有新发现、没有新错误为止。

经典场景：bug 发现。第一轮找出 10 个 → 修复 → 第二轮又发现 8 个 → 再修复 → 第三轮只发现 1 个 → 再跑一轮，没新东西，自动停止。你不会因为「助手累了」而漏掉 bug。

实际可以怎么用？

代码迁移与重构。 把 Python 代码改成 TypeScript，或把一个单体服务拆成微服务——Workflow 可以并行处理多个文件，每个文件独立转换，转换完再派验证助手交叉审查。比一行一行手动改写效率高一个量级。

深度研究。 不是让一个助手搜 20 个网页然后总结。而是同时派出多个助手，各自搜索不同角度、不同关键词，抓取原文，交叉验证观点，最后出一份带引用的综合报告。信息的广度和可信度都高得多。

大规模排序与评估。 200 个 bug 按严重程度排序——一次性塞进去 AI 根本处理不了。Workflow 用锦标赛模式分批对比：先 10 个一组内部排序，再组间交叉对比，最后得出靠谱的全局排序。

规则提炼与记忆。 从你过往的聊天记录里提取反复出现的问题和你的偏好，生成规则文件，然后自动验证这些规则在真实场景下是否有效。相当于让 AI 帮你复盘自己的使用习惯。

内容分类与 triage。 自动把信息条目按类型分流处理——客服工单、用户反馈、数据异常——不需要人手动分拣。

设计决策与命名。 需要「品味」的任务，Workflow 特别适合。让多个助手从不同角度提案，再派审查助手按预设标准打分。不是拍脑袋，是有竞争的方案比较。

什么时候不该用 Workflow？

Workflow 不是免费的。每次创建子助手都消耗 Token，大面积并行 = Token 消耗面积大。

适合用： 任务足够复杂、步骤足够多、一个人工检查不过来、结果质量比成本重要。

不适合： 问一个简单问题、改一行代码、日常小任务。这类事情默认模式更快更省钱——大炮打蚊子不划算。

怎么开始？以及三个实用技巧

最直接的方式：对 Claude Code 说「我需要一个 Workflow 来……」，描述你要做的事。它自己判断怎么拆、怎么并行。

或者在提示里加上 ultracode 这个词，引导它进入 Workflow 模式。

Thariq 的分享里还提到了几个进阶用法，这里单独拆开说一下：

给 Workflow 设 Token 预算上限。 工作流会消耗 Token，如果不设上限，一个复杂任务可能跑掉大量配额。在启动 Workflow 时可以指定预算（比如 +500k），Claude 会在预算内动态调整并行规模——预算少就少开子助手，预算充足就全力并行。

把好用的 Workflow 脚本保存下来。 每次 Dynamic Workflow 运行完后，脚本会自动保存。如果你发现某个 Workflow 模式反复用到（比如代码审查、bug 排序），下次可以直接复用，不需要重新生成。

配合 /goal 和 /loop 使用。 把 Workflow 嵌入到更上层的自动化流程里——比如用 /goal 定义目标、用 /loop 设定执行频率、用 Workflow 做每次循环的具体执行。三个指令组合起来，就是一套轻量级的 AI 自动化管道。

有 Claude Code 环境的读者可以直接试。光看不如跑一遍。

我的一点看法

Claude Code 的 Workflow 更新，让 AI 从一个「单线程助手」变成了一个「能自己组团队、自己管流程的项目经理」。

以前那些一个人 + 一个 AI 搞不定的复杂脑力活——大规模审查、多角度分析、跨文件重构——现在有了一个可行的解法。不是换了一个更强的模型，是换了一种更聪明的工作方式。

（本文基于 Anthropic 核心员工 Thariq 的分享整理。）

✅ 看完这篇文章，你搞清楚了这几件事

• Workflow 解决了默认 Claude Code 的三个核心问题：偷懒、自我偏袒、目标漂移
• Dynamic Workflow 和 Static Workflow 的本质区别——以前是你给 AI 写操作手册，现在是 AI 给自己写
• 6 种模式的各自适用场景，以及什么时候该用、什么时候不该用
• 拿到了 8 个可以直接复制提示词去试的真实例子
• 知道了怎么开始，以及 Token 预算、脚本复用、指令组合三个进阶技巧