不代表。
假设你在 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 改程序
