（原始文章於 2026 年 10 月 27 日刊出於掘金，此為回顧整理。）
2026 年 10 月底，掘金作者「乘風gg」分享了一段飯局對話。他的朋友是某公司的技術負責人，開口第一句就是：「老闆讓我裁員 20%，下不去手啊。」這篇文章很快在工程師社羣裡被轉發，因為它碰到的不是技術問題，是組織問題：當 AI 工具真的讓團隊跑得更快，快出來的產能要放到哪裡。
半年前導入 AI Coding，半年後交出裁員名單
按照作者的敘述，這位朋友的公司在半年前從零開始建立 AI Coding 工作流，從本地的 AI 輔助編碼，一路走到雲端自主運行、再到多 Agent 團隊協作。授課過程中作者的觀察很直接：工程師並非排斥工具本身，而是公司業務量早已不足。業務沒有成長，提效的結果只有一種去處，就是同一批人做更多的事，或者更少的人做同樣的事。
另一個細節更值得留意。老闆一直要求這位技術負責人量化「AI 到底提效了多少」，而他始終交不出一個準確數字。這不是他不會算。提效數字太多，等於證明公司不需要這麼多人；太少，又顯得專案白做。這個數字從來就不只是度量問題，它會直接變成人力預算的依據。
被追趕的感受，是怎麼來的
文章裡基層工程師的回饋，描繪了一個具體的處境：以前一個人跟一到兩個專案就夠了，現在 AI 不停，人也不能停，還要不斷開出新專案來填滿多出來的產能。原本該背的責任照背，多出來的產能又變成新的績效要求。
用日常一點的比喻：這像是一條廚房出餐線，洗碗機裝好之後，廚師沒有因此早下班，而是被要求每天多出三十道菜。工具縮短的是單一工序的時間，但工時和責任範圍是由排班表決定的，而排班表握在管理層手裡。
從老闆的角度，這筆帳更簡單。文章原文的算式是：一個月薪人民幣一萬五的程式設計師，一年成本將近二十萬。如果團隊用 AI 之後產能沒掉、人數可以減，裁員就是最直接的成本手段。作者甚至點出一種兩難：不會用 AI 的先被裁，殺雞儆猴；很會用 AI 的，反而證明了公司不需要這麼多人。
這個邏輯並非這篇文章獨有。先前我們整理過的AI 越強、失業越嚴重？這篇被轉發的文章，成立的部分和沒根據的部分要分開看，同樣是在檢驗「AI 進步直接等於裁員」這條因果線：短期內成立的，多半是企業藉著工具重新議價人力；長期的就業結構變化，證據還不足。
蛋糕沒變大，提效就是分蛋糕的方式變了
飯局最後的結論，作者自己寫得很白：公司業務的蛋糕做不大，AI 提效的結局就是崗位融合、就是裁員，除非業務量跟著成長。這句話把問題拉回最基本的地方。提效工具本身是中性的，決定它變成「早下班」還是「裁員通知」的，是公司有沒有新的業務去承接多出來的產能。
對正在用 AI 工具的工程師與中階主管，這篇文章至少給了兩個可以自己檢驗的訊號。第一，看公司的業務線：如果新專案、新客戶、新產品在增加，提效比較可能轉成產出；如果業務停滯而管理層開始要求量化每個人的產能數字，那個數字大概率是為了人力規劃服務的。第二，看自己手上的工作有沒有從「完成任務」變成「不斷發明新任務」：產能被擠出來卻沒有地方去，最後會以加壓或減員兩種形式回到人身上。
這位技術負責人的處境則是另一層：他因為主導 AI 導入而更受老闆重視，但也每天承受底下團隊的怨氣。工具導入的成敗由他報告，名單也由他來開。中階主管 夾在中間的位置，在這一波 AI 導入潮裡只會更常見。
文章來源是一篇個人經驗分享，樣本是一家公司的一次飯局，它提供的是一個具體案例與一套觀察，而非統計結論。它之所以被廣泛轉發，是因為很多人在自己的公司裡認出了同樣的劇本：工具先進來，度量跟著進來，然後排班表改寫。至於 AI 最終會不會普遍壓縮軟體工程職缺，目前能確定的只有一件事：決定權不在工具，在業務有沒有長。
（筆名：沈安）