今天你在 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 吗？
