RCF-007 — 知識資產類別矩陣 + 混合架構三層冗餘

類型：規則變更（新增類別分類規則 + 架構升級）日期：2026-04-24 觸發條件：

條件 1：新增或修改 HARD STOP 規則區塊（類別分類為 HARD STOP 級規則）
條件 5：影響 2+ 個技術系統的架構決策（Google Drive + GitHub repo + 本機離線備份 + NotebookLM 來源配置）

相關文件：

knowledge/classification-matrix.md（本次新建 — 14 類別 × 5 使用層矩陣）
knowledge/architecture.md（本次更新 — 混合架構三層冗餘 + 封號風險章節）
knowledge/operations/quarterly-offline-backup-sop.md（本次新建）
knowledge/product/assets.md（本次更新 — 3 份電子書補登 + 方案 C 贈品規則）
product/service-catalogue.md（本次更新 — 電子書名稱統一）
strategy/weekly-schedule.md（本次更新 — 每季新增 30 分鐘備份任務）
dev/tasks.md（本次更新 — 7 項 Tim 操作待辦新增）

問題背景

2026-04-24 Session 16-18 對話連續追問揭露 3 個核心架構缺陷：

缺陷 1：知識庫同步脫鉤

methodology/ 文件更新後，NotebookLM 無機制得知，導致 AI 助理回應基於舊資料。前置任務 RCF（Session 16 knowledge/architecture.md）已處理 NotebookLM 手動刷新 SOP，但未處理更根本的「主檔案庫」問題。

缺陷 2：Tim 看不到自己的文件歸檔

「我所有的文件內容歸檔在哪？只有你看得到，但我看不到」

根本問題：

Claude 可讀 GitHub repo 的 .md
Tim 可看本機資料夾與 Google Docs
但兩者無統一主庫，Tim 無法在一個地方看到「所有產品 + 電子書 + 模板 + 方法論」
電子書存在官網資料夾、模板在 Google Docs、方法論在 repo — 分散無統一視圖

缺陷 3：產品資產未按「類別」規則化

現況按「產品」分（S4 / S6 / D1），每次新增產品都要重新討論「這個該不該放入某 Notebook」。

Tim 提出戰略洞察：

「我們是不是應該思考用類別，例如說，模板類的開放給哪些客戶、問卷類的給哪些客戶、說明書的給哪些客戶，這樣未來新增才有依據，才不會每次都重新討論或是搞混」

缺陷 4：Google Drive 單點失效風險

Session 17 推薦 Google Drive 作主庫後，Tim 追問「被封的原因會是什麼？我們有可能觸犯嗎？」— WebSearch 揭露 Google ToS 8 類封鎖原因，Tim 實質風險雖 < 1%/年但仍需冗餘備份。

考慮過的方案

方案	描述	優點	缺點	採用？
A. 按「產品」分 Notebook（現況）	每次新產品重新討論放哪個 Notebook	無需預設架構	新產品重複討論；規則不一致；類別擴展無標準	❌
B. 按「類別」分 + 單一 Google Drive	14 類別 × 5 使用層矩陣；Google Drive 唯一主庫	規則化新增產品直接查表	單點失效風險高（帳號封鎖 = 全失效）	❌
C（採用）：類別矩陣 + 混合架構三層冗餘	14 類別 × 5 使用層 + 5 灰色地帶規則；Google Drive 主庫 + GitHub 次備 + 季度離線備份	規則化 + 單點失效補救 + Tim 可視 + NotebookLM 整合	首次建立需 Tim 操作 Google Drive 資料夾（30 分鐘）+ 季度 30 分鐘備份	✅
D. 按類別 + Notion 為主庫	資料庫功能強	NotebookLM 無原生整合；付費；匯出不完整	❌
E. 按類別 + Obsidian 本機	零封號風險	Tim 學習成本高；跨裝置需額外同步；無原生 AI 問答	❌

最終決策

採用方案 C。核心設計：

設計 1：14 類別 × 5 使用層權限矩陣

類別（14）：方法論 / 說明書 / 問卷 / 報告模板 / 交付模板 / Tim 內部模板 / 話術 / 簡報 / 提案書 / 電子書（免費）/ 電子書（付費）/ 審查報告 / 改善觀察 / 歷史決策

使用層（5）：Notebook A（Tim 內部）/ B（公開）/ C（S6 付費）/ D（D1 買家）/ 知識庫網站（公開）

判斷原則：商業機密預設不公開；方法論可公開；付費交付對應付費客戶；混合型以主要用途分類。

設計 2：5 個灰色地帶處理規則

規則 1：混合型文件以主要用途分類，次要用連結引用
規則 2：新形式類別先歸「參考資料」暫存，累積 3+ 升為獨立類別
規則 3：版本管理主資料夾只放最新，舊版移 _archive/
規則 4：跨類別共享一個主檔案 + 其他類別連結引用
規則 5：類別矩陣升級透過 RCF 觸發，不允許臨時添加

設計 3：混合架構三層冗餘

Layer 1：Google Drive「職涯停看聽_總倉儲」（Tim 主視圖 + NotebookLM 原生整合）
Layer 2：GitHub repo knowledge/（Claude 操作層 + 版本歷史）
Layer 3：季度離線備份（Google Takeout → 本機 + 外接硬碟 BitLocker）

恢復情境：任一層失效，其他兩層仍可完整還原。

設計 4：電子書贈品方案 C（混合）

S6 客戶贈送（感知提升 / 成本佔比低）
D1 買家不贈送（NT$199 佔 D1 25% 過重）
保留電子書獨立銷售通路

影響範圍

影響類型	具體項目
新增文件	`classification-matrix.md` / `quarterly-offline-backup-sop.md` / 本 RCF
修改文件	`architecture.md`（混合架構 + 封號風險）/ `product/assets.md`（電子書補登 + 贈品規則）/ `service-catalogue.md`（電子書名稱）/ `weekly-schedule.md`（每季 30 分鐘）/ `tasks.md`（7 項 Tim 待辦）
觸發部門同步	knowledge/CLAUDE.md（文件索引）/ strategy/CLAUDE.md（最近修改）/ decisions/README.md（RCF-007 登記）
影響的 SKILL	無（SKILL 執行時自動套用類別矩陣判斷）
Tim 需操作	Google Drive 建立資料夾 + 上傳 + NotebookLM A 擴充選源 + Notebook C/D 建立框架 + 兩步驟驗證（累計約 2 小時）

驗證方式

下次 Tim 新增任何產品資產時：Claude 應能直接查 classification-matrix.md 表格決定「放哪個類別 + 哪些 Notebook 可用」，無需 Tim 重新討論
下次 Google 帳號異常時：Layer 2 + Layer 3 確保資料可還原，檢驗三層冗餘是否有效
reflection-log 觀察 4 週：過去「新產品放哪」的重複討論次數應降為 0（類別矩陣已規則化）
Tim 季度備份執行率：weekly-schedule 已登記，observable from 日誌