反馈驱动

反馈驱动的 AI 开发：让用户之声来发下一迭代

传统的 backlog 优先级排序一半是政治，一半是直觉。投票驱动的 backlog 粗糙却诚实：需求最多的功能最先发版。AgentsRoom 的 Remote Backlog 把这条民主信号直接接入你的 AI 编码智能体。

每个产品团队都有同一个起源神话：创始人决定做什么，然后扩张，然后招一个 PM 来决定做什么，然后继续扩张，直到某一天公司意识到真正的信号来自用户，才开始倾听用户。反馈驱动开发就是那条捷径。跳过「我们说了算」的阶段，直接进入「用户说了算，我们负责发版」。

最经典的实现是投票驱动的 backlog：用户看到一份公开的功能请求列表，对自己在意的条目投票，列表顶部就成为下一个迭代。Canny、Fider、Featurebase、UserVoice、Frill 和 Aha 等工具让这个模式流行起来。但在所有这些工具里，统计完票数之后仍然留有一个经典的人肉工程回路：PM 浏览排行榜，写一张工单，开发把它领走，迭代开始。

AgentsRoom 把这个回路压扁。投票直接落到 AI 编码智能体可以执行的工单上。当一张工单超过你的投票阈值时，你只需把它拖进 In Progress 列，一个 Claude、Codex、OpenCode、Gemini CLI 或 Aider 的智能体就会以客户的原话作为 prompt 接手。从用户需求到功能上线，唯一需要人参与的步骤就是一次拖拽和一次 diff 审核。

这带来几个有意思的后果。第一，优先级排序变便宜了。你不再把时间烧在争论里；看一眼投票数，信号要么在那儿，要么不在。第二，优先级排序变诚实了。当榜单顶端是一个你个人并不想做、却有 42 位用户想要的功能时，你很难再骗自己。第三，优先级排序变快了。从「用户想要 X」到「X 已在生产」的滞后从几周缩到几小时。

反馈驱动的 AI 开发并不是银弹。投票可能有噪声，鼓噪的少数群体确实存在，纯粹的投票独裁会让产品变成为了迎合而堆砌的小胜利糊糊，以牺牲连贯的产品愿景为代价。这正是为什么 AgentsRoom 的 Remote Backlog 同时给你原始信号「和」控制权：你依然决定要拖动哪些工单、分配哪个智能体角色、批准哪些 diff。投票是信号，智能体是劳力，你是编辑。