SOP：把不可見知識編碼進倉庫

當重要上下文還散落在 Google Docs、聊天記錄、ticket 或人的腦子裡時，就用這份 SOP。

目標

讓那些 agent 以前看不見的知識，變成 codebase 裡可發現、可讀取、可執行的事實。

觸發信號

• agent 總在追問系統到底怎麼運作。
• 人開始說“這個是 Slack 裡定過的”或“按某某上週說的做”。
• review 裡經常引用倉庫裡根本沒寫下來的產品、安全或架構規則。
• 新會話總在重複那些本該已經穩定下來的發現工作。

執行 SOP

1. 先列出所有不可見知識來源：外部文檔、聊天、默認團隊規則、口頭決策。
2. 對每條知識判斷：它屬於架構、產品行為、安全策略、可靠性要求、執行上下文，還是參考材料？
3. 按類別編碼到對應倉庫工件：
   • 架構 -> ARCHITECTURE.md
   • 產品行為 -> docs/product-specs/
   • 設計理由 -> docs/design-docs/
   • 執行狀態 -> docs/exec-plans/
   • 外部參考材料 -> docs/references/
   • 質量或可靠性要求 -> docs/QUALITY_SCORE.md 或 docs/RELIABILITY.md
4. 把模糊表達改寫成運行上真正有用的表達。
5. 刪除或廢棄舊副本，保證倉庫裡有一個可發現的真相來源。

好的編碼規則

• 為“可發現”而寫，不是為“寫得很全”而寫。
• 檔案儘量短，名字儘量明確。
• 相關工件要互相鏈接。
• 記錄耐久規則，不要把會議流水賬原封不動塞進來。
• 決策形成的同一輪會話裡，就把倉庫更新掉。

完成定義

• 一個全新 agent 不問人也能找到相關規則。
• 同一個事實不會散落在多個互相打架的檔案裡。
• 新工件放在離它所治理的代碼或流程最近的地方。