讓工具去問問題，不要讓它寫文章
從 commit 生成日誌這件事我試了，結果是一坨流水帳。改成讓工具生成「該問的問題」。
AbstractAuto-generating posts from commits produced filler. The tool now generates recall questions instead, and the writing happens in a Q&A pass.
那時候在想什麼
原本的想法是寫一支程式讀 git log，自動生出日誌草稿。commit 訊息、變動檔案、時間區間都在那裡，拼一拼應該就能成篇。
實際做了什麼
拿 super-reversi 跑第一版。輸出大概長這樣：
這段時間修改了
src/main-complete.ts、src/i18n.ts、src/style.css等檔案，新增了多語系支援，並改善了響應式版面。
這句話沒有錯，可是它沒有任何價值。任何人打開 GitHub 都能得到同一句。
問題出在資訊來源本身。那個 repo 六十二個 commit 裡有十八個訊息是 add 或 fix。真正有內容的地方在別的地方：
#17 codex/fix-blurred-rectangle-for-multi-piece-flip |
PR 的分支名比 commit 訊息誠實得多。還有一個 commit 寫著 移除光束，那一行比前面五十個 fix 加起來都有資訊量，因為它記錄了一個決定。
試過但沒留下
第二版試著讓工具把這些線索組成敘事。偵測到大量刪除就寫「進行了重構」，偵測到新目錄就寫「引入了新模組」。
結果更糟。這種句子讀起來像真的，可是它在猜。「引入了新模組」聽起來很合理，但當時為什麼引入？工具不知道，而它寫出來的句子會讓人以為它知道。編出來的因果比留白危險。
結論
工具的產物改成兩塊，一塊是事實，一塊是問題。
事實那塊照抄不加工：檔案熱點、改最多次的檔案、PR 分支名、完整 commit 清單。問題那塊依訊號生成，看到 revert 就問「是踩到什麼還是想法變了」，看到「移除」就問「當初為什麼做、後來為什麼決定不要」，看到超過四成訊息是 add 或 fix 就直接標注「這篇幾乎沒東西可以從 log 撈，整段靠回憶」。
跑 super-reversi 的第二片，問出來的是這些：
- 有 1 次大量刪除，最多一次 −2820 行，拿掉的是什麼
- 新開了
src/i18n、src/workers、public、tests/unit，當時是想解決什麼 - 之前一直在動的
memory、scripts、src/view這次完全沒碰，是刻意先擱著還是已經定案 src/main-complete.ts被改了 20 次，是需求還沒定還是做法沒找到
這些問題我答得出來，而答案就是文章。
標進行中是因為提問規則還在調。第一版把「新開了根目錄」當成訊號，那是純雜訊，根目錄的檔案不是一塊區域。第一個切片問「新開了什麼」也沒有意義，因為那裡所有東西都是新的。這種規則要跑過幾個真的 repo 才會收斂。