哪些活，该交给Claude Code的 /workflows?
Claude Code 的 /workflows 功能，正在把那些需要大量人力或复杂编排的任务变得轻松可解，AI 的“体力”不再成为瓶颈。
上周，随着 Opus 4.8 的发布，Claude Code 迎来了一次重要更新，其中 /workflows 这个新功能相当有意思。
前几天在征集 /workflows 使用场景时，刘润老师微信私聊了一些截图，他用 Claude Code /deep-research（其实背后也是 /workflows）做调研报告，效果相当不错——同时开启了一百多个 Agent，分工明确，各司其职，井然有序。
这给了我们一个很直接的启发：
是否存在一些让 AI Agent 过去完成得比较勉强的任务，借助 /workflows 就可以显著提升完成质量？
如果存在这样的场景，它们应该符合两个条件：
- 1M 上下文不够用，借助 /workflows 能自动规划「到底需要多少个 Agent」，同时解决「装不下」的问题和「懒得编排多Agent分工」的问题。
- 任务可以大规模解耦，让串行变成并行。
做了两天的实验，两天就消耗完了 Claude Code 20x Max 的周限额——/workflows 烧 Token 确实挺猛，好在凌晨重置了限额。
是时候把这两天的心得梳理出来了。
/workflows 如何高效找出并修复“陈年老bug”
先说个最让人惊喜的场景。
让 /workflows 去扫代码库，找那种“低风险、能放心修”的陈年老 bug。
那种 bug 大家都懂——
不致命，不紧急，但你心里清楚它在那。
每次路过那段代码都心虚，但永远不可能专门花一下午去修。因为风险在那——万一改了一个，崩了三个呢？
于是就这么“陈”着。一年，两年。
这次完全不同。一个 /workflows 扔进去，它自己把代码库切成 12 个区，31 个 agent 同时扫，一批找、一批挑刺，置信度不够的直接扔掉。
两个小时后，甩出来一份清单。
看了一遍——确实是那种“明显该修但一直没人修”的陈年老 bug 集群。
那一刻的感受是：这些破玩意儿，终于有人替我们翻出来了。
结合 /deep-research 解决难题，打破信息茧房
接着又试了个完全不同的活儿：「我这个难题，别人一般如何解决」。
这个思路来源于刘润老师的实践。
如果只用 /workflows，可能陷入信息茧房。
如果只有 /deep-research（Claude 网页版已有此功能），则无法读取当前代码库。
最佳方案是：
遇到难题时，同时用 /workflows 和 /deep-research
如下图所示，一句话开启了 105 个 Agent。
最终效果非常出色，值得一试。
/workflows 的核心价值：将串行任务并行化，突破 AI 体力限制
试玩之后继续思考：/workflows 到底带来了什么？
想来想去，就一句话——
很多时候，AI 的智力水平早就超配了，瓶颈是体力不足。
一个再聪明的人，也读不完整个代码库——不是脑子不行，是装不下。
一个再能干的人，也没法同时改五十个文件——不是手不快，是只有一双。
/workflows 并不会让 Claude 变得更聪明，它让 Claude 变得更"多"。
所以，判断一件活适不适合 /workflows，就问自己一句：
这是个“智力问题”，还是个“体力问题”？
需要灵光一闪、需要连贯品味的——那是智力问题。
但凡“一个聪明人嫌烦，五十个普通人分头干就能干完”的——那是体力问题，这种情况下，放 /workflows 出去，甚至叠加 /deep-research，双重 buff，又快又好。
这可能是 AI Agent 工具的一个新趋势：它不是在让已经很天才的 AI 变得更加天才，而是让 AI 更适合做苦活累活。
