Claude 系統穩定性優化計畫

基本資訊

更新日期

2026-05-05

分析來源

Claude + Codex 共識

總工時估算

~11.5 小時（兩週內）

0核心原則

「凡是每次都要做、不需要判斷的事，從 AI 的腦子搬到系統的管線裡。AI 只負責內容判斷。」

目前問題：太多環節靠 AI 記住去做，context 壓縮後就忘，等於白寫規則。

解法方向：把「確定性邏輯」寫進腳本、hook、cron；把「理解與判斷」留給 AI。每一個「AI 忘記做 X」的問題，都是一個可以系統化的機會。

Phase 1 — 緊急

立即修復（今天可做，共 1-2 小時）

這些問題已在造成實際損失，今天就要做掉。

1-1 Token Refresh 合併

緊急工時：15 分鐘風險：低

現狀問題

auto-restart.sh 和 refresh_claude_token.py 兩套機制互搶，導致 429 rate limit（108/118 次失敗）。

改法

刪掉 auto-restart.sh 裡的 refresh_oauth_token() 函式
只保留 cron 的 refresh_claude_token.py
加 flock 鎖防止同時執行

1-2 部署後自動驗證

緊急工時：30 分鐘風險：低

現狀問題

git push 後沒有 smoke test，今天 .claude/worktrees submodule 導致 Cloudflare 部署失敗數小時沒人發現。

改法

寫 post-push-verify.sh：push 後等 90 秒，curl 打線上頁面驗 HTTP 200
失敗就用 Discord API 通知
應用到：研究報告網站-公開站、私人站的 push-reports skill

1-3 .gitignore 全站補齊

緊急工時：10 分鐘風險：低

現狀問題

.claude/ 目錄沒被 ignore，worktree 被意外 commit 成 submodule，造成 Cloudflare 部署異常。

改法

所有 git repo 加 .claude/ 到 .gitignore
確認已 commit 的 .claude/ 目錄全部 git rm --cached

Phase 2 — 本週

行為規則系統化（共 2-3 小時）

把最常被糾正的行為從「AI 記憶」移到「系統機制」。

2-1 DC 漏回覆偵測

本週工時：45 分鐘風險：低

現狀問題

AI 忘了回覆 DC 沒人知道，使用者等很久才發現。

改法

patrol.sh 新增檢查 — 用 Discord API 抓最近 10 條訊息
比對使用者最後訊息 vs Claude 最後回覆的時間差
超過 5 分鐘就 curl Discord API 發警告

2-2 高頻規則寫進 CLAUDE.md（不靠記憶）

本週工時：15 分鐘風險：無

現狀問題

feedback 規則散在十幾個 .md 檔案裡，context 壓縮後 AI 不會重讀。

改法：把最常被糾正的 5 條規則直接寫進 CLAUDE.md 最上面

DC 訊息先 react emoji 再處理
不要結尾 CTA
注音亂碼只按 emoji
不知道的事先 fetch_messages 查
長內容自動上 GitHub Pages

每次 session 啟動和壓縮後都會重載 CLAUDE.md，等於從系統層面強制執行這些規則。

2-3 Skill 自動觸發 Hook

本週工時：1 小時風險：低

現狀問題

技能靠 AI 判斷何時使用（推網站、轉譯等），容易忘記或判斷錯誤。

改法

偵測到新錄音檔 → patrol.sh 直接觸發轉譯腳本（已有 auto_transcribe.sh）
git push 完成 → hook 自動跑部署驗證（Phase 1-2）
寫完 HTML 報告 → PostToolUse hook 偵測 .html 寫入，自動提醒「要推送嗎？」

Phase 3 — 下週

狀態管理結構化（共 3-4 小時）

把模糊的「AI 自己判斷」轉成可驗證的結構化格式。

3-1 checkpoint/task_queue 改 YAML

下週工時：1.5 小時風險：低

現狀問題

純 markdown，AI 用猜測方式解析，壓縮後可能截斷，「下一步」是敘述而非指令。

改法

改成 YAML 格式 + 10 行 Python 驗證腳本在 patrol.sh 跑
checkpoint 加入「下一步指令」欄位（可直接執行的 command，不是敘述）

3-2 記憶檔案加 TTL

下週工時：1 小時風險：低

現狀問題

AI 自己判斷記憶是否過期，沒有客觀標準，過期資訊一直存在佔用 token。

改法

每個 .md frontmatter 加 last_updated（自動）和 ttl_days（手動設定）
patrol.sh 定期掃描，過期標 stale: true
月初自動生成「過期記憶清單」提醒清理

3-3 生圖/做圖腳本化

下週工時：1 小時風險：低

現狀問題

GPT Image API 每次手動組 prompt、格式參數，容易出錯、費時。

改法

封裝成 CLI 工具 generate-image.sh
品質/格式/尺寸寫死，只傳描述即可

Phase 4 — 視需求

進階管線（共 4-5 小時）

最激進的改法，適合系統穩定後再投資。

4-1 完整任務管線 (Pipeline)

視需求工時：2 小時

目標

錄音 → 轉譯 → 分析 → 上網頁 → 推送 → DC 通知：每一步由腳本串接，AI 只負責「分析」那一步的內容
報告撰寫 → HTML 生成 → 推送 → 部署驗證 → DC 傳連結：同理

AI 只在「需要判斷的點」介入，其他全部腳本自動化串接。

4-2 DC 互動中間層

視需求工時：1.5 小時

目標

收到 DC 訊息 → 中間層先做：react emoji、記錄時間戳、檢查是否附件
然後才傳給 AI 處理內容

