AI 不會讓你的工作更輕鬆，只會讓你有能力接下更大的工作
- 先手動跑懂，再把穩定、重複、可驗收的工作交給 AI -
最近讀到周加恩的〈AI 不會帶來更輕鬆的工作〉，我看完一直點頭，但有一個地方想再往前推一步。
他提到，自己和 AI 合作的方式，已經從早期追求「全部自動化」，慢慢轉成減少自動化的比例。其中一句話我特別有感：
自動化也是一種負債——更精確地說，過早的自動化是一種負債。
這也呼應我這一年大量使用 Claude、Codex、AI Agent、Skill、MCP、Harness，甚至讓不同 AI 分工合作的感受。不過換成我的說法，我會把它改成：
不要追求最低自動化，而要追求「最晚自動化」。
我不是反對自動化。相反地，我每天都在做自動化。只是越做越發現，真正危險的不是沒有自動化，而是一件事情都還沒搞懂，就急著把它規模化。
為什麼我不再追求「全部自動化」？
剛開始使用 AI 時，我也很容易有「AI First」的想法：這件事可以交給 AI 嗎？如果可以，下一步就是能不能全部交出去？最好只要送出一個 Prompt，AI 就自己規劃、搜尋、執行、整理、檢查，最後把成果交回來。
如果過程還需要人工介入，好像就代表 Agent 不夠厲害。於是我開始研究 Prompt、Workflow、n8n、MCP、Skill 和 Agent，希望最後能變成：
輸入 → AI → 完成
這個流程看起來很漂亮。但做過越多 AI 工作流，我越不迷信「全自動」。很多系統出問題，不一定是模型不夠強，而是我們在還沒理解工作之前，就先把它自動化了。
混亂乘上 AI，只會得到自動化的混亂
假設你請 AI：「幫我建立一套完整的公司知識管理系統。」
現在的 AI 很可能幾分鐘就規劃好資料夾、分類、標籤、Metadata、命名規則、工作流程、Agent 和 Skill。第一眼看起來完整得不得了，真的開始使用後，才發現分類太多、規則太多、每次產出的東西也太多；Context 越塞越肥，真正需要的資訊反而埋在一堆看起來很專業的內容裡。
最後，你原本想減少管理工作，卻每天都在管理 AI 幫你建立的管理系統。
所以我現在會提醒自己：不要用 AI，把一個還沒想清楚的流程規模化。混亂乘上 AI 不會變成效率，只會變成自動化的混亂。
先手動跑幾次，才知道什麼值得自動化
有人問我：「這個東西能不能做成 AI Agent？」我通常會先問：「這個流程你自己跑過幾次？」
如果還沒跑過，我會建議先自己做一次，再多跑幾次。實際操作之後，才會看見哪些資訊重要、哪些步驟每次都相同、哪些地方需要判斷、哪裡最容易出錯、會遇到哪些例外，以及怎樣才算完成。
最後還要回答一個更關鍵的問題：你打算怎麼驗收 AI？
我喜歡的發展順序是：
手動 → 跑熟 → SOP → Skill → 半自動 → 自動化 → Agent
手動不是落後，而是在蒐集自動化需求。每次做到某一步，心裡都冒出「這個怎麼又要重做一次？」時，就記下來。等你知道它何時重複、例外怎麼處理、輸出如何驗收，那才是可能值得自動化的地方。
從 Prompt Engineering 走向 Context Engineering
這一年我也感覺到，重要的問題不再只有「我要跟 AI 說什麼？」還包括「這次任務應該讓 AI 知道哪些事情？」
Prompt Engineering 仍然有用，但在 Agent 工作流裡，任務資料、歷史、規則、工具與記憶該在什麼時候提供或移除，往往同樣關鍵。這也是我開始重視 Context Engineering 的原因。
很多人第一次使用長 Context 模型，會直覺把能找到的資料全部塞進去：文件、歷史對話、公司規範、所有 Skills，越多越安心。但 AI 看過更多，不代表它做得更好。真正有用的，是這次任務需要的資訊；舊規則、不相關文件和過期決策，可能只是雜訊。
如果用一個很粗略的比喻，我會把 AI 的有效能力想成：
有效 AI 能力 ≈ 模型能力 × Context 訊噪比
這不是測量模型能力的正式公式，而是提醒自己：模型再強，脈絡太雜也可能拖累結果。
Skill Library 不是收集越多越強
我最近花很多時間整理自己的 Skill Library。以前看到「必裝 50 個 Skills」或「100 個 Agent Skills 免費下載」，也會想全部裝起來。後來才發現，Skill 不是 Pokémon，並非收集越多就越強。
更重要的是確認哪些工作流程真的反覆使用、哪些規則已經穩定、哪些是自己的寫作習慣與驗收標準，還有哪些經驗值得沉澱成 Skill。我也開始做 Session Review 和 Voice Calibration，因為有價值的不是 AI 知道很多，而是它知道我做這件事時怎麼做。
如果你也在整理經驗、判斷與方法，可以延伸閱讀從經驗到 AI Skill：把專業整理成 AI 能執行的能力。
AI 越強，越需要界定它能做什麼
以前我希望一個 AI 從頭做到尾；現在反而會拆開工作：有人負責規劃、Agent 負責執行，其他模型找問題，真正開始寫程式前也可以先做不同角度的 Review。
不是因為 AI 太弱，而是它太強了。一個能力很強、權限很大、Context 又混亂的 Agent，可能非常有效率地把錯的事情全部做完，而且還做得漂漂亮亮。
因此我會把成熟的工作流想成：
Context → Plan → Skill → Agent → Review → Feedback
每一層都有自己的責任，也要設計權限邊界、人工檢查的時機、完成條件，以及做錯之後如何 rollback。若想了解 Skill 如何和 Agent 的執行環境搭配，可以接著看從 Skill 到 Agent Harness。
AI 沒讓工作消失，而是把工作往上移
以前做網站時，我可能會問：「這段 JavaScript 怎麼寫？」有了 Codex 之後，這部分可以交給 AI，但我的工作沒有消失，問題變成「這個功能應該怎麼設計？」
接著要想資料怎麼流、權限怎麼分、Agent 能看到哪些資料、哪些決定可以交給 AI、哪些地方一定要 Human Review、做錯怎麼 rollback，以及怎麼確認 AI 說的完成是真的完成。
工作的重心慢慢從 Operator 轉向 Orchestrator：設計誰來做、怎麼做、看見哪些資訊、可以做到哪裡、誰來檢查，以及什麼條件才算完成。我的體感是，工作沒有消失，而是往更高一層移動。
效率提升後，目標也可能變大
以前準備一份簡報可能要一天，現在 AI 也許一小時就能幫上忙。省下來的時間會不會自動變成休息？不一定。公司也可能看到新的產能，接著問：「既然一天能做五份，是不是可以多接四個案子？」
我認為 AI 帶來的效率，很可能有一部分會變成更大的目標。以前一個人只能經營一個專案，之後可能同時管理多個 Agent、專案或內容流程；以前小團隊才能做的事，現在更小的團隊也能挑戰。實際結果會因工作與組織而異，但工作的範圍確實可能跟著能力一起擴大。
這也是我為什麼看好「一人公司」的槓桿。值得期待的不只是少工作兩小時，而是以前需要十個人完成的事，能不能由一到三個人完成。未來厲害的一人公司，背後可能有 Claude、Codex、不同 Agent、自己的 Skill Library、Harness，以及跑熟的自動化工作流；真正重要的能力，是設計工作。
我的版本不是減少自動化，而是最晚自動化
先讓人跑，跑到理解流程；再整理成 SOP，確認流程穩定；接著把可重複的能力沉澱成 Skill，再逐步半自動化、自動化，最後才讓 Agent 接手完整工作。
等到一個步驟已知、重複、穩定而且可驗收，自動化才比較可能成為資產。否則，它也可能只是另一種技術債。
AI 時代稀缺的能力，是設計脈絡
AI 用得越多，我越覺得模型能力不是全部。結果常常取決於你怎麼設計 AI 看見的世界：哪些資料要給、哪些不該給、哪些規則寫進 Skill、哪些判斷留給人；誰負責規劃、誰負責執行、誰負責 Review，又要符合什麼條件才算完成。
這些都是脈絡設計。未來擅長使用 AI 的人，不一定最會寫 Prompt，而是知道什麼時候該給 AI 哪些 Context、什麼時候該把 Context 拿掉，以及哪些事情根本不該交給 AI。
Slow is smooth, smooth is fast
繞了一大圈，我現在反而回到一個老派的方法：先自己做，先手動跑懂，再建立 SOP；SOP 穩定後做 Skill，Skill 穩定後做 Agent，最後設計驗收條件並串起工作流。
看起來比較慢，最後卻可能比較快。因為我們建立的不是 Demo 看起來厲害、三天後沒人敢碰的 AI 系統，而是三個月、半年後，甚至模型換掉之後，仍能繼續運作的流程。
AI 不一定讓我們工作更少；它真正帶來的，是讓一個人有能力完成以前一個團隊才能完成的事。人要做的，是決定什麼值得做、設計 AI 怎麼做，並知道什麼時候不該讓 AI 做。
延伸閱讀／觀點來源
本文受到周加恩〈AI 不會帶來更輕鬆的工作〉中「過早自動化是一種負債」與脈絡設計等觀點啟發，再從我實際使用 Claude、Codex、AI Agent、Skill、MCP、Harness 與多 Agent 協作的經驗，延伸出「最晚自動化」這個想法。
常見問答 (FAQ)
Q1：什麼時候適合把工作流程交給 AI Agent？
先親自跑過幾次，確認重複步驟、例外情況、需要人工判斷的環節，以及可驗收的完成條件。流程穩定後，再逐步把可重複的部分交給 Skill、自動化或 Agent。
Q2：為什麼不一開始就把整個流程自動化？
流程還沒理解清楚時，需求和規則容易改變。太早自動化會把錯誤假設與混亂一起規模化，後續還得花時間維護和修正。
Q3：Context Engineering 和 Prompt Engineering 有什麼不同？
Prompt Engineering 著重怎麼寫指令；Context Engineering 還會考慮任務需要哪些資料、規則、歷史與工具資訊，以及何時提供或移除它們。Agent 工作流通常需要同時設計兩者。
Q4：Skill 裝得越多，AI 就會越好用嗎？
不一定。應優先保留符合實際工作方式、反覆使用且規則穩定的 Skills。過多或不相關的內容可能增加脈絡雜訊，讓當前任務更難聚焦。
Q5：AI 自動化真的會讓工作變輕鬆嗎？
它可能縮短部分任務的處理時間，但省下的時間也可能被更大的目標、新的專案或更多協調工作填滿。是否更輕鬆，還取決於組織如何安排工作與分配效率收益。
