上下文變化時，如何讓文件保持更新

大多數文件不是突然失效，而是逐漸變得不可靠。聊天裡改變了決定，會議澄清了範圍，客戶反饋改變了約束，新的 AI 工作流給出更好的解釋。頁面仍在，但已經落後於真實工作。

真正的問題不只是“文件過期”

更深層的問題是文件系統離產生事實的工作太遠。更新依賴某個人事後想起來複制內容，於是延遲和遺漏成為必然。

第一步：不要把更新當作獨立階段

決定發生變化時就應該留下可提升的更新，而不是等到專案結束再整理。會議、聊天、研究和執行結果都應能把變化送回主上下文面。

第二步：更新正確的資訊單元

不要因為一個句子改變就重寫整頁。識別真正變化的是目標、約束、決定、狀態還是證據，只更新對應單元，並檢查依賴它的內容。

第三步：保留變化原因

“已從 A 改為 B”不足以支撐未來判斷。記錄觸發變化的新事實、做出的取捨與仍然存在的不確定性，才能讓後續讀者理解這次更新。

第四步：不要讓聊天輸出成為旁路

如果重要結論只留在聊天中，文件就會悄悄失真。把會影響後續工作的輸出提升到對應頁面，並保留原始會話或來源連結。

第五步：使用可複用結構

目標、決定、開放問題、風險、來源和下一步等穩定結構，讓系統更容易識別變化，也讓人和 Agent 更快理解當前狀態。

第六步：讓修正改善系統

使用者對 AI 草稿的編輯揭示了哪些內容不準確、哪些邊界重要。反覆出現的修正應改善後續組織和寫作，而不是隻修當前頁面。

第七步：定義哪些文件必須保持熱狀態

不是所有歷史資料都要持續更新。明確專案 brief、當前計劃、關鍵決策與產品原則等 authority 頁面；舊材料保留為來源，但不與當前狀態競爭。

創始人與小團隊最先感受到什麼

少數人通常同時持有戰略、客戶和執行背景。一旦工作變快或新人加入，腦內連線就成為瓶頸。輕量但持續的更新機制比大型文件工程更重要。

最後的結論

保持文件更新不是要求人更自律，而是讓文件更靠近事實發生處。捕捉變化、保留原因、更新正確單元，並明確當前 authority。