Kiro Memory 1.4.10 起預設關閉：四個存取等級怎麼選、跟 steering 怎麼分工（手把手設定）

瀏覽次數: 4

如果你在 10 月 19 日升級到 Kiro IDE 1.4.0、第一次看到側邊欄多出一個 Memories 圖示，隔天又更新到 1.4.10，那你可能會發現：昨天 Kiro 還記得「這個 repo 跑測試要加 --runInBand」，今天開新 session 它又忘了。

這不是 bug。AWS 的 Kiro 團隊在 1.4.10 的 changelog 標題直接寫了：Memory Setting Defaults to Off。從 1.4.0 推出跨 session 記憶，到 1.4.10 把預設改成關閉，中間只隔一天。

這篇不評論這個決定，而是把它當作一個好機會：既然記憶現在要你「主動打開」，那就花十分鐘搞懂它怎麼運作、四個存取等級差在哪、什麼該交給 Memory、什麼該寫進 steering，然後照著設定一次。

本文大綱

一、先確認：你的 Memory 現在是開還是關？

官方文件的說法是：Memory 由一個使用者層級設定控制，預設為 Off；如果你之前已經選過等級，更新後會保留你的選擇。

所以有兩種人：

1.4.0 時從沒動過設定的人：更新到 1.4.10 後就是 Off，Kiro 不讀也不寫記憶。
在 1.4.0 主動選過等級的人：維持你當時的選擇。

檢查方式（IDE）：

點左側 activity bar 的 Memories 圖示，打開 Memory view。
點 Memory settings 齒輪，Settings 會直接跳到 Kiro Agent: Memory 這一項。
看目前的值是哪一級。

注意兩個容易踩的點：

這是 user setting。文件明講：寫在 workspace settings 裡沒有效果。想用 .vscode/settings.json 幫整個團隊統一開啟，行不通。
開關、或切換到／離開 Use only，都只對新 session 生效。改完會跳出「Memory settings updated. The change applies to new sessions.」，記得按 Start new session，不然你會以為設定沒作用。

二、Memory 到底記了什麼、存在哪

先建立正確的心智模型，後面的設定才選得對。

它不是對話紀錄。 文件寫得很清楚：每筆 memory 是一個有 title、description、content 的紀錄，不是過去對話的副本。它要記的是「下一次還用得上的東西」，官方列的類型有：

repo 的指令和慣例（怎麼 build、怎麼跑測試）
你對 Kiro 的糾正
debug 時得到的洞見
已經排除過的做法（這點很實用，省得它每次都重新提一次你已經否決的方案）
你偏好的工作方式

它存在本機，綁使用者帳號，不綁 workspace。 原文是「stored locally per user account, not per workspace」。每筆記憶的 location 會標成 Global 或某個 repo 名稱；Memory view 只會列出 Global 記憶，加上目前視窗裡打開的 repo 所屬的記憶。CLI 端則會顯示像 repo:github/<owner>/<repository> 這樣的 scope。

IDE 和 CLI 共用同一份記憶庫，但各有各的開關。 同一台機器上，Kiro IDE 和 Kiro CLI 讀寫的是同一批 memories，可是 Memory 設定是分開的。這代表：你在 IDE 設成 Use only，但 CLI 開了自動更新，CLI 寫進去的東西，IDE 下一次還是會讀到。

它是「相關時才取用」。 文件描述的流程是：在後來的 session 裡，Kiro 可以在處理你的請求時「retrieve a matching memory」。也就是說，它不是把所有記憶一次塞進 context，而是按需要撈出符合的那幾筆。至於比對方式、一次撈幾筆、有沒有數量上限，文件沒有寫。

三、四個存取等級，怎麼選

IDE 的 Kiro Agent: Memory 有四級，用一句話講清楚差別：

等級	會讀記憶	你要求時會改	自動新增／更新
Use and learn	是	是	是
Use but don't learn	是	是	否
Use only	是	否（就算你要求也不改）	否
Off（預設）	否	否	否

前三級改動記憶時都還要經過你的權限設定。

我的建議是照「信任程度」逐步往上開：

第一週：Use but don't learn。 Kiro 會用記憶，但只有你明確叫它記，它才記。這讓你完全掌握記憶庫裡有什麼，也能順便觀察它取用記憶時對結果有沒有幫助。

