不代表。
假設你在 Project 的：
QWEN.md
很清楚寫了一句：
「Production 不可直接修改。」
Qwen Code 每次進來，
也真的讀到了。
是不是代表：
從此可以放心開：
Auto。
甚至 YOLO，
因為 AI：
「知道 Production 不能碰」？
答案是：
不能這樣推。
因為 QWEN.md 解決的是：
Instruction。
不是：
Permission。
更不是：
Verification。
這三件事一定要分開。
QWEN.md 的工作是什麼？
Qwen Code 官方把：
QWEN.md
定位成：
AI 每個 Session 都會讀取的：
長期 Instructions。
例如：
這個 Project：
怎麼 Build。
怎麼 Test。
使用什麼 Coding Convention。
有哪些 Architecture Rule。
有哪些固定工作要求。
所以：
「Production 不可直接修改」
放進 Project QWEN.md，
是很合理的。
因為你確實希望：
每次 Agent 工作
都先知道這條規則。
但「知道規則」和「做不到違規動作」不是一回事
想像公司新員工報到。
主管說：
「你不可以進 Server Room。」
這是：
規則。
如果 Server Room：
本身有門禁。
員工沒有：
門卡。
這才是：
權限。
兩個一起存在，
才比較完整。
如果只有主管口頭說：
「不要進去。」
但：
門永遠開著。
員工手上又有：
Master Key。
你不能說：
因為規則寫得很清楚，
所以技術上：
絕對不可能進去。
AI Agent
也是同樣道理。
所以第一層叫 Instruction
QWEN.md：
告訴 Agent：
應該怎麼做。
例如：
不要直接修改 Production。
先跑 Test。
修改 Database 前先提出 Plan。
某個目錄不能動。
先保存 Backup。
這些都是：
非常有價值的 Context。
但它們仍然屬於：
模型需要理解與遵循的指令。
不是：
Operating System
突然把權限拿掉。
Qwen 官方自己甚至提醒：QWEN.md 不是愈長愈可靠
官方 Memory 文件明確建議：
QWEN.md：
Short and Specific。
短。
具體。
因為內容愈長，
Qwen：
可靠遵循全部 Instructions
的能力可能下降。
如果你同時有：
多份 QWEN.md
而且內容：
互相衝突，
官方也提醒：
Qwen 可能表現得：
不一致。
所以：
「有寫」
本身甚至不等於：
「永遠能正確理解這條規則在這次操作中的含義。」
例如一句看起來很明確的規則
「Production 不可直接修改。」
Agent 接著做：
修改一份 Deployment Script。
這算不算：
直接修改 Production？
目前可能：
還沒有。
但這份 Script
下一步如果自動執行，
可能就會：
碰 Production。
或者 Agent：
修改：
Infrastructure Config。
CI Workflow。
Database Migration。
Secrets Reference。
這些東西雖然：
不是直接登入 Production Server 改檔案，
最後卻可能：
影響 Production。
所以真正高風險系統，
不能期待一句自然語言：
涵蓋所有可能路徑。
第二層才是 Permission
Qwen Code 現在有：
多種 Approval Mode。
它們真正控制的是：
Agent 可以直接做到什麼程度。
這和：
QWEN.md
是兩層不同機制。
最安全的 Plan Mode
Qwen 官方把：
Plan Mode
設計成：
Read-only Analysis。
在這個模式裡，
主要工作是：
讀 Code。
理解 Repository。
規劃修改。
不直接：
修改檔案。
也不執行：
Shell Command。
所以如果今天你只是：
第一次讓 Qwen Code
分析一個重要 Project，
Plan Mode
本身就是比：
「我在 QWEN.md 寫請不要亂改」
更強的邊界。
因為：
它不是提醒 AI：
不要改。
而是：
這個模式本來就不讓修改開始。
再來是 Ask Permissions
如果真的準備開始修改，
但專案：
很重要。
不熟。
多人共用。
Qwen 官方建議可以使用：
Ask Permissions。
這個模式裡：
File Edit。
Shell Command
都需要：
人工批准。
也就是 Agent 說：
「我要改這個。」
你還有一次機會：
說：
不要。
這才是真正的 Human Gate
QWEN.md：
是：
「請記得不要做。」
Ask Permissions：
則是：
「你真的準備做以前，我還要再按一次。」
兩個一起用，
風險就比：
只靠 Prompt
低很多。
Auto-Edit 又不一樣
Auto-Edit：
可以自動批准：
File Edit。
但 Shell Command：
仍要人工確認。
這就代表：
如果你的 QWEN.md 寫：
「某些檔案不要修改。」
但 Agent 判斷：
某次 Edit 很合理，
這時你本來已經：
授權 File Edit 自動執行。
所以：
不要把 QWEN.md 誤認成 Auto-Edit 的替代 Permission System。
Auto Mode 則交給另一個 AI 分類器判斷風險
Qwen 官方目前說明：
Auto Mode
會利用：
LLM Classifier
評估：
Shell Command。
Network Call。
Workspace 外 Edit。
再決定：
哪些自動批准。
哪些阻擋。
其中：
Workspace 內一般 File Edit
通常可以直接進行。
所以如果：
Production Config
本身就放在：
目前 Workspace 裡，
你不能只因為：
「它沒有離開 Workspace」
就認為：
一定沒有風險。
Auto Mode 確實還有其他 Guardrail
例如：
Qwen 官方表示，
permissions.deny
這類 Hard Rule
會在 Classifier
以前先阻擋。
Classifier 無法連線時，
也採：
Fail-closed。
也就是：
不能判斷就不直接放行。
連續阻擋後，
還可能退回：
Manual Approval。
這些都比：
純文字提醒
更接近：
技術控制。
但 Auto Mode 仍然不是「所有風險都自動知道」
因為它仍然需要：
判斷。
例如某個 Shell Command：
看起來只是：
正常 Build。
實際專案卻把 Build Script
接上：
Deployment。
或者：
某個正常 Test Command
其實會：
重建測試 Database。
AI Classifier
不一定擁有：
你公司全部隱性背景。
所以高風險操作：
仍然不能因為：
「Auto Mode 有 Safety Classifier」
就完全不看。
YOLO 更不能靠 QWEN.md 當安全帶
YOLO 的名字其實已經：
說得很清楚。
Qwen 官方把它列為：
最高風險模式。
在 YOLO Mode，
File Edit。
Shell Command。
其他 Tool Call
都可以：
自動批准。
官方甚至直接提醒：
AI 可以執行：
你 Terminal 權限本身允許的 Command。
所以如果你的 Terminal：
可以進 Production。
可以拿 Production Credential。
可以 Push。
可以 Deploy。
你不能靠：
QWEN.md 裡一句：
「不要做」
就把：
YOLO
變成：
安全模式。
真正的問題是：Agent 手上到底有什麼能力？
這比：
Prompt 寫什麼
更重要。
例如：
Agent 根本沒有：
Production SSH Key。
沒有：
Production Database Credential。
沒有：
Cloud Admin Permission。
Deploy：
必須經另一個人工批准系統。
那麼即使 AI：
犯錯，
它真正能造成的範圍：
就比較小。
這叫：
Capability Boundary。
如果 Agent 本身什麼權限都有
Production SSH。
Database Admin。
Cloud Root。
Force Push。
Deployment Token。
然後你的安全設計只有：
QWEN.md：
「請不要亂用。」
那不是：
真正的：
Least Privilege。
所以高風險工作至少要有三層
第一層：
Instruction。
告訴 AI：
什麼應該做。
什麼不應該做。
這裡可以使用：
QWEN.md。
第二層：
Permission。
真的限制：
哪些 Edit。
Command。
Network。
Credential。
Deployment
能執行。
第三層：
Verification。
即使前面全部正確，
修改結果還要：
驗收。
Verification 又包括什麼？
最基本的：
Code Diff。
AI 到底改了：
哪些 File？
有沒有：
順手改了不相關的東西？
接著：
Test。
原本功能：
還能不能跑？
新的功能：
有沒有真的符合需求？
再來：
Staging。
真實流程：
跑起來對不對？
最後才是：
Production Approval。
這四個字非常重要
「規則不是驗收。」
你告訴 Agent：
「不能破壞 Login。」
它也表示：
知道。
最後它改完：
Login 仍然可能：
真的壞掉。
因為：
Agent 的 Intent
可能完全正確。
Implementation
仍然有 Bug。
所以甚至 Agent 100% 遵守 QWEN.md，也不代表 Code 一定正確
這又是另一個常見誤會。
假設 QWEN.md：
所有規則
它都遵守。
沒有碰：
Production。
沒有改：
Legacy Folder。
有先：
跑 Test。
仍然可能：
新的 Business Logic
寫錯。
Edge Case
漏掉。
Concurrency
有問題。
UI
在某個裝置跑掉。
所以 QWEN.md
解決的是：
工作規則。
不是：
程式正確性證明。
這其實和我們之前談 Replit Plan Mode 是同一件事
SasaDaily 8 月 20 日就寫過：
Replit Plan Mode
把步驟列得：
非常完整。
也不代表：
Build 以後
一定不會弄壞 App。
因為：
Plan 正確
和：
Implementation 正確
還是兩件事。
今天只是再多一層。
QWEN.md：
是 Instruction。
Plan：
是 Intended Change。
Execution：
是真正修改。
Verification：
才是在問：
結果到底對不對。
可以把 AI Coding 想成四道門
第一道：
它知不知道規則？
QWEN.md。
第二道：
它現在有沒有權限做？
Approval Mode。
Permissions。
Credential。
第三道：
它做的結果有沒有過關？
Test。
Diff。
Preview。
第四道：
要不要真的上線？
Human Approval。
Production Gate。
任何一道：
都不能完全取代下一道。
最危險的說法就是：「我已經告訴 AI 不要做了」
因為這句話只完成：
第一道門。
就像你在公司文件裡寫：
「所有付款超過 100 萬元必須主管批准。」
很好。
但如果：
付款系統實際上允許任何員工：
自己按下 500 萬付款，
那制度仍然：
有缺口。
真正成熟的 Workflow
會讓：
規則
和：
系統權限
一致。
對 Production 最實際的做法是：不要只靠 Agent 自律
例如：
Local：
Agent 可以比較自由。
Staging：
可以修改，
但要跑完整 Test。
Production：
Agent 不直接取得必要 Credential。
正式 Deployment：
另外經：
人工批准。
這樣即使某一天：
QWEN.md 沒載入。
內容衝突。
Agent 誤解。
Model 換掉。
你仍然還有：
技術邊界。
「沒 Credential」通常比「請不要用 Credential」可靠
這就是：
Least Privilege
最核心的概念。
Agent 只得到：
完成這次工作
真正需要的：
最低權限。
不是：
因為未來可能有用，
先全部給。
如果今天只是：
分析 Code，
甚至不需要：
Write Permission。
這時直接：
Plan Mode
比任何：
「請不要修改」
更乾淨。
如果只是要修 Local Bug 呢？
那就不用把流程搞得：
像核電廠。
可以根據：
風險
調整。
例如：
個人測試 Project。
完整 Git。
隨時可以 Reset。
沒有敏感 Credential。
你可能願意：
Auto-Edit。
甚至在：
真正隔離環境
跑更多自動化。
這很合理。
重點不是：
「永遠只能最保守。」
而是：
權限要跟損失半徑相配。
損失半徑愈大，越不能只靠 Instruction
例如修改：
README。
風險低。
修改：
CSS。
可能：
中低。
Database Migration。
高。
Payment Logic。
高。
Production Infrastructure。
非常高。
不同工作：
本來就應該：
不同 Permission Mode。
不同 Review。
不同 Approval。
所以「Production 不可修改」最好不是只有一句文字
比較成熟的設計是：
QWEN.md：
有規則。
↓
Agent Session：
使用適當 Approval Mode。
↓
Production Credential：
不直接暴露。
↓
Code Change：
先 Local／Branch。
↓
Test：
通過。
↓
Diff：
人看。
↓
Staging：
驗證。
↓
正式 Deployment：
另外批准。
這時：
QWEN.md 才是：
整個 Safety System
其中一層。
不是：
全部。
那 QWEN.md 還重要嗎？
非常重要。
不要因為它不是：
硬權限
就覺得：
沒有用。
因為它可以：
讓 Agent 從一開始
就知道：
正確工作方式。
如果 AI 根本不知道：
Production 不可碰，
它可能：
一直提出不適合的 Plan。
如果知道：
它可以主動：
避開。
提醒你。
使用 Staging。
改成：
只產生 Deployment Instructions。
這能降低：
很多不必要風險。
所以真正正確的理解應該是
QWEN.md：
降低 Agent 做出錯誤決策的機率。
Permission：
限制錯誤決策真正能造成的動作。
Verification：
檢查即使動作合法，結果是不是仍然有問題。
這三層：
功能不同。
還有一個常見坑：QWEN.md 彼此打架
例如 User-wide QWEN.md 寫：
「所有修改自動完成，不要一直問我。」
Project QWEN.md 又寫：
「任何 Production 相關修改必須先確認。」
如果規則：
模糊。
衝突。
AI 就必須：
自己解讀。
Qwen 官方 Troubleshooting
也直接提醒：
多份 QWEN.md
如果存在：
Conflicting Instructions，
可能導致：
Inconsistent Behavior。
所以重要規則不只要：
寫。
還要定期：
Review。
尤其今天一分鐘教學才剛做過 Memory Scope
User。
Project-shared。
Project-local。
分 Scope
不只是為了：
整齊。
還能減少：
規則衝突。
把：
Production Policy
放在真正屬於這個 Project
的位置。
不要讓另一個 Project
的規則：
一起進來。
如果今天只想記一個安全公式
可以記：
Instruction ≠ Permission ≠ Verification。
Instruction：
QWEN.md。
Permission：
Approval Mode＋真正的系統權限。
Verification：
Diff＋Test＋Preview＋Human Approval。
看到任何 AI Agent 宣稱：
「已經有 Rules。」
下一個問題都應該是：
「Rules 以外，真正阻止錯誤發生的技術邊界在哪裡？」
最後回答一次今天的問題
QWEN.md
已經寫：
「Production 不可直接修改。」
這代表：
Qwen Code
每個 Session
可以取得一條明確：
Project Instruction。
非常值得做。
但它不代表：
Agent 技術上一定：
碰不到 Production。
也不代表：
每次都一定：
完美理解這句規則。
更不代表：
只要遵守這條規則，
寫出的 Code
就一定正確。
所以：
不要把：
Instruction File
當成：
Security Boundary。
真正高風險的 AI Coding Workflow，
應該同時做到：
先告訴它規則。
再限制它權限。
最後驗收它結果。
這樣 AI Agent 才不是：
「希望它不要出錯。」
而是：
即使它真的出錯，也不容易一步就把錯誤送進 Production。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
AI 快問快答｜2026/08/24：Slack Code 看完 Plan、Code Diff、Preview，就可以直接部署 Production 嗎？
AI 快問快答｜2026/08/20：Replit Plan Mode 已經把修改步驟列完整，就代表照著 Build 一定不會弄壞原本 App 嗎？
AI 一分鐘教學｜2026/08/24：Slack Code 驗收條件怎麼寫？先用「現在／要變成／不能動」三格再叫 AI 改程式
