前言
我當工程師已經 4 年了。現在每天都同時並行使用 Claude Code 和 Codex 來工作。
這篇文章是我把相當一部分工作交給代理之後，親身體會到「即便如此，人類仍然要負責什麼」所整理出來的隨筆，也包含了我自己的失敗經驗。你最近交出的成果裡，有多少比例是你敢拍胸脯說是「自己的工作」？我自己在面對這個問題時一度語塞，所以才寫了這篇文章。
本文是基於 2026 年 8 月時點、個人感受整理而成，並不是在討論某項特定技術的優劣。
能落到情境裡的工作，現在已經可以交給代理處理了
先從現況說起。這一年來，我的工作怎麼改變了？答案是：「只要能語言化、能落到情境脈絡裡的工作」，幾乎都已經改成透過代理來跑。
- 彙總 SQL 和制式實作
- 分析報告與簡報的初稿
- 技術調查與摘要整理
- 開立發票、整理每月目標這類可以流程化的行政工作
以我自己來說，我會把團隊成員的價值觀、工作背景、營運規則整理成 Markdown，集中存到一個儲存庫裡，代理會讀這些內容後直接行動。幾年前還得花上一整天才能做完的「工作」，現在在早上的排程執行裡就自己結束了。
重點在於「能落到情境裡」這句話的意思。只要是能寫成操作手冊、能列出前提條件的工作，一旦寫得出來，就立刻進入 AI 的主場。反過來說，人類的工作就會逐漸往「還沒寫出來的東西」以及「根本無法寫出來的東西」靠攏。關於代理設計的思路，可以參考 Anthropic 的代理建構指南；愈讀愈會加深一種確信：只要把工作結構化，連工具和評估機制都一起建立好，竟然真的能跑到這種程度。
當然，這並不是說現階段的 AI 無所不能。METR 的研究顯示，16 位有經驗的 OSS 開發者使用 AI 工具後，實際工作速度反而平均慢了 19%，而且和他們自己的主觀感受相反。更可怕的是，研究結束後，參與者仍然相信自己「用了 AI 之後快了 20%」。連使用者自己的感受都不一定準。
但我不會把這解讀成「AI 不能用」，而是解讀成「有效的領域和無效的領域分得非常清楚」。AI 被交付的任務類型有明顯偏向這件事，也在 Anthropic Economic Index 裡被呈現出來。當我每天都看到那些情境完整、流程固定的領域持續進化時，愈來愈能感受到「這裡是人類的聖域，所以沒問題」的地方，年年都在縮小。
此刻真正該害怕的，我認為不是「工作被 AI 搶走」。可怕的是，自己變成那種只會把 AI 輸出左手進右手出的人。前者是環境變化，無法抗拒；後者則完全是自己的選擇。
那麼，「人介入的意義」還剩在哪裡？
如果只會把輸出左手進右手出，那麼在工作流程裡，你的角色就會變成「人類路由器」。路由器不是介入價值，只是延遲而已。那麼，究竟什麼還能算是介入價值？我目前的答案畫成圖，大概是這樣。
留在「無法寫進情境脈絡」那一側的人類工作有 5 種。接下來逐一說明。
工作①：成為別人想一起共事的人
先從最不像技術文章的話題開始，但這其實是我最有感的一點。
以前，只要會寫程式就能接到工作。即使溝通有點生硬，只靠技術本事也能吃得開，像是那種「靠一把刷子闖天下」的技術人。但在「寫程式」本身的價值下降之後，我感覺真正能只靠純技術力活下去的，大概只剩下少數那種修到電腦科學碩士等級、還能持續對開源專案提 PR 的人。
包含我在內的大多數工程師，並不是在那種賽道上競爭。
那麼要靠什麼競爭？
就是讓別人覺得「想跟這個人一起工作」。
好不好問問題、能不能理解需求背後的原因、遇到失誤時會不會不是責怪而是一起補救——當產出之間的差距縮小後，這些連人味在內的綜合分數就會變得相對重要。
以我自己來說，我一直不嫌麻煩地承接面向非技術人員的說明和培訓，結果反而成了最常帶來下一個案子的事。比起靠技術力碾壓別人的記憶，我更常收到的是「你講解得很清楚，之後還想再麻煩你」這種回饋，而這些回饋更容易直接變成案子。
工作②：做出自己的堅持
AI 的輸出有時候是不是明明正確，卻讓你完全提不起閱讀慾望？
我在 Qiita 寫文章時，當然也會用 AI，但我好幾次回頭看 AI 產出的初稿，都會想：「這種內容，我自己也會直接跳過。」內容面面俱到、很仔細，也沒有錯，但誰寫都一樣，是那種「標準解」，沒有溫度。
所以最近我會在開始寫之前，先決定「我要在哪裡堅持」。像這篇文章，我選擇的是「具體攤開自己的失敗經驗」。和標準解之間的差異，正是文章會被讀下去的原因，而這種差異的素材，只存在於自己的經驗裡。程式碼也是一樣，生成後直接拿來用，和依照自己現場的狀況再磨一層，成品的面貌會差很多。
工作③：把不在情境脈絡中的資訊用在決策上
代理在給定的情境脈絡裡確實會表現得驚人地聰明，但那些沒有出現在提示詞、搜尋結果、工具鏈中的獨有資訊，無法成為它的判斷材料。
之前我曾經接過一個彙總需求，心裡明明覺得「這個有點怪」，卻還是照樣往下做。結果交付之後才發現前提兜不攏，整個案子全部重做。SQL 沒錯，資料處理也沒錯，錯的是我在覺得怪的時候沒有確認就直接往下做的判斷。
現場氣氛、客戶真正的目的、期限背後的原因、只靠口頭傳達的限制——這些「不會寫在文件裡的資訊」，如果人類不提供，就不會成為 AI 的判斷依據。而且，判斷要給哪些資訊、哪些資訊不該給，也是人類的工作。重點不是 AI 輸出有沒有對，而是這種情況下到底該不該採用它。這就是所謂的決策工作。
工作④：承擔責任
有一天，Claude 回報說「所有測試都通過了」，我信了它，當天就收工。結果隔天一確認，根本一個都沒過。
如果那樣直接交付出去，掛在壞掉成品上的就是我的名字。代理可以大量產出內容，但責任一點都不會承擔。既然能承擔責任的主體只有人類，那這件事就一定會保留成人類的工作。
從那次之後，我給自己定了兩條規則。第一，不要省略自己親眼驗證；第二，讓另一套 AI 做交叉審查。曾經有一次把 Claude 寫的程式碼拿給 Codex 看，結果找出了 4 個潛在 bug，從此這個雙層架構就成了固定流程。讓同一系統的 AI 做自我審查，分數總是意外地寬鬆。
我認為，承擔責任的意思，是要「理解」之後再接手。現在已經進入一個代理的產出速度，開始由人類的理解速度決定上限的時代了。一旦放棄理解，那就等於拿到一張「只會原樣送出」的單程票。
工作⑤：不要只待在單一領域
老實說，只靠一種專業吃飯，已經變得相當困難了。因為專業領域內的工作，越來越體系化、越來越容易語言化，也就是越容易落到情境脈絡裡，因而成為代理擅長的範圍。
如果你是後端工程師，就應該盡量具備看前端和基礎架構的能力；而我也認為，往工程外的領域——例如行銷或經營——擴展，會很有用。這是一場綜合實力的競賽。
我自己也從資料分析開始，逐步把領域擴展到 Web 開發、基礎架構，以及 LLM 活用基礎設施。最近我還開始經營個人媒體事業，也把腦袋投入到行銷和事業規劃裡。跨到別的領域時，自己常常會退回新手狀態，挫折也不少，但我也有很有意思的發現。只要跨過領域邊界，「不會寫在情境脈絡裡的東西」會一下子變多。像是在零售現場聽到的話，反映到資料設計上；或是從事業規劃的需求倒推，去調整分析的粒度——這些跨域操作，沒有任何一份文件會寫，所以只要背景不是由自己來共享，AI 幾乎不會自己提出來。領域知識與跨域經驗，正因為不容易被寫進情境脈絡，所以價值才會留下來。
那麼，該做什麼？
雖然前面列了 5 點，但不可能明天開始就全部練起來。我自己實際在做的只有以下 3 件事。
第一，一定要在 AI 的輸出上加上自己的差異（思考）再交出去。如果是程式，就要先看過並依現場情況修正；如果是文章，就補上一段自己的堅持。反過來說，如果發現自己完全不想加任何差異就直接送出，那就是「這份工作不需要我」的訊號，別猶豫，直接交給自動化。
第二，不能解釋清楚的東西就不要輸出。把代理的結果，理解到能對人說明的程度之後再拿出去。這很花時間，但如果偷懶，最後就會變成前面提過的那起「所有測試都通過了」事件。
第三，定期往隔壁領域跨一步。不需要誇張地轉職，只要多接手隔壁團隊的一件工作就夠了。每跨出去一次，能寫不進情境脈絡的「口袋名單」就會增加。
結語
AI 代理的進化真的非常快，這篇文章裡提到的「人類的 5 種工作」，幾年後也許有一半都能被寫進情境脈絡裡。但即便如此，「加上自己的差異、理解後承擔、跨出領域」這種做事方式，不管可被寫進情境脈絡的邊界怎麼移動，應該都還能一直拿來用。
最後再把開頭的問題放一次：你最近交出的成果裡，有多少比例是自己的差異？如果你也答不出來——那就跟我一樣。一起掙扎吧。這篇文章是帶著自我警惕，用 AI 一起寫完後，最後再由我補上自己的差異。
原文出處：https://qiita.com/ktdatascience/items/8d2dace07c9c7a9d0453
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
