近期我在開發生成式照護機器人的過程中，「Agentic AI」這個詞開始頻繁出現在各需求單位的討論。只是談得越多，我反而越擔心，因為不同角色對它的期待落差很大。有人希望它能自動做出決策，有人則只是把它視為更聰明的助理工具。如果只是停留在名詞層次，很難判斷這樣的技術究竟適不適合真正進入產品開發流程，更遑論落地在高度受限的醫療場域。
在我的理解中，所謂的 Agentic AI 並不是指某一個特定模型或新名詞，而是一種工作方式的轉變。它不再只是被動回應指令，而是在給定目標與限制條件後，能自行規劃行動、拆解任務，並在執行過程中不斷修正路徑。這類系統通常具備狀態感知、任務規劃，與自我修正的能力，能長時間維持上下文，而不是每一次都從零開始產生答案。也正因為這樣，它的表現高度依賴使用者所提供的背景資訊與邊界設定，一旦脈絡不清，就很容易過度延伸，甚至產生錯誤的行為。
基於這樣的特性，我覺得光靠聽別人的經驗分享，或是網路上的文章跟影片，無法真正理解 Agentic AI 的能跟不能。於是我選擇從自己最熟悉、但早被時間跟忙碌給擱置的舊專案下手，透過實際操作來觀察，當 AI 被賦予更多主動權後，整個開發流程會發生什麼樣的改變，又在哪些地方仍然必須由人工來介入跟收斂。
我刻意挑選了兩種性質不同的專案來做實驗。一個是十三年前我用 Objective-C 開發，後來在十年前因平台政策變更而下架的攝影教學 App；另一個則是我個人網站中，之前仰賴 Flash 呈現，目前已經無法正常運作的後台數據統計功能。這些專案都有完整的歷史脈絡，也存在明確的功能目標，非常適合用來實作跟觀察 Agentic AI 在實際工程情境中的行為。整個過程中，我並沒有親自動手改寫程式碼，而是嘗試把規劃、實作，與修正都交給 AI，我退到測試跟判斷的角色。這樣的嘗試，讓我對於人與 AI 的分工有了更具體的理解，也成為這篇文章整理與分享的起點。
在實作部分，我並沒有一開始就把指令丟給執行環境，而是刻意把「思考」與「執行」拆成兩個階段。我先在 Gemini 中說明專案背景、改寫目標與限制條件，讓模型協助我調整提示詞的結構，直到我確認這段描述已經足夠清楚，才將它轉貼到 Antigravity，作為正式的執行指令。這樣的流程，看似多了一道工，實際上卻能有效降低後續修正成本，避免 AI 在一開始就走偏方向。
真正讓輸出開始穩定的關鍵，不在於模型本身，而在於是否提供了可依循的工作框架。我會要求 AI 先產出完整的實作計畫，說明它打算如何理解現有程式、如何拆解工作項目，以及各階段的處理順序。接著再把這些內容轉化為明確的任務描述與操作步驟，讓 AI 在執行時有一致的參考依據。這些文件的存在，讓 AI 不必每一次都重新「猜測」專案全貌，也避免在不同回合中出現自我矛盾的決策。
當這套結構建立起來之後，AI 的行為會明顯收斂。它不再隨意延伸功能，也較少在細節上過度發揮，而是專注完成既定目標。對我而言，這其實是在替 AI 建立一種工作慣性。只要上下文一致、任務邊界清楚，它就能在長時間的執行過程中維持相對穩定的產出品質，也讓 Token 的消耗用在真正有價值的地方。
在這樣的開發流程中，我並沒有完全離開 Coding 的現場。相反地，我仍然需要安裝 Xcode、執行模擬器、實際跑起 App，親自確認功能是否符合預期，只是我沒有親自去寫程式碼。Agentic AI 並不是不會出錯，它其實非常容易出錯，尤其是在跨語言遷移、舊架構重構或狀態管理這類複雜場景中，Bug 頻繁的出現是必然的結果。差別只在於，這些錯誤不再是我一行一行碼出來的，而是由 AI 在執行過程中所產生。
也因為如此，我在整個流程中扮演的角色，更接近一個導師或審稿者。我需要指出問題發生的位置，說明錯誤的行為與實際需求之間的落差，並用足夠精確的語言告訴 AI 該如何修正。這並不是一句「這裡有 Bug」就能解決的事，而是要回到功能目的、執行條件與使用情境，重新建立 AI 的理解。當提示給得越清楚，AI 修正的品質才會越接近可用狀態。
這段過程，是整個實驗中最耗費心力與時間的地方。AI 的開發並不是即時的，它需要時間執行，我也必須等待結果產出，然後再次測試、回饋、修正。這種來回循環，與傳統開發相比，節奏並沒有變得更快，反而更考驗耐心。唯一不同的是，我投入的不是重複性的實作，而是持續的判斷與引導。這樣的工作方式，讓我更清楚意識到，Agentic AI 並沒有減少人的責任，而是把責任集中在最難被自動化的那一段。
在這樣高頻率的互動過程中，Token 很快就成為一個無法忽視的現實問題。這次實驗裡，我前後切換了三個帳號，其中兩個是付費的 Pro 帳號，但密集使用之下，模型額度仍然很快被消耗完畢。這讓我很清楚意識到，Agentic AI 並不是一個可以無限制試錯的環境，越是模糊、反覆、缺乏收斂的提示詞，消耗的資源就越驚人，而這些成本最終都會回到實際預算上。
因此在排錯時我刻意改變過往直覺式的回饋方式。我不再丟出整段錯誤描述，也避免重新貼上完整程式碼，而是先確認錯誤發生的條件、影響範圍與預期行為，然後只針對必要的段落給出修正指引（這就很吃使用者的經驗跟技術能力）。這樣做的目的很單純，就是減少 AI 在無關內容上的理解成本。當提示詞越精準，AI 的修正幅度就越小，Token 也不會被浪費在重新解讀整個專案上。
另一個很現實的限制來自雲端模型本身。當文本長度過高，或需要同時處理大量內容時，雲端 LLM 很容易遇到上下文截斷或品質不穩定的問題。因此在處理整本攝影書英文化的過程中，我部分使用地端的 LLM 來執行，並將可用 Token 上限開到 262,144（使用 LM Studio 透過 API 來呼叫）。這樣的設定，才能在同一輪處理中，同時保留完整文章內容、原始程式碼，以及頁面結構資訊，確保翻譯後的呈現不會跑版。
這些經驗讓我對 Agentic AI 的使用邊界有了更清楚的認知。它確實能大幅改變工作方式，但前提是清楚理解它的限制，並在不同任務之間做出合適的工具選擇。用最小的資源換取可控的成果，遠比一味追求自動化來得實際。
最終我順利完成了 App 與網站後台統計圖表的重構。App 在聖誕假期時已提交 App Store，正等待審核。而原本早已失效的網站後台圖片顯示功能，也已恢復正常運作。回頭看整個過程，我實際投入的開發工時不到三個工作天，其餘時間幾乎都在等待 AI 持續運作（AI 作業的時間累計約五個工作天，兩個專案的啟動到結束大概七天）。這個時間跨度，和過去形成了極為強烈的對比。無論是 App 的開發，還是攝影書籍的撰寫、圖片整理與排版，我過去實際花了兩年的時間，才完成那些作品。
當然這次的成果是建立在既有專案的基礎之上，並不是從零開始。但即便如此，我原先對程式改寫的保守預估，也至少需要兩個月以上的開發時間，還不包含遷移過程中，我得重新學習新技術所付出的成本。更現實的是，過去我往往需要前端設計協助版面調整，也需要家人幫忙校稿與檢視細節；而這一次，所有輔助角色，都由 AI 補上了。
這樣的實驗，讓我得以站在相對安全的立場，冷靜觀察 Agentic AI 的能與不能，也重新思考它該如何融入我目前正在開發的產品中。它並不適合被當成萬能解法，但在角色分工清楚的前提下，確實能大幅改寫工作節奏。對我而言，這篇文章不單純是成果展示，而是一段理解過程的整理，替我接下來的產品設計跟決策，留下可供檢視的參考標的。隨著技術不斷的演變跟提升，之後的程式開發肯定會以另一種全新的面貌呈現，這是你我不能輕易忽視的演變與趨勢。
回應管理, Pingbacks:
這篇文章還沒有 回應管理/Pingbacks ...
