RCF-020 — 品牌分析 SKILL Step 4-4 新增 analyses/ 同步（SYS-08 知識庫網站可見性）
類型：SKILL + 系統架構 日期：2026-04-28 觸發條件：條件 4 — 修改現有 SKILL 的核心執行步驟（Step 4 必做項目新增 Step 4-4） 相關文件：
.claude/skills/品牌分析.md（Step 4-4 新增）CLAUDE.mdSKILL 表格描述更新（品牌分析行）knowledge/brand-benchmarks/README.md管理規則新增雙存檔架構說明knowledge/analyses/README.md索引表新增「類型」欄knowledge/CLAUDE.md文件索引 +1 行（analyses/ 新條目）knowledge/improvements.md（IMP-069 觸發案例）
問題背景
Session 60 收尾時 Tim 提出：「品牌分析完成不是應該要把完整結果進入知識庫嗎？我在知識庫內沒看到。」
實際缺口：
- 品牌分析存檔位置 =
knowledge/brand-benchmarks/（tzlth-hq repo） - SYS-08 知識庫網站讀取範圍 =
knowledge/references/*.md（5 大分類）+knowledge/analyses/*.md（學習分析 tab，2026-04-27 新增） brand-benchmarks/不在 SYS-08 讀取範圍內 → Tim 在網站上看不到分析references/社群行銷.md雖有 condensed entry，但只是濃縮摘要，無 Section 八/九完整分析
Tim 後續澄清：「知識庫內的學習分析這區塊，是針對我在對話提供的連結去做學習分析，而將分析後的結果完整的進入知識庫這個區塊。在品牌分析應該也要這樣，將完整內容都要在知識庫中。才能達成你可以再利用學習，我也能完整觀看學習。」
→ 設計需求：完整內容（非摘要）必須出現在 SYS-08 可見的位置。
考慮過的方案
| 方案 | 描述 | 優點 | 缺點 | 採用？ |
|---|---|---|---|---|
| 方案 A | SYS-08 新增獨立「品牌標竿」tab：lib/knowledge.ts 新增 brand-benchmarks category，讀取 brand-benchmarks/*.md | 最完整，獨立分類；視覺上品牌標竿 vs 學習分析清楚分離 | 需改 SYS-08 程式碼 + build + deploy；brand-benchmarks 格式與 references 格式不同需新增解析邏輯；後續維護成本高 | ❌ |
| 方案 B | 在 references/社群行銷.md 補入完整分析內文 | 不用建新檔；既有分類 | references/ 是 condensed entry 格式，塞 400 行全文破壞既有結構；社群行銷分類混入品牌標竿造成定位模糊 | ❌ |
| 方案 C-α（採用） | analyses/ 標準標頭 + brand-benchmarks 全文 1:1 複製 | 立即可見（analyses tab 已 2026-04-27 上線無需 SYS-08 改動）；維護簡單（更新主檔再覆寫副本）；命名標籤 類型: brand-benchmark 為未來 SYS-08 子分類預留 |
brand-benchmarks/ + analyses/ 雙存儲，需明確「主從關係」避免內容漂移 | ✅ |
| 方案 C-β | analyses/ 寫獨立「網站閱讀版」（重新組織內容） | 可優化網站閱讀體驗 | 兩份各自寫；維護成本翻倍；回訪時可能漏更新一份 | ❌ |
最終決策
採方案 C-α：
Step 4-4：同步至 knowledge/analyses/（SYS-08 知識庫網站可見性）
→ 建立 knowledge/analyses/YYYY-MM-DD-brand-[帳號]-[platforms].md
- 命名：對齊既有 5 段式 YYYY-MM-DD-[type]-[author]-[topic]
- type 用 `brand`、topic 用涵蓋平台（如 `ig-threads`）
→ 設計：analyses 標準標頭（含 `類型: brand-benchmark` 標籤）+ brand-benchmarks/[帳號]-YYYY-MM-DD.md 全文 1:1 複製
→ 標頭必含「主檔」引用：knowledge/brand-benchmarks/[帳號]-YYYY-MM-DD.md
→ 更新 analyses/README.md 索引表 +1 行（類型欄填 brand-benchmark）
→ 回訪模式：在 analyses/ 建立新日期檔案；既有條目保留作歷史
排除方案 A 的核心原因：當前需求可在不改 SYS-08 的情況下解決（analyses tab 已存在）；新增獨立 tab 需要程式碼變更和持續維護，效益不顯著（學習分析 + 品牌標竿同 tab 共存可接受）。 排除方案 B 的核心原因：references/ 與 analyses/ 是不同層級的內容，混入會破壞既有架構。 排除方案 C-β 的核心原因：維護成本翻倍且容易漂移。1:1 複製是最簡單的同步機制。
主從關係定義：
- brand-benchmarks/ = 主檔（回訪時更新位置）
- analyses/ = 副本（從主檔同步而來，不獨立修改）
影響範圍
| 影響類型 | 具體項目 |
|---|---|
| 新增文件 | knowledge/analyses/2026-04-28-brand-betweengos-ig-threads.md（首次套用 Step 4-4） |
| 修改文件 | .claude/skills/品牌分析.md（Step 4-4 新增）/ CLAUDE.md（SKILL 表描述更新）/ knowledge/brand-benchmarks/README.md（管理規則 +1 條雙存檔架構）/ knowledge/analyses/README.md（標頭升規 + 索引表新增「類型」欄 + 既有條目補類型欄位）/ knowledge/CLAUDE.md 文件索引 +1 |
| 觸發部門同步 | 無（SKILL 修改 + 知識庫文件修改，不觸發 12 部門同步） |
| 影響的 SKILL | 品牌分析 SKILL |
| 影響的系統 | SYS-08（知識庫網站，不需 redeploy，push 即生效） |
驗證方式
立即驗證（執行後）：
- https://tzlth-knowledge-base.vercel.app/analyses 出現 betweengos 條目
- 點擊條目能讀到完整 Section 一到九內容
- 索引頁類型欄顯示「brand-benchmark」
下次品牌分析時驗證：
- 新帳號分析（首次）→ 自動執行 Step 4-1（brand-benchmarks/）+ Step 4-4（analyses/）
- 分析存兩份 = 雙存檔架構落地
下次回訪時驗證（首例：betweengos 2026-07-28）：
- 主檔（brand-benchmarks/）更新後，副本（analyses/）建立新日期檔案
- 既有 analyses/ 條目保留作歷史，不刪除
設計思考紀錄（為未來決策保留）
為什麼 analyses/ 而不是新 tab？ analyses/ 是 2026-04-27 才建立的彈性分類（學習分析 + 品牌標竿混存）。當前條目數 < 10，UI 上混存可接受；未來若條目 > 30 條再考慮二級分類（IMP-069 已記錄此擴展風險）。
為什麼 1:1 複製而非引用連結？ SYS-08 是 Next.js + GitHub API 即時讀取，能讀的範圍受 lib/knowledge.ts 配置限制。讓 SYS-08 跨資料夾讀「主檔在他處」的引用機制需要程式碼改動，違背「立即可見、不改 SYS-08」的設計目標。1:1 複製最簡單。
為什麼加 類型: brand-benchmark 標籤？
未來條目累積到 30+ 時，SYS-08 可在 lib/knowledge.ts 加子分類邏輯，依此標籤分流到不同子 tab。現在預留標籤 = 未來重構時不需逐條回填。