代碼決策的死亡時間：錯過提交瞬間，記憶就永遠丟失

　　全球7000種編程語言，能解釋清楚"為什么"的代碼不到1%。

　　你遇到過這種場景嗎？一個緩存TTL被設成17分鐘，沒人知道原因。一段代碼被注釋"別碰——會崩"，但不寫為什么。你去翻提交記錄，只看到fix、update、wip。寫代碼的人已經離職。知識變成了謎團。

　　更糟的是文檔本身在撒謊。A頁面說用OAuth認證，B頁面說用JWT，相隔六個月，沒人標哪個已廢棄。你開始不信任任何文檔。沒有文檔，有時比有假文檔更好。

　　這不是紀律問題，是工具問題。寫文檔耗時、打斷心流、永遠排在優先級末尾。

　　我試過所有辦法，不是從零開始。最終診斷：這是時機問題，不是工具問題。

　　現有方案都讓你在之后補文檔——另一個時刻、另一個工具、另一層摩擦。但你真正記得"為什么"的瞬間，只有做決定的那一刻。錯過這個瞬間，什么工具都找不回來。

　　在提交時捕獲決策，否則永遠丟失。

　　如果捕獲不能和工作同步發生，它就不會發生。Git唯一可靠的心跳，就是commit。

　　于是我做了Lore。設計簡單到有點尷尬：

　　$ git commit -m "feat: add rate limiter to /api/login"[1/3] Type [feature]:[2/3] What [add rate limiter to /api/login]:[3/3] Why? Token bucket — sliding window was too memory-hungry at 5k req/s? Captured: feature-add-rate-limiter-to-api-login.md

　　前兩個提示從提交消息預填充，直接回車。第三個Why才是你真的要輸入的——那個真正重要的部分。

　　生成的文件是純Markdown，帶前置元數據，存在倉庫的.lore/docs/里：

　　---type: featuredate: 2026-02-14commit: a3f9c2e# feat: add rate limiter to /api/login## WhatAdd rate limiter to /api/login## WhyToken bucket — sliding window was too memory-hungry at 5k req/s

　　沒有平臺。沒有同步。沒有賬號。Markdown就在你的倉庫里，和代碼一起提交，用grep或lore show 就能搜索。

　　這是Lore自己.lore/docs/里的真實條目——捕獲決策，而不是捕獲人。