專案並非任務的簡單堆砌－ 當前AI 在自動化複雜工作時仍有核心瓶頸：AI 雖能處理單一任務，卻難以駕馭整個專案。 作者@snewmanpv 是Google Docs 創始人，他以軟體工程為切入點，強調專案管理的“整體大於部分之和”，並質疑一些“短期AGI 時間線”論調——即AI 一旦掌握月級任務，就能輕鬆擴展到年級規模。文章透過作者親身經歷和邏輯分析，客觀剖析AI 的差距，提醒我們高估AI 「填補空白」的速度。 核心論點：專案不是任務的“樂高積木” 作者開頭指出，評估AI 能力時，人們常將工作拆解為「任務清單」（如編碼、調試），但這是一種簡化思考。現實中，任務間邊界模糊，資訊會「滲透」：完成子任務時，你不僅產出程式碼，還會累積對問題、程式碼庫或資料的新洞見。這些「副產品」可能在後續任務中發酵，推動整體策略調整。如果將子任務分配給獨立的AI 智能體，並在完成後丟棄其“記憶”，這種學習鏈就會斷裂，導致AI 難以形成連貫的進步。 作者引用放射科醫師為例：他們不只解讀影像，還需與病患和同事溝通──這些「模糊」活動無法簡單分割。同樣，在軟體工程中，專案管理依賴高層次技能，如持續適應和跨任務洞察，這些在任務清單中鮮有體現，卻對成功至關重要。 對照案例：從小專案到巨獸的躍遷為闡明觀點，作者分享兩段經歷，突顯規模帶來的質變： · 小型專案：Writely 原型（約1人年） 2005年，筆者與兩位夥伴以4個月敲定Google Docs 的前身Writely。這是個「即興」過程：快速搭建伺服器、UI 和同步機制，問題來了就修。整個系統易於腦中把握，無需長遠規劃，更靠「直覺」和即時應對。雖有技術挑戰（如瀏覽器相容），但整體像「熱身賽」——無需系統性工具或經驗累積。 · 大工程：Scalyr 系統（約100人年） 2011年起，作者領導數十人團隊，以10年建置日誌分析平台Scalyr，用於診斷複雜Web 應用的故障。這要求全新技能： · 系統性問題解決：不只逐一修bug，而是辨識模式，一次消除整類問題（如伺服器協調故障）。這依賴多年經驗和判斷力。 · 策略規劃：中途遇客戶流失等危機，團隊需重塑方向－評估架構、分解步驟、驗證假設、及早糾偏。這像是“指揮交響樂”，而非單人獨奏。 · 效能診斷：在千伺服器間瞬間分發任務，需精選關鍵數據點監控，避免資訊過載。 作者強調：小型專案的「智能體技能」（如任務分解、糾錯）在大專案中往往失效，甚至成障礙。 Writely 的「即興」在Scalyr 會釀成災難。 AI 的「升級門檻」：超越當前範式的認知技能文章借用管理學概念「What Got You Here Won't Get You There」（帶你到此的技能，無法帶你更遠），論證AI 進步曲線並非線性。當前AI（如Claude Code）擅長短期任務，但擴展到大專案需「深層認知」： · 情境管理：大項目生成海量細節，AI 須篩選相關訊息，而非淹沒其中。 · 持續學習與適應：資深工程師會「客製化」技能，針對專案痛點優化程式碼和調試習慣—— AI 的「一次性」訓練難以模擬這種累積。 · 後設認知：不只執行，還需反思流程、預測瓶頸、迭代方法。作者引用AI 研究員Nathan Lambert 的觀察：現代訓練管道從簡單幾步，演變為多團隊協調的複雜網絡，需「預判風險」的領導力。 這些技能非“通用智能體”，而是領域特定、經驗鑄就。 AI 掌握1年專案時，100人年規模仍遙遠。 結論與啟發：自動化需等待“AI 領導者” 作者重申：真正影響力的軟體工程專案（如Google Docs 的演化）往往從小起步，卻需大量投入。任務級自動化只是起點；全自動化需AI 獨立領導百人年專案。這挑戰了「AI 能力曲線向上彎曲、即將爆發」的樂觀圖像——歷史經驗顯示，規模躍升需全新R&D，而非簡單縮放。 文章地址
