Bug 越改越乱？给 vibe coding 小白的「问题管理机制」——把 bug 和需求都变成 Issue，让 AI 自己登记、开发、验收

这是「珍妮丁丁说AI」Vibe Coding 教学系列第三期的深度拆解。视频里是丁老师（技术担当）带着珍妮（从零起步的小白）做产品，主题只有一句话：MVP 做出来之后，bug 越改越乱，到底该怎么办？ 下面的内容来自双轨还原——逐字稿（口播）+ 逐帧读屏（画面里的 Codex 工程界面与 issue 文档），工具名、字段和文件结构均以画面截图为准。

珍妮的开场吐槽，几乎是每个 vibe coding 小白的真实写照：

「自从我那个 MVP 出来以后，本周我最大的感受就是——每天都在改 bug。一个 bug 改完了，又有新的 bug，满屏都是 bug。」

如果你也正在用 AI 做网页、做工具、做小产品，多半也撞过这堵墙：跟 AI 聊着聊着，改完这个坏那个，越改越乱，最后连自己都不知道还有多少问题没解决。这一期给的，就是一套小白也能照抄的解法。

一、先纠一个错觉：bug 多，根本不是 vibe coding 的病

丁老师上来第一句不是教方法，而是先泼一盆冷水纠偏：

「大家不要被珍妮误导，以为这是 vibe coding 才会有的问题。其实所有程序员做的所有产品，都是存在很多很多 bug 的。我们也只是选择一部分重要的 bug 把它修复，不重要的 bug 暂时搁置。」

这句话很关键。新手最容易掉进的心态陷阱是：「一定是我用 AI 写的代码太烂，所以才这么多 bug。」 于是要么自我怀疑，要么强迫症一样想把每个 bug 都清零。

真相是：正常产品的迭代，本来就是「不停做需求、不停改 bug」的循环，专业团队也一样。MVP 做出来，意味着产品的骨架已经搭好，你正式进入了一个新阶段——丁老师叫它**「正常迭代期」**。这个阶段只干两件事：

确定接下来要迭代的功能（需求）；
确定产品里必须修的 bug。

一句话定性：vibe coding 的失控感，90% 不来自「不会改 bug」，而来自「没有一个地方把 bug 和需求排好队」。

珍妮被无限 bug 困扰的真正根因，丁老师点得很准——不是 bug 多，是 bug 没被管理起来：没有把需求和 bug 条理化地登记下来，没确定到底哪些要优先改、哪些可以暂时放下不做。脑子里一团乱麻，自然觉得永远改不完。

二、核心方法：把 bug 和需求，全都变成一个 Issue

丁老师教珍妮的方法，叫**「问题管理机制」**。它不是什么新发明，而是源自 GitHub 的成熟概念，英文名就是 Issue（问题单 / 一修单）。

它的思路简单到一句话能讲完：

把你所有的需求、所有的 bug，都看作一个独立的「问题单」，给每个问题单一个编号存起来。

每个问题单只要两个核心状态就够了：

状态	含义
Open（开启）	问题还没解决
Closed（关闭）	问题已经解决

工作方式是这样的：

以后你想到的任何问题、在体验自己产品时发现的任何毛病，都让 AI 帮你创建一个问题单、登记进去——你不用自己手写，一句话丢给 AI 就行；
然后根据产品迭代的节奏，从里面挑几个比较重要的，开始优化或研发；
解决完的，AI 自动把它挪到 Closed 归档。

为什么一定要给编号？ 这是个被很多人忽略的细节，却特别提升效率。有了编号，你跟 AI 沟通时就不用每次都把问题描述一遍了——直接说「改第一个问题」「先处理第七个问题」，AI 就知道你指的是哪个。沟通成本断崖式下降。

丁老师还补了一句更长远的：如果你的产品以后想开源、想分享给别人用，一般都通过 GitHub。而 GitHub 天生自带这套 Issue 机制——所有体验你产品、发现问题的人，都能用同样的方式给你提 issue，你照着列表一个个修就行。也就是说，你现在练的，正是未来协作开发的标准动作。

三、落地长什么样：一个用 markdown 文件搭起来的 issue 库

光讲概念是空的，这期最值钱的是丁老师直接把珍妮项目里的真实文档摊开演示了一遍。它的样子，可能比你想象的朴素得多——就是几个 markdown 文件夹，零数据库、零依赖。

整套结构是这样的：

在项目根目录下建一个 issue 管理文件夹；
里面 issues/ 下分三个子目录对应状态：open/、closed/、deferred/（搁置），主要用前两个；
每个问题单是一个独立的 .md 文件，带编号（ISSUE-001、ISSUE-005……）；
外加一个看板 README，和一份使用说明书。

每个 issue 的 md 文件里，字段相当规整（以下是画面里两个真实 issue 的字段还原）：

字段	示例值
类型	bug / test、product / workflow
优先级	P1
状态	open / closed / ready-for-development
来源	验收 / 真实探针、GitHub Issue
发现日期	2026-06-05
关联 GitHub Issue / Spec / PR-commit / 验收	（链接或「无」）
负责人	Issue 管理 Agent
现象 / 证据 / 影响范围 / 下一步 / 验收方式	（正文描述）

而那个看板 README，丁老师写的标题是「Issue 反馈跟踪机制」，第一条核心原则就是**「看板做登录入口」**——一打开就能一眼看清四件事：

是否有需求在闭环里？
各个问题各自处于什么状态？
优先级最高的是哪个？
下一步该做什么？

