Claude Code 把檔案路徑藏起來了：一個產品管理的反面教材
用戶要一個顯示檔案路徑的開關，官方說「用 verbose mode」。結果 verbose mode 太吵，官方開始砍內容——等於用最麻煩的方式重新發明一個設定開關。月付 200 美金的工具，這種細節見真章。
產品管理
AI 落地的真正魔王：不是模型能力，而是『信任缺口』
模型越來越強，但專案落地常常慢到最後退回人工審核。問題多半不在技術，而在可控性、可追溯性與責任歸屬組成的『信任缺口』。
別再把馬車改得更快：第一性原理在產品迭代裡最實用的用法
很多產品失敗不是因為不夠努力，而是努力方向錯了。用第一性原理把問題拆回「用戶真正想解決什麼」，比追競品功能更能救你。
「講清楚了，卻還是做錯」：需求溝通最常見的問題其實是知識的詛咒
你一定看過這種需求對話：
* RD：「文件沒寫啊。」
* PM／使用者：「這不是理所當然嗎？」
兩邊都沒說謊。
真正的問題通常也不是能力，而是知識的詛咒（Curse of Knowledge）：你越熟某個領域，就越容易把自己的背景知識當成「大家都知道」。
於是你自以為講清楚了，對方卻在另一套假設下把事情做完，最後變成重工與互相抱怨。
## 需求不是「規則」，需求是「在真實情境下會發生的事」
很多需求文件一開始就想寫規則：
* 這個功能應該要怎樣
* 這個流程必須要怎樣
* 這個欄位不可為空
問題是：規則背後藏著大量未寫出的假設。
而這些假設，往往就是錯誤的來源。
## 解法：用例子把隱藏假設逼出來（Specification by Example）
實例化需求的思路很簡單：
不要先談抽象規則，先談「會發生的場景」。
把需求寫成三段：
* Given：在什麼情境下（前置條件）
* When：做了什麼操作（行為）
* Then：會得到什麼結果（可驗收的輸出）
例子一攤開，