確認記憶品質後：Use and learn。 讓它自己累積糾正和慣例。這一級最省力，但也最需要定期清理（第六節講）。

記憶庫已經整理好、不想再被動到：Use only。 適合你花了時間整理出一套乾淨的記憶，不希望某次 debug 的臨時結論把它污染掉。要注意 Use only 是真的唯讀：你在 chat 裡說「幫我更新這筆」它也不會做。不過從 Memory view 右鍵 Delete 仍然可以手動刪除。

Off 的時機： 做 demo、錄教學、或在客戶的機器上工作，不希望你個人的偏好混進來的時候。

CLI 怎麼開

Memory 在 Kiro CLI 需要 V3。在本機的 V3 session 裡：

/memories
→ 選 config
→ 選存取等級：read & write / read only / off
→ 若選 read & write，再決定要不要勾 Automatic memory updates

CLI 只有三級。對照 IDE：read & write 不勾自動更新 ≈ Use but don't learn；勾了 ≈ Use and learn；read only ≈ Use only。存取等級的變更同樣在新 session 才生效，但 Automatic memory updates 這個子選項改了會立刻生效。它的說明文字是「Automatically create and refine memories, including after a session ends」，也就是 session 結束後它還可能回頭整理記憶。

看記憶：/memories → list，ctrl+p 預覽、Enter 打開全文。CLI 的列表是唯讀的。另外文件沒寫 CLI 的預設值是哪一級，建議你自己進 /memories → config 確認一次。

四、Memory 和 steering 怎麼分工

Kiro 本來就有 steering：把 markdown 放在專案根目錄的 .kiro/steering/（只作用於該 workspace），或家目錄的 ~/.kiro/steering/（作用於所有 workspace）。兩邊衝突時，workspace steering 優先。steering 檔可以用 front matter 設定 inclusion 模式：always（預設，每次都載入）、fileMatch（碰到符合 pattern 的檔案才載入）、manual（用 #steering-file-name 手動引用）、auto（請求內容符合 description 時載入）。

那有了 Memory，steering 還要寫嗎？要。兩者解決的是不同問題：

steering 是寫給團隊的規則：跟著 repo 走、進 git、會被 code review，新同事 clone 下來就有。
Memory 是你個人的經驗筆記：存在你的本機帳號裡，別人看不到，也不會進版控。

實際判斷可以用一個問題：「這條規則換一個同事來用 Kiro，也該遵守嗎？」

是 → 寫進 .kiro/steering/。例如「API 一律回傳 { data, error }」「不准直接改 migrations/ 底下已發布的檔」。
否，是我個人的習慣或這陣子的踩坑 → 交給 Memory。例如「我偏好先給 diff 再解釋」「上週試過把 Redis 換成 in-memory cache，壓測撐不住，別再提」。

還有一個升級路徑值得養成：Memory 裡反覆被取用、而且其實是團隊共識的那幾筆，定期搬進 steering。Memory 是草稿區，steering 是正式規範。

五、讓 Kiro 記得「對」的東西：prompt 招式

在 Use but don't learn 底下，記憶只在你開口時才會產生，所以怎麼開口決定記憶的品質。記憶紀錄有 title、description、content 三個欄位，你給的資訊越接近這個結構，存下來的東西越好用。

招式 1：指令類，給可執行的完整指令和適用範圍。

記住這個 repo 的慣例：跑單一套件測試用
`pnpm --filter @app/api test -- --runInBand`，
不加 --runInBand 會因為共用 DB 互相干擾而失敗。
這只適用於這個 repo，不要存成全域。

招式 2：排除過的做法，要寫「為什麼排除」。 只寫「別用 X」，下次換個情境它可能又覺得 X 合理；寫清楚原因，它才能判斷新情境是否適用。

把這個結論存成記憶：我們評估過用 Prisma 的 interactive
transaction 處理批次匯入，但在 5 萬筆以上會撞 timeout，
已改用分批 createMany。之後遇到批次寫入，不要再建議
interactive transaction，除非筆數明確小於 1 萬。

招式 3：個人偏好，存成 Global。

記住我的偏好（全域）：修改超過 3 個檔案前，先列出計畫
讓我確認；回覆時先給 diff，再用三行以內說明。

