给 AI 智能体用的反馈看板：让用户来写提示词

晚上十一点，一个用户给你发消息。“导出按钮在 Safari 上点了没反应。”

接下来会发生什么你很清楚，因为这一幕已经上演过上百次。你读它。你看懂了。然后你打开一个跟踪系统，用自己的话把它再写一遍，补上文件路径、复现步骤，以及用户不可能知道的上下文。再过一会儿，你打开终端，把同一件事写第三遍，这次是作为提示词。

同一个需求，写了三遍。第一遍是免费的，来自真正撞上这个 bug 的人。后面两遍花的是你自己的时间。

智能体出现之后，第二遍和第三遍就成了这份工作里最荒谬的部分。

你还在手动敲的最后一样东西

编码智能体省掉了大量打字，但没有省掉任务简报。总得有个东西告诉智能体要做什么，而且要细到它不用靠猜，而这个东西目前仍然是一个坐在键盘前的人，把别人的话转写成指令。

问题是这次转写往往毫无意义。一份像样的 bug 报告里已经有智能体需要的一切：期望是什么、实际发生了什么、在哪个页面、用的哪个浏览器。一份像样的功能需求里已经写清了意图和理由。写它的人比你离问题更近。

我们却把这段文字当成需要再加工的原料，只因为收集它的工具和执行工作的工具从来就不是同一个。反馈待在一个产品里，工单在第二个产品里，而智能体跑在一个对这两者都一无所知的终端里。

把这道缝合上，重写这一步就没有地方可以发生了。

当看板本身能执行，反馈看板会变成什么

公开待办看板是一个你的用户能直接打开的页面。他们在上面报 bug、提功能需求、给别人的提议投票、追一条讨论、看着状态变化。到这里为止，它就是一块反馈看板，而这类产品里有不少做得很好的。

区别在于工单落在哪里。它不会落进一个等着被导出的反馈产品，而是落进你的智能体本来就在执行的任务待办看板，作为一张一等公民的工单，和你自己写的那些排在一起。

从这里开始，把它拖进 In Progress 就会启动一个智能体，而它的任务简报就是这张工单：标题、报告者自己写的描述、他当时所在的页面、他用的浏览器，以及你们之后的往来对话。没有人重写任何东西。提示词就是那份报告。

有意思的结果不是快。而是描述问题的那个人，现在同时也是定义这项工作的人。这正是所有人嘴上都想从用户反馈里得到的东西，却几乎没有人为它设计过结构。这种反转有个名字，叫由客户驱动的待办队列：队列不再是你对什么重要的猜测，而是一份关于用户真正提过什么的记录。

三个入口，因为人们在哪出问题就在哪反馈

一块反馈看板要成立，前提是提交反馈比跑到别处吐槽更省事。这意味着要在问题发生的地方接住人。

公开页面是最显然的那个入口：一个你可以分享出去的网址，带列表视图或路线图视图、投票和一个表单。它适合那种用户愿意加书签的产品，同时还兼职证明工作确实在推进，这比一封没人看的进度邮件有价值得多。

可嵌入的组件是第二个：放在你自己站点上的一小段脚本，就地弹出表单。用户不用离开出问题的那个页面，而这恰恰是他最愿意把问题描述清楚的时刻。

Chrome 扩展是第三个，也是最能改变用户行为的那个。用户在任意页面上选中出问题的文字，点一下扩展，工单就带着网址和这段选中内容提交了。你收到的不是一句“它不好使”，而是一份带坐标的报告。

对服务商来说，第三个入口通常就是客户本人，而客户门户模式是仅邀请的：每个客户一块看板，别人看不到，技术栈里也不用再加一份 SaaS 订阅。

分派，因为“合适的智能体”不止一个

新进来的工单不指名给任何人。任何收件箱都有这个现实问题：总得有人决定它归谁。

从外部进来的工单会按专长自动分派：布局错乱交给前端方向的智能体，泄漏的查询交给后端方向的，你不必每天早上手工分诊整个队列。什么都没配置的时候，兜底规则故意做得又笨又可预测：交给项目里的第一个开发类智能体，绝不会交给恰好排在列表最前面的市场或产品经理角色。

你也可以把工单指向一整个智能体团队，而不是单个智能体，这样客户的一个需求会先过开发这一步、再过 QA 这一步，然后才到你手上。

所有人都会忘的那一环：报告者收到了什么

收集反馈很容易。产品流失用户，都是在闭环这一步。

工单进入开发，提出它的人会收到通知。工单被排上优先级，他会收到通知。你决定不做，他也会收到通知，附上你写的理由，这比沉默好太多。而当修复真正上线时，他会收到一条明确的消息，并且是按版本合并成一条通知，而不是五张工单发五封邮件。

