AI原生工作必備的「抽象化與具體化能力」

大家好，我是TIMEWELL的濱本。

開始使用程式碼代理（coding agent）的人，常常告訴我同一件事：「我自己的工作明顯變快了，但團隊的產出並沒有更早出來。」我在為大企業與創業者經營AI驅動開發課程的過程中，反覆看到這種「個人很快、組織不快」的現象。本來應該補上人力缺口的AI，為什麼沒有反映在組織的數字上？這篇文章想用「抽象化與具體化」這組老詞來解釋原因，並寫下未來的工作者真正需要的能力。

先說結論。原因有兩個。一是加速的地方不是瓶頸。二是脈絡交給AI越多，AI就越傾向「在這個脈絡裡前後一致的答案」，越難給出往上一層看的答案。目前能補上這兩個缺口的，只有人。具體來說，是察覺事情不對勁的能力，以及把這份違和感說清楚的能力。想先了解我們如何在課程中訓練這種能力的讀者，可以先看WARP的課程頁。

「變快了」，組織效率卻沒有提升的原因

先用數字看看感覺和實測差了多少。

AI評測機構METR在2025年7月發表了一項實驗：讓16位資深的開源開發者，把246件真實任務隨機分配到「可用AI」與「不可用AI」兩組。結果是，可用AI的那一組慢了19%。令人驚訝的不是這個。開發者事前預測「會快24%」，在實驗中變慢之後，仍然相信「自己快了20%」¹。「變快了」的感覺，是獨立於實測而產生的。

METR在2026年2月發表了後續報告。2025年8月開始的第二次實驗中，因為不想在沒有AI的情況下工作而退出的開發者增加，還有三到五成的人表示會刻意不提交「不想在沒有AI時做」的任務，因此METR坦承資料的可信度下降了。原始數字上，原本參與者的子集合朝快18%的方向、新參與者朝快4%的方向，但信賴區間都跨過零。METR自己的結論是「2026年初AI很可能讓人變快了，但我們的資料對於幅度只是非常薄弱的證據」，並宣布要改變實驗設計²。

我想請大家注意的，是同一個METR在2026年5月發表的自評調查。他們把「速度」的變化與「價值」的變化分開，問了349位技術工作者。速度的變化中位數是3倍，價值的變化中位數是1.4到2倍³。METR舉了一個速度容易高估價值的例子：研究者用AI很快做出一個資料儀表板，沒有AI的話要花好幾倍的時間，但那個儀表板對專案來說並不重要。

這就是這篇文章最先想說的事。變快的那個工作，不是瓶頸。

製造業有一個叫做限制理論的老概念。整個流程的產出量，由最慢的那一道工序、也就是瓶頸決定。在瓶頸損失的一小時，是整個系統損失一小時；但在非瓶頸節省的一小時，連一分鐘的產出都不會增加⁴。計算機的世界也有同樣的法則，正如阿姆達爾在1967年所示，只要還有只能循序進行的部分，其他部分再怎麼平行化，整體速度都會碰到天花板⁵。

換成辦公室的工作，就是這樣：假設一份企劃書要寫兩小時，簽核要三天。就算代理把撰寫縮短到十分鐘，企劃開始推動的時間仍然是三天又十分鐘。組織產出的速度，是由簽核這道慢的工序決定的。但寫企劃書的本人，因為「兩小時變成十分鐘」，會覺得自己快了十二倍。METR的「速度3倍、價值1.4倍」，說明這個結構正在全世界發生。

再看一個總體的數字。芝加哥大學的研究者把丹麥的大規模調查與行政紀錄串接起來，發現受影響職種的多數雇主已導入生成式AI、工作者也回報了生產力上的好處，但對所得與紀錄工時的影響是精確的零，在ChatGPT推出兩年後的時點，排除了超過2%的效果。改變的是工作的結構，出現了AI監督、AI整合這類新任務⁶。個人感覺與組織數字之間的鴻溝，不是日本獨有的。

什麼是抽象化與具體化：工作是由來回構成的

在這裡先定義標題裡的詞。

