一个 bug、一部手机、8 分钟 —— 未来的需求管理就是这么敏捷

2026 年 4 月 23 日下午，我在外面办事，手机微信群里弹出一条消息。

用户"飞奔的残疾人"在 Auto-Coder 用户群里 @我，问了一句：

"祝大是不是排班出现了 bug"

紧接着发了一张截图过来。

我点开图片放大看了一眼。

auto-coder.chat 官网首页 PC 端——"开始使用"那一段的 4 个步骤卡片，布局明显挤崩了。第一张卡里的"安装"区被压得变形，"复制"按钮跑到了"OS 选择器"下面，命令文字一行也撑不住。手机端是好的，PC 上的 1024px~1280px 这一档完全乱套。

放在以前，我下一步会做的事是：

1. 在群里说"收到，回去我看一眼"
2. 找一张纸或者备忘录记一下，免得忘
3. 等晚上回家打开电脑，复现 bug
4. 写需求、改代码、测试、push、部署
5. 第二天告诉用户"修好了"

整个回路最快也要几个小时，慢一点要第二天。

但 2026 年 4 月不是这样的

我直接长按那张截图保存到相册。然后打开 Safari 进 auto-coder.chat 看板。

时间是 17:04。

填表单：

• 标题：网站首页有布局问题
• 描述：如图片 网站首页在 PC 下样式有问题，手机端是好的。修复下，你的要拉取最新代码再修复
• 验收标准：启动服务 使用 agent-browser 访问检查下时候解决了
• 优先级：高
• 绑定实例：allwefantasy · auto-coder.chat

往下滑：

• 执行方式：Cursor（手机端发起，让我家里电脑上的 Cursor 接管干活）
• 附件：把刚才用户发我的那张截图拖进来，agent 会自动下载到本地

整个填表单的时间，不超过 90 秒。

点"创建"。

17:04 — 卡片落进"待规划"列

#1 卡片就位。我点了一下右下角绿色 ▷ 执行按钮。

卡片瞬间从"待规划"跳到"进行中"列，下面冒出 Agent 正在执行... 状态条。

到这一步，我和这个 bug 的物理交互结束了。

我把手机塞回口袋，继续办我的事。

17:11 — 7 分钟后，一切都已经发生

办完事掏出手机，再点开看板。

卡片 #1 已经从"进行中"流转到了 "待审查"列，右下角变成绿色对勾 ✓。这意味着——

• Agent 已经在我家里那台 Cursor 上拉取了最新代码
• 复现并修复了布局问题
• 启动了 dev 服务、用 agent-browser 自己访问验证了一遍修没修好（这是验收标准里写的）
• 自校验通过，扔到"待审查"列等我点头

我点开卡片详情：

执行状态那块写得很清楚——

• 进入会话追问 & 深度审查 —— 待你审查
• 关联会话：8fad171e（点进去能看到 agent 完整的修复轨迹）
• Run 状态：COMPLETED
• 底部三个动作按钮：删除 / 拒绝 / 通过 / 编辑

往下滚，看 agent 写的"问题根因"。

Agent 自己分析出来的根因，原文照抄：

### 问题根因
`components/GetStarted.tsx` 的 4 步骤卡片区域：
1. 外层用了 `max-w-5xl` (~1024px)，配合 `lg:grid-cols-4` 后单卡片宽度只剩约 220px
2. 工具条用 `flex justify-between flex-wrap`，在窄卡片下复制按钮跑到 OS 选择器下面，互相挤压
3. `<code>` 没设 `min-w-0`，命令文字 `break-all` 实际不生效

精确到文件、精确到 CSS 类、精确到三条根因。

不是"已修复 ✓"这种轻飘飘的话，是让我能 5 秒判断"agent 的理解和我自己 review 时会得出的结论是不是一致"。

我心里默念了一遍：max-w-5xl + lg:grid-cols-4 → 单卡 220px → 工具条挤崩 → <code> 没设 min-w-0 → break-all 失效。对，就是这个根因。

点"通过"。

确认将此需求标记为「已完成」吗？

确定。

17:12 — Issue approved

绿色横条 Issue approved 弹出。卡片落到"已完成"列，计数 1。

整条链路：

从我决定动手处理 → 到这个 bug 在线上被解决，约 8 分钟。全程在手机上完成，我没碰过电脑。

这件事如果放在以前会怎么样

我自己做了 12 年研发，太清楚一个"PC 端 1024px~1280px 区段布局错乱"的 bug 走完传统流程是个什么体力活：

1. 回家、开机、拉代码 —— 5~10 分钟
2. 打开浏览器复现，调 devtool —— 5 分钟
3. 定位到 GetStarted.tsx 4 步骤区，意识到 max-w-5xl + lg:grid-cols-4 在这个宽度上爆了 —— 10~15 分钟
4. 改 CSS、试几个方案、看看哪个不破其他断点 —— 15~30 分钟
5. git diff 确认改动干净，commit + push —— 5 分钟
6. 等 CI、等部署、刷线上验证 —— 10~20 分钟

