AI 全栈 on 姚玉亮的网络日志

Claude Code 的 Workflow 功能：6 任务分 4 波，多 Agent 并行开发三端功能

Thu, 27 Aug 2026 22:30:00 +0800

一个 141 行的脚本，指挥一群 AI 干活

炼丹炉（Alchemy Furnace，我的开源项目）最近在做一个大功能：女娲蒸馏的范围收紧 + Skill 导出。它横跨三个端（Next.js 前端、Go 网关、Python 引擎），拆出来 6 个开发任务，有依赖、有先后、还要并行。

我用的方案是 Claude Code 的 Workflow 功能：写一个 141 行的 mjs 脚本，把 6 个任务分成 4 个波次，每波派多个 AI Agent 并行干活。脚本开头长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


export const meta = {
 name: 'nuwa-scope-skill-export',
 description: '按计划实现女娲炼丹范围收紧 + Skill 导出（6 Task 分波并行）',
 phases: [
 { title: 'Wave A: 并行底座', detail: 'Task1 前端入口 + Task2 Python 链路 + Task3 Skill 渲染器' },
 { title: 'Wave B: 服务端接合', detail: 'Task2b Go/前端错误透传 + Task4 导出接口' },
 { title: 'Wave C: 前端导出 UI', detail: 'Task5 详情导出对话框' },
 { title: 'Wave D: 端到端验收', detail: 'Task6 全量回归与修复' },
 ],
}

Workflow 的编排原语就几个：agent() 派一个 Agent 做一件事，parallel() 并行跑一组，pipeline() 流水线，phase() 分阶段。流程是确定性的（脚本写死的），干活是并行的（agent 同时跑）：确定性编排 + 并行吞吐，这就是 Workflow 和"让 AI 自由发挥"最大的区别。

分波设计：依赖关系决定顺序

6 个任务不是一把梭全并行，它们之间有依赖。分波的核心原则：同一波内的任务互不依赖且文件隔离，波与波之间靠产物衔接。

Wave A 三个任务互不依赖：前端改入口、Python 改链路、Python 写渲染器，改动文件完全不重叠，并行跑。Wave B 接合服务端：错误透传要读 Task2 的产物（Python 结构化错误），导出接口要调 Task3 的渲染器，等 A 波完成再动。C、D 依此类推。

多 Agent 协调的六个细节

分波只是骨架，真正让 6 个 Agent 不打架的是这些细节：

COMMON 纪律注入。每个 Agent 的 prompt 都是 COMMON + TASK + 终止条件 三段拼起来的。COMMON 里写死硬约束：TDD 先红后绿、只改自己任务列出的文件、提交格式 type(scope): 中文描述、绝不 git add -A、绝不提交 docs/superpowers/ 和 specs/ 等元文档、i18n 必须中英双语、测试命令、凭据保密。纪律写进 prompt 而不是靠自觉，6 个 Agent 才不会互相污染。
文件隔离 + 以磁盘为准。每个任务只允许碰自己的文件，但并发任务可能改到同一文件，所以约束里有一条：“编辑前先 Read 磁盘最新内容，不要基于记忆”。并行和踩脚之间的平衡，靠这条纪律兜底。
依赖确认靠 git log。Wave B/C 的任务 prompt 里写着：“先 git log 确认依赖任务已完成，并读它的接口签名再动手”。Agent 之间不通信，通过提交记录对齐。
终止条件。每个任务都附一段 A3：文件不存在或结构差异巨大、关键依赖无法确认、测试连续 3 次修复失败，立即停止并报告，不许硬撑。这防止 Agent 在不确定的情况下编造"成功"。
TDD 是硬约束。每个任务第一步都是"写失败测试 → 跑红 → 最小实现 → 跑绿"。6 个 Agent 并行写代码，质量一致性靠测试框架兜底。
进度可视化。每波完成打一条 log()：task1=ok task2=FAILED，失败的任务肉眼可见，可以在下一波前人工干预。

三端是怎么被协调的

这个功能本身横跨三端，Workflow 的波次刚好和端的分工对齐：

端	技术栈	对应的任务
前端	Next.js	Task1 收紧女娲入口、Task5 导出对话框
Go 网关	Gin + GORM	Task2b 错误透传、Task4 导出接口
Python 引擎	FastAPI	Task2 蒸馏链路、Task3 Skill 渲染器

有意思的是 Python 端同时有 Task2 和 Task3 两个并行 Agent：它们文件不同（链路 vs 渲染器）所以不冲突，但同端并行也要求 prompt 里把边界写得特别清楚：“不要碰 backend/go/ 与 frontend/ 的 UI 文件——那些由另一任务负责”。

复盘：Workflow 教给我的

复杂功能先拆波再并行，依赖决定顺序。先画出任务依赖图，互不依赖的并行，有依赖的排波次。比"一个 Agent 从头做到尾"快得多，比"全并行"稳得多。
纪律要写进 prompt，不是靠提醒。提交纪律、文件边界、TDD、终止条件，每一条都防止一种 Agent 翻车方式。
终止条件比任务本身重要。允许 Agent 说"我卡住了"，比让它硬编一个成功报告安全一个量级。
上下文隔离是并行的前提。每个 Agent 只拿自己的任务片段，看不到其他任务的 prompt：专注 + 不越界。

这个脚本不是银弹：它适合任务边界清晰、文件可隔离、有测试兜底的场景。如果任务互相纠缠，先拆任务再谈并行。项目、计划文档和完整脚本都在 GitHub 上，Wave A 的并行底座写法可以直接抄。

封面图：richard_clyborne / Flickr · CC BY 2.0

一次聊需求，三仓同落地：我的 superpowers 全栈开发工作流

