Dynamic Workflows 动态工作流教程：让 AI 一次派出上百个 Subagent 干重活
昨晚发布的 Dynamic Workflows，我个人觉得比单纯升级模型版本更值得关注。
原因很简单：它改变的不是“回答更聪明一点”，而是“干活方式变了”。
以前你让 AI 看一个项目，它像一个人坐在电脑前慢慢翻文件。
现在 Dynamic Workflows 更像是：你把任务丢过去，它临时拉起一支小队，几十个、上百个 Subagent 同时开工。
有的去看接口，有的去扫测试，有的去读文档，有的去找重复逻辑。
这玩意儿特别适合干重活。尤其是那种你一看就头皮发麻的任务。
比如：
- 扫完整个代码库的问题
- 整理大型项目的模块结构
- 收集大量资料并生成调研报告
- 对比多个方案的优缺点
- 把散落在各处的信息归纳成一份清晰文档
但有个关键点要说在前面：
Dynamic Workflows 更适合“分析、调研、整理、归纳”，不太适合一上来就让它大规模改代码。
别一激动直接说：“帮我重构整个项目。”
这就像让一百个人同时进你家装修。效率是高了，墙也可能没了。😂
Dynamic Workflows 到底是什么？
你可以把它理解成一种“动态并发任务系统”。
普通 AI 处理任务时，更像单线程：
看需求 → 查信息 → 推理 → 给答案
Dynamic Workflows 会先把你的任务拆开，再安排多个 Subagent 并行处理。
比如你让它分析一个代码库：
- Subagent A：扫描路由结构
- Subagent B：检查数据库相关代码
- Subagent C：分析测试覆盖
- Subagent D：找重复逻辑
- Subagent E：梳理依赖关系
- Subagent F：总结潜在安全风险
然后主流程会把这些结果汇总起来，变成一份完整报告。
这就是它厉害的地方。
不是单个 Agent 更努力了，而是它会“组织人手”。
它适合做什么？
Dynamic Workflows 最适合下面几类任务。
1. 扫描整个代码库
适用场景：
你接手一个老项目，老板说：
“你先熟悉一下，看看有没有什么问题。”
听起来轻飘飘一句话，实际可能是两周痛苦。
Dynamic Workflows 可以帮你做这些事：
- 识别项目目录结构
- 找出核心模块
- 标记高复杂度文件
- 检查重复代码
- 发现缺测试的区域
- 找出潜在风险点
- 整理成一份上手报告
你不用从 src 一路看到 node_modules 怀疑人生。
2. 生成大型调研报告
适用场景：
你要调研某个技术方案，比如：
- Cursor、Claude Code、GitHub Copilot 的差异
- React Server Components 在项目里的落地成本
- 向量数据库选型
- 多 Agent 框架对比
- 某个开源项目是否值得引入
Dynamic Workflows 可以把调研拆成多条线：
- 官方文档
- GitHub 活跃度
- 社区评价
- 性能表现
- 使用门槛
- 典型案例
- 风险清单
然后合成一份结构化报告。
如果你经常写技术选型文档，这个会很香。
3. 给大型项目做体检
你可以让它扮演“代码审计团队”。
例如：
请使用 workflow 分析这个代码库，重点检查：
1. 架构分层是否清晰
2. 是否存在重复实现
3. 错误处理是否一致
4. 测试覆盖薄弱区域
5. 潜在安全风险
6. 后续重构建议
请不要直接修改代码，只输出分析报告和优先级排序。
注意这句很重要：
请不要直接修改代码
这能明显降低它“手太快”的风险。
不太适合做什么？
Dynamic Workflows 很强，但别把它当万能锤。
下面这些任务要谨慎。
不建议直接大规模改代码
比如：
使用 workflow 重构整个项目，并直接提交所有修改。
这个提示词很危险。
并发 Subagent 多了，信息同步难度也会上升。一个 Agent 改了接口，另一个 Agent 可能还按旧接口写测试。
结果你得到的不是重构，是大型魔法现场。
更安全的做法是分两步：
请使用 workflow 分析这个项目的重构机会，只输出报告，不修改代码。
拿到报告后，再挑一个范围很小的任务：
根据刚才的报告，只重构 user-service.ts 中的错误处理逻辑。保持现有接口不变，并补充测试。
这样更稳。
不适合模糊任务
Dynamic Workflows 会拆任务。
问题是，你给的目标太糊，它拆出来也会糊。
比如：
帮我看看这个项目怎么样。
这句话太空了。
它可能从架构看到变量命名，再从依赖看到 README。最后报告很长，但你不知道该干嘛。
改成这样更好：
请使用 workflow 分析这个 Node.js 项目，目标是判断它是否适合在 3 个月内接入多租户功能。
请重点检查：
- 数据模型是否支持 tenant_id
- 权限系统是否容易扩展
- API 层是否有统一鉴权
- 测试是否覆盖关键业务
- 哪些模块改动风险最大
输出一份可执行的改造计划，按优先级排序。
目标越清楚，结果越有用。
怎么触发 Dynamic Workflows？
目前常见触发方式有两种。
方式一：提示词里带 workflow
更新后，你在提示词里写到 workflow，就可能触发动态工作流。
示例：
请使用 workflow 分析当前代码库，找出性能瓶颈、重复代码和测试薄弱区域。
不要修改文件，只输出结构化报告。
适合你想按需触发的时候。
你需要它干重活，就加 workflow。
普通小问题没必要用。
比如问一句“这个正则什么意思”，还开工作流就有点像叫搬家公司帮你挪一支笔。
方式二：开启 Ultra Code 模式
开启 Ultra Code 模式后，任何任务都会被规划成动态工作流。
适合这种情况：
- 你要连续分析一个大型项目
- 你正在做系统级代码审查
- 你需要长时间处理复杂任务
- 你希望 AI 每次都先规划再执行
但要记住：
Ultra Code 模式只在当前这次对话里生效。
如果你重启对话，系统会退回到 X-HIGH 推理模式。
所以你开了新会话，别以为 Ultra Code 还在。
要用就重新开。
推荐提示词模板
下面这些模板可以直接拿去用。
模板一：扫描代码库问题
请使用 workflow 对当前代码库做一次系统性分析。
目标：找出影响后续开发效率和稳定性的主要问题。
请重点检查：
- 项目结构是否清晰
- 核心模块职责是否混乱
- 是否存在重复代码
- 错误处理是否统一
- 日志记录是否合理
- 测试覆盖薄弱区域
- 潜在安全风险
- 依赖是否过旧或风险较高
要求：
- 不要修改任何文件
- 输出 Markdown 报告
- 每个问题给出影响范围、严重程度和建议处理方式
- 按优先级排序
适合接手老项目。
也适合团队准备重构前做摸底。
模板二：生成技术调研报告
请使用 workflow 调研以下主题：
主题：在现有 SaaS 产品中引入多租户架构的方案选择。
请从这些角度分析：
- 常见多租户模型
- 数据隔离方案
- 权限系统改造成本
- 对现有 API 的影响
- 对数据库迁移的影响
- 安全风险
- 推荐落地路径
输出要求：
- 用 Markdown 写成调研报告
- 给出方案对比表
- 标出适合小团队的低风险方案
- 给出 2 周、1 个月、3 个月三个阶段的执行计划
适合写方案、做汇报、开技术评审会。
模板三：分析开源项目是否值得引入
请使用 workflow 分析这个开源项目是否适合引入到我们的生产环境。
请重点评估：
- 项目活跃度
- 文档质量
- Issue 和 PR 响应情况
- API 稳定性
- 许可证风险
- 性能表现
- 社区使用案例
- 替代方案
输出：
- 一份结论明确的评估报告
- 风险清单
- 引入前检查项
- 推荐或不推荐的理由
别再拍脑袋引库了。
三个月后因为一个没人维护的依赖加班，真的不值得。
模板四：让它只做计划，不动代码
请使用 workflow 为当前项目制定一次重构计划。
限制：
- 不要修改任何代码
- 不要创建新文件
- 不要执行破坏性操作
请输出：
- 当前架构问题
- 重构目标
- 可分阶段执行的任务列表
- 每个任务的风险等级
- 推荐执行顺序
- 每一步需要补充的测试
这个模板很适合开会前用。
你拿着报告去讨论，比空口说“感觉这里有点乱”靠谱多了。
一套更稳的使用流程
我建议大家用 Dynamic Workflows 时按这个节奏来。
先让它看，不让它改
第一轮只做分析。
只输出报告，不修改代码。
这句话建议养成肌肉记忆。
尤其是项目比较大、业务比较重的时候。
再让它给优先级
不要只要问题列表。
问题列表太长，你看完还是不知道从哪下手。
让它给优先级：
请按 P0 / P1 / P2 标记优先级，并说明排序理由。
这样你可以立刻挑最值得处理的地方。
然后只改一个小范围
比如只改一个模块、一个文件、一类错误处理。
只处理 auth 模块中的错误处理逻辑，不要改动公共接口。
范围越小，成功率越高。
AI 写代码也是这个道理：别让它一口吞下一头牛。
改完必须跑测试
让它自己说明验证方式：
修改后请说明需要运行哪些测试，以及如何验证没有破坏现有行为。
如果项目里有测试命令，也可以直接写清楚：
修改后请运行 npm test，并修复本次改动引入的问题。
别让 AI 写完就跑。
你得让它对结果负责。
避坑清单 ⚠️
坑一：把 workflow 当成万能加速按钮
不是所有任务都需要 Dynamic Workflows。
小任务用它，反而可能让流程变重。
适合用：
- 大项目分析
- 大量资料整理
- 多角度调研
- 系统性审查
不适合用：
- 单个函数解释
- 小 bug 修复
- 简单文案润色
- 几行代码生成
坑二：不给边界
不要这样写：
用 workflow 优化我的项目。
太危险。
改成：
用 workflow 分析项目中影响构建速度的因素，只输出报告，不修改代码。
边界越清楚，输出越稳。
坑三：让它直接动核心代码
核心支付、权限、数据迁移、账号系统这些地方，别一上来就让它改。
先分析。
再拆小块。
再补测试。
成年人写代码，命可以苦，回滚不能慌。
坑四：忘了 Ultra Code 只在当前对话生效
Ultra Code 不是永久开关。
你重启对话后，会退回到 X-HIGH 推理模式。
如果你发现新会话里它不像刚才那样会规划工作流，别怀疑人生。
重新开启就行。
适合团队落地的用法
如果你在团队里用，可以把 Dynamic Workflows 固定成几个流程。
代码评审前
让它先扫一遍 PR 或模块：
请使用 workflow 分析本次变更的风险点，只输出审查建议，不修改代码。
你再去 Review，效率会高很多。
不是让 AI 替你拍板，而是让它帮你把角落扫干净。
重构前
让它生成重构地图：
请使用 workflow 分析当前模块的重构路径，要求按风险从低到高排序。
这样团队不会一上来就动最危险的地方。
技术选型前
让它生成方案对比：
请使用 workflow 对比 A、B、C 三个方案，输出成本、风险、维护难度和推荐结论。
开会时直接拿表格讨论，少一点玄学，多一点证据。
你可以记住这句话
Dynamic Workflows 不是“更会聊天的 AI”。
它更像一个会临时组队的执行系统。
用得好，它能帮你把一天的代码库摸底压到一杯咖啡的时间。
用得猛，它也可能把任务拆得太散，让结果失控。
最稳的姿势就三句话：
使用 workflow。
只分析，不修改。
输出优先级和可执行计划。
先让它当侦察兵。
别急着让它当施工队。
这就是 Dynamic Workflows 最值得上手的地方。
