一場關於方法演進、判斷力養成與專業未來的討論整理，但這個主題，未完待續。
穿過術語的噪音
短短一年多，運用 AI 進行軟體開發的「方法」就換了好幾個名字——從 Vibe coding，到 Spec-driven development（SDD），到 Agentic engineering，再到 Harness engineering，乃至於 2026 年六月才爆紅的 Loop engineering。連站在最前緣的人——例如 Anthropic 旗下 Claude Code 的負責人 Boris Cherny——說法也變得很快。對外圍的使用者而言，霧裡看花的成分反而愈來愈高。
但如果退一步，把這些新詞還原到它們的本質，會發現一個讓人安心、也讓人清醒的事實：這一切始終發生在同一條軟體開發生命週期（SDLC）上，只是各個節點的 AI 參與比例不同而已。 很多所謂的新方法，本質是把既有的工程實踐重新命名——有人甚至直言，SDD 不過是替「下手前先想清楚、寫清楚」這件老事掛上一個品牌名。
站在最前緣的人說法善變，與其解讀成反覆無常，不如理解成：他們正在真實時間裡邊做邊摸索，命名永遠追著現實跑，於是外圍觀察者拿到的訊雜比特別差——但底層能力的位移，是真的。
本文嘗試把這條演進軸線、以及它對「軟體開發作為一門專業」的意涵，做一次完整的梳理。
一、演進的主旋律：人類不斷往抽象層級上移
把五個階段依序攤開，會看見它們其實在做同一件事——把人類從「迴路內」一步步往「迴路外」移。
- Vibe coding（2025 年 2 月，Andrej Karpathy 提出1）：下提示、生成、靠感覺迭代。極快，適合低風險小任務，但約三個月後會撞上技術債複利累積的牆2。
- Spec-driven development（SDD）：不直接跳進實作，先把架構決策與需求寫成結構化規格，存進 repo。關鍵在於把「規格」與「實作」解耦，並藉此跨 session、跨 agent 保存 context3。
- Agentic engineering：人類退居協調者與監督者，99% 的時間不再直接寫程式，而是指揮替你寫程式的 agent。目標是取得 agent 的槓桿，卻不在品質上妥協。連 Karpathy 自己都在提出 vibe coding 一年後承認該時代正在結束、我們正進入 agentic engineering 的時代4。
- Harness engineering：當「用 agent」成為常態，問題從「哪個模型寫得好」轉向「如何讓 agent 可靠地量產」。它是設計包裹在 agent 外圍的約束、工具、文件與回饋迴路——人類設計環境、指定意圖、建立回饋，agent 負責寫程式。這個詞由 HashiCorp 創辦人 Mitchell Hashimoto 推廣5；2026 年 2 月 OpenAI 公開一個實驗——三位（後增至七位）工程師用 Codex agent、在「零手寫程式碼」的前提下產出約百萬行程式碼、約 1,500 個 PR——讓它受到全業界關注6。一個正式級 harness 通常含五層：工具編排、驗證迴路、context 與記憶、護欄、可觀測性7。
- Loop engineering：人類連「下提示」都交出去，改為設計「會自己驅動 agent 的控制系統」。你定義目標，系統行動、觀察、決策、重複，由獨立的評估機制把關，直到目標達成。這個概念在 2026 年 6 月由 Anthropic 的 Boris Cherny、OpenClaw 創作者 Peter Steinberger 點燃，並由 Google 工程師 Addy Osmani 正式命名整理8。
把這五段串起來，是同一條軌跡：親手寫程式碼 → 寫規格 → 指揮 agent → 設計 agent 的工作環境 → 設計會自己驅動 agent 的控制系統。 每一階段都在回應上一階段「人變成瓶頸」的問題；代價則是抽象層次愈高，對驗證機制與成本控管的要求也愈嚴格。
二、瓶頸的真正位置：不是「決策」，而是「信任」
一個常見的樂觀模型是：AI 把低階實作拿走後，人類退守到「高階探索、分析與決策」這片高地，於是壓力反而減輕。
這個模型過於溫和。當 Coding 推到接近 100%、Testing 推到接近 100% 時，人類殘留的工作並不主要落在「創意與決策」那一格，而是大量塌到驗證、審查與當責那一格。你沒寫的程式碼變多了，但你仍得為它背書、得相信它、得在出事時負責。
這裡有個工作量守恆的味道：把 Coding 壓到 100%，並不會讓總工作量下降，而是把它搬家——大量轉移到審查節點上。它變形，而不是消失。於是真正的瓶頸不是「高階決策還需要人」這種讓人安心的位置，而是「人得為一堆自己沒寫、也來不及細看的東西負責」這個遠比較難受的位置。
證據就藏在數字裡：開發者對 AI 生成程式碼的信任正在下滑——Stack Overflow 2025 年的調查顯示，信任 AI 程式碼準確性的比例年減至約三成，而近半數開發者明確不信任其輸出9；METR 在 2026 年 3 月的研究也發現，約有一半「通過 SWE-bench Verified 測試」的 AI agent PR，實際的 repo 維護者根本不會 merge10。更直接的瓶頸證據是：高 AI 採用度的團隊雖然 merge 的 PR 數量大增，審查時間卻同步暴增、而組織層級的 DORA 交付指標幾乎沒動11。所以真正的 choke point 是信任邊界——人要消化、要為之負責的 AI 產出量，成長速度遠快於人審查它的能力。
這也正好解釋了 harness 與 loop engineering 骨子裡在幹嘛：它們不是想把「創造」從人手上拿走，而是想把「驗證」從人手上拿走。整個演進的下一個主戰場，是想辦法讓機器來信任機器。
但這裡有個遞迴陷阱：用 agent 去驗證 agent，只是把信任問題往上推一層，並沒有消滅它。到最後，總得有人做兩件機器很難真正接手的事——定義「對」是什麼（spec / intent 的源頭），以及承擔後果。這兩件，delegate 不掉。
因此，那個最頑固、不會因為下一個 -ing 新詞出現就鬆動的人類殘留，與其說是「做高階決策」，不如更精確地說是：擁有「完成的定義」，並承擔其後果。
三、殘酷的斷裂：判斷力的養成路徑被架空
承上，未來進入軟體開發領域，心智上的訓練很可能遠重於實作。這個推論幾乎是必然——但它藏著一個對「入行」極其殘酷的結構性問題。
當 coding 那層被抽掉，我們等於要求一個剛進場的新人，直接從 lead 的位置開始做：判斷、取捨、當責，以前是資深者的事，現在一上場就得扛。而且他管的是一群比人類更快、更會一本正經地胡說八道、犯錯模式又跟人類完全不同的「AI 下屬」。心智壓力高，不只因為思考密度變高，更因為他被要求承擔的判斷，過去是要用很多年低風險的實作去換來的。
這就帶出最關鍵的斷裂：那套「高心智」的判斷力，過去恰恰是靠著做完那些現在被 AI 拿光的「低心智」工作，才長出來的。
你怎麼知道一段程式碼聞起來不對？因為你自己踩過那個坑。你怎麼知道一個架構決策三個月後會反咬你？因為你維護過自己三個月前的爛攤子。品味、嗅覺、那種說不清楚卻很可靠的「這裡怪怪的」——它不是讀來的，是手把手磨出來的。當低心智的階梯被整段抽掉（用「架空」來形容最為貼切），我們其實還不知道，新人要從哪裡長出資深者賴以判斷的那層直覺。
所以「未來心智訓練遠高於實作」這句話有個重要但書：它對已有實作底子的人幾乎全對——他們正好能把省下的實作時間，升級成判斷與治理；但對完全的新人，它可能反而是個陷阱。判斷力無法在真空裡訓練；脫離了夠多的實作接觸，所謂的心智訓練很容易退化成背術語、覆誦最佳實踐——也就是這個領域最不缺、最容易被 AI 取代的那種淺層知識。判斷力的弔詭在於：它無法被直接傳授，只能被經歷。
四、搭梯子的難題：為什麼這塊集體被繞過
於是「如何幫後人搭梯子」成了目前最沒有定論、坊間課程也幾乎集體繞過的問題。
第一個原因是 vibe coding 對不同的人是兩種東西。對資深者，它是主動的選擇：他心裡其實有規格，只是判斷任務小到不值得寫下來，於是用直覺代替形式化規格——他隨時能掉下去寫 spec，只是選擇不要。對新人，它是被動的退路：他不是選擇不寫規格，而是寫不出來。表面上兩人都在「憑感覺寫」，但一個是踩著地板往下蹲，一個腳下根本沒有地板。
這也解釋了為什麼「先學 SDD 再學 vibe」對新人沒用——你沒辦法叫一個還不知道「對」長什麼樣子的人，先去把「對」寫成規格。規格是判斷力的輸出，不是輸入；它是直覺的下游。 你沒法靠先寫規格來反推出直覺。
於是架空形成一個會自我強化的閉環：沒有實作經驗 → 長不出判斷力 → 開不出規格 → 進不了 agentic / spec 那層 → 只能 vibe → 而 vibe 出來的東西，因為你沒有判斷力去審查，你連自己錯在哪都看不見 → 連 vibe 本身都無法讓你學到東西。
而這裡有個更隱蔽的傷害：傳統的爛 code 至少會用 bug、用三個月後的維護痛苦來教育你；但 AI 生成的爛 code 往往跑得起來、看起來很體面，它把過去那個會痛、會回饋、因而能教人的迴路給消音了。新人被剝奪的不只是實作機會，更是「從失敗中學習的回饋訊號」。這比單純「少寫了程式碼」嚴重得多。
第二個原因是商業上的：判斷力無法被打包成「12 週精通」。 它無法承諾明確的習得時程，因為它本來就不是被教會的，是被經歷出來的。一個誠實的判斷力課程，大綱大概只能寫「去做二十個會失敗的專案，然後每次都搞懂自己為什麼錯」——這賣不出去。於是市場理性地避開它，轉而去賣能被打包、能畫出進度條的東西：工具操作、prompt 技巧、框架語法。市場結構本身，正在系統性地把最重要、最難自動化的那塊能力，排除在教育供給之外。 這不是疏忽，是誘因使然。
那梯子最後會怎麼搭？合理的猜測是：它不會以課程的形態出現，而會回到某種師徒制。差別在於，以前師徒之間隔著的是程式碼，徒弟看著師父怎麼寫；以後隔著的是 AI 的產出，徒弟看著師父怎麼讀、怎麼質疑、怎麼判斷該不該信。實作的示範被審查的示範取代，但那個一對一、高頻寬、難以規模化的人際傳遞核心，反而被 AI 逼著重新變得重要。
這帶出一個反直覺卻可能成立的推論：AI 一方面把實作大規模規模化，另一方面，卻可能讓「能傳授判斷力的資深人才」變成一種更稀缺、更難規模化、因而更值錢的資源。
五、現場的合流：摩擦被系統性消滅
把鏡頭拉到實際工作現場，幾股力量會合流成同一個結果。
其一，維護工作的學校被拆了。 維護既有 codebase，傳統上是磨判斷力最好的場域之一：你被迫去讀別人的決策、去理解某段看似多餘的程式碼背後擋著什麼坑。但 Copilot 式的 vibe 維護把這座隱形學校也拆了——你不再需要讀懂上下文，只要描述局部改動，AI 就給你一段能塞進去的程式碼。維護被降級成一連串互不相干的局部修補，它不只沒在培養判斷力，還在主動侵蝕「閱讀與理解既有系統」這個判斷力的母體能力。
其二，理解鏈的斷裂。 沒進過 agentic 的門，就無法理解 harness 和 loop 在解什麼問題。因為這兩者本質上都在解「當你把大量工作交給 agent、卻信不過它」時的焦慮——harness 建護欄讓你敢放手，loop 把驗證本身也自動化。但一個還停留在 vibe 式局部修補的人，從沒有「把一大塊工作整包交出去、然後不敢 merge」的具體痛苦，對他來說，harness 和 loop 就是「為了解決他從未體驗過的問題而存在的解法」——空中樓閣。門檻不在概念難不難，而在你有沒有受過那個對應的痛。 於是「AI 應能推升生產力」的預期發揮不出來，根源不是工具不夠好，而是一道經驗的鴻溝。
其三，資安限制意外保留了最後的訓練場。 為控制風險（尤其在以專案為主、需處理客戶 codebase 的團隊），許多人退回 code snippet 式協作，由開發者手動整合。snippet 式協作本質上把人鎖在 vibe 模式——AI 只看得到碎片、給不出有架構意識的建議，於是整合與架構決策必須由人扛回來。這在資安上很合理，卻產生一個諷刺的副作用：它在無意間，反而保留了一塊判斷力的訓練場，因為人被迫做整合，就被迫去理解全局。
這帶出一個對個人很實際、甚至有點黑色幽默的推論：在一個合規要求嚴格（如 ISO 42001）、codebase 不能全開的環境裡工作，短期看是生產力的枷鎖，長期看，卻可能是少數還能逼著新人長出判斷力的地方。約束有時候不是能力的敵人，而是能力的溫床。 而當 codebase 全開、agentic 化阻力消失的那天，生產力會跳上去，但最後一塊還在偷偷訓練判斷力的場域，也會跟著消失——資安的鬆綁與訓練場的消失，是同一枚硬幣的兩面。
把這幾層收攏：它們其實是同一個力在不同切面上的展現——AI 系統性地移除摩擦，而摩擦恰恰是判斷力賴以生長的養分。 實作的摩擦、閱讀的摩擦、整合的摩擦、信不過而不敢放手的摩擦，每一道被消除的摩擦都在提升當下產出，同時悄悄抽掉一塊長期能力的地基。真正的難題從來不是「要不要用 AI」，而是：在一個摩擦被系統性消滅的世界裡，要刻意把哪些摩擦留下來？
六、摩擦的具現化：當判斷力被寫進 skill 與 policy
短期內，讓 AI 自己架護欄的情況會愈來愈多——在 skill / MCP 這些工具與協定的基礎上。而那些「該被保留的摩擦」，會具體體現在兩種載體上：嚴格的走 hook / skill（把摩擦硬編碼成不可繞過的閘門），指引的走 policy prompt（把摩擦軟性注入成傾向）。這套工具鏈，某種意義上就是「摩擦的具現化技術」——它讓資深者得以把腦中那些說不清的「這裡要小心」，外化成 agent 跑得到的規則。判斷力第一次有了可以被部分封裝、被傳遞的載體。
但這裡，前面那個「架空」換了張臉重新出現。它把生態重新分層成兩個物種：寫 skill 的人，和用 skill 的人。
而這道鴻溝比「資深 / 新人」更深。因為一個封裝得好的 skill，它的全部價值，恰恰來自於它把判斷的過程藏起來了。用的人得到乾淨的結果，卻完全看不到背後那串「為什麼要這樣防、為什麼這個 case 要特別處理」的推理。skill 越成熟好用，就越像黑盒，也就越徹底地把 judgment 從使用者眼前移走。封裝是能力傳遞的福音，同時是能力養成的墳墓——同一個動作。
這讓「一手精練的特規 skill 才是差異化價值」這個判斷變得格外深刻。網路上抓來的、團隊或組織標準化的 skill，是別人判斷力的結晶——你用它，等於租用了你自己沒有的判斷，它能讓你的產出及格，卻無法讓你成長。而你一手精練出來的 skill，它的價值根本不在那個 .md 檔本身，而在於你為了寫出它所必須經歷的整個過程：你得先痛過、先踩過坑、先在無數次 agent 跑偏裡看出模式，才寫得出一條真正有效的 hook。
換句話說——精練 skill 這件事，本身就是我們一直在找的那個「該被保留的摩擦」。 它沒有被 AI 消除，反而是 AI 把判斷力逼到的最後一個、也最濃縮的據點。所有低階摩擦被自動化拿走後，「設計約束本身」成了人類最後親手做、且最吃判斷力的活。所以「能寫出好 skill 的人愈來愈少」不是一個會被工具填平的暫時缺口，而是判斷力這種稀缺性，在新工具層上找到了它新的棲身之處——它沒消失，只是從「會寫好 code」搬到了「會寫好約束」。
七、這門專業的未來：高地早有住戶
最後，回到那個核心問題：當實作被 AI 拿走，工程師被迫上移到的那片高地——商業分析、需求探索、規格定義、人際溝通——它們有個共同點：沒有一項是軟體開發專業獨佔的。
這正是這門專業真正的危機，而且方向和大眾焦慮恰好相反。大眾問「AI 會不會取代工程師」，但更精準、也更不舒服的問題是：工程師被擠出熟悉的低地後，推進的那片高地，早就有人住在上面了——產品經理、商業分析師、領域專家，他們在「搞清楚要做什麼、為什麼做、講清楚給誰聽」這件事上，往往訓練得比工程師更久更專。所以工程師面臨的不是被 AI 取代，而是護城河改了位置，而新位置上早有守軍。
那麼，在這片人人都能參與的高地上，工程師還剩什麼別人替代不了？答案不在那幾項本身，而在一個更窄、更硬的東西上：唯有工程師，知道一個需求說出口之後，它在系統裡會長成什麼樣子、會在三個月後從哪裡裂開。
商業分析師能把需求探索做到極好，但他探索出的終究是「想要什麼」。而把「想要什麼」翻譯成「在這個系統的真實約束下，什麼可行、什麼會帶來看不見的長期代價、哪個看似小的決定其實鎖死了未來」——這層翻譯需要的是對系統如何崩壞的直覺，也就是整篇文章反覆指向的、只能被經歷不能被下載的判斷力。非軟體專業的人能定義「對的需求」（what），但普遍缺乏判斷「這個對的需求會不會生出一個爛系統」（what-it-becomes）的能力。而軟體這門專業真正拿不走的核心，一直都在後者。
由此預測這門專業的走向：
- 它不會消失，但重心會從「製造者」徹底移向「翻譯者與裁決者」。 工程師的價值不再來自「我能做出來」（AI 會做），也不完全來自「我知道該做什麼」（很多人都能做），而來自那個夾在中間、別人補不上的位置——站在「商業意圖」與「系統現實」的斷層線上，做雙向翻譯。 往一邊，把模糊的商業欲望翻譯成 AI 能執行、且不會長期反咬的約束（寫進 skill 與 spec 裡的判斷）；往另一邊，把系統的真實限制翻譯回商業端聽得懂的取捨。這個位置之所以穩，是因為它同時需要兩種稀缺：既要懂系統會怎麼壞，又要懂人到底要什麼——而大多數人只佔其中一邊。
- 但這個位置容納的人數，會遠少於今天的工程師總量。 翻譯者 / 裁決者本質上是個槓桿角色——一個這樣的人搭配一群 AI，能頂過去一整隊人。這門專業大概率不會消失，但會收窄、上移、並且兩極化：站上斷層線的少數人價值暴漲，停留在純實作的多數人，面對的是一條持續下沉的地板。前面談的「梯子被架空」，從個人成長的困境，到這裡放大成了整個職業的結構性問題——爬上斷層線的人會很穩，但通往那裡的梯子，正是被 AI 抽掉的那一截。
結論：唯一穿得過不確定性的硬核
要說有什麼能穿過這一切不確定性、值得押注，大概就是這串思考從頭到尾反覆指向的同一個硬核：
真正不會被取代的，從來不是「會寫程式」，而是「痛過、因而知道事情會怎麼壞」的那種判斷。
工具會一層層往上疊（vibe → SDD → agentic → harness → loop，後面還會有新詞），專業的名字或許也會換，封裝、傳遞、變現判斷力的形式都在變——但只要軟體還會在某個沒人預料到的地方裂開，就永遠需要一種人：他光看一眼，就知道這裡要小心。
而這種人的養成形式，大概是這波演進裡唯一沒被改變、也改不了的東西。skill 和 MCP 改變了判斷力的封裝、傳遞與變現，卻沒改變它的養成——它依然只能被經歷，不能被下載。 整串討論真正的收斂只有一句：無論抽象往上疊幾層，那個無法被抽象掉的硬核始終是同一個——有人得真的痛過，才知道要把什麼寫進規則裡。
這門專業的未來，於是濃縮成一個尚無定論的任務：怎麼守住、並且傳下去這一種人。
（本文為一段持續進行中的討論之階段性整理。隨著工具、方法與市場結構的演變，許多判斷仍會被修正。未完待續。）
參考來源
註：以下出處用於佐證文中的具體事實與數據；本文的論證與推論則為討論者自身的觀點。各家工具的指令、能力與定價變動快速，引用數據以查證當時（2026 年 6 月）為準，實際請以官方最新資訊為準。
- Vibe coding 一詞由 Andrej Karpathy 於 2025 年 2 月提出。見 Spec-driven development（Wikipedia）與 From Vibe Coding to Spec-Driven Development, Towards Data Science。https://en.wikipedia.org/wiki/Spec-driven_development；https://towardsdatascience.com/from-vibe-coding-to-spec-driven-development/ ↩
- 「三個月技術債之牆」的說法，見 Vibe Coding vs Spec-Driven Development (2026), Augment Code——該文指出 vibe coding 會撞上一道有紀錄可循的三個月牆，技術債在此複利累積成龐大維護負擔。https://www.augmentcode.com/guides/vibe-coding-vs-spec-driven-development ↩
- SDD 把「規格」與「實作」解耦、並藉此跨 session 與跨 agent 保存 context 的論述，見 From Vibe Coding to Spec-Driven Development, Towards Data Science。其思想根源（1960 年代 NASA 工作流程、2004 年 TDD 與 Design by Contract 的結合）見 Spec-driven development（Wikipedia）。 ↩
- Karpathy 承認 vibe coding 時代結束、進入 agentic engineering 的引述，見 From Vibe Coding to Spec-Driven Development, Towards Data Science。 ↩
- 「harness engineering」一詞由 HashiCorp 創辦人 Mitchell Hashimoto 推廣（提出六階段 AI 採用歷程），並經 Martin Fowler 與 Thoughtworks 的 Birgitta Böckeler 進一步框架化。見 Harness Engineering — The New Discipline...（codenote.net）與 Harness engineering for coding agent users, Martin Fowler。https://martinfowler.com/articles/harness-engineering.html ↩
- OpenAI 官方文章 Harness engineering: leveraging Codex in an agent-first world（2026 年 2 月）：repo 約含百萬行程式碼，三位（後增至七位）工程師驅動 Codex 合併約 1,500 個 PR，全程零手寫程式碼。作者 Ryan Lopopolo（OpenAI Frontier Product Exploration）。https://openai.com/index/harness-engineering/；亦見 InfoQ 報導 https://www.infoq.com/news/2026/02/openai-harness-engineering-codex/ ↩
- harness 的五層結構（工具編排、驗證迴路、context 與記憶、護欄、可觀測性），見 Harness Engineering: Making AI Coding Agents Work in 2026, Faros AI。https://www.faros.ai/blog/harness-engineering ↩
- Loop engineering 於 2026 年 6 月成形：Boris Cherny（Anthropic，Claude Code 負責人）與 Peter Steinberger（OpenClaw 創作者）的發言點燃討論，Google 工程師 Addy Osmani 正式命名整理。見 Addy Osmani, Loop Engineering https://addyo.substack.com/p/loop-engineering；Agentic Loops: From ReAct to Loop Engineering, Data Science Dojo https://datasciencedojo.com/blog/agentic-loops-explained-from-react-to-loop-engineering-2026-guide/。Claude Code 的
/loop與 Codex 的/goal為對應的產品化實作。 ↩ - 開發者信任下滑數據出自 Stack Overflow 2025 年開發者調查：信任 AI 程式碼準確性的比例由 40% 年減至約 29%，約 46% 開發者明確不信任其輸出，66% 將「幾乎對、但不完全對」列為首要挫折。轉引並整理見 AI Generated Code Technical Debt（buildmvpfast）https://www.buildmvpfast.com/blog/ai-generated-code-technical-debt-management-2026 與 AI Coding Productivity Paradox（philippdubach.com）https://philippdubach.com/posts/93-of-developers-use-ai-coding-tools.-productivity-hasnt-moved./。DORA 2025 報告亦有相近的低信任比例佐證。 ↩
- METR, Many SWE-bench-Passing PRs Would Not Be Merged into Main（2026 年 3 月）：在調整維護者判斷的雜訊後，約有一半通過 SWE-bench Verified 測試的 AI agent PR，實際維護者不會 merge；研究同時提醒不應據此推論這是模型的根本能力上限（agent 未獲得依回饋迭代的機會）。https://metr.org/notes/2026-03-10-many-swe-bench-passing-prs-would-not-be-merged-into-main/ ↩
- 審查瓶頸數據：高 AI 採用度團隊 merge 的 PR 數大增（一說 +98%）、PR 體積增大（+154%），但審查時間增加（+91%）、組織層級 DORA 交付指標幾乎持平。見 Faros AI 與 DORA 2025 相關整理，轉引見 AI Coding Productivity Paradox（philippdubach.com）。另有 2025 年 7 月一項隨機對照研究發現，16 位資深開源開發者使用 AI 後實際多花 19% 時間，但自評以為快了 20%——同屬「生產力悖論」的佐證。 ↩