人均配了 AI，為什麼公司還是沒變快？🤔 本質還是分散式系統問題

一句話概括：給個人配 AI 能加速 3 到 10 倍，但組織整體的產出週期幾乎不變——問題不在「人」這個節點上，在「人和人之間的協作依賴」這條邊上。這篇文章用三條分散式系統的老定律講清楚原因，再給一套不管你是 leader 還是個人開發者都能上手的具體做法。

週五下午五點，一個產品經理在群裡發了句「這個文案能今天出嗎」，

設計說「我這邊今天排不上，最快下週一」。

這條訊息掛在那裡，沒人 catch，直到下週一。這一幕，大概是過去一年裡，每個用上了 AI 的團隊都見過的場景——只不過它發生的頻率，並沒有像大家期待的那樣，隨著人均效率的提升而降低。

這不是個例。這半年問了幾個 AI-native 新創公司和大廠內部團隊，答案高度一致：個人的 workflow 被 AI 加速了 3 到 10 倍，但整個團隊的產出週期幾乎沒有變化。有的團隊甚至因為多了一層「review AI 產出」的環節，交付週期反而更長了。

這件事讓我想起十幾年前讀《人月神話》和分散式系統論文時學到的幾條老定律。

當時覺得那是講「軟體專案管理」的，現在發現，

• 把「團隊」換成「分散式系統」；
• 「人」換成「節點」；
• 「部門牆」換成「網路延遲」；

這幾條定律幾乎可以原封不動地套用在今天的 AI 組織效率問題上。

這篇文章想講清楚兩件事：為什麼人均 10x 換不來組織 2x，以及具體應該怎麼辦。

一、瓶頸不在節點，在邊

把一個幾千人的組織想像成一張有向圖：每個人是一個節點，每一次 review、對齊、審批，是連接節點的一條邊。給每個人配 AI，做的事是把節點的處理速度提升了 10 倍，但完全沒有動邊。而組織的整體吞吐量，恰恰是由邊決定的，不是由節點決定的。這個判斷，可以用三條經典定律精確量化。

1. Amdahl 定律：加速比被不可並行部分死死封頂

結論先說：哪怕個人被加速到無窮快，組織整體的加速比也有一個數學上的天花板，這個天花板由「不能被個人獨立完成、必須靠協作完成」的那部分工作占比決定。

想看推導的可以展開這一段，只想要結論的可以直接跳到下一條定律。

Amdahl 定律給出的加速比公式是：

S(n)=1(1−p)+pnS(n) = \frac{1}{(1-p) + \dfrac{p}{n}}S(n)=(1−p)+np​1​

其中 ppp 是任務裡可以被個人獨立完成、可並行加速的部分，nnn 是這部分被 AI 加速的倍數。關鍵在於極限：

lim⁡n→∞S(n)=11−p\lim_{n\to\infty} S(n) = \frac{1}{1-p}limn→∞​S(n)=1−p1​

舉個例子：如果 review、對齊會議、跨部門審批占了工作總時長的 40%（即 p=0.6p=0.6p=0.6），那無論個人被 AI 加速多少倍，組織整體加速比封頂在 2.5 倍——這還是理想情況，實際很多團隊的不可並行部分遠超 40%。

這裡有個容易被忽略的角度，值得多想一層：ppp 不是天生固定的常數。

AI 真正厲害的地方，恰恰可能是把原本必須跨部門商量的事，變成一個人可以獨立判斷完成的事，也就是提高 ppp 本身，而不只是加速 nnn。這也是為什麼本文後半段講的「給上下游做 skill」，本質上是在做提高 ppp 這件更難但更有效的事，而不是繼續在 nnn 上加碼。

2. Brooks 法則：協作成本按組合數增長，不是按人數線性增長

Fred Brooks 在《人月神話》裡講過一個反直覺的結論：給一個 delay 的專案加人，只會讓它更晚交付。

原因是 nnn 個人之間需要維護的溝通路徑數是 n(n−1)2\dfrac{n(n-1)}{2}2n(n−1)​，呈平方增長。

這條定律解釋了為什麼「給個人配 AI」根本沒碰到問題的根——AI 只是讓單個節點算得更快，節點之間要維護的 n(n−1)/2n(n-1)/2n(n−1)/2 條溝通邊，一條沒少。

3. 約束理論：系統吞吐量，等於瓶頸的吞吐量

高德拉特在《目標》裡的核心結論是：優化非瓶頸資源，只會在瓶頸前堆積更多在製品，不會提升系統整體吞吐。如果某個評審節點是瓶頸，給瓶頸上游的人配 AI，只會讓「待評審隊列」變長——上游產出速度上去了，下游處理速度沒變，隊列積壓，整體交付週期不但沒縮短，有時反而更長。

怎麼找到那個真正的瓶頸？ 最樸素但最有效的方法，是花一週時間，給團隊裡每個跨團隊協作的環節記一筆：這件事發出去之後，等了多久才收到第一次回應。不是處理時長，是等待時長。把這些數字擺在一起，排在最長的那幾項，幾乎無一例外就是真正的瓶頸——它們往往不是你以為的那個環節。

