讓文件活著：三個提醒，單向流動

文件的變更和程式碼放進同一個 pull request，再加上三個提醒：程式碼變更時、每次 push、每個月。所有變更只往一個方向流動。

程式碼有 code review。那文件誰來核准？

我的答案很簡單。文件的變更，放進同一個 pull request。同一個 reviewer 一起核准。

三個提醒

三個提醒，都放在團隊本來就有的時間點上。

每月清理來自 Bullet Journal 的「遷移」。每個月，你把還沒完成的項目手抄到新的一頁。不值得抄的，就丟掉。

AI 在第一個提醒最有用。pull request 改了程式碼，AI 可以先起草文件的 diff，人再審。這正好解決先找痛點再選工具說的「跟程式碼不一致」。

第二個提醒，執行的是嚴格規則只給機器能檢查的裡的嚴格規則。

單向流動，就只有一個真相來源。

兩份內容不一致時，離程式碼越遠的那一份是錯的。

PRD 也一樣。PM 和 RD 討論後，我們團隊來寫 PRD。我們是 owner，所以它走同一個流程。如果以後 PM 自己寫 PRD，我們再調整。

提醒	起點
程式碼變更時	CI 步驟看變更的檔案。`app/x` 改了但 `docs/x` 沒改，就在 PR 上警告
每次 push	Markdown linter、連結檢查、欄位檢查，放進既有的 CI lint 步驟
每個月	CI 排程（GitHub Actions、GitLab CI、Jenkins），為「最後確認日期」太舊的文件開工單（Jira、Linear）
同步到 wiki	CI 步驟把 Markdown 發布到團隊 wiki，例如 Confluence 可用 `mark`

我只指出起點。工具的細節，你可以自己研究。

文件跟程式碼走同一扇門，就不會留在門外。

參考來源

延伸閱讀： 接著讀系列總結：把這些帶回你的團隊，回頭讀先找痛點再選工具，看看文件一開始是怎麼過期的。或回到系列總覽：AI 時代，文件怎麼活下來