用问题+标签替代看板：可视化你和AI的开发进度

1. 为什么"问题+标签"比看板更贴近真实开发节奏

大多数团队都经历过这样的场景：项目启动时兴致勃勃地建了一个看板，列了"待办、进行中、待测试、已完成"四列，前两周大家还认真拖卡片，第三周开始卡片就没人动了。不是团队懒，而是看板这种形态天然适合"人手动搬运信息"，而开发者的注意力永远在代码编辑器里，不在浏览器标签页上。

我后来换了一个思路：把开发进度的载体从"卡片"换成"问题（Issue）+标签（Label）"。这个转变听起来很小，但实际用下来差别巨大。原因在于，问题本身就是开发者提交代码、讨论方案、记录缺陷时天然会产生的东西，它不需要额外维护；而标签是附加在问题上的元数据，可以自动流转、自动统计、自动触发后续动作。换句话说，问题负责承载"发生了什么"，标签负责表达"现在处于什么状态"，两者组合起来，就形成了一套不需要人刻意维护的进度系统。

这套思路还有一个更重要的价值：它天然适配 AI 协作。当 AI 参与开发时，它最擅长处理的恰恰是结构化的文本对象——问题描述、标签状态、评论记录。你不需要让 AI 去"看"一个图形化看板，只需要让它读取问题和标签，它就能判断当前进度、下一步该做什么、哪些任务被阻塞了。这就是标题里"可视化你和 AI 的开发进度"的真正含义：不是画一张漂亮的图，而是让人类和 AI 共享同一套可读、可查、可自动化的进度语言。

下面我会从标签体系设计、问题模板、自动化流转、AI 协作接口、可视化呈现、踩坑经验几个层面，把这套方法完整拆开讲。适合正在被看板维护成本折磨的团队，也适合想让 AI 真正参与开发流程而不是只当聊天工具的开发者。

2. 标签体系怎么设计才不会三个月后变成一团乱麻

2.1 标签分三类，不要混在一起用

我见过太多团队的标签列表长这样：bug、紧急、前端、待确认、张三、v2.0、优化……几十个标签混在一个维度里，用的时候根本不知道该选哪个。问题出在没有区分标签的语义类别。

我的做法是把标签严格分成三类，每类只表达一个维度：

关键点是加前缀。status:、type:、area:这些前缀看起来啰嗦，但它带来两个好处：一是在标签列表里自动按类别聚拢，找起来快；二是自动化脚本可以按前缀精确匹配，不会误伤。比如我要统计所有未完成的问题，只需要筛选status:开头且不等于status:已完成的标签即可，逻辑非常干净。

2.2 状态标签的数量必须克制

状态标签是整个体系的核心，也是最容易膨胀的地方。很多团队一开始设了"待处理、已分配、开发中、待测试、测试中、待验收、已验收、已发布"八个状态，结果发现根本没人认真切换，最后全部退化成"待处理"和"已完成"两个。

我的经验是：状态标签最多五个，而且必须对应一个明确的动作触发点。比如：

• status:待处理——问题刚创建，还没人认领
• status:开发中——有人创建了分支或提交了第一个 commit
• status:待验证——代码合并到主分支，等待测试或人工确认
• status:已完成——验证通过，问题关闭
• status:阻塞——遇到依赖或决策问题，暂时无法推进

这五个状态覆盖了绝大多数开发场景。注意status:阻塞是独立状态而不是"开发中"的子状态，因为阻塞需要被单独统计和提醒，混在开发中里就看不见了。

2.3 标签颜色和命名的一致性

标签颜色不是装饰，是视觉索引。我的习惯是：状态标签统一用蓝色系（从浅到深表示推进程度），类型标签用绿色系，归属标签用灰色系。这样在问题列表里扫一眼，就能通过颜色判断大致情况，不需要逐个读文字。

命名上坚持全小写、用短横线连接、不加空格。status:in-progress比Status: In Progress在脚本处理时省心得多，不会因为大小写或空格导致匹配失败。这个细节看起来微不足道，但当你写自动化脚本时，会感谢自己当初的克制。

提示：标签一旦创建就不要轻易删除或改名。已经打上的标签如果被删除，历史问题上的标记会丢失，统计就会出现断层。如果确实要调整，用"新增替代旧标签 + 批量迁移"的方式，保留旧标签至少一个迭代周期。

