怎麼搭配不同 AI 工具建立日常工作流：知識、開發、日常三塊

現在的 AI 工具越來越多，最容易卡住的地方反而不是「哪一個模型最強」，而是每件事都想丟給同一個工具處理。查資料、寫程式、做簡報、整理錄音，表面上都可以叫 AI 幫忙，但背後需要的資料來源、輸出格式跟可靠度完全不同。

我的結論是：AI 工程師的日常工作流不用追求一套工具全包，先把任務拆成場景，再把工具放到對的位置。這篇整理我目前怎麼搭配 Multica、Claude Code、Codex 跟 Gemini，讓知識蒐集、開發、設計跟日常工作各自跑順；真正值得留下的知識，最後會進到 know.lumakes.com。

底層邏輯：先分場景，再選工具

我現在不會先問「哪個 AI 最好用」，而是先看這件事需要哪一種能力。固定重複的流程，交給能排程、分派角色、整理輸出的工具；要長期留下的知識，放進 Git、Markdown 跟 agent 都能操作的結構；寫程式就找能讀專案、改檔案的工具；生活資料則交給最懂日曆、郵件、雲端硬碟的工具。

拆開之後，這些工具就不用互相取代。Multica 管定時任務跟部署，Notion 做每日新聞工作檯，know.lumakes.com 放長期知識，Claude Code 做主要開發，Codex 給第二輪 Review，Gemini 則處理 Google 生態系跟多媒體任務。

全部都交給同一個 AI，看起來省事，但很容易變成萬用又不穩的入口。拆成多個場景後，每個工具只做自己最擅長的那段，整個流程反而穩。

知識蒐集

在 AI Toolbox 裡，我把知識蒐集拆成兩個工作檯：一個放長期知識，一個看每天進來的新聞。它們都在處理知識，只是節奏不一樣。

每天的新聞先進 Notion，讓我快速看、篩選、暫存；know.lumakes.com 則放我決定要留下的內容。Multica 不是其中一個工作檯，它在後面跑兩件事：定時把新聞送進 Notion，等知識網站內容累積到一定量後，再觸發部署。

知識網站、個人數位大腦網站

know.lumakes.com 是我現在的知識網站，也就是個人數位大腦網站。不是每一則新聞都會進來，只有我判斷值得留下、整理過後的內容才會放在這裡。

資料層維持在 Obsidian / Markdown，網站則把概念、MOC、最近 ingest 來源跟反向連結攤開。對我來說，這一層回答的是「留下來之後怎麼查、怎麼連、怎麼延伸」，不是「今天又發生什麼」。

每日新聞工作檯

Notion 在這裡是每日新聞工作檯。Multica 定時任務會把 AI 新聞、產品動態跟產業訊號整理進來，我再用資料庫跟瀏覽模式快速掃過。

這個工作檯不是要把每則新聞都變成長期知識，而是先把每天進來的內容放到一個看得到、篩得動、追得到的地方。新聞卡片會露出標題、Tags、摘要跟幾段判斷，我可以先掃一輪；真的有價值的，再往知識網站那邊整理。

執行細則：新聞先進每日工作檯

每日新聞這一段，我會讓 Multica 用定時任務處理。它依照我設定的方向整理 AI 新聞、產品更新跟我想追的產業訊號，再寫進 Notion 的新聞工作檯。

我真正要看的時候，不是從一張表格開始，而是用 Notion 的「瀏覽模式」跟「動態」版面配置先掃卡片。這樣可以快速知道每篇在講什麼、可能跟哪些 Tags 有關；有興趣的，再點進去看完整內容。

執行細則：知識再進個人數位大腦

新聞、文章或資料被我判斷值得留下後，才會進到知識網站這一層。這時候重點就不是「收集更多」，而是把內容整理成可以長期回查的 Markdown 筆記，補上概念連結、MOC、log 或反向連結。

這些內容不需要每次改一點就部署一次。我的做法是先累積到一定量，再從 Multica 觸發部署，讓 know.lumakes.com 更新。這樣 Notion 負責每天的瀏覽跟追蹤，知識網站負責長期保存，兩邊不會混在一起。

知識站背後的完整做法，我另外整理在 如何用 AI 做個人知識管理：我的 LLM Wiki 流程。這篇講工具分工；那篇則講內容進到知識庫後，怎麼被整理成可以長期查詢跟維護的結構。

軟體開發

在開發工作上，我採用 Claude Code 主力開發、Codex 輔助 Review 的混合策略。

這裡先講工具分工；如果你已經真的同時在跑 Claude Code 跟 Codex，帳號切換跟用量輪換我整理在 多帳號 Claude 跟 Codex 管理方式。

Claude Code

我目前主力使用的 AI 開發工具。在程式碼的表現上，Claude 的速度跟準確性是目前最均衡的選擇。主要使用場景包含：

• 程式碼撰寫：日常的功能開發、重構跟除錯都在 Claude Code 裡完成。
• 架構討論：在開始一個新功能之前，會先跟 Claude 討論架構跟實作方向。
• 文件生成：讓 Claude 根據程式碼自動產生技術文件跟 API 說明。

