建議歸位機制
建議產出後若沒有歸位機制，就會反覆被重提而不落地——觀察不會自動變成行動，需要一個 queue 把它吃進去。
雷蒙的解釋
2026 年 W22 的雙 AI 復盤抓到一個摩擦模式，雷蒙叫它「告訴你了沒落地」：同一個建議在 daily log 反覆出現，但因為沒有機制把它從「建議」推到「完成」，提了就忘，下次又重提。實測數據很難看——同一件工具設定該寫進 Skill 這件事在兩週內被提了 4 次（期間重複做了同樣的白工），另一項基礎建設被提了 3 次仍未落地。
問題不是 AI 知識不足，也不是雷蒙不想做，而是「建議」這種產物天生沒有家：它不是待辦、不是專案、不是知識，只是一句觀察。解法是給它一個家——把建議吃進 actionable backlog，用出現次數自動升級優先級，做完的項目留在 Done 不刪（避免下次又被當成新建議）。復盤的價值不在「知道發生什麼」，在「建議有沒有地方去」。
現行落地
- 每週復盤前必讀的 work queue：規則是同建議出現 2+ 次自動進 queue（P1）、3+ 次升 P0、4+ 次標 RED ALERT 當週必處理；超過 30 天沒動的 P0 要嘛降級要嘛拆小，不能放著爛。
- TODO 發佈清單的 backlog 降級制：內容候選未入精選、連續 3 週未選中就自動降級——同一個原理反著用，讓沒人要的建議自然退場，而不是永遠佔位。
什麼時候用
- 復盤、會議、AI 對話產出「應該要做 X」的建議時：先問這條建議會被誰、在什麼時機再次讀到。
- 發現自己（或 AI）第二次講同一件事時：這就是缺歸位機制的訊號，別再重講一次，先建 queue。
- 設計任何自動化盤點（daily log、週報、健檢腳本）時：輸出端一定要接一個會被消化的入口，否則盤點只是儀式。
反例與邊界
- 歸位不等於全都要做：queue 的另一半功能是體面地說不——降級與退場規則跟升級規則一樣重要。
- 不要為每種建議各建一套 queue：同一件事只保留一個主要入口，多個 queue 本身就會變成新的「沒人讀的建議」。
- 一次性決策不需要歸位機制，寫進 daily log 就結束；只有「重複出現的可行動建議」才值得進 queue。
出處
2026-W22 雙 AI 復盤儀式首次把這個摩擦命名為「告訴你了沒落地」，並提議建立 Work Queue 機制；2026-05-25 落地為一份常設的 action queue。
在哪裡討論過
相關概念頁
- 復盤 — 復盤的產物從「觀察報告」升級為「有去處的行動」，這張卡是復盤閉環的最後一哩。
- AI工具應用 — AI 自動盤點（daily log、weekly insights）量產建議，更需要歸位機制消化。