任务、计划、迭代和工作流

Coroid 包含四种工作单元。它们可以相互嵌套，选择恰当的单元主要取决于工作的规模以及需要同时执行的工作量。

任务#

最基本的单元。一个任务是一个可产出单个 pull request 的工作单元，也是实际被执行的内容——计划、迭代和通道都是组织任务的方式。

如果你能用一段话描述出结果，且审核人员能一次性读完相关内容，那它就是一个任务。

计划#

当工作需要按特定顺序进行多次变更时，就会形成计划：即按阶段分组的有序任务集合，在编写任何代码前需先获得审批。

以下情况可使用计划：

• 后续步骤依赖前期步骤的输出
• 你想在确定实施方案前先了解整体思路
• 该项工作是功能开发而非简单变更

审批计划是系统中成本最低的干预节点。在此阶段否决方案仅需花费一分钟；若三个任务执行完毕后再否决，则需重复三次操作。

计划如何进入你的代码库#

计划的各任务不会分别生成单独的 pull request。它们会在各自的分支上工作，然后合并到共享的通道分支，该分支会被提升为针对你的基准分支的单个拉取请求。

task branch ─┐
task branch ─┼─► lane branch ─► one pull request ─► main
task branch ─┘

因此你只需审核一次整合后的完整功能，无需逐个审核未完成的阶段。

例外情况是跨多个项目的工作：属于不同项目的任务会在各自的通道中推进，因此跨项目计划会为每个代码库生成单独的 pull request。这是不可避免的——一个 pull request 无法跨越两个代码库。

迭代#

迭代是限定时间的工作容器，拥有独立的指标和时间线。迭代用于回答“本周期内我们要做什么、进展如何”，而非“该功能如何构建”。

当你需要协调团队在一定周期内的工作时可使用迭代；分解单个功能时使用计划。二者并非互斥选项——一个迭代可包含属于多个计划的任务。

通道#

通道是计划并行工作的集成位置。任务以通道的分支为目标，而非你的基准分支，因此多个智能体可同时推进而不会发生冲突，一旦符合条件，整合后的结果就会被提升为单个 pull request。

计划关注的是顺序，通道关注的是并发和集成。如果你有充足的智能体资源且工作无需严格串行执行，通道就能让它们协同运行，最终仍输出为可审核的单一变更。

如何选择#

关键不在于你想要多少个拉取请求——任务和计划最终都会生成一个拉取请求。关键在于结果值得审核前需要完成多少工作量。

1. **这项变更是否能让审核人员一次性读完？**是 → 任务。
2. **它是否需要按顺序进行多次变更才能形成完整的功能？**是 → 计划。其通道会在允许的情况下并行处理各部分工作。

迭代作为规划和报告层，与上述机制并行运作。

限制同时运行量的因素是什么#

并非结构本身，而是处理能力。若一个包含十个可并行任务的计划只有单个智能体插槽，它会依次执行这些任务。详见处理能力和智能体插槽.

相关主题#

• 规格说明
• 质量门控