部門 AI 工具導入專案
目標：在 Matt 筆電部署部門級 AI 工具生態系（Telegram bot + 部門知識庫），提升團隊整體效率 發起人：Matt + Enoch 技術基礎：已驗證於個人環境——Telegram bot 多人版、zettelkasten 知識管理 部署方式：本機（Matt 筆電）——使用現有 Telegram bot + Claude Max 訂閱，零額外成本
一、系統架構
部署拓撲
┌─────────────────────────────────────────────────┐
│ Matt 筆電（Arch Linux） │
│ │
│ ┌──────────────┐ ┌────────────────────────┐ │
│ │ Telegram Bot │───▶│ Claude Code CLI │ │
│ │ (Bun runtime) │ │ (Claude Max, OAuth) │ │
│ │ systemd svc │ └──────────┬─────────────┘ │
│ └──────────────┘ │ │
│ ┌────────────▼─────────────┐ │
│ ┌──────────────┐ │ ~/team-zettelkasten/ │ │
│ │ 個人環境 │ │ 部門知識庫 + Skills 子集 │ │
│ │ ~/zettelkasten│ └──────────────────────────┘ │
│ └──────────────┘ │
│ ┌──────────────────────────┐ │
│ │ ~/team-workspace/ │ │
│ │ Lung-Teng repos (git) │ │
│ └──────────────────────────┘ │
└─────────────────────────────────────────────────┘
▲ ▲
│ Telegram API │ Anthropic API
▼ ▼
┌─────────┐ ┌──────────┐
│ 部門成員 │ │ Claude │
│ 手機/電腦│ │ (Max) │
└─────────┘ └──────────┘
目錄結構
| 路徑 | 用途 | 說明 |
|---|---|---|
~/team-zettelkasten/ | 部門知識庫 | 獨立 git repo，部門版 CLAUDE.md + skills + templates |
~/team-workspace/ | Lung-Teng repos | Clone 全 11 repos，Sprint 自動化用 |
~/zettelkasten/ | 個人知識庫 | 不動，完全隔離 |
~/Documents/telegram-claude-bot/ | Bot 程式 | 現有 bot，修改 team 角色 cwd |
為什麼不用 GCP VM
- Anthropic 使用條款：Max 訂閱僅限「ordinary, individual usage」，不可在 VM 上跑 OAuth 登入
- VM 上跑需要 API Key（按 token 計費），成本不可預測
- 本機已有 Telegram bot（systemd service），直接複用零成本
- 先導期驗證後，若需要 24/7 高可用再評估 GCP + API Key 方案
二、部門 Zettelkasten 設計
與個人版的差異
| 面向 | 個人版（Matt） | 部門版 |
|---|---|---|
5-self/ | 有（自我認識系統） | 無 |
1-fleeting/ | 個人靈感 | 團隊快速筆記 |
| 知識內容 | 全領域 | 聚焦部門業務 |
| 存取方式 | 本地 Obsidian + Claude Code | Telegram bot |
| 寫入權限 | 只有 Matt | 依角色分級 |
| 標籤系統 | 含 self/、area/、outcome/ 等個人向 | 精簡為團隊核心 tag |
| 說明筆記 | 7 篇方法論筆記 | 1 篇快速上手指南 |
資料夾結構
department-zettelkasten/
├── 0-inbox/ # Telegram 進來的快速記錄
├── 2-literature/ # 技術文獻、課程筆記（團隊共享）
├── 3-permanent/ # 核心知識庫（技術決策、架構文件、SOP）
├── 4-project/ # 專案追蹤（WriteAhead、OJT 等）
├── meetings/ # 會議紀錄（live-listen 產出）
├── templates/ # 筆記模板
├── CLAUDE.md # 部門版系統指引
└── 團隊知識庫快速上手.md # 唯一的說明文件
知識庫內容來源
| 來源 | 如何進入知識庫 |
|---|---|
| 會議紀錄 | 手動整理或 AI 輔助摘要存入 meetings/ |
| 專案決策 | Sprint 過程中的技術決策、架構變更記錄 |
| 技術筆記 | 團隊成員透過 Telegram 丟入，或 skill 產出 |
| 課程學習 | /udemy-notes、/youtube-notes 產出 |
| 外部文件 | SA 文件分析、需求文件整理 |
部門版 CLAUDE.md 草稿
Phase A 建置時從此草稿產出正式版
# 部門知識管理系統
基於 Zettelkasten 方法的團隊知識管理系統。
成員透過 Telegram bot 存取，AI 自動整理、連結、維護知識品質。
## 資料夾結構
| 資料夾 | 用途 | 寫入時機 |
|--------|------|----------|
| `0-inbox/` | 快速記錄 | Telegram 傳入的片段、待整理素材 |
| `2-literature/` | 文獻筆記 | 課程、文章、影片摘要 |
| `3-permanent/` | 核心知識 | 成熟、可信賴的技術知識與 SOP |
| `4-project/` | 專案追蹤 | 進行中的專案規劃與紀錄 |
| `meetings/` | 會議紀錄 | live-listen 產出或手動整理 |
| `templates/` | 模板 | 筆記模板 |
## 筆記格式
### Frontmatter 必要欄位
---
id: YYYYMMDDHHmm
title: "筆記標題"
created: YYYY-MM-DD
author: "貢獻者姓名"
tags: [topic/主題, status/狀態]
---
### 連結格式
- 內部連結：筆記標題
- 帶別名：顯示文字
- 新筆記至少連結一篇既有筆記（避免孤島）
## 標籤系統
| 前綴 | 用途 | 範例 |
|------|------|------|
| `topic/` | 技術主題 | `topic/vue`, `topic/nuxt`, `topic/cicd` |
| `status/` | 筆記成熟度 | `status/unreviewed`, `status/seedling`, `status/evergreen` |
| `type/` | 筆記類型 | `type/moc`, `type/how-to`, `type/meeting`, `type/decision`, `type/sop` |
| `source/` | 來源類型 | `source/book`, `source/video`, `source/course` |
| `project/` | 所屬專案 | `project/writeahead`, `project/ojt` |
### 狀態流程
- `unreviewed`：AI 或成員新建，尚未被團隊確認
- `seedling`：已確認正確，內容尚可補充
- `evergreen`：成熟可信賴，可作為 SOP 或參考依據
### 狀態規則
- 新建筆記一律 `status/unreviewed`
- 重大修改改回 `status/unreviewed`
- 由知識庫管理員（admin 角色）review 後升級狀態
## Telegram 訊息處理
| 訊息特徵 | 處理方式 |
|---------|---------|
| 技術問題 | 搜尋知識庫回答，附上來源筆記連結 |
| 知識分享（「我發現...」「這個技巧...」） | 整理成筆記存入對應資料夾 |
| 專案相關（「SCRUM-xxx...」） | 觸發對應 skill 或更新專案筆記 |
| 會議相關（「上次開會...」「action items」） | 搜尋 meetings/ 回答 |
| Sprint 操作 | 執行 /sprint-analyze 等 skill |
## 知識品質規則
1. **原子化**：一篇筆記一個概念，不混搭
2. **有連結**：新筆記必須連結至少一篇既有筆記
3. **有來源**：文獻筆記標註 source，技術筆記標註 author
4. **可搜尋**：標題用中文，清楚描述內容（不用編號或代碼）
## 會議紀錄格式
live-listen 產出或手動整理的會議紀錄統一存入 `meetings/`：
- 檔名：`YYYY-MM-DD 會議名稱.md`
- 內容：出席者、逐字稿摘要、決策事項、action items、待確認事項
- action items 格式：`- [ ] @負責人 事項內容（截止日）`
## 遊戲化互動
### 每日知識推薦（每天早上自動推送）
從知識庫中挑一篇筆記推送給所有成員——「今日知識：xxx」
選擇邏輯：優先推最近更新的、與當前 Sprint 相關的、或較少被查閱的。
### 週報（每週一自動推送）
個人統計：本週查詢次數、貢獻筆記數
團隊統計：知識庫新增筆記數、最活躍貢獻者、本週最多人查閱的筆記
### 里程碑（達成時通知）
- 🎯 首次使用 bot
- 📝 首次貢獻知識
- 🔥 連續五天使用
- 📚 知識庫第 50/100/200 篇筆記部門版標籤系統對照
| 個人版 | 部門版 | 說明 |
|---|---|---|
topic/ | topic/ ✅ 保留 | 核心分類，不變 |
status/ | status/ ✅ 保留 | 精簡為三級（去掉 budding） |
type/ | type/ ✅ 擴充 | 新增 meeting、decision、sop |
source/ | source/ ✅ 保留 | 不變 |
action/ | ❌ 移除 | 專案狀態改用 4-project/ 內的 frontmatter 管理 |
self/ | ❌ 移除 | 純個人 |
area/ | ❌ 移除 | 個人生活領域 |
outcome/ | ❌ 移除 | 實驗筆記專用，團隊版不需要 |
| — | project/ ✅ 新增 | 跨資料夾標記所屬專案 |
部門版模板
保留（從個人版調整）
| 模板 | 調整內容 |
|---|---|
permanent-note.md | 加 author 欄位，移除 area/ tag |
literature-note.md | 加 author 欄位，其餘不變 |
moc.md | 不變 |
project-tracking.md | 移除 action/ tag，加 project/ tag |
project-analysis.md | 加 author，其餘不變 |
移除
| 模板 | 原因 |
|---|---|
experiment-note.md | 個人實驗框架，團隊不適用 |
新增
meeting-note.md（會議紀錄）：
---
id: "{ date:YYYYMMDDHHmm }"
title: "{{title}}"
created: "{ date:YYYY-MM-DD }"
author: "{{記錄者}}"
attendees: []
tags:
- type/meeting
- project/
- status/unreviewed
---# {{會議名稱}}
## 出席者
-
## 摘要
（3-5 點重點）
## 決策事項
-
## Action Items
- [ ] @負責人 事項（截止日）
## 待確認事項
-
## 連結
- 相關：[[]]decision-record.md（技術決策紀錄）：
---
id: "{ date:YYYYMMDDHHmm }"
title: "{{title}}"
created: "{ date:YYYY-MM-DD }"
author: "{{決策者}}"
tags:
- type/decision
- project/
- topic/
- status/unreviewed
---# {{決策標題}}
## 背景
（為什麼需要做這個決策）
## 選項
1. **選項 A**：...
- 優點：
- 缺點：
2. **選項 B**：...
- 優點：
- 缺點：
## 決策
選擇：**選項 X**
原因：
## 影響
-
## 連結
- 相關：[[]]sop.md（標準作業程序）：
---
id: "{ date:YYYYMMDDHHmm }"
title: "{{title}}"
created: "{ date:YYYY-MM-DD }"
author: "{{作者}}"
tags:
- type/sop
- topic/
- status/unreviewed
---# {{SOP 標題}}
## 適用場景
（什麼時候要用這個流程）
## 前置條件
-
## 步驟
1.
2.
3.
## 常見問題
| 問題 | 解法 |
|------|------|
| | |
## 連結
- 相關：[[]]初始說明筆記：團隊知識庫快速上手
取代個人版的 7 篇方法論筆記，濃縮為 1 篇實用指南
---
id: （建置時產生）
title: "團隊知識庫快速上手"
created: （建置日期）
author: "Matt"
tags: [type/how-to, status/evergreen]
---
# 團隊知識庫快速上手
## 這是什麼？
部門共享的知識管理系統。透過 Telegram bot 就能查知識、記東西、追專案。
底層是 Zettelkasten 方法——用大量短筆記互相連結，取代長文件和資料夾分類。
## 怎麼用？
### 查東西
直接用 Telegram 問 bot：
- 「WriteAhead 的 API 認證怎麼做？」
- 「上次跟 XX 開會決定了什麼？」
- 「Sprint 4 進度？」
### 記東西
把想法/學到的東西丟給 bot：
- 「我發現 Nuxt 3 的 middleware 可以這樣寫...」→ bot 整理成知識筆記
- 「今天跟客戶確認了 XX 規格」→ bot 存入專案紀錄
### Sprint 操作
- `/sprint-analyze` — 看 Sprint 全貌
- `/task-plan SCRUM-xxx` — 拆解 story 為執行步驟
- `/task-execute SCRUM-xxx` — 讓 AI 按計畫寫 code
- `/task-complete SCRUM-xxx` — 自動測試 + commit + 更新 Jira
### 學習
- 丟 YouTube / Udemy 連結 → bot 產出結構化筆記
## 三個原則
1. **一篇一件事**：「Vue 的 computed 和 watch 的差別」是一篇，不要塞進「Vue 全部知識」
2. **連結比分類重要**：不用煩惱放哪個資料夾，重要的是跟哪些筆記有關
3. **先記再整理**：品質不完美沒關係，丟進來就好，AI 會幫忙整理和連結三、Skill 選擇
部門適用（納入部署）
| Skill | 用途 | 為什麼部門需要 |
|---|---|---|
/sprint-analyze | Sprint 狀態分析 | PM/dev 都需要掌握進度 |
/task-plan | Story → 執行計畫 | 減少規劃時間，統一拆解品質 |
/task-execute | 按計畫自動寫 code | 開發效率核心 |
/task-complete | 測試 + commit + Jira 更新 | 自動化收尾流程 |
/youtube-notes | 影片 → 結構化筆記 | 團隊學習 |
/udemy-notes | 課程 → 結構化筆記 | 團隊學習 |
/project-kickoff | 專案規劃 | 統一專案啟動品質 |
個人專用（不納入）
| Skill | 原因 |
|---|---|
/daily-plan | 依賴 5-self/，純個人 |
/goodnight | 個人自動化（接案掃描等） |
/victory | 個人反饋機制 |
/wrap-up | 個人回顧 |
/playwright | 個人瀏覽器自動化 |
/udemy-tutor | 個人學習教練（可評估未來開放） |
/udemy-practice | 個人練習專案（同上） |
可能新增的部門 Skill
| 構想 | 用途 |
|---|---|
/meeting-summary | 從 meetings/ 中搜尋歷史會議、追蹤 action items |
/onboarding | 新人查詢部門知識庫中的 SOP 和技術文件 |
/code-review | 提交 PR 前讓 AI 先 review |
四、Telegram Bot 部門設定
角色與權限
沿用現有多人架構，調整角色定義：
先導期成員：正一（主管）、卜仁（後端）、Enoch（DevOps + Scrum Manager）、褚得健（PM）、Matt（前端）
| 角色 | 對象 | 權限 | 每日額度 |
|---|---|---|---|
| admin | Matt、Enoch | 完整權限（所有 skill + 管理指令） | 無限 |
| dev | 卜仁 | Sprint skills + 知識庫查詢 + 學習 skills | 30 次 |
| pm | 正一、褚得健 | 知識庫查詢 + 會議相關 + Sprint 狀態 | 20 次 |
cwd 隔離
所有角色的 cwd 統一指向部門 zettelkasten，不存取個人檔案。
五、成本估算
成本
| 階段 | 月費 | 說明 |
|---|---|---|
| 先導期（本機） | $0 | Matt 現有 Max 5x + 筆電，零額外成本 |
| 擴展期（若需 24/7） | $25-35 VM + API Key 用量 | 屆時再評估 |
對比：一個兼職助理月薪 NT$15,000+。先導期完全免費就能驗證。
六、安全考量
| 面向 | 措施 |
|---|---|
| 個人/團隊隔離 | ~/zettelkasten/（個人）與 ~/team-zettelkasten/（團隊）完全分離，5-self/ 不可見 |
| 程式碼存取 | Lung-Teng repos 在 Matt 筆電本機，不外傳 |
| 資料傳輸 | Telegram（加密）→ 本機 bot → Claude API（加密） |
| 存取控制 | Telegram bot 角色系統 + userId 白名單 |
| Anthropic 政策 | Max 訂閱在個人裝置使用，符合使用條款 |
七、使用者黏著度設計（Octalysis 遊戲化）
問題：純「問問題 + 看 Sprint」不足以讓人養成每天用的習慣。 解法：用遊戲化驅動力設計 bot 的互動機制，讓「回來用」本身有動力。
驅動力對應
| CD | 驅動力 | 機制設計 | 觸發時機 |
|---|---|---|---|
| CD2 成就感 | 週報摘要：bot 每週一主動推送個人使用統計——「你本週問了 12 次，知識庫因此新增 3 篇筆記」 | 每週一早上自動推送 | |
| CD2 成就感 | 里程碑：首次使用、第 10 次查詢、第一篇貢獻知識、連續五天使用 | 達成時 bot 主動通知 | |
| CD3 創造力 | 知識貢獻：使用者丟進來的資訊被整理成知識庫筆記，能看到自己的輸入變成團隊資產 | 每次貢獻後回饋 | |
| CD3 創造力 | 自訂 prompt：讓使用者可以教 bot 新的回答方式或知識（「以後有人問 X，先看 Y 文件」） | 隨時 | |
| CD5 社交影響 | 團隊知識活躍度：「本週知識庫新增 8 篇，最活躍貢獻者：Enoch（3 篇）」 | 週報中呈現 | |
| CD5 社交影響 | 共享發現：「Matt 剛加入一篇關於 Nuxt 3 middleware 的筆記，可能跟你的 task 有關」 | 新筆記入庫時推送相關成員 | |
| CD7 好奇心 | 今日知識推薦：bot 每天早上從知識庫中挑一篇推送——「你知道嗎？」 | 每天早上 | |
| CD7 好奇心 | Sprint 趣味統計：「這個 Sprint 團隊總共 commit 了 47 次，最大單次改動 312 行」 | Sprint 結束時 |
不使用的驅動力
| CD | 為什麼不用 |
|---|---|
| CD6 稀缺 | 額度限制已經存在但不應該被強調為驅動力——「快用完了」會造成焦慮而非動力 |
| CD8 損失恐懼 | 「不用就落後」的框架對團隊文化有害，不採用 |
實作優先序
| 優先度 | 機制 | 實作難度 | 理由 |
|---|---|---|---|
| P0 | 每日知識推薦 | 低 | 零成本讓人每天打開 bot，建立習慣 |
| P0 | 週報摘要 | 低 | 用數據讓使用者「看見」自己的使用 |
| P1 | 里程碑通知 | 低 | 已有 usage-stats.json 可追蹤 |
| P1 | 知識貢獻回饋 | 中 | 需要在知識寫入流程加 hook |
| P2 | 相關筆記推送 | 中 | 需要 tag/內容比對邏輯 |
| P2 | 團隊活躍度 | 低 | 週報中加一段就好 |
八、分階段落地
Phase 0：環境建置（2/24-3/2，每天一點）
目標：3/2（一）全部就緒，3/3（二）team 試用，3/4（三）報告
| 日期 | 工作項目 | 預估時間 |
|---|---|---|
| 2/25（三） | A.1 建立 ~/team-zettelkasten/（結構 + CLAUDE.md + templates） | 30 min |
| 2/26（四） | A.2 Clone Lung-Teng 全 11 repos 到 ~/team-workspace/ | 30 min |
| 2/27（五） | A.3 修改 Telegram bot：team 角色 cwd → ~/team-zettelkasten/ + skills 子集 | 60 min |
| 2/28（六） | A.4 設定 Jira API token + 測試 Sprint skills | 30 min |
| 3/1（日） | A.5 加入先導成員 + 全流程自測 | 30 min |
| 3/2（一） | A.6 最終確認 + 修 bug | buffer |
| 3/3（二） | Team 試用日 — 收集問題和擴充需求 | — |
| 3/4（三） | 報告日 — 展示已在跑的系統 | 1 hr |
- A.1 建立
~/team-zettelkasten/（結構 + CLAUDE.md + templates） - A.2 Clone Lung-Teng org 全 11 repos 到
~/team-workspace/ - A.3 修改 Telegram bot：team 角色 cwd + skills 子集
- A.4 設定 Jira API token + 測試 Sprint 自動化
- A.5 加入先導成員（正一、卜仁、Enoch、Matt — 褚得健待加入）
- [~] A.6 全流程測試（初步測試完成，待深度驗證）
Phase A：先導期（3/3 起，2-4 週）
目標：5 人試用，驗證「部門真的用得到」
- A.1 每週收集回饋，調整 skill 和流程
- A.2 上線 P0 遊戲化機制（每日知識推薦 + 週報摘要）
先導期成功標準：
- 每位成員每週至少使用 3 次（遊戲化機制輔助達成）
- 正一認為「值得繼續」
- 知識庫至少累積 20 篇團隊產出的筆記
先導期採用觀察
3/5 褚得健使用狀況（來源：Matt 與皓澤 LINE 對話）
- 在 daily 說 bot 回答「感覺有追上 Gemini」——不知道背後是 Opus，不理解模型差異
- 一天大約使用 1-2 次，主要是應付 Matt 的要求
- 沒有在知識庫中做任何筆記，缺乏知識管理意識
- 大部分仍使用 Gemini，把 bot 當 Google 用
- 每天工作到八點，沒有利用 AI 提升效率的認知
- 觀察：符合典型的「工具導入阻力」——使用者無法區分工具品質差異，因為工作性質（PM，非 coding）的錯誤容忍度高，AI 回答品質的差距不明顯。遊戲化機制（Phase A.2）可能是提升黏著度的關鍵
Phase B：部門推廣（Phase A 驗證後）
目標：全部門上線
- B.1 根據先導期回饋調整角色/額度
- B.2 全部門成員加入 bot
- B.3 撰寫使用指南（怎麼跟 bot 對話、可以問什麼）
- B.4 定期知識庫維護流程（誰負責 review、清理）
Phase C：深化（Phase B 穩定後）
目標：擴展應用場景
- C.1 新增部門專屬 skills（meeting-summary、code-review 等）
- C.2 知識庫與 Jira/Confluence 整合評估
- C.3 跨部門推廣可行性評估
- C.4 Garden 部署（部門知識庫公開站點）
連結
- 報告準備：Claude Code 部門導入提案會議
- 技術基礎：Telegram Bot 多人擴充專案
- 個人版參考：Claude Code 報告給正一
- 人物：LTrust 團隊人物側寫