長對話錨定與寫作規範
對話開頭説了用 PostgreSQL，聊到 30 輪 AI 突然建議 SQLite，因為早期約定已經被上下文窗口擠掉了。這一節講兩件事：怎麼對抗長對話的認知漂移，以及怎麼讓 AI 寫出的中文擺脱 AI 腔。兩個互動演示，動手拖一拖、點一點。
理解漂移成因
上下文窗口截斷和長文本尾部注意力衰減，讓 AI 忘掉早期約定。即使是 200K token 的模型，注意力在長文本尾部的衰減也真實存在。
會設 checkpoint
超過 10 輪後，關鍵操作前強制複述當前目標和關鍵約束，用週期性錨點對抗遺忘。
消滅 AI 腔
用可搜索的違禁模式清單和自查流程，替代「請寫自然流暢的中文」這類空話。
下面是一個模擬對話視窗，假設上下文窗口只裝得下最近 20 輪。第 1 輪定了「用 PostgreSQL」的硬約束，拖動滑塊增加對話輪數，觀察這條約定的命運。然後切換到「開啓錨定」，看同樣 30 輪之後有什麼區別。
灰色劃綫的消息表示已滑出上下文窗口，AI 看不見它們了。本演示假設窗口容量為最近 20 輪。
複述有固定格式
修改程式碼、修改配置、部署之前，AI 必須先回顧並複述當前目標和關鍵約束，格式固定，便於掃一眼確認。
目標以最新一次為準
用戶在對話中修改了目標時，複述要以最新一次為準，並明確標註變更，避免新舊目標混在一起。
並行編輯前先重讀文件
多個 SubAgent 或多次編輯涉及同一文件時，後續修改必須先重新讀取文件當前狀態，禁止基於緩存或記憶中的舊內容編輯。這是多 Agent 時代的「樂觀鎖」。
下面這段文案由 AI 生成，讀起來處處透着一股 AI 腔。點擊「開始檢測」，按 writing-style.mdc 的自查表逐條掃描違禁模式；再點擊每一處紅色高亮，查看它違反了哪條規則、應該怎麼改。
其一，「請用自然流暢的中文」沒有用。AI 認為的自然和你認為的自然可能完全不同，必須給出具體的違禁詞和違禁句式列表，AI 才能精確執行。交付前逐條搜索違禁模式，發現一處改一處，完成後註明已完成自查，System Prompt 裏的違禁句式同樣要改。
其二，寫作規範獨立成文件並設 alwaysApply: false，只在寫文案或 Prompt 時手動引用，避免污染編碼對話的上下文。
錨定對抗遺忘，清單對抗含糊。長對話裏靠週期性複述保住約定，寫作上靠可搜索的違禁模式保住風格。兩者的共同點是把模糊期望變成可執行動作。
素材來源：對應 rule-opensource.mdc 第十三章「溝通規範」與 writing-style.mdc，開源倉庫 itshen/xs_vibe_rules（MIT License）。