① 為什麼要做這個？
如果你同時在做研究、管理多個專案、追蹤財務、維護伺服器 — 你一定經歷過這種場景：正在寫論文，突然想到備份腳本昨天好像沒跑。切過去看 log，發現 NAS 連線有問題。修完回來，已經忘記剛才寫到哪裡了。
這就是context switching 的認知成本。研究顯示，每次切換任務後需要 15-25 分鐘才能回到深度專注狀態。如果你每天被打斷五次，就損失了兩個多小時的深度工作時間。
傳統的解法是「用 AI 工具自動化」— 但大多數 AI 助手是一次性的：你問一個問題，它回答，然後忘記一切。它不知道你上週做了什麼決定，不知道你的專案之間有什麼依賴關係，更不知道你此刻最應該專注在哪件事上。
核心洞察：AI 是認知夥伴，不只是工具
我們把這套系統定位為新創公司的 CEO-COO 模式：你（CEO）負責方向決策和創意發散，AI（COO）負責執行追蹤、流程管理、補償你的認知弱點。就像有一個永遠不會忘事的營運長，隨時知道所有專案的進度和優先序。
② 架構全貌
三層面工作模型
COO 的一切工作服務於三個層面。它們不是獨立的 — 專案產生知識，知識啟發新專案，營運確保什麼都不掉球。
系統架構
整套系統分三層：記憶層存你的思考，執行層跑自動化，儲存層做備份。每一層都有明確的職責，不混用。
每個元件存在都有原因：
- Obsidian — 你的第二大腦，所有知識和決策歷史都在這裡。選它是因為純 Markdown、可離線、資料完全屬於你。
- Workspace — 所有自動化腳本的執行基地。和 Obsidian vault 分開，因為筆記和程式碼的生命週期不同。
- NAS — 每天自動備份，不依賴雲端。你的資料不該只存在一台電腦上。
- Telegram Bridge — 讓你在外面也能跟 COO 對話。選 Telegram 是因為 Bot API 極簡、支援 Markdown、手機體驗好。
- Local LLM (ollama) — 批次處理（摘要、分類、報告生成）走本地模型，省成本、保隱私、無 API 依賴。
- Claude Code — 需要深度推理的工作交給它。品質天花板最高，適合策略決策和複雜分析。
③ 演進路徑
這套系統不是一次設計出來的。每個階段都是為了解決一個具體的痛點。這是最重要的設計原則：不超前設計，走通再擴展。
Phase 0：手動腳本
問題：每天手動抓財務數據、手動備份，忘記就漏掉
解法：寫獨立的 Python/Shell 腳本，一個功能一個檔案
學到：先讓每個腳本獨立可用，不要一開始就想整合
Phase 1：Cron 自動化 + 通知
問題：腳本寫好了但還是忘記跑，而且跑完沒回饋
解法：cron 排程定時執行 + Telegram bot 推送結果
學到：自動化 + 通知 = 最小可用的被動系統。通知 bot 和對話 bot 要分開
Phase 2：Telegram Bridge（雙向通訊）
問題：出門後無法跟 AI 溝通，只能等回到電腦前
解法：寫一個 bridge，把 Telegram 訊息注入 tmux session 的 Claude Code
學到：Bridge 不用 webhook（需要公開 IP），long polling 就夠用。安全防護很重要 — shell injection、卡住偵測
Phase 3：知識層
問題：和 AI 討論的內容散落在對話中，過幾天就找不到了
解法：建立結構化知識管理 — Wiki 索引、Canvas 全局圖、自動摘要回寫 Brief
學到：DevLog（時間綁定：那天發生了什麼）和 Insights（主題綁定：這個 pattern 在哪裡適用）要分開存
Phase 4：專案管理系統
問題：高優先專案任務複雜、依賴多，容易失焦
解法：完整 PM pipeline — inbox 收集 → LLM 分類 → 早報 → Gantt chart
學到：用 YAML 而非 database — 透明、可 git diff、你可以直接編輯。狀態變更需人核可（human-in-the-loop）
Phase 5：認知夥伴
問題：PM 報告只是數據呈現，沒有真正幫你「思考」
解法：給 PM 一個「靈魂」— 理解你的認知模式，能指出你在迴避什麼
學到：AI 最大的價值不是幫你做更多事，而是幫你看到盲點。Discussion-first：你的問題驅動分析，不是 AI 先報告再等提問
④ 核心模組
通知與溝通
從單向通知到雙向對話，手機就是你的遠端控制台。
專案管理
從隨手記到結構化追蹤，YAML 是你的 single source of truth。
知識管理
讓你的想法不只是「寫下來」，而是能被找到、能回撈、能啟發。
自動化
Cron 是你的自動化骨幹，簡單、可靠、不需要額外服務。
技術選擇的理由
為什麼 Local LLM (ollama) 做批次任務？
每天跑十幾次摘要和報告生成。如果全走雲端 API，每月成本可觀。本地模型零成本、資料不出機器、不受 API 限額影響。品質對批次任務來說足夠。
為什麼 Claude 做複雜推理？
當你需要分析專案策略、找出認知盲點、做跨領域的深度思考時，品質天花板就很重要。本地 7B-30B 模型能做 80% 的工作，但最關鍵的 20% 需要更強的推理能力。
為什麼 Telegram 不用 Slack？
這是個人工作站，不是團隊工具。Telegram Bot API 非常簡潔（HTTP long polling 就行），支援 Markdown 格式，手機 app 體驗好。而且免費、不限歷史訊息。
為什麼 YAML 不用 database？
YAML 人類可讀、可以直接用編輯器改、git diff 一目了然、不需要跑 server。對個人專案管理來說，這些優勢遠大於 database 的查詢能力。
⑤ 自己動手做
30 分鐘最小可用版本
不需要一次做完所有東西。以下四步就能有一個可用的起點：
-
安裝 Claude Code CLI
npm install -g @anthropic-ai/claude-code
# 或: brew install claude-code
-
建立 CLAUDE.md — 定義你的 COO
在 home 目錄建立 ~/CLAUDE.md，寫下你是誰、你希望 AI 扮演什麼角色、你的工作方式偏好。這個檔案是整個系統的靈魂。
# ~/CLAUDE.md 範例
## 角色
你是 COO。用戶是 CEO。我們用新創模式協作。
## 用戶畫像
- 軟體工程師，同時管理 3 個 side project
- 偏好簡潔回覆，不需要重複確認
## 工作方式
- 每次工作前讀 WORKSPACE.md 確認狀態
- 版控優先：每個專案有獨立 git repo
- 任務完成 = 用戶收到結果
-
建立 Telegram Bot + 通知腳本
# 1. 在 Telegram 找 @BotFather，發送 /newbot 建立 bot
# 2. 記下 bot token
# 3. 向你的 bot 發送一則訊息
# 4. 取得你的 chat_id:
curl "https://api.telegram.org/bot<TOKEN>/getUpdates" | python3 -m json.tool
# 5. 寫通知腳本 notify.sh:
#!/bin/bash
TOKEN="your-bot-token"
CHAT_ID="your-chat-id"
MSG="$1"
curl -s -X POST "https://api.telegram.org/bot${TOKEN}/sendMessage" \
-d chat_id="${CHAT_ID}" -d text="${MSG}" -d parse_mode=Markdown
-
加一個 cron job
# 每天早上 8 點提醒你今天的重點
crontab -e
# 加入:
0 8 * * * /path/to/notify.sh "早安！記得檢查今天的待辦事項"
漸進升級路線圖
Level 1: 通知系統
約 1 小時
- Telegram notify bot
- 備份腳本 + cron
- 失敗時自動告警
Level 2: 雙向溝通
約半天
- TG Bridge 設定
- tmux session 長駐
- 手機遠端指揮 AI
Level 3: 專案追蹤
約 1 天
- YAML 專案檔案
- LLM inbox digest
- 每日早報生成
Level 4: 知識整合
持續迭代
- Obsidian vault 結構
- Wiki index + lint
- Canvas 全局圖
- Insight 沉澱
工具替代方案
這套系統的設計是模組化的。每個元件都可以替換成你熟悉的工具：
| 元件 | 我們的選擇 | 替代方案 |
|---|
| AI 助手 | Claude Code + ollama | ChatGPT, Cursor, Copilot, 純本地模型 |
| 筆記系統 | Obsidian | Notion, Logseq, plain Markdown files |
| 通訊管道 | Telegram | Slack, Discord, LINE, Signal |
| 儲存備份 | Synology NAS | Google Drive, rsync to any server, local disk |
| 排程自動化 | cron + launchd | GitHub Actions, n8n, systemd timers |
| Python 管理 | uv | pip + venv, conda, poetry |
| 專案資料格式 | YAML | JSON, SQLite, Notion database |
設計原則（帶著走）
不管你用什麼工具組合，這些原則是通用的：
- 先 human-in-the-loop，穩定後放權 — 新功能先做需要人核可的版本，確認可靠再自動化
- 預設輕量，主動升級 — 不過度自動化，由你決定什麼時候升級
- 簡單可迭代 — 不超前設計，走通再擴展。每個階段解決一個具體痛點
- 版控優先 — 每個專案有獨立 git repo，每次有意義的變更都 commit
- 單一真相原則 — 每個事實只存一個地方，其他地方用指標
- 任務完成 = 用戶收到結果 — 報告生成但通知沒送出 ≠ 完成