今天你在 Qwen Code 裡告訴 AI：
「Production 絕對不能直接修改。」
很好。
這是一條很重要的規則。
接著你換到另一個小型測試專案。
那個專案根本沒有：
Production。
結果 AI 還一直把：
「Production 不可修改」
當成全域工作原則。
這時問題不是：
Qwen Code 記錯了。
而是：
你把一條只屬於某個專案的規則，放到了太大的記憶範圍。
今天只學一個問題。
每次要讓 AI：
長期記住一件事以前，
先問：
「如果我現在換到另一個完全不同的 Project，這句話還成立嗎？」
只靠這一題，
就能先排掉很多：
Memory Scope
錯誤。
第一種｜換到所有專案都成立
例如：
「我所有 TypeScript 專案都優先使用 pnpm。」
或者：
「修改 Code 前，我希望先看 Plan。」
或者：
「回答時先說明風險，再進行高風險修改。」
這種規則的特徵是：
今天做：
網站。
明天做：
App。
後天換：
另一個 Repository。
你都還是：
希望 AI 照做。
這才比較適合：
User-wide Instruction。
Qwen Code 官方文件目前提供：
~/.qwen/QWEN.md
作為：
你自己、跨所有 Projects
都會載入的指令。
所以最簡單判斷就是：
換 Project 還成立 → 才考慮放全域。
第二種｜只有這個 Project 成立
例如：
「這個 Laravel 專案使用 PostgreSQL。」
「這個 Repository 所有新 API 都必須先補 Feature Test。」
「這個網站 Production 不能直接 Deploy。」
「這個專案 /legacy 目錄現在不能修改。」
換到另一個 Project，
這些規則可能：
完全不成立。
那就不要放進：
全域 User Instruction。
比較適合：
這個 Project 自己的：
QWEN.md。
為什麼 Project Root 的 QWEN.md 很適合這類規則？
Qwen Code 官方把：
Project Root 的 QWEN.md
設計成：
這個專案的固定 Instructions。
而且可以：
放進 Version Control。
所以如果是一個團隊共同工作的 Repository，
裡面可以放：
Build Command。
Test Command。
Coding Convention。
Architecture Decision。
Git Workflow。
也就是：
不是「我喜歡怎麼工作」，而是「這個 Project 本來就應該怎麼工作」。
這裡有一個很好用的第二個問題
當你已經判斷：
「只屬於這個 Project。」
再問：
「其他隊友也應該知道嗎？」
如果答案：
是。
放：
Project Root QWEN.md
通常比較合理。
因為它可以：
隨 Repository 一起分享。
第三種｜只屬於這個 Project，但只有我自己需要
例如：
「我本機 Docker Container 叫什麼。」
「我自己的測試資料放在哪裡。」
「我現在暫時用這個 Debug Command。」
「這台電腦的 Local Environment 有一個特殊設定。」
這些資訊：
的確只和目前 Project 有關。
但如果直接放進：
大家共用的 QWEN.md，
隊友可能：
根本用不到。
甚至：
被你的本機設定誤導。
Qwen Code 官方另外提供：
.qwen/QWEN.local.md
給這種：
只屬於你，而且只屬於這個 Project
的 Instructions。
所以真正只有三格
看到一條規則，
先不要急著：
Remember。
先分類。
換專案還成立？
是：
User-wide。
不是：
繼續問。
同一個專案的其他人也需要？
是：
Project-shared。
不是：
Project-local。
完成。
用三個實際例子測一次
第一句：
「所有 JavaScript 專案都使用 pnpm，不使用 npm。」
假設這真的是你的固定工作方式。
換 Project：
仍然成立。
所以：
User。
第二句
「這個網站正式部署以前，一定先在 Staging 驗證。」
換 Project：
不一定成立。
同一專案的隊友：
也都應該知道。
所以：
Project-shared。
第三句
「我本機測試這個專案時使用自己的 Debug Port。」
換 Project：
不成立。
隊友：
也不需要。
所以：
Project-local。
這就是今天整個方法
不是：
學一堆 Qwen Code 指令。
而是建立一個：
Scope Test。
每一條 Memory／Instruction
先通過：
這個測試，
再決定放哪裡。
為什麼這比「AI 記得更多」重要？
因為 AI Memory
真正危險的地方，
往往不是：
忘記。
而是：
記得一件原本正確的事，卻在錯的地方使用。
例如 Project A：
使用：
Node 24。
Project B：
還在：
Node 22。
如果全域 Memory 寫：
「專案使用 Node 24。」
你回到 Project B，
AI 可能非常有自信地：
按照 Node 24
修改。
它不是：
幻覺。
它真的：
記得。
只是：
Scope 錯了。
「記錯」和「用錯地方」是兩種完全不同的錯
第一種：
Memory 本身：
錯。
例如：
你明明用 PostgreSQL，
卻記成 MySQL。
第二種：
Memory 是對的，
但只在：
另一個專案
對。
AI Agent 工作愈長，
第二種錯誤會：
愈值得注意。
因為很多 Project Rule
單獨看：
都很合理。
Qwen Code 0.23.0 為什麼特別值得在今天學這件事？
因為最新版開始更明確支援：
Scoped Workspace Memory。
Release Notes 顯示，
Memory Task 可以指定：
Project Target。
或：
User Target。
而且 Remember／Forget
在不同 Store 之間，
會有：
Filesystem Permission Boundary。
這代表產品本身也開始把：
「記在哪裡」
當成重要問題。
不是所有記憶：
塞到同一個地方。
Qwen Code 的正式文件甚至把幾種 Instructions 分得更細
官方目前的 Memory 文件，
主要有兩種長期知識來源。
第一：
QWEN.md。
你自己寫。
屬於：
固定 Instructions。
第二：
Auto-memory。
由 Qwen 在工作過程中，
自己保存：
有用的偏好。
Feedback。
Project Context。
Reference。
所以今天這個分類方法，
不只是：
整理檔案。
它真正是在幫你回答：
哪些規則值得成為長期 Context？
對固定規則，我反而更建議不要完全依賴 Auto-memory
例如：
「Production 不可以直接修改。」
這不是：
AI 聊著聊著「最好能記住」的事情。
它是：
重要 Boundary。
這類規則更適合：
明確寫進：
QWEN.md。
因為官方文件也區分得很清楚。
Auto-memory：
比較像：
Best-effort Learning。
QWEN.md：
則是每個 Session
固定會讀的：
Instruction。
所以還可以再加一個很簡單的判斷
如果一句話是：
「最好記得。」
可以考慮：
Memory。
如果一句話是：
「每一次都必須遵守。」
更值得：
明確寫成：
Instruction。
不要把：
Safety Rule
只交給：
AI 自己判斷要不要記。
例如 Production 規則
不要只期待 AI：
某一次對話聽過，
以後就一直記得。
可以直接在 Project QWEN.md
寫清楚：
正式 Production：
不屬於自動修改範圍。
所有 Deploy：
先人工批准。
這種規則：
短。
明確。
專案專屬。
非常適合：
Project Instruction。
QWEN.md 也不要變成一本 200 頁公司手冊
Qwen 官方自己就提醒：
Instructions：
最好：
短。
具體。
如果 QWEN.md
愈來愈長，
模型遵循效果可能：
下降。
所以不要看到：
「AI 可以記。」
就把：
所有 README。
會議紀錄。
客戶 Email。
完整公司 Wiki
全部塞進去。
Memory 的目標不是：
資料愈多愈好。
是：
下一次工作時，真正需要的規則能準確出現。
一條好的 Project Rule 最好只回答一件事
例如：
不好：
「這個專案很重要，請小心修改，而且我們一直都很重視品質，部署前最好仔細看看。」
太模糊。
比較好：
「修改資料庫 Schema 前，先產生 Migration Plan，不得直接執行 Production Migration。」
AI 比較知道：
什麼情況：
要做什麼。
另一個常見問題：舊規則失效了卻沒有刪
假設三個月前：
「這個專案使用 Node 22。」
現在已經：
升級 Node 24。
但 Memory：
還留著。
Agent 就可能一直：
按照舊環境工作。
所以記憶除了：
Remember，
還需要：
Forget。
Qwen Code 本身也提供：
/forget
處理不再正確的 Auto-memory。
正式 Instructions
則應該：
直接更新相關 QWEN.md。
你可以每次版本大更新後做一次「Memory Review」
不用每天做。
例如：
Framework 升級。
Deployment Flow 改變。
資料庫搬家。
重大 Folder 重構。
CI 改版。
做完後，
順便問：
「哪些 AI Instructions 現在已經過期？」
把舊規則：
一起清掉。
這樣 AI 才不是：
永遠帶著過期 SOP
進新版本。
Project Memory 還有另一個細節：Worktree 可能有自己的範圍
Qwen Code 官方 Memory 文件指出，
Auto-memory 會按照 Project 保存。
同一個 Checkout 的 Branch
可以共享相關 Memory；
Linked Git Worktree
則有自己的 Memory Folder。
Daemon Mode 的新文件還提供：
Workspace-based Project-memory Partitioning。
這代表 Qwen Code 已經開始把：
Repository。
Workspace。
Worktree。
之間的 Context Boundary
做得愈來愈細。
一般使用者不需要：
第一天就全部設定。
但觀念一定要先有：
AI 工作空間不同，記憶範圍也應該跟著不同。
今天第一次實作，不需要碰複雜設定
打開你一個真實 Project。
先找：
三條你每次都會重複告訴 AI 的規則。
例如：
「用 pnpm。」
「跑某一個 Test。」
「Production 不直接改。」
然後逐條問：
換 Project 還成立嗎？
第一條可能得到
「用 pnpm。」
假設你所有 Project：
都這樣。
放：
User-wide。
第二條
「改 Checkout 前先跑這個專案的 Feature Test。」
只有這個 Repository
才有這個 Test。
放：
Project。
第三條
「我的本機暫時使用某個 Debug Shortcut。」
只有：
你。
只有：
這個 Project。
放：
Project-local。
這樣就完成。
不用一開始建立 50 條 Memory
先放：
3～5 條
真正高頻。
真正穩定。
真正影響工作結果
的規則。
用一星期。
看看：
AI 有沒有：
在正確 Project
使用。
如果有：
再慢慢增加。
還有一個非常重要的原則：Secret 不要當 Memory
API Key。
Password。
Token。
Private Key。
不要因為：
「AI 下次需要」
就放進：
Memory。
Project Instructions
應該描述：
怎麼工作。
不是：
把秘密直接保存成 Context。
尤其是：
會進 Git 的 Project QWEN.md，
更不能隨便放：
Credential。
如果你真的只記得今天一句話
就是：
「換 Project 還成立嗎？」
成立：
才有資格往：
User-wide
放。
不成立：
就留在：
Project。
再問：
其他隊友需不需要。
需要：
Project-shared。
不需要：
Project-local。
這個方法不只適用 Qwen Code
未來你使用：
Claude Code。
Codex。
Gemini CLI。
其他有長期 Memory 的 Agent，
都會遇到：
一樣問題。
AI 愈能：
跨 Session 記住事情，
我們就愈需要知道：
它到底應該在哪個範圍記住。
因為真正安全的 AI Memory
不是：
永遠不忘。
而是：
在該記得的地方記得，在不該帶過去的 Project 裡不要出現。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
AI 一分鐘教學｜2026/08/20：Replit 要改 App 前，先開 Plan Mode，只看計畫、不先動程式
今日 AI 工具｜2026/08/24：Slack Code，把 AI Coding Agent 拉進 Code Channel，團隊一起看計畫、改動與 Preview
AI 快問快答｜2026/08/20：Replit Plan Mode 已經把修改步驟列完整，就代表照著 Build 一定不會弄壞原本 App 嗎？
