最近我把团队的DevOps流程整个重排了一遍核心方法可以浓缩成一句话所有工作都从一个“问题”Issue开始所有问题都挂上对应的“标签”Label再借助看板把人和AI的开发进度可视化出来。这套思路特别适合AI辅助开发已经全面铺开、但“进度全靠问、代码全靠猜”的团队。你不用再去猜AI到底在做什么只需要看问题列表和标签分布它的工作状态就全部摊在台面上。我之所以想做这个改变是因为AI辅助开发普及以后项目代码产出量增长得很快但团队的“进度感”反而退化了。以前我说“这个需求怎么样了”同事能口头讲清楚现在AI一口气提交大量代码没有人能说清哪些是完成的、哪些被测试过、哪些还卡在评审阶段。为了解决这个问题我尝试过多种办法最后真正愿意一直在用的就是问题标签驱动开发。这篇文章适合正在用AI辅助写代码的开发者、负责研发流程的DevOps工程师以及需要同时带人和AI一起干活的小团队负责人。它不依赖特别复杂的工具只用到代码托管平台自带的问题、标签、看板三项基础能力门槛很低但把规则定清楚之后效果非常直接。1. 为什么是“问题标签”驱动开发1.1 传统任务管理的三个痛点先说传统任务管理的三个痛点方便你对号入座。第一是信息散落。需求详情躺在文档里拆解结论留在会议室白板上完成进度记在每个人脑子里。日常站会能补一部分但只要是散落的信息就一定会有丢失。人可以靠追问找回来可追问本身也是成本追问多了团队就会烦。第二是状态失真。看板上的状态靠人手工维护大家忙起来就不记得更新。代码明明已经改了问题还停在“待开始”代码早就停滞状态还是“进行中”。状态一旦失真看板就从管理工具退化成一张装饰图没人愿意看也没人敢信。第三是黑盒化。这一点是AI加入之后才痛起来的。人类开发者至少会在群里说“我卡住了”而AI不会主动说它只会等到你质问时才回应。于是AI生产代码的过程几乎没有过程信息提交通道很热闹但没有一条记录解释“为什么写、写到哪一步、是否符合预期”。结果就是代码量上去了团队对项目的理解却变浅了。这三个痛点叠加在一起团队会陷入一种很分裂的状态一方面速度感很强因为提交通道里全是活动另一方面掌控感很弱因为没人能在某个时刻回答“我们到底完成到什么程度”。我最后得出的结论是与其增加更多会议和报告不如把所有开发活动统一挂到问题这条主线上来。1.2 问题要成为唯一事实源而不是另一套文档很多团队把问题当“提需求的入口”我觉得这是远远不够的。问题标签驱动的用意是把问题变成整个开发流程的“唯一事实源”。什么叫唯一事实源就是当你想知道“某个功能做到哪一步了、谁在做、怎么做的、遇到什么问题”你只需要打开那一个问题不需要再翻其他系统。要让问题成为唯一事实源需要做到三件事。第一所有代码改动都通过关联问题来表达没有问题的提交要接受检查。第二所有决策性讨论尽量沉淀到问题评论区而不是散落在聊天工具里。第三状态的变更由真实开发动作触发而不是靠记忆手工改。这个习惯一旦养成团队协作会出现一个明显变化新人加入项目时不用挨个问人“过去发生了什么”把历史问题按标签筛选一遍项目的来龙去脉就清楚了。对于AI也一样AI不用参加站会只要给它一个结构完整的问题它能知道上下文它做完事把结果写回问题评论人也知道该从哪里开始复核。在这里问题不只是一张任务卡片而是一条把人和AI串在一起的公共轨道。1.3 为什么这个方法特别适合人机协作人和AI协作最大的问题不是代码能力而是“对齐”。人可以通过会议、闲聊、手势甚至语气来对齐想法AI只能理解信息结构。看起来是个劣势但从另一个角度看恰恰是问题机制的优势标题、描述、标签、状态、评论这些字段AI程序都能自动读写。我举一个实际发生过的例子。以前我刚开始用AI编码助手时给了它一句很口语的指令“把登录页做一下”。它确实生成了代码但跟我脑子里的登录页完全不是一回事。后来我把需求写成一个标准问题包括背景、验收标准和涉及范围AI的输出基本稳定在八九不离十的水平。这里的关键不是AI“理解能力变强了”而是问题模板给了它足够的约束条件。反过来AI完成任务后不仅能提交代码还能自动在问题里留下“已完成哪些验收项、测试结论是什么”。人类开发者不用反复追问“你做了什么”扫一眼评论就够了。所以问题标签驱动开发本质上是为人机协作设计的一种“结构化对话协议”。谁能更早建立这套协议谁就能让AI产出变得可控也就真正做到了标题里说的“可视化你和AI的开发进度”。2. 标签体系怎么设计一套能直接用的方案2.1 用“前缀分类法”避免标签失控标签设计是这套流程里最容易被低估的环节。很多人一开始建标签很随意遇到“紧急需求”就建一个“加急”遇到“要写文档”就建一个“写文档”几个月后标签列表上百个筛选时根本不知道选什么流程自然就崩了。我推荐的解法是“前缀分类法”也就是所有标签统一写成“维度:取值”的形式比如status:todo、type:bug、agent:human。这种做法有三个好处。第一自解释性强任何人看到pri:high都能猜出是“高优先级”不用翻标签说明。第二筛选效率高代码托管平台的查找功能支持前缀匹配输入“agent:”就能列出所有角色类标签。第三防重复同一维度下的取值是收敛的不会出现“高优”和“紧急”两个含义类似的标签。在团队里我还加了一条规则新增标签前必须先看现有列表确认这个维度是否已经存在如果只是新增一个取值必须在周会上说明理由。这个门槛不高但能挡住大部分随手建标签的冲动。标签这东西数量一旦失控筛选列表本身就成了噪音问题标签驱动也就名存实亡。2.2 五个基础维度够用了我这套流程长期使用的维度只有五个状态、类型、优先级、角色、复杂度。下面分开讲。状态维度解决的是“做到哪一步了”取值固定为todo、in-progress、review、done。这四个状态正好对应看板的四列不搞多余的“待测试”“待部署”这类中间态因为那种状态很难维护宁可合并到评审列里用评论说明。类型维度解决的是“这是什么性质的工作”取值是feature、bug、chore、docs。它的作用不只是分类也能用来筛选工作重心。比如一周里dones的标签全是feature、没有bug那代码质量隐患就要引起注意。优先级维度解决的是“先做什么”取值是high、medium、low。这里我建议优先级标签宁少勿多只有三个档位。因为档位一旦细分每个人都会觉得自己手里的活是高优最后等于没有优先级。复杂度维度解决的是“工作量大小”取值是s、m、l。它对人和AI协作特别有用。拆任务时如果一个问题被判定为l通常建议再拆成几个小问题保证每次交付都能被快速验证不会拖成跨数周的大工程。2.3 角色标签怎么划分人和AI的边界五个维度里我想特别强调角色维度因为“可视化你和AI的开发进度”就靠它。我只定义两个标签agent:human和agent:ai含义是这个问题最终由谁负责执行。规则很简单但执行起来要小心一个边界AI参与了代码生成不代表这个问题属于agent:ai。判断标准是“谁对结果负责”。如果是人全程主导AI只负责片段式辅助比如补了一个函数、跑了一次测试那核心执行者仍然是人类标签应该打agent:human。只有当AI从分析需求、编写代码到验证结果全程独立完成并且有人对它输出的最终质量负责时才适合打agent:ai。这样做的好处是统计出来的“AI这周完成多少个问题”不会虚高我们在审查时也知道哪些代码需要特别注意。另一个容易被忽略的点是agent标签会变化。一个问题刚创建时可能标agent:human后来人判断这个任务足够规整、可以交给AI独立做就要同步把标签改成agent:ai。不要代码和数据结构都改了只剩下标签没更新那会让后续所有统计失真。2.4 一份可以直接抄的最小标签清单下面这份清单是我在真实项目里验证过的总数不到20个足以覆盖日常开发。你可以直接复制过去再按团队情况微调。维度标签含义状态status:todo待开始状态status:in-progress进行中状态status:review待评审状态status:done已完成类型type:feature新功能类型type:bug缺陷修复类型type:chore工程杂项类型type:docs文档优先级pri:high高优先级优先级pri:medium中优先级优先级pri:low低优先级角色agent:human人工执行角色agent:aiAI独立执行复杂度size:s小复杂度size:m中复杂度size:l大如果你确实需要按模块统计我建议不要急着加module标签。先算算看是不是真的有人在周报里统计“前端完成了多少、后端完成了多少”大多数团队其实只需要状态和类型维度就能管好日常。标签一旦超过20个维护意愿会迅速下降这套流程就会慢慢失效。记住标签是给人做筛选用的不是给平台堆展示量的。3. 问题模板与状态流转规范怎么定3.1 模板里的关键字段验收标准最重要标签把问题分门别类问题模板则负责让每个任务都清晰可执行。我打磨过多版模板最终留下的字段并不多但每项都有明确作用。标题: [类型] 一句话说清楚要做什么 ## 背景 为什么做这件事服务谁解决什么问题 ## 目标 完成后应该让用户或系统达到什么状态 ## 验收标准 1. 可以... 2. 必须... 3. 不能... ## 涉及范围 - 模块/服务 ## 依赖与关联 - 关联问题 ## 测试要求 - [ ] 单元测试 - [ ] 手工验收模板里最重要的其实是“验收标准”。我见过不少问题写得很长背景讲得天花乱坠但看完整个人还是不知道“做完了”长什么样。没有可勾选的验收项人和AI都会靠猜测来填空。我的习惯是每条验收标准都写成可以被测试或检查的短句比如“支持通过手机号登录”而不是“提升用户体验”。这条细节直接影响后续开发质量值得多花几分钟去写。3.2 四步状态流转让开发动作自动推动状态有模板之后还得有流程。我把问题状态变化规定为四步闭环todo、in-progress、review、done并且让真实开发事件去推动状态而不是靠人手工记。第一步从todo到in-progress执行者真正开始动手时先创建开发分支再改状态。分支名我建议写成“问题编号-简短描述”比如“128-fix-login-bug”。这样分支本身就能反查问题后面做自动化判断时也有依据。第二步从in-progress到review提交代码并创建合并请求时必须在描述里关联问题编号然后把状态改为review。如果你还用了自动化脚本可以在检测到关联关系后自动改状态省掉人工操作。第三步从review到done合并完成后由机器人或脚本检测合并事件自动关闭问题、打上status:done。这一步最关键它砍掉了“记得去关问题”这件事。我实测下来谁都会忘记去关问题但机器不会。第四步异常回退如果审查发现问题应把状态从review拉回in-progress并在评论里写明返工原因不要直接改代码却留着review状态。否则看板会告诉你“在评审”代码却已经变了状态又一次失真。这套流程没有添加多少“额外动作”每个步骤都跟真实开发行为一一对应。跑顺之后你会发现看板上的状态不再依赖某个人记得更新而是开发动作的副产品这是它比我以前用过的任何任务管理表都可靠的原因。3.3 提交信息与问题绑定怎么防止失联整套流程里最容易被钻空子的是“改了代码但不关联问题”。代码一多提交历史和问题之间对不上标签统计自然失真可视化也就成了空中楼阁。我在团队里用的是双保险。第一道是约定分支名带问题编号提交信息至少写一行“fix #编号”这样的关联语句。第二道是强制在DevOps流水线里加一个检查步骤凡是本次改动里没有任何一条提交信息关联问题流水线就把它标记为“未关联改动”需要人工确认才能进入合并。实测下来这种“约定强制”的组合能把关联率从60%左右拉到95%以上。剩下一小部分确实是实验性或临时改动人工确认后放行不会误伤。你如果不想一开始就上流水线检查也可以先只在项目文档里立规矩但我的建议是既然做了问题标签驱动就把这道检查尽早自动化否则很快会有大量改动重新变成“游离态”前面花的时间就白费了。4. 可视化让人和AI的进度一目了然4.1 看板怎么搭列和泳道的分配基础可视化直接用代码托管平台自带的看板功能就能实现。第一步把看板列设置为To Do、In Progress、Review、Done分别对应status:todo、status:in-progress、status:review、status:done。这样每个问题按当前状态进对应列一个最朴素的进度视图就有了。第二步加上“泳道”。泳道可以理解为看板里横向的分隔区域。我把泳道按agent标签设置成三条agent:human、agent:ai、尚未标注。这样一来同一个看板上你能同时看到“人的活”和“AI的活”各自分布在哪一列。如果某个泳道的In Progress列堆得很高、Review列却是空的问题就立刻被暴露出来。4.2 第一次搭完我看到的人机失衡我第一次把这套看板搭出来的当天就发现了一个扎心的事实agent:ai泳道里In Progress有十几个问题Review却是零。这说明AI批量完成了任务但人还没有时间去审查。在旧的流程里这种风险要等到快上线时才会爆发有了按角色分的看板问题在两天内就被识别出来了。这种失衡还有另一个方向agent:human泳道的Review列堆积说明人的代码在排队等检查或测试这时可以考虑把一部分规整的检查工作交给AI自动化脚本。两种泳道一对照人机协作的瓶颈到底是“AI写太多、人看不过来”还是“人在等着AI反馈”不再需要靠开会讨论来猜。这就是“可视化你和AI的开发进度”最直接的价值。4.3 多项目时的分组视图和报表口径项目一多按单一看板汇报就不够。我通常会在之前分组的基础上再增加“类型”维度feature、bug、chore、docs。此时一个比较实用的视图是“行执行角色列状态卡片颜色类型”。它能回答很多管理问题比如这周AI处理的bug是不是还压在评审列人工处理的feature还有几项没开始。如果你要做正式周报我反而建议不要让看板承担所有统计工作。看板适合日常追踪不适合做大报表。我一般把问题列表导出成表格再用透视表按标签汇总算出来的数据又快又不容易看错团队也更愿意认可。记住可视化是为了让人快速做判断不是为了展示花哨的仪表盘。4.4 四个值得长期跟踪的进度指标可视化做到位以后可以升级成数据驱动的管理。我固定跟踪四个指标它们都直接从问题和标签里算出来不需要额外填报。吞吐量每周进入done状态的问题数量按agent分组。它反映人和AI的交付速度差异。周期时间每个问题从in-progress到done的时长分别取人和AI的中位数。它反映交付链路是否顺畅。缺陷回流率一个问题完成后两周内是否又新增了关联的type:bug。如果AI的完成项回流率明显偏高说明需要增加对AI产出的审查强度。积压时间高优先级问题停留在todo超过3天的数量它提醒团队及时处理最重要的事。这组指标出现最多的规律是AI的单问题处理速度和吞吐量都占优但真正的瓶颈集中在人审环节。所以我在团队里逐渐形成了一个共识AI不是用来替代评审的问题标签驱动的落点是让人能把有限的注意力花在最值得负责的地方。这个认知调整比任何工具选型都重要。5. 实操中踩过的坑与排查建议5.1 标签爆炸一份带教训的清洗记录我第一次推行这套流程时标签体系建得很随意。三个月后标签已经接近50个里面还有“紧急!今天做”“等设计师出图”“先跑通再说”这类完全无法归类的标签。结果是谁都不愿意用筛选标签形同虚设。后来我做了一次彻底清洗把所有标签映射回五个维度不符合维度的直接删除。同时立下规则创建新标签必须过前缀分类的检查否则不允许建。半年后再看标签数量稳定在20个以内每个都被复用流程才真正站住了脚。这里想提醒一句如果一个标签在两周内没有被任何新问题引用它对流程就没有价值应该及时删掉或者并入现有标签。定期清理和前缀命名同等重要。5.2 AI提交的问题“看起来很完整实际没边界”AI很会生成格式工整的文本所以让AI直接写问题时最怕的就是“看起来什么都写了其实什么都没定”。典型表现是验收标准写成“确保系统稳定”“体验顺畅”这种根本无法验证的句子。我的对策是两段式AI先按模板起草问题人再做一次结构评审专门检查验收标准是否每一条都能被勾选验证。如果某条标准不能被测试或观察就退回改写。多出这一步后AI后续产出的偏差明显减少返工成本也低很多。整个过程并不复杂关键是“验收标准可勾选”这条硬门槛要有不能省略。5.3 假In Progress状态被卡在中间层另一种常见问题是状态虚高问题停在in-progress但对应分支已经两周没有任何提交。这通常意味着执行者早停下来了状态却没跟着变。如果不管看板会长期显示“好几个任务在做”给管理决策提供错误信号。我给这个坑配了一个自动化扫描脚本定期检查所有in-progress的问题是否有近期提交活动如果超过3天没有活动就会在看板上标记为“疑似停滞”提醒执行者确认状态。这个脚本不需要多复杂调用代码托管平台的查询接口就能实现关键是把“真相”摆进看板里而不是美化一切。5.4 改动和问题失联流水线检查是最后的防线即使定下分支名和提交信息规范总有人会在赶工期时漏掉关联。这种情况如果只是偶尔发生影响不大但一旦成为习惯标签统计就失真“人和AI的进度可视化”也就失去了意义。所以我始终建议把“必须关联问题”变成流水线里的硬校验。检查规则很简单本次改动相关的提交信息中至少有一条包含“#问题编号”否则流水线标黄需要人工确认。这种硬约束虽然不是最早加入的但效果最好比任何口头强调都可靠。如果你只做一件自动化我建议就做它。5.5 自动化到哪一步就够最后说说自动化该做多少。我的看法是自动化围绕“事件驱动”做四件事就够第一版用了。新建问题时检查模板和标签是否完整不完整的自动评论提醒。检测到分支创建事件时把关联问题的状态自动改为in-progress。检测到合并请求关联问题时自动把状态改为review合入后自动关闭问题并标记done。定时扫描停滞问题输出警告清单。这四件事都不高大上但覆盖了流程里最容易出现“人忘了更新”的地方。你不需要一开始就把所有自动化都搭好可以先手动跑两周让团队熟悉规则再挑抱怨最多的那一环节做脚本化。整套流程的意义不是让工具变复杂而是让开发进度能在问题标签的轨道上自动流动最终变成你抬眼就能看到的视图。我自己的体会是这套流程最值得的地方不是“管住了AI”而是让团队终于能在任何一天回答“人和AI到底做到哪了”。如果你也被“AI写了很多代码、进度却说不清”的问题折磨先别急着换工具。把第一个问题写好给它贴上标签然后让看板告诉你答案。 
长河君 · 2026/10/22 16:52:06 · 阅读 1.2k 问题+标签驱动开发：让AI辅助开发进度一目了然
最近我把团队的DevOps流程整个重排了一遍核心方法可以浓缩成一句话所有工作都从一个“问题”Issue开始所有问题都挂上对应的“标签”Label再借助看板把人和AI的开发进度可视化出来。这套思路特别适合AI辅助开发已经全面铺开、但“进度全靠问、代码全靠猜”的团队。你不用再去猜AI到底在做什么只需要看问题列表和标签分布它的工作状态就全部摊在台面上。我之所以想做这个改变是因为AI辅助开发普及以后项目代码产出量增长得很快但团队的“进度感”反而退化了。以前我说“这个需求怎么样了”同事能口头讲清楚现在AI一口气提交大量代码没有人能说清哪些是完成的、哪些被测试过、哪些还卡在评审阶段。为了解决这个问题我尝试过多种办法最后真正愿意一直在用的就是问题标签驱动开发。这篇文章适合正在用AI辅助写代码的开发者、负责研发流程的DevOps工程师以及需要同时带人和AI一起干活的小团队负责人。它不依赖特别复杂的工具只用到代码托管平台自带的问题、标签、看板三项基础能力门槛很低但把规则定清楚之后效果非常直接。1. 为什么是“问题标签”驱动开发1.1 传统任务管理的三个痛点先说传统任务管理的三个痛点方便你对号入座。第一是信息散落。需求详情躺在文档里拆解结论留在会议室白板上完成进度记在每个人脑子里。日常站会能补一部分但只要是散落的信息就一定会有丢失。人可以靠追问找回来可追问本身也是成本追问多了团队就会烦。第二是状态失真。看板上的状态靠人手工维护大家忙起来就不记得更新。代码明明已经改了问题还停在“待开始”代码早就停滞状态还是“进行中”。状态一旦失真看板就从管理工具退化成一张装饰图没人愿意看也没人敢信。第三是黑盒化。这一点是AI加入之后才痛起来的。人类开发者至少会在群里说“我卡住了”而AI不会主动说它只会等到你质问时才回应。于是AI生产代码的过程几乎没有过程信息提交通道很热闹但没有一条记录解释“为什么写、写到哪一步、是否符合预期”。结果就是代码量上去了团队对项目的理解却变浅了。这三个痛点叠加在一起团队会陷入一种很分裂的状态一方面速度感很强因为提交通道里全是活动另一方面掌控感很弱因为没人能在某个时刻回答“我们到底完成到什么程度”。我最后得出的结论是与其增加更多会议和报告不如把所有开发活动统一挂到问题这条主线上来。1.2 问题要成为唯一事实源而不是另一套文档很多团队把问题当“提需求的入口”我觉得这是远远不够的。问题标签驱动的用意是把问题变成整个开发流程的“唯一事实源”。什么叫唯一事实源就是当你想知道“某个功能做到哪一步了、谁在做、怎么做的、遇到什么问题”你只需要打开那一个问题不需要再翻其他系统。要让问题成为唯一事实源需要做到三件事。第一所有代码改动都通过关联问题来表达没有问题的提交要接受检查。第二所有决策性讨论尽量沉淀到问题评论区而不是散落在聊天工具里。第三状态的变更由真实开发动作触发而不是靠记忆手工改。这个习惯一旦养成团队协作会出现一个明显变化新人加入项目时不用挨个问人“过去发生了什么”把历史问题按标签筛选一遍项目的来龙去脉就清楚了。对于AI也一样AI不用参加站会只要给它一个结构完整的问题它能知道上下文它做完事把结果写回问题评论人也知道该从哪里开始复核。在这里问题不只是一张任务卡片而是一条把人和AI串在一起的公共轨道。1.3 为什么这个方法特别适合人机协作人和AI协作最大的问题不是代码能力而是“对齐”。人可以通过会议、闲聊、手势甚至语气来对齐想法AI只能理解信息结构。看起来是个劣势但从另一个角度看恰恰是问题机制的优势标题、描述、标签、状态、评论这些字段AI程序都能自动读写。我举一个实际发生过的例子。以前我刚开始用AI编码助手时给了它一句很口语的指令“把登录页做一下”。它确实生成了代码但跟我脑子里的登录页完全不是一回事。后来我把需求写成一个标准问题包括背景、验收标准和涉及范围AI的输出基本稳定在八九不离十的水平。这里的关键不是AI“理解能力变强了”而是问题模板给了它足够的约束条件。反过来AI完成任务后不仅能提交代码还能自动在问题里留下“已完成哪些验收项、测试结论是什么”。人类开发者不用反复追问“你做了什么”扫一眼评论就够了。所以问题标签驱动开发本质上是为人机协作设计的一种“结构化对话协议”。谁能更早建立这套协议谁就能让AI产出变得可控也就真正做到了标题里说的“可视化你和AI的开发进度”。2. 标签体系怎么设计一套能直接用的方案2.1 用“前缀分类法”避免标签失控标签设计是这套流程里最容易被低估的环节。很多人一开始建标签很随意遇到“紧急需求”就建一个“加急”遇到“要写文档”就建一个“写文档”几个月后标签列表上百个筛选时根本不知道选什么流程自然就崩了。我推荐的解法是“前缀分类法”也就是所有标签统一写成“维度:取值”的形式比如status:todo、type:bug、agent:human。这种做法有三个好处。第一自解释性强任何人看到pri:high都能猜出是“高优先级”不用翻标签说明。第二筛选效率高代码托管平台的查找功能支持前缀匹配输入“agent:”就能列出所有角色类标签。第三防重复同一维度下的取值是收敛的不会出现“高优”和“紧急”两个含义类似的标签。在团队里我还加了一条规则新增标签前必须先看现有列表确认这个维度是否已经存在如果只是新增一个取值必须在周会上说明理由。这个门槛不高但能挡住大部分随手建标签的冲动。标签这东西数量一旦失控筛选列表本身就成了噪音问题标签驱动也就名存实亡。2.2 五个基础维度够用了我这套流程长期使用的维度只有五个状态、类型、优先级、角色、复杂度。下面分开讲。状态维度解决的是“做到哪一步了”取值固定为todo、in-progress、review、done。这四个状态正好对应看板的四列不搞多余的“待测试”“待部署”这类中间态因为那种状态很难维护宁可合并到评审列里用评论说明。类型维度解决的是“这是什么性质的工作”取值是feature、bug、chore、docs。它的作用不只是分类也能用来筛选工作重心。比如一周里dones的标签全是feature、没有bug那代码质量隐患就要引起注意。优先级维度解决的是“先做什么”取值是high、medium、low。这里我建议优先级标签宁少勿多只有三个档位。因为档位一旦细分每个人都会觉得自己手里的活是高优最后等于没有优先级。复杂度维度解决的是“工作量大小”取值是s、m、l。它对人和AI协作特别有用。拆任务时如果一个问题被判定为l通常建议再拆成几个小问题保证每次交付都能被快速验证不会拖成跨数周的大工程。2.3 角色标签怎么划分人和AI的边界五个维度里我想特别强调角色维度因为“可视化你和AI的开发进度”就靠它。我只定义两个标签agent:human和agent:ai含义是这个问题最终由谁负责执行。规则很简单但执行起来要小心一个边界AI参与了代码生成不代表这个问题属于agent:ai。判断标准是“谁对结果负责”。如果是人全程主导AI只负责片段式辅助比如补了一个函数、跑了一次测试那核心执行者仍然是人类标签应该打agent:human。只有当AI从分析需求、编写代码到验证结果全程独立完成并且有人对它输出的最终质量负责时才适合打agent:ai。这样做的好处是统计出来的“AI这周完成多少个问题”不会虚高我们在审查时也知道哪些代码需要特别注意。另一个容易被忽略的点是agent标签会变化。一个问题刚创建时可能标agent:human后来人判断这个任务足够规整、可以交给AI独立做就要同步把标签改成agent:ai。不要代码和数据结构都改了只剩下标签没更新那会让后续所有统计失真。2.4 一份可以直接抄的最小标签清单下面这份清单是我在真实项目里验证过的总数不到20个足以覆盖日常开发。你可以直接复制过去再按团队情况微调。维度标签含义状态status:todo待开始状态status:in-progress进行中状态status:review待评审状态status:done已完成类型type:feature新功能类型type:bug缺陷修复类型type:chore工程杂项类型type:docs文档优先级pri:high高优先级优先级pri:medium中优先级优先级pri:low低优先级角色agent:human人工执行角色agent:aiAI独立执行复杂度size:s小复杂度size:m中复杂度size:l大如果你确实需要按模块统计我建议不要急着加module标签。先算算看是不是真的有人在周报里统计“前端完成了多少、后端完成了多少”大多数团队其实只需要状态和类型维度就能管好日常。标签一旦超过20个维护意愿会迅速下降这套流程就会慢慢失效。记住标签是给人做筛选用的不是给平台堆展示量的。3. 问题模板与状态流转规范怎么定3.1 模板里的关键字段验收标准最重要标签把问题分门别类问题模板则负责让每个任务都清晰可执行。我打磨过多版模板最终留下的字段并不多但每项都有明确作用。标题: [类型] 一句话说清楚要做什么 ## 背景 为什么做这件事服务谁解决什么问题 ## 目标 完成后应该让用户或系统达到什么状态 ## 验收标准 1. 可以... 2. 必须... 3. 不能... ## 涉及范围 - 模块/服务 ## 依赖与关联 - 关联问题 ## 测试要求 - [ ] 单元测试 - [ ] 手工验收模板里最重要的其实是“验收标准”。我见过不少问题写得很长背景讲得天花乱坠但看完整个人还是不知道“做完了”长什么样。没有可勾选的验收项人和AI都会靠猜测来填空。我的习惯是每条验收标准都写成可以被测试或检查的短句比如“支持通过手机号登录”而不是“提升用户体验”。这条细节直接影响后续开发质量值得多花几分钟去写。3.2 四步状态流转让开发动作自动推动状态有模板之后还得有流程。我把问题状态变化规定为四步闭环todo、in-progress、review、done并且让真实开发事件去推动状态而不是靠人手工记。第一步从todo到in-progress执行者真正开始动手时先创建开发分支再改状态。分支名我建议写成“问题编号-简短描述”比如“128-fix-login-bug”。这样分支本身就能反查问题后面做自动化判断时也有依据。第二步从in-progress到review提交代码并创建合并请求时必须在描述里关联问题编号然后把状态改为review。如果你还用了自动化脚本可以在检测到关联关系后自动改状态省掉人工操作。第三步从review到done合并完成后由机器人或脚本检测合并事件自动关闭问题、打上status:done。这一步最关键它砍掉了“记得去关问题”这件事。我实测下来谁都会忘记去关问题但机器不会。第四步异常回退如果审查发现问题应把状态从review拉回in-progress并在评论里写明返工原因不要直接改代码却留着review状态。否则看板会告诉你“在评审”代码却已经变了状态又一次失真。这套流程没有添加多少“额外动作”每个步骤都跟真实开发行为一一对应。跑顺之后你会发现看板上的状态不再依赖某个人记得更新而是开发动作的副产品这是它比我以前用过的任何任务管理表都可靠的原因。3.3 提交信息与问题绑定怎么防止失联整套流程里最容易被钻空子的是“改了代码但不关联问题”。代码一多提交历史和问题之间对不上标签统计自然失真可视化也就成了空中楼阁。我在团队里用的是双保险。第一道是约定分支名带问题编号提交信息至少写一行“fix #编号”这样的关联语句。第二道是强制在DevOps流水线里加一个检查步骤凡是本次改动里没有任何一条提交信息关联问题流水线就把它标记为“未关联改动”需要人工确认才能进入合并。实测下来这种“约定强制”的组合能把关联率从60%左右拉到95%以上。剩下一小部分确实是实验性或临时改动人工确认后放行不会误伤。你如果不想一开始就上流水线检查也可以先只在项目文档里立规矩但我的建议是既然做了问题标签驱动就把这道检查尽早自动化否则很快会有大量改动重新变成“游离态”前面花的时间就白费了。4. 可视化让人和AI的进度一目了然4.1 看板怎么搭列和泳道的分配基础可视化直接用代码托管平台自带的看板功能就能实现。第一步把看板列设置为To Do、In Progress、Review、Done分别对应status:todo、status:in-progress、status:review、status:done。这样每个问题按当前状态进对应列一个最朴素的进度视图就有了。第二步加上“泳道”。泳道可以理解为看板里横向的分隔区域。我把泳道按agent标签设置成三条agent:human、agent:ai、尚未标注。这样一来同一个看板上你能同时看到“人的活”和“AI的活”各自分布在哪一列。如果某个泳道的In Progress列堆得很高、Review列却是空的问题就立刻被暴露出来。4.2 第一次搭完我看到的人机失衡我第一次把这套看板搭出来的当天就发现了一个扎心的事实agent:ai泳道里In Progress有十几个问题Review却是零。这说明AI批量完成了任务但人还没有时间去审查。在旧的流程里这种风险要等到快上线时才会爆发有了按角色分的看板问题在两天内就被识别出来了。这种失衡还有另一个方向agent:human泳道的Review列堆积说明人的代码在排队等检查或测试这时可以考虑把一部分规整的检查工作交给AI自动化脚本。两种泳道一对照人机协作的瓶颈到底是“AI写太多、人看不过来”还是“人在等着AI反馈”不再需要靠开会讨论来猜。这就是“可视化你和AI的开发进度”最直接的价值。4.3 多项目时的分组视图和报表口径项目一多按单一看板汇报就不够。我通常会在之前分组的基础上再增加“类型”维度feature、bug、chore、docs。此时一个比较实用的视图是“行执行角色列状态卡片颜色类型”。它能回答很多管理问题比如这周AI处理的bug是不是还压在评审列人工处理的feature还有几项没开始。如果你要做正式周报我反而建议不要让看板承担所有统计工作。看板适合日常追踪不适合做大报表。我一般把问题列表导出成表格再用透视表按标签汇总算出来的数据又快又不容易看错团队也更愿意认可。记住可视化是为了让人快速做判断不是为了展示花哨的仪表盘。4.4 四个值得长期跟踪的进度指标可视化做到位以后可以升级成数据驱动的管理。我固定跟踪四个指标它们都直接从问题和标签里算出来不需要额外填报。吞吐量每周进入done状态的问题数量按agent分组。它反映人和AI的交付速度差异。周期时间每个问题从in-progress到done的时长分别取人和AI的中位数。它反映交付链路是否顺畅。缺陷回流率一个问题完成后两周内是否又新增了关联的type:bug。如果AI的完成项回流率明显偏高说明需要增加对AI产出的审查强度。积压时间高优先级问题停留在todo超过3天的数量它提醒团队及时处理最重要的事。这组指标出现最多的规律是AI的单问题处理速度和吞吐量都占优但真正的瓶颈集中在人审环节。所以我在团队里逐渐形成了一个共识AI不是用来替代评审的问题标签驱动的落点是让人能把有限的注意力花在最值得负责的地方。这个认知调整比任何工具选型都重要。5. 实操中踩过的坑与排查建议5.1 标签爆炸一份带教训的清洗记录我第一次推行这套流程时标签体系建得很随意。三个月后标签已经接近50个里面还有“紧急!今天做”“等设计师出图”“先跑通再说”这类完全无法归类的标签。结果是谁都不愿意用筛选标签形同虚设。后来我做了一次彻底清洗把所有标签映射回五个维度不符合维度的直接删除。同时立下规则创建新标签必须过前缀分类的检查否则不允许建。半年后再看标签数量稳定在20个以内每个都被复用流程才真正站住了脚。这里想提醒一句如果一个标签在两周内没有被任何新问题引用它对流程就没有价值应该及时删掉或者并入现有标签。定期清理和前缀命名同等重要。5.2 AI提交的问题“看起来很完整实际没边界”AI很会生成格式工整的文本所以让AI直接写问题时最怕的就是“看起来什么都写了其实什么都没定”。典型表现是验收标准写成“确保系统稳定”“体验顺畅”这种根本无法验证的句子。我的对策是两段式AI先按模板起草问题人再做一次结构评审专门检查验收标准是否每一条都能被勾选验证。如果某条标准不能被测试或观察就退回改写。多出这一步后AI后续产出的偏差明显减少返工成本也低很多。整个过程并不复杂关键是“验收标准可勾选”这条硬门槛要有不能省略。5.3 假In Progress状态被卡在中间层另一种常见问题是状态虚高问题停在in-progress但对应分支已经两周没有任何提交。这通常意味着执行者早停下来了状态却没跟着变。如果不管看板会长期显示“好几个任务在做”给管理决策提供错误信号。我给这个坑配了一个自动化扫描脚本定期检查所有in-progress的问题是否有近期提交活动如果超过3天没有活动就会在看板上标记为“疑似停滞”提醒执行者确认状态。这个脚本不需要多复杂调用代码托管平台的查询接口就能实现关键是把“真相”摆进看板里而不是美化一切。5.4 改动和问题失联流水线检查是最后的防线即使定下分支名和提交信息规范总有人会在赶工期时漏掉关联。这种情况如果只是偶尔发生影响不大但一旦成为习惯标签统计就失真“人和AI的进度可视化”也就失去了意义。所以我始终建议把“必须关联问题”变成流水线里的硬校验。检查规则很简单本次改动相关的提交信息中至少有一条包含“#问题编号”否则流水线标黄需要人工确认。这种硬约束虽然不是最早加入的但效果最好比任何口头强调都可靠。如果你只做一件自动化我建议就做它。5.5 自动化到哪一步就够最后说说自动化该做多少。我的看法是自动化围绕“事件驱动”做四件事就够第一版用了。新建问题时检查模板和标签是否完整不完整的自动评论提醒。检测到分支创建事件时把关联问题的状态自动改为in-progress。检测到合并请求关联问题时自动把状态改为review合入后自动关闭问题并标记done。定时扫描停滞问题输出警告清单。这四件事都不高大上但覆盖了流程里最容易出现“人忘了更新”的地方。你不需要一开始就把所有自动化都搭好可以先手动跑两周让团队熟悉规则再挑抱怨最多的那一环节做脚本化。整套流程的意义不是让工具变复杂而是让开发进度能在问题标签的轨道上自动流动最终变成你抬眼就能看到的视图。我自己的体会是这套流程最值得的地方不是“管住了AI”而是让团队终于能在任何一天回答“人和AI到底做到哪了”。如果你也被“AI写了很多代码、进度却说不清”的问题折磨先别急着换工具。把第一个问题写好给它贴上标签然后让看板告诉你答案。