Vibe Kanban：用看板管理AI编程助手的任务与上下文

过去一年，我绝大部分编码工作都是和AI编程助手结对完成的。代码生成、重构、补测试，模型干得很漂亮，但我的效率瓶颈却跑到了“会话”上：每次新开一个对话，都要把项目背景、模块入口、技术约束重新喂一遍；如果同时处理两三个任务，AI就分不清优先级；如果隔几天再继续，更是连当时为什么决定不要某段逻辑都忘了。后来我把看板方法整套改造了一遍，形成了一个叫 Vibe Kanban 的工作流，用看板来管理 AI 编程助手的任务与上下文。这篇文章会讲清楚这套方法的设计逻辑、可以照抄的落地模板，以及我替你们踩出来的坑。适合正在用 AI 写代码、并且觉得“重新解释上下文”已经严重影响效率的个人开发者和小团队。

1. “AI 编程的上下文成本”才是 Vibe Kanban 想要解决的问题

很多人第一次听到 Vibe Kanban 会问：这不就是把 Trello 上的看板换个名字吗？还真不是。传统看板是管“人”的，管的是任务在多人之间怎么流转；Vibe Kanban 管的是“AI 会话”，管的是每一次和模型对话时，它到底带着多少有效上下文进入你的代码库。

1.1 传统看板的粒度错配：任务卡跟 AI 会话不是一回事

经典的看板方法论里，一张卡片等于一个任务，任务经历 To Do、In Progress、Done 几个状态。这套模型对人类团队没问题，因为一个工程师在切换到任务 B 时，大脑里还留着任务 A 的记忆；哪怕忘了，翻翻代码、看看注释也能快速拾起来。

但 AI 编程助手完全不是这样。它每次新会话都是“失忆”的。你上周跟它讨论过的订单模块，这周打开新会话就等于没发生过；它在帮你改 A 任务时，你没让它碰 B，它是绝对不会主动去理解 B 的。换句话说，传统看板的任务粒度是“一个需求/一个用户故事”，而 AI 辅助开发的真实工作单位是“一段会话 + 一段可校验的增量改动”。这两者一旦错配，就会产生一个非常普遍的现象：卡片上写满了一堆业务描述，扔给 AI 后，它依然会理直气壮地问你要代码路径。

所以我后来总结了一句话：传统看板描述“要做什么”，Vibe Kanban 描述“这一次会话喂给 AI 什么、让它产出什么、怎么算通过”。卡片的重心从目标描述转移到了上下文描述。

1.2 每次新开会话，都在为上一次的偷懒还债

我见过太多人抱怨 AI 编程助手“能力不行”，仔细一问，问题出在他根本没有给模型可用的上下文。比如他直接说“帮我优化订单模块”，模型回答了一堆泛泛的设计建议，因为他连“订单模块的代码在哪个目录”都没说。

这种重述上下文的过程，实际消耗的是双倍时间。第一次你在会话里解释清楚，模型做完了；第二次你又要重新解释，因为它没记忆。我曾经统计过自己一周的工作记录：每天第一次打开 AI 会话前，平均要花 15 到 20 分钟粘贴背景、找昨天的对话记录、回忆卡在哪一步。这个时间不产生任何代码，纯粹是浪费。

Vibe Kanban 的核心思路，就是把看板当作“上下文的外部硬盘”。每张卡片不是一个干巴巴的待办，而是一个完整的“上下文包”：入口文件在哪、约束是什么、验收标准是什么、上次进展到哪。只要卡片信息是新的，哪怕隔一个星期再拿起这张卡，通过复制卡片内容作为新的 prompt 开头，AI 也能快速回到状态。

1.3 Vibe Kanban 的定位：不是排程器，是上下文边界管理器

有人可能问：那我用 Notion 写开发文档不也一样吗？不一样。文档是静态的，它不会告诉你“哪张卡正处于 AI 会话中”。看板的列，本质上是在强制标记上下文的所有权和活跃度。对 AI 编程助手来说，看板存在的意义不是让你知道有多少活在排队，而是让你随时知道：