还有一个看着很小、实际分量不轻的细节：关闭用户工单的那个提交会用名字署上报告者，而这份署名会一路留到公开的更新日志里。看到自己的名字挂在一个已上线的改动上的人，下一个 bug 也会来报。整个留存机制就这么点东西，而且不花一分钱。让这个循环跑上几个月，由反馈驱动的开发就不再是口号，而是可以观察到的事实：投票决定顺序，顺序决定发版内容。

如果需求提得含糊，工单范围界定会卡在反馈和动手之间：一个 Product Manager 智能体把模糊的需求变成你真实产品加上这个改动之后的效果图，于是在写下第一行代码之前，你就能在同一张工单上确认这个想法。

传统工具停在哪里

这不是在贬低这些老牌产品。Canny、Featurebase、Fider 和 UserVoice 在收集、去重和排序上都做得不错，在产品团队真正在意的那些环节上打磨了很多年。它们停在同一个地方，原因也是同一个结构性原因：它们是为那种工程属于另一个部门、只能通过导出触达的组织设计的。

决定性的是最后一行。在大团队里，把需求写成规格说明是一份有真实价值的工作，导出也不是瓶颈。而在一个靠编码智能体发版的一到五人团队里，这次重写就是瓶颈，而且是纯粹的损耗。

它解决不了的事

接上智能体的反馈看板不是自动驾驶，把它当自动驾驶用，结果会完全如你所料。

烂工单照样产出烂结果。一句话、没有复现路径的报告，给不了智能体任何可用的东西，它会非常自信地做错事。看板只能原样传递写下来的内容。

没有任何东西会自己合并。智能体产出的是一个分支和一份 diff，你原本关于审查智能体成果的所有规矩仍然有效，尤其是涉及身份验证、支付或数据的部分。一张来自陌生人的工单不是降低标准的理由，而是提高标准的理由。

量的问题也是真实存在的。一块做成了的公开看板一定会变吵，这是个好问题，但它有实实在在的成本。重复项在提交时就会被标出来，投票能把一个人想要的和四十个人想要的分开，写一句理由把工单关掉，也比让它烂在那里更快。但收件箱终究还是要有人去读。

怎么开起来

打开某个项目的待办列表，点“公开待办看板”，选一个网址和一种可见性模式。配置就这么多，到这一步页面已经上线了。

接下来做什么比配置本身更重要。把链接放到用户已经在的地方：应用里、你的客服回复里、更新说明的末尾。没人知道的反馈看板什么也收不到，而这个功能的失败方式不是技术性的，而是那个链接从来没被分享出去。

AgentsRoom 就是这套做法运行其上的指挥中心：一块卡片即可变成运行中智能体的任务看板、一个接进来的公开或私密反馈页面、一个可嵌入的组件、一个 Chrome 扩展，以及在工作真正上线时才触发的客户通知。它可以配合 Claude Code、Codex、OpenCode、Antigravity CLI、Aider、Grok Build、Mistral Vibe 和 Kimi Code 使用。

下载 AgentsRoom，发布你的第一块看板。

常见问题

什么是给 AI 智能体用的反馈看板？

一个供用户报 bug、提功能需求的公开页面，它直接连着编码智能体执行任务的那块看板。和传统反馈工具的区别在最后一步：不用再把需求导出到某个跟踪系统、再重写成提示词，工单本身就是智能体的任务简报，用的是报告者自己的措辞。

用户提的工单真的能直接启动一个 AI 智能体吗？

启动始终是一个人为动作：有人把工单拖进 In Progress，智能体就带着这张工单作为提示词启动。自动的是分派，新进来的工单会被送到专长对得上的那个智能体手里。让陌生人写的任何东西全自动执行，那不是功能，那是安全漏洞。

这和 Canny、Featurebase、Fider 或 UserVoice 有什么不同？

它们在收集、去重和排优先级上都做得很好，而且都停在同一个地方：给你一份排好序的清单，然后还是要人来把每一行变成实际工作。它们没有执行层，因为它们本来就是为工程团队在别处的产品团队设计的。这里赌的是相反的一面：收集的界面和执行的界面是同一个东西。

要用它，就必须把路线图公开吗？

不用。公开、不索引和仅邀请是三种独立的模式。给每个客户单独开一块看板的服务商用仅邀请模式，搜索引擎永远看不到它。想从用户那里收需求和收投票的独立开发者用公开模式。执行的那部分在三种模式下完全一样。

怎么防止公开看板被噪音淹没？

没有什么能拦住噪音进来，说有就是不老实。看板改变的是处理它的成本：提交时就会标出高度相似的重复项，投票告诉你大家真正想要什么，不打算做的工单可以写一句理由关掉，而这句理由会送到提出者手里。留下来的那些工单，自带一个陌生人已经替你写好的上下文。