先把想法梳理清楚
再动手开发
工单需求梳理会在写下第一行代码之前，把一条模糊的用户反馈变成一个梳理清晰、经过验证的诉求。一键即可派出一个 Product Manager AI 智能体，它会读懂你的代码库，理解你真实的产品，并构建一份把改动放进真实场景呈现的原型。
这份原型看上去就是用户自己的产品，而不是一张千篇一律的线框图。它会先回到你手上供你审阅，同一张工单上的双向对话则让你把需求厘清到一目了然。
“在个人资料页面某个位置加一个按钮”
梳理这个想法模糊的反馈进来，忠实还原产品的原型和一个厘清需求的问题出去。梳理会在智能体动手构建之前，先把工单梳理清楚。
用户反馈很少是清晰的。"在某个地方加个按钮"、"把这个做得更简单点"、"个人资料页面好像少了点东西"。你可以快速开发然后交付一个错的东西，也可以开一条缓慢的邮件长线去厘清。两条路都代价高昂，而且都发生在你真正在跟踪的那张工单之外。
工单需求梳理在每一张反馈工单之上加了一个梳理环节。点击"梳理这个想法"，AgentsRoom 就会派出一个临时的 Product Manager 智能体。它会探索你项目的代码库，理解这条诉求所触及的真实产品，然后产出一份自包含的 HTML 原型，忠实还原那个产品，并把所要求的改动放进真实场景中。这是一份概念验证，提出反馈的人一眼就能认出这是自己的应用或网站。
梳理是一个验证环节，而不是开发的承诺。它从不把工单挪到进行中，从不触发"工作已开始"的通知，从不写入文件，也从不提交代码。你会拿回原型链接供审阅，你来决定要不要把它发给提出这个想法的人，并在同一张工单上通过双向对话持续厘清需求。
工单需求梳理带给你什么
先梳理，再开发。一个 Product Manager 智能体把模糊的功能诉求变成一个具体、经过验证的需求，让执行智能体从清晰出发，而不是靠猜。
一份忠实还原你产品的原型。智能体会读懂你的代码库，还原你真实的界面、配色、字体和布局，并把所要求的改动放进真实场景。不是千篇一律的模板，而是你实实在在的产品。
工单上的双向对话。你在 backlog 上留言，提出反馈的人从他们的应用内聊天里回复。一条线程，一个事实来源，没有被遗忘的邮件。
没有过早的信号。梳理从不启动任务，也从不通知反馈者说工作已经开始。你先验证想法，然后再决定。
你的产品，不是一张千篇一律的线框图
一份现成模板和一份读起来就像用户自己应用的原型之间的差别。梳理构建的是后者。
一张满是灰色方块的通用线框图对反馈者毫无意义。它不像他们的产品，所以他们无法确认这个改动是不是他们想要的。
智能体还原真实产品，在正确的界面上，把所要求的元素放进真实场景加进去。反馈者一眼就认出自己的应用或网站，一目了然地完成验证。
因为原型来自你真实的代码库，它看上去就是你真实的产品。这正是让验证变得即时的原因。
工单需求梳理如何运作
从一条模糊的建议，到一张梳理清晰、经过验证的工单，你的团队可以放心地拿去开发。
一张反馈工单到来
用户、队友或客户在 backlog 里丢下一条建议，通常是通过你公开的远程 backlog。它以反馈工单的形式到来，往往很模糊。
点击「梳理这个想法」
打开工单，点击「梳理这个想法」按钮。它只出现在反馈工单上，并带有 Product Manager 头像，让你清楚知道它派出的是哪个智能体。
PM 智能体读懂你的代码库
一个临时的 Product Manager 智能体会探索项目，理解它所针对的真实产品：所在界面、视觉标识，以及这条建议所触及的具体页面。
它构建一份忠实的原型
智能体产出一份单一、自包含的 HTML 原型，CSS 和 JS 都内联在内，还原你的产品并把所要求的改动放进真实场景。一份静态的可视化概念验证，而不是一个可运行的功能。
你审阅原型链接
原型被发布，一个预览链接会先回到你手上。默认情况下它不会发给反馈者。你打开它，确认无误，或者进一步打磨。
在工单上验证并厘清
准备好之后再把原型分享给反馈者，并通过工单评论持续厘清需求。一旦想法通过验证，同一张干净的工单就可以交给执行智能体了。
同一张工单上的双向对话
在对方本就所在的地方厘清需求，而不是在一个被遗忘的收件箱里。工单线程就是唯一的事实来源。
这个按钮应该打开编辑器，还是直接进入设置？
直接进设置，大家都是在那儿找它的。
你在 backlog 工单上留言，消息会落到反馈者的应用内反馈聊天里。他们从自己那边回复，又会作为评论回到同一张工单上。两边都能读、都能写，没有重复。
盲目开发，还是先梳理
处理一条模糊功能诉求的两种方式。第二种交付的才是对的东西。
不做梳理
- : 你读到一条含糊的建议，就按你以为的意思开始开发。
- : 功能交付了，却不太是对方想要的那样。
- : 你开一条邮件长线去厘清，缓慢又与工单脱节。
- : 返工在交付之后越堆越多，而那正是修复代价最高的时候。
有了工单需求梳理
- : 一个 Product Manager 智能体梳理诉求，并构建一份你产品的原型。
- : 反馈者一眼就通过验证，因为它看上去就是他们的应用。
- : 你在同一张工单上通过双向对话厘清需求，就在真实场景里。
- : 执行智能体从一个清晰、经过验证的需求出发。返工更少。
先梳理再开发，整个团队就能一次交付对的东西。
梳理的行为方式
FAQ
AgentsRoom 里的工单需求梳理是什么？
工单需求梳理是反馈工单上的一个梳理环节。一键即可派出一个 Product Manager AI 智能体，它会读懂你的代码库，并构建一份忠实还原你真实产品的原型，让你在写下任何代码之前就验证一条模糊的功能诉求。它与同一张工单上的双向对话并行运作。
我该怎么梳理一张工单？
打开一张反馈工单，点击「梳理这个想法」按钮。它只出现在反馈工单上，并显示 Product Manager 头像。随后 AgentsRoom 会派出一个临时的 PM 智能体，注入一段梳理提示词，并打开它的终端，让你能看着它工作。
梳理智能体构建的是什么样的原型？
一份单一、自包含的 HTML 原型，所有 CSS 和 JS 都内联在内，不依赖任何外部资源。智能体会先探索你的代码库，因此原型会在正确的界面上还原你真实的产品：手机应用、网站、桌面应用或仪表盘，并把所要求的改动放进真实场景。它是一份静态的可视化概念验证，而不是一个可运行的功能。
梳理会启动任务，或通知提出这个想法的人吗？
不会。梳理有意被设计成一个验证环节。它从不把工单挪到进行中，也从不发送"工作已开始"的通知。原型链接会先回到你手上。只有当你明确选择分享时，它才会被送到反馈者的应用内聊天。
原型会自动发给客户吗？
不会。默认情况下，原型预览链接会回到你这位 backlog 负责人手上供你审阅。你打开它，判断它是否合适，然后才选择要不要分享给反馈者。没有经过你审阅的东西，什么都不会发出去。
这个双向对话是怎么运作的？
工单的评论线程是一个共享通道。你在 backlog 工单上留言，消息会送达反馈者的应用内反馈聊天。他们的回复又会作为评论回到同一张工单上。一条线程，两边都能读、都能写，没有被遗忘的邮件。
为什么要梳理工单，而不是直接开发？
因为模糊的反馈会导致功能跑偏，以及交付之后代价高昂的返工。梳理会预先把诉求梳理清楚，并用一份原型加以验证，让执行智能体从一个清晰、经过验证的需求出发，而不是从一句含糊的话出发。
梳理用的是哪种智能体角色？
一个 Product Manager 智能体。按钮带有 PM 头像，让你始终清楚它实例化的是哪个智能体。这个智能体是临时的，仅限于那张工单，而且不会被绑定为该工单的执行智能体。
工单需求梳理能配合公开的远程 backlog 使用吗？
能，那正是它的天然归宿。反馈通过公开 backlog 到来，梳理活在同一张工单上，而同一张工单稍后由智能体执行。梳理是反馈驱动的收集与开发之间的桥梁。
梳理能配合 Claude、Codex 和 Antigravity 使用吗？
能。梳理智能体与 provider 无关，在 Claude、Codex、Antigravity 以及其他智能体 CLI 上的表现都一致。它在本地面向你自己的项目运行。
你可能还会喜欢
先把想法梳理清楚，再动手开发
用上 AgentsRoom，借助一个 Product Manager AI 智能体，把模糊的反馈变成经过验证、梳理清晰的工单。
配套应用：随时随地监控你的 Agent
使用 Claude、Codex、Antigravity CLI 或其他 AI 提供商。
把 Bug 和需求直接发送到您的公开待办清单。
AgentsRoom 实际运行一瞥。