Communitygithub.com

HusDev/preferences-logger

在專案中維護一份活生生的 PREFERENCES.md,記錄使用者工作時所下的每個決策與偏好,讓後續對話與協作者都能遵循,無需重複提問。

preferences-logger 是什麼?

這個技能(Skill)會在專案根目錄建立或更新一份 `PREFERENCES.md` 檔案,即時捕捉使用者在開發過程中對產品、設計、技術、工作流程、寫作風格等方面所做的每個決定——無論是明確偏好、選項選擇、修正指示、變更決定或嘗試性方案。它的核心價值是解決 AI 助手常見的「遺忘問題」:同一專案的不同對話之間,經常重複問相同的問題,或默默推翻先前已確認的做法。透過記錄決定、變更與原因,並附上日期與修改記錄,這個檔案能跨對話、跨工具、跨協作者持續生效。支援的平台包括 Claude Code、Cursor、Codex 等任何能讀寫專案檔案的 AI 代理工具。使用方式很自然:助手從 `PREFERENCES.md` 開始閱讀,在使用者說出「我偏好」、「從現在開始」、「永遠」、「不要」、「讓我們用這個」等關鍵字時,於同一輪回應中寫入新決定或更新舊決定,並自動加入變更記錄。如果新請求與檔案記錄衝突,則以使用者最新的明確陳述為準。這個技能大大提升開發效率與決策一致性。

相容平台✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/HusDev/preferences-logger/tree/HEAD/skills/preferences-logger

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

偏好記錄器

人們在使用 AI 助手工作時,會做出數十個小決定:一個顏色、一個函式庫、一個命名規則、「不要做 X」、「選項 B」。但其中大部分都不曾被記錄下來,導致下一次對話時又得重新問一次,或者被悄悄地復原。這個技能維護一份 PREFERENCES.md 檔案,在每個決定做出的當下就記錄下來,使其能跨對話、跨工具、跨協作者持續生效。

何時行動

讀取:在開始對一個已有 PREFERENCES.md 的專案進行任何修改前,請先讀取它;在你的提案設計、選項或任何該檔案可能已涵蓋的內容之前,也要再次讀取。遵循檔案中的內容。除非使用者主動提起,否則不要對已記錄的事項再次提問。

寫入:在使用者進行以下行為時,在工作完成的同一輪回應中進行寫入:

  • 陳述偏好或規則(「我偏好 tab 縮排」、「永遠使用英式拼寫」、「永遠不要直接提交到 main 分支」);
  • 在你提供的選項中做出選擇(「A」、「選第二個」、「混合 A 和 C」);
  • 修正或否決某個做法(「這樣看起來很糟」、「不,把它放在右邊」、「錯了,只有在……時才這樣做」),只要修正內容說明了應該怎麼做;
  • 改變或推翻先前的決定;
  • 嘗試某個方案(「我們試試這個」):記錄並標註為「試驗中」。

不要記錄:

  • 僅適用於當前任務的一次性指示(「重新命名這個變數」);
  • 程式碼或版本歷史已經包含的事實(檔案結構、已安裝的函式庫);
  • 機密資訊、憑證、令牌,或任何人的個人資料(地址、身分證號碼、健康資訊)。記錄的是「決定」本身,而不是私人數值:例如「在頁尾使用使用者的真實姓名」,但絕不要記錄姓名本身(如果它是敏感資料);
  • 你自己提出但使用者未接受的建議。

如果你不確定某件事是否屬於長期決定,就先記錄下來:多寫一行簡短的說明,遠比遺忘一個選擇的代價要小得多。

檔案位置

PREFERENCES.md 位於專案根目錄,除非專案的代理程式指示檔(CLAUDE.md、AGENTS.md 等)指定了其他路徑。如果沒有專案(一次性對話),則不要建立檔案;只需遵循使用者的指示即可。

如果還沒有這個檔案,請從 templates/PREFERENCES.md(與此檔案相鄰)以第一條決定為基礎建立它。然後,如果專案中已有 CLAUDE.md 或 AGENTS.md,請在接近檔案頂端加入一行,讓未來所有對話都能讀取它:

請先讀取 PREFERENCES.md 並保持更新:每當做出或更改一個決定,請編輯其對應的行,並在相同回應中加入帶日期的變更記錄。

格式

# <專案名稱> — 決定

關於此檔案內容的簡短說明。

## <主題>
- **<決定的簡短名稱>:** 用簡潔的文字說明決定的內容。如果使用者說明了原因,也要記錄原因。(先前:被取代的舊決定及其日期。)

## 變更記錄
- 2026 年 10 月 17 日 — <決定或變更的摘要,簡短一行>(使用者原話:「…」)。

維持檔案實用性的規則:

  1. 每個決定一行,按主題分組。 挑選適合專案的主題(產品、設計、技術棧、工作流程、寫作風格……)。一開始只設少數主題,當某個決定不屬於任何現有主題時,再新增一個。
  2. 原地編輯。 當決定變更時,重新撰寫該行以反映目前的狀態,並將舊選擇以簡短的「先前:……」備註保留。絕不要留下兩條互相矛盾的記錄。
  3. 每次變更都新增變更記錄條目,最新的放在最下方,並使用絕對日期(「2026 年 10 月 17 日」,絕不要用「今天」或「昨天」)。寫入時請將相對日期轉換為絕對日期。
  4. 保留使用者自己的原話作為重要部分,引用且簡短:這有助於日後釐清原意。不要曲解或放大他們的語氣。
  5. 記錄原因(當使用者給出理由時)。有了原因,後續對話才能在規則未涵蓋的情況下做出正確判斷。
  6. 連結決定所指的對象: 一份設計稿、一個 Issue、一個線框圖、一個提交記錄。
  7. 標記試驗與未知狀態: 使用「(正在嘗試)」、「(尚未確定)」。當決定被確認後,移除這些標記。
  8. 寫得清楚明白。 使用簡短的句子,避免使用者沒用過的術語。除非使用者指定了人稱代詞,否則使用對方的名字或「他們」;不要從名字猜測。

當請求與檔案衝突時

最新的明確陳述為準。如果使用者現在要求做某件檔案中禁止的事,請按照他們的要求執行,並同時更新對應的行與變更記錄。如果不確定使用者是否真的想改變規則,請用一個簡短的問題提問,並引述檔案中的記錄。

簡短告知使用者

在你更新檔案後,請在回覆結尾用一個簡短的子句提一下(「我已將此記錄在 PREFERENCES.md 中」),而不是列出檔案的摘要。只有在使用者要求時,才顯示完整的檔案內容。

範例

使用者在你展示的三種側邊欄設計中選擇了「A,但按鈕應該用圖示」。在實作它的同一輪回應中:

## 設計
- **側邊欄:** 緊湊選單;資料夾列表填滿剩餘高度並可滾動;設定與隱私開關使用圖示按鈕,排列在底部一行(從三個選項中選擇 A,搭配圖示按鈕)。

## 變更記錄
- 2026 年 10 月 17 日 — 側邊欄:選項 A,底部操作改為圖示按鈕(使用者原話:「A,但按鈕應該用圖示」)。

一週後使用者說「把那些按鈕的標籤加回來」:

- **側邊欄:** …設定與隱私開關使用附有標籤的按鈕,排列在底部一行。(先前:僅圖示,2026 年 10 月 17 日。)

- 2026 年 10 月 24 日 — 側邊欄底部按鈕恢復標籤(使用者原話:「把那些按鈕的標籤加回來」)。

相關技能