1. 只聊不记的AI协作方式问题出在哪儿先把话说在前头现在很多人和AI协作开发方式基本是“开个聊天窗口把需求一贴让AI写代码改完复制粘贴跑不通继续贴报错跑通了关窗口”。我这两年见过太多团队和个人开发者都是这个状态包括我自己早期也是这么干的。最开始觉得挺爽但项目一复杂问题就像滚雪球一样全出来了。最典型的一个场景某个周一早上你打开上周和AI的聊天记录想继续改一个功能结果发现对话框里塞满了十几个需求有些改了、有些没改、有些改了一半而你自己根本记不清哪个是哪个。更离谱的是AI上下文窗口有限聊着聊着它把最初的需求忘了于是你不得不反复重申“上次那个xxx的改动还在吗”。到了上线前要做变更记录打开聊天记录从头翻到尾硬是理不出一份能交给别人的进度清单。说到底就一句话聊天窗口不是一个项目管理系统AI更不是一台听话的代码生成器。一旦AI真正参与了多个功能、多个修复任务它就成了团队里一个“看不见的成员”——你不知道它手里有几个活、每个活进展到哪、哪些活已经验收完、哪些活卡住了。这种不透明比多写几行Bug更危险。我后来把公司的代码托管平台那套“问题Issue标签Label”的流程搬到了与AI的协作里给自己定了一套规矩所有交给AI的活先建档再动手。配合看板视图和简单的标签聚合人做了什么、AI做了什么、项目整体进度走到哪一眼就能看明白。这篇文章就是把这套玩法完整拆给你看适合个人开发者、三五个人的小团队以及正打算把AI正式纳入开发流程但不知道怎么管的人。2. 让AI进入工作流一套最小可跑的Issue流转机制这个章节是整套方案的骨架。核心思路并不复杂不要直接和AI对话开工先在问题列表里建一条记录把需求、验收标准、关联模块全部写清楚然后给这条记录打上标签。这一步做完AI才真正进入你的开发流程而不是继续游离在流程之外。2.1 一需求一Issue给AI布置任务的正确姿势所谓“一需求一Issue”意思是一个独立的功能点、一个可复现的Bug、一个明确的改造任务就建一条问题记录。为什么要这么细因为AI和协作者不同它不会主动帮你拆解需求也不会问你“这一步是不是要对齐其他模块的改动”你给它的指令颗粒度决定了它产出的颗粒度。举个例子。我早期写过这样一条需求“优化一下登录模块”。这种Issue给任何人类开发都会挨骂给AI就更灾难了——它不知道你是要改密码找回流程、加单点登录还是要调样式、压缩接口耗时。AI大概率会挑它最熟悉的方向去写你和它的思路就此分叉。正确做法是拆成风格统一的多条记录“登录接口增加图形验证码参数验证码服务独立部署失败时返回自定义错误码”“登录页面增加二次确认弹窗防止用户误触碰退出按钮”“会话过期后返回401前端统一跳转登录页并保留当前页面路由”每条都是单一职责验收口径清晰。AI在处理单条Issue时的表现远好于面对一段混合了多需求的冗长指令。它对上下文的依赖越小出错概率越低你复查的成本也越低。2.2 用标签完成类型、状态、归属、优先级四维管理问题记录建好了接下来靠标签来给所有记录分门别类。标签的价值在于它把一条条散乱的Issue变成可筛选、可统计、可自动聚合的数据。我最终使用的标签体系一共四个维度简洁但覆盖面很全维度标签示例用途类型type:feature、type:bugfix、type:refactor、type:docs说明这是一件什么性质的活状态status:todo、status:doing、status:review、status:verified标记当前流转到哪个环节归属owner:ai、owner:human标明这个活主要由谁来执行优先级priority:high、priority:normal、priority:low排出先后顺序让看板排序不再靠人工记忆这套设计的妙处在于“组合查询”。比如你只需要拖一下筛选条件把所有owner:ai且status:doing的记录拉出来AI现在手上有几个活、分别是什么、卡在哪个环节比任何聊天记录都清楚。2.3 流转规则从“待办”到“已验证”的完整链路光有标签还不够关键是让问题记录按固定节奏流转。我给AI协作定下的流转链路是这样的待办todo——需求确认无误等待开工。AI不跑单人类也不插队。进行中doing——AI正在实现或人类正在改代码。一条记录同一时刻只能有一个主负责人。待复查review——AI提交了代码或方案等待人类审核。这个环节绝不能省。已验证verified——代码跑过、验收标准逐条确认、相关问题已关闭这个活才算彻底结束。开始运转后你会发现这套流程最大的价值不是“管着AI”而是把“AI做完了”和“这事真的完了”这两个概念强行分开。聊天式协作里AI说“写完了”就等于结束但在Issue机制下“写完”只是从doing挪到review还需要一个人类角色去做验证。这个门槛挡住了大量AI自以为做完、其实漏洞百出的交付。2.4 怎么强制AI遵守这套纪律听到这里你一定会问AI怎么会老老实实按Issue来它就是个聊天模型我总不能每条让它读一遍我的问题列表。我自己实践下来的办法有三个都很土但很有效第一个办法把Issue编号写进提示词。每次给AI下达开发任务时在开头明确写“请实现issue #123描述的改动验收标准见该条记录”。让它聚焦单一上下文。如果项目大、AI上下文强也可以让它自己拉取内容但对我这种中等规模项目直接粘贴已足够。第二个办法让AI的产出回填Issue。我一般要求AI在完成后输出一段“改动摘要”大意包括修改了哪些文件、如何验证、有没有遗留问题。我确认后把这些信息整理进Issue的评论或描述里。时间一长每条Issue都成了带完整上下文的项目日志。第三个办法也是最重要的你自己先当好纪律执行者。AI不会主动去关Issue也不懂你的流转规则你得在它每完成一个交付后手动推进状态。前两周可能觉得烦但一旦习惯成自然你会明显感觉到“项目可控”带来的安全感远比那一点操作成本值得。3. 进度可视化把几十个Issue变成一眼能看懂的开发地图建了Issue、打了标签、定了流转规则接下来就是让进度“看得见”。这一部分我分三步来做先聚合再上图表最后选对工具。别小看可视化这一步它直接决定了这套流程能不能坚持用下去——人都是视觉动物盯着一串列表看三天就会失去耐心但看一眼彩色看板和趋势图反而会上瘾。3.1 基于标签聚合出三种视图按类型、按状态、按模块标签给了你纵向的筛选能力而视图给你横向的全局视角。我用一套简单的三维聚合规则把Issue变为可读性很强的项目地图。第一维按状态聚合。把status:todo、status:doing、status:review、status:verified四类标签作为看板泳道所有Issue根据当前状态自动落入对应列。这就是最经典的看板视图左边是待办中间是进行中右边是待复查和已验证。每天打开一眼就能看到项目卡在哪个环节——如果review列堆了十来条说明你的复查成了瓶颈得赶一赶如果doing列长时间没有变化说明某项活可能被卡住了需要去排查。第二维按类型聚合。通常在做一个涉及面比较广的需求时用。把type:feature、type:bugfix、type:refactor分开统计你就能清楚看到本周的工作量集中在加功能还是修漏洞。我有一段时期不停堆功能bugfix数量几乎没变化后来一分析才发现问题测试覆盖一直没跟上回归全靠手动等于一边盖楼一边拆楼。没有类型维度的统计这种不健康状态很难被注意到。第三维按模块聚合。这一步是给项目打了module:auth、module:payment、module:ui这层标签之后按模块把Issue归堆。这个视图最适合做版本规划一眼可以看出哪些模块改动多、风险高、需要额外测试。模块聚合的颗粒度自己控制一个前端项目用三四个模块足够了不用拆到组件级过度细化会变成维护负担。3.2 让AI产出也进入燃尽与累积流动图标签聚合解决的是“当下的一眼视图”问题但要判断开发进度是加速还是滞后还得靠趋势图。我用的两个经典指标是燃尽图和累积流图。燃尽图本质上是看“剩余工作量”随时间的变化。先把每个Issue按复杂度或者预计耗时估一个工作量数值然后每天或者每天早晚各一次统计一次所有未完成Issue的工作量总和把点连成曲线。一条理想的曲线应该总体向下、平滑递减。实际跑起来我的曲线经常在某几天突然上跳——不用慌多半是新增了需求、加了新Issue这说明版本范围在膨胀该考虑冻结需求了。累积流图更有意思它按状态统计Issue数量并叠加面积。如果所有列的面积都在均匀增长然后又同时下降说明项目在稳定流动如果“进行中”的面积越拉越大“已验证”的面积不见增长说明任务大量积压在中游交付通道堵了。你会清楚地看到是AI产出太快导致人类复查跟不上还是AI卡在某个技术上迟迟不交付——这两种堵塞症状都在同一张图上原因却完全不同。这里额外提一句AI产出的Issue也照样计量。每条owner:ai的记录跟owner:human的记录同等进入统计不因为是机器写的就区别对待。这样算出来的进度才是真实的项目进度而不是单看你手写了多少行代码的自欺欺人数据。3.3 轻量工具选型不折腾团队的前提下怎么落地聊到这里肯定有人问我用的是哪套工具坦白讲工具并不神秘——代码托管平台自带的问题追踪和看板功能完全够用把每一张看板卡片都对应一条Issue把标签直接打到卡片上是最省事的方案。如果你当前的项目根本不在代码托管平台上托管那用在线表格配合“分列筛选”也能撑起初期使用我在只有一个演示项目的时候就是这么干的。选型原则就两个第一团队已经在用的工具优先不要去引入一套新的系统逼所有人迁移协作成本会吃掉流程收益第二功能点到为止能筛选标签、能分列看板、能导出数据就足够了。真正的关键不是工具本身而是你有没有坚持“每一条改动都有对应的记录”这个习惯。如果你想要更重的方案可以在日常项目管理软件里开辟一块专门的面板独立管理所有和AI协作相关的Issue不和人手任务混在一个看板里。我当时分开的原因很简单节奏不同人类开发人员之间的任务流转和人机协作任务流转的颗粒度、验收频次都不一样混在一起很容易让看板显得杂乱分开后反而谁都能一眼看清各自的状态。4. 把常见坑一个个踩平这套流程跑顺之前你大概率会遇到的麻烦任何流程都不是装上就跑得顺的。我在推行这套问题标签驱动做法的初期踩过的坑不下五个每个都能单独写一篇吐槽。这里挑最有代表性的几个说清楚同时给出我自己验证过的处理办法。4.1 坑一标签设计得太细维护成本直接爆炸起手阶段最容易犯的毛病是追求“完美分类”。我一开始除了类型、状态、归属、优先级还加了什么urgency:tomorrow、skill:python、source:customer恨不得把每条Issue的所有维度都打上。结果是每建一条Issue要花五分钟打标签每天还要花时间维护过期标签没到一周就坚持不下去了。后来我做了减法狠狠砍掉所有“暂时用不上”的维度只保留前面表格里那四个。用下来的体会是标签的价值不是越细越好而是“够用且大家愿意维护”。如果你发现某个标签从来没有被拿来筛选过那就是多余标签直接删。每多一个标签都是在增加所有人的认知负担。4.2 坑二AI填写的验收描述过于乐观几乎每次都漏边界条件这个问题几乎无法根治只能靠流程弥补。AI在答案末尾给你列“验收标准”的时候写得又整齐又漂亮照着做也确实能跑通“正常路径”。但只要你拿真实的边界输入去怼它比如超长字符串、空值、并发请求、断网重连它给出的方案有一半会在这些情况下翻车。所以我在每条Issue的“验收标准”里专门加了一个字段边界条件检查。给AI下指令的时候也会主动强调“请考虑并列出至少三个可能的边界情况并说明你的处理方式”。就算这样复查的时候我仍然会自己构几个刁钻输入跑一遍。别把AI写的验收清单当成最终标准它只是一个起点真正的验收权永远在人类手里。4.3 坑三Issue和提交记录散落无法快速回溯对应关系早期我是在聊天里让AI给方案然后把代码复制进工程一切顺利但当某个修改上线后出了故障你想查“这一行是谁在哪次改动里引入的”就会非常痛苦。Issue是分析阶段的产物提交记录是代码仓库里的事件中间如果没有一条线串起来回溯就断了。解决的办法是给提交做绑定。现在主流代码托管平台的提交信息都支持关联关键词在提交说明里写上类似“fixed #123”之类的编号提交和Issue就会自动建立起关联对应的分支、提交、变更记录全都挂到Issue下面。这一条操作成本几乎为零但长期价值极高——一个多月后再回来看某个旧需求点开Issue就能看到从讨论、到实现、到提交、到验证的完整闭环比翻聊天记录高效太多。4.4 坑四只查“AI做了什么”不查“AI没做什么”这个坑很难靠看板发现因为它跟标签和视图无关是整个协作习惯的问题。AI协作模式下你很容易被AI产出的代码量迷惑——今天它写了500行明天又写了600行感觉进展神速。但真相往往是它用500行实现了一个你认为理所当然但实际并不需要的功能你要的却是另一个。验证的手段是让AI“复盘未做事项”。每次关闭一条Issue前我都会额外追问一句“有没有任何和你这次改动相关的模块、文件或配置你认为应当处理但没有处理”AI有时会给出很关键的遗漏提醒比如“会话过期处理未加入到改造范围内的所有接口”。这不是什么AI灵性而是因为当你把遗漏作为明确问题抛给它时它的输出会比“自由发挥”阶段更加收敛、更能暴露盲区。5. 关于这套机制的一次复盘以及长期运行的几点体会没有一次复盘的习惯任何流程都会慢慢变形。我大概每隔两三周会把整套机制从头过一遍重点看三件事标签有没有冗余、状态流转是否顺畅、以及每个角色的统计数字有没有异常。问题不少但值得坚持。到目前为止这套“问题标签驱动开发”最大的收益不是进度图变得好看了而是它给了我一种“上帝视角”任何时刻打开看板我都能准确说出项目里所有工作在谁手里、做到哪一步、下一步该做什么。当AI参与的开发事项越来越多这种掌控感变得越发珍贵。朋友偶尔问我“你现在让AI写这么多代码心里不慌吗”我说“以前慌因为我不知道AI到底写了啥、写到哪了。现在不慌因为每条改动都在看板上都有一条跟踪记录等着验收。”我自己的体会是这套方法的核心不在标签命名、也不在看板颜色而在于你愿不愿意把“和AI的每一句闲聊”升级为“和AI的正式协作档案”。聊天记录是流水项目看板才是资产。如果你已经被多任务并行、反复扯皮、上下文丢失这类问题折磨过建议先拿一个两星期的演示项目试试这套机制把每个需求拆成Issue打上四维标签让AI在流程内干活。两星期后你会回不去的。