抽象化，是從眼前具體的事件裡，抽出「這是為了什麼」「它是哪個結構的一部分」。從「寫企劃書」這件工作往上爬：「這份企劃書是為了取得簽核」「簽核在一道三天的工序裡」「整個流程的目的是創造下一期的營收」，一層一層往上，就是抽象化。具體化則相反，是把目的與結構落成「那麼今天，由誰、做什麼、怎麼做」。落到「要把簽核從三天縮到一天，就先把簽核者要看的項目濃縮成三點摘要」，就是具體化。

計算機科學家戴克斯特拉在1972年的圖靈獎演講中這樣說：「抽象化的目的不是為了模糊，而是為了創造一個能夠絕對精確地表達的新語義層次」⁷。我認為這句話可以直接當成工作的技術來用。擅長抽象化的人，不是說話模糊的人，而是能在上一層精確地說出「這個案子的瓶頸在簽核工序」的人。

在日文世界，細谷功的《具體與抽象》把抽象與具體之間的「來回」整理為智性的運作本身⁸。我持相同立場。工作做得好的人，既不是一直待在高抽象層次的人，也不是一直做具體作業的人，而是來回次數多、來回幅度大的人。

那麼，AI原生地工作是什麼意思？我的定義是：「把來回的一部分交給AI，但由人決定要在哪個高度提問的工作方式」。代理非常擅長具體化。說一句「幫我做一份給簽核者看的三點摘要」，幾分鐘就出來了。抽象化也做得到，只要開口要求。問「這個工作流程的瓶頸在哪」，就會得到一個看起來合理的答案。問題在於，那個答案的品質，受我們交給AI的脈絡數量與品質的影響，遠大於我們的想像。

AI能抽象化。但脈絡持有得越多，越傾向「這個脈絡的答案」

「給AI越多脈絡，它就越聰明。」很多人這麼想，於是一直延續同一段對話、把資料全部貼進去、把過去的往來全部帶著走。研究顯示，這並不那麼單純地成立。

2023年由史丹佛大學等研究者發表的「Lost in the Middle」指出，在長輸入中，相關資訊位於中段時，模型的效能會大幅下降。開頭和結尾的資訊抓得到，中間的卻會漏掉⁹。2025年的NoLiMa研究更嚴格：在問題與答案之間沒有字面重合、也就是需要「聯想」的檢索中，到了32K token時，13個模型中有11個掉到短輸入效能的一半以下。就連最強的GPT-4o也從99.3%降到69.7%，即使使用推理功能或思維鏈也無法維持¹⁰。

Chroma在2025年7月發表的技術報告「Context Rot」，以18個模型確認了輸入越長、效能越不均勻地劣化。我認為特別重要的是，在從對話紀錄回答問題的LongMemEval任務中，只保留相關部分、約300個token的輸入，一致地比給全文的表現更好¹¹。給得少，答案反而更好。

Anthropic在2025年9月的工程文章中，把這個現象稱為「脈絡腐化（context rot）」，說明模型有類似人類工作記憶的「注意力預算（attention budget）」，每多加一個token，預算就被削減一些；並把好的脈絡設計定義為「找出能讓期望結果機率最大化的、最小的高訊號token集合」¹²。同一篇文章還說，指示應該寫在「適當的高度（right altitude）」，也就是介於過細而脆弱的指示，與過於模糊而沒有線索的指示之間。這個「高度」，講的正是抽象程度。

把研究翻譯成工作上的症狀。和代理的長對話中，有沒有發生過這種事？一開始是從「我想把這個業務自動化」這個高抽象層次出發，往來幾輪之後，「把這個按鈕移一下」「把這個錯誤消掉」這類具體修改不斷堆疊，不知不覺代理只會回覆針對最近一句指示最佳化的答案。「這個畫面根本不需要吧」這種往上一層的提案，再也不會出現。這就是脈絡持有得越多、越傾向「這個脈絡的答案」的意思。

老實說，人也會這樣。會議拖得越長，質疑當場前提的發言就越難出現。不過，人和AI有一個差別：人能把「總覺得哪裡不對」的違和感，從脈絡的外側帶進來。至少目前是如此。

