围绕交付物和依赖拆分并行智能体工作
本文目录
CueSpec 工作流编辑组撰写 · AI 辅助团队编辑。
围绕能够独立完成和检查的产物拆分并行工作。为每项任务指定必需的输入、由其负责的输出，以及下游工作可以开始的具体条件。这样，即使用普通笔记协调，而不使用智能体调度器，工作依赖图也能发挥作用。
第一轮先写清四件事：什么必须先决定，随后哪些工作可以独立推进，哪些文件需要共享，以及谁来整合结果。
一项功能变更，拆成四个任务
设想一个虚构项目，要为文章列表增加分类搜索。功能应在选定分类内匹配文本，保留条目的原始顺序，并提供有用的空状态。下面的示例是一项规划练习，不是智能体实际运行的报告，也不是经过测量的交付排期。
输出契约由一个小型查询对象和有序结果组成：
Query v1
- text：字符串；去除首尾空白
- category：分类 ID，或 "all"
搜索行为
- 将去除首尾空白后的查询与文章标题匹配，忽略 ASCII 字母大小写。
- 空文本表示不限制文本。
- category="all" 表示不限制分类。
- 保留输入条目的顺序。
结果条目
- 保留各条目的 id、title 和 category。
- 视图自行提供无结果时的提示。
这个契约为匹配模块和视图提供了共同的实现依据。它有意将搜索文章正文、按相关性排序等产品问题排除在本次变更之外。
画出工作依赖图
flowchart LR
A["A · 契约和共享样例"] --> B["B · 匹配模块"]
A --> C["C · 搜索控件和状态"]
B --> D["D · 整合与组合检查"]
C --> D
箭头表示必需的输出。A 的产物可用后，B 和 C 可以同时推进。D 可以提前准备检查清单，但只有两个实现产物都已存在，才能检查整合后的功能。
GitHub 的任务范围指南建议提供清晰的问题描述、验收条件和相关文件指引。以下任务卡将这一思路用于这项虚构功能；它们不预设某个平台的并发能力或权限。
为每项任务指定其负责的产物
| 任务与角色 | 输入 | 负责交付的产物 | 满足何种条件后可供下游使用 |
|---|---|---|---|
| A：契约编辑 | 功能目标和现有条目结构 | search-contract.md 和一份共享样例数据 |
查询字段、空输入规则、顺序和样例预期 ID 一致 |
| B：匹配模块实现者 | 已接受的 Query v1 和样例数据 | search-items.js，以及拟议检查 |
能处理契约中的情形，并说明确切改动和检查结果 |
| C：视图实现者 | 已接受的 Query v1 和样例数据 | 搜索控件、空状态和视图专属检查 | 能输出约定的查询结构，并处理已定义的结果状态 |
| D：整合者 | B、C 的确切交付版本，以及 Query v1 | 组合改动、共享配置和整合记录 | 匹配模块与视图能够按照同一契约和选定检查协同工作 |
用角色标签明确责任；实际团队可以将它们分配给人或智能体。共享入口和配置由 D 负责。如果 B 或 C 发现必须修改共享文件，应在交付中附上提案，避免双方都去覆盖该文件。
一份小型共享样例，可以让“符合契约”变得可检查：
条目，按以下顺序：
1. id=a, title="Voice drafts", category=guide
2. id=b, title="Draft review", category=reference
3. id=c, title="Keyboard notes", category=guide
Query v1 下的预期示例：
text=" draft ", category=all -> [a, b]
text="", category=guide -> [a, c]
text="DRAFT", category=reference -> [b]
text="absent", category=all -> []
这些是根据虚构规则推导出的预期答案，不是已记录的测试结果。
复制一张任务卡
任务与负责角色：
必需输入及版本：
由本任务负责的一项交付物：
本任务可以修改的文件：
需要向整合者提议修改的共享文件：
本次交付需要的检查：
实际检查结果，或明确注明未运行：
确切交付版本的引用：
使用该交付物的下游任务：
可能改变契约的未决问题：
任务结束聊天是一项沟通事件。交付物是否可用则是一项产物判断：使用方能够找到预期版本，理解其内容，并检查相关条件。
例如，如果交付中将 category 改名为 categoryId，仅说“匹配模块完成”就不够。C 可能已经按约定输出原字段。在要求 D 合并双方产物之前，先解决这一契约差异。
修正过度并行的计划
一种欠妥的计划会让四项任务立即全部启动。B 自行设计查询字段，C 设计另一种结构，而双方仍在改变假设时，D 就开始修改共享配置。更多同时进行的活动，带来了更多协调工作。
修正后的顺序如下：
| 阶段 | 有用的工作 | 启动条件 |
|---|---|---|
| 1 | A 定义 Query v1 和样例；D 准备整合问题 | 已理解功能目标 |
| 2 | B、C 分别实现各自的输出 | A 的契约和预期情形一致 |
| 3 | D 整合确切交付版本 | B、C 明确指出相互兼容的产物及其实际检查状态 |
| 4 | 相关负责人处理组合检查发现的问题 | 已识别具体不一致或失败 |
这是一条依赖顺序，不是工期承诺。如果匹配模块和视图必须反复协商接口，难以分开推进，那么交给一个任务顺序完成，可能更容易收尾。
明确处理契约变化
假设分类搜索现在需要支持多个分类。记录 Query v2 提案，并指出它影响 B、C 的哪些工作。决定先完成 v1，还是同时修订两边的交付物。下游仍在工作时悄悄修改共享笔记，会让依赖图失去可靠性。
在稳定输入允许分别推进的地方使用并行。将工作依赖图控制在足够小的范围，使每一条箭头都指向真实产物；让最后一项任务负责检查组合结果，而不是把各方的成功消息相加。