这套东西最妙的地方：它就是几个 markdown 文件夹。人能看，AI 也能看；AI 改完一个 bug，自己就把对应的 md 从 open/ 挪到 closed/ 归档。没有任何花哨技术，却把「混乱」变成了「可追踪」。

四、进阶玩法：三个 Agent 串成一条自动流水线

如果说前面是基础，这一段就是全片真正的高阶操作——珍妮把整个开发，拆成了三个各司其职的 AI Agent。

上一期，他们已经把工作分成了「开发 Agent」+「规划 / 产品 Agent」两个；
这一期新增了一个「Issue 管理 Agent」，专门负责管理所有 issue 单的状态。你提问题，就只提给它。

然后神奇的事情发生了。画面里演示了一段真实流转，整条链路是自动跑的：

你（提问题）
   ↓
Issue 管理 Agent ——登记问题单、自动派单——→ 产品 Agent
                                              ↓（设计完成，自动通知）
                                          研发 Agent
                                              ↓（开发完成，自动通知）
                                          产品 Agent（验收）

用丁老师的原话还原这个闭环：珍妮把问题提给 Issue 管理员 → 管理员登记成一个问题单 → 自动发一段话通知产品 Agent → 产品 Agent 根据这个问题开始做设计 → 设计完成后自动通知研发 Agent → 研发完成后又通知回产品 Agent，告诉它「可以去验收了」。

「在这整个过程中，我只需要跟我的 Issue 管理员说『什么问题』，然后从提 issue、到产品、到研发、再回到产品验收，这个流程它全都是自己闭环的。」

这就是它的威力：你从一个手忙脚乱的「全栈打杂」，变成了只管提需求、拍验收的产品经理。 干活的是三个 AI，调度的也是 AI，你只负责出题和收货。

五、怎么搭：其实一段话就能起一个最小闭环

听到「三个 Agent 自动协作」，小白很容易被吓退，以为要写一堆复杂配置。丁老师反复强调：「非常非常简单。」

实现方式就是——在每个 Agent 的会话开头，用自然语言把规则讲清楚（也就是给它喂好背景信息），机制就成立了。大致是这么三句话：

对 Issue 管理员：「以后我给你提问题，你就创建一个问题单，并且通知产品 Agent 进行开发。」
对 产品 Agent：「你拿到产品设计需求、设计完成之后，直接通知开发 Agent 进行开发。」
对 开发 Agent：「你开发完之后，通知回来让我 / 产品 Agent 验收。」

把这些背景信息分别告诉它们，一个最小的闭环就跑起来了。丁老师送的那份提示词，目前能做到的是：在你当前的文件夹下，创建一个 issue 管理文件夹，然后你随便找一个会话告诉它「以后你就负责接收我给你提的 issue 问题单」，就可以开始用了。

关键判断：别一上来就追求「完美的多 Agent 协作系统」。先用一句话把规则讲清，跑通一个「提问题 → 登记 → 开发 → 验收」的最小闭环，再往上加。机制是长出来的，不是设计出来的。

六、两条配套纪律：里程碑判断 + git 存档

这两条是丁老师收尾时顺带提的，但它们其实是让整套机制不崩塌的地基。

1. 给产品定「里程碑式的判断」。 珍妮问了一个特别小白也特别真实的问题：「我怎么知道什么时候 MVP 算 OK 了、可以进下一步？」丁老师的答案是——你要对产品有一个里程碑式的判断：每个节点，你期待产品长成什么形态、你自己满意了，就进下一阶段。而且每个阶段的需求方向是会变的：这一版你所有的功能需求都是冲着「能用」去的；到了下一版，重点就转向「完成度」「美观」「UI」。珍妮当场就说，下一期想引入一个专门的 UI 设计 Agent，因为整个页面风格她都还不满意。

2. 用 git 给代码「存档」。 这是第一期就讲过、但这期特意重提的纪律：每当产品实现了一批功能、跑通了一些需求，你就要告诉开发 Agent「可以提交了」（git commit）。

「相当于是把你的代码做了一个存档。之后修改的内容，就不会再影响你已经确定好的版本。不然的话，你一直改一直改，会牵动整个大厦动摇起来，你会非常麻烦。」

这一条对 vibe coding 小白尤其救命——因为你看不懂代码，一旦 AI 改崩了又没有存档点，你连「退回上一个能跑的版本」都做不到。git commit 就是你的后悔药。

七、可以直接抄的作业清单

把这期能立刻照做的步骤拎出来，给正在 vibe coding 的你：

在项目根建一个 issues/ 文件夹，下分 open/、closed/ 两个目录；
每个 bug / 需求建一个 .md 文件，编号（ISSUE-001…），写清：类型、优先级、状态、现象、来源；
建一个 README 当看板，列：当前在做什么、优先级最高的是哪个、下一步；
开一个会话当「Issue 管理 Agent」，把规则讲给它：我提问题你就登记建单、派给开发，解决了就挪到 closed/ 归档；
跟 AI 沟通只说编号（「改第 3 个问题」），不再重复描述；
每完成一批，让 AI git commit 存档；
用「里程碑判断」决定何时进下一阶段：功能 → 完成度 → UI。

最后一句：这套机制的本质，不是教你「怎么管 bug」，而是把 vibe coding 从「跟 AI 瞎聊改代码」升级成「像一个真正的产品团队那样跑迭代」——只不过团队成员全是 AI Agent，而你，是那个提需求、拍验收的产品经理。

本文为 AI 短视频深度拆解学习笔记，方法论归原作者「珍妮丁丁说AI」。原视频与作者提供的提示词请以其抖音主页为准。