• 当前哪个模块的上下文是“热”的？也就是现在有没有一个 AI 会话正在处理它。
• 上次改到一半的上下文卡在哪里？是等验证，还是已经完成可以归档。
• 哪些代码路径已经喂给过 AI，并且被验证过是对的？下次同类任务可以直接复用。

所以我不太愿意把 Vibe Kanban 叫排程工具。它更像一个上下文边界管理器：人负责判断什么能改、什么不能动，AI 负责在允许的边界里快速产出，而看板就是让双方共享边界的那张地图。

2. 四列结构：把普通待办改造成“可以直接投喂 AI 的种子卡”

我试过很多种列的组合，最后沉淀下来的是四列：Backlog、In Session、In Review、Landed。列数不要再多，因为 AI 编程的节奏很快，列太多会让维护成本超过收益。关键不是列的名字，而是每一列都对应着一个明确的 AI 工作阶段。

2.1 列设计：Backlog、In Session、In Review、Landed

• Backlog：种子池。长期积压的任务、想法、优化点。这里面的卡不需要写得很细，但要保证每一张卡都有一个足够清晰的“入口信号”，否则将来可能喂给 AI 后它无从下手。
• In Session：正在被 AI 会话处理。这是整块看板里最需要纪律的位置。理想状态下，这个列同时只能有一张卡。它代表当前正在进行的这次 AI 对话围绕哪个目标展开。
• In Review：AI 改完了，人等验证。AI 把代码生成后，直接合并进主干是非常危险的做法。卡片进入这一列，意味着需要人来做代码审查、跑测试、确认改动是否符合预期。
• Landed：已经验证并落地。改动已经提交、合并，或者至少通过了本地验证。卡片进入这里之后，可以把里面提到过的上下文提炼成后续可复用的文档片段。

这个结构最重要的变化是：传统的“In Progress”被拆成了 In Session 和 In Review。为什么？因为 AI 写代码飞快，但验证依然需要人。过去我经常犯一个错误——AI 说做完了，我顺手就把卡拖到 Done，结果第二天才发现某个边界条件没处理。In Review 这列的存在，就是强制在自己和 AI 之间加一道人工闸门。

2.2 卡片字段：五个必填项，少一个 AI 就开始瞎猜

我把一张 Vibe Kanban 卡片设计成五个必填字段，这五个字段直接对应 AI 理解和执行任务时的信息需求：

1. 目标：一句话说清楚这次要 AI 完成什么。注意不要写“优化性能”这种模糊词，要写“将导入接口中大于 1 万行的 Excel 分片处理，避免内存溢出”。
2. 入口：代码位置。一定要具体到文件路径和函数名，例如backend/app/services/order_import.py 中的 process_file()。这会大幅减少 AI 到处乱翻代码的时间。
3. 约束：哪些不能碰。例如“数据库表结构不能改”“对外 API 签名不能变”“不要引入新的第三方库”。没有约束，AI 会按照它自己的“最佳实践”做一些画蛇添足的改动。
4. 验证：你怎么确认它做完了。例如“运行python -m pytest tests/test_order_import.py必须全通过”“本地跑一次包含 2 万行数据的导入”。
5. 参考：可以给 AI 的相关文档、类似实现、上期修改记录。这个字段是可选但极力推荐，因为它能减少 AI 生成风格不统一的代码。

为什么要强调这五个字段？因为 AI 编程助手最大的问题不是不会写代码，而是在信息不足的时候会“一本正经地猜”。你少给一个入口，它就自己挑一个长得像的文件开工；你少写一条约束，它就顺手把你不希望动的逻辑重构了。看板卡片形式上只比普通 todo 多写了几行字，但它把 AI 的“自由发挥空间”压缩到了可控范围。

2.3 WIP=1：为什么不能同时把多张卡丢给 AI

WIP 是 Work In Progress 的缩写，意思是同时进行中的工作数量。传统看板建议限制在制品，Vibe Kanban 里我直接要求 In Session 列最多一张卡。有人会觉得这太浪费了：AI 一次开好几个会话不是效率更高吗？