最快 50 分钟，慢一点 90 分钟。而且要求"我这个工时块不能被打断"——回到家、洗完澡、安顿好家务才能坐下来干。

今天的回路是：

看到 bug → 拍照 / 截图保存 → 打开手机看板 → 90 秒填表单 → ▷ 一点 → 把手机塞回兜 → 7 分钟后看一眼根因 → 点"通过"

我办我的事的间隙，bug 自己解决了。

这背后撑着的三件事

不要被"8 分钟修 bug"这件事的字面表象骗了。它能成立，是因为下面三件事同时成立：

1. 看板模式——bug 不是一段聊天，是一张带"标题 / 描述 / 验收标准 / 附件"的结构化卡片。所有"agent 需要知道才能干活"的信息，在创建那一刻就齐了。我不需要等晚上回家再"补上下文"。

2. Agent 自带 + Subagent 分层——卡片点 ▷ 之后，是我家里 Cursor 这个 Code Agent 在干活，不是某个云端服务。代码、密钥、工程环境、调试全部不出我的电脑。Subagent 把执行成本压到几毛钱级别，所以"随手提一张卡"这件事不会变成"账单焦虑"。

3. Agent 自校验 + 写根因——验收标准写"启动服务用 agent-browser 检查下"，agent 真的会去启动服务、真的会去用 agent-browser 访问、真的会判断有没有修好。它跑完之后还要写精确到 CSS 类的根因分析给我看。这一步把"AI 嘴硬说做完了"挡在我审查之前。

少任何一件，8 分钟这个数都不成立——

• 没有看板，bug 就是一段聊天，我得记到备忘录里、晚上找时间处理
• 没有自带 Agent + 接力，我得在手机上 SSH 进电脑、起会话、喂 prompt
• 没有自校验 + 根因，我得自己拉代码看 diff，才敢相信它真的修好了

未来的需求管理就是这样

我做 Auto-Coder 这两年，看过太多"AI 编程演示视频"——一个人坐在电脑前，对着 Claude Code 或 Cursor 说一句话，几分钟后代码出来。

那种 demo 是"AI 在帮我写代码"。

今天发生在我身上的这件事是另一种东西——"我不在场，AI 帮我把一件事从需求到 commit 走完了"。

未来的研发协作不会再是"工程师坐在工位前对着 AI 干活"。它会是——

• 你在地铁上看到一个 bug 报告，手机上 60 秒提一张卡
• 你在饭桌上想到一个新功能，掏出手机扔进看板，吃完饭回来已经在 review
• 你晚上睡前列一周的需求，早上起来 commit 一半
• 你团队里 5 个工程师人不在工位，云端电脑接力把 30 张卡的活做掉

需求管理这件事的颗粒度，正在从"小时 / 天"压到"分钟"。

它能这么快，不是因为模型变得多聪明（虽然 Opus 4.7 确实变聪明了），而是因为协作载体换了——从聊天窗口换成了看板，从"必须坐在电脑前"换成了"手机上几下点击"，从"AI 写完我得逐行 review"换成了"AI 自己写根因 + 我点头"。

这就是软件工业流水线的手机版本。

顺手补一张图——需求多起来是什么样

上面那条 8 分钟的链路只展示了"一张卡"的故事。但真实的工作里，需求从来不是一次一张地来。

我自己手机里现在长这样：

时间是同一天的 17:48——比修完那个布局 bug 晚了 36 分钟，待规划列里已经又堆了 3 张：

• #5：待审核的卡片新增确认并且提交代码按钮（功能改进）
• #4：大部分涌道里的卡片点击详情都有 review（UI 一致性）
• #2：会话页面发送信息后延迟问题（bug，带 1 张附件截图）

每一张都是 60~90 秒落进来的。有的是我自己用产品时顺手发现的，有的是用户在群里随口提的，有的是我看一眼竞品产品突然想到的。

如果是以前，这 3 张需求会是 3 条飘在我脑子里 / 备忘录里 / 微信收藏里的"待办"，总有一两条最后会忘掉。今天它们全在看板上，按优先级排好。等我打开"自动接力"开关，agent 就会从"待开发"列里按顺序把它们一张一张做掉。

我下午办事回来的时候打开手机一看——常常会发现有 1~2 张已经在"待审查"列等我点头了。

这才是看板的真正价值——它把"想法"和"产能"之间那段无序的、容易丢的、靠记性维持的链条，变成了一条永不丢卡片的传送带。

团队场景：每个角色都有自己的位置

8 分钟那个故事里只有"我自己"一个人。但 auto-coder.chat 看板真正想做的东西，是让一个团队里产品、老板、测试、程序员、Agent 各就各位。

我先把这套分工画清楚：