察覺違和感，並說清楚：豐田所說的「人的智慧」

豐田生產方式有兩根支柱。一根是及時生產，另一根是「自働化」。依豐田自己的說明，自働化是「加入人的智慧的自動化」：當設備異常、品質異常、作業延遲等異常發生時，機器會自己停下，或者作業者拉繩讓生產線停下¹³。因為偵測到異常就停，所以不良品不會流出，異常的原因也能被消除。同一個頁面還寫著：「無論機器、機器人或IT多麼優秀，它們自己無法再進化。能為了進化而改善的，只有人。」

我認為AI原生工作方式的核心，就在這個「自働化」的思想。代理不會停下來。它會不停地產出「差不多對」的答案。在Stack Overflow 2025年的開發者調查中，對AI工具最大的不滿是「差不多對、但不完全對的答案」，占66%；45%表示「除錯AI產生的程式碼很花時間」。信任AI工具準確度的開發者是33%，不信任的是46%¹⁴。當「差不多對」堆積起來，拉繩的是人。

那麼，拉繩需要什麼？兩件事：察覺違和感的能力，以及把違和感說清楚的能力。察覺的能力，幾乎就等於抽象化的能力。「就算把這件工作加速，整體也不會變快吧」這種察覺，不從上一層看現在的位置，是不會產生的。在代理不斷堆疊具體修改的當下，忽然把高度拉高，問一句「這原本是為了什麼」。這就是察覺。

說清楚的能力，是把察覺轉成可以驗證的句子的能力。我建議用四行來寫。

行	寫什麼	例子
第一行	原本期待的狀態	從企劃到簽核通過、開始推動的時間減半
第二行	實際的狀態	企劃書十分鐘就寫好，簽核仍然是三天
第三行	差距	變快的是撰寫，簽核工序完全沒被碰到
第四行	放著不管的影響	企劃的數量會隨撰寫速度增加，簽核的待辦堆得更高

寫到第四行，違和感就會從「總覺得怪」變成「不動簽核工序的話，反而會惡化」的判斷。而且，這四行可以直接變成給代理的下一個指示：「把簽核者要看的項目濃縮成三點摘要，改成放在企劃書開頭的格式」，在正確的高度上具體化。

重要的是順序。有違和感時，在問AI之前先自己寫四行。如果問AI「你覺得問題在哪」，AI會在既有的脈絡裡找一個前後一致的問題，而那通常在最近工作的延長線上。先自己寫好四行再交出去，AI就能從上一層開始具體化。

明天就能做的五件事

把以上的內容落到明天的工作。

第一，在自動化之前，先把流程畫在一張紙上。從企劃誕生到送達客戶，誰做什麼、各花幾天。用箭頭連起來，在最長的那一段畫圈。那就是瓶頸。要交給代理什麼，看了圈再決定。加速沒畫圈的工序，只是在自己的桌上重現METR的「速度3倍、價值1.4倍」。

第二，交給代理之前，先用一行寫出目的。「為了把簽核從三天縮到一天，建立給簽核者的摘要格式」。這一行決定了指示的高度。寫不出這一行，就是自己還沒抽象化的訊號，先別動手，回到那張流程圖。

第三，需要抽象化的問題，用空的脈絡來問。在長對話裡問「這個設計根本上對嗎」，得到的會是那個脈絡的答案。另外開一段對話，只給幾百字的現況摘要，問「這個流程的瓶頸在哪」。Chroma實驗中約300個token的聚焦輸入勝過全文，就是這種用法的佐證¹¹。拆給子代理、只帶摘要過去等營運細節，我寫在AGENTS.md、Skills、Hooks與cron的組織營運裡。

第四，記錄違和感。每週一次，用四行的格式寫下三個違和感。寫不出來的那一週，就是沒有時間拉高高度的一週。這份紀錄會成為自己抽象化能力的軌跡，半年後回頭讀，就知道自己已經能接住哪一個層次的違和感。