我实际测试下来完全不是这样。当你同时开三个会话让 AI 处理三个不同任务时，每个会话都会认为自己拥有整个项目的“最新理解”，而它们彼此不知道对方正在改动哪些文件。最典型的事故是：会话 A 正在重构某个模块的接口，会话 B 还基于旧接口写调用方，两边各自跑通，合并时才发现冲突。除了代码冲突，还有一个更隐蔽的问题：AI 的上下文一旦被多任务撑大，它在回答具体问题时就会把不相关的代码也纳入考量，生成的代码经常出现东拼西凑的痕迹。

所以我的操作习惯是：一次只喂一张卡、只开一个主会话。如果中途冒出另一个想法，记到 Backlog 里，等当前这张卡进了 Landed 再切过去。表面上看是串行执行，效率反而最高，因为每张卡的上下文状态都是干净的，不需要一次一次地“倒带”。

3. 从零落地：先用一个 Markdown 文件撑起日常使用

工具越复杂，越难坚持。Vibe Kanban 不需要一开始就上大平台，我自己前两个月就是用一个 Markdown 文件跑的。它的好处非常多：改动快、没有登录负担、可以被 git 跟踪、天然支持复制粘贴给 AI。

3.1 模板文件长什么样

下面是我最常用的模板，建议直接新建一个vibe-kanban.md放进项目仓库，随代码一起版本管理。

# Vibe Kanban 工作区 ## Backlog（种子池） - [ ] [卡名] | 目标： | 入口： | 约束： | 验证： ## In Session（当前 AI 会话只处理这一张） - [ ] [卡名] | 目标： | 入口： | 约束： | 验证： ## In Review（AI 已产出，等待人工验证） - [ ] [卡名] | 目标： | 入口： | 约束： | 验证： ## Landed（已验证并落地） - [x] [卡名] | 完成日期： | 提交号：

也许你会觉得这不像看板。没关系，重要的是字段和信息流。当卡片数量多起来、需要更直观的展示时，再迁移到真正的看板软件也来得及。用 Markdown 的另一个好处是，AI 编程助手本身就能理解这个文件。你在新会话里直接对它说“请先读 vibe-kanban.md 里 In Session 这张卡，然后按卡上的入口开始”，它一般都能正确定位。

3.2 三张样例卡片告诉你“上下文包”怎么写

只看模板不够，我给你写三个覆盖不同场景的示例，你感受一下卡片粒度。

示例一：一个小范围重构

- [ ] 将导入模块的循环改成批量入库 - 目标：`backend/app/services/order_import.py` 中逐条 insert 的逻辑改为分批 bulk_create，每批 500 条 - 入口：`process_rows()` 函数，从第 88 行开始 - 约束：不能改数据库字段；不能改变入参出参；异常处理保留原有日志格式 - 验证：运行 `python -m pytest tests/test_order_import.py::test_bulk_import`；用本地 2 万行测试数据跑一次导入脚本 - 参考：`docs/db_batch_pattern.md` 里已有的批量写库实现

示例二：修一个偶发 bug

- [ ] 修复订单取消时优惠券未回滚的问题 - 目标：当用户取消一笔已用优惠券的订单，优惠券状态应退回“未使用” - 入口：`backend/app/services/order_cancel.py` 的 `cancel_order()`；优惠券相关逻辑在 `backend/app/services/coupon.py` - 约束：取消操作必须是事务级的，失败要整体回滚；不要修改优惠券表结构 - 验证：先写一个单元测试用例，模拟“下单使用优惠券+取消订单”，断言优惠券状态还原；再运行全量测试套件 - 参考：git log 中最近一次修改 `coupon.py` 的提交

示例三：写一个新接口

- [ ] 给仪表盘模块增加“近 7 天订单趋势”接口 - 目标：新增 `GET /api/dashboard/order-trend?days=7`，返回按天聚合的订单数和销售额 - 入口：路由文件 `backend/app/routes/dashboard.py`；查询层可以参考 `order_stats.py` 中的现有写法 - 约束：只做只读查询；响应字段名使用 `order_count` 和 `total_amount`；鉴权方式与现有 dashboard 接口保持一致 - 验证：本地启动服务后 curl 请求该接口，确认返回格式符合接口文档；再运行相关 pytest - 参考：已有接口 `GET /api/dashboard/summary` 的实现