最激進但最有效的改法，完全消除「AI 忘記 react」的問題。中間層不需要 AI 參與，純腳本可靠性接近 100%。

4-3 監控儀表板

視需求工時：1 小時

目標

把 patrol.sh 的檢查結果寫成結構化 JSON
建一個簡單的 HTML dashboard 顯示：系統健康度、最近部署狀態、token 過期倒數、記憶體用量、待處理任務數

Phase 5 — 記憶與日誌

記憶品質與日誌完整性（共 3-4 小時）

解決「做了事但記憶/日誌沒更新」的核心問題。

5-1 Daily Log 即時寫入（不靠 session 結束）

記憶品質工時：1 小時風險：低

現狀

Daily log 在 session 結束時由 generate-daily-log.sh 生成，但如果中間做了很多事然後 context 壓縮，結束時 AI 已經忘了早期的工作內容。今天的日誌只記了 DriveTidy（本機），雲端做的 5+ 件事全部沒記到。

改法

PostToolUse hook：偵測到 git commit → 自動 append 一行摘要到 daily log（commit message + repo 名稱 + 時間）
PreCompact hook：context 即將壓縮前，把當前 session 的工作摘要寫入 daily log（已有 pre_compact_checkpoint.sh，擴充功能）
不靠 AI 在 session 結束時回憶，而是邊做邊記

5-2 跨 Session 記憶同步強化

記憶品質工時：45 分鐘風險：低

現狀

雲端 Claude 跟本機 Claude 共用記憶 repo（claude-memory），但 session 啟動時只做 git pull，不會主動告知「上一個 session 改了什麼」。導致兩邊 Claude 資訊不同步。

改法

SessionStart hook 加強：git pull 後用 git log --oneline -10 列出最近更新的記憶，生成差異摘要注入 context
讓新 session 一開始就知道「上次做了什麼、改了哪些記憶」

5-3 任務完成後自動觸發記憶更新提醒

記憶品質工時：45 分鐘風險：低

現狀

完成一個任務後，AI 應該檢查相關記憶是否需要更新（CLAUDE.md 寫了這個規則），但 context 壓縮後就忘了。例如：錄音分析出保險知識，但保險相關記憶沒跟著更新。

改法

建立「影響矩陣」：定義哪些任務類型會影響哪些記憶檔案（例：轉譯 → project_voice_transcription.md + 相關人物記憶）
PostToolUse hook 偵測到 skill 完成（如 /transcribe、/push-reports），自動輸出提醒：「以下記憶可能需要更新：[相關檔案列表]」
AI 仍負責判斷要不要更新、更新什麼內容，但「該看哪些檔案」由系統決定

5-4 DC 對話每日摘要

記憶品質工時：30 分鐘風險：低

現狀

DC 對話是主要的工作記錄，但 context 壓縮後就丟失。使用者經常引用「之前說的那個」「那個不是說要改嗎」，AI 要重新 fetch 歷史訊息才能找到。

改法

每天 23:50（cron）自動用 Discord API 拉當天所有訊息
用 Haiku 做摘要（省 token），寫入 daily log 的「DC 對話重點」段落
隔天 session 啟動時自動載入昨天的 DC 摘要，保持對話連續性

5-5 專案狀態 Dashboard

記憶品質工時：1 小時風險：低

現狀

15+ 個專案的狀態散在不同記憶檔案裡（project_*.md），沒有一個地方能一眼看到所有專案的進度。MEMORY.md 有索引但只有一行描述，看不出最新狀態。

改法

每個 project_*.md frontmatter 加 status（active/paused/planned/done）和 last_activity 欄位
patrol.sh 每天自動掃描，生成 project_dashboard.html 推到私人站
一頁總覽：專案名稱、狀態、最後活動日期、下一步行動
使用者隨時打開就知道每個案子到哪了

▶現狀 vs 目標對照表

環節	現狀（靠 AI）	目標（靠系統）	Phase
DC emoji 回覆	AI 記住規則	Hook 自動 react	4-2
部署驗證	沒有	push 後自動 curl 檢查	1-2
Token refresh	兩套互搶	單一 cron + flock	1-1
任務接續	AI 記住下一步	checkpoint YAML + 顯式指令	3-1
記憶過期	AI 自己判斷	TTL 標記 + patrol 掃描	3-2
技能觸發	AI 讀描述選擇	關鍵路徑 dispatch 表	2-3
漏回覆偵測	沒有	patrol.sh 時間差檢查	2-1
生圖參數	每次手動組	CLI 工具寫死預設	3-3
Daily Log	session 結束才寫，常漏	git commit hook 即時 append	5-1
跨 session 同步	只 git pull，不知道改了啥	啟動時自動差異摘要	5-2
記憶更新	靠 AI 想到才更新	影響矩陣 + 自動提醒	5-3
DC 對話記錄	context 壓縮就丟失	每日自動摘要存 daily log	5-4
專案進度追蹤	散在 15+ 個記憶檔案	自動生成 dashboard 頁面	5-5

▶總工時估算

Phase 1

~1

小時

立即修復

Phase 2

~2.5

小時

本週

Phase 3

~3.5

小時

下週

Phase 4

~4.5

小時

視需求

Phase 5

~4

小時

記憶與日誌

合計（Phase 1-3 + 5） ~11 小時

含全部 Phase ~15.5 小時

建議分散在兩週內完成。Phase 1 今天就動手，Phase 2+5 本週內（記憶問題影響每天使用），Phase 3-4 下週。