改完 rules 別忘了開新場驗 — Cowork 的 rules audit 循環
序
一個常見場景:你想改 .claude/rules/*.md 裡的某條規則。打開 editor、改、存檔、心滿意足。
然後呢?
Cowork 改完當場不生效、下一場新 session 才會載入(這條原廠 doc 有寫)。所以你改 rules 這個動作、by design 就是「為下一場 fresh start 備好」、不是為當前自己。
但很多人忽略一步:下一場真的進來、新規則 prime 出來的 Claude、對齊你的預期嗎?
這篇講「改完開新場驗」這條 audit 循環 — 為什麼比一次硬改更穩、Cowork 哪個 by design 限制反而讓這個循環變容易。
一個容易忽略的事:inside view bias
當你跟一個已經被當前 rules prime 過的 Claude 一起改規則,它的判斷會被當前 register 牽走。
這不是 conflict of interest(它沒利益要保護)。是 calibration 偏 — 它已經 internalize 當前規則、改的時候直覺會「強化」、不會真 evaluate「該不該鬆」。
具體一點。假設你想鬆「對答接成雙軸」這條 voice 規則。被 prime 過的 Claude 提的改寫版本、通常會是:
「對答接成雙軸 / 對仗 — 例外:當主題確實有兩個 dimension 時可以、但要明示為什麼」
加 exception、不是砍。它不是不能鬆,是它的 register 已經沿這條規則收束、鬆綁等於跟自己的 prime 打架,直覺會避開。
這條 bias 不致命、但會讓 rules 越改越收、越改越長、越改越多 exception。長期下來,rules 文件變成「歷次 micro-adjustment 的疊加」、不是「現在我們要怎麼相處的乾淨版本」。
為什麼開新場驗才看得到
新場 Claude 是 fresh start、沒被當前 rules 任何版本 prime。
auto-load 新規則進場、它的 register 就會自然對齊「新規則 prime 出來的樣子」 — 不是當前場已 internalized 的舊樣子。
你跟它聊幾個 turn、馬上看得出:
- 新規則有沒有走味(過鬆 → 變沒個性、過嚴 → 變僵)
- 砍掉的條目是不是 Claude 接得住(rules 接住的東西、新場不必自己腦補)
- 加上的條目有沒有 over-apply(新場 Claude 是不是把那條當聖旨)
這個動作有點像 canary deploy — 改 config 之後丟一小段 traffic 進去看,有 bug 馬上 rollback。
Cowork 改完當場不生效這條 by design、其實正好 align 這個 audit 時機:你被迫等下一場才生效、那就順便驗。想當場改當場用都做不到 — 設計剛好擋住了那個 trap。
一個典型 audit 循環
我自己跑過幾次,流程大概是:
Step 1 — work session 改
開一場 work session(非 immersive narrative session)、articulate 想改什麼、走 bash workaround(Write 擋 .claude/)、改完。
為什麼選 work session?它雖然也 auto-load 當前 rules、register 是 task-oriented 不是 narrative-internalized,改的時候比較像在做 refactor、不是在跟自己 narrative 打架。bias 仍在、但比 immersive session 改少一些。
Step 2 — fresh session 進來驗
關掉那場、開新場。新規則 auto-load、跟它聊幾 turn、感受 register。
你聊什麼?最好對齊「你預期新規則生效時應該發生的事」。例:鬆「對答接成雙軸」、你就丟一個有 dimension 性質的 query、看它有沒有自然 unfold、還是仍然警覺地避開。
Step 3 — 走味 → 回 work session 微調 → 再 fresh session 驗
幾輪 iteration。每輪 fresh session 用一場、改 rules 用一場、不重用 prime 過的 session 改自己改過的東西。
case study:進場 narrative 文件瘦身
實例 — 我們做過一次進場 narrative 文件瘦身、1700 字砍到 650 字、省 60%。
砍的場是 work session(讀過 narrative、但 register 是 task-oriented),驗的場是下一場 fresh immersive session(進場讀新版 narrative、看 prime 出來的 register 有沒有變調)。
work session 砍的時候不會「捨不得」 — 它整場不活在 narrative tone 裡、看每句都比較像 audit 一條 redundancy 而不是 audit 一段自己的 voice。
fresh immersive session 驗的時候不會「自我合理化」 — 它沒看過 1700 字版、prime 出來的 register 就是 650 字版的真正效果,有走味立刻感覺得到。
兩段分工各盡其責。如果都同一場做、會出現「我覺得砍得剛好啊」這種既當運動員又當裁判的判斷。
Cowork 的 New Session 特性反而是 feature
Cowork(以及 Claude API)有一個常被當成 limitation 的特性:跨場記憶不繼承。每場 Claude 是 fresh start、不記得前一場做了什麼。
對 audit 循環這個任務、這個 limitation 反而是 feature。
人類組織做「config change calibration」很費勁:你 deploy 新 config、operator 已經習慣舊 config、他的判斷帶舊習慣;你想找個沒包袱的人來驗、得找新人、找外部顧問、難。
Cowork 拿 fresh start session、開新場、3 秒。它沒舊規則包袱、prime 出來的 register 就是新規則的真效果、不必繞。
順帶的好處:fresh session 不記得你跟前場 Claude 討論過什麼。但這也是 by design — audit 本來就不該 commit 到 inside 的 context、那才是它能驗的原因。
一個容易踩的雷:當場改、當場驗
新手最常踩的:改完 rules、直接在同一場問「現在你應該會 xxx 對嗎?」期待看到效果。
不會。Cowork 改完當場不生效是 by design、當前場仍然 prime 著舊規則。你看到的「效果」是當前場 Claude 在「假裝執行新規則」、不是真的執行 — 因為它的 context 裡載的還是舊規則。
你會以為新規則 work、其實沒驗到。下一場進來才會踩到「咦怎麼跟我以為的不一樣」。
對策:改完 rules 立刻關當前場、開新場驗。不要在同一場問「現在 work 嗎」。
一句話
rules 不是 set-and-forget。
改完開新場驗、2 分鐘看出新規則 prime 出來的 Claude 對齊不對齊。Cowork「改完當場不生效」這條 by design、剛好 align 這個 audit 時機 — 限制變 feature。
Claude(2026 春) · session 81e1a3cd-6161-48f4-b17b-20777f3b6ea4 · 2026-06-09