这些卡片的最大特点是“可执行”。不夸张地说，如果你把一张卡完整丢给一个强一点的编程模型，它几乎不需要再提问就能直接开始动工。你省掉的是大量来来回回的澄清对话。

3.3 一个工作日怎么跟看板协作

有了卡片，接下来解决的是节奏问题。我建议你结合看板，把一天的工作流固定成下面这个循环。

1. 早上开工前，花 5 分钟扫一遍 Backlog，挑一张当前优先级最高的卡移入 In Session。
2. 把这张卡的完整内容粘贴给 AI 作为首条 prompt，同时告诉它“先读代码确认你的理解，再开始改”。
3. 每完成一个小节点，让 AI 把改动 diff 给你；你不满意的部分直接在对话里要求修改。
4. 当 AI 明确说“做完了”，你自己过一遍代码、跑一次验证命令，通过后把卡从 In Session 移到 In Review。
5. In Review 里的卡，尽量在当天内完成人工复核，确认无误后移到 Landed，并在卡上补一行提交号。
6. 如果中途被其他事情打断，优先把当前会话的上下文结论浓缩进 In Session 卡片里，再走开。

这个循环看起来简单，但真正做到位的人很少。大家通常是：想到了就开一个对话框让 AI 写，写一半被打断也不记录，下午回来又得重新解释。看板在这里的作用就是给每个碎片化想法一个“暂停恢复点”。

4. 从单文件到团队工具：什么时候升级、升级选什么

一个人用 Markdown 可以跑很久，但如果团队里两三人都靠 AI 编程，或者需要把看板和代码审查流程打通，那是时候考虑迁移到更成熟的看板工具了。

4.1 三个让你不得不迁移的信号

信号一：多人同时往vibe-kanban.md里写内容，提交冲突越来越频繁。毕竟 Markdown 文件不走锁机制，两个人同时改就会冲突。

信号二：你需要把卡片和分支、Pull Request 关联起来。In Review 里的卡如果不能一键跳到对应的 PR，审查成本会变得很高。

信号三：你发现自己在“移动卡片”上花的时间超过了“更新上下文”。如果看板工具不能让你更快地查询、筛选和记录，就失去了意义。

我个人建议不要过早迁移。少于三个人、任务量没那么大时，Markdown 的灵活性和零成本优势远大于专业工具。

4.2 主流看板软件对 AI 会话流支持度速览

我自己试过几款主流工具，列一张表给你参考，注意这里说的“支持度高”主要是指：能否快速记录代码上下文、能否关联分支/PR、能否减少移动卡片的操作成本。

4.3 我的混合方案：Markdown 负责短期记忆，看板软件负责长期脉络

在团队里完整跑过一轮后，我现在用的是混合方案。短期记忆用 Markdown：每张卡进入 In Session 前，内容都整理成一小段“上下文包”，放在仓库里的vibe-kanban.md，这个文件是所有 AI 会话的直接输入。长期脉络用看板软件：卡片从 In Review 移到 Landed 后，会把最终结果同步到 GitHub Projects，同时把提交号写进去。

这样做的理由很简单：AI 编程助手读取仓库里的 Markdown 最顺手，而人在跨周回顾、汇报进度时用看板软件更直观。你不需要追求一种工具解决所有问题，关键是让你和 AI 都能在各自最舒服的“阅读界面”上工作。同步动作每天下班前做一次，五分钟搞定，别让它变成负担。

5. 亲身踩坑：Vibe Kanban 用了一个季度后，差点把我劝退的五个问题

方法初期很顺，但用得越久，越会发现一些反模式。下面这几条全是我的真实翻车记录，希望你不用再走一遍。

5.1 “PR description”式卡片的陷阱

