本頁內容
能回到對話所描述的工作，聊天才更有用。當對話開始能提出修改，影響也跟著變大。
這時，我希望介面稍微放慢。回答問題與改變專案，是兩種不同操作。模型的語氣可能一樣，產品卻需要把差異說清楚。
Bisonflow 的 Agent 隨著 2.0 發布審查進入測試階段，將專案問題、文字與語音指示，以及需要審核的任務指令放進工作空間對話。「測試版」是有意義的字眼：我想讓人嘗試真實、範圍有限的工作，再告訴我結果從哪裡開始不可靠。
從已知答案的問題開始
第一次可以問你熟悉的專案。某個里程碑還有哪些未完成工作？根據現有脈絡，某項任務是在做什麼？
拿實際工作核對答案：專案對嗎？有分清已記錄的事實與推論嗎？能從引用連回來源嗎？資料不在時，它會承認，還是用文字繞過缺口？
事先知道答案不是作弊。這讓你在提出不容易檢查的問題前，先評估助理。
我不建議從「整理我的整個工作空間」開始。這句話藏了太多關於優先順序、負責人與重複項的決定。範圍小的問題，對使用者與產品都比較公平。
審查確切的指令
Agent 提出支援的任務更新時，審查畫面應指出目標與預計變更。像看小型 code review 一樣，確認任務正確、欄位值也符合指示。
確認後的指令仍經過 app 的伺服器存取檢查。確認不代表能繞過成員資格、專案權限、計費規則或資料驗證。請求重試時，也不能把同一個確認動作執行兩次。
這些保護是實作的一部分，不代表每項建議都正確。人仍可能確認沒幫助的修改，模型也可能誤解模糊要求。所以可見的提案很重要。
第一次嘗試修改時，先用改錯了也容易發現和修正的任務。完成後回頭檢查。聊天顯示成功還不夠，得回到任務裡確認狀態是否正確。
語音也要留下相同的審查線索
你可以用語音給指示，但麥克風不會產生另一種權限。結果應留在對話裡，讓你讀過並檢查建議動作。
說話可能不精確。兩項任務也許有相近名稱；你也可能說到一半改日期。系統應使用完整最終指示，並澄清剩下的歧義，而不是默默替你選目標。
語音工作流程文章談得更完整。核心檢驗仍是：說話是否讓有用的工作更容易完成，也包括記錄後的審查。
測試版需要什麼回饋
「答案怪怪的」是起點。真正有用的報告會包含：問了什麼、當時在哪個專案、預期結果，以及 Agent 實際回答或提議什麼。涉及任務時，請指出是哪一項，但不要把私人資料貼到公開回報中。
缺少脈絡也很重要。只問一個精準的澄清問題，可能比立刻回答更好；反覆問畫面上已經有的資訊，則是另一種問題。我想透過使用找到界線，而不是把自信語氣當成做好了的證據。
權限與用量取決於目前工作空間的方案和設定。價格頁面仍是今天可購買內容的依據，規劃中的新方案不會改變現有條件。
更多自主權，需要先證明
我不想慶祝模型一分鐘能生出幾項任務。塞滿待辦清單很容易。
我想知道你是否接受了正確的修改、拒絕了錯誤修改，並理解之後發生什麼。如果這個循環有效，Agent 才能承擔更多有用工作；如果無效，多給工具只會放大問題。
先做小事、檢查結果，重要決策留在自己手上。這是我希望這個測試版的使用方式。