3. 问题模板：让每个问题天生就带着进度信息

3.1 为什么模板比自由填写更重要

如果让开发者自由写问题描述，你会得到两种极端：一种是"登录有问题"五个字，另一种是洋洋洒洒两千字但没有重点。这两种都无法被自动化系统有效处理。模板的作用不是限制表达，而是保证关键字段一定存在，这样后续的标签流转、AI 分析、进度统计才有稳定的输入。

我的问题模板包含四个必填区块，用 Markdown 的二级标题分隔，这样解析起来非常方便：

## 背景 （这个问题的来源，一句话说清楚） ## 期望结果 （完成后应该是什么样，可验证） ## 当前状态 （现在是什么情况，附上复现步骤或截图） ## 验收标准 （满足什么条件可以关闭这个问题）

这四个区块对应了开发流程里最关键的四个问题：为什么做、做成什么样、现在卡在哪、怎么算做完。缺任何一个，问题都会在流转过程中反复被追问。

3.2 模板字段与标签的自动映射

模板的价值不止于规范描述，更在于它可以驱动标签自动打标。比如我在自动化脚本里做了这样的映射：

• 问题创建时，自动打上status:待处理和type:功能（如果标题或背景里出现"修复""报错"等词，则打type:缺陷）
• 当有人在评论里写了"开始处理"或创建了关联分支，自动切换到status:开发中
• 当关联的合并请求被合入主分支，自动切换到status:待验证
• 当问题被关闭，自动切换到status:已完成

这套映射不需要 AI，用简单的关键词匹配和事件监听就能实现。但它的效果是：开发者几乎不需要手动碰标签，进度却始终是准的。这一点非常关键，因为任何需要人额外操作的系统，最终都会因为"忘了"而失效。

3.3 给 AI 留一个"上下文区块"

如果团队里有 AI 参与开发，我建议在模板里额外加一个区块：

## AI 上下文 （相关文件路径、依赖模块、已知约束、参考实现）

这个区块是专门给 AI 读的。当 AI 需要接手一个问题时，它不需要去翻整个代码库，只需要读这个区块里列出的文件路径和约束条件，就能快速定位到相关代码。实测下来，有了这个区块，AI 首次给出有效方案的概率明显提升，因为它不用花大量 token 去"猜"项目结构。

这个区块的内容由创建问题的人填写，通常就是几行文件路径加一两句说明，成本很低，但对 AI 协作效率的提升非常明显。

4. 自动化流转：让标签自己动起来

4.1 用事件驱动代替人工拖拽

看板最大的问题就是"人工拖拽"，而问题+标签体系最大的优势就是"事件驱动"。所谓事件驱动，就是当某个动作发生时，自动触发标签变更，不需要人去手动改。

常见的事件和对应的标签变更：

这张表是整个自动化体系的核心。你可以用项目托管平台自带的自动化功能实现，也可以写一个轻量脚本轮询 API 来实现。我两种都用过，平台自带的功能省事但灵活性差，自写脚本灵活但需要维护。中小团队建议先用平台自带功能跑通流程，等流程稳定了再考虑自写脚本做精细化控制。

4.2 分支命名规范是自动化的前提

上面表格里有一行"分支被创建且命名含问题编号"，这是整个自动化链条里最容易断掉的一环。如果分支命名随意，脚本就无法把分支和问题关联起来，status:开发中就打不上。

我的分支命名规范是：<类型>/<问题编号>-<简短描述>，例如feat/123-login-retry或fix/456-payment-timeout。这个规范的好处是：类型前缀一眼能看出改动性质，问题编号让自动化脚本能精确关联，简短描述方便人阅读。

为了让这个规范落地，我在项目里加了一个提交前的检查脚本，如果分支名不符合规范，直接拒绝推送并给出提示。一开始大家会抱怨麻烦，但一周之后就习惯了，因为自动化带来的便利远大于命名的小小约束。

4.3 阻塞检测：让沉默的问题浮出水面

开发流程里最危险的不是"明显卡住的问题"，而是"没人提但也没人动的问题"。这类问题在传统看板上就是一张静静躺着的卡片，谁也不会注意。但在问题+标签体系里，我可以用一个简单的规则把它揪出来：任何处于status:开发中或status:待处理且超过 7 天没有任何评论、提交、标签变更的问题，自动打上status:阻塞并通知负责人。