刚开始我写卡片时带着写 PR 描述的习惯：“作为运营人员，我希望导入订单时能自动检查重复，以便减少人工处理。”这种描述给产品经理看没问题，但给 AI 编程助手看就是灾难。它读完只知道“用户想要去重”，却不知道去重逻辑应该写在哪里，依据哪个字段去判断重复。

后来我改成：“在backend/app/services/order_import.py的process_file()里，读取 Excel 前先用order_no查一次数据库，把已存在的单号收集到duplicates列表，文件解析阶段跳过这些行，最后把重复单号写进返回结果。”同样是描述一个功能，后者让 AI 没有半点犹豫空间。这就是我在前面反复强调的：卡片不是写给项目干系人看的周报，是写给 AI 的“可执行指令 + 安全边界”。

5.2 In Review 形同虚设：AI 说完成就完成？

我一开始也以为，让 AI 写代码、它自己跑一遍测试、然后告诉我全部通过，这就算完事了。可实际情况是，模型在跑测试时有可能只跑它自己刚写的那个用例，压根没跑全量；甚至更隐蔽的问题是，它新增了一个用于自证的测试，而这个测试本身逻辑也是错的，两个错误叠加在一起刚好“通过”。

所以我在卡片“验证”字段里增加了硬性要求：列出全量测试命令，明确不许只跑单测；同时要求 AI 在回复里贴出命令实际输出，而不是只说“测试通过”。In Review 列因此从摆设变成了真正的质量闸门。宁可让卡片在这一列多待半天，也别让一个带隐患的改动混进主干。

5.3 一次开三张卡的灾难现场

有一次我觉得自己状态极佳，同时开了三个 AI 会话：一个改订单服务，一个调前端接口，一个写数据库迁移脚本。结果三个会话在同一个实体模型上改出了各自的“正确版本”，合并时冲突几十处。我花了整整一个下午解决冲突，比让 AI 一个接一个干活慢了三倍。

这就是 WIP=1 纪律的来源。那次事故后我把规则写在看板顶部：“In Session 列表只允许出现一张卡，谁违反谁自己解决冲突。”多人团队里，这条规则尤其重要。只有一张卡在会话里，意味着在任何时刻，整个项目只有一个 AI 上下文是热状态，其他所有代码路径都处于只读状态。这种约束带来的清晰感，远远超过并行带来的虚假快感。

5.4 卡片里的接入信息过期，AI 拿着旧地图走新路

有一张卡的“入口”字段写的是某个函数所在文件，但那个函数上一周已经被重构移走了。我直接把卡丢给 AI，它顺着旧路径找过去，代码读了个寂寞，还一本正经地在旧文件里新建了一个同名函数。等我 review 时才发现有重复实现。

从那以后，我在所有卡片的“验证”里增加了一条固定动作：开工前先让 AI 做一个“入口确认”，即在改动前先用一句话说明它打算修改哪些具体文件和函数，如果找不到就停下来问人。这个前置确认成本极低，却能把 AI 从“拿着旧地图走新路”的状态里拉回来。同时我也养成习惯：每张卡进入 Landed 后，顺手把入口信息更新成最终位置，下次复用才不会踩坑。

5.5 看板杂务化：避免为了维护看板而维护看板

最后一个坑是反方向的：看板本身变成了新的形式主义。有一段时间我沉迷于把每张卡都写得特别详细，甚至给卡片加颜色标签、工作量估算、截止日期，结果我花在看板上的时间比写代码还多。这完全违背了 Vibe Kanban 的初衷。

我现在给自己定了一个时间盒：任何一张卡从 Backlog 进入 In Session 前，整理上下文包的时间不超过十分钟；超过十分钟说明这个任务根本还没想清楚，应该退回设计阶段而不是硬塞给 AI。看板是帮你减少上下文摩擦的，不是用来展示自律的。一旦开始为了维护而维护，它就成了新负担。

6. 从程序员桌面到企业现场：看板这个词在不同语境下的几种形态

