Velocity Sickness: What Happens When Your Whole Team Gets 10x Faster — Matt Dailey, Ref.
三句話摘要
當 AI 讓個人工程師加速 10 倍時，團隊卻陷入協作混亂；解決之道是建立共享的文檔驅動計畫層，讓人類掌控決策，Agent 專責執行。 轉向共享文檔驅動的計畫層，讓人類掌控決策、Agent 專責執行，是釋放 AI 速度同時保留團隊協作和產品掌控權的關鍵。 速度病的四大症狀：PR 爆炸（合併衝突破裂）、方向分散（團隊各自跑向不同目標）、Agent 破產（每天起 12 個終端機，隔天全忘，重新開始浪費代幣）、決策權喪失（讓 Agent 做關鍵決定等於放棄代碼所有權）。這些問題在個人層級就很棘手，放大到整個團隊就失控。
重點整理
重點- 1
速度病的四大症狀：PR 爆炸（合併衝突破裂）、方向分散（團隊各自跑向不同目標）、Agent 破產（每天起 12 個終端機，隔天全忘，重新開始浪費代幣）、決策權喪失（讓 Agent 做關鍵決定等於放棄代碼所有權）。這些問題在個人層級就很棘手，放大到整個團隊就失控。
- 2
工作模式的根本轉變：傳統工程是「計畫→實現→拋光」的線性流程，AI 時代變成「計畫（人類創意探索）→實現（Agent 執行，不需人工）→拋光（人類品質把關）」。核心工作已經從「實現」轉向「計畫」和「決策」——這才是表達工程師品味和創意的地方。
- 3
工具層級的錯配：IDE 和 Chat 都是為「實現層」設計的，但我們現在需要「決策層」工具。Chat 的問題在於隔離、短暫、無共享——重要決策在私密對話中進行，最後在代碼裡消失。文檔驅動方法則能提前對齐關鍵決策、建立持久的決策日誌、跨 Agent 共享上下文，讓整個團隊看見系統全貌。
- 4
從代碼速度到想法速度：真正的加速不是堆積代碼，而是更高效地探索想法空間。通過提前書寫和對齐計畫，工程師能識別哪些想法值得投資，減少重複工作、PR 衝突、和決策返工，同時讓 Agent 保持無狀態（所有狀態存在文檔，新 Agent 可直接上手）。
實用技巧與重點
乾貨- 速度病定義：
- 個人或團隊因 AI 輸出突增帶來的壓力，導致「輸出暴增卻無實際影響」(output without impact)
- 四大問題：
- Too many PRs emerge（PR 爆炸）
- Moving in too many directions（方向分散）
- Declaring agent bankruptcy（Agent 破產：重複工作、浪費代幣）
- Critical decisions made by agents（決策權喪失）
- 案例：
- 時事通訊作者：每週產出一本書的內容量，但讀者無法跟上，頁面無人閱讀
- 工作流程對比：
- 舊時代：計畫 → 實現（個人頭下工作）→ 拋光 → 出貨
- AI 時代：計畫（人類）→ 實現（Agent）→ 拋光（人類評估）
- Chat vs. 文檔：
- Chat：隔離、短暫、無共享、腦子放空、決策不透明
- 文檔：共享、持久、清晰、可被對齐、決策可追蹤
- 三個立即可做的事：
- 區分「計畫」和「拋光」兩個工作檔位，根據當下任務選用合適工具
- 把計畫當作「軟體系統入口」(portal to software system)，讓 AI 幫你掌握系統全貌、凸顯關鍵決策點
- 把計畫分享給團隊而非直接交給 Agent，讓隊友提供反饋、集思廣益
結論
結論“轉向共享文檔驅動的計畫層，讓人類掌控決策、Agent 專責執行，是釋放 AI 速度同時保留團隊協作和產品掌控權的關鍵。”
完整解析
詳細Matt 在演講開場拋出的核心問題是：當個人工程師用 AI 加速 10 倍，團隊卻沒有跟上。個人速度快了，但團隊協作出了問題。這個現象他稱為「速度病」——輸出爆炸卻缺乏實際影響。
具體表現有四個。第一是 PR 爆炸——工程師被 AI 加速沖昏頭，推出一堆 PR，然後發現根本無法全部合併，導致衝突和隊列崩潰。第二是方向分散——個人記不住誰在做什麼，團隊各自跑向不同目標，沒有凝聚力。第三是「Agent 破產」——每天起 12 個終端機執行各種 Agent 任務，隔天醒來全忘了，只好全刪重來，結果是白費力氣、重複工作、浪費代幣。第四，也是最危險的，是決策權轉移——當 Agent 做了關鍵決定，工程師就喪失了代碼所有權，進而喪失了對產品的控制權。
Matt 用一個時事通訊作者的故事來說明這個問題的實質。這位作者用 AI 大幅提升了內容產出，每週寫一本書的量。但問題是：讀者每週根本讀不完一本書。所以雖然頁面很多，但大部分無人閱讀。這正是速度病的寫照——我們被速度麻痺，忘記了真正的目的是創造影響力，是讓作品被看見、被理解、改變人們的生活。
根本的解決方案源於對工作模式變化的理解。傳統工程是「計畫→實現→拋光」的線性流程，每個階段都由人類完成，工具（IDE）是為這種方式設計的。但 AI 改變了遊戲規則——計畫和拋光仍然是人類的創意工作，但實現可以完全交給 Agent。這意味著我們的工作模式從「沉浸式編碼」轉變為「決策導向」。
既然工作核心不再是「實現」，而是「計畫」和「決策」，工具也應該跟著改變。現有的工具（Chat、IDE）都是為實現層設計的——隔離、短暫、無共享。但決策層需要不同的東西：共享的、可持久保存的、能清晰記錄決策理由的文檔系統。
Matt 把這個新工具稱為「軟體系統的入口」。想像自己像 Tony Stark，對系統說「告訴我什麼重要」，AI 就幫你找出相關的代碼片段、設計決策、約束條件，組織成一份清晰的計畫文檔。這份文檔不是交給 Agent 做完就忘，而是成為團隊的共享精神模型。所有 Agent 都基於同一份文檔上下文工作（保持無狀態），人類掌控所有決策點，這樣既能利用 AI 的速度，又不失去產品的掌控權。
這個轉變產生的連鎖效應很強大。首先，PR 審查變簡單了，因為決策已經在計畫階段對齐。其次，團隊方向統一了，因為計畫是共享的。再次，沒有 Agent 破產，因為所有狀態都在文檔裡。最後，人類掌控決策，產品始終是人的理性表達。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
