從聊天到工作流
近半年，我花了不少時間，在不同的 AI Agent 工具裡反覆折騰。
一開始的念頭很單純，一方面是工作上的需求，另一方面我想知道，Agentic AI 這些被稱為下一代工作革命的東西，到底是真正能幫研發團隊分攤工作，還是另一波被媒體包裝得很漂亮的新玩具。
三年半以前，我主要透過 LLM 的 Chat，或是 GitHub Copilot 來協助開發。當時主要的 IDE是 VSCode，工作方式也很直覺：我問問題，AI 回答；我寫程式，用 tab 補全；遇到 bug，我將錯誤訊息輸入，由 AI 推測原因。那時候的 AI像顧問，或是一個很懂語法的自動完成器。它可以提高速度，但真正決定工作如何展開的人還是我自己。
後來開始使用 Cursor、Windsurf，情況就有些變化了。AI 不再只是回答問題，而是開始處理整個專案脈絡。它會讀檔案、理解 repo、跨檔案修改，也可以承接較完整的功能開發。這時明顯感覺到，提示工程正在變成另一種東西。過去我們在意的是 prompt 寫得好不好，現在更重要的是任務是否被拆解清楚、上下文是否乾淨、驗收條件是否明確。
而從 Antigravity 推出之後，我就改用 Antigravity 來開發。同時我也混用了 Codex、Claude Code、Claude Cowork 等 coding agent。到這個階段，我已經很難只用「哪個工具比較強」來形容它們。它們比較像不同性格、不同工作習慣的工程師。問題不只是能力，而是我們要把什麼工作交給誰，以及怎麼讓它照著我們的期待前進。
Antigravity 的規劃感
Antigravity 很像一位習慣先把白板規劃好的人。接到工作需求之後，它通常不會立刻動手，而是先拆解問題、安排步驟、建立 task list，然後才往下執行。很多時候，它會停下來，需要我確認下一步。剛開始我覺得這樣有點慢，因為使用工具時，總會希望它愈快愈好，最好一句話，就能讓 AI 將整件事完成。
但真正把複雜任務交給它之後，這種需要我確認的節奏反而重要。當任務不只是問答，而是包含下載資料、閱讀論文、整理摘要、翻譯、建立文件，甚至跨 browser 與 terminal 操作時，AI 若沒有節制地一路往前衝，其實很容易偏離原本的目標，重點是 token 的消耗都要錢。
最早我曾讓它處理十五篇專業論文的工作流程。從下載、抽取內容、摘要、翻譯，到最後輸出整理過的文件，那種感覺很奇妙。它不只是執行而已，它會規劃，而這個能力很重要。真正的大型任務，會失敗往往不是模型看不懂，而是作業流程在某個地方開始偏掉，接著 token、上下文、檔案與工具呼叫混在一起變得難以控管。
對齊不只是一個好 prompt
我現在喜歡用「對齊」來說明我使用 AI 開發的方式。這裡說的對齊，不只是把 prompt 寫得漂亮，而是讓 AI 知道任務的方向、邊界、格式、停止條件，以及什麼事情需要跟我確認。
以前談提示工程時，很多重點放在角色設定、語氣、範例與輸出格式。這些當然還是有用，但 Agent 能做的事情變多之後，溝通方式也必須跟著改變。我會更明確地告訴它：先讀資料，不急著改；先提出計畫，不急著執行；遇到成本、權限、不可逆操作、或需要價值判斷的地方，要停下來；輸出之後，要用我指定的角度檢查，而不是只給一份看似完整的結果。而這些過程，我會混著雲地模型來使用，部分工作我先進行處理，才讓它接手後續作業。
這也是我現在使用 AI 的核心變化。它不再只是回答者，而是可以執行複雜任務的協作者。既然它會執行，就必須有工作準則；既然它會消耗 token，就須要有成本意識；既然它會接觸檔案與工具，就必須有邊界。不然它雖然會工作，但也同樣會製造難以收拾的災難。
OpenClaw、Codex 與混合式工作模式
相較於 Antigravity，OpenClaw 的世界又是另一種風景。如果說 Antigravity 像一位習慣規劃的工程師，那 OpenClaw 更像把一整座工廠交到我們手上。我們可以自由配置模型、接 Telegram、串 LINE、建立 workflow、調整 memory、設計 sub-agent，甚至連整套系統都能架在自己的設備裡。除了有很多 Skill 可以直接下載使用，也可以自己開發 Skill。同時可以將不同主機上的 OpenClaw 組成一個團隊，我是透過 Gateway（WebSocket）進行健康檢查與連通測試，然後利用一個 Telegram 群組跟規則化協作，讓不同的 OpenClaw 來處理工作任務。
初次將本地模型接上 Telegram，讓 AI Agent 可以透過即時訊息開始工作時，會突然有一種「這東西好像活起來了」的錯覺。但自由度愈高，相對的問題也愈多。有時候是 workflow 卡住，有時候是 tool calling 漂移，更多時候是任務繞進重複流程裡出不來。使用這類框架，有太多事情需要使用者自己處理。
我目前有一些資料自動化蒐集與功能測試放在 OpenClaw 上執行。包含本地部署的 Qwen3.5-35B-A3B 4bit，透過 Mac 上的 oMLX 推論服務呼叫，再由 Telegram 當作遠端控制入口。主模型、搜尋模型、本地模型、小型 embedding 與翻譯模型會依任務分工。有些簡單任務，我會交給小模型或 translategemma-4b 這類模型處理，避免所有事情都丟給雲端高價模型。
Codex 則是另一條完全不同的路線。它給我的感覺，最像工程化之後的 AI Agent。它不是單純的聊天工具，而是試圖直接進入 software engineering workflow。從 CLI、IDE、GitHub、background task，到 review、sandbox、approval policy，整套思維都很接近真正的開發流程。而最近的一版還可以透過手機來控制電腦上的 Codex，我都開玩笑說最近我跟 AI 溝通已經超過跟人溝通了。太太還提醒我要注意跟 AI 協作的時間感，因為太過投入往往會忘了時間。
Claude Code 與 Claude Cowork，或其他付費模型，我更多時候拿來做對照、長文脈絡整理、設計另一種解法，或是在需要第二意見時使用（例 Code Review）。這些工具各有特性，也讓我愈來愈不想把問題簡化成哪一套最強。更實際的問題是：這個任務需要規劃、需要執行、需要文件化、需要進 repo，還是需要自動化排程？不同工具適合的位置並不一樣。
Token 也是工程問題
模型是有價的。即使現在已經有地端模型可以使用，地端模型也需要等級夠高的算力設備才跑得動。以我自己的電腦來說，最多安裝 35B 左右的模型已經是極限，再往上就不太實際。
因此我最近也在研究如何有效運用 token。能在本地完成的前處理，例如資料清洗、初步分類、翻譯、embedding、格式轉換，就不一定要全部交給雲端模型。真正需要高階推理、規劃、跨資料判斷與最後文字品質的地方，再交給能力較強的雲端模型。這種雲地整合不是為了追求技術名詞，而是讓成本、速度與品質取得平衡。
以我目前部分自動化排程任務來看，一天額外付費（透過 API 使用）的雲端模型成本大約可以控制在 0.2 美元上下。這不是什麼驚人的優化，但它提醒我一件事：當 AI Agent 從問答工具變成工作系統之後，token 就不只是帳單，而是架構設計的一部分。
Harness Engineering 的意義
最近常聽到 Harness Engineering 這個詞。第一次聽到時，我其實覺得有點像矽谷會出現的典型名詞。但對 AI Agent 來說，它形容得非常精準。Harness 本來就有安全帶、控制裝置的意思。不是把馬換掉，而是讓馬能被穩定地運作；對 AI 來說也是如此。
AI Agent 真正困難的地方，並不是只讓它動起來，而是它執行出錯時，能不能知道卡在哪裡，能不能停下來，能不能修正，能不能回到一個可理解的狀態。多數包裝出來的 AI 使用場景看起來流暢、聰明、反應迅速。但實際進入真實工作，很快就會發現，真正消耗時間的往往不是 prompt，而是 debugging。這些問題繞了一圈，其實又回到傳統軟體工程的議題：流程、觀測、回滾、測試、權限與責任邊界。
某種程度上，AI Agent 很像 DevOps 剛開始普及時的狀態。大家一開始都在比功能，比誰的畫面漂亮、誰的自動化比較炫。可真正進入企業或長期工作流程之後，留下來的往往是那些能追蹤、能驗證、能回復、能穩定運作的系統。AI 也是一樣。真正的差距，最後不會只有模型，而是 workflow。
我實際拿它做了什麼
這半年，我讓 AI 做的事情其實不只寫程式。比較日常的，是資料蒐集與彙整。例如每天把我需要的新聞依我定義的格式整理好，不只是摘要，而是依照我個人的角度拆成背景、影響、可能的行動與後續追蹤。這種工作若只是普通摘要，很快就會變成資訊垃圾；但如果格式與判斷準則先對齊，它就能變成我需要的情報流程。
我也讓它幫我閱讀論文。論文摘要最容易做成看起來很工整、但其實沒有幫助的東西，所以我通常會要求它用我的問題意識來讀：這篇研究真正的貢獻是什麼？跟我正在看的議題有什麼關係？方法上的限制在哪裡？如果我要把它轉成簡報、規格或實作方向，應該抓哪些重點？
至於簡報、文件、規格書、流程圖，這些我原本就已經透過 AI 在作業。差別是模型愈來愈聰明之後，成果的上限也被往上推。以前我常需要把 AI 的初稿大幅重修，現在比較像是在管理一個可以快速產出草稿、再與我來回收斂的工作流程。我的角色沒有消失，只是從逐字產出，慢慢移到定義方向、校正判斷、決定取捨。
五個實作案例
為了讓這些經驗不要只停留在抽象描述，我整理了近期幾個實作。它們有些是網站，有些是 Skill，有些是文件與流程，但共同點是：過去都不是不能做，而是很容易因為時間成本太高，最後只停在想法階段。
01｜人像街拍行前計劃書
第一個案例，是我為人像街拍預先規劃的行前計劃書。我把拍攝地點、現場動線、光線、構圖、器材與注意事項整理成網頁版本，一方面留下記錄，另一方面也想測試 AI 輔助開發可以做到什麼程度。這個專案有意思的地方，是它不是單純做一個漂亮頁面，而是把拍攝前的思考變成可以分享、檢查與溝通的結構。
02｜人像街拍 Model 招募網站
第二個案例，是用來招募人像街拍 Model 的網頁。過去我的作品以風景、人文、旅遊為主，人像作品並不多。若只是貼幾張照片或寫一段徵求說明，未必能讓對方理解我想創作的風格。因此我希望透過較完整的專業包裝，讓招募本身也成為一種提案：我想拍什麼、怎麼合作、希望遇到什麼樣的共同創作者。
03｜個人履歷介紹頁
第三個案例，是我的個人履歷介紹頁。原本這些資料整理在 Notion 裡，後來我還是覺得放在自己的網域比較一致。這個頁面特別的地方，是它不是一般履歷模板，而是用我個人攝影愛好的元素來包裝職涯敘事。履歷不只是工作經歷清單，也是一種個人品牌的呈現方式。
04｜Digital Duncan 攝影 Skill
第四個案例，是我部署在 OpenClaw 服務裡的 Skill。我把它想成一個數位的我，至少在攝影觀念上，它要能接近我的判斷方式。只要我透過 Telegram 選一張自己拍攝的照片，再提供地點與簡單描述，系統就會解析這張照片，並以我的攝影知識寫出一篇文案。
這個 Skill 對我來說，不只是自動產生社群貼文，而是研究如何打造數位孿生人格。也就是說，AI 不只是替我寫字，而是能不能把我的觀察方式、審美偏好、語氣與發布流程，變成一套可反覆執行的工作方法。而它有很多技術需要克服，需要建立一個知識索引，來源是我自己發行的攝影工具書。另外透過 VLM 讀取照片時，解析需要能處理物件、關係、構圖、光影、色彩、空間層次與觀看路徑，這些條件出來後才以向量模式取取出對應的知識，而內部思考材料，不直接暴露在最終文案。因此儘管是透過 AI 輔助開發，也研究了一整個月，下班跟假日都不斷在開發與測試。
05｜Lydia 個人學術網站
第五個案例，是我幫太太製作的個人網站。二十年前我曾經幫她做過一套系統，但後來沒有時間維護，十多年前已經失效。這次趁著母親節重新打造了一個支援多語系的新版本，也加入關聯圖的概念，用來呈現研究、出版、教學與合作脈絡。
如果完全自己開發，這類互動與多語系結構肯定會花上不少時間。AI 在這裡的價值，不只是幫忙寫程式，而是協助把內容架構、語系切換、互動設計、規格文件與驗收流程一起推進。而這邊困難的點，是要如何讓 AI 知道我想呈現的風格跟效果是什麼？這其實跟團隊協作一樣，只是原本對接的人，現在改成了 AI。
不是選邊站，而是建立工作型態
使用各種工具到現在，我發現自己其實沒有選邊站，反而慢慢形成一種混合式工作模式，而 AI 技術迭代很快，隨時都會有更好用的服務出現。目前在高價值規劃與複雜判斷，同時需要看原始程式碼時，我會交給 Antigravity。大量重複性任務、自架 Skill 與自動化整合，我會使用 OpenClaw。真正進入 repo、CI/CD、工程流程的部分，則交給 Codex。而本地模型比較像整套系統裡負責搬運、整理與執行的 worker。
這樣的組合，說來有點像一間逐漸成形的數位公司或團隊。有規劃的人、有執行的人、有維持系統運作的人，也有負責整理資料與草稿的人。而我處於中間，決定方向、調整分工、設定準則、檢查結果。
所以我現在愈來愈覺得，我們正在做的事，也許已經不只是「使用 AI」。而是在開始學著，如何管理另一種新的工作型態。AI Agent 困難的地方，不是讓它變得更主動，而是當它愈來愈主動時，我們要有能力讓它與我們的目標、方法與價值判斷對齊。
回應管理, Pingbacks:
這篇文章還沒有 回應管理/Pingbacks ...
讀者回應:
