Workflow MCP Server

## 專案說明 ### 1. 暫停機制 - 如果內容重複失敗：告知用戶，Explain what happened and why 後結束對話 - 需要最新資訊 → 提示用戶去 Perplexity 查（不是雙手一攤，只説去網頁查） - 媒體分析 → 提示用戶去 Gemini 上傳（同上） - 安全風險評估 為什麼重要：解決「訊息孤島」問題，同時錯誤停止機制不浪費 token ### 2. 思考策略 + 複雜度分析 - 能提升推理品質 - 對複雜問題的價值遠超 token 成本 - 減少「試錯次數」= 間接省 token - 分為外顯思考和內部思考 - 詢問一系列問題（詳見下方「功能比較」） - 簡單的任務不需進入分析系統 - 永遠保持真正中立客觀，而不是只會「你說的對...」 範例： ``` 1. Re-examine reasoning (don't immediately agree) 2. If wrong: explain why you were wrong 3. If right: provide evidence 4. NEVER: "你說的對..." without verification ``` 為什麼重要：解決「曲解原意」問題，人在迴路中可以糾正，不浪費 token 可以解決的副問題：環境偵測（有 venv 就必須用，而不是直接 pip install） ### 3. 輕量級的專案記憶系統 - 不是完整的 codebase 理解 / 上下文，只記住重要資訊 - 記住「專案的關鍵決策」（為什麼這樣設計） - 記住「解決了什麼問題」 - 保存「當前在做什麼、下一步計劃」，可以跨對話恢復工作環境 壓縮策略： - 最多 1000 tokens，FIFO - 只保留「為什麼」和「結果如何」 - 刪除所有具體程式碼 - 保留失敗經驗（避免重複踩坑） - 永久保留 = 違反 FIFO = 會無限增長 為什麼重要：對抗上下文腐蝕，讓長期使用變得可行，不用重新解釋背景 ### 5. 任務清單 - 將大任務拆成小任務，提升 AI 專注力 - 不應該使用md：要嘛用內建清單工具，要嘛直接輸出條列式項目 - ❌ 錯誤做法 (很多人在做): ``` ## todo.md - [ ] 步驟 1: 建立資料庫 - [ ] 步驟 2: 寫 API - [ ] 步驟 3: 測試 ``` 問題：AI 讀到後會說「好的我會照做」然後忘記更新 - 正確做法：**不是寫在 md**，是在**對話中** ## 設計原則 ### 1. 工具優先集 - 優先度：內建工具 → 外掛工具（MCP）→ 手動建立 為什麼這樣設計：有內建工具何必使用外掛？有工具何必手動造輪子？ ### 2. 人在關鍵決策點 - AI 建議資源，人確認執行 - AI 發現歧義,人提供澄清 ### 3. 狀態要可遷移 - 不同 AI 工具間透過「同步文檔」溝通 ### 4. 失敗也是知識 - 記錄「什麼沒用」和「什麼有用」一樣重要 - 避免重複踩坑 - 每次失敗都更新情節記憶 ### 6. 避免重複冗餘 - MCP 或提示詞的內容過於詳細，但實際上很多區段重複使用 - 沒有實際價值，只是浪費 token - 內容在精不在多 ### 7. 避免簡短提示 - 過於簡短的提示會讓 AI 無法理解 1. 為什麼 2. 要做什麼 3. 怎麼做 - 不會執行，只是浪費 token ### 8. 不依賴特定工具名稱 - 一律統稱為 file tool / writing tool / read tool... - 而不是 read_file，因為每個 AI 用的工具名稱都不同 ## 現實問題 ### 1. 能用的工具 - 現有代碼 agent 助手只能補充 1. 系統提示詞 和 2. MCP ### 2. 過去經驗 本專案的歷史（理想 → 現實）： - 以為只要使用系統提示詞，AI就會遵守 → AI 直接無視（包含mandatory） - 透過系統提示詞要求 AI 在任務開始前使用 XXX MCP → AI 依舊無視（包含mandatory） - 寫一個帶指令的 MCP，系統提示詞說明對應的簡化名稱 → 必須透過強制說明"You MUST use XXX mcp first 建立一個遊戲..."調用，而不是只有"?f 建立一個遊戲..."等短詞，但是調用完依然會無視 MCP 的指示 (包含mandatory，不管是建立檔案或是 todo，詳見 Q12，但他的解法我認為應該還是無效) - 目前方案：只保留最精簡的 ?r 紀錄，叫 AI 讀取或寫入 ### 3. AI 的實際限制 - **AI 不會遵守系統提示詞中的命令，就算使用mandatory等詞彙也一樣** - **只能手動呼叫 MCP** ，無法透過系統提示詞讓 AI 主動呼叫 - 要**執行的命令必須緊貼在MCP呼叫後**，否則 AI 會忘記 - 可以讓 AI 讀取檔案，但**不能讓 AI 不讀取檔案**：AI 還是會讀取程式碼，在記憶中重複寫程式相關的說明只是浪費 token ### 4. MCP 的實際限制 - process.cwd() → 永遠是 MCP server 的執行路徑，不是用戶的專案路徑！ - （新發現）讓 AI 傳入專案路徑到 MCP，MCP 處理後續步驟（建立檔案，比對...） - MCP 不是另一個 AI，只能回傳預先寫好的內容或判斷邏輯（如字串比對、計數），但不能做「語義理解」（如理解錯誤訊息的深層意義），關鍵字的啟發式判斷能力還是不如 AI，但不是不能處理任何邏輯 ### 5. AI 的能力 - **不能提供任何選擇或備案**，因為 AI 只會走最偷懶/省事的方案 - **如果同時有指令和內容**，AI 會無視所有「流程控制」指令，直接執行「看起來像任務」的內容，所以對話中**要嘛只執行指令，要嘛只說明任務** 舉例說明（?f = 紀錄失敗）： 用戶：?f bcrypt 錯誤 AI：調用 MCP 記錄 → 但下一段對話直接修正，沒有記錄 ## 功能比較 ### 1. 思考工具 - 回聲式思考： MCP 只是把 AI 思考的內容再傳回去，可以強制暫停 AI 並讓其重新審視問題 缺點：依然不是真正的思考（內容重複），而且用戶一樣看不見過程 → 可能不如內部思考，因為內部思考一樣具有 CoT - 對話式思考： AI 分析需求後「明確告訴用戶」接下來的步驟，用戶手動確認後再執行 缺點：每次必須經過 2 次對話，造成多餘 token 浪費 - 清單式思考（可融入複雜度分析）： AI 呼叫 MCP ，MCP 回傳一系列固定問題（如為什麼？可能問題？...等「語義層啟發」）， AI 必須檢查並讀取所有問題才會實作，但可以不需經用戶確認就直接執行 -> 目前最佳方案 ## QA **Q1: 為什麼不在任務完成後自動記錄成功經驗 / 提示用戶輸入 ?f ？** **A**: 因為「執行的命令必須緊貼在 MCP 呼叫後」，如果等 AI 執行完再調用 MCP 記錄，AI 早就忘了上下文。 **Q2: MCP 的 token 估算公式是什麼？** **A**: 理論值粗估：中文 × 2 + 英文 × 0.75 + 符號 × 0.5。精確度不重要，目的是控制 memory.json 不超過 1000 tokens。 **Q3: ?f 有多個操作怎麼記錄？** **A**: AI 總結成一句話。例如「創建 venv + 激活 + pip install bcrypt」→ `what: "配置 Python 環境並安裝 bcrypt"`。 **Q4: FIFO 刪除如何處理超量 entry？** **A**: 一次計算需刪除數量，循環刪除直到 tokens ≤ 1000。 **Q5: FIFO 壓縮會不會丟失重要失敗？** **A**: 會。但「標記重要度」機制最終會變成「只有重要項目存活」，違背 FIFO 初衷。如需保留關鍵失敗，用戶應在 context.current_task 中簡短記錄（如「注意：必須用 venv」）。 **Q6: 為什麼 ?f 是別名而不是獨立命令？** **A**: 減少輸入成本。`?f` 比 `record_failure` 短且易記，用戶也可選擇完整名稱，效果相同。