PART 1 · 速度從哪裡來
不是少開會，而是少讓資訊停在隊列裡
Cat Wu 把 Anthropic 的節奏描述成從數月、數週，縮到有些功能只需數天。這不代表每個想法都直接上線；核心是讓工程、產品、模型能力與使用者回饋更早相遇。當模型每週改變能力邊界，等季度規劃完成才驗證，往往已經在回答過時的問題。
對讀者最有用的翻譯是：AI 團隊的瓶頸不只在寫程式，也在等待「誰能決定現在值得做什麼、如何測試、何時停止」的時間。
PART 2 · 產品經理改變了什麼
程式變便宜後，判斷什麼該寫更昂貴
訪談反覆回到 product taste：生成能力讓原型與實作成本下降，但不會自動告訴你使用者真正需要哪個行為、哪個失敗模式不可接受，或功能應在何種不確定性下暫停。產品經理不再只交付規格，而要與工程一起建立可反覆驗證的假設。
先問能力邊界目前模型真能完成什麼，而不是簡報上預期它終將完成什麼。
再設計回饋把真實使用、失敗案例與評估訊號帶回下一輪，而不只看發表日。
最後做取捨速度不取消責任：哪些風險、品質或信任成本不能用「之後再修」處理？
「程式愈便宜，決定要寫什麼就愈有價值。」— Cat Wu 在訪談中談 product taste（意旨整理）
PART 3 · AI-native 團隊的節奏
每週交付不是 KPI；它是一個可被推翻的假設
Wu 主張團隊要能更頻繁地推出功能、觀察結果並調整。若把它誤讀成「永遠加速」，很容易把使用者當測試場。比較嚴謹的讀法是：把交付切成足夠小的可檢查單位，讓一個錯誤假設不必等到大型重寫才被發現。
尤其在 Claude Code、Cowork 這類會影響實際工作流程的工具上，功能是否看似會跑，不等於在真實任務中可靠。評估、可回溯性與人工判斷不是速度的對立面，而是速度能持續的條件。
PART 4 · 不要替訪談補上承諾
願景、目前能力與可驗證成果，必須分開
受訪者談到 AI 產品、組織設計與未來工作方式的方向，但這些不是已被所有外部資料證實的普遍結論。讀這類公司訪談時，可以同時保留兩件事：它揭示團隊正在優化什麼；它也天然帶有公司自身的選擇與敘事。真正值得追的是日後能否以具體產品行為、使用者成果與安全紀錄檢查。