You Can't Prompt the Room: The Last Skill AI Won't Replace - Balázs Horváth, VisualLabs
三句話摘要
AI 時代軟體開發的真正瓶頸已從寫代碼轉移到確定應該構建什麼，需要透過需求分析與人際溝通能力來確保產品價值。 AI 時代的關鍵競爭力已從編寫代碼轉向透過商業分析與需求挖掘來確定正確要構建的產品，這將決定企業是構建被廣泛使用的成功系統，還是構建被閒置的失敗產品。 代碼已商品化，需求分析成為競爭優勢：當所有團隊都能用 AI 快速生成代碼時，區別在於誰能更準確地理解商業需求。過去 13 年講者從測試工程師、功能顧問到創辦公司，始終充當商業與技術的橋樑，這項技能在 AI 時代變得更加關鍵。
重點整理
重點- 1
代碼已商品化，需求分析成為競爭優勢：當所有團隊都能用 AI 快速生成代碼時，區別在於誰能更準確地理解商業需求。過去 13 年講者從測試工程師、功能顧問到創辦公司，始終充當商業與技術的橋樑，這項技能在 AI 時代變得更加關鍵。
- 2
故事地圖是最實用的需求收集工具：將使用者流程拆解為主流程（支援系統中的「聯繫→分類→解決→結案」），再在每一步下挖掘使用者故事，能清晰識別 MVP 需要構建什麼。每個故事應包含「角色」「做什麼」「為什麼」的標準格式，因為 AI 對此格式訓練充分。
- 3
價值架構設計（VAD）流程：價值→流程→架構→設計：先確認為誰解決問題、成功的定義是什麼、什麼會讓他們拒用、是否能改變決策，再反推需要構建的系統。這個思考過程避免了「構建速度快但無人使用」的陷阱。
- 4
改變 KPI 指標衡量成功：停止計數「發布功能數」，改為計數「被使用超過兩次的功能數」。另要警惕「演示即可交付」和「功能點擊率高但重複使用率低」的反面模式。
實用技巧與重點
乾貨- 具體例子
- 內部黑客松：21 個 AI 代理想法中 17 個被放棄（無業務價值或無數據存取），4 個產生巨大影響
- 支援系統使用者故事地圖主流程：聯繫 → 分類 → 解決 → 結案
- MVP 涵蓋的第一層故事：「擷取進來」「分類緊急度」「草擬答覆」「記錄到系統」（共 4 個故事）
- 第二層故事（待辦清單）：讀取情緒、指派團隊、建議後續行動、檢查滿意度
- 決策四問
- 誰的問題？（指定具體角色/人物角色）
- 成功的樣子是什麼？（量化的成果）
- 什麼會讓他們拒用？（平台限制、易用性、資安考量）
- 改變什麼決策？（目標是影響使用者決策）
- 反面模式與警示
- 功能發布速度快，但採用率低
- 使用者試用新功能但不重複使用（單次體驗高但頻度低）
- 演示很棒但無法投入生產
- PRD 未經真實使用者驗證就開發
- 立即行動清單（下周一開始）
- 審計當前追蹤的錯誤指標
- 將 KPI 從「上季發布功能數」改為「被重複使用超過兩次的功能數」
- 將最強的技術人才轉向客戶對接和商業需求定義
- 在開發前執行故事地圖或商業模式圖
結論
結論“AI 時代的關鍵競爭力已從編寫代碼轉向透過商業分析與需求挖掘來確定正確要構建的產品，這將決定企業是構建被廣泛使用的成功系統，還是構建被閒置的失敗產品。”
完整解析
詳細在 AI 時代，軟體開發的競爭格局已經改變。講者指出，過去限制產出的瓶頸是能否寫出好代碼，但如今所有開發團隊都能透過 AI 快速生成品質相近的代碼。當代碼生成的成本和時間大幅下降時，真正決定軟體成敗的因素轉移到了「確定應該構建什麼」這個環節。講者用公司內部黑客松的例子說明：21 個 AI 代理構想中，有 17 個因為無法存取必要數據或沒有實際商業價值而被放棄，只有 4 個產生了重大業務影響。這充分反映了需求理解的重要性。
講者強調，建立這種需求理解能力的關鍵不是更強的技術棧，而是人際互動和商業分析的軟技能。他用「你無法向會議室提示詞，只能向 AI 提示詞」這句話概括核心差異。支援系統的故事地圖是他推薦的最有效工具：首先畫出使用者的完整旅程（聯繫客服→分類問題→解決問題→結案），然後在每個階段下挖掘具體的使用者故事。MVP 版本只需完成第一層的四個故事（擷取、分類、草擬、記錄），而讀取情緒、團隊指派、建議後續行動等則列入待辦清單供未來迭代。這種結構化方式特別適合 AI，因為大型語言模型在這類標準化格式上受訓練充分，能產生更準確的設計與代碼。
更重要的是建立正確的價值觀框架。講者提出了「價值架構設計」（VAD）流程：從「我們在為誰解決什麼問題」開始，深入四個關鍵提問——誰的問題、成功定義、拒用因素、決策影響——然後逆向推導必要的系統架構與流程改變。這與傳統產品管理思維相似，但在 AI 時代被賦予了新的經濟學意義：當所有人都能低成本地開發時，勝負手在於誰能更早、更準確地確定正確的方向。
講者也警告了常見的失敗模式：團隊發布功能的速度很快，但實際採用率很低；使用者嘗試新功能後便不再使用；或者花時間做出漂亮的演示系統卻無法轉換成生產系統。這些都反映了沒有真正理解使用者需求。他建議將 KPI 從「本季發布多少功能」改為「有多少功能被使用者重複使用超過兩次」，同時應該將公司的最強技術人才重新配置到客戶對接和需求定義的角色上，而非純粹的編碼工作。最後，他推薦每個專案在動手編碼前，都應該進行一次故事地圖或商業模式圖的規劃會議，確保整個團隊在構建的「是什麼」上達成共識。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