三條定律指向同一個結論：

定律結論對應現象Amdahl 定律加速比被不可並行部分封頂Review/對齊天然串行，個人 AI 碰不到這部分Brooks 法則協作成本按 n(n−1)/2n(n-1)/2n(n-1)/2 增長配 AI 沒有消除任何一條協作邊約束理論吞吐量=瓶頸吞吐量加速非瓶頸只會在瓶頸前堆積隊列AI 要真正提升組織效率，得作用在邊上——也就是人與人之間的依賴——而不是繼續往點上加碼。

如果你在的是一個幾個人的小團隊，不涉及跨部門審批，這套框架依然成立——只是「邊」從「部門之間的協作依賴」，變成了「你自己腦子裡，在開發、設計、營運幾個角色之間來回切換的成本」。個人身兼數職時，真正拖慢你的往往不是任何單項工作本身變慢了，而是切換角色、等外部回饋（客戶回覆、甲方確認）的那些空隙，道理是一樣的。

二、把「等回覆」變成「自己動手」：一次服務化改造

「給上下游做 skill」，說到底是一次很具體的改造：把一次沒有約定規則的等待，改造成一個有明確輸入輸出的自助介面。

「設計團隊做需求 → 排期 → 交付」

這條鏈路，本質上是市場團隊發出一個請求後，原地等待——回應時間取決於對方的排期和優先級，完全不可控。這是效率問題裡最常見的一種模式：請求方沒有選擇，只能等。破解它的辦法，業內早就有成熟路徑——把能力服務化，讓請求方可以自己動手，而不是排隊等對方動手。

原文裡幾個例子，拆開看都是同一件事的不同實例：

• 設計團隊給市場團隊一個能自助出物料的 skill，等於把「設計能力」變成了一個自助介面
• 研發團隊給設計團隊一個能做高保真原型的 skill，等於把「前端渲染能力」變成了自助介面
• 資料團隊給業務方一個能自助查數建看板的 skill，等於把「資料查詢能力」變成了自助介面

這不是在削弱上游團隊的專業價值，是把上游的能力介面化了。

二十年前，亞馬遜就用行政命令做過一次幾乎相同的事——2002 年，貝佐斯給全公司發了一份內部備忘錄（後來在業內被稱為「Bezos API 備忘錄」），要求所有團隊必須通過標準介面對外暴露功能，不允許團隊間私下繞過介面溝通，違反者會被解僱。這次改造，後來演化出了 AWS。

今天不一樣的地方是：當年靠 CEO 的強制令才能推動的服務化改造，現在寫一個 skill 的邊際成本已經低到很多團隊可以自發去做，不需要等一份行政命令。

大型組織很難一夜轉型成「按 loop 組織」的結構，但有一條更現實的路徑：不用先推翻組織架構，先讓局部團隊之間產出服務化的介面，協作路徑會先在局部變成自助的樣子，組織結構會被這些實際跑起來的路徑，慢慢「拽」著重排。不需要等一次自上而下的重組，先把介面發出去，重排就已經開始了。

這個思路和 Shrivu Shankar 在《The Transposed Organization》裡提出的「loop」概念一脈相承——他把這種組織形態定義為「一個人擁有從問題到部署方案的完整決策鏈」，專家的角色從直接執行轉向把判斷力編碼進 agent 可用的規範裡。這和本文說的「上游從工單處理者變成規範所有者」，講的其實是同一件事的兩種說法。

三、「教會同事，會不會取代自己」

這是推行這件事時最大的心理阻力，值得單獨講清楚機制，而不只是給一句「別擔心」。

傳統協作是一個工單模式：下游發一張工單，上游按隊列處理，處理完關單。這個模式裡，上游的價值等價於「處理了多少張工單」——人力越稀缺，價值越顯性，但也越容易在流程被標準化之後，第一個被自動化取代。

Skill 把這個模式換成了 PR 模式：下游直接呼叫 skill，自己先把事情做到七十分，上游不再是「從零處理請求的執行者」，而是規範的所有者——定義準則、審核關鍵改動、決定要不要把新的判斷規則合併進主幹。Anthropic 內容設計團隊做的 Clontent（一個專門協助生成產品內容文案的內部 agent），走的就是這條路：團隊成員每週投票決定要不要把新規則寫進 agent 的長期記憶，agent 遇到「起名字」這類超出內容團隊職責的事，會主動叫人來判斷——這不是執行者會做的事，是規範所有者才會做的事。

維度工單模式（舊）PR 模式（新）上游角色請求處理者規範／介面的所有者價值體現方式處理了多少張工單定義了多少條被下游複用的規則稀缺性來源人力有限判斷力稀缺對自動化的抵抗力弱強這也是為什麼 Chelsea Larsson（Anthropic 內容設計團隊的成員，Clontent 專案的主要推動者之一）會說，因為 Clontent，公司內部有遠比以前多的人了解了「內容設計」這個職能——她沒有把自己變成一個被工單吞掉的執行者，而是把自己升級成了內容規範背後的那個人。下游用得越多，規範制定者的存在感和影響力就越強，不是越弱。

