MumbleKey Blog

CLAUDE.md 是樂譜：一人公司的 AI 指揮家模式

Mon, 06 Jul 2026 00:00:00 GMT

Reid Hoffman 在一次訪談裡說：

"I'm more of a conductor than I am a violin player or a piano player."

這句話我聽進去了。大部分人說「我有在用 AI」，意思是拿 AI 加速某個步驟——翻譯快一點、code 補全快一點。真正的分水嶺不在這裡，而在把工作本身重組成 AI 可以接手的結構。這篇文章講我怎麼做，以及一年下來系統長成什麼樣子。

兩台機器，兩種角色

我的系統跑在兩台 Mac 上：

MacBook Pro（M1 Max）：互動主力。我在這裡跟 Claude Code 對話、開發、做決策。
Mac mini（M1, 8GB）：無人值守。跑排程任務——每週一早上抓流動性指標、每天掃排程健康狀態、盤前更新期貨點位，異常直接推 Discord 通知我。

兩台機器各有一個 Claude Code agent（我叫它們 Pro CC 和 Mini CC），透過共用的 handoff 筆記交接工作狀態。我睡覺的時候，Mini CC 在工作；我坐到桌前，Pro CC 從 handoff 摘要接手上一場的進度。

CLAUDE.md 是樂譜

指揮家不拉小提琴，但譜架上有總譜。我的總譜是一份叫 CLAUDE.md 的 Markdown 檔——每次會話自動載入，定義這個 agent 能做什麼、曾經在哪裡跌倒、怎麼避免再跌一次。

重點不是寫規則，是讓規則會長大。每次踩坑，教訓就寫回系統：

## F-0. Git 操作紀律（hard rule，pack 吞噬事故後新增）