Codex

OpenAI 的 AI 開發工具，我主要拿它來做程式碼的 Review。工作流程是：

1. Claude Code 完成開發後，讓 Codex 去看這個分支上的所有修改。
2. 把 Codex 的模式開到最高思考層級，讓它完整看完差異後產出 Review 報告。
3. 把報告內容餵回 Claude Code 去修正。
4. 來回直到 Codex 的 Review 結果 OK，才推送到遠端。

這樣用兩個不同的 AI 互相檢查，程式碼的品質會比只靠單一模型好不少。

怎麼讓這套組合真的好用

工具搭配只是一半，另一半是提示詞的品質。同樣一個需求，寫得好跟寫得爛，出來的結果差距很大，後續花在除錯跟回修的時間也完全不同。從「先進 Plan Mode 再輸入」到「CLAUDE.md 怎麼寫才有效」，我整理在另一篇 我的 Claude Code 調教筆記 — 提示詞的日常技巧 裡，原則其實對 Codex、Cursor 這類工具也通用。

日常使用

日常生活中，我最常使用 Gemini，主要是因為它跟 Google 生態系的深度整合。

Gemini

語音轉文字（STT）

Gemini 可以處理錄音檔，直接把語音內容轉成文字並提煉重點大綱。這是目前 Claude 跟 ChatGPT 都還不太能做到的事情。我在會議結束後或錄完語音備忘錄時，會把錄音檔丟給 Gemini 整理成結構化的筆記。

Google 生態系操作

因為我的日曆、郵件、雲端硬碟都在 Google 生態系裡，Gemini 可以直接操作這些服務。像是建立行程、查詢排程、搜尋雲端文件等等，不需要切換不同的 App。

設計與簡報

Gemini 圖片生成

Gemini 的圖片生成效果很好，基於圖片的二次創作我會用它來處理。我在生成圖片時的技巧是：

• 先用 AI 分析圖片結構：在生成之前，先讓 AI 分析參考圖片的構圖、色調跟排版，產出文字描述。
• 視覺效果用文字敘述：背景、風格、氛圍這類元素先寫成文字，比直接丟圖片更容易控制方向；也可以先讓 AI 分析參考圖，再拿那段描述去生成。
• 只有需要保持現實的素材才提供圖片：例如 Logo、產品照片等必須還原的元素，才在生成時附上原始圖片，其餘都交給文字描述。

這樣做的好處是 AI 有足夠的創作空間，同時關鍵的視覺元素又能維持一致性。

Upscayl 圖片放大

生成的圖片如果解析度不夠，可以搭配 Upscayl 做 AI 放大，在不損失畫質的情況下提升解析度。詳細介紹可以參考 Mac 軟體・設計篇。

AI 簡報製作

用 AI 製作簡報時，我目前會根據需求使用三種不同的方式：

1. Canva — 模板化設計

最傳統也最容易編輯的方式。我會先用 AI 整理每個章節需要呈現的內容大綱，再到 Canva 裡套用模板完成設計。適合需要快速產出、後續還要反覆修改的場景。

2. AI 圖片生成 — 客製化風格

用 Gemini 之類的 AI 圖片生成工具，直接產出每一頁簡報的圖片。這種方式可以做到高度客製化的視覺風格，效果比模板好看很多，但缺點是產出的是圖片，後續要修改文字或內容比較困難。

3. AI 簡報網頁 — 兼顧美觀與可編輯

直接請 AI 生成 16:9 的簡報網頁。跟圖片生成一樣可以做到客製化的視覺效果，但因為是網頁，修改文字、內容跟樣式都變得更簡單可控。唯一需要多處理的是網頁轉成 PDF 這一段，如果最後需要交付文件的話。

三種方式的比較

我的流程通常是兩步驟：先讓 AI 分析文件整理大綱，再用大綱生成簡報（同時定義風格）。以下是提示詞範例：

步驟一：分析文件，整理簡報大綱

請分析以下文件內容，整理成簡報大綱。
每一頁列出：
1. 頁面標題
2. 核心訊息（一句話）
3. 需要呈現的重點（3-5 個）
4. 建議搭配的視覺元素（圖表、圖片、icon 等）

文件內容：
（貼上文件）

步驟二 — Canva：用大綱到 Canva 套模板製作

拿到大綱後直接到 Canva 裡依照每頁的內容套用模板完成設計。

步驟二 — AI 圖片生成：大綱轉簡報圖片

根據以下大綱，逐頁生成 16:9 的簡報頁面圖片：
- 視覺風格：簡約、深色背景、白色文字、圓角卡片排版
- 字體風格：現代無襯線體
- 配色：以___為主色調

大綱：
（貼上步驟一的結果）

步驟二 — AI 簡報網頁：大綱轉互動網頁

根據以下大綱，生成一個 16:9 的簡報網頁（HTML）：
- 使用全螢幕切換的方式呈現每一頁
- 支援鍵盤左右鍵換頁
- 視覺風格：___

大綱：
（貼上步驟一的結果）

工具搭配總覽