这个规则我用了很久，效果非常好。它逼着团队要么推进问题，要么明确说明为什么卡住。很多被遗忘的任务就是这样被重新激活的。注意阈值不要设太短，7 天是个比较合理的值，太短会频繁误报，太长就失去意义了。

5. 可视化：不画图，而是让数据自己说话

5.1 用查询代替图表

一提到"可视化进度"，很多人第一反应是画燃尽图、累积流量图。但这些图表的问题是：它们需要额外维护数据源，而且一旦没人看就失去意义。我的做法是反过来的：不主动画图，而是把常用的进度查询保存成固定视图，需要的时候点一下就能看到。

比如我会保存这几个查询：

• 所有status:开发中的问题，按更新时间排序
• 所有status:阻塞的问题，按创建时间排序
• 本周新创建且仍未关闭的问题
• 按area:标签分组统计各模块的未完成问题数

这些查询在项目托管平台里都是原生支持的，不需要写代码，配置一次就能长期使用。它们的价值在于：每次打开都是实时的，不需要人去更新数据。这比一张需要手动维护的燃尽图可靠得多。

5.2 给 AI 一个"进度摘要"接口

如果 AI 要参与开发，它需要知道"现在整体进度如何、我该做什么"。我的做法是提供一个简单的摘要脚本，输出当前所有未完成问题的结构化列表：

{ "in_progress": [ {"id": 123, "title": "登录重试逻辑", "area": "登录", "updated": "2024-01-15"} ], "blocked": [ {"id": 456, "title": "支付超时处理", "area": "支付", "reason": "等待接口文档"} ], "pending": [ {"id": 789, "title": "用户头像上传", "area": "个人中心"} ] }

AI 读这个 JSON，就能清楚地知道哪些任务在进行、哪些卡住了、哪些还没开始。然后它可以基于这个列表给出建议，比如"建议先处理阻塞的支付问题，因为它影响其他任务"或者"登录重试逻辑已经进行三天了，需要确认是否有困难"。

这个接口不需要多复杂，一个几十行的脚本就能生成。但它是人类和 AI 共享进度认知的关键桥梁。

5.3 每日摘要：让进度主动找人

可视化不一定要等人来看，也可以主动推送。我配置了一个每日定时任务，在固定时间把当天的进度摘要发到团队频道：

• 昨天完成了哪些问题
• 今天计划推进哪些问题
• 有哪些问题处于阻塞状态需要关注
• 有哪些问题超过一周没有更新

这个摘要完全由脚本生成，不需要人写。它的作用是让进度信息主动出现在大家眼前，而不是等着谁去打开看板。实测下来，有了每日摘要之后，团队对整体进度的感知明显提升，站会也开得更短了，因为大家已经提前知道了情况。

6. 和 AI 协作时的几个实操细节

6.1 让 AI 读问题，而不是读代码库

很多人让 AI 参与开发时，习惯把整个代码库丢给它，结果 token 消耗巨大，效果还不好。我的做法是：让 AI 先读问题，再根据问题里的"AI 上下文"区块去读指定文件。这样 AI 的输入是高度聚焦的，既省 token 又准确。

具体流程是：AI 读取一个status:待处理的问题，理解背景和期望结果，然后读取"AI 上下文"里列出的文件，给出实现方案。方案以评论形式写回问题，人审核后再决定是否让 AI 生成代码。这个流程把 AI 的输出限制在"方案"层面，人始终掌握决策权，风险可控。

6.2 AI 的产出也要打标签

AI 生成的方案或代码，同样需要被追踪。我的做法是给 AI 参与的问题额外打一个ai:参与标签，这样后续可以统计"AI 参与的问题平均解决时间"和"AI 方案被采纳的比例"。这些数据能帮你判断 AI 在哪些类型的任务上真正有用，哪些类型上还不如人。

注意ai:参与是独立维度，不要和status:混在一起。一个问题是status:开发中的同时可以是ai:参与，两者不冲突。

6.3 不要让 AI 直接改状态标签

这一点很重要：AI 可以建议状态变更，但不应该直接执行。原因是状态变更往往涉及人的判断，比如"这个算不算验证通过"需要人来确认。如果让 AI 自动关闭问题，很容易出现"AI 觉得做完了但实际没做完"的情况。

我的做法是：AI 在评论里写"建议将此问题切换到status:待验证"，然后由人确认后手动切换，或者由人触发的自动化脚本来切换。这样既利用了 AI 的判断力，又保留了人的最终控制权。

