跳到主要内容

任务描述与团队编排写法

CountBot 的重点不是“把一句提示词写得更花”，而是把任务、角色、团队和执行路径写清楚。
本页说明怎样写任务描述，什么时候该用团队，以及怎样选择 pipeline、graph、council 三种模式。

先判断是不是需要团队​

并不是所有任务都适合多成员协作。

适合单角色直接处理的任务：

  • 简单问答
  • 单文件修改
  • 一次性配置查询
  • 明确输入、明确输出、无明显分工的工作

适合团队处理的任务：

  • 需要拆分为多个阶段
  • 需要不同角色视角
  • 需要评审、复核或交叉审查
  • 需要并行节点或条件分支

判断标准很简单：
如果“一个人做完更快更清楚”，就不要为了显得高级而强行上团队。

一个完整任务应写清哪些信息​

在 CountBot 中，好的任务描述至少要包含五项：

  1. 目标 最终要交付什么。
  2. 输入材料 当前能提供什么文件、页面、配置或背景。
  3. 约束条件 不能做什么，或必须遵守什么。
  4. 交付格式 最终结果希望如何呈现。
  5. 完成标准 什么情况下算完成。

例如：

请审查 website 目录中的官网文案与文档入口。
输入材料是当前仓库代码和现有页面内容。
约束条件：保持正式风格，不夸大未实现能力，不改动后端代码。
交付格式：直接修改文件，并给出变更说明。
完成标准：官网首页与文档入口一致，文档站可重新构建通过。

这类描述比“帮我完善一下官网”稳定得多。

三种团队模式怎么选​

CountBot 当前支持 pipeline、graph、council 三种团队模式。

pipeline​

按固定顺序执行，适合线性流程：

  • 需求整理 → 实现 → 审查
  • 调研 → 起草 → 校对
  • 收集材料 → 生成方案 → 复核结论

当任务天然有前后顺序时，优先选 pipeline。
它最容易理解，也最容易维护。

graph​

按依赖关系和条件流转，适合较复杂的工作流：

  • 多个节点并行收集材料
  • 某节点通过后才进入下一步
  • 某类条件满足时触发额外分支

只有在确实存在分支和依赖时，才值得用 graph。
否则会增加配置成本。

council​

多个成员并行给出判断，再统一汇总，适合：

  • 多视角分析
  • 争议问题评审
  • 风险讨论
  • 方案比选

如果任务本质上需要“不同角色各说一遍，再汇总”，council 最合适。
但如果只是流水线式分工，不要误用 council。

团队成员如何拆分​

一个成员最好只承担一种主职责。
推荐按“产出物”拆，而不是按“形容词”拆。

好的拆分方式：

  • Planner：拆解任务与交付物
  • Implementer：完成实现
  • Reviewer：识别风险与回归

不好的拆分方式：

  • 高级专家
  • 资深专家
  • 超级专家

如果三个成员都只是语气不同，团队配置没有实际价值。

role、task、system_prompt 如何配合​

推荐分工如下：

  • role 角色名称，用于表达成员身份。
  • task 该成员本轮最核心的工作内容。
  • system_prompt 该成员长期稳定的工作方式、边界和输出要求。

例如：

{
  "id": "planner",
  "role": "Planner",
  "task": "将需求拆分为可执行步骤并定义交付物",
  "system_prompt": "你负责把复杂任务拆成可执行步骤，明确每一步所需输入、输出和依赖关系。不要直接产出最终内容，不代替实现成员写代码或写文案。"
}

这比只写一句“你是规划专家”更有效。

怎样写可执行的团队任务​

1. 任务目标要可交付​

不推荐：

研究一下这个项目，看看怎么优化。

推荐：

审查官网首页与文档结构，补齐错误入口，重写两篇不贴合当前产品的文档，并确保文档站可以重新构建。

2. 明确哪些材料是可信输入​

如果任务只能根据仓库代码、当前页面和本地配置来做，就应明确写出。
否则成员可能会凭空补充不在仓库里的设定。

3. 把“不要做什么”写出来​

例如：

  • 不改数据库结构
  • 不新增未实现的功能说明
  • 不把内部实现包装成对外能力
  • 不替换既有产品名称与域名

这类约束会直接影响最终结果的可信度。

4. 交付格式要能直接验收​

例如：

  • 修改文件并可构建通过
  • 输出风险清单
  • 输出适合官网发布的最终文案
  • 输出渠道配置说明，不输出内部调试过程

没有交付格式，团队很容易各说各话。

什么时候用 @团队名​

如果团队已经在系统里配置好，并且你希望在聊天中直接触发协作，可以使用 @团队名。
这适合：

  • 日常复用的固定团队
  • 前台聊天窗口直接发起协作
  • 渠道消息里按团队入口路由

例如：

@发布团队 请审查本次官网更新，输出上线前检查结论。

这种方式适合频繁复用的团队入口。

什么时候用 workflow_run​

如果你需要显式控制团队执行，或在工具链中调用团队工作流，则更适合 workflow_run。
它更适合：

  • 结构化任务执行
  • 从主对话中调用团队
  • 需要把团队作为执行节点接入链路

也就是说：

  • 面向人类使用入口时，@团队名 更自然
  • 面向执行链路时，workflow_run 更明确

典型场景写法​

官网与文档更新​

推荐使用 pipeline：

  1. 规划成员整理修改范围
  2. 内容成员改写文案
  3. 评审成员检查准确性与遗漏

因为这是典型的线性流程。

复杂配置排障​

如果要同时检查模型配置、渠道配置和工作空间权限，可以考虑 graph：

  • 一支检查模型连通性
  • 一支检查渠道参数
  • 一支检查安全与工作空间限制
  • 最后汇总结论

因为多个检查项可以并行。

方案评审或多视角争议问题​

推荐使用 council：

  • 架构视角
  • 成本视角
  • 风险视角
  • 统一汇总

因为重点是多观点并行判断。

常见误区​

误区 1：任务没有完成标准​

没有完成标准，团队就无法判断何时停止。

误区 2：模式选择过重​

很多线性任务本应使用 pipeline，却为了“高级感”强行做成 graph 或 council。

误区 3：成员职责重叠​

如果 Planner、Writer、Reviewer 都在重复总结需求，实际只是在浪费上下文。

误区 4：把一次性细节写进长期配置​

团队成员配置应该稳定，某次任务的特殊要求应留在当前任务描述中，不要每次都改团队定义。

推荐落地顺序​

  1. 先判断是否真的需要团队。
  2. 再选择最简单的协作模式。
  3. 再定义每个成员的唯一职责。
  4. 最后写清当前任务的目标、输入、约束和交付格式。

这比直接堆“高级提示词技巧”更符合 CountBot 的实际运行方式。

相关文档​