前言：內部有文件，不等於公司看得到

我的 Obsidian Vault 裡有幾百份 Markdown，SOP、制度、技術筆記都在裡面。但這套知識有一個致命限制：它只在我的機器上。

同事要查工程 SOP，得開通訊軟體問我；主管要看制度草案，得等我截圖或轉貼。知識存在，但不可分配，就等於不存在。

這一篇記錄我把內部知識輸出成 Google Docs 的做法，以及一個代價不小的 403 教訓。

────────────────────

兩種產出並存，不要互相取代

我們的文件流程現在是雙軌：

關鍵原則是：Obsidian 仍是唯一原始資料層，Google Docs 是衍生輸出。若反過來，把 Docs 當編輯中心，Markdown 會失同步，最後變成兩套互相矛盾的知識庫——這正是我在知識庫分層上極力避免的失憶問題。

輸出時也保留來源連結與必要 metadata（owner、狀態、建立日期），讓讀者能回溯原始版本。

────────────────────

建立與讀回：不是送出就算成功

用 Agent 自動建立 Google Docs 時，我定義的完成標準不是「API 回傳成功」，而是三段驗證：

1. 建立：文件 ID 回傳。
2. 讀回：用 export 把文件內容抓回來，比對位元組數與關鍵句。
3. 一致：標題、正文與本機草稿一致，無亂碼。

export 的 bytes 確認特別重要。曾經遇過建立成功、但內容因編碼處理不當而出現亂碼的情況。若只看建立 API 的 200，就會把殘缺文件當成品交付。

繁體中文文件尤其要小心編碼。任何用 Latin-1 假設處理 UTF-8 字串的寫法，都會讓「設定」變成「設定」這種 mojibake。讀回抽查繁中字句，是我現在的固定步驟。

────────────────────

403 教訓：帳號邊界不能為了方便而跨越

這個教訓來自一次很自然的操作失誤。

我的個人帳號本來就登入著 Google 服務，公司文件產生時，指令預設用了當時可用的認證。結果請求直接被拒：403 Forbidden。

錯誤本身很清楚：公司 Google Drive／Docs／Sheets 必須用公司帳號。個人帳號既沒有權限，也不該有權限——資料隔離的意義就在這裡。私人資料不得流入公司空間，公司財務、客戶與工程資料更不能出現在個人帳號可見的地方。

修正方式不是想辦法讓個人帳號通過，而是把認證邊界明確化：

之後我在每個會碰 Google 的 cron 前都加了一段 preflight：先用輕量請求確認當前認證是公司帳號且有效，失敗先修復重測，仍失敗才回報阻塞。這讓「帳號用錯」從事後發現，變成事前攔截。

────────────────────

文件化也要有驗收標準

對外文件和內部筆記的差異，在於讀者不是作者本人。所以產出 Google Docs 時，我要求每份文件自帶：

• 標題與用途：一眼看出這是什麼、給誰看。
• 狀態標示：現況證據、建議制度、待核准，分別標明。
• owner：誰負責更新。
• 來源：回溯到 Obsidian 原始檔的連結。

讀者不需要知道整個知識庫結構，但必須知道這份文件多新、誰負責、算不算正式規定。

────────────────────

實際證據

目前公司制度類文件（工程 SOP、顧問決策 SOP、考核制度草案）都已產出對應的 Google Docs，建立後以 export 讀回驗證內容與位元組。認證面改用公司帳號專用的 gog CLI 設定，個人帳號與公司帳號的授權範圍完全分離，並在相關 cron 加入 preflight 檢查。

下一篇，我會從「文件與知識」轉向「讓系統自己動」：D15 談 cron 如何成為 Agent 的班表，把每天手動盯資料變成定時自動交付。