第五，組織要肯定「停下來」。就像豐田不會責備拉繩的作業者，把說出「這樣直接自動化，整體不會變快」的人，當成擋住浪費的人，而不是擋住進度的人。這是經營者與管理者的工作。衡量的不是導入了幾個代理、省了幾小時，而是瓶頸縮短了幾天。不改變衡量方式，增加的只會是「變快了」的感覺。

我們為大企業與創業者經營的AI驅動開發課程，就是用學員實際的業務來跑這五件事。教操作程式碼代理的時間，反而比畫流程圖和寫四行的時間短。因為操作幾天就學得會，但拉高、降低高度的習慣，只能靠反覆練習養成。課程的架構整理在WARP的頁面上。

總結

程式碼代理會讓工作變快。這是真的。但「變快了」的感覺和組織的數字是分開的。在METR的實驗裡，開發者相信自己快了20%，實測卻慢了19%；2026年的調查中，速度3倍、價值1.4到2倍；丹麥的行政紀錄裡，所得與工時都沒有超過2%的效果。原因是加速了不是瓶頸的工序，以及AI持有的脈絡越多，越傾向那個脈絡的答案，越難從上一層回答。

所以，未來的工作者需要的，是能自己轉動抽象化與具體化的來回，並在來回途中察覺「哪裡不對」、用四行寫清楚、然後拉繩的能力。AI不會停。停下來的是人。

明天如果只做一件事，請針對你現在交給代理的某一項工作，用一行寫出「這是流程中的哪一道工序，那道工序是瓶頸嗎」。寫不出來，那就是第一個違和感。想從自家的業務開始一起設計這種來回的讀者，歡迎與我們聊聊。

Footnotes

1. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（METR，2025年7月10日）。16位開發者、246件任務的隨機對照試驗。事前預測快24%、事後自評快20%，實測慢19% ↩

2. We are Changing our Developer Productivity Experiment Design（METR，2026年2月24日）。第二次實驗的選擇偏誤與原始估計值（原參與者-18%、新參與者-4%，信賴區間皆跨零）依該文 ↩

3. Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity（METR，2026年5月11日）。2026年2至4月、349位技術工作者的自評調查。價值變化中位數1.4至2倍，速度變化中位數3倍 ↩

4. Eliyahu M. Goldratt、Jeff Cox《The Goal》（North River Press，1984年）。繁體中文版《目標》。限制理論的原典 ↩

5. Validity of the single processor approach to achieving large scale computing capabilities（Gene M. Amdahl，AFIPS 1967） ↩

6. Still Waters, Rapid Currents: Early Labor Market Transformation under Generative AI（Anders Humlum、Emilie Vestergaard，NBER Working Paper 33777，2025年5月、2026年3月修訂）。舊題為「Large Language Models, Small Labor Market Effects」 ↩

7. The Humble Programmer（Edsger W. Dijkstra，1972年ACM圖靈獎演講，EWD340）。原文為 "the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise."（筆者翻譯） ↩

8. 細谷功《具體與抽象》（原書名 Gutai to Chusho，dZERO，2014年，日文） ↩

9. Lost in the Middle: How Language Models Use Long Contexts（Nelson F. Liu等，arXiv:2307.03172，TACL 2024） ↩

10. NoLiMa: Long-Context Evaluation Beyond Literal Matching（Ali Modarressi等，arXiv:2502.05167，2025年） ↩

11. Context Rot: How Increasing Input Tokens Impacts LLM Performance（Chroma，Kelly Hong等，2025年7月14日） ↩ ↩²

12. Effective context engineering for AI agents（Anthropic，2025年9月29日）。「context rot」「attention budget」「right altitude」為該文用語（筆者翻譯） ↩

13. Toyota Production System（豐田汽車全球網站）。將自働化（Jidoka）說明為 "automation with a human touch"，並指出異常時停線、改善只有人能做 ↩

14. 2025 Developer Survey: AI（Stack Overflow，2025年）。「差不多對但不完全對」66%、「除錯很花時間」45%、信任準確度33%、不信任46% ↩