為什麼 AI 不會加速你的業務流程

現代組織中盛行的觀點認為人工智慧（AI）是提高生產力的萬靈丹。當市場下滑或效率成為企業的首要目標時，人們的直覺反應往往是「投入 AI」。其假設很簡單：如果 AI 能在幾秒鐘內生成程式碼或文本，那麼從構思到部署的整個流程都必然會成比例地加速。

然而，這種觀點忽略了系統思考的一個基本真理：加速流程中的某一部分並不一定會加速整個系統。事實上，它往往只是將瓶頸轉移到其他地方，或者暴露了上游輸入端的脆弱性。

The Visual Bottleneck Fallacy

當觀察專案時程表時——無論是透過 Gantt chart 或 BPMN diagram——最耗時的階段幾乎總是執行階段（例如：軟體開發）。對管理者而言，這看起來像是最明顯的優化點。直覺反應是增加更多資源或實施 AI 工具來縮短該特定區塊的持續時間。

但長時程並不自動代表問題起源於此。正如原作者所指出的，軟體開發並非關於打字；而是關於將一個複雜、通常模糊的問題轉化為電腦可以安全且具擴展性地執行的精確解決方案。

The Upstream Problem: Requirements and Clarity

大多數技術流程中的真正瓶頸並非「創作」的行為，而是請求的清晰度。一個模糊的功能需求，例如「一旦銷售完成就向用戶發送郵件」，這並非程式碼問題；這是一個定義問題。它需要回答關鍵問題：什麼觸發了「完成」狀態？郵件的內容是什麼？如何處理錯誤？

當 AI 被引入這個過程中時，問題往往會更加劇烈。有一種常見的誤解，認為 AI 能讓開發者變成專案經理，從而繞過詳細的需求範圍界定（scoping）。事實上，AI 需要更多的精確度，而非更少。

"Vague requirements get vague results."

如果你提供給 AI 一個模糊的提示詞（prompt），它會生成一個看起來合理但錯誤的解決方案。要從 LLM 中獲得正確的結果，人類必須提供細節程度——如果這些細節提供給人類開發者，本來就已經能大幅提升生產力了。AI 並沒有消除對需求範圍界定（scoping）的需求；它只是將精確度的負擔從開發者的直覺轉移到了提示詞的規格說明上。

The "Steam Horse" Era of AI

許多組織目前正處於 AI 採用的「蒸汽馬」階段。當蒸汽機最初被發明時，人們想像中的交通工具未來是拉著傳統馬車的馬形蒸汽機。他們試圖將新技術強行塞入舊有的流程形式中。

同樣地，公司正將 AI 應用於現有的、臃腫的流程，卻不去質疑為什麼這些流程會存在。如果一個法律審批流程緩慢，是因為律師正在追蹤五個不同的人以獲取不完整的文檔，那麼增加一個 AI 來總結這些文檔並不會解決底層的協調失敗問題。

Insights from the Field: Throughput vs. Latency

關於這個主題的社群討論突顯了幾個關鍵的細微差別，這些差別進一步複雜化了「AI 速度」的論點：

1. Throughput vs. Latency

有些人認為 AI 將焦點從延遲（latency，即單一任務完成的速度）轉移到了吞吐量（throughput，即可以同時處理多少任務）。雖然單一功能可能生成得更快，但組織的開銷（code reviews、security audits 和 cross-team alignment）仍然保持不變。這是 Amdahl's Law 的一種體現：整體加速比受限於流程中序列化、依賴於人類的部分。

2. The Risk of "Vibe Coding"

對於「vibe coding」的擔憂日益增加，即在沒有進行深入探索的情況下，僅根據 AI 生成的迭代版本快速交付原型。雖然這縮短了到第一個原型的週期，但它可能會延長到最終產品的交付時間。如果沒有前期的設計和用戶訪談，團隊可能會花更多時間在「解開」錯誤的假設，並在不斷變化的介面中重新培訓用戶。

3. The Small Team Advantage

小團隊具有優勢。

有趣的是，AI 可能會成為小團隊最終的顛覆性工具。大型企業通常被「正統方法論」和龐大的協調開銷所拖累。一個擁有極少官僚主義的小型、敏捷團隊，可以利用 AI 來完成比大集團更龐大的工作量，有效地繞過那些扼殺大企業的組織瓶頸頸。

Conclusion: Fixing the Input, Not the Tool

如果你想真正加速你的流程，重點不應放在用於執行的工具，而非輸入端的品質。正如 The Goal 中的核心教訓：瓶頸應該獲得可預測、高品質的輸入。

AI 是一個強大的加速器，但將加速器應用於一個破碎的流程，只會讓破碎的結果產出得更快。為了實現 AI 的真正潛力，組織必須停止詢問「AI 如何能讓這件事做更快？」並開始詢問「為什麼這件事從一開始就這麼慢？」