你的看板在撒谎，Git早就知道了

打开你团队的看板。数一下"审核中"里躺了三天没人动的工单，"测试中"里根本没人测的卡片，还有从"进行中"直接跳到"已完成"的漏网之鱼。

答案通常是：很多。看板成了团队心照不宣的 fiction（虚构叙事）。

Git 仓库知道每张工单的真实状态。看板只是还没跟上。

谁在设计和现实打架的看板

大多数看板的设计者想的是流程，不是 Git 里实际发生的事。

于是你得到这样的列：

"待测试"——谁说的待测试？在哪测？这是人的主观判断，不是 Git 状态。

"审核中"——真在审吗？还是 PR 开了三天没人点？

规则很简单：每一列必须对应一个能独立验证的状态，不依赖任何人的记忆。

"进行中"能通过——有分支吗？有提交吗？可验证。

"代码审核"能通过——有未合并的 PR 吗？有通过审核的记录吗？用 gh pr view 或平台 API 能查到。

"待测试"通不过——就绪的标准是谁定的？测试环境在哪？这是人类声明，不是仓库状态。

如果一列无法从仓库验证，只有两种可能：

要么这列是幻觉，要么有人在手动维护一套平行记录。两种情况都是浪费。

两个维度硬塞进一条流水线

设计看板时最大的洞察：工单状态有两个独立维度，团队却总把它们压成一条水平流。

代码流（从左到右）：待办 → 进行中 → 审核中 → 测试中 → 已完成。这些直接映射 Git 状态。

任务流（横向出口）：阻塞、搁置、需补需求、等客户反馈。这些和 Git 完全无关——它们反映的是工作本身的状态，不是代码状态。

一张工单标记为"阻塞"，分支照样开着。它在流程里没有后退，只是暂停。

把这两个维度分开，就能避免经典错误：把"阻塞"插在"进行中"和"审核中"之间。这种插法会打断流程，让所有人困惑。

被跳过的列就是谎言

理论上，工单要流经每一列。实际上，开发者跳过一半。

工单从"进行中"直接跳进"已完成"——跳过"审核中"和"测试中"。为什么？因为开发者合并了 PR，自己在生产环境验证通过，顺手一拽卡片。

这不是懒。是看板不匹配现实。

如果团队没有专职 QA，也没有预发环境，"测试中"这列就是 fiction。工单跳过它，是因为这列代表的状态根本不存在。

规则：如果一列总是被跳过，要么删掉它，要么补上流程。

加上缺失的环节（真正的 QA 阶段，真正的预发环境），或者删掉假装它存在的列。有跳过列的看板，就是撒谎的看板。

让 Git 自己更新看板

最好的看板由 Git 事件驱动更新，不是人手动拖卡片。主流追踪系统原生支持：

GitHub Projects、GitLab 看板、Jira 的 Git 集成——都能配置规则：PR 打开时自动移到"审核中"，合并时自动进"已完成"，分支删除时自动归档。

人只负责处理那些 Git 不知道的事：阻塞原因、优先级变化、需求变更。

看板终于开始说真话了。

现在打开你的看板。找一列你无法从 Git 验证的列。那就是你的第一个修复目标。