Thu, 27 Aug 2026 09:00:00 +0800

一个跨三个仓库的需求

我最近接到一个挺典型的需求：数据集管理里，“文档核验"这个动作要留痕：谁核验的、什么时候核验的；核验完还要能按数据集分页翻历史记录；管理后台加一个"核验记录"入口，点击弹列表，下拉就能一直加载；上层的知识库问答服务也要同步暴露这个列表接口。

这个需求横跨三个仓库：数据集管理服务、数据管理后台、知识库问答服务。

以前这种需求在我这儿是这么过的：拉群对齐需求 → 各写各的需求文档 → 前后端各自开工 → 联调时发现字段名对不上、分页参数叫法不一样 → 返工。现在我用 Claude Code 的 superpowers 工作流走了一遍完整流程，发现整个链条可以压缩成四步：brainstorming 聊需求 → 方案对比 → 写 spec → 生成实施计划。

flowchart LR
 A["brainstorming 聊需求"] --> B["方案对比"] --> C["写 spec 落盘"] --> D["生成实施计划"] --> E["add-dir 挂三仓并行落地"]

第一步：先探索代码，再开口问

superpowers 的 brainstorming 第一步不是问"你想要什么”，而是先看项目上下文：路由注册在哪、handler 怎么写的、DAO 用的什么 ORM、前端页面结构、有没有现成的分页组件。

我让 Claude 把两个仓库都翻了一遍，结论：

数据集管理服务是 Hertz + GORM 的架构，核验逻辑在文档服务的 revise 方法里，文档表上已经有一个"核验状态"字段，核验时会把它置为"已核验"
管理后台是 React + antd，代码里已经有现成的 useInfiniteScroll 下拉加载 hook，数据详情页结构也很清晰

这一步的价值在于：问题基于真实代码，而不是基于想象。我不用花十分钟给 Claude 讲架构，它自己读出来的上下文，比任何人的转述都准确。比如"核验状态字段已经存在"这个事实，直接影响了后面的设计：记录表和状态字段是两回事，但很多人第一版设计会混在一起。

第二步：一次只问一个问题

brainstorming 最反直觉的一条规则是：一次只问一个问题。

我一开始也觉得慢。但跑下来发现，需求是逐层展开的：先问"核验记录需要存哪些字段"，确定存核验人和核验时间；再问"列表按什么过滤"，确定按数据集 ID；再问"前端入口放在哪"，确定放数据详情页。每个答案都会修正下一个问题，一次抛十个问题，模型只能靠猜排优先级，猜错一半就得返工。

对话节奏大概是这样的（简化示意，实际要比这细致）：

我：核验记录需要展示哪些字段？ Claude：先确认一下，除了核验人和核验时间，要不要把核验前后的版本号也存下来？这会决定表结构。我：先只存核验人和核验时间，跑通第一版。 Claude：好。那列表接口按数据集 ID 过滤、支持分页返回，这个方向对吗？

一次一个问题看着慢，其实最快：每个问题都建立在之前答案的基础上，方向不会歪。

第三步：给 2-3 个方案，而不是直接开写

需求聊清楚之后，brainstorming 会要求给出 2-3 个实现方案对比。这个需求当时有两个主流方案：

方案 A：复用现有的行为记录表。那张表是 JSON 半结构化的流水表，加一种行为类型就能记录，不用建新表。
方案 B：新建独立的核验记录表。字段干净，查询直接，列表接口就是一条简单的 WHERE dataset_id = ? 分页查询。

我选了 B。核验记录是高频查询的业务动作，独立表让列表接口简单直接；方案 A 虽然少建一张表，但查列表要拆 JSON，而且行为流水表的数据量会持续膨胀，不适合做业务查询的底座。

选完方案，设计按块确认：表结构一块、接口定义一块、前端改动一块、上层同步一块，确认完再写进 spec 文档，落盘到 docs/superpowers/specs/ 目录下。这份文档是后续实施计划的输入，也是代码评审时对照的依据：评审不再靠记忆，而是对着 spec 逐条核对。

第四步：add-dir 多项目，前后端同时动

设计获批后进入实施阶段。Claude Code 的 add-dir 可以把多个项目目录加进同一个会话，这个需求一次挂了三个目录：

数据集管理服务：建表、在核验接口里写记录、新增分页列表接口
管理后台：数据详情页加入口、列表抽屉、下拉加载
知识库问答服务：同步暴露列表接口

多目录的意义不只是"能改多个仓库"，而是 AI 同时持有两边的上下文：字段名、接口路径、分页参数天然一致，联调成本趋近于零。以前前后端联调要查半天"到底叫 page 还是 current"，现在在计划阶段就把契约定死了，代码照着写就行。

几个真实的感受

一次一个问题反直觉，但确实是最快的提问方式。需求是逐层展开的，一次一个才能保证每个问题都有价值。
探索比提问重要。让 AI 先读代码，它问出来的问题才有质量；不探索就问，问的都是网上搜得到的通用问题。
设计文档不是走流程。跨仓库改动里，它是唯一让所有人（包括几周后的你自己）对齐的锚点。代码评审对着 spec 审，比对着记忆审靠谱一个量级。
YAGNI。AI 很容易过度设计，比如顺手提一句"要不要顺便做个操作审计"。不需要，砍掉。每个设计阶段都要主动问：这个功能现在真的需要吗？

建议

如果你也在用 AI 写代码，别只停留在"让它写函数"的层面。试试把流程也交给它：从一个小需求开始，完整走一遍 brainstorming → 方案对比 → spec → 计划 → 实现。第一次会不习惯"一次只问一个问题"，但跑完一个需求你就会发现，多花在澄清上的半小时，会在联调阶段加倍省回来。