第三章. ViBe KanBan 任务管理进阶
第三章. ViBe KanBan 任务管理进阶
Prorise第三章. ViBe KanBan 任务管理进阶
本章将深入讲解 Vibe Kanban 的任务管理体系,包括任务创建的三种方式、Task Tags 的使用、任务尝试(Task Attempts)机制、子任务(Subtasks)的应用场景,以及任务状态的自动化流转
我们将分四个阶段掌握任务管理:
阶段一:任务创建的三种方式(10 分钟)
- 手动创建任务
- 使用 Task Tags 插入模板
- 通过 MCP 批量创建任务
阶段二:任务尝试(Task Attempts)机制(8 分钟)
- 理解 Task Attempts 的设计理念
- 何时需要创建新的 Attempt
- 切换 Agent 与 Base Branch
阶段三:子任务(Subtasks)的应用(10 分钟)
- 将复杂任务拆解为子任务
- 子任务的分支继承与合并策略
- 父任务与子任务的依赖关系
阶段四:任务状态流转与自动化(7 分钟)
- 理解任务生命周期
- 配置 GitHub Integration 自动同步 PR
- 任务完成后的通知机制
3.1. 任务创建的三种方式
Vibe Kanban 提供了三种任务创建方式,分别适用于不同的开发场景。
3.1.1. 手动创建:使用任务表单
这是最直接的任务创建方式,适合单个任务的快速创建。
步骤 1:打开任务创建对话框
在项目看板页面,点击右上角的 “+” 按钮(或使用快捷键 C)。
步骤 2:填写任务基本信息
任务创建对话框包含以下字段:
| 字段 | 说明 | 是否必填 | 示例 |
|---|---|---|---|
| Title | 任务标题 | ✅ 必填 | “实现用户登录页面” |
| Description | 任务描述(支持 Markdown) | ✅ 必填 | 详细的需求说明 |
| Base Branch | 任务分支的起点 | ✅ 必填 | main |
| Agent | 执行任务的 AI Agent | ✅ 必填 | GEMINI_FLASH |
步骤 3:编写任务描述
任务描述是 Agent 理解需求的唯一依据,必须清晰、具体、可执行。
❌ 错误示例(过于模糊):
1 | 实现登录功能 |
这个描述缺少关键信息:
- 登录方式是什么?(邮箱、手机号、第三方登录?)
- 需要实现哪些功能?(记住密码、忘记密码?)
- UI 设计是什么样的?
✅ 正确示例(清晰具体):
1 | ## 任务目标 |
任务描述的最佳实践:
| 原则 | 说明 | 示例 |
|---|---|---|
| SMART 原则 | Specific(具体)、Measurable(可衡量)、Achievable(可实现)、Relevant(相关)、Time-bound(有时限) | “在 2 小时内完成登录页面的 UI 实现” |
| 包含验收标准 | 明确定义 “完成” 的标准 | “代码覆盖率 > 80%” |
| 提供上下文 | 引用相关文档或设计稿 | “参考 Figma 设计稿:[链接]” |
| 指定技术栈 | 明确使用的库和工具 | “使用 React Hook Form + Zod” |
步骤 4:选择执行 Agent
在 “Agent” 下拉菜单中,选择适合当前任务的 Agent。
| Agent | 适用场景 | 推荐任务类型 |
|---|---|---|
| GEMINI_FLASH | 前端开发、文档生成 | UI 实现、需求分析 |
| CLAUDE_CODE | 后端开发、复杂逻辑 | API 实现、架构设计 |
| CODEX | 测试生成、Bug 修复 | 单元测试、代码重构 |
步骤 5:创建并启动任务
填写完成后,你有两个选择:
| 按钮 | 行为 | 适用场景 |
|---|---|---|
| Create | 创建任务但不启动 | 需要稍后手动启动 |
| Create & Start | 创建任务并立即启动 Agent | 立即开始执行 |
点击 “Create & Start” 后,Vibe Kanban 会:
- 创建任务分支(如
feature/user-login) - 创建 Worktree
- 执行 Setup Scripts
- 启动 Agent
3.1.2. 使用 Task Tags 插入可复用模板
在实际开发中,我们经常会遇到相似的任务(如 “修复 Bug”、“实现 CRUD 接口”)。为了避免重复编写任务描述,Vibe Kanban 提供了 Task Tags 功能。
什么是 Task Tags?
Task Tags 是预定义的文本片段,可以在任务描述中通过 @tag_name 语法快速插入。
步骤 1:创建 Task Tag
打开 Vibe Kanban 设置页面,点击左侧菜单的 “Task Tags”。
点击 “Add Tag” 按钮,创建一个新的 Tag。
示例 1:Bug 修复模板
| 字段 | 内容 |
|---|---|
| Tag Name | bug_report |
| Content | 见下方 |
1 | ## Bug 描述 |
示例 2:CRUD 接口模板
| 字段 | 内容 |
|---|---|
| Tag Name | crud_api |
| Content | 见下方 |
1 | ## 接口需求 |
步骤 2:在任务描述中使用 Task Tag
创建任务时,在描述框中输入 @,Vibe Kanban 会自动弹出 Tag 列表。
选择 @bug_report 后,模板内容会自动插入到描述框中。你只需要填写具体的 Bug 信息即可。
Task Tags 的高级用法:
技巧 1:嵌套 Task Tags
你可以在一个 Task Tag 中引用另一个 Task Tag。
1 | ## 任务描述 |
技巧 2:使用变量占位符
在 Task Tag 中使用 [变量名] 作为占位符,提醒自己填写具体内容。
1 | ## 接口路径 |
3.1.3. 通过 MCP 批量创建任务
当你需要创建大量相似的任务时(如将一个 Epic 拆解为 10 个 Story),手动创建会非常低效。Vibe Kanban 提供了 MCP(Model Context Protocol)集成,允许 AI Agent 自动创建任务。
什么是 MCP?
MCP 是一个标准化的协议,允许 AI Agent 调用外部工具。Vibe Kanban 既是 MCP Client(可以调用其他 MCP Server),也是 MCP Server(可以被其他 AI 工具调用)。
使用场景:
| 场景 | 说明 |
|---|---|
| 从 PRD 生成任务 | 让 Claude Desktop 读取 PRD 文档,自动拆解为多个任务 |
| 从 Epic 生成 Story | 让 Agent 将一个大任务拆解为多个小任务 |
| 批量创建测试任务 | 为每个功能模块自动创建对应的测试任务 |
步骤 1:配置 Vibe Kanban 作为 MCP Server
以 Claude Code 的配置文件(~/Library/Application Support/Claude/claude_desktop_config.json),添加以下内容:
1 | { |
重启 Claude Code 后,你会在工具列表中看到 Vibe Kanban 的 MCP 工具。
步骤 2:使用 Claude Code 批量创建任务
在 Claude Code 中,输入以下提示词:
1 | 我有一个 PRD 文档(见附件),请帮我将其拆解为多个可执行的任务,并使用 Vibe Kanban MCP 工具创建这些任务。 |
Claude 会分析 PRD 文档,然后调用 Vibe Kanban 的 create_task MCP 工具批量创建任务。
步骤 3:验证任务创建结果
回到 Vibe Kanban 看板,你会看到 Claude 自动创建的所有任务。
MCP 批量创建的优势:
| 优势 | 说明 |
|---|---|
| 节省时间 | 10 个任务只需 1 分钟创建 |
| 保持一致性 | 所有任务的描述格式统一 |
| 自动分配 Agent | 根据任务类型自动选择合适的 Agent |
3.2. 任务尝试(Task Attempts)机制
在实际开发中,一个任务可能需要多次尝试才能完成。例如:
- 第一次尝试使用 Gemini,但生成的代码质量不佳
- 第二次尝试切换到 Claude Code,重新实现
Vibe Kanban 的 Task Attempts 机制允许你在不创建新任务的情况下,重新执行同一个任务。
3.2.1. 理解 Task Attempts 的设计理念
核心概念:
- 一个 Task 可以有多个 Attempts(尝试)
- 每个 Attempt 对应一个独立的 Worktree 和 Git 分支
- 只有最新的 Attempt 会被合并到主分支
关系图:
为什么需要 Attempts?
| 场景 | 传统方式 | 使用 Attempts |
|---|---|---|
| Agent 生成的代码不满意 | 创建新任务 “修复登录页面” | 创建新的 Attempt,重新生成 |
| 切换技术方案 | 手动删除代码,重新开始 | 创建新的 Attempt,切换 Base Branch |
| 对比不同 Agent 的效果 | 创建多个任务 | 在同一个任务中创建多个 Attempts |
3.2.2. 何时需要创建新的 Attempt
场景 1:Agent 生成的代码质量不佳
假设你创建了一个任务 “实现商品列表页”,使用 Gemini 执行。但 Agent 生成的代码存在以下问题:
- UI 布局不符合设计稿
- 缺少错误处理
- 代码风格不统一
此时,你可以创建一个新的 Attempt,重新执行任务。
步骤 1:打开任务详情
点击任务卡片,进入任务详情页面。
步骤 2:点击 “New Attempt”
在任务详情页面右上角,点击 “New Attempt” 按钮。
步骤 3:配置新的 Attempt
在弹出的对话框中,你可以修改以下配置:
| 配置项 | 说明 | 示例 |
|---|---|---|
| Agent | 切换到其他 Agent | 从 GEMINI_FLASH 切换到 CLAUDE_CODE |
| Base Branch | 修改任务分支的起点 | 从 main 切换到 develop |
| Description | 修改任务描述(可选) | 添加更详细的需求说明 |
步骤 4:启动新的 Attempt
点击 “Create & Start” 后,Vibe Kanban 会:
- 创建新的任务分支(如
feature/product-list-attempt-2) - 创建新的 Worktree
- 执行 Setup Scripts
- 启动新的 Agent
关键点:
- 旧的 Attempt 不会被删除,你可以随时查看其代码
- 新的 Attempt 会从 Base Branch 重新开始,不会继承旧 Attempt 的代码
场景 2:切换技术方案
假设你最初计划使用 REST API 实现后端接口,但在开发过程中决定改用 GraphQL。此时,你可以创建一个新的 Attempt,切换 Base Branch 到包含 GraphQL 配置的分支。
步骤 1:准备新的 Base Branch
1 | # 在主项目中创建 GraphQL 配置分支 |
步骤 2:创建新的 Attempt
在任务详情页面,点击 “New Attempt”,将 Base Branch 修改为 feature/graphql-setup。
步骤 3:更新任务描述
在任务描述中,明确说明使用 GraphQL 实现:
1 | ## 技术要求 |
场景 3:对比不同 Agent 的效果
如果你想对比 Gemini 和 Claude Code 在同一个任务上的表现,可以创建两个 Attempts。
步骤 1:创建 Attempt 1(Gemini)
- Agent:
GEMINI_FLASH - 任务描述:保持不变
步骤 2:创建 Attempt 2(Claude Code)
- Agent:
CLAUDE_CODE - 任务描述:保持不变
步骤 3:对比代码质量
在任务详情页面,你可以切换不同的 Attempts,查看它们生成的代码。
对比维度:
| 维度 | Gemini | Claude Code |
|---|---|---|
| 代码行数 | 150 行,样式优雅简洁 | 180 行样式花里胡哨但功能完善 |
| 注释质量 | 简单注释 | 详细注释 + JSDoc |
| 错误处理 | 基本的 try-catch | 完善的错误处理 + 日志 |
| 测试覆盖率 | 60% | 85% |
3.2.3. Attempts 的分支管理策略
每个 Attempt 对应一个独立的 Git 分支,分支命名规则如下:
1 | feature/[task-name]-attempt-[number] |
示例:
| Attempt | 分支名称 |
|---|---|
| Attempt 1 | feature/user-login-attempt-1 |
| Attempt 2 | feature/user-login-attempt-2 |
| Attempt 3 | feature/user-login-attempt-3 |
合并策略:
只有最新的 Attempt 会被合并到主分支。旧的 Attempts 会被保留在 Git 历史中,但不会影响主分支。
清理旧的 Attempts:
如果你确定不再需要旧的 Attempts,可以手动删除它们的分支:
1 | # 删除本地分支 |
3.3. Story 驱动的子任务拆解模式
在 Vibe Kanban 中,最优雅的协作方式不是让 AI 去操作看板,而是让 AI 在代码仓库中写规划文档,Vibe KanBan支持创建子代理
那么我们的思路就是,让主代理负责将需求PRD文档拆分为Epic(大型任务清单),再将大型任务清单整理为依赖关系清晰的Story故事集合
我们利用 Git Worktree 的特性,让主任务(Epic)的 Agent 直接在项目中创建一个 stories/ 目录,并将复杂的 Epic 拆解为多个按顺序编号的 Story 文件(如 1-1-setup.md, 1-2-nav.md)。用户只需要看着这些文件,手动分发任务即可。
3.3.1. 核心流程:Epic -> Stories -> Tasks
这种模式的核心在于:用文件来管理任务依赖。
- Epic (规划者):拥有完整的 Git Worktree,它不写代码,只负责规划,在
stories/目录下生成 Markdown 文件。 - Stories (文件):以
阶段-序号-名称命名(如1-1,2-1),天然决定了执行顺序。 - Task (执行者):用户根据 Story 文件手动创建任务,AI 执行时直接读取对应的 Story 文件作为需求。
3.3.2. 实战:拆解 Todo 模块
假设我们有一个空的 React 项目,现在要实现 Todo 模块。
步骤 1:启动规划任务
创建一个名为 [Epic] Todo 模块规划 的任务并启动。在 Chat 中输入以下指令(这是你的核心 Prompt):
1 | # Role |
步骤 2:AI 生成 Story 文件
AI 会在你的项目中生成如下文件结构。因为都在同一个 Git Worktree 中,你可以直接在左侧文件树看到它们:
1 | stories/todo/ |
步骤 3:用户手动分发 (The Human Loop)
这一步由你控制节奏,既灵活又安全:
- 并行阶段 1:你看到
1-1是第一阶段,直接创建两个 Vibe Kanban 任务,把这两个文件的内容分别贴进去(或者告诉 AI 读取这个文件)。 - 并行阶段 2:等阶段 1 完成后,你基于1-1创建
2-1和2-2任务。由于都在一个仓库里,执行阶段 2 的 Agent 能直接读取到阶段 1 提交的代码。 - 收尾阶段 3:最后创建
3-1任务进行集成。
3.3.3. 这种模式的巨大优势
| 优势 | 说明 |
|---|---|
| 零冲突风险 | Story 1 和 Story 2 是完全隔离的文件,规划阶段绝不会冲突。 |
| 持久化 | 你的项目规划直接保存在 Git 里(stories/ 目录),任何人接手都能看懂开发路径。 |
| 上下文共享 | 因为 Epic Agent 就在 Git Worktree 里,它生成的 Story 是完全基于当前项目真实目录结构的,不会瞎编文件名。 |
| 灵活调度 | 用户看着文件名就能秒懂哪些可以并行(同为 1-x 开头),哪些需要等待(2-x 开头)。 |