7. 踩过的坑和对应的解法

7.1 标签打得太细，反而没人用

我一开始设计标签体系时，状态标签设了八个，类型标签设了十个，归属标签按模块设了二十多个。结果就是：创建问题时面对一长串标签不知道选哪个，最后干脆不选。整个体系形同虚设。

解法：砍到最少可用集。状态五个、类型四个、归属按实际模块数但不建议超过十五个。宁可粗一点，也要保证每个标签都有人用。用不到的标签就是噪音。

7.2 自动化脚本误伤历史问题

有一次我写了一个脚本，把所有超过 30 天未更新的问题自动关闭。结果它把一批"长期规划"的问题也关掉了，因为这些问题的特点就是长期不动。团队发现后很生气，因为那些问题虽然不紧急但确实还需要保留。

解法：自动化规则一定要加白名单或排除条件。比如"长期规划"类的问题打一个type:规划标签，脚本跳过这类问题。任何批量操作之前，先在测试环境跑一遍，确认影响范围。

7.3 分支命名规范执行不到位

前面说过分支命名规范是自动化的前提，但实际推行时总有人忘记。我试过在代码评审时提醒，效果一般；后来改成在推送前用钩子脚本强制检查，不符合规范直接拒绝，效果立竿见影。

解法：把规范检查前置到推送环节，而不是依赖人的自觉。钩子脚本不需要多复杂，一个正则匹配就能搞定。关键是拒绝要给出明确提示，告诉开发者正确的命名格式是什么，而不是只说"命名不规范"。

7.4 AI 读不懂模糊的问题描述

有一次我让 AI 处理一个status:待处理的问题，问题是"优化一下加载速度"。AI 给出的方案非常泛泛，因为问题本身就没有说清楚优化哪里、目标是什么。这不是 AI 的问题，是问题描述的问题。

解法：问题模板里的"期望结果"和"验收标准"必须可量化。比如改成"首屏加载时间从 3 秒降到 1.5 秒以内"，AI 就能给出有针对性的方案。问题描述的质量直接决定 AI 协作的质量，这一点怎么强调都不过分。

7.5 每日摘要没人看

我一开始把每日摘要发到团队频道，结果发现没人认真看，消息很快被其他聊天刷走了。后来我改成只在有阻塞问题或超期问题时才发摘要，没有异常就不发。这样摘要出现的频率降低了，但每次出现都意味着"有事需要关注"，打开率明显提升。

解法：通知的价值在于稀缺性。如果每天都发一样的东西，大家就会自动忽略。只在真正需要关注的时候发，才能保持通知的有效性。

8. 从零搭建这套体系的落地步骤

如果你看到这里想动手试试，我建议按这个顺序来，不要一次全上：

1. 第一步，先建状态标签。只建五个：status:待处理、status:开发中、status:待验证、status:已完成、status:阻塞。手动用一周，感受一下够不够用。
2. 第二步，加问题模板。把背景、期望结果、当前状态、验收标准四个区块加到问题创建流程里。这一步不需要任何技术配置，改一下模板设置就行。
3. 第三步，配自动化流转。从最简单的开始：问题创建自动打status:待处理，问题关闭自动打status:已完成。跑通之后再逐步加分支关联、合并请求关联。
4. 第四步，加每日摘要。先手动写几天，看看哪些信息真正有用，然后再用脚本自动化。
5. 第五步，接入 AI。等前面几步稳定运行至少两周后，再让 AI 参与。AI 读问题、给方案、人审核，这个流程跑顺了再考虑更深的集成。

这个顺序的核心逻辑是：先让流程在人之间跑通，再引入自动化，最后引入 AI。反过来做，很容易因为流程本身没理顺，导致自动化和 AI 都在处理混乱的输入，效果自然好不了。

我个人在实际操作中的体会是，这套体系最大的价值不在于"可视化"本身，而在于它把开发进度从"需要人维护的状态"变成了"开发过程的自然副产品"。问题本来就要建，标签本来就可以自动打，进度信息只是这两者的组合产物。当进度不再需要额外维护时，它才真正可靠。至于 AI，它在这套体系里不是主角，而是一个能读懂结构化进度、能给出针对性建议的协作者。把基础设施搭好，AI 的价值自然就体现出来了。