Code Abundance and Product Taste
Code Abundance and Product Taste 指的是：當 Codex 這類 coding agent 讓「建東西」變便宜後，組織真正稀缺的能力不再只是實作，而是判斷該建什麼、哪些版本值得保留、何時用文件、何時用原型，以及何時該出貨。BusinessNext 轉述 OpenAI Codex 產品與工程負責人 Ambrosino 的說法：OpenAI 內部接近全公司使用 Codex，結果不是少數工程師產能提升而已，而是不同角色同時產生大量 prototype 與功能變體。
核心判斷
- 實作不再是最貴階段：傳統 PRD / prototype / implementation 流程假設程式碼最貴；AI coding 讓這個假設開始失效。
- 瓶頸改成選擇與整合：當同一功能有許多無協調版本，問題變成哪個好、好在哪裡、哪些部分該合併到產品主線。
- 品味不是美感而已：品味包含美學、系統架構、產品方向與媒介選擇；有些問題該寫文件，有些才該做原型。
- 模型時機會改變產品命運：同一個 AI-native 產品形態，可能因模型品質差三個月而從失敗變成可行。
AI-native product management 補充
AIHAO 的 AI 時代產品管理文章補上一個 PM 視角：模型能力像「正在上升的地面」，所以 PM 不能只用穩定技術時代的長週期 PRD / roadmap / mockup 流程。當 Claude.ai 用來思考策略、Claude Code 用來做 prototype / eval、Cowork 用來處理溝通與脈絡，PM 的工作更接近快速產生候選、用評測與用戶回饋收斂、再判斷哪些東西值得進產品主線。
這也把「產品品味」拆得更具體：不是只靠直覺決定美醜，而是在工程產能放大後，管理過量 prototype、跨角色 builder、設計流程縮短、PM bottleneck 與模型時機。對 ai-native-engineering-organization 來說，PM / 設計 / 工程角色邊界融化不是職稱消失，而是每個角色都要更清楚自己負責的判斷面。
安全是產品判斷的一部分
BusinessNext 2026-07-17 轉載 Full-stack PM 對多份公開 Anthropic Interview Guide、候選人分享與官方安全文件的整理，補上 AI-native PM 的風險判斷面：文章觀察到，面試題不只要求產品 sense、execution、metrics 與跨部門協作，也會把 capability、使用者價值、商業利益與 AI safety 放在同一個取捨問題裡。這表示在高風險 AI 產品中，安全不是上線前才加的獨立檢查，而是產品方向與成功條件的一部分。
可重用的判準是：遇到沒有標準答案的產品決策，要求團隊明確說出風險、價值取捨、錯誤回復與升級路徑，而不是只套用 Product Framework 或把最後結果修到看起來正確。這與 ai-native-enterprise-governance 的 owner、權限與 audit 邊界，以及 eval-is-spec 的可測量驗收相連；前者定義誰承擔決策責任，後者檢查系統行為，但兩者都不能替人決定什麼風險可接受。由於這是轉載者對多份公開材料的綜合解讀，不把它當成 Anthropic 官方招聘政策，信心維持 medium。
Spotify / Honk 補充
BusinessNext 轉述 Spotify 工程副總 Niklas Gustavsson 與 Claude Code 負責人 Boris Cherny 的對談，讓「實作便宜後的產品品味」多了一個工程底座案例。Spotify 內部超過 99% 工程師每週使用 AI coding tools，PR 頻率增加 76%，但 Gustavsson 承認更難的是把 PR、部署、工作項目、A/B 測試與產品成果連起來；產出速度本身不能證明使用者價值增加。
這個案例把 ai-code-validation-bottleneck 與本頁接在一起：先用 monorepo、一致技術棧、Backstage、Fleet Management、CI / lint / test 讓 agent 改得動也驗得過，接著才面對更上游問題——哪些 prototype 值得留下、哪些變更能自動合併、哪些想法應該進主線。換句話說，AI 放大的是既有工程紀律與決策品質，不是取代它們。
Work archetypes 補充
BusinessNext 轉述 Claude Code 負責人 Boris Cherny 的 5 種 work archetypes，讓本頁的「品味」更接近組隊與責任分配問題。當 PM、設計師與工程師都能把文件假設提前變成可操作 prototype，交接物從 PRD / mockup 變成可點擊、可測試、可推翻的東西；但瓶頸也從「誰會建」移到「哪個方向值得上線、誰能停止錯誤方向、誰負責清理與維護」。
這個框架把角色拆成 Prototyper、Builder、Sweeper、Grower、Maintainer。重點不是取消職稱，而是避免團隊只獎勵新增功能；在 AI 讓第一版產出變便宜後，Sweeper / Maintainer 反而成為控制技術債、功能膨脹與長期可靠性的稀缺能力。對 ai-native-engineering-organization 而言，這是組織設計層的補強：跨職能不是人人都做所有事，而是每個產品狀態都有明確 owner。
設計工作流補充：大量生成後再策展
BusinessNext 轉述 YC Head of Design Eve Bouffard 的工作方式：當 Claude 或 Codex 能處理 shader、模板與重複排版，設計師的瓶頸便從軟體熟練度轉向創造力、脈絡提供、方向定義與策展。她會把 Pinterest moodboard、截圖與專案資料放進脈絡，先生成 16 個可丟棄的網站版本，再用並排工具比較、挑選與組合；但對 SOTA Zine 實體封面仍刻意維持零 AI，表示探索速度與最終工藝可以分開處理。這把本頁的「品味」具體化為一個 workflow：讓 agent 擴大候選空間，人負責設定方向、過濾 generic 結果、維持品牌一致性與決定哪些成果值得留下。
軟體成本歸零論的邊界
AIHAO 的軟體工程辯論補上一個重要拆分：AI 讓 code generation 變便宜，不等於可信軟體的總成本歸零。歸零派多半把一次性 prototype、短暫 app 或模型產出的程式碼，外推成所有 production SaaS 都會拋棄式；反方則把成本拆回需求澄清、發現正確行為、驗證、維運、相容性與長期責任。可重用的判準是先問系統是否有持久狀態、真實使用者、合規要求與 on-call 責任，再判斷 coding agent 帶來的是速度提升、更多 disposable prototype，還是可直接降低總成本；文章的產業數字與引用屬二手綜合，需保留來源歸屬。
這個拆分也說明為什麼「重新生成代替 debug / refactor」不能當成普遍工程策略：生成是可平行化的部分，正確行為的發現與驗證仍是瓶頸。當大量候選被快速產生，產品品味、取捨與 integration review 的稀缺性反而上升；因此本頁與 ai-code-validation-bottleneck、ai-native-engineering-organization 應一起使用，而不是把 AI 產碼比例當成產品價值的 proxy。
從個人品味到系統思考
BusinessNext 轉述 Netflix CPTO Elizabeth Stone 的案例，將「品味」的範圍再往上游推進：AI 讓各職能都能快速做 prototype，卻沒有讓「什麼是好」變得不稀缺。真正需要保留的人類判斷包括：agent 產出的程式是否可上線、體驗是否對會員有價值、功能能否跨內容類型與平台規模化，以及局部解法是否應抽象成共用基礎設施。換句話說，產品品味不只是挑畫面或挑功能，也包含能否退一步看系統、辨認 source of truth 與長期整合成本。
這個案例把本頁的選擇問題連到 ai-native-engineering-organization：builder 供給增加後，組織需要用 design system、共用元件與明確護欄把品質外部化，再讓所有職能共享一層會隨模型變動的 AI fluency 期待。它也提醒 ai-code-validation-bottleneck，候選不只要通過單次測試，還要避免形成跨系統不一致的 Frankenstein；Netflix 的 keeper test 與「卓越即作業系統」則是人才密度與決策責任的管理案例，不是可直接複製的普遍制度。
從大量生成到品牌品味
BusinessNext 2026-07-24 的品牌對談把「大量生成後再策展」推到非軟體內容：AI 可加速基礎素材、資料整理與轉換內容，但批量生成會帶來 AI 審美疲勞，讓品牌看起來同質化。可重用的判準不是拒絕 AI，而是先把品牌內容與轉換內容分層，再由人保留真人感、核心信仰、差異化與是否妥協的判斷；這補充 YC 設計工作流中的「生成候選、人做策展」，並與 ai-native-enterprise-governance 的 human-review gate 相接。
同一篇文章提出上線前 AI 初篩、魔鬼代言人與 Brand Voice Guide。這使「品味」不只是最後挑一個好看的結果，而是把最壞解讀、禁用語、品牌邊界與具名核准者外部化；若數據只能告訴團隊發生了什麼，不能替團隊決定是否背離核心原則，就應保留 ai-cognitive-offloading-and-agency 的 agency gate。品牌案例屬對談與作者觀點，不當作通用行銷效能 benchmark。
AI 簡報：骨架與皮可外包，觀點與靈魂不外包
BusinessNext 2026-07-31 的簡報專題把「大量生成後再策展」延伸到溝通工作：AI 能快速整理資料、產生多套大綱與劇本、調整版面，但不能替講者決定哪個觀點最重要、如何回應聽眾的焦慮，以及什麼內容值得被相信。文章將簡報拆成邏輯結構的「骨架」、版面的「皮相」、講者內容的「肉」與個人風格的「靈魂」；可重用的分工是讓 AI 擴大候選與處理低價值排版，人保留觀點、取捨、脈絡與說服責任。
簡報的最小 AI workflow 可寫成：先定義受眾與目的，再讓 AI 產生多個結構／劇本，接著以批判性討論淘汰平庸方案，最後才調整視覺。這與 ai-cognitive-offloading-and-agency 的 agency gate、anti-sycophancy-prompting 的反迎合檢查及 ai-native-enterprise-governance 的具名 owner 相接；若把「肉」與「靈魂」也交給模型，產出可能看似完整，卻無法代表團隊真正要說服誰、帶對方走向哪個決策。來源是媒體轉載的簡報教練觀點，不是獨立溝通成效 benchmark。
BusinessNext 2026-08-05 的後續文章把這個 workflow 壓成開工具前的四題 gate：想讓聽眾做什麼決定、聽眾最在意或反對什麼、只能留下哪一句話，以及每頁是為了說服還是事後查閱。這四題把「目的」從抽象的受眾設定轉成可檢查的簡報輸出契約；若答不出來，應先補自己的觀點與說服邏輯，而不是再要求 AI 生成更漂亮的頁面。
Agentic Engineering Patterns 補充
AIHAO 2026-07-25 對 Simon Willison《Agentic Engineering Patterns》的導讀，將「程式碼變便宜」的下半句說得更完整：便宜的是產生、重構、補測試與探索性原型，昂貴的是確認程式真的能動、解對問題、錯誤可預期、文件一致且值得長期維護。這把本頁的產品品味接到工程證據：大量候選不是價值，能被驗證、理解與安全整合的候選才值得留下。
可重用的邊界是：產品品味決定「哪個問題與方向值得做」，agentic-engineering-patterns 決定「留下的變更如何被測試、手動探索、walkthrough、Git history 與 PR evidence 支撐」。這也提醒 harness-engineering-for-ai-coding 與 ai-code-validation-bottleneck，coding agent 降低 code generation cost，不會自動降低理解、驗證、整合與 ownership cost；文章是 AIHAO 對 Simon guide 的整理，不把個人 prompt 偏好或工具案例視為通用 benchmark。
長時程生成：產出便宜，品味與驗證仍稀缺
Karpathy 的實驗把 code abundance 推到互動內容：模型可以用約兩小時與 1M token 預算生成一個人類通常不會手工製作的 3D 世界，讓「客製化內容幾乎免費」變得可想像。但成果仍有粗糙與自我檢查瓶頸；人要決定這個世界是否值得保留、如何改善體驗，工程師則要補上可重播的視覺與互動驗證。這是 loop-engineering 與 harness-engineering-for-ai-coding 對產品品味的下游約束，不把生成量當成產品價值。
PM 從團隊配比轉成問題 owner
BusinessNext 2026-08-04 轉述 Whatnot 產品長 Tom Verrilli 的觀察：當 AI 讓 prototype、試錯與部分實作變便宜，PM 的稀缺性不應用「每幾名工程師配一名 PM」的固定比例衡量，而應回到具體結果與未被擁有的問題。Whatnot 的做法是每六個月先列出必須成真的結果與關鍵專案，再把 PM 配給真正需要產品判斷的問題；這可能讓某些工程團隊長時間沒有掛名 PM，並不等於沒有產品工作。Verrilli 也把「理解客戶、商業與技術並在三者間轉譯」視為 AI 時代更耐久的產品能力。
這補強了本頁的產品品味判準：在產碼與候選方案大量增加後，組織要先問「哪個問題值得被解、誰真正擁有結果、怎麼證明做對」，而不是用簡報、對齊會議或 roadmap 完整度代替判斷。Whatnot 以實作型 case study、PRD 與口頭辯護檢查細節能力的做法，可與 eval-is-spec、ai-code-validation-bottleneck 連結；但它是單一公司訪談案例，不足以證明更少 PM 或更資深 PM 對所有組織都更好。
從 code abundance 到 intelligence inflation
「智慧通膨」把本頁的 code abundance 往更廣的知識工作推進：當文字、分析、程式與方案候選都能大量生成，產品品味只是其中一個下游瓶頸，問題定義、領域脈絡、責任承擔與現場執行也會變得更稀缺。這個框架可用來區分「產出更多」與「創造更高價值」，但文章的 token、API 價格與勞動市場推論仍是來源歸屬。
- intelligence-inflation 關注認知輸出供給增加後的價值重定價；本頁關注大量候選出現後如何做選擇、整合與驗證。
1% 法則：模型能力上升前的產品窗口
BusinessNext 2026-08-07 整理 Jeff Dean 的觀點：若通用模型已能完成約 20% 的任務，產品可能已進入會被下一次模型更新吞掉的區域；較有機會形成持久優勢的切入點，是通用模型成功率只有 0% 至 1%，但團隊能靠專有資料、領域知識、工具與可靠 eval 逐步把成功率推高。這不是「1% 成功率必然是商機」，因為仍要先確認真實需求、資料可得性與是否能建立驗收方法。
這把產品品味接到 model-harness-fit 與 coding-agent-as-optimizer：真正稀缺的不是再做一個模型能很快補上的薄 app，而是選對問題、寫清楚規格、建立模型看不到的 context 與工具，並用可重跑的任務級 eval 證明自己持續變好。對 discovery-loop 而言，科學與工程研究自動化正是把人類的問題選擇與驗收責任，和 agent 的長時程執行能力分開。
「少做一點」：反功能膨脹與雙速設計投資
BusinessNext 2026-08-17 整理 OpenAI 產品設計負責人 Ian Silber 的觀察：AI 先壓縮構想與原型生成，不會自動壓縮使用者驗證、內部回饋與跨團隊對齊。因此設計師不必用每天交付多少程式碼和工程師比較產能，反而要先問功能是否真的需要存在、是否能延伸既有系統或元件。這把「少做一點」從個人效率口號轉成反功能膨脹的產品判斷，並延伸 ai-native-engineering-organization 的角色與責任重設。
來源還提出兩個可重用的產品設計判準。第一，把能力做成可組合、可被模型自行串接的底層積木，而不是互不相容的一次性體驗；這與 generative-ui、agent-experience 的介面可操作性相接。第二，按技術穩定度分配投入：仍可能被下個月技術推翻的想法，可以用短週期公開試作；確定要成為主體驗的能力，才值得反覆淘汰候選、打磨細節並蒸餾回簡單介面。這不是降低驗證標準，而是把探索速度與 production 品質分開；真正難的是判斷何時該切換。來源中的調查、內部倍數與訪談觀點均屬 attributed claims，不是設計生產力 benchmark。
研究投資組合：敢押大注，也要砍掉好產品
BusinessNext 2026-08-24 整理 Sam Altman 的訪談，將 AI 研究描述成冪次法則形狀的投資組合：最好的少數下注可能貢獻超過其餘全部，因此可以接受大部分賭注失敗，但前提是命中時的價值足以改變方向。這把「產品品味」往資源配置上游推進：不是只挑哪個 prototype 好看，而是要判斷哪個問題值得承擔機率、算力與機會成本。
同一個框架要求團隊能殺掉「還不錯」但不再是最高價值的產品，將人力與算力轉向更重要的主線；但單一創辦人的訪談不能證明冪次法則適用於所有研究或產品決策。可重用的 gate 是 定義高價值假設 → 估算成功時的槓桿與失敗成本 → 設定停止／轉向條件 → 用現實回饋更新機率，並與 discovery-loop 的題目選擇、frontier-model-release-governance 的安全成本及 agent-experience 的產品化瓶頸一起看。
DHH：從指定路徑轉向描述問題
BusinessNext 2026-09-01 整理 DHH 在 Lex Fridman Podcast #501 的觀察：當 agent 能處理更多實作與路徑選擇時，過度指定「怎麼做」可能反而把使用者的舊經驗套回模型；先描述問題、目標與模糊方向，再用實際產物做差異評估，可能更容易發現原本說不清楚的需求。這是 DHH 對自身工作方式的案例，不是「模糊 prompt」在所有任務都優於精確規格的實驗結論。
這個案例也把品味拆成兩個不同 gate：第一是用問題、願景與使用結果選擇值得探索的方向；第二是用架構、測試、成本與長期 ownership 決定哪些候選能進主線。DHH 在 Basecamp 5 的設計師 vibe coding 實驗中，觀察到個別 PR 看似合理、合在一起卻破壞整體架構；因此「能做出來」與「值得留下」仍是不同問題。
Omarchy Quattro 的案例則把大量候選與人類策展接在開源維護上：DHH 自述由 agent 先篩掉重複、錯誤或低價值 PR，再保留人類的合併決定。這補強本頁原有的「產碼便宜後品味稀缺」判準，但 PR／plugin 數量是單一專案的維護者自述，不是開源品質或採用成效 benchmark。
和既有概念的關係
- ai-code-validation-bottleneck 說明 code 供給暴增後的驗證瓶頸；本頁補上更上游的產品取捨、PM bottleneck 與方向瓶頸。
- loop-engineering 可以把生成、審查與修正做成閉環，但閉環仍需要人類或組織定義什麼值得優化。
- coding-agent-as-optimizer 把 agent 視為優化器；本頁提醒目標函數本身來自產品品味與市場時機，不是 agent 自動知道。
- ai-native-engineering-organization 補上組織層：PM、設計師與工程師都能建 prototype 後，norms、review 與協作邊界要重設。
- replit-agent-eval-scale 也提到人類品味在 eval、架構與產品決策中介入；BusinessNext 與 AIHAO 兩個來源把同一問題放到 Codex、PM 與跨職能組織脈絡。
對 AI Ark wiki 的意義
對 aiark-loop-engineering 來說，這是 Ponytail gate 的產品版：不要因為 agent 能產生更多候選，就把每個候選都 ingestion。watch loop 應該保持「少量、高重用、可驗證」；實作與擷取便宜，不代表 index、log、concept space 可以無限制膨脹。