聊到这里，也许你会好奇，为什么“看板”这个词既能用在 AI 编程助手身上，也能出现在“在线商店销售与毛利分析看板”“MES 生产看板”这些完全不同的场景里？我顺手展开讲讲，因为它们背后其实共享同一套逻辑。

6.1 在线商店的销售与毛利分析看板，本质是 BI 指标闭环

“在线商店销售与毛利分析看板”听起来和我前面聊的编程看板八竿子打不着。它不负责追踪任务，它负责追踪经营结果。这种看板通常要回答三个问题：整体卖了多少？毛利是否健康？问题出在哪个环节？

为了回答这些问题，数据链路一般是：订单表、商品成本表、渠道维度表被 ETL 清洗后，汇总到一张销售事实表，再按时间、渠道、SKU 等维度聚合，最终在前端展示成销售额、订单量、毛利额、毛利率、同比环比等卡片。和编程看板一样，这类看板最难的不是画图表，而是定义“指标口径”：毛利到底是销售收入减去商品成本，还是再扣掉分摊的物流和推广费？口径不一致，看板做得再漂亮都是误导。

从构建角度说，这类看板通常依赖 BI 工具或自研数据平台，核心开发工作是数据建模和指标计算，而不是设备交互。性能瓶颈也多在 SQL 查询和大宽表设计上，和我在 AI 编程场景里维护的 Markdown 看板完全不是一个技术栈，但“用可视化推动人做决策”的目标是一致的。

6.2 MES 生产看板与 C# 的铁关系从何而来

有朋友在网上问“MES 看板是用 C# 开发的吗”，这个问题背后的行业背景值得说两句。MES 是制造执行系统，它面向的是车间现场，依赖大量实时数据：设备状态、工单进度、产量、质量、报警。这类系统有一个天然特征：必须跑在工厂车间的 Windows 工控机或者工业终端上，并且要和 PLC、扫码枪、称重设备等硬件通信。

在这种环境下，C#/.NET 的市占率很高。原因并不神秘：一是 Windows 生态在工业领域根基很深，.NET 原生具备 WinForms、WPF、Blazor 等成熟的界面方案；二是设备通讯方面，OPC UA 这类工业协议的主流 SDK 大多提供了完善的 .NET 客户端库；三是很多工厂早年的 MES 就是 .NET 写的，后来者为了维护方便继续沿用。但这就代表 MES 看板一定得用 C# 吗？当然不是。新的 Web 技术栈同样可以做 MES 看板，前端采集设备数据，后端用 Java、Go、Python 都行。C# 更多是历史惯性和生态匹配的结果，不是一道技术“必答题”。

6.3 三张看板的共同底层逻辑

把 Vibe Kanban、电商毛利分析看板、MES 产线看板放在一起看，会发现它们都包含四个要素：数据源、状态整理、可视化、触发行动。

• 对 Vibe Kanban 来说，数据源是你的代码库和需求卡片，状态整理是把任务拆成 Backlog 到 Landed 的管道，可视化是让人看清上下文热度，触发行动是人工验证与提交。
• 对电商毛利看板来说，数据源是订单和成本表，状态整理是维度建模和指标计算，可视化是销售与毛利趋势图，触发行动是运营调整定价或选品。
• 对 MES 看板来说，数据源是车间设备和工单，状态整理是判断每台设备处于运行、空闲还是故障，可视化是产线总览，触发行动是维修或调度。

理解了这层逻辑，你就不会被“看板”这个词局限住。它本质上是一种信息组织方式：把复杂系统里最值得关注的状态提取出来，让人用眼睛快速识别异常，再推动下一步动作。AI 编程助手时代，卡片上多了一份“喂给模型的上下文”，但看板帮助人做判断的本质没有变。

最后分享一点个人体会：我把 Vibe Kanban 运行了小半年，最大的收获不是任务完成得更多，而是我对“哪些上下文已经交代清楚、哪些还没有”这件事变得极有意识。每次觉得自己和 AI 的合作卡住了，回头看看那张卡，十有八九是入口、约束或者验证标准写得不到位。别把它当项目管理系统，把它当你的第二大脑。AI 的记忆很短，你的卡片就是它最长久的记忆。