招式 4：糾正當下順手存。 Kiro 犯錯、你糾正之後，緊接著說「把剛剛這個糾正記下來，標題用『○○○』」。這是 Use but don't learn 模式下最自然的記憶來源，效果接近 Use and learn，但每一筆都經過你點頭。

怎麼知道它真的用了記憶？ chat 會顯示 Memory accessed (1)、Memory created (1)、Memory updated (1) 這類標記；CLI 會出現 Memory 項目並標示 command=get 和記憶標題。如果你覺得某個回答怪怪的，先看有沒有 Memory accessed，可能是一筆過期的記憶在作祟。

六、記憶庫的維護：別讓它變成技術債

Memory 會累積，累積就會過期。建議每週固定花五分鐘做一次：

打開 Memory view，按 Refresh Memories。
用 Search memories… 搜尋最近改過的模組名稱、套件名稱，看有沒有跟現況矛盾的記憶。
過期的右鍵 Delete（Kiro 會要求確認）。
被反覆取用、又屬於團隊共識的，搬進 .kiro/steering/，然後刪掉原本那筆記憶，避免兩邊各說各話。

特別要清的三種：

版本相關的記憶：「Next 14 要這樣寫」這種，升級後就是毒藥。
臨時 workaround：上游修好了，記憶還叫 Kiro 繞路。
錯誤的 debug 結論：當時以為是 A 造成的，後來證明是 B，但 A 那筆還在。

七、限制與還不清楚的地方

這段誠實列出從文件看得到的邊界，以及文件沒說的部分：

Workspace trust：就算開了 Use and learn 或 Use but don't learn，在你沒有信任的 workspace 裡，Kiro 不能從 chat 新增、修改或刪除記憶，但仍然可以讀。換句話說，打開一個陌生 repo 時，你累積的個人記憶還是會被用上。
本機存放路徑：文件只說存在本機、按使用者帳號存，沒有公開實際路徑，所以目前不建議依賴手動備份或用腳本同步。
送給模型的內容：文件沒有說明被取用的記憶怎麼送給模型、會不會離開本機，有隱私疑慮的團隊值得向官方確認。
取用機制細節：「retrieve a matching memory」怎麼比對、有無數量上限，文件沒寫。
Web 版：Memory 頁面的 Web 分頁目前寫「Memory support coming soon」。
為什麼一天後就改預設：1.4.10 changelog 只寫了「changes the Memory setting's default to Off」，沒有說明原因。我們不猜，但從結果看，Kiro 團隊選擇讓「會自動寫入、跨 session 帶著走」的功能由使用者自己決定要不要開，這跟上面的 trust 規則是同一個方向。

八、照著做：十分鐘設定清單

更新到 Kiro IDE 1.4.10 以上，打開 Memories view，確認 Kiro Agent: Memory 目前的值。
設成 Use but don't learn，按 Start new session。
有用 CLI 的話，升到 V3，/memories → config 設成 read & write、先不勾 Automatic memory updates，讓兩邊行為一致。
用第五節的四個招式，手動存 3 到 5 筆最常重複交代的事：測試指令、已排除的方案、個人回覆偏好。
把其中屬於團隊規則的寫進 .kiro/steering/，進 git。
用一週，觀察 Memory accessed 出現時回答有沒有變好。
品質穩定再升 Use and learn，並把每週五分鐘的清理排進行事曆。

Memory 改成預設關閉，換個角度看反而是好事：它逼你在打開之前先想清楚，你要 Kiro 記住的到底是什麼。

來源

Kiro IDE Changelog 1.4.10：Memory Setting Defaults to Off, Workflow Plan Feedback, and Resilient Powers（2026-10-20，Kiro / AWS）https://kiro.dev/changelog/ide/1-4-10/
Kiro IDE Changelog 1.4.0：Memory Across Chat Sessions（2026-10-19）https://kiro.dev/changelog/ide/1-4/
Kiro Docs：Memory（IDE / CLI / Web 分頁）https://kiro.dev/docs/memory/
Kiro Docs：Steering https://kiro.dev/docs/steering/
Kiro Docs：Workspace trust https://kiro.dev/docs/permissions/#workspace-trust