Today, you tell the AI in Qwen Code:
“Production must never be modified directly.”
Great.
That’s an important rule.
Then you switch to a small testing project.
That project doesn’t even have:
Production.
Yet the AI keeps treating:
“Production cannot be modified”
as a global working principle.
At this point, the problem is not that:
Qwen Code remembered it wrong.
Instead, it’s that:
you put a project-specific rule into a memory scope that is too broad.
Today, we’ll learn just one question.
Before making AI:
remember something long-term,
ask first:
“If I switch to a completely different project, does this still apply?”
Just this one question
helps filter out many common
Memory Scope
mistakes.
Type 1｜Rule Applies Across All Projects
For example:
“All my TypeScript projects prioritize using pnpm.”
Or:
“Before modifying code, I want to see the plan first.”
Or:
“When answering, first explain risks before making high-risk changes.”
These rules share the feature that:
Today you work on:
a website.
Tomorrow on:
an app.
The day after, a
different repository.
You still want the AI:
to follow these.
These are best placed as:
User-wide Instructions.
Qwen Code’s official documentation currently supports:
~/.qwen/QWEN.md
as rules that load for:
you personally, across all projects.
The simplest check is thus:
If it still applies when you switch projects → consider global scope.
Type 2｜Rule Applies Only Within This Project
For example:
“This Laravel project uses PostgreSQL.”
“All new APIs in this repo must have feature tests first.”
“Production on this site cannot deploy directly.”
“The /legacy folder in this project must not be modified right now.”
Switching to another project,
these rules may:
not apply at all.
So don’t put them into:
global User Instructions.
Instead, put them into:
this project’s own
QWEN.md.
Why Is the Project Root QWEN.md Ideal for These Rules?
The Qwen Code official designates:
the Project Root QWEN.md
as:
fixed instructions for this project.
It can also be:
put under version control.
If it’s a team-working repository,
you can put in:
build commands,
test commands,
coding conventions,
architecture decisions,
Git workflows.
In other words,
these aren’t “how I like to work,” but “how this project should work.”
A Useful Second Question
After deciding a rule:
“only belongs to this project,”
ask:
“Should other teammates also know this?”
If yes,
it makes sense to put it in the:
project root QWEN.md.
This way it can be:
shared through the repository.
Type 3｜Only Belongs to This Project and Only Me
For example:
“What my local Docker container is named.”
“Where I keep my personal test data.”
“The temporary debug command I am using now.”
“My local environment has some specific settings.”
These relate only to the current project,
but should they go in:
a shared QWEN.md?
Teammates might:
never need them,
or worse, get confused by your local set up.
Qwen Code provides:
.qwen/QWEN.local.md
as instructions for
just you, and just this project.
So there Are Three Clear Scopes
When you see a rule,
don’t rush to:
“Remember it.”
Instead classify it.
Does it still apply when switching projects?
If yes:
User-wide.
If not:
ask:
Do other people in the same project need it?
If yes:
Project-shared.
If not:
Project-local.
Done.
Test with Three Examples
Example 1:
“All JavaScript projects use pnpm instead of npm.”
Assuming this is your stable working style.
Switch projects:
still true.
So:
User-wide.
Example 2
“Before production deploy, always verify in staging.”
Switch projects:
not always true.
Teammates in same project:
should know this, too.
So:
Project-shared.
Example 3
“I use my own debug port locally when testing this project.”
Switch projects:
not true.
Teammates:
don’t need it.
So:
Project-local.
This Is the Entire Method
It’s not about learning a bunch of Qwen Code commands.
It’s about establishing a:
Scope Test.
For every memory or instruction,
run this test.
Then decide where to place it.
Why Is This More Important Than Just “Remembering More”?
Because the real danger of AI memory
is not:
forgetting.
It’s:
remembering something correct but applying it in the wrong place.
For example, Project A:
uses Node 24.
Project B:
still on Node 22.
If global memory says:
“This project uses Node 24.”
When you return to Project B,
the AI might confidently:
work as if on Node 24.
This isn’t:
hallucination.
It is actually:
remembering.
Just with:
the wrong scope.
“Remembering Wrong” vs. “Using Memory in the Wrong Place” Are Two Different Types of Mistakes
Type 1:
The memory itself:
is incorrect.
For example,
you use PostgreSQL,
but the AI remembers MySQL.
Type 2:
The memory is correct,
but it only applies in:
another project.
The longer the AI agent works,
the more serious Type 2 mistakes become.
Because many project rules
make sense only in context.
Why Learn This Now With Qwen Code 0.23.0?
Because the latest version clearly supports:
Scoped Workspace Memory.
Release notes show that memory tasks can specify:
Project target
or
User target.
Remember and forget
happen across different stores,
with filesystem permission boundaries.
This means the product itself
has begun treating:
“Where something is remembered”
as an important issue.
Not all memories
should be stored in the same place.
Qwen Code Official Docs Further Differentiate Several Instruction Types
The current memory docs mainly identify two long-term knowledge sources.
First:
QWEN.md.
Written by you.
Belongs to:
fixed instructions.
Second:
Auto-memory.
Automatically saved by Qwen during work,
capturing useful preferences,
feedback,
project context,
and references.
So today’s classification method
is beyond just organizing files.
It helps answer:
Which rules deserve long-term context?
For Fixed Rules, I Recommend Not Relying Solely on Auto-memory
For example:
“Production must not be modified directly.”
This is not a rule
the AI should just “hopefully remember” after chatting.
It’s a critical boundary.
Such rules are better suited:
explicitly written into:
QWEN.md.
Because official docs differentiate clearly.
Auto-memory is more like:
best-effort learning.
QWEN.md is read
every session as fixed instruction.
A Simple Additional Rule
If a phrase is:
“Good to remember.”
consider:
putting it into memory.
If a phrase is:
“Must always follow.”
consider:
writing it clearly as an
instruction.
Don’t leave a
safety rule
to the AI’s judgment of whether or not to remember it.
Example: Production Rule
Don’t just expect the AI to:
hear a rule once
and always remember it.
Instead, write clearly in the project QWEN.md:
production systems must not be modified automatically.
all deployments require manual approval.
These rules are:
short,
clear,
project-specific,
and very suitable as:
project instructions.
Don’t Let QWEN.md Become a 200-Page Company Manual
Qwen’s official guidance reminds us:
instructions should be:
short,
specific.
If your QWEN.md
gets longer and longer,
model adherence may:
decrease.
So don’t just shove everything in because:
“AI can remember.”
Not every README,
meeting note,
customer email,
or company wiki
should be stuffed inside.
Memory is not about:
more data is better.
It’s about:
making sure the rules you really rely on show up accurately next time you work.
A Good Project Rule Should Only Answer One Question
For example:
A bad rule:
“This project is important, be careful when modifying, we always value quality, and it’s best to review carefully before deployment.”
Too vague.
Better:
“Before modifying the database schema, generate a migration plan first; never run production migrations directly.”
The AI better understands:
when and what to do.
Another Common Problem: Old Rules That Are No Longer Valid
Suppose three months ago:
“This project uses Node 22.”
Now it’s upgraded to:
Node 24.
But memory
still contains the old info.
The agent may keep:
working according to the old environment.
So besides remembering,
you also need to:
forget.
Qwen Code itself provides:
/forget
to remove incorrect auto-memory.
Official instructions
should be updated directly in the related QWEN.md.
You Can Perform a Memory Review After Each Major Version Update
No need to do it daily.
For example:
framework upgrades,
deployment workflow changes,
database migration,
major folder restructuring,
or CI pipeline changes.
Afterwards, ask:
“Which AI instructions are now obsolete?”
Remove old rules.
This prevents AI from carrying outdated SOPs
across new versions.
Another Memory Detail: Worktrees May Have Their Own Scopes
Qwen Code’s official memory docs state:
Auto-memory is saved by project.
Branches checked out from the same checkout
share related memory;
linked Git worktrees
have their own memory folders.
The new daemon mode document introduces:
workspace-based project memory partitioning.
This means Qwen Code increasingly
refines boundaries between:
repositories,
workspaces,
and worktrees.
Regular users don’t need to set all this up
on day one,
but the concept is:
different AI workspaces should have different memory scopes.
First-Time Practical Step: No Complex Setup Needed
Open one real project.
Find three rules you always repeat to the AI.
For example:
“Use pnpm.”
“Run this specific test.”
“Don’t modify production directly.”
Then ask each:
Does this apply if I switch projects?
The First Rule Might Be
“Use pnpm.”
Assuming this is true across all your projects.
Put it:
User-wide.
The Second Rule
“Run feature tests for this repo before checkout.”
This test exists only in this repository.
Put it:
Project.
The Third Rule
“I temporarily use a debug shortcut locally.”
Only applies to:
you.
Only applies to:
this project.
Put it:
Project-local.
That’s it.
No Need to Add 50 Rules at Once
Start with:
3 to 5
rules that are truly frequent,
stable,
and impactful.
Use for a week.
See if the AI:
uses them in the correct project.
If yes:
slowly add more.
A Very Important Principle: Don’t Put Secrets Into Memory
API keys,
passwords,
tokens,
private keys.
Don’t put them into memory just because:
“AI might need it next time.”
Project instructions
should describe:
how to work,
not contain secrets directly as context.
Especially in project QWEN.md files that go into Git,
never casually put in credentials.
If You Only Remember One Thing From Today
It’s:
“Does this rule apply when switching projects?”
If yes:
Put it in user-wide scope.
If no:
leave it in the project.
Then ask:
Do other teammates need this?
If yes:
Project-shared.
If no:
Project-local.
This Method Applies Beyond Qwen Code
In the future, if you use:
Claude Code,
Codex,
Gemini CLI,
or any AI agent with long-term memory,
you’ll face the same issue.
The more AI
remembers across sessions,
the more important it is to know exactly:
where it should remember things.
Because truly safe AI memory
isn’t:
never forgetting.
It’s:
remembering in the right context and not carrying it over where it shouldn’t.
Today, let’s grow a little with AI.
Learn one AI skill every day.
Save a little time every day.
Improve a bit more every day.
SasaDaily, growing together with you.
