Generative AI 年會小聚分享

// 在臺下

聽了很多場
10 分鐘。

每一場都帶回很多點子
回家搞砸嘗試。

// 直到今天

現在，輪到我了

從自己經驗出發，但也是開放性的點子？

// 歹誌不是憨人想得那麼簡單...

兩個月前，我本來想講的是另一件事

PM 的日常是大量使用 Claude Code 處理數據——
查資料庫、跑分析、產報表。

當時想聊的是：怎麼把這些零散的數據，
透過 Discord 變成團隊都能一起用的資訊。

// 無奈

這兩個月，事情變了

1

工具更新速度極快

兩個月前想分享的 Skill 做法，現在可能已經是基本功了。

2

把事情做出來，門檻非常低

社群的開源性和多元性，讓執行本身不再是瓶頸

// 而且我發現

考驗我的，不是工具本身

而是過程中那些人為介入——
問對人、對齊脈絡、等回覆、再輸入給 AI...

我們正在嘗試的，是把這些人為介入降到最低。

怎麼降低？

大概是三個階段

STAGE 1

集中化

→

STAGE 2

基礎設施

→

STAGE 3

自動迭代

// 所以今天想分享

斑馬手冊

進化史

斑馬手冊進化史：從 Repo 到團隊的知識基礎設施

// 我的日常

很大一部分跟數據為伍

用 Claude Code 去查自家資料庫、產出報表、
找出哪些指標在動、哪些流程需要優化。

// 卡在哪？

做得出來，只是路徑繞了一圈

資料能撈到、數據沒有錯——
但有些更直線的做法，只有工程師的 know-how 才知道。

資料沒錯，但結構繞了一圈、效率打了折

還是得找工程師 review，才知道「原來有更聰明的做法」

斑馬手冊 1.0

讓 Claude Code 成為最懂公司的那個人。

📄 zeabur/zebra-manual private · 113 篇 SOP · 8 contributors

▶

業務邏輯、指標定義、schema 關聯、歷史算法變更

▶

跨部門踩雷經驗——踩一次，全公司都學到

▶

Claude Code 讀進記憶，問手冊就好，不用再問人

// 斑馬手冊 1.0

一個 GitHub Repo

// 運作方式

做任何專案前——
先讀手冊，再動工

1

團隊夥伴要啟動一個專案（分析、開發、客服⋯⋯）

2

先讓 Claude Code 讀斑馬手冊——資料庫結構、API 定義、業務邏輯

3

再進入實際執行——每個人用法不同，但起點一致

先讀過 KB 再動工——一次成功率明顯提升。

// 但我們發現

1.0 只是業務知識的一部分

手動寫進 GitHub 的，只是通用業務知識。

還有更多來源沒被納入——
Changelog、Docs、論壇工單回覆，
甚至 Agent 自己迭代出來的 Skill 與回覆。

// stage 2

斑馬 2.0

// 改變一 · 來源擴充

知識來源：從 1 個變成 6 個

不只是人為輸入——還包括 Agent 自己迭代出來的 Skill、回覆，
以及原本就有的 Docs、Changelog、論壇工單。

2521

Docs

2511

Forum

915

Blog

567

Changelog

210

Skills

27

Learned

Total: 6,751 Knowledge Chunks

// 新的問題

來源變多了，但有沒有更好操作或循環的方式

人眼難掃、介面也不友善。

有什麼？

沒有目錄、沒有標籤、沒有視覺化——只能一篇篇翻。

// 改變二 · 可視化介面

RAG service 可視化

// 改變三 · 共享基礎設施

誰都能接入

知識庫變成團隊的共享基礎設施，不只給一個工具用。

API

任何內部工具都能透過 API 查詢知識庫

CC

Claude Code

開發者、PM 在 Claude Code 裡直接查詢團隊知識

AG

Zeabur Agent

客服 Agent 自動檢索知識庫，起草回覆

UI

Web UI

非技術人員也能在瀏覽器裡搜尋

// 多一層把關

Agent 學到的知識，由人決定要不要用

每一筆新知識進來，都要經過驗證才能進入下一輪循環。

未驗證

3

Agent 自動學到的新知識，等待審核。

已驗證

26

確認品質 OK，進入下一輪循環素材。

已拒絕

1

品質不夠，不進入循環。

已驗證 · 進入循環

// 但還是

光靠人維護，還是不夠

驗證靠人工

素材好壞還是得人點進去判斷，規模一大就追不上。

// stage 3

The Loop

讓基礎設施自己進化

// 實際案例

比如說——

Skills

這版 Skill 跟上版，誰更好？

Skill 可以拆成幾個面向去量化，
每次調整都能衡量效果。

有量化的數據，就知道每次改得更好還是更差。
有持續的探索，這件事就不會停。

// THE LOOP

自我進化循環

人（團隊）

編輯 program.md：「本週聚焦 marketplace 相關文件」

↓

AI（每週一自動執行）

1

讀 program.md

→

2

跑 evaluate.sh
取得 baseline 分數

→

3

選最低分維度
執行改進

→

4

開 PR
附 before/after 分數

↓

Merge = 保留 ✓

自動跑 health-report，更新 HEALTH.md，進入下一輪。

Close = 丟棄 ✗

AI 從失敗中學習，下一輪換策略。

以上，都是工程師在搞

// 換個玩法

自己雜亂的知識庫，
有沒有自我迭代的辦法？

做了一個最小 MVP。

// 地利之便

省下 0 到 1 的時間

同樣的 RAG 架構、同樣的後台，一鍵部署到自己的環境，剩下時間花在迭代知識本身。

But

有些前置，得先討論清楚

如果是知識盲區，怎麼知道——

一篇新知識，值不值得存？

// 先嘗試的作法

冷啟動

系統要按知識量自動升級嚴格度。

// 累積期

< 50 筆

寬進，全部自動 verify

只過濾垃圾來源與太短內容，把量先衝起來。

// 之後預計

資料累積一定量後

// 01

提取問題

AI 從新文章抽 3 個「這篇應該能答的問題」。

// 02

記 Before

拿這 3 題問現有知識庫，記錄分數。

// 03

存入文章

把這篇文章寫入知識庫。

// 04

記 After

再問一次同樣的 3 題，記錄新分數。

// 05

決定去留

After > Before → 保留；否則刪除。

// 順手就丟一條

讓資訊的來去，都在我本來的習慣動線上

滑手機看到好東西，丟到平常就在用的 Discord 頻道——剩下交給 rag-bot。

// 個人 RAG

我的基礎設施正在迭代，期待會變成什麼樣子

// 收尾

Takeaway

// 現今

技術迭代

// 更有趣

形塑的方式

最聰明 vs. 夠可控

// one more thing

模板開源免費

一鍵部署你自己的 RAG 知識庫——同樣的架構、同樣的後台。

→ zeabur.com/templates/H126IM

// shout-out

開發工程師也有來到現場

歡迎會後一起交流。

讓知識自己長大。

反正歪了再改，哪次不迭代啦

Vita Chen

PM @ Zeabur

聽了很多場10 分鐘。