我從問 AI 問題，到開始把事情交給 AI 做
最近兩年，我使用 AI 的方式有一個很明顯的變化。一開始，我幾乎都在問問題：這個 Linux 指令怎麼下、這段程式哪裡錯、這個 SEO 概念怎麼理解、這篇文章可以怎麼整理。那時候 AI 對我來說，比較像一個更快、更會整理脈絡的搜尋引擎。後來真正改變我的，不是回答變得更完整，而是我開始把一小段工作交出去。這個差異比工具名稱重要。問 ChatGPT 時，我還是工作流程的唯一執行者；開始使用 AI Agent 之後，我要做的事變成定義目標、設定邊界、提供上下文、檢查結果，然後讓它在一定範圍內自己往前跑。
這件事對管理的啟發很直接，AI Agent 的差異不是工具能力，而是人必須重新定義任務、邊界、驗收與責任。AI 最早改變的是搜尋，現在開始改變的是工作。
一開始，我只是把 AI 當成比較快的搜尋
我最早使用 ChatGPT 的方式很直覺，就是問問題。以前遇到 Linux 指令不熟，我會搜尋好幾篇文章，交叉比對參數，最後再試著下指令。後來我會直接問：我要找出某個資料夾底下包含特定字串的檔案，應該怎麼做？它通常可以很快給出 `grep`、`find`、`rg` 之類的方向。這個階段的價值很明確：節省查資料的時間。它幫我縮短從「不知道」到「知道可能怎麼做」的距離，但工作本身仍然完全在我身上。我必須判斷指令是否安全、參數是否正確、要不要真的執行，也要自己處理結果。
這種使用方式很像搜尋的進化版。Google 讓我找到資訊，ChatGPT 讓我更快理解資訊。可是它還沒有真正接手工作，它只是讓我比較快進入工作。
真正的變化，是我開始把工作交出去
後來在開發系統時，我開始感受到另一種模式。不是問「這段程式怎麼寫」，而是描述一個任務：請檢查這個頁面的資料來源、找出欄位對應問題、修改程式、跑測試，最後告訴我改了什麼。這時候 AI 不只是回答，它開始在一個工作環境裡讀檔、改檔、執行指令、驗證結果。OpenAI 在 Codex 的介紹中提到，Codex 可以在獨立環境中處理 coding task，包含讀寫檔案、執行測試、修 bug，並把結果交給人審查。這個描述之所以重要，不是因為 Codex 是某個新工具，而是它把 AI 從「回答問題」推進到「處理任務」。
我自己的使用經驗也很接近這個變化。以前我問 AI：「Astro 裡這個 component 怎麼寫？」現在我會說：「請依照目前專案架構，新增這個內容頁，保持現有 URL 規則，不要動 published content，完成後確認 build。」前者是在問知識，後者是在委派工作。
Linux 指令查詢：從問答案到請它協助判斷
Linux 指令是一個很小但很清楚的例子。以前我會問某個指令怎麼下，得到答案之後自己執行。現在我比較常把目標和限制一起交代清楚，例如要搜尋哪些目錄、哪些檔案不能碰、是否只能讀取不能修改、輸出要怎麼整理。差別不在於 AI 會不會 `rg` 或 `find`，而在於它是否理解工作邊界。搜尋檔案可以直接做；如果涉及刪除、搬移、覆寫，就必須先停下來確認。這其實很接近我平常管理專案時的要求：不是每個人都只需要知道怎麼做，更重要的是知道什麼時候不能直接做。
所以我後來不再只看 AI 能不能給出漂亮答案，而是看它能不能在限制條件下完成任務。這才是 Agent 的核心能力。
程式開發：從片段建議到完整修改
程式開發讓這個差異更明顯。問答式 AI 很適合解釋語法、產生範例、指出錯誤方向，但真正的開發工作通常不是單點問題。它會牽涉到既有架構、命名慣例、資料來源、型別、測試、建置流程，以及不能破壞的功能。當我把 AI 用在 tigerlee.cc 的開發時，我不是只問「這個功能怎麼做」，而是讓它先讀專案，理解目前的 Astro、TypeScript、PostgreSQL CMS、blog route、topic page、SEO metadata，再依照現有架構修改。這和單純請 ChatGPT 產生一段程式碼完全不同。
單純問問題時，AI 的回答可以是抽象的、通用的、看起來合理的。委派工作時，它必須面對真實系統。真實系統裡有歷史決策、有資料庫欄位、有既有 URL、有不能亂改的內容生命周期。這些限制會讓工作變難，但也讓 AI 的價值變得更具體。
tigerlee.cc：從想法到一個真的跑起來的 Blog 系統
tigerlee.cc 這個網站本身就是我感受到變化的案例。它不是只有幾個靜態頁面，而是逐步長成一個個人品牌網站、Blog 文章平台、PostgreSQL CMS，以及 SEO、GEO、AIO 友善的內容系統。如果只把 AI 當成問答工具，我可能會問：個人品牌網站要有哪些頁面？Blog 架構怎麼設計？SEO metadata 怎麼寫？這些問題都有價值，但它們還停留在討論層次。真正讓網站從 0 到有的，是把任務拆成一段一段可以執行的工作：建立首頁資訊架構、整理 Blog Archive、設計 topic hub、接上 CMS、處理 sitemap、補上 llms.txt、調整文章頁結構化資料。
其中一個很具體的取捨，是我一直要求保留既有 URL，並且不要任意修改 published content。從工程角度看，改檔名、改 slug、重新整理內容位置也許很快；但從個人品牌、SEO 和內容資產角度看，URL 是外部引用、搜尋收錄與內容權重的入口。這不是技術能不能做的問題，而是能不能承擔後果的問題。這也是為什麼我在委派 tigerlee.cc 的工作時，會先把內容生命周期、topic 分類、CMS 欄位、SEO 規則和不可修改範圍寫清楚。AI Agent 的價值在於，它可以在我定義好方向之後，把很多原本需要我手動處理的工程細節往前推進；但方向與取捨仍然必須由我負責。
這讓我對「效率」有了比較務實的理解。AI Agent 不是讓工作消失，而是讓工作重心移動。過去我花很多時間在查資料、重複修改、整理格式、比對檔案；現在我花更多時間在定義問題、檢查結果、修正邊界和建立流程。
AI Agent 和 ChatGPT 問答最大的差別
如果要用一句話說明，ChatGPT 問答解決的是「我不知道什麼」，AI Agent 解決的是「這件事能不能被推進」。
問答的核心是資訊交換。你問一個問題，AI 回答，接著你自己判斷下一步。Agent 的核心是任務推進。你給它目標、上下文、工具和限制，它在一定範圍內計畫、執行、回報，必要時再請你決策。OpenAI 的 Agents SDK 文件把 agent 描述為帶有 instructions 和 tools 的 LLM，並提到 agent loop 會處理工具呼叫、把結果送回模型，持續到任務完成。這個說法和我的實際感受一致：Agent 不是更會聊天的 chatbot，而是被放進工作流程裡的執行單位。
但這也代表使用者的責任變重了。以前問問題，問題問得不好，最多得到一個不準確的回答。現在委派工作，如果目標不清楚、權限沒有限制、驗收標準沒寫清楚，就可能得到一個方向錯誤但執行得很認真的結果。這不是工具問題，而是管理問題。
Skills 和 Workflows 讓委派變得可重複
我後來開始建立自己的 Skill Library 和 Workflow，不是因為想把提示詞寫得更複雜，而是因為我發現同樣的工作規則一直在重複出現。文章怎麼寫、SEO 分析怎麼做、topic cluster 怎麼拆、開發任務要先讀哪些檔案、哪些內容不能修改，這些其實都是工作方法，不應該每次靠臨場提醒。
有幾次我把任務交出去之後，結果方向並沒有錯，但格式、判斷順序或輸出邊界不夠穩定。後來我才意識到，問題不在於單次 prompt 寫得不夠長，而是我沒有把「我怎麼做這件事」變成可重複使用的規則。Anthropic 在 Claude Code 的 Skills 文件中提到，當你反覆貼上相同指示、checklist 或多步驟程序時，就適合建立 skill。這點很接近我自己的經驗。Skill 的價值不是讓 AI 變聰明，而是把我的工作規則固定下來，讓每次委派都有比較一致的起點。
Workflow 則是另一層。Skill 比較像工作規則，Workflow 比較像工作順序。例如文章生產不是只寫正文，還包含主題判斷、內容結構、官方佐證、FAQ、CMS 欄位、internal link 和 cover concept。這些步驟如果每次都靠臨場交代，結果就很難穩定。
所以我現在看 AI Agent，不會只看模型能力，也會看它能不能吃進我的工作方法。沒有 Skills 和 Workflows，很多委派只是一次性的 prompt；有了 Skills 和 Workflows，委派才開始變成可複製的生產方式。
SEO 分析讓我更理解 Agent 的工作邊界
SEO 是另一個很好的例子。以前做 SEO，常見工作包括搜尋意圖分析、競品頁面觀察、標題調整、meta description、FAQ、internal link、topic cluster。這些工作有些需要判斷，有些需要整理，有些需要大量重複比對。
AI 很適合協助後面兩種，但不能取代前面的策略判斷。以 tigerlee.cc 來說，我可以請 AI 協助盤點 AI Agent topic 下面有哪些文章、哪些 cluster 還缺內容、哪些文章需要互相連結、FAQ 是否符合搜尋意圖。但網站要建立什麼權威、主題要怎麼定位、哪些觀點符合 Tiger Lee 的專業形象，這些仍然必須由我決定。
這也是我不喜歡把 AI Agent 講成「自動化一切」的原因。真正有效的 Agent，不是無限制自動化，而是在清楚邊界裡自動推進。SEO 分析如此，內容策略如此，系統開發也是如此。
這件事對管理的啟發
從管理角度看，AI Agent 帶來的變化很有意思。它不是單純多了一個工具，而是多了一種新的工作分工。以前管理者主要管理人的目標、進度、品質和風險；現在如果團隊開始使用 Agent，也要管理 Agent 的目標、上下文、權限和驗收。這件事看起來像技術問題，其實更像管理問題。你不能只說「幫我把網站 SEO 做好」，就期待 Agent 自動理解品牌定位、內容策略、資料庫限制和發布流程。你要把任務拆清楚，把不能做的事寫清楚，把完成標準定清楚，最後還要有人負責審查。
所以 AI Agent 不會讓管理消失，反而讓管理的要求更具體。模糊的指令在人的團隊裡會造成誤解，在 Agent 工作裡也一樣。只是 Agent 可能執行得更快，所以錯誤也可能更快被放大。
AI 最早改變的是搜尋，現在開始改變的是工作
回頭看這兩年的使用變化，我覺得最重要的不是哪個工具更新了，也不是哪個模型能力更強，而是我的工作方式已經被改變。一開始，我問 AI 問題，是為了更快得到答案。後來，我把工作交給 AI，是為了讓一段流程能夠被推進。這中間的差異，就是從搜尋到工作，從回答到執行，從 prompt 到 workflow。但我也越來越確定，AI Agent 的價值不在於取代人的判斷。它真正有價值的地方，是把人的判斷變成更清楚的任務、規則和流程，然後在這些邊界裡加速執行。
所以如果有人問我，AI Agent 和單純使用 ChatGPT 問問題有什麼差別，我會這樣回答：問 ChatGPT，是把問題丟給 AI；使用 AI Agent，是把一段工作交給 AI。但前提是，你要先知道自己真正要完成的是什麼。
FAQ
AI Agent 和 ChatGPT 問答有什麼不同？
ChatGPT 問答主要是在回答問題，使用者仍然自己執行下一步。AI Agent 則是在明確目標、工具、上下文與限制下，協助推進一段多步驟工作，例如讀檔、改檔、執行指令、整理結果或等待人類確認。
AI Agent 是不是就是比較強的 ChatGPT？
不是。模型能力當然重要，但 AI Agent 的差別不只在回答品質，而在它能否進入工作流程。它需要工具、狀態、權限、任務邊界和驗收標準，否則只是更會回答的聊天工具。
什麼工作適合交給 AI Agent？
適合交給 AI Agent 的工作通常有明確目標、可拆步驟、可驗證結果，例如程式修改、資料整理、SEO 分析、內容結構檢查、internal link 建議、系統設定盤點。需要高度價值判斷、品牌取捨或敏感決策的部分，仍然應由人主導。
使用 AI Agent 最大的風險是什麼？
最大的風險不是它不會做，而是它在錯誤目標下做得太快。當需求不清楚、權限過大、驗收標準不足時，Agent 可能產出看似完整但方向錯誤的結果。因此使用 Agent 前，要先定義邊界、限制與確認點。
為什麼 Skills 和 Workflows 對 AI Agent 很重要？
Skills 和 Workflows 可以把反覆使用的規則、檢查表和工作步驟固定下來，讓委派不必每次從頭說明。它們的價值在於提高一致性，讓 AI 更接近照著既有工作方法執行，而不是每次重新猜測使用者想要什麼。