在年假期間，我花了很多時間打造我的個人助理；而在年假結束、正式把我的「蝦瞎貓」（我幫我的 OpenClaw 取的名字）投入使用後，不到一週，我發現我已經徹底離不開它了。
但我並沒有把任何業務場景放進去。我做的事情反而剛好相反——我讓它深度結合到我的每日工作流當中。
為什麼我想做這個AI Agent？
因為職務的關係，我的「執行型」或「日常型任務」其實非常少。大部分時間，我在做的是制度建立、數據分析、工具建置，這些任務同時具有「一次性專案」與「滾動式修正」的性質，外加日常非常大量的資訊交換。
我的工作幾乎可以用一個循環描述：開會確認行動 → 行動 → 開會確認結果 → 修正結果。這個迴圈大概佔了我工作內容的八成。
為了應付這樣的工作型態，我一直使用 GTD 系統來管理任務，並且希望透過「會議錄音」來協助我記憶。我先前是用 Heptabase 的日誌與白板功能來實作。
但很快就遇到兩個痛點。
GTD本身維護需要成本
每天早上，我都要從Google Calendar同步 Schedule、整理 Inbox，然後再把內容歸檔到我的 GTD 看板上。系統是有幫助的，但維護它本身也需要時間。
會議記錄的操作鏈路太長
開會時手機錄音 → 用手機內建 App 轉逐字稿（這裡要等上很久） → 複製到 ChatGPT 做摘要 → 再存回 Heptabase。
事實上，這段會議記錄的流程我只認真做了一兩次就放棄了——不是因為它沒有價值，而是工具太多、摩擦太大。
後來 OpenClaw 開始流行時，我突然意識到一件事：這整條流程，其實都可以被拆成很多個 Skill，然後集中在同一個聊天視窗裡完成。
只要我能把它設計好。
我一開始以為，最難的是 AI
在真的開始動手之前，我其實很直覺地認為：這件事最難的部分，應該會是 AI 本身。
例如語音辨識準不準、逐字稿品質好不好、摘要會不會漏東西、模型要用多大、延遲能不能接受、要不要做 speaker 分離、要不要準備詞庫……這些都是我一開始最在意的事情。
我也確實花了一段時間在這些問題上反覆測試與比較。
但真正開始用之後，我很快發現一件有點反直覺的事：逐字稿其實不用完美，摘要也不用完整，甚至 speaker 分錯，大多時候也不影響我後續行動。
反而真正會讓整個系統壞掉的，完全是另一類問題。
- 當我說「幫我把這個加入待辦」，系統到底新增了哪一件事？
- 當我說「這個先不用做」，它改到的是不是我心裡想的那一件？
某個行程被錯誤移動、某個不對的任務被關閉、某個期限被誤判——只要發生一次，我就會開始不敢相信這一套系統。
我後來才意識到：我以為我要解決的是 AI 聽不聽得懂，但實際上我在處理的是另一件事——讓系統不要誤會我。
AI 不夠聰明其實還好，人會補；但如果它自作主張地幫我做了錯的決定，那整個「記憶系統」就失去意義了。
也因此，我後來花最多時間的，不是調模型，也不是改 prompt，而是反覆思考一件事情：什麼時候 AI 應該行動、應該怎麼行動；什麼時候則不應該行動。
因此，我替蝦瞎貓設計了幾個原則
當我意識到問題其實是「系統不能誤會我」之後，我做了一個很直接的決定：我不再把 AI 當成記憶本身，而是把它當成一個操作介面。也就是說，AI 可以幫我理解語句、整理資訊、替我操作系統，但它不能成為「事實的來源」。
為了做到這件事，我替蝦瞎貓設計了幾個原則。
AI不是「決策者」，而是「轉譯者」
我後來發現一個很根本的問題：LLM 非常擅長「合理推測」，但任務管理系統最不能接受的，恰好就是推測。
人在對話時其實非常模糊。我常常會說：「這個先不用做」、「剛剛那個幫我改到下週」、「這個我已經處理過了」。對人來說，語境可以補足一切；但對系統而言，「應該是那一個」其實是一種猜測。
如果 AI 被允許自行判斷我指的是哪一筆任務，它大多時候可能是對的，但只要錯一次，我就會開始不敢相信它。因為我使用這套系統的目的，本來就是為了讓我不用再反覆確認自己有沒有記錯事情。
因此我刻意把 AI 的角色降了一級。AI 只負責把自然語言轉換成結構化的意圖，例如我要新增一件事、查詢某段時間，或修改某個狀態，但它不能負責判斷「是哪一筆」，也不能替我做選擇。換句話說，它不是在替我管理任務，而是在替我操作系統。
AI 的理解可以不完美，但它的行為必須可預期。我寧願它回來問我，也不要它幫我猜。當 AI 不再被當成決策者，而只是轉譯者時，整個系統才開始變得可以信任。
資料不能依賴對話上下文(Context)，而必須真實存在
既然 AI 不能成為事實來源，那麼所有重要資訊就不能只存在於對話裡的某一句話，也不能只存在於模型的上下文記憶中。任何待辦、行程、檔案與逐字稿，都必須被寫入本地，成為一筆真實存在、可以被查詢、可以被驗證的資料。
換句話說，我不是讓 AI 記住事情，而是讓 AI 幫我「寫入」事情。對話只是一種輸入方式，而不是記憶本身。
所有資料都透過 Index（索引/目錄） 被管理與關聯
當資料是真實存在的，接著會出現另一個問題：如何確定我們談的是同一件事？
因此每一類資料都需要有對應的 Index，並且可以被唯一識別與關聯。當我說「把這個任務完成」時，系統不是去猜我指的是哪一個，而是必須先找到對應的那一筆資料，才能進行操作。這使得對話從單純的語意理解，轉變為精準的資料操作。
任何修改都必須透過 Skill，而不是由 Agent 直接處理
最後一個原則，是限制 AI 的權限。Agent 負責理解語句，但不能直接改動資料；真正的新增、更新與刪除，全部必須透過 Skill 執行，而且必須符合明確規則。
這看起來比較麻煩，但它帶來一個很重要的結果：我可以接受 AI 聽錯一句話，但不能接受它改錯一筆資料。一旦 AI 能在沒有約束的情況下直接操作資料，這套系統就會變得不可預期，也就不再可靠。
蝦瞎貓的主要兩大功能
從我的工作流程與前面提到的痛點，其實可以很自然地推導出蝦瞎貓的兩個核心功能：一是待辦事項管理（GTD），二是會議相關檔案的整理、產出與管理。
我在上一篇〈AI Agent：點完餐之後，才是真正的開始〉中曾提到「UI → Agent → Tools → Data」的四層架構，而這次我也是依照這個架構來設計整個系統。接下來我會用流程圖來說明這兩套系統的運作方式，並用類似系統設計泳道圖的方式，一步一步解釋我的設計與思考。
這一段看起來可能會有點「工程」——確實也包含一些工程概念，但整個過程中的程式碼其實幾乎全部都是由 AI（就是 ChatGPT）產生的。我做的事情，比較像是在定義規則、調整行為，並確保整體流程能穩定運作。
核心功能一：待辦事項管理（GTD）
在設計 GTD 這一段時，我真正想解決的其實不是功能豐富度，而是如何讓自然語言穩定地變成一筆可以被信任的資料。對我而言，日常的需求並不複雜，無非是新增一件事、查詢某段時間的任務，以及修改某一筆任務的狀態，因此我刻意把整個系統收斂成三個 Skill——create、query 與 update——並且讓它們全部只操作同一個資料來源，也就是 Todo Index。
整個待辦任務系統的靈魂：Todo index
Todo Index 本質上是一張結構化表格，每一列代表一筆承諾，而這張表就是整個系統的唯一事實來源。我不讓任何任務只存在於對話裡，也不讓 Agent 依賴上下文去「記住」事情，所有重要資訊都必須被寫入 Index，才能算真正存在。對話只是輸入方式，而不是記憶本身；AI 不是替我記住事情，而是幫我把事情寫進系統裡。當資料是真實存在、可被查詢、可被驗證、可被回溯的時候，這套系統才開始具有可依賴性。
Create-todo
在新增任務時，create-todo 的角色非常單純，它只負責把自然語言轉換成結構化欄位，例如抽出描述、解析時間並寫入對應欄位，而不負責替我判斷分類，也不會自動補齊我沒有說清楚的資訊。我寧願自動化少一點，也不要多一層推測，因為在任務管理系統中，合理猜測往往才是最大的風險來源。
Query-todo與Update-todo
真正容易出問題的，其實是更新。人在對話中習慣使用「剛剛那個」、「幫我延到下週」、「這個先不用做」這種高度語境化的表達方式，但如果系統被允許自行判斷我指的是哪一筆任務，只要錯一次，我就會開始懷疑整個系統。因此我強制規定，任何更新之前都必須先透過 query 找到候選清單，再由唯一識別碼進行精準修改，update-todo 只接受明確的 todo_id，不允許模糊更新。這樣的設計看起來保守，但它帶來的結果是行為可預期、資料可追蹤，而信任正是任務管理系統最核心的基礎。
外界的事實來源：Google Calendar
最後，我把 Google Calendar 當成資料入口，而不是另一套需要手動維護的系統，行程會被同步寫入 Todo Index，然後透過同一套查詢邏輯被拉出來，於是我每天只需要在同一個聊天視窗中詢問「我今天有哪些事」，而不再需要在多個工具之間來回切換。
這一段Google Calendar並不是蝦瞎貓的一部分，而是另外一段每天會自動的程式。
整體來說，這套待辦管理並沒有追求華麗功能，它真正做到的，是把 AI 從一個會幫我猜測的助理，降級成一個行為可預期的操作介面；當 AI 不再被期待替我做決定，而只是負責轉譯與執行規則時，我才開始願意把它納入我的記憶系統，而不是把它當成一個聊天玩具。
在這個段落中，其實有一個大坑：Openclaw本身並沒有「從聊天介面拉檔案」的能力，而Openclaw對Telegram的官方適配器甚至不接受5MB以上的檔案（我的錄音檔動輒就是50MB），在這邊我花了很大一段時間跟ChatGPT一起研究，最後成功在電腦上架設了Telegarm Local Server，並且跟官方適配器產生分工：Telegarm Local Server處理檔案、官方適配器處理文字溝通。
核心功能二：會議檔案的整理、產出與管理（錄音 → 逐字稿 → 摘要）
在這一段，其實包含三條彼此獨立、但可以互相整合的流程，而它們的共同核心，是所有檔案產出與狀態變動都必須被寫入 File Index 來管理路徑與狀態。也就是說，音檔、逐字稿與摘要並不是散落在資料夾中的檔案，而是被納入一個可以查詢與追蹤的資料系統。
將檔案下載到本機
第一段流程其實與 Agent 無關，而是由「上傳檔案」這個行為觸發的獨立程序。當我在聊天介面上傳音檔時，系統會自動將檔案拉到本機指定目錄，並同步在 File Index 中新增一筆資料，記錄檔案名稱、路徑與當前狀態。當下載完成後，程式會主動發送一則訊息到聊天視窗，告知我（也讓 Agent 知道）檔案已成功上傳，這讓整個流程在進入後續處理前就已經完成一次結構化落地。
產出逐字稿與摘要
接下來的兩個步驟，才是蝦瞎貓真正負責的 Skill。無論是語音轉文字，還是文字生成摘要，邏輯都刻意保持單純：接受指定的 file_id，產出對應檔案，更新 File Index 狀態，並輸出結果。逐字稿完成後會回傳檔案路徑，而摘要則會直接在對話中輸出重點，讓我快速檢視會議內容。
這樣的設計保留了高度彈性。我可以只上傳檔案而暫時不處理，也可以在上傳的同時就告訴蝦瞎貓：「檔案下載完成後幫我做成摘要。」因為每一步都是獨立 Skill，是否串接由我決定，而不是被固定流程綁住。
配套 Skill：管理與查詢檔案
為了讓整個系統可維護，我另外設計了幾個配套 Skill，專門處理 File Index 的管理與查詢：
update_file_index：用來更新檔案的狀態或補充相關資訊，例如事件類型或標籤。search_file：以檔案的相關資訊，找到符合條件的檔案名稱及id。query_file_by_id：根據唯一識別碼（id）精準取得某一個檔案中的內容。
這些 Skill 的存在，讓檔案系統不只是單向的產出流程，而是一個可以被回溯、檢索與持續使用的資料結構。
回頭看，這整段流程其實並不是在解決「語音轉文字」或「摘要品質」的問題，而是在建立一種可被信任的資料流。上傳只是觸發、Skill 只是執行，而真正重要的是每一步都被寫入 Index、被明確標記狀態、被保留為可再次操作的資料。當檔案不再只是聊天中的附件，而是系統中的一筆結構化紀錄時，我才開始覺得這不只是把 AI 接進工作流程，而是把工作流程本身重新設計過一次。
我現在的STT，採用的是Google提供的Speech_to_Text方案（畢竟免費的，很香）。我卻也必須說——轉錄結果慘不忍睹。但我發現一個有趣的互補：只要LLM具有足夠的推理跟補全能力，破碎的逐字稿也能有可用的摘要。當然，我後續還是會思考STT的優化方案。
小結
寫到這裡，其實我想分享的已經不是某幾個 Skill 做了什麼，而是我怎麼把 AI 放到一個「不會自作主張」的位置：它可以幫我把語句轉成操作、把資訊轉成結構、把流程變得更順，但它永遠不是事實本身。當我把資料落在 Index、把變動鎖在 Skill、把推測留在對話之外之後，我才第一次覺得自己不是在用一個很聰明的聊天機器人，而是在用一套可以被信任、可以持續演化的工作系統；接下來無論我要再加上每日整理、週回顧、甚至更進階的知識檢索或自動化提醒，我都不需要「祈禱它別做錯」，而只需要把規則補齊，然後讓蝦瞎貓照著規則去跑。
和蝦瞎貓合作一個禮拜後，我才真正意識到它已經成為工作的一部分。七天之內，todo_id 從 0 增長到一百多筆；那個數字其實不是壓力，而是一種可視化——原來我每天承接、承諾、決定的事情，比我以為的還要多。而當我可以成功把這些「記憶」外包，我也終於可以解放一部分的腦力，到更重要的事情上。
最後的最後，我有說過我會分享我的skill、文件跟程式碼
希望可以與大家交流！點>這邊<囉，這是一個Google drive，歡迎大家自由閱讀與取用。
本來想要用Github的......但算了，我沒那麼專業XD
CTA
我的所有文章都是我濃縮之後的心血，所有文章都是免費公開，
所以.....
如果你認同我的內容有所幫助，
歡迎在「方格子」或是「Linkedin」給我一個愛心or讚！
如果你認為我的內容可以幫助到更多人，
歡迎在各種管道進行分享！
如果你想要給我回饋或是有任何想法，
歡迎在「方格子」或是「Linkedin」留言告訴我！
這對我真的很重要！
