當產品上架一天就被 AI 抄襲，唯一的護城河或許是「吃你的狗糧 (Dogfooding)」
2026 年走到現在，看著身邊每個人都能用 Claude Code 或 Codex 快速做出小工具與產品，相信很多創作者跟創業者心裡都浮現過同一個焦慮：
> 如果今天 A 發布了一個新產品，明天 B 就能用 AI 直接抄襲出來，那 A 的護城河到底是什麼？
在之前的會員信〈產品被 AI 秒殺抄襲的年代，個人品牌是唯一護城河〉裡，我曾從「對外防禦」聊過個人品牌與真實性的重要；而若從「產品本身」來看，我想到的答案是：或許 Dogfooding（吃自己的狗糧）就是最好的護城河，因為抄襲者「不願吃你的狗糧」。
這封信，我想從科技業經典的 Dogfooding 聊起：先看它的由來與 AI 時代的轉變，接著看台灣代表案例 Heptabase，最後聊聊一般人與上班族如何從「眼前在意與想學的事」出發，找到打造 AI Native 服務的最佳啟動方向。
什麼叫做 Dogfooding？為什麼科技業把「自己用產品」稱為吃狗糧？
Dogfooding（完整英文是 Eating your own dog food）的意思很直接：
> 如果你相信自己做的產品很好，那你就應該先成為這個產品的使用者。
重點在於把產品放進你真實的生活或工作中持續使用，親自體驗問題，再帶回開發流程。
這個詞最早來自兩個故事：
1970 年代 Alpo 狗飼料廣告：演員 Lorne Greene 在電視廣告中強調，他真的把代言的 Alpo 飼料餵給自家的狗，傳達「連代言人自己的狗都吃」的信任感（另一說則是 Kal Kan 寵物食品總裁曾在股東會當場吃下自家狗罐頭）。
1988 年微軟的 
\\dogfood 伺服器：當時微軟開發 LAN Manager 網路管理軟體卻缺乏真實使用者，主管 Paul Maritz 寄出主旨為Eating our own Dogfood的內部郵件，架設\\dogfood內部伺服器讓員工先用，追問一個核心問題：「消費者究竟會不會真的使用我們的產品？」
它跟一般產品測試（QA）的差別在於：
| 比較項目 | 一般產品測試 | Dogfooding |
|---|---|---|
| 目的 | 驗證功能是否正常 | 驗證產品是否真的好用 |
| 使用方式 | 按照測試案例操作 | 融入日常工作流程 |
| 發現問題 | Bug、功能錯誤 | 操作摩擦、真實痛點、需求落差 |
例如假設我要開發 AI 會議紀錄工具，一般測試只看摘要做得準不準；Dogfooding 則是連續一個月用它記錄每場會議，這時你才會發現「摘要很準，但每次整理待辦事項都要花十分鐘，煩到根本不想繼續用」。