┌─────────────────────────────────────────────────────────────┐
│  待规划         待开发         进行中         待审查    已完成    │
│  ────────      ────────      ────────      ────────  ──────── │
│                                                              │
│  产品 PM ───┐                                                │
│  老板    ───┼─→ 程序员审核 ───→ Agent 自动 ───→ 程序员审核 ──┐ │
│  测试    ───┘  + 改写需求       接力执行       + 测试介入   │ │
│  自己提的 ──┘  → 移到"待开发"   → "待审查"     → "已完成"  ──┘ │
│                                                              │
└─────────────────────────────────────────────────────────────┘

第一关 · 谁都可以提"待规划"

产品经理、老板、测试、客户支持，甚至运营——任何人都可以打开看板，新建一张需求卡，扔进"待规划"列。

他们不需要懂 git、不需要会 prompt、不需要知道这个项目用的是 Vue 还是 React。

他们只要会做一件事：把"我想要什么"说清楚。可以打字、可以语音输入、可以丢一张截图。

"待规划"这一列的本质，是整个团队和 AI 之间的需求收件箱。

第二关 · 程序员是"需求的把关人"

需求一旦进来，程序员有权也有责任去审核它。

• 描述写得太模糊？打开卡片帮 PM 改清楚。
• 验收标准缺了？补上"启动服务后 X 接口返回 Y"这种机械可核对的条件。
• 优先级排错了？调整。
• 一张大卡可以拆成 3 张小卡？拆。
• 有些需求根本不该做？关掉，写明原因。

改完之后，程序员把卡片从"待规划"拖到"待开发"列——这一拖的物理动作，就是程序员对 AI 说："这张卡现在状态干净了，可以让你接手了。"

这一关在传统团队里叫"需求评审"，往往要拉一个会、几个人吵半天。在看板上，它变成了一张卡片的字段编辑 + 一次拖拽，几分钟就能搞定一张。

第三关 · Agent 自动接力，干活不睡觉

打开看板顶部的 ⚡ 自动接力 开关。

接下来的事情就由 Agent 自己来了——

• 从"待开发"列里按优先级 + 手动顺序挑出最上面那张卡
• 自动启动执行，卡片进"进行中"列
• 跑完之后自校验，对照验收标准打卡，写出根因
• 校验通过 → 卡片自动跳到"待审查"列
• 调度器立刻去"待开发"列里挑下一张

白天程序员在审需求 / 改卡片，晚上 Agent 在执行 / 自检——两班倒。

一个 5 人的团队，可以同时在看板上挂 30~50 张卡，agent 在多台云端电脑上接力跑。早上来上班，"待审查"列里通常已经堆了好几张等你点头。

第四关 · 程序员先审，测试后跟

Agent 跑完进入"待审查"列。这一关有两步：

• 程序员审 Agent 写的根因——和我修那个布局 bug 时做的事一样，看根因分析是不是对、看 diff 是不是干净。如果 Agent 走偏了，要么"拒绝"打回让它重来，要么编辑卡片追加一条更严的验收标准、再点"执行"。
• 测试介入——程序员判断"代码层面 OK"之后，测试同学拉这个分支跑一轮回归 / 端到端 / 业务校验。这一步可以是手工的，也可以是把测试用例写在卡片的"验收标准"里让 Agent 一并跑。

测试通过、程序员点头，卡片才被允许进"已完成"列。

整条链路连起来看

这套分工的关键不在于"AI 替代人"，而在于"每个角色都不再做自己最不擅长的事"——

• 产品不再被迫学技术语言去描述需求，只管说自己想要什么
• 程序员不再每天写大量 CRUD 代码，只管把好两道关：需求评审 + 结果审查
• 测试不再追在程序员屁股后面问"做完了没"，直接看"待审查"列
• Agent 不再坐在某个工程师面前等指令，自己从队列里拿活

这就是 auto-coder.chat 看板对"未来研发团队"的回答——人专注审查与决策，Agent 专注执行与自检，传送带自己跑。

如何快速体验

打开手机浏览器（或者电脑都行），访问：

auto-coder.chat

下载对应平台的桌面客户端，登录后进 Dashboard 就能看到"需求看板"Tab。

下次再有人在群里 @你说"是不是出 bug 了"，别急着说"回去看"——直接打开看板提一张卡，把那张截图丢进附件，点 ▷。

剩下的事情交给流水线。

最后

我们做 auto-coder.chat 看板的初衷其实很朴素——

让每一个开发者都能在手机上、在地铁上、在咖啡馆里、在出差的高铁上，把自己的工程产能"装在口袋里"。

不需要工位、不需要电脑常开、不需要"等我回家"。需求一来，60 秒落卡，几分钟后已经在 review 根因。

让软件开发，像微信回消息一样自然。

体验 auto-coder.chat 看板：auto-coder.chat

本文所有截图均来自 2026 年 4 月 23 日下午一次真实的 bug 处理过程，时间戳未做任何修饰。