嚴格規則只給機器能檢查的
把團隊文件對照 Diátaxis 四種類型，現況和歷史分開放。只有工具檢查得了的，才當嚴格規則，其他都是大家的習慣與默契。
我們其實已經有文件類型，只是沒人這樣叫它。
Diátaxis 用兩個問題替文件分類：讀者是要動手做事，還是想搞懂原理？是第一次學，還是工作中查？拿我們自己的檔案走一遍：
把我們的檔案對照這四種類型，一看就清楚。
| 我們的檔案 | Diátaxis 類型 | 放在 | 讀者 |
|---|---|---|---|
| README Quick Start | tutorial：做中學 | repo | 工程師、AI agent |
| RUNBOOK | how-to：完成一件事 | repo | 工程師、AI agent |
| ARCHITECTURE | explanation：為什麼這樣做 | repo | 工程師、AI agent |
| ADR | 決策紀錄 | repo | 工程師、AI agent |
| API 文件（從程式碼產生） | reference：查事實 | repo | 所有人 |
| PRD / 總覽 | explanation | 團隊 wiki | PM 與業務角色、新進成員 |
現況和歷史，分開放
- 現況文件：README、ARCHITECTURE。只留最新版，直接改。今天必須是對的。
- 歷史文件：ADR、日誌。只新增。新的一筆取代舊的，舊的不改。
這對應記憶的兩種類型：「現在什麼是真的」和「什麼時候發生了什麼」。
規則分兩種：機器擋得住的，和只能靠人提醒的
第一種，機器檢查得了。每次 push 都跑 CI，文件不合格，build 就失敗，沒人能忘記。例如：必填欄位（owner、日期）存在、連結沒壞、檔案放在對的資料夾、Markdown 格式正確。
第二種，只有人看得出來。工具判斷不了寫得夠不夠細、是不是寫給對的讀者。這種只能大家同意，再由 reviewer 在 code review 時提醒。例如：要寫多細、寫給誰、用字白不白話、ADR 模板（Status、Date、Author，然後 Context → Decision → Consequences）。
沒人能檢查的規則，就沒人遵守。然後大家連其他規則都不信了。所以嚴格那一邊要短。
習慣也可以搬到嚴格那一邊，只要加一個工具。commit 格式 <type>: <title> (TICKET-123) 就是例子：加上 commit message 檢查，它就從習慣變成規則。這個檢查在哪裡跑，見讓文件活著：三個提醒，單向流動。
降低認知負擔
資深工程師都知道的習慣，不用寫進我們的文件。標準只連結一次，例如 Conventional Commits 和 ADR 模板。不要重寫。新進成員和 AI agent 會跟著連結走。
沒有 owner 和日期這類欄位，就沒人看得出文件已經過期。要選哪些欄位，交給團隊決定：owner、最後確認日期、狀態、讀者、工單編號（Jira、Linear）、tag、到期日。
機器能檢查的才叫規則，其他的叫默契。
參考來源
延伸閱讀： 看看名字怎麼承載意義，以及這些檢查在哪裡跑。或回到系列總覽：AI 時代，文件怎麼活下來