給 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 有什麼不同？

它們在收集、去重和排優先順序上都做得很好，而且都停在同一個地方：給你一份排好序的清單，然後還是要人來把每一行變成實際工作。它們沒有執行層，因為它們本來就是為工程團隊在別處的產品團隊設計的。這裡賭的是相反的一面：收集的介面和執行的介面是同一個東西。

要用它，就必須把路線圖公開嗎？

不用。公開、不索引和僅邀請是三種獨立的模式。給每個客戶單獨開一塊看板的服務商用僅邀請模式，搜尋引擎永遠看不到它。想從使用者那裡收需求和收投票的獨立開發者用公開模式。執行的那部分在三種模式下完全一樣。

怎麼防止公開看板被噪音淹沒？

沒有什麼能攔住噪音進來，說有就是不老實。看板改變的是處理它的成本：提交時就會標出高度相似的重複項，投票告訴你大家真正想要什麼，不打算做的工單可以寫一句理由關掉，而這句理由會送到提出者手裡。留下來的那些工單，自帶一個陌生人已經替你寫好的上下文。