工具越強、團隊越難搞？軟體工程師的協作心理學
AI 時代的工程團隊，問題從來都不是技術
> Meta Shift
我的判斷很直接：AI 工具讓個人工程師的生產力提升了，但同時也讓團隊裡的人性問題更難被忽視。以前你可以用「大家都很忙」當藉口，現在 AI 把重複性工作清掉之後，剩下的全是需要人跟人協作才能解決的問題。Cat Hicks 這本《The Psychology of Software Teams》出得很是時候 — 不是因為它很潮，而是因為工程界終於有人用科學數據在講這件事，不是靠感覺、不是靠 agile 教練的直覺。
這本書的作者 Cat Hicks，UC San Diego 量化實驗心理學 PhD，創辦了 Catharsis 這個科學顧問公司，做的事情是幫組織用人本證據驅動轉型。這不是一個純粹賣管理學課程的人在寫的書，數據是從頂尖工程組織和全球數千名工程師身上蒐集來的。
你現在在工程團隊裡看到什麼？
我最近看到的現象有幾個層次：
第一層：個人生產力數字好看，團隊交付卻沒有等比例提升。
GitHub Copilot 在 2022 年的研究數據顯示，使用 AI 輔助的工程師完成任務的速度快了 55%。（來源：GitHub 官方研究報告）這個數字很漂亮，但同一家公司的產品還是照樣 delay，bug 還是照樣從 staging 流到 production。個人 velocity 跟團隊 throughput 之間有一條鴻溝，沒有人認真去量那條鴻溝有多寬。
第二層：code review 的 dynamic 正在變得很奇怪。
現在很多 PR 是人跟 AI 合寫的。reviewer 不確定他在 review 的是工程師的判斷還是 AI 的輸出，被 review 的人也開始對 feedback 不太確定要怎麼回應 — 「這個問題是 AI 生的，不算我不懂」。這聽起來很蠢，但我確實在幾個工程師社群裡看到這類對話。accountability 變模糊了，而 accountability 模糊的地方，文化就開始爛。
第三層：「10x Engineer」的迷思被 AI 具象化了，然後炸開了。
過去「10x Engineer」是個神話，大家心知肚明這個說法主要是用來合理化某些人的自大行為。現在有了 AI，真的有人因為工具用得好，在短時間內產出十倍的 code volume。然後主管不知道該怎麼評估這件事，其他工程師也不知道這是否代表自己的績效很差，團隊裡的比較焦慮開始發酵。Cat Hicks 在書裡有一章叫「More Bands and Fewer Rockstars」，就是在戳這個問題 — 搖滾明星文化在軟體業一直是個毒瘤，AI 把這個毒瘤放大了。
為什麼技術問題往往是人的問題？
這讓我想到 2010 年代初期 DevOps 剛興起的時候。當時大家的問題不是沒有工具 — Jenkins、Chef 都已經存在了。問題是 Dev 和 Ops 兩個部門的人不說話，文化上互相甩鍋，工具再好也沒用。解決 DevOps 問題的不是更好的 pipeline，是讓兩個部門的人開始共同承擔 on-call 責任，讓他們有理由坐下來講話。
現在的 AI 導入也是同樣的邏輯。你可以買最貴的 AI coding assistant，但如果你的 team lead 對 AI 生成的 code 有隱性偏見、或者你的資深工程師把 AI 當成是「讓初級工程師失業的威脅」，這些工具的 ROI 就會遠低於預期。
Cat Hicks 在書裡拆解了幾個關鍵的心理機制：
The Performance Paradox（第四章）： 工程師在被評估績效的時候，反而會迴避有學習價值的挑戰性任務，選擇自己熟悉、有把握的事。AI 工具的引入沒有解決這個問題，甚至可能強化了它 — 因為現在你有更多 cover 可以讓「看起來很忙」變得更容易。
Psychological Safety 不是 HR 的事： 書裡引用的研究數據（基於 Google 的 Project Aristotle 以及 Hicks 自己的研究）指向同一個結論：team psychological safety 是預測工程團隊效能最強的單一因子，比技術 stack、比工程師個別能力都更有預測力。（來源：Google re:Work、書中研究）但在我看到的大部分工程組織裡，psychological safety 要不是被當成 buzzword 貼在牆上，要不就是被完全忽略。
Conflict or Coalitions： 這是第五章的主題，核心問題是：你的團隊在面對衝突的時候，是真的在解決技術或方向上的分歧，還是在玩政治？工程師很擅長把「我不喜歡這個人」包裝成「這個 architecture decision 有問題」。AI 工具的引入，因為它改變了每個人的工作方式，會觸發更多這類隱性衝突。
老實說，這不是什麼新問題。Frederick Brooks 在 1975 年的《The Mythical Man-Month》就講過了 — 軟體開發不是線性擴展的，加人不等於加速，因為溝通成本是 O(n²)。快五十年後的今天，我們把人換成 AI，溝通成本的結構沒有根本改變，複雜度倒是又多了一層。
Meta 判讀：這是 Meta Shift，不是 Patch Note
我的判定是 Meta Shift，原因有三：
第一，問題的暴露速度加快了。 AI 工具清掉了大量的瑣碎工作，讓工程師有更多時間面對真正的軟體設計和人際協作問題。過去你可以靠「大家都很忙」掩蓋文化問題，現在這個藉口越來越難用了。
第二，組織開始願意花錢量化這件事。 過去「軟體團隊心理學」聽起來像是給工程師的心靈雞湯，現在因為 DORA metrics、SPACE framework 這些衡量工具的普及，越來越多組織開始意識到 team health 是可以被量化、被管理的。（目前這個市場的規模沒有公開數據，但科技組織對 developer experience 的投資正在顯著成長。）
第三，人才市場的壓力正在重塑優先順序。 在裁員潮和 AI 替代焦慮的雙重夾擊下，能夠建立高心理安全感、低政治內耗的工程文化，已經變成留住頂尖工程師的關鍵競爭力，不再是 nice-to-have。Gartner Consulting 的 Eli Israel 評論這本書時說了一句話很直白：「Psychological safety、learning、collaboration 不是福利，它們是基礎設施。忽視它們，你的系統就會掛掉。」
我的建議：現在該做什麼
如果你是個別工程師：
先認清楚一件事 — AI 工具提升了你的個人 output，但它沒有幫你在 team 裡建立信任、沒有幫你在 code review 裡說出不受歡迎的真相、沒有幫你在 sprint planning 裡推掉不合理的需求。這些才是決定你在一個組織裡能活多久、活得多好的核心技能。不要因為 Copilot 讓你寫 code 變快就覺得自己的護城河夠深了。
如果你是 Tech Lead 或 Engineering Manager：
認真去讀 DORA 和 SPACE 這兩套 framework，把「心理安全感」這件事從 HR 座談會的議程移到你的週會上。最直接的 action：你上次在 incident review 裡讓一個工程師在不怕被罰的狀況下講出真正的 root cause 是什麼時候？如果你想不起來，那就是問題所在。
如果你是 CTO 或 VP of Engineering：
值得看這本書，預計 2027 年出版（來源：Routledge 官網），但現在就可以開始做的事是：停止只看 velocity 和 story points，開始量化 team health。至少季度做一次 psychological safety survey，把結果公開跟團隊討論。這不是在做軟性管理，這是在維護你的工程基礎設施。
最後，Cat Hicks 書名裡有一個字很關鍵：「resilience」。技術債可以還，架構可以重寫，但一個失去信任感、陷入政治內耗的工程團隊，復原成本遠遠超過任何技術問題。這件事在 AI 工具滿天飛的現在，只會越來越重要，不會越來越不重要。
延伸閱讀
Waiting7777
WoW Arena 冠軍轉前端，用電競 meta 思維拆解技術趨勢。
相關文章
AI監管+3AI 大老們喊了幾年「管管我們吧」，然後呢？一份帶點諷刺的時間軸
從「說一套做一套」的角度切入：AI 高管喊監管不是新鮮事，但每次都有具體的時機背景。整理這條時間軸背後的商業動機 — 喊監管，往往是為了鞏固自己的護城河。
2026年9月18日 · HW SHU · 5 分鐘閱讀
繼續閱讀 →SnapAI Agents+13Snap 又在推 AR 眼鏡 AI 功能了 — 這次有機會嗎？
從「Snap 為什麼還在賭 AR 硬體」的角度切，分析 Specs + AI 這個策略對 Snap 的商業意義，以及在 Apple Vision Pro 和 Meta Ray-Ban 夾擊下，這條路還走不走得通。
2026年9月18日 · HW SHU · 6 分鐘閱讀
繼續閱讀 →AI Agents工作流程+5設計師用 AI Agent 自己刻網站了 — 工程師的邊界在哪裡？
從「設計師用 AI 直接幹工程師的活」這個角度切入——這不只是工具使用心得，而是職涯角色邊界正在模糊的真實案例。
2026年9月16日 · HW SHU · 7 分鐘閱讀
繼續閱讀 →這篇文章對你有幫助嗎？
每週一篇 — 技術趨勢背後的商業邏輯
AI 產業在變什麼、工程師該注意什麼——拆清楚寄到你的信箱。