結論

文章範圍的泛化（CLI → 工具設計）需要在五個位置同步調整，遺漏任一個都會讓文章的「說的」和「做的」不一致：title、開頭 hook、原則段措辭、對照表範例、結尾 checklist。

漂移軌跡

階段範圍觸發
初稿CLI 工具的 opinion從 ticket CLI 事件出發
R1 修法後CLI 工具，但原則段已泛化審查建議補遷移性
作者第一次回饋「不應該侷限於 CLI」作者指出核心觀點適用於所有工具
泛化修正所有工具設計調整 title / hook / 原則 / checklist / 對照表
作者第二次回饋語氣從指令式改為分享式title 中「你的 CLI 應該有 opinion」太喊話

教訓

案例具體、原則泛化是 work-log 的理想結構：用具體的 CLI 事件作為案例（讀者需要具體故事才能共鳴），但原則段和 checklist 不綁定在案例的技術棧上（讀者需要帶走可遷移的 takeaway）。

泛化時容易遺漏的是中間地帶——title 和 hook 已經泛化，但內文的某句話仍寫著「Opinionated CLI」或「列出你的 CLI 所有參數」。這類殘留在自己反覆讀時不容易發現（因為知道意思），但冷讀者會注意到 title 說「工具設計」而內文只講 CLI。

逐行 grep 原始範圍的關鍵詞（如 CLI、命令列）是最有效的殘留偵測方式。每處命中判斷：是案例引用（保留）還是原則陳述（改泛化）。

這個 pattern 適用於任何「把具體經驗提煉為通用原則」的寫作——技術 blog、內部 postmortem、教學文章。泛化的時機通常在第一輪回饋後，觸發點是讀者說「這不只適用於你的場景」。