這裡有個容易被忽略的前提：PR 模式能跑起來，是因為它不要求每一次都做到滿分。

七十分的草稿，加一個足夠便宜的人工合併機制，吞吐量會遠高於追求滿分但需要排隊等待的處理方式。這也是為什麼「agent 只要做到七十分就有價值」這句話，不是在降低標準，而是在換一種更有效率的品質控制方式。

四、什麼時候不該做 skill 化

前面講的都是這件事的好處，公允地說，它也有明確的邊界，不是所有環節都值得投入。

判斷依據，而不是執行動作的環節，先別急著 skill 化。 比如涉及價值判斷、需要為結果承擔責任的決策（要不要發布一個有爭議的功能，要不要為一個客戶破例），這類環節的核心難點不是「處理速度慢」，是「誰來負責這個判斷」，skill 在這裡幫不上什麼忙，硬做只會製造一種「看起來自動化了、實際責任更模糊」的假象。

協作頻率本身很低的環節，投入產出比不划算。 如果某個協作節點一個月只發生兩三次，花精力做一個 skill、維護它的邊界 case，成本可能比它節省的時間還高。這條建議看起來樸素，但恰恰是很多團隊推行 skill 化時最容易忽略的一步——先看頻率，再決定值不值得做。

沒人維護的 skill，會比沒有 skill 更糟。 skill 不是做完就一直好用的東西，業務規則會變，邊界 case 會累積，如果沒有人持續更新它，幾個月後它給出的答案會開始悄悄地錯，而且因為大家已經習慣了自助呼叫、不再走人工審核，這種錯誤反而更難被發現。這是所有「自助化」改造共同的風險，值得在推行之初就想清楚誰來維護、多久 review 一次。

五、具體怎麼落地

這套框架不管你在什麼角色上，都能找到能立刻上手的動作，按角色拆成了兩份清單。

如果你是 leader / 有組織決策權

• 先測等待時長，再決定做哪個 skill。 花一週記錄每個跨團隊協作環節的等待時長，排在最長的那幾項，才是真正值得優先做的。
• skill 的目標是七十分，不是一百分。 覆蓋最常見、最標準化的場景就夠了，剩下需要專業判斷的部分，保留一個「主動喊人」的機制。
• 把這件事變成明確的工作產出，不是隱性勞動。 給上下游做 skill 這件事，大概率不在任何人的 KPI 裡，容易被一拖再拖。靠自己自上而下推動，或者設一個專門的角色去做這件事，比指望個人自發靠譜得多。
• 定一個維護節奏。 哪怕只是每月看一次 skill 的輸出有沒有開始跑偏，這個動作決定了它是長期有用，還是三個月後變成一個沒人敢關但也沒人信的黑箱。

如果你是個人貢獻者 / 小團隊，沒有組織決策權

• 先從「自己」開始，不用等公司推動。 找出你自己每週被同一個人／同一個環節反覆卡住的那件事（比如總是要等設計師改文案排版，或者總是要手動匯出一份資料表），先做一個只服務你自己的最小化 skill——一個腳本、一個 prompt 模板、一份填空式文件都算。
• 做完一次，就把它變成一個「能複用的東西」。 哪怕只有你和身邊兩三個同事在用，只要它把「等對方回覆」變成了「自己動手」，這件事的性質就已經從「個人小技巧」變成了一個雛形介面——這正是本文說的「邊」被拆掉的最小單位。
• 不用追求完美，先解決自己的問題。 不需要一開始就想著「給全公司做標準化工具」，能穩定省下你自己每週幾小時的等待時間，這件事就已經值得做，後面自然會有人來問你「這個東西能不能也給我用」。

結語

人均 10x 沒有換來組織 10x，不是因為 AI 不夠強，是因為我們把 AI 用在了錯誤的地方——用在了點上，而組織真正的瓶頸，一直都在邊上。

給自己配 AI，優化的是一個節點；

給上下游做 skill，拆的是一條邊。

這件事不需要等一次自上而下的組織重組才能開始——不管你是團隊 leader 還是個人開發者，現在就可以先把自己的一部分能力，變成一個別人可以自己動手用的介面。

那條訊息不用再掛在群裡等到下週一了。這才是真正的開始。

六、參考文檔

• Fred Brooks, The Mythical Man-Month（人月神話），1975
• Gene Amdahl, "Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities", 1967
• Eliyahu M. Goldratt, The Goal（目標），約束理論（Theory of Constraints）出處
• Shrivu Shankar, The Transposed Organization，Shrivu's Substack, 2026.03 —— 本文第二節「按 loop 組織」部分的概念來源
• Anthropic Clontent / Chelsea Larsson 相關案例來源

原文出處：https://juejin.cn/post/7657956930892136475