使用蜂羣

把一個清楚的目標交給蜂羣，讓各路分別處理其中一部分，再回到當前對話彙總。本篇用“審閲發佈説明”説明從發送任務到閲讀結果的完整過程。

準備材料

把需要審閲的文檔加入當前會話，或提供當前工作區內可讀取的文件。指明以哪個版本為準，以及這次是隻讀檢查還是允許修改。

例如，只審閲發佈説明時，不需要順便重寫產品文檔。範圍越清楚，各路輸出越容易合併。

開啓併發送

在輸入框底部打開「蜂羣」，確認顯示「蜂羣 開」，然後發送目標。只想在這一輪使用時，也可以直接在消息裏明確要求“用蜂羣”，不必長期打開開關。

用蜂羣審閲這份發佈説明。一路檢查功能描述是否前後一致，一路檢查操作步驟是否缺少前提或入口。每項問題給出原文位置、原因和修改建議。最後合併重複項，無法確認的內容單獨列出。先不要修改文件。

這條指令同時説明了分工和交付格式。只説“多開幾個智能體幫我看看”，沒有明確分工，不利於區分各路檢查範圍與合併結果。

查看執行進度

下面使用虛構的發佈説明演示完整流程。打開蜂羣並點擊發送，查看兩路審閲、合併和最終回覆；左右箭頭可以逐步查看，關係圖與列表可切換。演示僅在本頁運行，不會發送真實任務。

關係圖適合看整體：主智能體把工作交給各路，節點狀態展示哪些仍在運行。候選結論尚在等待時，不能把其中一路完成當作最終彙總已經完成。

列表適合逐項讀：對照任務名稱、工作器和當前狀態，打開記錄查看該路實際檢查了什麼。示例中的“功能描述”已完成，“操作步驟”仍在進行，兩種視圖表達的是同一組任務。

右側説明幫助你理解現在誰在做、是否需要等待其他分支，以及下一步會發生什麼。圖例中的顏色深淺表達用量，不代表結果質量。

安排先後順序

不是所有步驟都適合一起開始。繼續上面的審閲任務，如果還要生成修訂稿，應讓修訂稿等待兩路審閲結束：

可以這樣説明：

兩路審閲可以同時進行。等它們都結束後再整理修訂建議；有衝突的意見列出依據，由我確認，不要直接選擇一方改文件。

這就是依賴關係的用途：需要前置結果的工作等它完成，無關的工作繼續推進。普通任務也支持依賴關係，不是出現先後順序就必須使用遞歸任務。

讓結果能被下一路使用

“等待上游完成”和“參考已經完成的結果”是兩件事。前者決定能否開始，後者決定開始時有哪些材料可讀。

例如術語核對可以參考已經完成的功能審閲摘要，但摘要共享不等於共享整段對話，也不會讓正在運行的任務自動重新讀入所有新結論。如果術語核對必須覆蓋兩路最終結果，就明確要求它等待兩路結束。

需要這種結果參考時，把要求寫進任務，並在執行記錄中核對是否實際採用：

為後啓動的術語檢查提供已經完成的功能審閲摘要。沒有現成結果時先獨立檢查；最終彙總時再統一核對全部意見。

兩項檢查同時開始時，不把尚未完成的摘要作為已有輸入。必須使用完整上游結論的工作，應明確安排在上游結束之後。

交接完整產物時，要寫明文件或材料位置、版本和要使用的部分。不要只説“照上一位的結果處理”。

收到結果後怎麼做

先要求主智能體合併，而不是把各路回答原樣拼在一起：

按原文位置合併這次建議。重複問題只保留一項；不同意見列出各自依據。最後區分可以直接修改、需要我確認和暫時無法核實的內容。

檢查引用是否存在，建議是否改變原意，未完成的分支是否被遺漏。確認後再授權修改，並複核整份文檔。

如果多路要直接修改項目，提前劃分文件範圍。並行任務可以共用工作目錄，不會自動各自獲得隔離副本。部分失敗時，按 恢復與追加 處理，不必一上來重跑全部任務。

任務描述不是文件訪問權限邊界。共享工作區前，先移開無關憑據和私人文件，只提供各路分工需要的材料。