- 禁止 `git add -A`、`git add .` — 一律明確 pathspec
- 原因：雲端同步工具會把 .git/objects/pack/*.pack hardlink
  進 worktree，全量 add 會吞 pack 造成 repo 指數膨脹
  （本 repo 曾脹到 2.0TB）

這條規則來自一次真實事故：雲端同步工具跟 git 打架，repo 膨脹到 2TB。修復之後，教訓變成一條 hard rule，從此每個 agent 會話都不會再犯。用得愈久，系統愈懂我——這比任何模型升級都值錢。

記憶分三層

單一大檔案會爆 token，所以記憶按重用性分層：

情節記憶：帶日期的會話紀錄，追查「那天發生什麼」用
語義記憶：跨會話可重用的知識，按主題整理
強制規則：不管什麼情境都必須遵守的約束

情節記憶累積到一定程度，蒸餾成語義記憶；語義記憶再往上凝結成 wiki 文章。加上懶加載（會話啟動只讀核心身份檔，其他模組按需載入），token 消耗比單一大檔少了七成。

四個角色，各有邊界

開發 iPhone 鍵盤 app 的時候，我把 agent 拆成四個角色：PM 分析需求寫 spec、Designer 出設計稿、Engineer 實作、QA 審查把關。關鍵是邊界用制度鎖死：PM 不碰程式碼，Engineer 才能 commit，QA 擋 release。

這不是角色扮演遊戲。邊界存在的理由跟人類團隊一樣：寫 code 的人不該自己驗收自己的 code。我的驗證紀律裡有一條鐵律——「驗證不自驗」，實作者的產出必須由另一個獨立 agent 或我本人用真實輸入跑過才算數。

這套系統實際產出什麼

商業產出：客戶的影片字幕，從每支 2-3 小時人工校正壓到 15-30 分鐘自動化（這條 pipeline 值得單獨一篇，已經寫了）
日常生產力：行事曆、提醒事項、email 摘要、每日規劃，全部是 Claude Code 黏著原生 Apple app，零 SaaS 訂閱
投資基礎設施：券商 API 串接、持倉異常掃描、選擇權籌碼快照，跑在排程上

沒請員工，沒買 SaaS。系統的邊際成本是每月的 Claude 訂閱費。

如果你想開始

不用一次建完。我的建議順序：

先寫一份最小的 CLAUDE.md：你是誰、專案在哪、有什麼絕對不能做
每次 AI 犯錯，把教訓寫回去（這一步是複利的來源）
檔案變大之後再拆層：規則、記憶、wiki
最後才是多機、多角色

Hoffman 那段訪談還有一句："Even most people who say 'Oh yeah I'm using AI' are not using it seriously enough." 認真用的意思，不是 prompt 寫得多漂亮，是願意把工作結構打掉重組。

從 3 小時到 30 分鐘：我的中文字幕自動化 pipeline

Mon, 06 Jul 2026 00:00:00 GMT

我幫一位財經教育創作者做影片字幕。一支兩小時的影片，人工校正要 2-3 小時；現在同樣的工作，pipeline 自動跑完加上我抽查，15-30 分鐘。這篇講這條生產線怎麼搭起來，以及三個讓它從「能跑」變成「可靠」的關鍵教訓。

生產線長什麼樣

整條 pipeline 在 Claude Code 裡用一個 skill 觸發，依序跑六個階段：

下載（yt-dlp）
  → 畫面術語抽取（OCR / VLM caption，每 60 秒一幀）
  → ASR（Breeze ASR 25，Apple Silicon 本地推理）
  → 預處理（斷句清理、詞中逗號修復）
  → LLM 校正（分段派 subagent，注入術語表＋畫面上下文）
  → 後處理（超長字幕切分、品質 gate、SRT 輸出）

全程本地跑 ASR，只有校正階段用雲端模型。財經內容的難點不是語音辨識本身，是專有名詞：股票代號、ETF、指標縮寫、講者的口頭禪。ASR 把「美光」聽成別的詞、把「MA30」拆成碎片，這類錯誤靠通用模型修不好，要靠領域知識。

術語表是活的

系統的核心不是任何單一模型，是一個會學習的術語迴圈：

每支影片校正完，跑一次 term learning，把「ASR 錯法 → 正確詞」寫成機械替換規則
下一支影片的 ASR 輸出，先過這批規則再進 LLM 校正
畫面上的投影片文字（OCR 抽取）補充當集的新術語

量化過一次效果：連續處理 8 支影片，第一輪學習後新增 16 條替換規則，同一支影片的自動修正數從 0 跳到 58。第二輪之後，LLM 校正 subagent 回報的修正量明顯下降——因為便宜的錯誤已經在上游被機械規則吃掉了。

教訓一：驗證要看值，不是看有沒有錯誤

有一次，一個校正 subagent 把 300 條字幕「過度合併」成 110 條，出現 10-29 秒的超長字幕。當時的驗證只檢查「檔案存在＋格式正確」，照樣放行。

修法是把驗證改成檢查數值：

ratio = corrected_count / original_count
if ratio < 0.55:
    fail()          # 條數掉太多，必是過度合併
if ratio < 0.80 and longest_entry_sec > 15:
    fail()          # 條數比例配合時長症狀雙重確認

閾值不是拍腦袋，是拿 10 部歷史影片的 88 個分段校準出來的（誤報率 0）。單看條數比例不夠——講者講碎句的段落天然低 ratio，要配上「最長條目時長」這個症狀一起判。

教訓二：subagent 的輸出永遠要防禦性解析

LLM subagent 偶爾會把判斷過程寫進輸出（「[通順，不改]」），或洩漏工具呼叫的 XML 標籤。更麻煩的是，後處理的切分邏輯會把單點污染放大成多處擴散。

防呆分三層：prompt 明列禁止輸出的模式、合併前先 strip、後處理完再 strip 一次。原則只有一句：清理必須在切片之前，不能信任 subagent 自律。

教訓三：資源衝突要編排，不是祈禱

32GB 的 M1 Max 跑不動兩個大模型同時推理。20GB 的視覺模型跑完之後，框架還會把模型在記憶體裡保留幾分鐘——這段時間啟動 ASR 就直接 OOM。修法很土但有效：caption 一跑完就明確下 ollama stop，再啟動下一個階段。小模型（1.5GB 的 ASR ＋ 5GB 的輔助 ASR）反而可以放心並行，頂多互搶 GPU 變慢，不會掛。

值得抄的三個設計

如果你要搭類似的東西，我覺得最值得抄的是：

保留所有中間產物。每個階段的輸出都留檔。品質 gate 的閾值校準、事故後的重建，靠的都是這批歷史資料。
機械規則吃便宜錯誤，LLM 吃難錯誤。分層之後，貴的模型只處理真正需要理解的部分。
gate 用真實資料校準。防呆閾值拿歷史產出算出來，不是猜出來。

這條 pipeline 的 skill 已經開源，跟它的姊妹技能（把錄音整理成忠於原話的文章）都在我的 GitHub 上。