# Unscript with Dave > 渴望時間自由、不受地點限制的 Software Engineer；真實記錄這段 Unscripting 旅程 Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts. Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`). ## Pages ### 關於這個 Blog URL: https://www.davehuang.io/about/ Last updated: 2026-07-24T14:46:43.000Z Hi 我是 Dave，一名軟體工程師，我想要寫出關於我如何從這世界獲得自由的思考與學習。我現在正在打造一款名叫 [Peak Pals](https://peakpals.io/?ref=davehuang.io) 的生產力工具。 我喜歡藝術、攝影、科技、咖啡，目前正走在成為獨立開發者的路上。 --- 這個 Blog 名稱來自於今年影響我很深的一本書： [UNSCRIPTED: Life, Liberty, and the Pursuit of Entrepreneurship](https://www.amazon.com/UNSCRIPTED-Life-Liberty-Pursuit-Entrepreneurship/dp/0984358161?ref=davehuang.io) ![](https://www.davehuang.io/content/images/2025/09/image-3-1.png) ### Writings URL: https://www.davehuang.io/writings/ Last updated: 2025-11-17T16:17:36.000Z _No content available._ ### Projects URL: https://www.davehuang.io/projects/ Last updated: 2025-11-17T16:19:25.000Z _No content available._ ### Tags URL: https://www.davehuang.io/tags/ Last updated: 2025-11-17T16:20:05.000Z _No content available._ ### 會員登入 URL: https://www.davehuang.io/signin/ Last updated: 2025-11-18T15:34:30.000Z 歡迎回來 Unscript with Dave 的世界！ > 本站使用 Ghost.org 會員系統，登入後就能留言、加入討論。 ### 會員註冊 URL: https://www.davehuang.io/signup/ Last updated: 2025-11-18T15:39:11.000Z 歡迎來到 Unscript with Dave 的世界！ 僅需留下名稱、電子郵件，便可註冊。 我很好奇你們的看法，歡迎與我討論！ > 本站使用 Ghost.org 會員系統，登入後就能留言、加入討論。 ### Unscript with Dave URL: https://www.davehuang.io/home-en/ Last updated: 2026-07-24T15:06:52.000Z Use the `Excerpt` as blog description: ![](https://www.davehuang.io/content/images/2026/07/-------2026-07-24-------10.56.53.png) ### About This Blog URL: https://www.davehuang.io/about-en/ Last updated: 2026-07-25T03:51:17.000Z Hi, I’m Dave, a software engineer writing about what I’m learning and how I’m working toward greater freedom in life. I’m currently building [Peak Pals](https://peakpals.io/?ref=davehuang.io), a productivity tool designed to help people live more intentionally. I love art, photography, technology, and coffee, and I’m recently into AI tech. --- The name of this blog was inspired by a book that had a profound impact on me this year: *UNSCRIPTED: Life, Liberty, and the Pursuit of Entrepreneurship*. by MJ DeMarco ![](https://www.davehuang.io/content/images/2026/07/37615314_10156600493762430_7707721225337831424_n.jpg) Me on my 1st business trip to SF ### Subscribe to my newsletter URL: https://www.davehuang.io/subscription-en/ Last updated: 2026-07-24T14:59:07.000Z `Title` & `Excerpt` : ![](https://www.davehuang.io/content/images/2026/07/-------2026-07-24-------10.58.10.png) ### Signin URL: https://www.davehuang.io/signin-en/ Last updated: 2026-07-24T15:05:14.000Z Welcome back to **Unscript with Dave**! > This site is built on Ghost.org. Signin to comment and join the discussion. ### Signup URL: https://www.davehuang.io/signup-en/ Last updated: 2026-07-24T15:05:17.000Z Welcome to the world of **Unscript with Dave**! Enter your name and email to sign up. I’d love to hear what you think—feel free to join the conversation! > This site is built on Ghost.org. Signup to comment and join the discussion. ## Posts ### 獨立開發者該如何選題？ URL: https://www.davehuang.io/domain-knowhow/ Last updated: 2026-08-30T14:39:01.000Z 自從看完《[Unscripted](https://www.amazon.com/dp/0984358161?lv=shuf&channelId=500&plpRedirect=mhFallback&ref=davehuang.io)》以及許多 [Starter Story](https://www.youtube.com/@starterstory?ref=davehuang.io) 的商業案例後，我就養成了在生活中觀察 SaaS 題目的習慣。 剛好身邊有不少經營中小型企業的朋友，每次聽他們分享公司經營上遇到的問題，我都會忍不住在腦中拆解他們的 workflow，思考其中有沒有什麼事情，可以透過我會的技術解決。 最近的一次聊天，就讓我找到了一個結合法遵與 RAG 的題目。我很快開始動手做 POC，除了寫程式，也一邊補足自己在 RAG 與法遵上的知識。 靠著 Claude Code 輔助，一開始的進展非常順利，隨著 RAG pipeline 與系統架構逐漸完整，我開始意識到，工程實作可能只是這個題目最容易解決的部分，真正困難的點在後頭：Golden set 的資料要從哪裡來？當一個法遵案例連我自己都看不懂時，該怎麼判斷系統的回答是否正確？Eval 又該由誰來做？ 這些問題最後都指向同一件事：這套系統能不能商業化，取決於我對 domain knowhow 的理解，以及能否把這份理解轉成可靠的交付。 對我來說，軟體系統有相對清楚的 verification 方式。但法律就沒這麼容易了，那是超出我專業範疇外的知識體系。 軟體與法律，兩者都需要有人為其負責，但法律答案即使附上法源，仍需要具備資格的人判斷，並且願意替結果背書。我沒有足夠的信心，單靠技術跨過這道門檻。 走到這裡，我開始省思：是我一開始就選錯了題目，還是這有辦法透過 skin in the game 來跨過？ ![](https://www.davehuang.io/content/images/2026/08/IMG_0643-1.jpg) 這是一隻英鬥 當我還卡在這個問題裡找不到答案時，LinkedIn 上的獵頭竟然剛好丟給我幾個 AI Native SaaS 的機會。我甚至還沒來得及把自己的思緒整理清楚，就進入了另一輪面試準備週期。這個專案就這麼被我擱置在一旁。 在幾輪面試下來，也剛好給了我機會看見資金更充足的新創，如何處理類似的 domain knowhow 困境。 比方說，以法律為題材的 AI 新創，他們有足夠的資金直接把律師與顧問納入團隊，有些人甚至就是公司股東。提供領域知識的人共同承擔風險，也共享產品成功後的利益。 很顯然，這種資本與組織規模已經超出獨立開發的範疇。但它呈現出的工作方式，很接近我嚮往的環境：工程師與領域專家長期待在同一個問題裡，也一起承擔產品最後能否交付的責任。 對我來說，這種合作最有價值的地方，是工程師能一路參與問題如何被定義、答案如何被驗證，以及產品最後如何交到客戶手上。 如果有機會加入這樣的團隊，我能透過自己的工程能力，把領域專家的判斷轉成可靠、可維護的系統，除了把需求做完，也逐漸弄懂為什麼要做、客戶真正重視的是什麼、技術上該怎麼取捨。Domain knowhow 便會在這個過程中累積。 這段面試經驗也讓我回頭檢視，自己對獨立開發的假設。 我原本把這條路想得很線性：找到一個潛在痛點 → 累積足夠的 domain knowhow → 搭配 technical skills 與執行力做出 POC → 確認有人需要之後，接著處理 distribution。 而問題就在這個順序。它假設我能先辨認出值得解的痛點，再把所需的 domain knowhow 補齊。 真的走進陌生領域後，我才發現，domain knowhow 很難像技術套件一樣，等到需要時再安裝。有些知識需要長期累積，有些資訊根本不在公域流通。更麻煩的是，一個題目是否適合獨立開發，可能在我真正理解它以前，根本沒有辦法判斷。 那麼，獨立開發者究竟該如何找到值得長期投入的痛點？又該怎麼累積足以解決它的 domain knowhow，最後把產品帶到願意付費的人面前？ 帶著這些問題，我回頭研究了最近接觸到的三位獨立開發者。 ## **三位獨立開發者，三種選題路徑** Jesse Hanley、Takuya Matsuyama 與 Jannis Fedoruk-Betschki 三人的背景跟產品截然不同，卻都從自身的職涯軌跡逐步累積，發展出一門能由一人或極小團隊長期經營的生意。 以下我會先簡單介紹產品，再用四個問題來拆解這三個案例： - 他解決了什麼問題？ - 他憑什麼能解決？ - 客戶從哪裡來？ - 驗證花了多久？現在走到哪裡？ ### **題目 #1: Bento by Jesse Hanley** [Bento](https://bentonow.com/?ref=davehuang.io) 是一套主打 Email 成功送達率與行銷自動化的平台，服務對象以 SaaS 和電商公司為主。 當初我會注意到 Jesse，是因為在 X 上看見 Marc Lou 跑去日本找 [Jesse](https://x.com/marclou/status/2069264657102336353?s=20&ref=davehuang.io) 玩。好奇之下，我開始爬文研究他到底是誰，也撈出了一系列 Podcast 訪談。 我很喜歡 Jesse 在 Podcast 上帶給我的感覺：務實、真誠、帶有溫度。而他也常在訪談中帶出自己的價值觀——他很重視家人與生活品質，他總是傾向把生意維持在小而美的規模，把時間跟專注留給真正重要的人事物。 #### **他解決了什麼問題？** Jesse 想解決的問題，來自他過去操作 Email 行銷的經驗。 行銷團隊寫了好的內容、設計了完整的漏斗，最後卻因為寄件信譽、DNS 身分驗證或共享 IP 裡的其他寄件者，讓信件直接進入垃圾郵件。既有工具的自動化流程編輯器也常常很難用，價格還會隨著聯絡人數暴增，即使多數名單根本沒有收到信。 Bento 最初走的其實是網站個人化的服務，當時還不是 Email 行銷產品。為了讓企業客戶看見個人化帶來的成效，Jesse 又加入分析與追蹤功能，記錄網站訪客的行為。上線後，他發現客戶對這些訪客數據的興趣，甚至高於原本的個人化功能。這讓他開始思考：既然已經知道訪客做過什麼，能不能直接根據這些行為採取下一步行動？於是他加入 Email 自動化，再一路往 SMS、交易型郵件與成功送達率深挖。 #### **他憑什麼能解決？** Bento 這題目與 Jesse 的工作經驗幾乎完全重疊。他早期替澳洲的保健品零售與電商公司負責系統、行銷及運營，後來又自己經營行銷公司，替客戶操作 SEO、廣告與 Email 行銷活動。等於他自己就是 Bento 的理想顧客 (ICP)，多年後才開始打造自己的工具。 Jesse 自學 Rails 與 React 進行全端開發，當遇到超過能力範圍的問題，就找更有經驗的工程師合作，再從對方提交的程式碼中學習。 #### **客戶從哪裡來？** Bento 的獲客方式也沿用他過去經營行銷公司的做法：長期在網路上無償的幫助別人。 Jesse 曾經連續三、四年把 Calendly 放在 [Twitter 個人檔案](https://x.com/jessethanley?ref=davehuang.io)，任何人都能直接跟他預約通話。他常常花一個多小時免費幫對方釐清問題，最後什麼也不賣。這些關係可能幾年後才變成客戶，或在某個朋友受不了 Mailchimp、Klaviyo 時，想起可以找 Jesse。 客戶進來後，他又透過創辦人親自提供的支援繼續推動口碑。US$30 與 US$3,000 的客戶都能直接在 [Discord](https://bentonow.com/docs/support?ref=davehuang.io) 找到他；他也會親自展示產品、協助資料搬遷、錄製教學影片。 小客戶介紹大客戶的情況反覆發生，客戶支援本身逐漸變成 Bento 最重要的獲客渠道之一。近年他也開始透過 Podcast 節目、贊助與訪談，反覆讓目標客群記得 Bento 的存在。 #### **驗證花了多久？現在走到哪裡？** 從 Jesse 的回顧看來，Bento 在開始前沒有經過一輪明確的市場驗證。當時他仍在經營自己的行銷公司，出發點之一只是很想寫程式、成為開發者。他找來在東京認識的 Andrew Culver 合作，第一年把數據分析、少量 Email 與自動化功能全塞進產品。Jesse 後來形容，當時的自己想替所有人做所有功能，結果一直沒有進展。 直到 COVID 疫情期間賣掉行銷公司，需要重新建立現金流，他才開始全心投入回 Bento。 這時他發現，使用者真正有迴響、也確實持續使用的是 Email 功能，才開始把產品往這個方向收斂。 如果只看市場驗證所需的時間，Bento 其實是三個產品裡最慢的。Jesse 邊經營行銷公司邊開發，花了約三到四年，才讓功能完整到足以被客戶視為既有 Email 服務商的替代方案。這場驗證沒有在幾週內跑完。他一路從客戶的使用狀況找線索，慢慢收斂產品定位。 但這段時間也換來了很深的產品認知。2026 年 3 月的 [Tropical MBA 訪談](https://tropicalmba.com/episodes/million-revenue-no-employees?ref=davehuang.io) 將 Bento 描述為一間年度經常性收入已超過 US$1M 的公司，換算後每月營收規模至少是 US$83K。Jesse 沒有公開精確 MRR，但整間公司大多數時候依然只有他自己，加上幾位兼職協作者。 ### **題目 #2: Inkdrop by Takuya Matsuyama** [Inkdrop](https://www.inkdrop.app/?ref=davehuang.io) 是一套專門為軟體工程師打造的跨平台 Markdown 筆記工具，支援離線使用、雲端同步、端對端加密與外掛系統。 我是在研究 [Peak Pals](https://peakpals.io/?ref=davehuang.io) 編輯器選型時，關注到 [Takuya](https://www.craftz.dog/?ref=davehuang.io)。他是我少數知道的日本獨立開發者，他也用 Ghost 自架 [部落格](https://www.devas.life/?ref=davehuang.io)，讓同樣身為 Ghost 用戶的我感到格外親切。 他非常認真地透過 [YouTube](https://www.youtube.com/@craftzdog?ref=davehuang.io) 經營受眾，用著他獨特的日本腔英語，分享自己的生活，以及一路面對的挑戰。他近期有一集講述自己如何在 AI Era 被搞到 [burnout](https://youtu.be/Mf%5F524J8fPE?si=qo62chYjCIHaPXKf&ref=davehuang.io)，讓我相當有共鳴。 #### **他解決了什麼問題？** 這個產品的起點非常直覺：Takuya 找不到自己想用的筆記軟體。（跟我開發 Peak Pals 的初衷很像！） 他當時用 Evernote 記錄開發筆記，但它並不適合存放大量程式碼片段與 Markdown。網頁版工具離線時不能用，透過 Dropbox 同步的編輯器又慢又吃 CPU，其他選項不是功能太少，就是複雜到讓他不想每天打開。試過一輪後還是找不到能長期使用的工具，於是他決定乾脆自己做一個。 #### **他憑什麼能解決？** Inkdrop 的領域認知首先來自 Takuya 自己。他就是目標用戶，每天寫程式，也每天記錄技術筆記。 他從青少年時期就持續開發軟體，工作上待過 Yahoo! Japan，也長期參與開源專案與接案。他曾經做出擁有 13 萬使用者的音樂應用程式 Walknote，卻完全沒有辦法變現。這段失敗讓他深刻認知到，下載量與商業可行性是兩件不同的事。到了 Inkdrop，他從第一天就採用訂閱制，並把客群限縮在願意為開發工具付費的人。 #### **客戶從哪裡來？** Inkdrop 早期的獲客幾乎都來自內容行銷。Takuya 持續寫下自己如何開發、獲得第一批客戶以及經營一人 SaaS，再把文章分享到 Hacker News (HN)。流量最高的時期，約九成新使用者都來自 HN。他沒有在部落格直接推銷產品，只是很誠實地分享自己做對與做錯的事情，反而慢慢累積了讀者與口碑。 2018 年後，獲客重心逐漸移到 devaslife YouTube 頻道。他拍自己的開發生活、工具與業餘專案，在影片裡自然帶到 Inkdrop。到了 2024 年，YouTube 一度帶來 70–80% 的新使用者。後來他也建立付費用戶才能加入的 Discord、舉辦線上聚會；這些管道未必帶來大量新客，卻讓核心用戶更願意留下。 #### **驗證花了多久？現在走到哪裡？** Takuya 沒有在開發前進行用戶訪談或架產品 waitlist。他先清空了手上的接案，接著給自己三個月的時間完成 MVP，並在 2016 年 6 月把封閉測試版丟上 Hacker News。文章登上首頁後，短時間內帶來超過 1,000 人登記測試。這些使用者提供錯誤回報與功能建議，也讓他從使用數據裡觀察到確實有人每天使用。這是 Inkdrop 最早的市場驗證。 產品在 2016 年 10 月正式收費，半年後累積 US$1,000 銷售與 30 位付費使用者；上線約一年時，MRR 已經來到 US$1,361。速度不算爆發，但已經足以證明有人願意長期為這個利基產品付費。 Takuya 最近一次給出的明確數字，是 Inkdrop 已經連續三年以上超過 US$10K MRR。不過他在 2026 年初的 [2025 年回顧](https://www.devas.life/my-2025-indie-dev-journey-review/?ref=davehuang.io) 中也提到，因為整年專注開發 v6、減少行銷，新客成長放緩，營收比 2024 年低。因此目前只能確認它曾穩定跨過 US$10K MRR，無法知道 2026 年的精確數字。 ### **題目 #3: Magic Pages by Jannis Fedoruk-Betschki** [Magic Pages](https://www.magicpages.co/?ref=davehuang.io) 做的是 Ghost 部落格託管服務。使用者不需要處理伺服器、更新、備份、CDN 或寄信設定，幾分鐘內就能建立一個功能完整的 Ghost 網站。 Jannis 是近期讓我印象最深刻的一位獨立開發者，因為我們有過實際互動——我甚至在跟他接觸的兩個月後，成了他的付費用戶！ 我當初是在 [Ghost forum](https://forum.ghost.org/?ref=davehuang.io) 上搜尋關於搜尋功能的討論串，當時的我想要自己做一個 Ghost RAG 的 side project，進而看見 Jannis 在論壇上非常活躍，還分享了自己開發的全新搜尋套件。當時我覺得：這個人超屌，一定是個 Geek。繼續往下爬文才發現，他竟然還經營著 Ghost 託管服務，而且是一人公司！ 最開始跟他的接觸，是因為 Magic Pages 官網的 localization pricing 頁面出了一些 bug，讓我誤以為年費是 US$4,480，後來才發現其實是 NT$4,480，幾乎是 Ghost(Pro) 的半價！跟他反饋完本地化問題後，他竟然在 30 秒內秒回我，還在 10 分鐘內修正了這個 bug，讓我非常驚艷。 隨著我鑽研如何進行 migration 的過程，我也問了他幾次問題，接著就開始了試用期。這段期間只要我寄信到客服信箱，他都在短時間內親自回應我，不論他自己當地是什麼時間。就這樣，我被他的執行力與熱誠打動了，決定加入他的平台。 後來我也發現了他的 [寶藏 Blog](https://www.jannis.io/?ref=davehuang.io)。他在上面分享許多創業過程遇上的困難以及個人經驗。我最喜歡的是他講述自己當初 [回絕 Apple offer 的故事](https://www.jannis.io/how-saying-no-to-apple-changed-everything/?ref=davehuang.io)，那個選擇也一路造就了今天的他。 #### **他解決了什麼問題？** Ghost 這套開源軟體已經把寫作體驗與電子報系統做得很好，剩下的差異通常出現在架站方式的選擇；選擇自行架站，就得面對 Docker、資料庫、備份、DNS 與 Email 設定；選擇託管服務，價格又可能隨著自訂主題、CDN 或進階功能一路往上疊。許多創作者只想專注在寫作，最後卻被迫理解一堆可能兩、三年才碰一次的技術細節。 另一個差異在於電子報的計價方式。Ghost(Pro) 依網站的會員總數決定方案，免費會員也會列入計算，但寄信次數沒有限制。Magic Pages 則提供無上限的會員數，每月包含 10,000 封 Email，超出後每 10,000 封收取 US$5。對寄信頻率不高的小型部落格來說，後者更貼近使用情境，能夠省下寄信成本。 Jannis 最初也沒有打算經營一間完整的託管服務公司。2023 年初，他只是想架一台伺服器，放一批 Ghost 網站，再以這套基礎發展 Ghost 客製化開發服務。他先開出 15 份、每份 US$249 的終身方案預售。產品當時甚至還不能使用，第一批客戶卻已經願意付錢。 #### **他憑什麼能解決？** 這份信任與他先前累積的領域認知有關。Jannis 原本從事客服工作，2020 年曾在一間新創公司從零建立客服團隊。當時公司突然有了數百名客戶，規模又不足以繼續請人，他才開始學網頁開發，希望透過程式解決客服與運營問題。 後來他成為專職網頁工程師，也替 Carrd 製作範本、協助客戶處理網站問題。Magic Pages 解決的痛點，剛好落在在客服、網頁開發與 Ghost 三個經驗的交叉點上。 隨著託管的網站從 30 個成長到 100、600，再到現在的 1,400 多個，他又被迫補上基礎設施的知識。Docker、Kubernetes、分散式儲存、CDN、Email 成功送達率，幾乎每一塊知識都來自實際運營遇到的問題。這種認知很難靠做一個 POC 專案就補齊。 #### **客戶從哪裡來？** Magic Pages 的獲客起點是 Twitter。 Jannis 在產品還沒有名字時就公開分享想法，最早的客戶來自他既有的人脈，以及曾經買過 Carrd 範本、接受過他幫助的人。第一輪客戶開始使用後，真正把產品推出去的是口碑行銷。到了 2023 年中，他發現客戶會主動向朋友推薦 Magic Pages，才意識到這可能不只是一個業餘專案。 現在他的主要獲客渠道依然圍繞著創辦人個人品牌、既有客戶與 Ghost 社群。他會在個人部落格公開寫基礎設施出包（post mortem）、成本變化與經營上的困難，也長期出現在 Ghost 論壇和 Reddit。當有人詢問 Ghost 託管服務時，往往是他的客戶主動跳出來推薦。 我自己就是被這種創辦人熱誠轉換成付費用戶的例子。過去我曾因為網站後台卡頓而聯絡 Ghost(Pro) 客服，正常情況要等2\~3天才會回，若剛好遇上員工放假，甚至有過七天以上才收到回覆。相較之下，我每次寄信給 Magic Pages，幾乎都由 Jannis 本人在 15 分鐘內回覆。對網站正在出問題的創作者來說，這種回應速度會直接影響對託管服務的信任。 #### **驗證花了多久？現在走到哪裡？** 如上面所述，Magic Pages 的市場驗證發生在產品完成以前。最初 15 份預售帶來約 US$3,500，支付了第一台伺服器與部分開發成本；從預售到第一批網站真正上線，大約隔了三個月。2024 年 2 月，他在終身方案之外加入月繳與年繳方案，七個月後達到 US$1,034 MRR。 這也是 Jannis 最後一次公開精確 MRR。2025 年 5 月，他只透露 Magic Pages 的收入已經持續高過自己的正職工作；截至 2026 年 8 月，官網則顯示超過 1,400 位創作者。由於客戶混合了月繳、年繳、終身方案、舊價格與多網站帳號，無法從網站數量推算目前 MRR。但從產品在三年內由一人業餘專案長成三人小團隊來看，它已經走過最初的商業驗證階段。 ## **回到我的選題困境** 研究完這三個案例，我也重新梳理了自己開發 [Peak Pals](https://peakpals.io/?ref=davehuang.io) 的經驗。 跟 Takuya San 一樣，我當時就是 Peak Pals 最直接的使用者。從流程該怎麼設計，到哪些問題應該優先解，我一直都很清楚；產品上線後，我自己每天使用，搭配 beta users 持續提供回饋，feedback loop 很自然就建立了起來。這些 domain knowhow 原本就存在於我的生活裡，幾乎不需要另外取得。 真正卡住的是商業模式與 distribution。這部分我在 [Peak Pals V1 發佈心得](https://www.davehuang.io/peakpals/) 也有寫下省思。 這次的法規 RAG 剛好相反。我透過工程視角看見了解法，卻卡在無法有效進行 LLM Eval、缺乏情境資料，難以替結果背書。 其實在深入研究這三位獨立開發者以前，我曾經跟一位好友 [Marcus](https://blog.0xhhc.me/?ref=davehuang.io) 討論過，該怎麼補足自己缺少的 domain knowhow。 他提出了一個我沒有仔細想過的方向：如果缺的是領域知識，何不直接聘請領域專家，透過長期顧問或鐘點諮詢來補足？ 而且問題的規模可以調整。一個人能做的事情，跟一個團隊能做的事情肯定不同。如果目標是打造一個人能完成的產品，需要諮詢的範圍應該也不至於高到無法負擔。 反過來說，如果一間公司需要聘請大量領域專家，靠著許多不會寫在書上的經驗建立背景資料，那可能本來就不是一個人的範疇。即使我真的加入那間公司，這些知識門檻也不會因此消失。 聽完之後我才發現，自己原本的思緒把兩件事情混在一起了：一件是「我要怎麼取得 domain knowhow」，另一件是「這個問題到底適不適合獨立開發」。 我很認同聘請顧問可以幫我快速理解產業結構、既有 workflow、法規與常見問題，少走很多冤枉路。 但我比較沒把握的，是那些難以量化，卻足以深刻影響 product sense 的經驗。以及那些「未知的未知」。 那天我們沒有聊出一個明確的答案，不過 Marcus 確實幫我把原本混在一起的問題拆開了。從第一性原理去拆解問題本質，一直以來都是他的強項。也因為他提出這個方向，我才繼續往下研究，最後寫成這篇文章。 ### **工程與 Domain Knowhow 的不對稱** 研究這三人的過程中，我被提醒了一件事：Jesse 跟 Jannis 都曾將工程開發外包。 Jesse 找了 Andrew Culver 協助開發 Bento，自己是一邊看 code，一邊慢慢學會 Rails 與 React。 Jannis 早期也曾花錢請外部開發團隊協助客製 Email functionality。 但即便他們都外包過工程環節，他們都持續保持 hands-on，事情爆炸了自己都有辦法跳下去解決。他們這段從非工程背景一路走到 SaaS founder 的過程，帶給我很大的啟發。 但我也發現，他們選擇外包的工作都是「功能」問題或是「客服」——範圍明確，能夠定義與驗收。 就像現在為何 LLM 可以取代大量的 coding 實作一樣，工程師們對於定義 spec 最在行了，而 code 本身也是最容易被驗證的介質。 Domain knowhow 與商業邏輯就沒那麼容易定義與外包。 他們一直自己握著「什麼問題值得解、該服務誰、誰會願意付錢」的商業判斷。 AI 加速了軟體基底的建置，卻沒有能力提供 product sense。 這讓獨立開發者做產品的職涯路徑有機會反過來： > Non-tech Domain Expert → 借助 AI 與工程能力 → Domain-specific SaaS 對工程師來說，如果想進入一個完全陌生的領域，顧問也許可以幫忙補課。但要真的理解那個領域，長期環境的選擇 (exposure) 或 incentives 一致的夥伴，還是更務實的切入點。 ### **痛點背後的「在乎」** 回頭看這三人，我發現他們還有一個共同點：他們都由衷的高度在乎自己正在解的問題。 Jesse 過去經營行銷代理商，所以他很清楚 Email 工具不好用、信件進垃圾郵件，最後會怎麼傷害客戶的行銷成果與信任。 Takuya 每天都要寫 technical notes。只要工具不好用，就會持續磨損他日常的開發能量。 Jannis 原本做過 customer service。他在意創作者有沒有被技術問題卡住，也在意問題發生時，有沒有人願意接住他們，並且用對方聽得懂的語言協助解決問題。我自己也親身感受過 Jannis 的這一面。有好幾次，我都覺得自己的問題問得有點唐突，Jannis 還是很大方地回答了所有細節毫無保留。那種熱誠很難靠 SOP 模仿，也是我很欣賞、很嚮往的一種做產品的態度。 這幾位開發者都不是某天突然坐下來想著：「噢！我要開始找痛點囉～」再決定產品要往哪裡走。這些痛點原本就存在於他們的生活與工作裡。 因為在某個領域待得夠久，他們知道哪些地方真的麻煩，也看得出哪些摩擦力只是大家已經習慣了，但不代表無法被解決。當其中一個問題讓他們在意到想親手做出解決方案，產品就慢慢的「長」了出來，這過程是有機的。 當然，光是在乎還不夠。 持續交付的能力，以及有效的根據回饋持續修正與 pivot 也很重要。 ### **我想讓什麼開始複利** 寫到這，我開始思考另一個問題：接下來幾年，我想讓什麼開始複利？ 作為工程師，我很習慣累積 technical skills。LeetCode、system design、framework knowledge，都有相對清楚的學習路徑。投入多少時間、學會哪些東西、能不能通過面試或完成實作，通常也有明確的 feedback。 這些能力依然重要。我希望自己對工具的掌握一直維持在前緣，也持續磨練處理複雜問題的能力。但如果我想做出真正解決問題，也讓自己感到驕傲與滿意的產品，工程能力還需要搭配對使用者與 domain 的理解。 Peak Pals 的開發經驗讓我理解到，工程能力佐以 AI 可以把想法快速帶到 production，但產品該解決什麼、哪些功能應該優先，以及最後能不能真的幫助使用者，還是取決於我對問題的理解。 我想刻意累積的，是這種產品思維的複利（product sense）。 在一個問題空間裡待得夠久，久到知道哪些問題真的值得解、哪些需求只是噪音、客戶願意為什麼付錢，以及產品應該往哪裡長。 這些判斷很難透過讀書或短期衝刺補起來。它們藏在一次次與使用者互動、解決問題與修正假設的過程裡。對我來說，這些 domain knowhow、customer insight，都是做出好產品前很難取代的累積。 如果能在職涯上置身於自己真正在乎，且願意長期投入的 domain，依然是時間上最高效的配置。有著良好工程文化的團隊會讓工程師接觸客戶、參與問題定義，也能看見產品決策最後造成的結果。 Coding 已經能被 AI 加速。省下來的心力，我想拿去理解用戶、思考產品，再把這些理解轉回技術判斷。 工作以外的生活經驗、遇見的人、長期參與的社群，也會把我帶進其他問題裡。我未必需要刻意切出一個 time block 來「Explore domain knowhow」。 對我來說，當前能持續執行的，是留意那些反覆讓我覺得不對勁、甚至在乎到想親手解掉的麻煩。Technical skills 繼續累積，當真的遇到一個足夠在乎的問題時，我就有能力立刻動手驗證。 ![](https://www.davehuang.io/content/images/2026/08/778591255_29055549177367744_4431112862882210191_n.jpg) 感謝老爸幫我做的 AI 圖 ## 後記: 來自 Jannis 的補充 文章發佈後，很開心意外收到了 Jannis 本人的來信。 他在信中補充，其實在 Magic Pages 出現以前，他也曾經花了很長一段時間，刻意尋找生活與工作中的痛點，試著從中發想可能的創業題目。 有趣的是，最後真正被他做成產品、一路走到今天的 Magic Pages，卻不曾出現在那些刻意尋找的點子裡。 所以文章裡原本那句：「這幾位開發者都不是某天突然坐下來想著：『噢！我要開始找痛點囉～』」其實並不完全準確。 而這個補充，除了讓我覺得很有意思，也讓我對這件事多了一層理解。 刻意尋找問題，本來就是旅程的一部分；只是最後真正值得投入、也真的長成產品的那個機會，未必會按照原先設想的方式出現。重要的或許還是先開始行動，因為很多真正值得解決的問題，都是在過程中才逐漸看見的。 ### How Should Indie Developers Choose What to Build? URL: https://www.davehuang.io/domain-knowhow-en/ Last updated: 2026-08-30T14:40:15.000Z Ever since I read [*Unscripted*](https://www.amazon.com/dp/0984358161?lv=shuf&channelId=500&plpRedirect=mhFallback&ref=davehuang.io) and dozens of [Starter Story](https://www.youtube.com/@starterstory?ref=davehuang.io) case studies, I have kept an eye out for SaaS ideas in everyday life. A lot of my friends run small and mid-sized businesses. When they tell me about something going wrong at work, I start breaking down their workflow in my head. Is there a piece of this I could solve with the technology I know? One recent conversation turned up an idea: regulatory compliance plus RAG. I started a proof of concept right away and read up on RAG and compliance while I coded. Claude Code kept the early part moving. Then the RAG pipeline and the architecture came together, and I saw that the engineering was probably the easiest part of the problem. The hard part came after. Where does the data for the golden set come from? If I cannot understand a compliance case myself, how do I judge whether the system answered it correctly? Who runs the evals? Those questions all landed in the same place. Whether the system could become a business came down to how well I understood the domain, and whether I could turn that understanding into something reliable. With software I have a fairly clear way to check whether it works. Law is not like that. Both fields need someone to be responsible in the end. But a legal answer with its sources attached still needs a qualified person to judge it and sign off on it. I was not confident that technology alone would get me over that barrier. That was where I started asking myself: did I pick the wrong problem to begin with, or is this a barrier I could cross with enough skin in the game? ![](https://www.davehuang.io/content/images/2026/08/IMG_0643-2.jpg) This is a chubby bulldog While I was stuck there, recruiters on LinkedIn sent me a few AI-native SaaS openings. I had not even finished sorting out my thoughts before I was back in another cycle of interview prep. The project went on the shelf. The interviews gave me a look at how better-funded startups handle the same domain knowledge problem. Legal AI startups, for instance, have enough money to put lawyers and consultants on the team directly. Some of those experts are shareholders. The people supplying the domain knowledge carry the risk and share the upside if the product works. That much capital and organization is out of reach for indie development. But the way those teams work is close to the environment I want. Engineers and domain experts sit in the same problem for a long time, and both are on the hook for whether the product ships. What I value most in that setup is that engineers get to watch how the problem is defined, how the answers are checked, and how the product finally reaches the customer. If I got the chance to join a team like that, I could use my engineering skills to turn what the domain experts judge into systems that stay reliable and can be maintained. I would also want to stay in one problem domain long enough to get past the requirements: why we are building this, what customers actually care about, which technical tradeoffs make sense. Domain knowledge builds up through that. The interviews also sent me back to my own assumptions about indie development. I had pictured the path as a straight line. Find a potential pain point. Build enough domain knowledge. Add technical skills and execution, and make a proof of concept. Once I know someone needs it, work on distribution. I really did think I could walk those steps in order. Then I walked into a field I did not know, and found that domain knowledge does not install like a technical package the moment I need it. Some knowledge takes years. Some information never circulates in public at all. More frustrating: I may not be able to tell whether a problem suits an indie developer until I already understand the problem. So how does an indie developer find a pain point worth years of attention? How do we build enough domain knowledge to solve it, then get the product in front of people willing to pay? With those questions in mind, I looked into three indie developers I had come across recently. ## Three indie developers, three paths to choosing what to build Jesse Hanley, Takuya Matsuyama, and Jannis Fedoruk-Betschki have very different backgrounds and very different products. What they share is that each one built on the career he already had, and ended up with a business that one person or a tiny team can run for years. I will introduce each product first, then break down the three cases with four questions: - What problem does he solve? - Why was he able to solve it? - Where do his customers come from? - How long did validation take, and where is the product now? ### Project #1: Bento by Jesse Hanley [Bento](https://bentonow.com/?ref=davehuang.io) is an email deliverability and marketing automation platform. Most of its customers are SaaS and ecommerce companies. I found Jesse through X. Marc Lou had gone to Japan to hang out with [him](https://x.com/marclou/status/2069264657102336353?s=20&ref=davehuang.io), and I got curious enough to dig around for who he was. I came out of it with a pile of podcast interviews. I like how Jesse sounds on those podcasts. Practical, sincere, warm. His values keep surfacing in the answers. He cares about his family and his quality of life, so he keeps the business small on purpose and saves his time and attention for the people and things that matter to him. #### What problem does he solve? The problem came out of Jesse's own years of running email marketing. A team writes good content and builds the whole funnel, and the mail still lands in spam. Sender reputation, DNS authentication, some other sender on the same shared IP. The automation editors in existing tools are often painful to use, and the price climbs steeply with contact count even when most of the list never receives anything. Bento did not start as an email product. It started as a website personalization service. Jesse added analytics and tracking so business customers could see whether the personalization was doing anything, and after launch he noticed customers cared more about the visitor data than about personalization itself. That raised a question. If Bento already knew what a visitor had done, could it act on that behavior? He added email automation, then kept going into SMS, transactional email and deliverability. #### Why was he able to solve it? Bento sat almost exactly on top of Jesse's work history. Early in his career he ran systems, marketing, and operations for Australian health supplement retailers and ecommerce companies. Later he had his own marketing agency, handling SEO, ads, and email campaigns for clients. He was Bento's ideal customer for years before he built anything. He taught himself Rails and React and did the full stack himself. When something went past what he could do, he brought in more experienced engineers and learned from the code they committed. #### Where do his customers come from? Bento's customer acquisition reuses what Jesse did at the agency: help people online, for free, for a long time. For three or four years he kept a Calendly link on his [Twitter profile](https://x.com/jessethanley?ref=davehuang.io) so anyone could book a call with him. He would spend an hour or more helping someone untangle a problem and sell them nothing at the end. Some of those relationships turned into customers years later. Sometimes a friend finally lost patience with Mailchimp or Klaviyo and remembered Jesse. Once customers sign up, he keeps the word of mouth going by doing support himself. A customer paying US$30 and a customer paying US$3,000 can both reach him on [Discord](https://bentonow.com/docs/support?ref=davehuang.io). He runs demos, helps with migrations, records tutorial videos. Small customers kept introducing bigger ones, and support itself turned into one of Bento's main acquisition channels. In recent years he has added podcasts, sponsorships, and interviews to stay in front of the customers he wants. #### How long did validation take, and where is Bento now? Going by Jesse's own retrospectives, Bento never had a clear round of market validation up front. He was still running the agency, and part of why he started was that he wanted to write code and become a developer. He brought in Andrew Culver, whom he had met in Tokyo, and spent the first year stuffing analytics, a bit of email and automation into the product. He later described it as trying to build everything for everyone, and getting nowhere. He went all in on Bento only after selling the agency during the COVID pandemic, when he needed to rebuild his cash flow. That was when he noticed the part users actually responded to and kept using was email. The product started narrowing from there. By time to market validation, Bento is the slowest of the three products here. Jesse built it on the side of the agency for about three or four years before it was complete enough that customers could treat it as a replacement for their existing email provider. Nothing got validated in a few weeks. He kept reading clues in how customers used the product and narrowed the positioning slowly. The slowness bought him a deep understanding of the product. A [Tropical MBA interview from March 2026](https://tropicalmba.com/episodes/million-revenue-no-employees?ref=davehuang.io) described Bento as a business with annual recurring revenue over US$1 million, which puts monthly revenue at around US$83K at minimum. Jesse has not published an exact MRR. Most of the time the company is still him plus a few part-time collaborators. ### Project #2: Inkdrop by Takuya Matsuyama [Inkdrop](https://www.inkdrop.app/?ref=davehuang.io) is a cross-platform Markdown note-taking app built for software engineers. It works offline, syncs to the cloud, encrypts end-to-end, and takes plugins. I found [Takuya](https://www.craftz.dog/?ref=davehuang.io) while picking an editor for [Peak Pals](https://peakpals.io/?ref=davehuang.io). He is one of the few Japanese indie developers I know of. He also runs his \[blog\](https://www.devas.life/) on Ghost, and as a Ghost user myself, that made him feel closer to home. He works hard at building an audience on [YouTube](https://www.youtube.com/@craftzdog?ref=davehuang.io). In his own Japanese-accented English, he talks about his life and the problems he keeps running into. A recent video about [burning out in the AI era](https://youtu.be/Mf%5F524J8fPE?si=qo62chYjCIHaPXKf&ref=davehuang.io) hit home for me. #### What problem does he solve? The starting point was simple. Takuya could not find a note-taking app he wanted to use. That is pretty much why I built Peak Pals. He kept his development notes in Evernote, which handled code snippets and Markdown badly. Web apps died offline. Editors that synced over Dropbox were slow and ate CPU. The rest were either too thin or so fiddly he did not want to open them every day. He went through the options, found nothing he could live with long term, and built his own. #### Why was he able to solve it? Inkdrop's domain knowledge started with Takuya himself. He was the target user. He wrote code every day and took technical notes every day. He had been building software since he was a teenager. He worked at Yahoo! Japan, contributed to open source, and freelanced for years. Before Inkdrop he made a music app called Walknote. It reached 130,000 users and made no money. That failure taught him downloads and a working business are two different things. So Inkdrop charged a subscription from day one, and he narrowed the audience to developers willing to pay for their tools. #### Where do his customers come from? Early customers came almost entirely from writing. Takuya kept posting about how he built the app, how he got his first customers, and what running a one-person SaaS is like, then shared those posts on Hacker News (HN). At the peak, HN sent about 90% of new users. He never pitched the product on his blog. He wrote honestly about what he got right and what he got wrong, and readers and word of mouth built up from there. After 2018 the weight shifted to the devaslife YouTube channel. He filmed his life as a developer, the tools he used, his side projects, with Inkdrop showing up naturally along the way. By 2024, YouTube was sending 70 to 80% of new users at one point. He later set up a Discord for paying users and ran online meetups. Those channels may not bring in many new customers, but they give core users a reason to stay. #### How long did validation take, and where is Inkdrop now? Takuya did not run user interviews or put up a waitlist before building. He finished off his client work, gave himself three months for an MVP, and dropped a closed beta on Hacker News in June 2016\. The post hit the front page and pulled in more than 1,000 beta sign-ups in a short time. Those users filed bugs and asked for features. The usage data showed that some of them really did open it every day. That was Inkdrop's first market validation. The product started charging in October 2016\. Six months later it had US$1,000 in sales and 30 paying users. About a year after launch, MRR hit US$1,361\. Growth was not explosive, but it was enough to show that people would keep paying for a product this niche. The most recent hard number Takuya has given is that Inkdrop held above US$10K MRR for more than three years. In his [2025 retrospective](https://www.devas.life/my-2025-indie-dev-journey-review/?ref=davehuang.io), posted in early 2026, he also said new customer growth slowed and revenue came in below 2024, because he spent the year on v6 and did less marketing. So what we can say is that Inkdrop sat above US$10K MRR for years. We do not know its exact 2026 number.. ### Project #3: Magic Pages by Jannis Fedoruk-Betschki Magic Pages is managed hosting for Ghost blogs. You get a working Ghost site in minutes and never touch a server, an update, a backup, a CDN, or email settings. Jannis is the indie developer who has impressed me most lately, because we have actually talked. Two months after I first contacted him, I was paying him money. I found him on the [Ghost forum](https://forum.ghost.org/?ref=davehuang.io), digging through old threads about search. I wanted to build a Ghost RAG side project. Jannis was all over that forum answering questions, and he had released a search package he wrote himself. My reaction was: this guy is awesome. He has to be a serious geek. I kept reading and found out he also runs a Ghost hosting company, alone. Our first real contact came from a bug. The localized pricing page on the Magic Pages site had me convinced the annual plan cost US$4,480\. It was NT$4,480\. Almost half of Ghost(Pro). I wrote to him about the localization problem. He replied in 30 seconds and shipped the fix in 10 minutes. Then I worked out how to migrate, asked him a few more questions, and started a trial. Every time I emailed support, he answered me himself, quickly, whatever time it was where he lives. His execution and his enthusiasm got me. I moved my site over. Later I found his [blog](https://www.jannis.io/?ref=davehuang.io), which is a treasure. He writes about what is hard about building this business and what it has cost him personally. My favorite post is the [story of how he turned down an offer from Apple](https://www.jannis.io/how-saying-no-to-apple-changed-everything/?ref=davehuang.io). That choice is part of how he got here. #### What problem does he solve? Ghost is open source and already does writing and newsletters well. What is left is how you host it. Host it yourself and you own Docker, databases, backups, DNS, and email settings. Pay for managed hosting and the price climbs as you add custom themes, a CDN, or advanced features. Most creators only want to write, and instead they end up learning technical details they will touch once every two or three years. Newsletter pricing is the other difference. Ghost(Pro) prices by a site's total member count, free members included, and lets you send as much email as you want. Magic Pages puts no cap on members and includes 10,000 emails a month, then charges US$5 for every extra 10,000\. A small blog that does not send much email fits the second model better and pays less to send. Jannis did not set out to run a hosting company. In early 2023 he wanted a server to park a batch of Ghost sites on, and a base to sell custom Ghost development from. He presold 15 lifetime plans at US$249 each. The product did not work yet. The first customers paid anyway. #### Why was he able to solve it? That trust came from what he already knew. Jannis started out in customer support and built a support team from nothing at a startup in 2020\. The company suddenly had hundreds of customers and was too small to keep hiring. That is when he started learning web development, because he wanted to solve support and operations problems with code. He went on to work as a full-time web developer, made templates for Carrd, and fixed website problems for customers. Magic Pages sits right where customer support, web development, and Ghost overlap. Then the sites he hosted went from 30 to 100 to 600 to more than 1,400, and he had to fill in infrastructure too. Docker, Kubernetes, distributed storage, CDNs, email deliverability. Almost all of it came from something breaking while he was running the service. You do not get that from building a proof of concept. #### Where do his customers come from? Magic Pages got its first customers on Twitter. Jannis talked about the idea in public before the product had a name. The earliest customers came from his own network, plus people who had bought his Carrd templates or had him help them out. Once that first group was using it, word of mouth did the work. By mid-2023 he saw customers recommending Magic Pages to their friends and realized this could be more than a side project. He still gets customers the same way: his own name, his existing customers, and the Ghost community. On his blog he writes openly about infrastructure failures and the postmortems, about cost changes, about what is hard in the business. He has been a fixture in the Ghost forum and on Reddit for years. When someone asks where to host a Ghost site, his customers answer before he does. That enthusiasm is why I am a paying customer. I used to email Ghost(Pro) support when my admin panel was crawling. A normal reply took two or three days. Once, when their staff were on holiday, I waited more than seven days. Almost every email I send Magic Pages comes back from Jannis in 15 minutes. When a creator's site is breaking, that gap decides how much they trust their host. #### How long did validation take, and where is Magic Pages now? Magic Pages was validated before the product was finished. The first 15 presales brought in about US$3,500, which covered the first server and part of the development. Roughly three months passed between the presale and the first sites going live. In February 2024 he added monthly and annual plans next to the lifetime plan, and seven months later he hit US$1,034 MRR. That is the last exact MRR he has published. In May 2025 he said only that Magic Pages had been out-earning his full-time job for a while. As of August 2026 the website shows more than 1,400 creators. Customers are spread across monthly, annual, and lifetime plans, old pricing, and multi-site accounts, so you cannot work out the current MRR from the site count. But a one-person side project became a three-person team in three years. It is past its first commercial validation. ## Back to my problem of what to build After studying these three cases, I looked again at my own experience building [Peak Pals](https://peakpals.io/?ref=davehuang.io). Like Takuya-san, I was the most direct user of Peak Pals. I knew how the workflow should run and which problems to solve first. After launch I used the product every day, and beta users kept sending me feedback. The loop built itself. The domain knowledge was already sitting in my life, so I never had to go out and get it. Where I got stuck was the business model and distribution. I wrote about that in my [Peak Pals V1 launch retrospective](https://www.davehuang.io/peakpals-en/). The compliance RAG project ran the other way round. I could see a solution through an engineering lens. But I could not run effective LLM evals, I had no contextual data, and I could not stand behind my own results. Before I looked into these three indie developers, I talked with my friend [Marcus](https://blog.0xhhc.me/?ref=davehuang.io) about how to make up for the domain knowledge I was missing. He offered something I had never seriously considered. If domain expertise is what I lack, why not pay for it? Hire domain experts, either as ongoing advisors or by the hour. He also pointed out that I get to choose how big the problem is. One person cannot build what a team can build. If I aim at a product one person can finish, the consulting bill for it should stay affordable. The same logic works in reverse. If a company needs a room full of domain experts to assemble context out of experience that nobody writes down, then it was probably never a one-person problem. Joining that company would not remove those knowledge barriers either. Listening to him, I realized I had jammed two questions into one. How do I acquire domain knowledge? And is this problem even suitable for an indie developer? I agree that a consultant could teach me an industry's structure, its existing workflows, its regulations and its common problems, and teach me fast. That would save me a lot of wrong turns. What I am less sure about is the experience that is hard to measure but shapes product sense. And all the unknown unknowns. We did not arrive at a clear answer that day. Marcus did pull apart the two questions I had tangled together. Breaking a problem down from first principles has always been one of his strengths. Because he raised the idea, I kept digging, and that research eventually became this article. ### The asymmetry between engineering and domain knowledge Researching these three developers reminded me of something. Both Jesse and Jannis had outsourced engineering work. Jesse brought in Andrew Culver to help develop Bento, and read the code alongside him until he had picked up Rails and React. Jannis paid an outside team to build custom email functionality in the early days. Neither of them let go of the product. When something blew up, they could jump in and fix it themselves. Their paths from nontechnical backgrounds to SaaS founders changed how I thought about the problem. What they handed off was feature work and customer support. Both have a clear scope. You can define the job and check the result when it comes back. That is the same reason LLMs can now write so much of the code. Engineers are good at writing specs, and code is about the easiest output there is to verify. Domain knowledge and business logic do not come in that shape. Which problems are worth solving, who to serve, who will actually pay: they kept all of that themselves. AI speeds up building the software foundation. It cannot hand you product sense. So for an indie developer, the path into a product can run in the other direction: > Nontechnical domain expert → AI and engineering capabilities → Domain-specific SaaS For an engineer walking into an unfamiliar field, a consultant can help with the catching up. To really understand the field, picking an environment that keeps you exposed to it for years, or finding a partner whose incentives line up with yours, still looks like the more practical way in. ### Caring about the pain behind the problem Looking back at these three, they share one more thing. They genuinely care about the problem they are solving. Jesse ran a marketing agency. He knows exactly what a painful email tool costs a client, and what happens to their results and their trust in you when the mail lands in spam. Takuya writes technical notes every day. A bad tool wears down his development energy a little more each day. Jannis came from customer service. He cares whether creators get stuck on a technical problem, and whether someone is there to catch them when it happens and explain the fix in language they can follow. I have been on the receiving end of that. More than once I felt my questions were a bit abrupt, and Jannis answered every detail anyway, holding nothing back. You cannot fake that with a support playbook. It is the attitude toward building products that I admire and want for myself. None of these three sat down one day and thought, "Oh! Time to look for pain points!" and then worked out where the product should go. The pain was already sitting in their lives and their work. They had spent long enough in a field to know which parts were genuinely annoying, and to spot the friction everyone had simply gotten used to. Used to it does not mean unfixable. When one of those problems bothered them enough that they wanted to build the solution with their own hands, the product grew out of it slowly. Organically. Caring is not enough on its own, of course. They also needed to keep shipping, and to read feedback well enough to correct course and pivot when it was time. ### What I want to compound Writing this got me thinking about a different question. Over the next few years, what do I want to compound? As an engineer, I am used to stacking technical skills. LeetCode, system design, framework knowledge. The path is clear and so is the feedback. I put in the hours, learn the material, and then either pass the interview or ship the thing. Those skills still matter to me. I want to keep my hands on the newest tools and keep getting better at complex problems. But engineering skill on its own does not get me a product that solves a real problem and leaves me proud of the result. That also takes an understanding of the users and the domain. Engineering got Peak Pals to production. It could not tell me what the product should solve, which features to build first, or whether the thing actually helped anyone. That part still comes down to how well I understand the problem. So product sense is what I want to compound on purpose. I want to sit in one problem space long enough to know which problems are worth solving, which requests are noise, what customers will pay for, and where the product should grow next. I cannot read my way there, and I cannot cram it into one sprint. It comes from talking to the same users again and again, fixing things for them, and finding out which of my assumptions were wrong. Domain knowledge and customer insight are the parts of a good product I cannot shortcut. Which is why spending my working years inside a domain I care about and would stay in for years still looks like the best use of my time. The team matters as well. I want one that lets engineers talk to customers, sit in on defining the problem, and see what our product decisions did. AI already speeds up the coding. I would rather spend the attention it frees up on the users and the product, then feed that back into my technical judgment. Life outside work will pull me into other problems anyway, through the people I meet and the communities I stay in. I may not need to block out time and force myself to "explore domain knowledge." For now, the practical version is smaller. Pay attention to the things that keep bugging me, especially the ones I care enough about to want to fix myself. Keep stacking technical skills in the meantime. Then when a problem I care about that much shows up, I can start testing a solution right away. ![](https://www.davehuang.io/content/images/2026/08/778591255_29055549177367744_4431112862882210191_n-1.jpg) Thanks my Dad for making this AI pic for me ## Postscript: A note from Jannis After publishing this article, I was glad to receive an email from Jannis himself. He kindly pointed out that he had also spent years actively looking for pain points and brainstorming startup ideas before Magic Pages came along. Interestingly, though, Magic Pages wasn’t one of the ideas he had been deliberately searching for. So my original line—“None of these three sat down one day and thought, ‘Oh! Time to look for pain points!’”—wasn’t quite accurate. If anything, I think his story makes the point more nuanced: actively looking for problems can still be part of the journey, while the opportunity that eventually works may emerge from somewhere you didn’t originally expect. ### Just enough to make me care URL: https://www.davehuang.io/poker-en/ Last updated: 2026-07-25T08:18:03.000Z Last weekend, my creative writing teacher invited me to the highest-stakes Texas Hold'em tournament I had ever played in. After it ended, I told a friend who came with me, "That game might have been my biggest dopamine spike of the first half of this year." Before this, my strongest impressions of Texas Hold'em came from two poker scenes in movies. I had played a few casual home games with friends, but this buy-in was higher, and players outside our group could buy in. ![](https://www.davehuang.io/content/images/2026/07/Casino-Royale-1.jpg) ![](https://www.davehuang.io/content/images/2026/07/In-Time-1.jpg) I did not really want to go at first. I knew exactly where I stood. At my level, I was probably walking in to get slaughtered. Texas Hold’em is fairly beginner-friendly. There’s enough variance in any given hand that even a beginner can get lucky and win. But over a large enough number of hands—especially in a tournament where the blinds keep increasing—the skill gap eventually reveals itself in each player’s chip stack. ## **Going in with awareness** A few weeks before the event, my teacher messaged me and asked if I was coming. I thought about it again. Wait, I was not going there to win. Getting together with classmates was already fun. Maybe I did not need to think so much about it. My teacher had also talked with me before about patterns he noticed in my personality and had given me advice on writing. So I figured I could go in deliberately aware of myself and watch how I reacted at the table. It would be a chance to practice reading people and maybe collect some material to write about. I borrowed a metaphor from *Hunter x Hunter*: "En (圓)," a technique that lets a character sense everything within a certain radius. I wanted that kind of radar covering the whole table while I watched how I reacted to money, winning, losing, and pressure. ![](https://www.davehuang.io/content/images/2026/07/----1.jpeg) President's En The buy-in also hit an interesting sweet spot. I could spend it without thinking too hard, but it was still enough to make the stakes feel real. Before I went in, I gave myself one rule: make the best decision I could with what I knew, enjoy the experience, and engage with the people at the table. ## **A predator's gaze** At the beginning of the first round, my teacher, my classmates, and I were laughing and chatting. Whenever two of us made it all the way to the river, we would still trash-talk each other. Then one hand reminded me that real money was involved. It came down to me and a player I did not know. I had assumed he was a student from another class. Later, I found out that the tournament had been open to anyone willing to buy in. Confident in my hand, I kept raising with him as the board ran out to the river. Then I pushed in the rest of my chips. All-in. When it was his turn to act, the player who had been curled up under a blanket finally leaned forward and looked at me from across the table. It was nothing like making eye contact with a friend. There was no warmth and no smile. He looked at me the way a predator looks at prey. In that glance, I could almost hear his inner monologue: "He looks like a fish. How much value can I extract from him?" He called. I lost every chip I had in the first round. It was the first time I had felt another person's hostility so directly across a poker table. ## **A testing gaze** I paid the buy-in again and sat down for the second round. Alongside the same teacher and classmates, another stranger took the seat to my left. His chip tricks and the way he interacted with the dealer made it obvious that he was a seasoned player. He was also much looser and more aggressive than the stranger from the first round. He played more hands and applied more pressure. Several times while we waited for the cards, I caught him watching my body language and reactions. I have a wide field of vision, and I consider myself fairly sensitive to microexpressions and subtext. I pretended not to notice and observed him observing me. His gaze was less aggressive than the first player's, but I could still hear what it was saying: "Is he acting, or does he really have no idea what he's doing?" (A lot of the time, I really had no idea.) This kind of silent sparring felt strange. It was nothing I had experienced in home games with friends. This might sound a little dramatic. It felt like a scene from a samurai movie, with two samurai circling each other before either one drew a blade. I had assumed scenes like that only existed in fiction. When it happened to me, it felt completely real. ## **I got pulled in** Halfway through the second round, his probing started getting under my skin. I wanted to take him on. In several hands, I had cards I would normally never play. After he raised, I made a point of calling almost instantly, trying to take back control of the table's rhythm. A voice in my head said: I am not letting you see that I am a beginner. Until we show our cards, we are equals. I only understood that thought process after I had calmed down. In the moment, my emotions were already driving me, and I did not even notice. Before the game, I had planned to keep that radar on and watch myself. Once I was actually sitting there, I was already fixated on my opponent and on winning. We went back and forth a few times. I won some and lost some, and I barely understood why either way. I was like someone who had never trained stepping into a ring and throwing wild haymakers. I have to admit, it felt great. When two people go head-to-head and one of them loses every chip, it feels strangely territorial. For a moment, a modern poker table felt like a place for old-fashioned conquest. The rules of Texas Hold'em allow deception and sometimes reward it. You cannot wait for a good hand every time you bet, and you cannot bluff every hand either. Play too many hands and you are too loose. Play too few and you are too tight. Eventually, your opponents will read you. Through your bets and behavior, you have to sell them a story that benefits you. With a big enough bankroll and enough skill, Texas Hold'em can be a hell of a game. It is social, and the dopamine hits hard. You can crush someone with better reads and prove that you have the nerve to back your judgment with money. ## **Why did my teacher choose poker?** While writing this, I started reverse-engineering what my teacher had in mind when he arranged the event. There are plenty of friendlier ways to spend time together. Why did he choose poker? Even with all my mental preparation, the table still drew out my irrational side. When people spar like this, their personality starts showing through in their eyes, betting patterns, and body language. The tournament setup was unusual too. A group of friends shared a table with random strangers. There was enough familiarity to relax and enough outside pressure to keep everyone alert. It is hard to recreate that mix in everyday life. I do not know if my teacher intended all of it, but it reminded me of something he once said: a good teacher has to let students fall and make mistakes in ways that will not kill them. You cannot take away their right to make mistakes. Poker gave us exactly that kind of room. ## **Where the game leaks into real life** The game looked self-contained, with a clear start and finish, but it had a leak. Once the game ended, the chips became real money again. You walked away with a different amount in your wallet. The wins and losses at the table had leaked into ordinary life. Luckily, I had already treated the buy-in as a one-time entertainment expense before I sat down. In my head, the money was already spent. Good decisions still lose. Bad decisions still get lucky. The only things I could control were my decisions and my emotions. Looking back, playing poker well seems to come down to this: be disciplined about execution and relaxed about the result. ![](https://www.davehuang.io/content/images/2026/07/IMG_3264-1.png) We went to izakaya after the game, I was exhausted! ### 剛好足以讓我在乎 URL: https://www.davehuang.io/poker/ Last updated: 2026-07-25T08:24:54.000Z 上週末，在[創作課](https://www.davehuang.io/start/)老師的邀請下，我參加了一場自己打過最高額的德州撲克錦標賽。 牌局結束後，我跟一同參加的朋友說：「今天這場遊戲，大概是我上半年多巴胺噴發的峰值時刻。」 在這之前，我對德州撲克最深的印象，大概只有《皇家夜總會》和《終點戰》裡的兩幕。雖然也跟朋友玩過幾次輕鬆的 Home game，但這次入場費更高，牌桌上還會出現完全不認識的玩家。 ![](https://www.davehuang.io/content/images/2026/07/Casino-Royale.jpg) ![](https://www.davehuang.io/content/images/2026/07/In-Time.jpg) 我原本其實不太想去。我有自知之明，以我的程度上桌，大概只有被屠宰的份。 德州撲克對新手算友善。單一牌局有足夠的隨機性，就算亂玩，也可能靠運氣暫時贏錢。但當回合數打得夠多，再加上錦標賽不斷升盲，技術差距遲早會呈現。 ## **帶著「圓」進場** 活動開始前幾週，老師傳訊息問我來不來。我才重新想了一次：Wait，參加這場活動又不是為了贏。 跟同學們聚在一起，本身就很開心，好像也不用想那麼多。 再加上老師過去也曾跟我聊過，他對我的個性有哪些觀察，也給過我一些寫作上的建議。我心想，既然如此，或許可以刻意帶著覺知進場，觀察自己在牌桌上的反應。這也算是練習心理側寫的機會，說不定還能累積一些寫作素材。 我想試著把《獵人》裡的「圓」全開。一邊感受整張牌桌，一邊注意自己在金錢、輸贏與壓力面前會有什麼反應。 ![](https://www.davehuang.io/content/images/2026/07/---.jpeg) 會長的圓 入場費也剛好落在一條很有趣的邊界上——這筆錢花下去不需要想太多，卻又足以讓我在乎。 是一個得失心的甜蜜點。 進場前，我給自己下了一個心理建設：用認知內最大的能力做好每一個決策，享受過程與環境，也好好跟牌桌上的人互動。 ## **掠奪的眼神** 第一輪開始時，老師、同學們一行人還有說有笑。每當自己人一路打到河牌對決，大家還是會互相嘴砲。 直到有一手牌讓我回過神來：這是一場關乎金錢的比賽。 那次只剩下我和一位陌生玩家對決。我原本還以為他是其他期的同學，後來才知道，原來這場錦標賽一開始就開放外面的玩家自行買入。 我憑著對手牌的自信，一路跟他打到河牌，最後把剩下的籌碼全推了進去（All-in）。 輪到他行動時，原本披著毛毯、窩在座位上的他，難得向前傾身，側過一個角度，從牌桌另一端瞥了我一眼。 那個眼神跟朋友間的互視很不一樣。沒有友好，沒有笑意，只有純粹的打量。 就在這一瞅之際，我彷彿透過他的視線，聽見了他內心的旁白： 「看來他是羊，我該如何掠奪他的價值？」 他跟注了。 我輸掉第一輪的所有籌碼。這也是我第一次在一場封閉賽局裡，這麼直接地感受到對手的惡意。 ## **試探的眼神** 到了第二輪，我重新付了入場費。除了第一輪原班人馬的老師與同學，另一位陌生玩家坐到了我的左手邊。 從他玩弄籌碼的熟練度，以及跟荷官互動的舉手投足，看得出來是個老玩家。他的打法也比上一位陌生玩家寬鬆、激進許多，願意玩的牌更多，攻勢也更強。 好幾次等待發牌時，我都發現他在偷看我的肢體動作和反應。我的視野其實很寬，而且自認對微表情與潛溝通有一定的敏銳度。 我順勢假裝沒發現，觀察著他的觀察。 這次的視線沒有上一位玩家那麼侵略，但我還是聽得見它的語言：「他到底是在裝，還是真的不懂？」 （很多手我其實是真的不懂） 透過視線與潛溝通「過招」的體驗很特殊。平常跟熟人在家裡玩 home game，我從來沒有體驗過這種感覺。 講出來好像有點中二，但那過程很像俠客漫畫裡，雙方揮刀前來回盤旋的內心戲。原本以為是腦補的劇情，真的發生在我身上時，它在我的感知裡就是這麼真實。 ## **我真的被拉進去了** 第二輪打到一半，我開始受不了對方的試探，也想跟他來尬一下。 有幾手，我拿著平常根本不會入局的爛牌，在他加注（raise）後，我故意很快跟注，想把牌桌上的氣勢和節奏搶回來。 我心裡有個聲音：我才不想讓你看出我是新手。只要還沒開牌，我們就是對等的。 這是事後冷靜下來，我才整理出的心理進程。牌局當下，我確實被情緒牽著走，卻完全沒有發現。 進場前，我還想著要打開「圓」觀察自己。真的坐上牌桌，注意力卻一點一滴的被勝負欲給侵蝕。 我跟他來回交鋒幾次，有輸有贏，但大多贏得不明不白，輸得也不明不白。像一個根本不懂格鬥的人，上了擂台跟人打王八拳。 不得不說，真的很過癮。 當兩個人正面對決，其中一方的籌碼被清空時，確實有一種攻城掠地的感覺。文明時代的野蠻掠奪，就這樣出現在牌桌上。 德州撲克的規則允許，甚至鼓勵玩家欺騙。你不能永遠等到有好牌才下注，也不能每一手都在唬人。出手太多、打得太寬，或出手太少、打得太緊，都會逐漸被對手讀懂。 你得透過下注與行為，讓對手相信一個對自己有利的敘事。 當你有夠深的口袋，再搭配足夠的知識與技術，德州撲克確實是一種很好的娛樂。它有社交性，也有峰值極高的多巴胺衝擊。你可以運用自己的智慧輾壓對手，也能證明自己有面對風險的膽識。 ## **老師為什麼選撲克** 寫到這裡，我才開始回推老師安排這場活動的心思。 有這麼多更和氣的互動方式，他為什麼偏偏選了撲克？ 即使我帶著一堆心理建設進場，還是被牌桌引出了非理性的那一面。人與人過招時，個性也會從眼神、下注和肢體動作裡慢慢滲出來。 這場錦標賽的 setup 也很特別——一群彼此認識的朋友，混著隨機出現的陌生玩家。桌上有著一定程度的熟悉感，卻又保留了充足的外部刺激。 這種環境塑造在現實生活裡可遇不可求。我不知道這是否全是老師原本的用意，但它讓我想起老師以前說過的一句話：一個好的老師，得讓學生在不會死掉的範圍內跌倒、犯錯，不能剝奪對方犯錯的權利。 撲克剛好提供了這樣的範圍。 ## **封閉賽局留下的洞** 這場遊戲看起來是一場限時的封閉賽局，卻留著一個洞。 牌局結束後，籌碼會換回現實中的錢。離開時，錢包的厚度真的產生了變化。桌上的輸贏，就從那個洞外溢到生活裡。 好在進場以前，我已經把入場費視為一次性的娛樂開支，把這筆錢先在心裡支付掉了，得失心才沒那麼重。 合理的決策可能會輸，錯誤的決策也可能因為運氣而贏。牌桌上能控制的，只有自己的決策與情緒。 回頭看，德州撲克要玩得好，大概就是：嚴格面對執行，鬆散面對結果。 ![](https://www.davehuang.io/content/images/2026/07/IMG_3264.png) 賽後，一行人一起前往居酒屋，我累爆了 ### 旅行雜感、計時器、多巴胺 URL: https://www.davehuang.io/okinawa/ Last updated: 2026-07-13T06:28:38.000Z *4/20:* 我正坐在 Airbnb 的露台上，看著海，喝咖啡用電腦。 太陽雖大，但風吹過來還是很涼。 ![](https://www.davehuang.io/content/images/2026/06/IMG_2107.png) 這趟沖繩自駕旅行已經接近尾聲。 明天，我就要和朋友們一起開車前往機場，把這幾天的歡笑收進記憶裡。 旅行的這幾天，時間過得很純粹。不需要被通知打斷，不需要一直處理未完成的事，也不需要反覆在任務之間切換。 我只需要專注地與眼前的旅伴相處。走路、吃飯、發呆、看風景。 每一件事都能自然地延展，不需要刻意被壓縮。 那是一種節奏完全掌握在自己手上的狀態。 ## 回歸日常 *4/25:* 回到台灣，面對著排山倒海的工作量與累積的待辦事項。硬著頭皮撐了幾天後，我又覺得自己快要 burnout 了。 Wait...我不是才剛度假回來嗎？我以為度假的聖光 buff 至少能維持久一點。 更讓我在意的是，出發前那種能夠穩穩坐在電腦前、持續推進 side project 的專注狀態，也消失殆盡。 我想起剛開始開發 [Peak Pals](https://www.davehuang.io/peakpals/) 的那段時間。每天一早都很有動力地從床上跳起來開發，洗澡時還在想 bug 要怎麼解，睡前也滿腦子都是新的 idea。 我很懷念那種被一件事情徹底吸住的 obsession。 --- 我知道從心理機制上來說，這和多巴胺曲線有關——旅行帶來的高刺激體驗結束之後，情緒自然會下墜。 理性上我理解這件事，也知道幾週後這種感覺會慢慢淡掉。 但它還是讓我正視了一件事：我對於自己最近的生活，可能不是那麼滿意。 我希望[旅行](https://www.davehuang.io/travel/)固然令人興奮，但回到日常之後，依然能感受到自己正朝著有意義的方向前進。 ## 計時器 卡在這種狀態中，一時也不知道該怎麼辦。我突發奇想，上網買了一個 DRETEC 的計時器。 ![](https://www.davehuang.io/content/images/2026/06/IMG_2346.png) 這是一個專門用來記錄讀書與專注時間的實體計時器。 我心想，既然我想重新回到那種時間被自己掌握的狀態，那就先看看每一天，我究竟花了多少時間在自己認為真正重要的事情上。 按下 Start 按鈕時，也像是對自己下一個制約：在這段時間裡，我只做眼前這一件事。 計時器本身並沒有讓我突然變得更自律，但它讓時間變得「可見」。 而且，我還是喜歡這種類比時代的浪漫——拿起一個專注只做一件事情的儀器，按下那個物理按鈕。 使用 Dretec 的這幾天，我開始看見，一天之中究竟有多少時間真正屬於自己，又有多少在不知不覺間流向了其他地方。 ## 更平緩的多巴胺 旅行期間，我又重新養成了使用社群媒體拍照、分享與紀錄的習慣。 副作用是，除了拍以外，也會順手滑幾下。 回到台灣後，手也很自然地繼續滑了下去。 於是我想，與其單靠意志力阻止自己滑手機，不如用另一種更平緩的多巴胺來替代它。 我果斷下訂了兩套一直在待讀清單裡的實體漫畫。 一部是《薄墨的鏡頭》，另一部是《異獸魔都》。 ![](https://www.davehuang.io/content/images/2026/06/155_165559954_543_mainCoverImage1.jpg) ![](https://www.davehuang.io/content/images/2026/06/main1_230213_268848.jpg) 看漫畫就是要拿著實體書！ 我用這兩部作品作為工作累了後的休閒模式，取代原本下意識就會打開的社群軟體，也讓旅行結束後的情緒落差，多了一點緩衝。 對我來說，這兩部作品都是藝術品般的存在。 在被作品吸進整個世界觀的過程中，我又重新找回了那種心無旁騖、整個人沈浸的時光。 就像我曾在[《Final Sanctuary：告別類比聖堂》](https://www.davehuang.io/sanctuary/)裡寫過的，這是一種更有重量與溫度的純淨多巴胺。 ## 提醒方向的籤 回來後的第二週，我趁著工作的空檔，跑去附近的土地公廟坐了一會。 一方面，是想感謝自己平安度過了這麼棒的旅程，另一方面，也問了關於工作與職涯的疑問。 那時的我，其實有一點混沌。我知道自己想往哪裡走，也知道有些事情需要長期累積。但當時間與注意力都被工作和疲憊佔據時，人很容易開始懷疑自己。 得到的籤詩大意是： > 你知道自己想要什麼， > 也知道該怎麼做才能抵達那裡。 > 剩下的，就是專注執行，撐過寒冬。 > 不用再無謂內耗， > 也不用因一時的迷失而懷疑自己。 > 因為這段過程，本身就是一場投資。 > 投資的本質，就是承擔風險。 > 只要方向正確，風險另一端的報酬，終將值得。 它沒有指給我一條新的道路。 某種程度上，它只是提醒我：既然方向已經知道了，接下來要做的，就是穩妥地做好準備。 於是我也開始把那些擱置在心裡的事情，一件件重新撿回來。 繼續鑽研系統設計，把過去零散的知識體系重新串起來。 也預約了一場 career coaching，開始整理自己的經歷，以及下一個職涯階段真正想前往的方向。 我的目標依然是 indie hacking。 但我也知道，這不代表職涯與技術能力就可以被擱置。這是我目前仍然需要累積的地基。 我就帶著這份信念，慢慢走過這個失去方向感的五月。 ## 重建生活結構 回頭翻了翻自己曾經寫下的[《Protect Your Context》](https://www.davehuang.io/context/)： 睡眠、運動、飲食，減少資訊干擾，維持穩定的輸入與輸出。 生活很奇妙，即使曾經想通、寫下，甚至親自實踐過，還是會在忙碌與混亂中，慢慢偏離原本的方向。 我需要做的，是讓生活的基礎結構重新回到穩定狀態。 計時器讓我重新看見時間。 漫畫讓我重新選擇多巴胺的來源。 籤詩讓我在混沌中重新確認方向。 至於系統設計、career coaching 與職涯準備，也提醒了我：如果真的想把 indie hacking 當成長期方向，這些看似務實、甚至有點無聊的累積，同樣是路的一部分。 回頭看，這場旅行帶給我的不只是快樂，也照出了我日常生活裡逐漸失衡的部分。 ### Travel Bits 回來後，剪了一集 Daily Sec 的特別篇，用我的懶人剪輯法，原封不動的記錄每個開心的瞬間。 附上猴仔與爆好吃的蝦飯： ![](https://www.davehuang.io/content/images/2026/06/IMG_1968.png) 🍤 ### 時間分艙：一套降低認知負載的時間管理方法 URL: https://www.davehuang.io/time-encapsulate/ Last updated: 2026-04-05T07:13:01.000Z 這篇文章想分享一個我過去一個月實踐的時間管理策略，也是近期少數讓我明顯感受到成效的方法。 我在 2025 與 2026 這兩年的宏觀目標，是成為一個能快速建構產品、也能有效驗證市場的軟體工程師。 而要走向這個目標，我有兩個面向必須同時兼顧：一是打造出好的產品（Maker mode），二是驗證痛點，並學習怎麼讓產品被看見（Manager mode）\[[1](https://www.davehuang.io/time-encapsulate/#fn1)\] \[[2](https://www.davehuang.io/time-encapsulate/#fn2)\]。 在我原本的生活中，我常常像在拋接雜耍球一樣，同時在 4 \~ 5 個任務之間維持動態平衡。這些任務可能包括 Side project 開發、技術調研、職涯精進、閱讀與運動。 ![](https://www.davehuang.io/content/images/2026/04/IMG_0562.jpg) Juggling balls (我畫的) 會這樣做，一方面是我認為，這幾個面向都是我生命中的核心支柱，所以每個都想鞏固；但另一方面，也有一部分不是出於理性判斷，是身體被這種任務切換時的新鮮感牽著走，像開很多瀏覽器分頁一樣，誤把多巴胺假象當成進展。 如同我在 [Protect Your Context](https://www.davehuang.io/context/) 這篇文章中所陳述的，這樣的動態平衡過程只會造成腦中 Context 越變越髒，很容易時不時就 [burnout](https://www.davehuang.io/burnout/)，也不知道自己在累什麼。 ## 新的時間運用策略 在我多次跟 Claude 據實討論自己的困境與時間配置後，他提出了一個很棒的概念，叫做「時間分艙」(Time encapsulate)。 他建議我不要再把時間切得那麼碎。 既然我是那種需要一大段 time block 才比較容易做出關鍵產出的人，就更應該簡化任務類別，把時間預先配置好。 一旦認定大方向無誤，剩下的執行細節就應該盡可能降低認知負載，照表操課。 ### Before 這是我原本的時間規劃方式，就像開頭講的，像在玩雜耍球： ![](https://www.davehuang.io/content/images/2026/04/old-time-2.png) 我每天都在重新決定、微調該推進哪一個面向。 ### After 下方是我現在的時間分艙策略。 以**一週**為單位，我進行了宏觀的分艙： ![](https://www.davehuang.io/content/images/2026/04/new-time-macro.png) 以**一日**為單位，這是微觀的分艙： ![](https://www.davehuang.io/content/images/2026/04/new-time-micro.png) 原本那些並行的任務，在我的日常生活裡其實還是持續在運作，只是我把它們抽象化，盡可能簡化自己的思維模組。 對我來說，眼前能做的事情只剩下三類：任務 A 是技術精進，任務 B 是 Build Project，而其餘面向，我都先收進任務 C。 而內心的主線任務只有一個，就是朝著我的年度目標邁進：成為一個能快速建構產品，也能有效驗證市場的軟體工程師。 而我也替未來的 3 個月與 6 個月各設了一個明確的檢核點，用來 review 自己的達成率。 ### 如何面對突發事件? 1. 當突發事件發生在其中一個分艙，就直接放掉，專心處理下一個分艙。而過程就是把事情處理好，不要多想。這個分艙就當作沒了，不然就是去休息耍廢。 2. 有惰性，或是心中有雜訊怎辦？不管它，最低限度的繼續做這個分艙該做的事情，讓動能推著自己前進，做多少算多少。當作這個分艙沒有了，多做都是賺。 ![](https://www.davehuang.io/content/images/2026/04/new-time-micro-incident.png) ## 結語 這個策略帶給我的好處，是更純淨的 context。 捨棄了對於多面向都想推進的貪念，讓我專注把一件事情做好。 而檢核點也很重要。把確切的檢核方式與時間點寫下來，時間到了就要誠實面對成果。缺乏檢核，很容易又退回原本熟悉的慣性。 在這個執行過程裡，我也再次體悟到寫日誌的重要性。 透過持續寫下日誌，我可以反思自己是否有走在預先安排好的道路上，把腦中雜訊丟掉，只留下方向感。 Trust the process. ## 近期紀錄 ### Peak Pals & HY 上個月我找了創作課的同學們幫我寫了幾篇 [Peak Pals](https://peakpals.io/blog/?ref=davehuang.io) SEO 文章。 回頭看 [HY](https://www.youtube.com/@x2010231?ref=davehuang.io) 寫的其中一篇[《只是怕麻煩》](https://peakpals.io/blog/zh-tw/troublesome-ayo/?ref=davehuang.io)，我才發現，他其實早就在默默跑「時間分艙」這套策略，而且幾乎和這次 Claude 給我的建言一模一樣。 這種原本模糊的方法論，突然被明確命名的時刻，好像很常在與 AI 協作時發生，我覺得很有趣。我也蠻佩服 HY 的，因為他其實早就摸索出一套很有效益的策略，而我也能明確感受到他這段期間的專注與產出效率。 ### 掃墓 上週我提早和父母一起去台中掃墓，看看阿公。 過去的我對這個禮俗其實沒什麼感覺，甚至會覺得只是在浪費時間、跑一套流程。但隨著這幾年開始接觸台灣傳統信仰，也一路追尋自己內心的信標，我反而越來越能 respect 這個習俗。 我現在會覺得，掃墓某種程度上是一個和集體潛意識 bonding 的過程。 它讓我更懂得感激前人的努力，還有自己此刻所擁有的一切。回頭想想，過去的祖先真的很不容易，而這些世代累積下來的東西，以及各方面的庇蔭，也都不是理所當然的，物質與關係，很多時候其實稍縱即逝。 ### 乒乓 這禮拜另一個讓我非常開心的事情，是朋友 [蛤蠣](https://www.facebook.com/BigClamBizarreAdventure) 邀請我去打乒乓球。 [場地](https://maps.app.goo.gl/jR9QnwYJqnuGj15w5?ref=davehuang.io)與板橋捷運站共構，捷運出口一走出來就是球場。每個場地後面都有時鐘和廣播器，讓每個 section 的人都可以明確地 rotate，超方便，也很現代化，我真心覺得這是德政。 我和蛤蠣兩個 180cm+ 的大漢組隊打雙打，大家都說我們的肢體動作很像。而且我們殺球下去的力道和擺動很有壓迫感，常常讓對手下意識往後退，哈哈。我已經超過三年沒打桌球了，精準度還是明顯掉了不少。 真的很久沒有這麼愉快、這麼單純地享受運動的美好了。這也讓我想起很多在第一間公司和 CTO 一起在桌球社打球的回憶，我們的雙打組合可是有拿過獎狀的。 打完球之後，兩個爆餓的人又去狂吃一頓，一路聊人生、聊著各自的目標，討論彼此對世界的理解，不亦樂乎。 我：看來我以後一季要來跟你打一次球，太快樂了。 蛤蠣：什麼一季！兩週打一次啦！ 我：好啦，不然兩個月一次。 蛤蠣：一個月一次啦。 （詭異的討價還價） ![](https://www.davehuang.io/content/images/2026/04/IMG_1650.png) 我手很大，所以球拍看起來很小。（騙你的，這是小拍） --- [1](https://www.davehuang.io/time-encapsulate/#end1) Alex Hormozi: [Maker Mode vs Manager Mode](https://youtu.be/GIRkQQHzsxI?si=ivwkOlReTGQgoCo2&ref=davehuang.io) [2](https://www.davehuang.io/time-encapsulate/#end2) Paul Graham: [Maker's Schedule, Manager's Schedule](https://www.paulgraham.com/makersschedule.html?ref=davehuang.io) ### 寫作的意義 URL: https://www.davehuang.io/writes/ Last updated: 2026-03-13T17:43:13.000Z 上週我讀了一位同期[創作課](https://www.davehuang.io/start/)同學寫的文章，文章中談到了他在創作過程中經歷的痛苦與拖延。 文章並不完美，但我卻很自然地把整篇看完了。 透過他的文字，我能感受到他的掙扎，也能看見他所看見的世界。我當下看的感覺是，他應該沒有用 AI。(又或者他用得太淋漓盡致了讓我察覺不出來。) 也正是這樣的文字，讓我願意停下來，把時間交給他。 這不禁讓我思考：到底是什麼樣的文章，能夠真正收下我的時間與注意力？ 思考後我第一個念頭是：當它是某個人生命中的一個片段，我就願意讀。 但我覺得這個結論還不夠完整，應該還有更多理由。 就在差不多同一時間，我讀到了 Paul Graham 的一篇關於寫作的[文章](https://paulgraham.com/writes.html?ref=davehuang.io)，他探討到，為什麼很多人對於寫作這件事情有很大的障礙? 甚至可說，寫作這件事對很多人來說是非常痛苦的? 因為它很難。 為什麼難? 因為你若要寫得好，就得想得透徹，而**想透徹這件事情本身就很難。** --- 回頭看，我最開始寫作是在我大學時期。當時寫下的，除了一些生活中的不滿、情感的抒發，還有一些自以為是的見解。 更多時候，其實也是一種逃避。 低潮時，我會帶著筆電躲進交大的浩然圖書館，找一個被柱子擋住的隱密座位，先是翻幾本建築雜誌、藝術雜誌，逃避一下 (逃避寫作，然後寫作也是逃避，所以可以說是逃避的逃避)，然後才開始打字，寫下自己的想法。 對這個分數至上的校園體系來說，那一天的我大概是「沒有產值」的。 但對我自己而言，我覺得那是很有生產力的一天。 因為在寫作的過程裡，我的生命會變得比較清晰一點，像是一種內在的校正機制。同時也抒發了我 DNA 裡對於創作的渴望，以及對未來某個可能性的自我期許。 那是我寫作最早的樣貌。 --- 而創立這個 blog，是因為我讀到了 [Unscripted](https://www.amazon.com/UNSCRIPTED-Life-Liberty-Pursuit-Entrepreneurship/dp/0984358161?ref=davehuang.io) 這本書，被它所深深打動，決定走向它所描繪的一條路。而我想一邊走，一邊把自己看到的世界寫下來。 當然，裡面也混雜著很多其他動機。 好比說我想做出好的軟體這件事。我知道好的產品需要 distribution。所以某種程度上，這個 blog 也帶著一點實驗的意味，實踐著自己對於 distribution 這件事情的認知。而 distribution 代表的是寫作這件事不再只是自己寫著自 high，還需要是別人看得懂，甚至看完了能產生正向[影響力](https://www.davehuang.io/spcl/)。 而在這些不同的動機交織之下，這件事情就開始了。 為了能把這件事情做好，我甚至去上了一門[創作課](https://www.davehuang.io/start/)。在上完這門課之後，我認知到若要掌控寫作這門技術，我需要透過「量」來打開一道又一道的門。 中間有好幾次，我曾以為自己看見了一套公式，好像理解了寫作的某種道理。但回頭看，那些理解又常常顯得有點粗淺可笑。 --- 我和另一位同樣也在寫作的朋友討論過一個問題：AI 在寫作這件事情裡，應該參與到什麼程度？ 我們都糾結過，被 AI 插手過的寫作到底還算不算是我們自己的創作? 不論是討論式的將模糊想法拼湊成一篇可讀的文本，又或是巧妙的運用提詞將生活片段編織成一個故事。 我很坦白地跟他說：當我讀一篇文章，很快就察覺主體是 AI 生成的，我通常就不太想讀了。因為那對我來說是一種浪費時間——那不是你的思考，也不是你的觀點。 接著我去想，如果一個人的寫作能力大概落在 20 分，他可以輕鬆透過幾個 prompts讓 AI 把一篇文章拉到 80 分。但問題是，20 分到 80 分之間，那 60 分成長軌跡，你就再也不會經歷到了。 人類本來就是懶惰的生物，我們很自然地會去尋找那條最省力的路。如果有一條捷徑可以直接抵達好結果，大多數人都會選擇那條路。 但這違反了學習的本質。 真正重要的能力，都是在那段 **緩慢、笨拙、又痛苦** 的過程裡淬鍊出來的。你必須一次又一次地寫得很爛，一次又一次卡住，寫得很尷尬不想讓人看到，所以只好重新改良結構與編排。 但也正是那個過程，你才真正開始建立起自己的能力。 所以我真正想提醒自己的，其實不是「不要用 AI」。 而是要 see the bigger picture，要有意識地讓自己經歷那段痛苦，不要取巧，也不要逃避。 要先能跨過運用文字這個載體的能力門檻，在那之後，才能進入一個更自由的意識空間，在這空間中雕琢自身**思考的能力**。 AI 或許可以幫助我們生成漂亮文字，但它無法替我們經歷思考。 如果你還沒有開始寫作，又或仍舊仰賴 AI 幫你 gen 出巨量電子雜訊，我鼓勵你真正用自己的手，開始寫作的旅程。這過程保證你痛苦，但在巨量練習後，在某個遠處的境界裡，你將獲得清晰、獲得連結，偶爾也獲得一點點愉悅。 ### 後記 回到前面所提到的自我提問：我為何願意駐足這位同學寫的文章？儘管不完美。 除了這是他個人獨特的生命體驗外，更在於我感受得到他在上面花的苦心與歷程，我下意識的給了這篇文章一個 genuine respect，它帶給了我真實價值，不論是情緒價值也好、某種自我提醒也好。 而這也是我所追求的、想打造的產品樣貌：儘管不完美，用戶感受得到被 respect，他們生命中的某個問題與痛點被解決，得到了巨量價值。 ![](https://www.davehuang.io/content/images/2026/03/IMG_1391.png) 台北終於放晴了 ### Protect Your Context URL: https://www.davehuang.io/context/ Last updated: 2026-03-08T06:15:26.000Z 農曆年連假結束後的短短兩週內，我的生活很快又變得混亂起來。 工作節奏需要重新銜接、社交邀約開始堆疊、生活裡的各種瑣事也等著被處理。作息因此崩壞，注意力被待辦事項切得零碎。 就在這個時候，朋友推薦了 Bryan Johnson 的《8 Steps to Reclaim Your Life》 Bryan Johnson 整理出八個讓生活回到正軌的步驟，大致圍繞在幾個很基礎的原則上： - 維持穩定的睡眠 - 規律運動 - 吃得簡單乾淨 - 減少干擾注意力的資訊來源 - 保留一些與人真實互動的時間 看完之後，我照著這幾個行動項目，在生活中做了調整。 這些改變分開來看都微不足道，但加在一起，確實讓我的生活重新回穩，思緒也更清晰。 ## **大腦的 Context** 在反思的過程，我有一種很強烈的感覺：這些道理我早就知道了不是嗎？ 睡好、運動、少滑手機、專心做事，都是再熟悉不過的道理，為什麼總得透過一個權威人士再說一遍，我們才會重新認真對待？為什麼每隔一段時間，生活又會慢慢變得混亂，然後我們再一次回到同樣的起點？ 也許問題從來不是我們不知道該做什麼，而是**我們大腦的 context，很容易被污染。** 在 AI 領域裡，context window 指的是語言模型一次能「看到」的資訊量。超出這個範圍的東西，對模型來說就等於不存在。 研究也發現，context window 越長並不代表模型表現一定越好。當對話裡摻雜了大量不相關的資訊、前後矛盾的指令、或是早已過時的中間推論時，模型在判斷「什麼才是重要的」時反而容易被這些雜訊干擾，難以聚焦在真正關鍵的部分。 人類大腦的運作方式也是如此。 仔細回想一天的生活，其實不難理解為什麼我們腦中的 context 很容易變得混濁。 現代生活的資訊密度極高，它們以非常零碎的方式進入我們的意識——訊息通知、分頁切換、演算法推送。 我們很少能長時間停留在同一個 context 裡。 生活看起來好像一直很忙，但很少真正進入一個清晰而專注的狀態。每一件事情的處理都只停留在很淺的層次。 ## 幫助整理 Context 的習慣 而很多被視為「好習慣」的事情，其實有著一個共通點：它們能幫助我們重新整理腦中的 context。 瑜珈跟冥想清理心裡的噪音； 健身替身體與情緒做 reset； 散步讓思考暫時離開密集的資訊環境。 我長期寫日誌，記錄自己每天做了什麼、感覺如何。回頭看那些數據，我發現了一個規律——當生活開始變得混亂時，習慣的消失是有順序的。 ![](https://www.davehuang.io/content/images/2026/03/-------2026-03-07-------9.47.30.png) Peak Pals weekly goals 最先消失的是瑜珈跟閱讀，因為它們「最不緊急」。接著是健身，被臨時的工作量排擠掉。然後作息開始鬆動，晚上熬夜，隔天靠咖啡因撐過去，進入惡性循環。 每一步看起來都是合理的取捨，但實際上是 context 在一層一層地崩塌，思緒變得越來越混亂。 當我照著 Bryan Johnson 的這些行動建議開始重整作息——好好睡覺、規律運動、減少資訊干擾，刻意替自己保留不被打擾的意識空間後，大腦隨之變得清晰，情緒也好很多。 在上一篇[文章](https://www.davehuang.io/productive-lny/)中，我提到了農曆年連假那幾天，我刻意暫停了社交、工作與移動，給自己大段不被打擾的時間，每天只專注在一兩件事情上。那段日子我既快樂又高效，現在回頭看，不是因為我突然變得更有紀律，而是 context 終於乾淨了。 我清楚知道當下重要的是什麼，以及我要怎麼去逐步實現。 ## 每天的賽局 在我過去的[文章](https://www.davehuang.io/playground-1/)中，我將人生類比為遊戲（賽局），而在這賽局中，能夠投注的主要籌碼是[「時間」與「注意力」](https://www.davehuang.io/rand/#%E7%B8%BD%E6%98%AF%E4%B8%80%E6%A8%A3%E7%9A%84%E7%B5%90%E8%AB%96%EF%BC%9A%E6%99%82%E9%96%93%E8%88%87%E9%81%B8%E6%93%87)。 每一天，我們都在把這些籌碼分配到不同的牌桌上——工作、學習、健康、娛樂與關係。 而這些分配，往往是被當下的 context 所左右。 大多數人的一天，其實是這樣過的：100 個籌碼，押在 100 件不同的事上。 每一注都很小，但每一注都有即時的多巴胺回饋。回了一封信、滑了一段 Reels、處理了一件小事。看起來一直有在「做事」，但從期望值的角度看，這些分散的小注很難帶來真正的回報。 為什麼？ 因為很多真正能改變生活的事情，都有臨界點：建立專業能力、完成一個作品、培養一個習慣。累積不到那個門檻，投入的東西就等於零。就像燒水到 99 度還是不會沸騰。 你以為自己在平衡，其實是在確保每一桌都輸。集中籌碼才有機會突破，而突破之後的回報往往是非線性的。 只有在 context 清晰的情境下，我們才能做出期望值最好的 calculated bet。 ## 保護 Context 的策略 如果 context 決定了我們每天把時間與注意力押在哪裡，那麼要玩好這場賽局，我們需要有意識地保護自己的 context。 把大腦的 context 視為一種需要被照顧的「身體器官」，而不是任由它被各種資訊與任務佔滿。 就像我們每天會刷牙、洗澡一樣，context 其實也需要被定期維護。 清理雜訊、限縮任務，替自己的 context 建立秩序，時間與注意力才更容易停留在真正重要的事情上。 當我在使用 AI 工具時，除了計畫模式（`/plan` ），我最常用的兩個指令是 `/clear` 與 `/compact`。 它們的作用其實很單純：清理對話、壓縮 context，讓 AI 接下來的思考重新變得清晰。 很多時候，好的產出並不是來自更多的 prompts，而是來自更乾淨的 context。 人也是如此。 ![](https://www.davehuang.io/content/images/2026/03/-------2026-03-07-------5.17.44.png) My beloved Claude Code ### Protect Your Context URL: https://www.davehuang.io/context-en/ Last updated: 2026-07-27T14:53:19.000Z In the two short weeks after the Lunar New Year holiday, my life fell apart again. Work needed catching up. Social invitations started stacking. Everyday errands waited in line. My sleep schedule collapsed, and my attention got chopped into pieces by an endless to-do list. That was when a friend recommended Bryan Johnson's *8 Steps to Reclaim Your Life*. Bryan lays out eight steps for getting life back on track. Most of them come down to a few basic principles: - Keep a steady sleep schedule - Exercise regularly - Eat simple, clean food - Cut sources that pull your attention away - Leave time for real interaction with people After watching it, I started adjusting my life around those action items. Each change looked trivial on its own. Taken together, they really did help my life settle again, and my thinking got clearer. ## **The brain's context** While reflecting on this, one thought kept coming back: hadn't I already known all of this? Sleep well. Exercise. Spend less time on your phone. Focus on what you are doing. None of this is new. So why does it take hearing it again from an "expert" for us to take it seriously? And why does life slowly fall into chaos every so often, until we end up back at the same starting point? Maybe the problem was never that we do not know what to do. Maybe the brain's context just gets polluted very easily. In LLM's term, a context window is the amount of information a language model can "see" at once. Anything outside that window might as well not exist for the model. Research also shows that a longer context window does not automatically mean better performance. When a conversation fills up with irrelevant information, conflicting instructions, or outdated middle conclusions, the model has a harder time telling what matters. The noise gets in the way, and it struggles to focus on the parts that actually count. The human brain works a lot like that. If you replay an ordinary day, it is not hard to see why the context in our heads gets murky so easily. Modern life is packed with information, and most of it arrives in fragments: notifications, tab switching, algorithmic feeds. We rarely stay in the same context for long. Life looks constantly busy, but we rarely enter a clear and focused state. We handle everything at a shallow level. ## **Habits that restore context** A lot of what we call "good habits" share one thing in common: they help us clean up the context in our heads. Yoga and meditation clear mental noise. Working out resets the body and emotions. Walking gives thinking a temporary break from an information-heavy environment. I have been [journaling](https://peakpals.io/?ref=davehuang.io) for a long time, writing down what I did each day and how I felt. Looking back at that data, I noticed a pattern: when life starts getting messy, habits disappear in a particular order. ![](https://www.davehuang.io/content/images/2026/07/image-2.png) Peak Pals weekly goals Yoga and reading go first, because they feel "least urgent." Then the gym gets squeezed out by unexpected work. Then my sleep schedule loosens. I stay up late, lean on caffeine the next day, and slide into a vicious cycle. Each step looks like a reasonable trade-off. What is actually happening is that context collapses layer by layer, and my thoughts get more and more confused. When I started rebuilding my routine around Bryan's suggestions, sleeping well, exercising regularly, cutting information noise, and deliberately leaving myself some uninterrupted mental space, my mind got clearer and my emotions improved a lot. In my previous article, I wrote about those few days during the Lunar New Year holiday when I deliberately paused social life, work, and travel. I gave myself long stretches of uninterrupted time and focused on only one or two things each day. Looking back, those days felt happy and productive not because I suddenly became more disciplined, but because my context was finally clean. I knew what mattered in the moment, and I knew how to move toward it step by step. ## **The daily game** In earlier articles, I compared life to a game. The main chips we get to bet in this game are time and attention. Every day, we place those chips on different tables: work, learning, health, entertainment, and relationships. Those bets are rarely deliberate. The context of the moment decides for us. Most people's days look like this: 100 chips, spread across 100 different things. Each bet is tiny, but each one comes with an instant dopamine hit. Reply to an email. Scroll a few Reels. Knock out a small task. It feels like you are always "doing something," but from an expected-value perspective, these scattered little bets rarely produce a real return. Why? Because a lot of the things that actually change a life have a tipping point: building expertise, finishing a piece of work, forming a habit. If you never reach that threshold, the effort might as well be zero. Heating water to 99°C still does not make it boil. You think you are balancing. What you are really doing is making sure you lose at every table. Concentrating your chips is what gives you a shot at a breakthrough, and after the breakthrough, the return is often nonlinear. Only when context is clear can we make the calculated bet with the best expected value. ## **Protecting your context** If context decides where we bet our time and attention each day, then playing this game well means consciously protecting that context. Treat the brain's context like an organ that needs care, not something every piece of information and every task is free to occupy. We brush our teeth and take showers every day. Context needs regular maintenance too. Clear the noise. Limit the number of tasks. Put your context back in order. Then time and attention have a better chance of staying with what actually matters. When I use AI tools, aside from plan mode (`/plan`), the two commands I rely on most are `/clear` and `/compact`. Their job is simple: clear the conversation or compress the context, so the next round of thinking can start clean. Good output often comes from cleaner context, not more prompts. The same is true for people. ![](https://www.davehuang.io/content/images/2026/03/-------2026-03-07-------5.17.44.png) My beloved Claude Code ### 最有生產力的農曆年 URL: https://www.davehuang.io/productive-lny/ Last updated: 2026-03-13T09:26:22.000Z 今年農曆年我做了一個決定：待在台北，不回南部過年。 我很珍惜大家聚在阿嬤家的那種年味，但今年我想維持年初到現在的開發節奏。為了不讓自己卡在「人回去、頭腦還懸在工作上」的矛盾狀態，我決定把年假的九天留給自己。 我把這九天視為一場模擬實驗：如果我是一名全職 Indie Hacker，我的完美日常會長怎樣？代價是少了一次全員到齊的過年，但我也因此得到一段完整、純粹的時間。 年假開始前，我先在 [Peak Pals](https://peakpals.io/?ref=davehuang.io) 寫下目標： - 上線 Peak Pals 的 SEO blog - 啟動下一個 side project 開發 - 上線一個自架的 Ghost 技術部落格 - 重構健身菜單 - 清空大腦，思考下一步 ## **預期產出 vs 實際成果** 年假結束後回頭看，完成度大概只有預想的 7 成： - \[延誤\] 上線 Peak Pals 的 SEO blog **→** *花了兩天，超出預期* - \[部分完成\] 啟動下一個 side project 開發 **→** *只建構了專案基底，未完成 MVP* - \[失敗\] 上線一個自架的 Ghost 技術部落格 **→** *完全沒時間* - \[部分完成\] 重構健身菜單 **→** *弄了一半* - \[成功\] 清空大腦，思考下一步 **→** *思緒更清晰* - \[意外收穫\] 每天曬太陽、爬山 - \[意外收穫\] 寫了兩篇文章 那少掉的 3 成跑去哪了？ 主要花在整理思緒、曬太陽、跟朋友相處。 前兩天花了點時間洩壓，把年前累積的工作張力放掉。後面幾天台北天氣真的太好，涼涼的、又有太陽。這種天氣在台北可說是稀世逸品般的存在，不出門總覺得可惜，我就常常拎著一本書去公園坐著曬太陽。也臨時起意，約朋友去爬山。 老實說，我原本只排了一天放鬆日，其他天都想專注在 coding。看著幾個沒打勾的項目，確實會有一點罪惡感。但回頭看，這些休息跟梳理出來的思緒，我覺得值得。 我在衝刺 mode 和放鬆 mode 之間，大概做了 7:3 的配置。 ## **多巴胺這件事情比我想的複雜** 這九天我注意到一件有趣的事——電玩對我的吸引力下降很多。 平常工作忙到情緒快暴走時，電玩往往是一個出口。但當時間掌控權完全在我身上，那種暫時逃避的需求反而下降。 相反地，做 side project、寫文章這些正事帶來的多巴胺更純淨、更扎實，吸引力也就上升了。 我不認為娛樂就該被完全移除，若沒有放鬆緩衝，人會開始渙散、思考也會僵化；但如果玩得太開心，隔天也會很難拉回工作需要的專注頻段。我覺得人類這個硬體可能有點弱（或我不夠強），主動校正大概是一輩子的功課。 > 排定的放鬆日：早上跟朋友吃早午餐；下午去野餐、曬太陽、看書；晚上再聚在一起吃美食，看《單身即地獄》狂罵崔美娜秀……隔天真的很難拉回專注模式，太開心了。 ## **同樣的運動，不一樣的心境** 這九天我幾乎用跟平常工作日一樣的時間、同樣的強度在運動，但感受完全不同。 平常健身的時候，腦子裡多少都跑著一個背景程式：等一下幾點有會議、回去後有什麼事還沒做完。它不是什麼很大的負擔，但它一直在，讓我無法真的進入當下。 這九天那個背景程式關掉了，運動就只是運動，我反而更能享受每一個動作的過程。 這也提醒我一個現實：作為團隊 tech lead，上班與下班的界線對我一直偏模糊。管理者的工作之一是處理外部依賴——不是自己做完就結束，而是一件任務是否有被完整承接、落地。這種心智損耗是結構性的，不是時間管理能解的，調整心態也很有限。 但 Indie Hacker 的邏輯不一樣：有地方沒做好，責任鏈很短，直接回到自己身上。我失敗，是因為我哪裡決策錯了；我成功，也是因為我哪裡做對了。那種「被別人的進度牽著走」的懸掛感，應該可以少很多。 ## **生活裡的毒素** 上面這個體悟讓我進一步去想：生活裡有哪些毒素，正在慢慢侵蝕我的心智，讓我到了某個臨界點就容易進入 [burnout](https://www.davehuang.io/burnout/) 循環？ - 有一些是「不得不」，只能用自己的免疫力扛過去 - 有一些則是自己的想法轉不過來造成的 這次我閱讀到了一篇[創作課](https://www.davehuang.io/start/)同學寫的 [7:3 工作心法](https://vocus.cc/article/69948e3afd8978000129f462?ref=davehuang.io)，有種被點醒的感覺。（這期間有餘裕把積很久的待讀清單劃掉，真爽） 有時候我自詡在工作上很盡責，結果反而成了低效率組織裡的自我逞罰。長遠看，這幫不到任何人，甚至有點像職場浪漫主義的自high。 專注力拉回自己運行的航線，校正羅盤，先確保我能穩定航行，才有餘裕把組織層級的事情慢慢推往正軌。 ## **北極星依然清晰，羅盤重新校準** 這段時間我慢慢意識到，那些生活裡的毒素，其實就像航行途中悄悄偏移航線的洋流。 即便北極星（我的最終目標）依舊清晰不變，羅盤（我每天做的每一個選擇）卻可能在不知不覺中受到干擾。這次假期中的大量思考，讓我能重新校準羅盤──方向一樣，但路徑變得更清晰。 能夠活得有意識、有覺察，一直都是我很重視的事。所以就算少打勾幾個待辦，我也覺得很值得。 ## **結語** 這是一個很棒的農曆年。 雖然少了家人的相處時光，我還是會想念，但整體來說，這幾乎是我這輩子最有生產力的一個年假。 這為期九天的實驗結束，我帶回的不只是開發進度，也帶回很多資訊——在完全自主的時間裡，我真實的運作模式是什麼。 這些觀察不會直接變成一份待辦清單，但會慢慢滲進開工後的每一個選擇裡。哪些事值得花時間、什麼樣的節奏更適合我、哪些慣性需要改進。 --- ### 最後補一個關於時間感知的心得 時間過得快，有兩種截然不同的質地： - 一種是渾渾噩噩的自動導航，日子過去了，你也不太記得發生了什麼 - 另一種是充實且活在當下，時間一樣飛快，但你知道自己每一天在做什麼、為什麼而做 這次的農曆年是後者。開心是扎實的，前進的軌跡也很明確。 --- 其中一天跟朋友爬山，前面遇到一對爺爺奶奶帶著孫女。奶奶對小女孩說：「今天回去要整理書包囉！禮拜一要開學了！」小女孩嘟著嘴假裝沒聽到。後面我們這夥上班族聽到，反而比小女孩更 blue 🤣。 回想起來，那種學生時代對寒暑假的期待感，我已經好久沒體驗了。這次就是我久違的寒假。 ![](https://www.davehuang.io/content/images/2026/02/IMG_1181.png) 這種天氣你要我怎麼待在家 coding 呢！是不是？ ![](https://www.davehuang.io/content/images/2026/02/IMG_1216.png) 拎著書跑公園閱讀的節奏 在 Peak Pals 上加我為好友，一起成長！🤝 🚀 [Add Dave on Peak Pals ](https://peakpals.io/profile/dave-huang?ref=davehuang.io) ### Farewell, Black Cat —— 關於優雅、野心與自由 URL: https://www.davehuang.io/black-cat/ Last updated: 2026-03-13T09:28:56.000Z 信義區最繁華的地帶，有一隻身形豐腴、儀態自信的黑貓。 她是我前往健身房的路上，幾乎每天都會遇見的存在。 她跟別的野貓不太一樣。每當我經過，她不急著逃開，只是直啾啾地盯著我看。等到我接近她的社交距離邊界，她才優雅地向後一躍，跳進上億豪宅的華麗柵欄內，像是那裡本來就該是她的邊界。 她的毛色很漂亮，烏黑亮麗，乾淨得不像流浪貓。 我跟她有一種很強的連結感。 --- 經過這些大樓的時候，我往往正走在一段內心掙扎之中。 健身這件事，我其實一直沒有真的享受過。我覺得它消耗了我大量的時間，佔據了生活的節奏，但我又清楚知道，這是一件不得不做的事。 所以走在這段路上，我常常抬頭看著這些超級大樓，心裡反覆問同一個問題： 到底是怎樣的人，有資格住在這裡？ 他們付出了什麼樣的努力，把握住了什麼樣的機會，才能買下這樣的房子？ 我知道其中一定有很多不對稱的世代級財富，但我也相信在這裡一定有人是憑藉著自己的實力，白手起家走到這個位置。 而我正走在一條不確定會不會通往那裡的路上。 --- 每當我陷入這種沈思、進入自我省思的片刻，那隻黑貓就會出現。 她總是從旁邊從容又悠哉地「滑～」過去，像是完全不在意這些我腦中翻騰的問題，卻又強制地把我焦躁的思緒拉回地表。看著她，我的內心總是會安靜下來。 雖然我們之間始終保持著一段距離，但對我來說，那也是一種奇特的陪伴。 即使妳住在這裡，但我總覺得，妳跟我其實有一點像。 --- 我羨慕的，從來不只是住在那些大樓裡的人。 我真正嚮往的，是一種狀態——能夠坐擁繁華與資本，卻又在這場「[遊戲](https://www.davehuang.io/playground-1/)」之中，超然地做自己，活出屬於自己的美學。 那隻黑貓就是這種狀態的化身。 她靠近權力與財富，卻不屬於其中； 她在場，卻不需要被認可； 她不是展示品，更不是寵物，她只是很自然地存在著。 我想要的，也許正是那樣的存在方式。 --- 我知道，走在這條努力的道路上，一定會有很多失去。 這不是我現在才知道的事，而是我早就隱約明白，卻一直不太願意直視的事實。 黑貓的存在，像是在這條路上陪我走了一小段。她讓我在反覆質疑與比較的過程中，有一個可以短暫停靠的對象。她沒有給我答案，卻讓我不至於被問題完全吞沒。 我從來不確定她是不是有主人。 我總覺得她應該是有的。 但同時，我又忍不住想，如果她是一個人，比起她的主人，她或許會覺得我跟她更相像。 --- 昨天夜裡，我再度離開健身房，騎著車經過那條平常會看見她的小巷。 巷口立著一個三角錐。 我心裡一沉，開始瘋狂祈禱，不要是我心裡浮現的那個畫面。但那一幕就像既視感一樣，像兩塊磁鐵不可避免地貼合，硬生生地吸進我的視線裡。 妳躺在那裡，一動也不動。 那一刻，我知道我今晚一定睡不好了。 --- 躺著的妳，一如既往的優雅。 像是終於可以休息了。 我知道，在寫下這些文字的過程中，我一定會很難過。但我也很清楚，如果我不把妳寫下來，妳就真的消失了。 在這條我早就知道會不斷失去的路上， 至少，讓妳停留在一篇我的文章與我的記憶之中。 ### Ocean's Eleven x 成功方程式 URL: https://www.davehuang.io/oceans-eleven/ Last updated: 2026-01-28T13:12:17.000Z 上個月與兩位朋友重溫《[瞞天過海](https://zh.wikipedia.org/zh-tw/%E7%9B%9C%E6%B5%B7%E8%B1%AA%E6%83%85?ref=davehuang.io)》（Ocean's Eleven）。 散場後我們聊起：「如果是我們，誰是誰？」 Marcus 說：「我覺得自己像 Rusty。我擅長規劃協調，雖然不想主動掌權，但為了達成目標，我願意動態補位。」 Frank 說：「我比較像 Linus 和 Livingston 之間。我喜歡偵查、靜態規劃，透過支援讓任務順利進行。」 而兩位朋友和我自己都一致認同：我像 Danny Ocean。 --- 我會這樣側寫 Danny Ocean 這個角色： Danny 心中有明確的目標，他能 envision 一場任務成功的軌跡。他的願景吸引人追隨，跟著他玩這場「遊戲」既充滿挑戰又好玩——Because he's a pro, he's got class. 但 Danny 需要 Rusty。 Rusty 有人脈找到對應的專家填補執行細節。他知道 Danny 心裡在想什麼，也適時 cover Danny 的思考盲點。 他們是完美的互補。 電影中，Rusty 看到 Danny 的第一句話是：「我好無聊啊。」 為什麼？因為 Rusty 在意的不是錢，是遊戲本身。而好的遊戲需要清晰的目標與獲勝條件——這正是 Danny 的拿手戲。 沒有 Danny，Rusty 有一堆專家但不知道要玩什麼。 沒有 Rusty，Danny 有完美劇本但無法開演。 我很羨慕 Danny & Rusty 這樣的友誼。這組合是男人的浪漫，太帥了！ ## 成功的方程式 這個月在 X 上最火紅文章，是 Dan Koe 的《[How to fix your entire life in 1 day](https://x.com/thedankoe/article/2010751592346030461?ref=davehuang.io)》。 文中他提出了成功的方程式： > **Success = Agency + Opportunity + Intelligence** > (成功 ＝ 行動力 + 機會 + 智慧) 他對 Intelligence（智慧）的定義也很有意思： 「越有能力在人生中獲得自己想要的結果，就代表有著越高的智慧。」 我認同這個框架，但我想補上二個關鍵元素。 ### **第一個是 Autonomy（自主權）** Agency（行動力）和 Autonomy（自主權） 聽起來很像，但其實是兩回事： - Agency 是個體的行動力——你是否願意並且能夠採取行動 - Autonomy 是個體的自主權——你是否有權決定自己的選擇 一個人可以很有行動力（每天工作 12 小時）， 但如果他不知道自己真正想要什麼， 或者他的選擇被外在期待所綁架（父母的期望、社會的標準）， 那他其實沒有真正的自主權。 反過來說， 一個人就算意識到自己有選擇的自由， 但如果沒有行動力去實踐那些選擇， 自主權也只是空談。 因此，Agency 和 Autonomy 必須同時存在：知道要去哪裡，也有能力到達。 ### **第二個元素是 Luck（運氣）** 這個元素是我的 mentor 幫我補上的。 當我分享這個成功方程式時，他立刻指出： 「你少了最重要的一個因子：運氣。」 他說得很對。 運氣是唯一「不能控制，但能放大」的因子。 你不能控制會不會遇到好機會， 但你可以增加被好機會撞到的機率。 所以我將 Dan 的成功方程式改寫為： > **Success =** > **Autonomy + Agency + Opportunity + Intelligence + Luck** > (成功 ＝ 自主權 + 行動力 + 機會 + 智慧 + 運氣) 當然，成功有許多形式，而這個公式只是一種抽象化的討論。 ### Ocean's 11 x 成功方程式 回到 Danny 和 Rusty 拍檔，他們完美詮釋了這個方程式。 **Danny Ocean = Autonomy 的代表** - 他決定要搞哪三家賭場 - 他構思整個計畫的願景 - 他知道需要哪些角色 **Rusty Ryan = Agency 的代表** - 他把願景轉化成行動 - 找到對的人填補每個角色 - 讓計畫真正發生 兩個人有著對等且同步的智慧得以識別機會，而當他們組合在一起，運氣被最大化。 ## Agentic 的未來 從文章開頭我和朋友的討論可以看出：每個人在擁有足夠的自我覺察後，都能識別出自己在團隊中的角色定位。 這些角色識別，可能代表「你覺得這遊戲最好玩的位置」， 也可能代表「純論能力來說最適切的位置」。 共通的是，我們都在思考如何在一個局中，最大化自身的槓桿。 這是一種稀缺的能力—— 抽離，看清自己在整體系統中的最佳位置。 這讓我開始思考： 如果我們擁有 Danny 的大局觀，能看到機會、構思願景、知道需要哪些角色，那我們是否可以用 AI Agent 來填補那些缺失的角色， 讓自己專注在AI 難以替代的位置上？ 我認為可以。 而我在工作上也經常這樣做，雖然現階段的 AI Agent 尚未有足夠的 toolset，但我認為這個時代背景之下，每個人都該往「Danny + Rusty」這樣的技能組合邁進，因為在人生賽局中，AI並不知道你真正渴望的是什麼，AI也無法在物理世界建立關係連結、做出人性化決策。 AI 可以做的是「執行層」的專業任務：寫 code、生成文案、設計 UI、分析數據。 同樣的 Ocean's 11，現在可能只要 Ocean's 2 + 核心任務的專業外包 + AI Agents。這是新時代的團隊配置。 不是「11 個專職成員」， 而是「核心成員 + 彈性協作網絡 + AI 系統」。 ### Pitfall: AI 絕對無法取代 Rusty 真人版的 Rusty 會： - 挑戰你的願景（你真正的 Why 是什麼？別跟我說是 Tess...） - 在你想放棄時推你一把 - 帶來你意想不到的機會（我認識一個人...） - 陪伴你度過人生的下風期 這些 AI 都不會。 AI 只會執行你的指令。 即使你設計好精美的題詞，模擬出這樣的一位 "Rusty Agent"，缺乏生命軌跡背書，你只會覺得這 model 很欠揍。 再者，它也不會在凌晨三點傳訊息說「我有個想法，一起來幹一票！」 ## 結語 我很喜歡這次透過電影討論起自身角色的過程。 與朋友們這樣的討論讓我看見了許多我在執行 Indie Hacking 路上的盲點。（而這也是AI無法帶給我的） 比方說：我還是太沈浸於 clean code & design pattern 這些 coder 範疇的事情，做這些看似「對」的事情會拉長開發期，對於產品交付與迭代反而是有害的。 透過 Ocean's Eleven 這個夢幻團隊的組成也讓我反思，一個強大的團隊所能槓桿出來的效益，絕對是指數性的，保持自身的 Autonomy 與 Agency，即使我們現在能很輕易地利用 AI Agent 來補足團隊的缺角，仍須時不時跳脫任務本身，思考是否有把自己放在對的位置。 另外我也問自己：如果能與 Ocean's Eleven 這樣的團隊一起玩這場遊戲，我還會堅持 solopreneur 嗎? ### 後記 我與 Marcus & Frank 相遇，是在一場讀書會。當我知道他們兩個都有著想「搞事」的念頭，想藉由生命中的 X factor 找到自己的 Why 時，我心中便有計畫在醞釀：我想透過一個有意義的挑戰進而讓彼此更深度認識，我也希望在這個過程中，我們都能最大化得到我們想獲得的東西。（比方說 Frank 想練習到的軟實力、以及我在 Marcus 身上看見他所擅長的事情，或許可以透過幫助他人得到一些體驗）。後來，這樣的「任務」也很幸運的順利落幕，達到了一個我心中認為的正和賽局。回想起我做的這些，還真覺得自己像是 Danny Ocean。 ## 本週紀錄 結束[連續創作](https://www.davehuang.io/process/)的幾週後，我慢下了生活步調。 有更多時間沉澱想法、閱讀素材， 也更有餘裕投入 Peak Pals v2 的開發與構思。 過程中不免仍有自我苛責與困境，但我感覺節奏正在往更好的方向發展。 這段時間，我和小 e 去了日本的岡山、廣島、尾道旅遊， 也花了很多時間在台北與朋友們度過高品質的相處時刻—— 就像這次和 Marcus、Frank 的電影討論；與內湖團的草莓桌遊聚；與 Darren 的早午餐兄弟對話；與 Ares & Henry 的酒吧深談。 2026 的農曆年我想給自己一個挑戰：把年假用來全力開發下一個 side project。待在台北，每一天的生活結構由：運動、Coding、休息、吃健康的 whole food 組成。我想一定會很有趣！ 也因為我過年沒打算回老家，我提早回了南部陪伴我的家人，我知道他們在新年看不見我一定會很想我的！🤠 ![](https://www.davehuang.io/content/images/2026/01/IMG_0821.png) ### Burnout 系列——別用控制來應對失控感 URL: https://www.davehuang.io/burnout/ Last updated: 2026-01-28T13:24:55.000Z 這是我在某個 burnout 時刻，和 [Claude](https://claude.ai/?ref=davehuang.io) 的一段對話： > 我：我不想爬企業階梯（corporate ladder）、我不想玩辦公室政治、我也不喜歡自己的績效與命運被掌控在別人手裡的感覺。但我快 burnout 了。 > Claude：你意識到那不是你想要的人生。所以你選擇了相反的路——Indie Hacker，完全自主。 > Claude：但現在的問題是：你用「成為 Indie Hacker」這個目標來逃避現在的失控感，結果反而制造了另一種失控：對時間的執迷。 Claude...我說你呀，有時候是真的太嗆了。但不得不說，他這次是對的。 在我過去的職涯中，面臨過無數次的 [burnout](https://zh.wikipedia.org/zh-tw/%E8%81%B7%E6%A5%AD%E5%80%A6%E6%80%A0?ref=davehuang.io)。在這些 burnout 中我發現有固定的規律，我試著逆向拆解它。我相信許多正在自我提升的人，也會面臨相同的情境。 所以我想把這次的經驗寫下來。不只是給你，也是給未來的自己。 ## 惡性循環 許多自我要求很高的人，都有著一套自己的進度管理系統—— 試圖用可量化的指標來卸載對自己的期待，感受「我有在前進」。 你是否也曾聽到親友說：「你已經很努力了，別給自己太大壓力。」 你笑著點頭。但你心裡清楚：你見過比你更強大的人，付出比你更多的專注與努力。所以你知道自己的努力，其實只是及格邊緣。 理性上你知道，最大的敵人不是「沒時間」，而是心理疲憊。 這種疲憊造成了一個詭異的落差：你的行為軌跡，永遠比你給自己的標準，低那麼一點。 也因為這種自覺，罪惡感便開始累積。 9-5 的工作表現下降（因為倦怠） → 5-9 的自主時間也無法好好投入（因為本身就累，沒有真正休息過） → 兩個都做不好，罪惡感更深 → 更想透過「擠時間」來彌補 → 更加倦怠 完美的惡性循環。 ## 真相：我在逃避失控感 你認為「每一分鐘不用在執行目標上都是浪費」。 這看起來像是紀律和努力，但實際上，你正在用工作來控制焦慮。 用控制來應對失控，本身就是一種新的失控。 這控制慾的根源是什麼？ 向下挖掘，是恐懼： - 害怕失敗？ - 害怕被掌控？ - 害怕人生被浪費？ - 害被自己沒有自己中想像中的那麼好？ 這些都是真實的。都是 valid 的人性本質。 但即使你達到目標，站上了預想的位置，你也會看見更多的痛苦和困難。 每一層成就，都會解鎖新的恐懼。 所以「透過完美掌控來逃離恐懼」這個策略，本質上是不可能成功的。 所以答案不在「更完美的掌控」。 答案在於：學著在不確定中活著。 不是漫無目的地變強，而是學會感受當下的每一個過程。 學會允許不完美。 學會允許失敗。 因為沒有任何掌控策略，能夠消除恐懼。 但你可以學著和恐懼共處。 ## 體悟與行動項目 以下是我在這一次 burnout 循環中，梳理出來的幾個體悟與行動項目。 ### 認知到自己正在 Burnout 第一步，是認知。 認知到自己正在 burnout，是打破循環的關鍵。 聆聽你的身體訊號： - 開始報復性熬夜 → 試圖用夜晚來「奪回」白天失去的時間 - 早上很難爬起來面對接下來的「正事」 - 對以往感興趣的事情都喪失興趣。電玩、影劇、運動...這些以往能幫自己充電的休閒都變成了「浪費時間」 一旦你意識到「啊，burnout 差不多要來了」，你才能抽離自己。 這很關鍵，因為感知往往比現實更糟。 即使現實在往好的方向走，感知還在對你大喊「不夠好」。 認知到在 burnout，並且試著找到根源，你才能真正去處理它。 ### 自我許可 365 天中，即使你 burnout 10 幾天，也不到 3%。 這也是旅程的一部分。接受它。 如果你無法給自己休息時間，覺得每一秒都應該用在生產力上，那你已經在用新的方式監禁自己。 我們都希望人生像火車一樣：建造好軌道，就能高效直達目標。 看著身邊的強者用高鐵般的速度在衝，我們也急著升級自己這台慢慢的莒光號，心想至少也要是自強號吧。 我們都不希望自己在人生的旅途上「誤點」。 但真實世界沒有軌道。 人生更像是船。 有時風來了，你能順勢而行。 有時逆風、有迷霧，你就在海上漂泊。 偶而有個小島，你就上去玩玩。 活在當下，讓[過程累積](https://www.davehuang.io/process/)。 問自己：「我要怎麼設計一個生活系統，讓我在接下來的 5-10 年可以持續運行它？ 」 在這個系統中，我能保持健康和快樂、我能欣賞沿途的風景。 同時，我知道這艘船正在駛向我理想的方向。 > You cannot control the wind but you can adjust your sails. ### 自我控制有隱形成本 想像你的身體是一台電腦。 大腦是 CPU，控制著所有的行為。 而任何對自己生活的控制——無論多麼微小——都有隱形成本（overhead）。 舉例來說，我的 burnout 就源自於過度「微管理」（micro management）。 我喜歡時間管理和目標管理（重度J人），甚至為此創造了 [Peak Pals](https://peakpals.io/?ref=davehuang.io) 這個目標管理工具。 出發點是對的——我深知自身惰性與拖延，所以需要透過系統來制衡它。 但這種微管理本身，反而成了心智負擔。 我試著控制得太精細了。每一分鐘都要有價值。每一個行為都要被追蹤。 這層管理本身消耗的能量，反而超過了它帶來的收益。 解決辦法不是「更精細的控制」，而是「放寬控制的尺度」，讓自己更有彈性。 處於衝刺期時，密集的規劃和追蹤很有用。但長期來看，這種高度的自我監督會耗盡你。 用「系統」來反制惰性與拖延是對的，但也別忘記將身體訊號納入考量： 當身體告訴你「現在就想衝」，就享受當下去衝。 當身體說「我累了」，就停下來修復。 不要試圖用意志力去強制一個固定的模式。畢竟我們不是機器。 ![](https://www.davehuang.io/content/images/2025/12/maxresdefault.jpg) Sheldon bot ### 找到休息與修復的方式，先求「活著」 「不要去想像一頭粉紅色大象」🐘。 我知道休息很重要。但當我進入上面講的惡性循環迴圈時，我的大腦就像被下咒語一般，更是無法進入休息。 我開始跟 AI 聊天，一步一步拆解自己 burnout 的主因，然後透過他給我的答覆，找出一個可以讓自己身體感受到休息的方式。 我開始去找朋友玩。（Thanks Jeff, love you） 我打給阿嬤與外婆聊聊她們的近況。 在這過程中，我發現自己是開心的。我也發現到自己有多久沒有將注意力向外看。我停止強迫自己要「有效率的玩」，只為了修復，我回歸到了能夠享受當下的狀態。 而也是到這一個階段後，又過了兩三天，我才終於能夠放下心中的焦躁，好好玩一款遊戲、好好看一部影片、好好聽一首音樂。 在這樣的 burnout 狀態中，光是做到「好好活著」，就已經非常足夠。 在完成各種責任的最低限度後，讓自己自動導航。 讓身體修復，不要感到內疚。 ## 結語 這是我一直想寫的「Burnout 系列」的第一篇。 從一開始規劃這個部落格時，我就知道要寫這個主題。 在職涯中，我已經面臨無數次的 burnout。 每次都像地獄一樣，但每次我都爬起來了。而且我也確實有在前進。 幾個月前，當我還在構思創作藍圖時，我還半開玩笑地想著：「好期待下次 burnout 來臨，這樣我就能好好用這個身歷其境的靈感寫下這篇。」 結果不出所料，它來了，深陷其中的我卻一個字都寫不出來，早被它揍得鼻青臉腫。 --- 我的理工腦讓我想找到一個規律，來有效的對抗這個頑強的敵人。 它就像是光與暗無法分離一般，每當我完成一個強大又充滿自信的衝刺期後，啪一聲又把我打回原點。 如同一種病一樣，要知道他是啥病，要先診斷（定義），再來想辦法治。 而這也是為什麼我想寫「Burnout 系列」。 不是因為我已經「解決」了 burnout，而是因為我開始明白：每一種 burnout 都不同。 每一次都會教我不同的功課。 對我來說這是一種能力，是可以練習的。而這也是我走在這條 indie hacker 之路上必將面對的課題。 ## 本週紀錄 禮拜一在 Peak Pals 上寫下「有點快要 burnout 了」後，朋友們開始給我鼓勵： ![](https://www.davehuang.io/content/images/2025/12/-------2025-12-27-------5.13.00.png) 我真正發現不對勁，是在某天下班後的夜晚，行屍走肉的走進 7-11，買了盒六入的金沙，癱軟的坐在公園長椅上，一顆接著一顆吞下。回過神來，金沙已經被我秒殺...這時我知道我已經爆了。 我心想我不是在戒糖嗎？但身體不聽使喚。 回家後對啥都提不起勁。打開 [Anno 1800](https://store.steampowered.com/app/916440/Anno%5F1800/?l=tchinese&ref=davehuang.io) 一玩就是三天。這是一款能夠任由我微管理 ＆ 完美主義無限擴張的瘋狂遊戲，所有元素都近乎可控、可最佳化。 ![](https://www.davehuang.io/content/images/2025/12/image.png) 但也因為這樣，玩到最後很無聊。而隨著發想這個 burnout 系列的文章，我體悟到——會無聊就是因為「可控」。 如果生命是全然可控，全然理性，到頭來我們只會感到無聊。也因為這樣，我們更要找到適合自己的方式來好好玩它。 --- 在我結束創作課的 12週連續創作挑戰後有個體悟：一個約定好的週更頻率，是很好鍛鍊自己寫作能力的方式，但創作對我來說需要沉澱期——讓想法沉澱、然後發酵，最終進行萃取，一週的週期對我來說太短，常常發出去的文章在未來的幾週需要反覆調整，但如果骨架歪了，之後再改裡面的肉，效益不大。 ### 限縮的自由——找到理想受眾 URL: https://www.davehuang.io/icp/ Last updated: 2025-12-21T07:46:50.000Z ## 咆哮的年代 1920 年代的美國，被稱為「咆哮的二十年代」。 一戰剛結束，經濟爆發式成長，中產階級收入大幅提升。這是美國人口史上第一次超過一半的人住在城市。 城市化帶來全新生活節奏，人們有了休閒時間和可支配收入。他們渴望娛樂、渴望知識、渴望跟上這個世界的變化。 在 1920 年代早期，電影還是默劇，廣播才剛起步，家庭電視還不存在。所以如果你想深入了解世界、想學習新知，大部分人最好的選擇是雜誌。 ![](https://www.davehuang.io/content/images/2025/12/data-src-image-409c03b4-87bd-4b8d-a30f-3e773f3fb44c.png) 20s 也因為這樣的時代背景，當你走進書報攤，你會看到雜誌越來越厚——你甚至有可能看到200多頁的雜誌。出版商在比拼誰的內容更全面。 因為雜誌的商業邏輯靠廣告賺錢，越厚能賣更多的廣告，也會帶給購買者一種「買到很多知識」，很划算的錯覺。 ![](https://www.davehuang.io/content/images/2025/12/data-src-image-63b97345-cef9-418d-8415-7931b841b60a.png) 但有一對夫妻注意到這種把雜誌越賣越厚的趨勢並不對勁。 華萊士先生（DeWitt Wallace）在一戰受傷住院，每天翻閱大量雜誌打發時間。他很想跟上世界變化，但厚厚的雜誌讓他感到挫折——太多廣告、太多重複、太多用不上的內容。 他開始用剪刀把值得讀的文章剪下來，濃縮成精華，釘成小冊子。 華萊士的小冊子開始在醫院成為最搶手的娛樂，大家都會很開心的傳閱這個小冊子，大家都說：「這才是我想要的！」 出院後，他和妻子繼續觀察市場趨勢，他們發現一個矛盾： 自從福特開始推行週休二日後，美國勞動人口的平均工時從每週 50 小時降到 45 小時，但人們反而覺得更忙了——城市化加快生活節奏，娛樂選項爆增，**注意力越來越稀缺。**（有沒有發現跟現在很像？） 當其他出版商還在想「我們還能加什麼內容？」時，Wallace 夫婦做了一個瘋狂的決定： > 「我們不服務所有想看雜誌的人，我們只服務一種人——生活忙碌、但依然渴望學習的人。」 ![](https://www.davehuang.io/content/images/2025/12/data-src-image-4582a914-58c0-4c4a-86c3-875506a0fe03.png) 於是他們創辦了《讀者文摘》，並且秉持三個原則： 1. 不追求全面，只挑最值得讀的 2. 不追求厚度，口袋大小就好 3. 不追求原創，精選濃縮就好 在剛推出時被業界嘲笑：「二手內容，誰會買？」 結果？他們成為20 世紀最成功雜誌之一，巔峰時期全球有1億讀者 為什麼？因為他們問對了問題： > 不是「我們能做什麼」，而是「誰最需要我們？」 ## 始於矛盾的知識探索 在過去連續 12 週的[密集創作](https://www.davehuang.io/process/)中，我一直有一個問題跟困境，那就是： 寫了這麼多內容，我既想抒發自己的想法，又想創造真實的價值給讀者，這兩件事該怎麼平衡？ 在找尋答案的過程中，我學到了一個概念，也就是這篇文章的主軸——[ICP](https://en.wikipedia.org/wiki/Qualified%5Fprospect?ref=davehuang.io) (理想顧客) ### Find Your Amy > Credit: 以下舉例的概念，最初是受到 A Smart Bear 這篇 [Selling to Carol](https://longform.asmartbear.com/icp-ideal-customer-persona/?ref=davehuang.io) 的啟發，我改了其中舉例的英文名字來貼近台灣人習慣的英文名。 在創作的領域常看到一句話是「當你想寫給所有人看，到頭來等於沒人會看。」 那要如何知道要寫給誰看？ 解法是：找到你的 "Amy" ![](https://www.davehuang.io/content/images/2025/12/data-src-image-04065d92-ca9f-4355-b2a1-2c0ae6a23a2f.png) 她，名叫 Amy，她是你的理想讀者，是一個非常具體的存在。 當你們看到一個這樣子形象的人，腦中對她會有什麼第一印象？ 我們可以用這樣的骨架來建構這個人： - 她在什麼情境中？ - 她遇到什麼問題？ - 她想達成什麼？ 而這也是逆向工程找到你理想受眾時的假定，我們可以試著用這樣的填空來定義 Amy： 「我的內容是寫給：在\_\_\_\_\_\_（情境）中，遇到\_\_\_\_\_\_（痛點），想要\_\_\_\_\_\_（目標）的人。」 以上面這個圖片的形象來說，我會這樣去想像： 「我的內容是寫給 Amy，她是一名在外商工作了 4 年的產品經理，對市場已經累積出自己見解，但厭倦了辦公室政治，想透過內容創作建立個人品牌並轉職獨立顧問」 這只是個舉例，但這樣的發想，要越明確越好。並且在未來的創作中（不論是產品或是內容），為這樣的人物誌（persona）量身打造。 ### 設定 ICP 時的難處 在假定 ICP 時的最大恐懼就是： 「如果我只寫給 Amy，我不是把其他人都排除了嗎？我的市場不就變小了？」 事實恰好相反。 ![](https://www.davehuang.io/content/images/2025/12/data-src-image-4929d5b3-dde7-4995-8d0d-dcc80d62e479.png) 我們假定，你心中預想的 Amy 真實存在，而你所產出的內容的所有優點，都完美的符合她的需求： 1. Amy 想理解小型新創公司的成功案例 2. Amy 想看見創辦人如何透過執行力突破臨界點 3. Amy 想看見創辦人跟他所解決的痛點間，是有實質的個人連結 而你身為一個創作者，也有著你做不出來的內容，可以視為缺點，但這些缺點反而是 Amy 最討厭的幾個概念： 1. Amy 討厭一直探討 Tier 1 龍頭的造神文章 2. Amy 討厭談論商業的理論 3. Amy 討厭一直聚焦於冰冷的銷售數字 也因為妳完美的符合了她注重的要點，也因為你缺少的恰巧是她討厭的（負負得正），近乎所有的 Amy 都會追蹤你、關注你的內容、使用你的產品。 ![](https://www.davehuang.io/content/images/2025/12/data-src-image-bee3bc8e-4273-4d65-b30e-2de9f774ad2c.png) 而有另一群人，他並不完全符合 Amy 的形象，我們稱之為 David。 他大致認同你的優點，對你的缺點是中性～不在乎之間。 10個 David 裡有3\~5個會想追蹤你，但 David 的人數是 Amy 的 10倍！ ![](https://www.davehuang.io/content/images/2025/12/data-src-image-dbd2ad7f-7cca-47c1-84ac-2e136433d6ab.png) 再來到下一層，我們找到一群名為 Kevin 的群體。 你的內容只有一小部分被他視為有價值，他其實在你跟其他人之間，有更好的選擇，10個 Kevin 裡面只有 1\~2個會稍微看你一眼。但 Kevin 的人數是 David 的 10倍。 ### 關鍵洞察 當你只針對 Amy 進行創作，反而能藉此讓 David 和 Kevin 這兩個群體浮現。 David & Kevin 的轉化率較低，但因為他們的基數更大，你得到的總受眾，遠超過你用模糊定位吸引到的人數。 如果你所創造出的內容，連你自己設定的 Amy 都不一定能夠買單、接受，那更不用想像 David & Kevin 會買單。 這是一種自我檢核的機制，也銜接回前面所提出的「當你想寫給所有人看，到頭來等於沒人會看。」 唯獨在確保自己的產出，能夠完全「守住」自己所能服務到最好的一群人時，接下來的調整與改變才有一個系統性的基礎。而不是一昧的想討好所有人，到頭來沒有人被你幫助到。 在尚未突破關注力的閥值前，受眾都無法真正「看見」你能為他提供什麼。 ### Subaru 找到 ICP 的故事 ![](https://www.davehuang.io/content/images/2025/12/data-src-image-dcb65b83-efed-41bc-9975-e09befb8efca.png) 除了開頭的讀者文摘故事以外，這邊要講述另一個透過找出 ICP 而成功的故事。 時間來到90年代。這時的 Subaru 發現他們的銷量正在下滑**。** 他們想要挽救這個情況，於是開始調查自己的客戶族群，他們發現自己的主力客群來自五種人物誌：老師、衛生單位人員、IT工程師、戶外運動愛好者，最後，則是女同志。 女同志在這群顧客人物誌中，有個最強大的購買意願，她們願意購買 Subaru 的概率是其他人的 4 倍！ 問題是——那是 1990 年代，當時的美國社會對 LGBTQ 極不友善。（當時IKEA甚至因為播有同志內容的廣告，總公司收到炸彈客威脅。） Subaru 最終做了一個豪賭：all-in 同志市場。 ![It's not a choice. It's the way we're built](https://www.davehuang.io/content/images/2025/12/data-src-image-3ce3361b-eb12-44f5-b5dc-15aa006ad6da.jpeg) 在他們的廣告文宣中，除了大膽的支持當時時代背景不友善的 LGBTQ 客群外，他們也積極的圍繞著這個群體最在乎的核心訴求——「便宜、安全、越野、不花俏」。 結果？接下來 10 年，Subaru 成為美國成長最快的汽車品牌。 而且，大部分買家是異性戀。 他們鎖定的 Amy 是女同志，但更多的 David 和 Kevin 發現：「欸，這也是我要的！」 「便宜、安全、越野、不花俏」。 精準定位不是排除別人，而是讓對的人找到你。 ## Roast Myself 在理解 ICP 概念前，我其實也還在調整自己這個 "Unscript with Dave" 部落格的調性與走向。 上一版的 Profile 長這樣： ![](https://www.davehuang.io/content/images/2025/12/data-src-image-133e4dba-d62e-462e-83ee-806340247ae6.jpeg) 現在回頭看起來，是個非常 general，毫無目標的一個自我介紹。非常尬。 而在研究完 ICP 理論後，我稍微調整了一下 intro: ![](https://www.davehuang.io/content/images/2025/12/data-src-image-23440829-846a-4d36-a5cc-bd78f51e00cd.png) 我根據了我自己內心假定的 Amy 做了一次調整。看得出更限縮，但我覺得還有進步的空間。 改完的當下其實內心也會覺得有點擔心，這樣限縮後的結果會把許多既有的讀者與潛在讀者排除在外，但我覺得我仍舊得專注在最能受到我內容幫助的讀者身上。這才是我相對可控且能產出價值的範疇。 > 我不是要寫給所有人，我是要寫給那個最需要我的人。 希望這篇關於 ICP 的文章能夠幫助到你。 ## 本週紀錄 上禮拜完成了12週創作挑戰後，跟一起進行這個挑戰的[同學們](https://www.davehuang.io/start/)前往彰化進行了慶功宴。這過程就像是一種「兄弟會」的入幫儀式，我們因為這樣的自我挑戰，對彼此更加暸解，也因為我們共同經歷過這個磨練，更深知彼此都是「來真的」，激發出一種非常奇妙的情誼。I love it! 我們晚上在酒吧狂歡、深聊，交換彼此的夢想與故事。最後回到民宿還一起熬夜看了我最愛的電影 [Ocean's Eleven](https://www.imdb.com/title/tt0240772/?ref=davehuang.io) 弄到了3\~4點才昏昏睡去。 ![](https://www.davehuang.io/content/images/2025/12/IMG_0050.JPG) 隔天，我們前往了彰化的受天宮參拜。整個過程我與這個場域有著很深刻的連結感與安定感，是個很棒的文化之旅。彰化給我的 vibe 也是非常之棒。以後會在來這邊走走。 ![](https://www.davehuang.io/content/images/2025/12/IMG_0059.png) 很喜歡坐火車，自強3000最高 回到台北後，繼續了一整週的關注產出與工作。下午如果沒下雨時，我總會跑去公園坐一會，讀幾頁 Unscripted 系列的新作 [The Great Rat-Race Escape](https://www.amazon.com/Unscripted-Rat-Race-Business-Financial-Lifetime-ebook/dp/B093RMTVL6?ref=davehuang.io)。曬曬太陽後再散步回家繼續工作。 ![](https://www.davehuang.io/content/images/2025/12/IMG_0084.png) 這禮拜心情值也還不錯。 ![](https://www.davehuang.io/content/images/2025/12/-------2025-12-21-------3.37.26.png) Peak Pals weekly review 在 Peak Pals 上加我為好友，一起成長！🤝 🚀 [Add Dave on Peak Pals ](https://peakpals.io/profile/dave-huang?ref=davehuang.io) ### 過程驅動——看不見的蒙太奇 URL: https://www.davehuang.io/process/ Last updated: 2025-12-09T07:46:33.000Z 我很喜歡《[天菜大廚](https://zh.wikipedia.org/zh-tw/%E5%A4%A9%E8%8F%9C%E5%A4%A7%E5%BB%9A?ref=davehuang.io)》這部電影。它講述著一名主廚追求米其林星星的故事。 在這部電影中我最愛的一段，是由幾秒鐘所構成的[蒙太奇](https://zh.wikipedia.org/zh-tw/%E8%92%99%E5%A4%AA%E5%A5%87?ref=davehuang.io)註1： 清晨五點，走進廚房：喝咖啡，備料，嘗試新醬汁，下班； 又是五點，走進廚房：討論外場動線，歡笑，用餐，下班； 再是五點，走進廚房：備料，出餐，看心理醫生，下班； 這過程如同真空狀態，沒有對白，鏡頭隨著配樂，有節奏地快速推進。 直到米其林評分員來訪，團隊成員互相確認眼神，最後視角聚焦回主廚。 主廚：「我們就照平常做的。」 ... 時間快轉，來到天臺上的早晨，主廚與外場經理互視、微笑，他們知道自己已經到了自己想達到的高度。 --- 這就是「過程驅動」（Process）的真實樣貌：日復一日的重複，沒人在看，也沒有掌聲，直到某一天，你已經改變了。而你甚至沒有意識到改變發生在什麼時刻。 我們為什麼如此著迷於這類電影？天菜大廚、F1、Free Solo、國寶、Blue Giant、奧本海默——我深愛的這些作品，都在訴說同一種美：追求屬於自己的極致，那是一種圓滿。 而有趣的是，在這些主角們的時空中，背景的人群在乎的是最終的結果：米其林3星、世界冠軍、登頂難度最高的懸崖、人間國寶、原子彈發明。 這些都是「事件」（Event）。 事件是可見的。事件會登上新聞頭條。事件會被分享、被討論、被記住。 但過程？ 過程是隱形的，人們看不見。 然而，所有真實的改變都發生在看不見的地方。 註1: 蒙太奇（Montage）指的是一種電影剪輯技術與表現方式，透過快速切換的短鏡頭來展現時間的推移和過程的累積。 ## 過去的12週 過去的12週，我與 [創作課](https://www.davehuang.io/start/) 的同學們進行了一場連續12週的創作挑戰。規則很簡單：每週寫一篇「對得起自己」的文章。 在挑戰開始前一週，我們進行了一個叫「藍圖健檢」的儀式——寫下我們即將在這12週內要表達的想法。那時候的我充滿自信。我想：以我的閱讀量和思考深度，每週輸出一篇文章應該輕而易舉。 當我完成這12週、回頭看當初的自己時，我才明白，我當時活在「未知的未知」中。我以為我已經足夠了解創作，其實我什麼都不知道。 真正的改變來自於什麼？不是藍圖，而是**行動**。 每個星期，我坐下來寫作、修改、重寫。寫完後發布。讀者反饋，我又改進，下週重新開始。這個循環重複12次。在這12次的交付、連結、回饋的真實循環中，我才真正有所成長。 --- 同樣的故事也發生在 [Peak Pals](https://peakpals.io/?ref=davehuang.io)。 它的誕生早於這個創作課一個多月。過去4個多月的時間，我在一個看不見的空間裡——沒人知道我在做什麼，沒人在乎進度——不斷地編碼、測試、改進、再編碼。就像《天菜大廚》裡清晨五點的廚房。 直到我決定發布它。 從社群媒體的角度看，Peak Pals 的發布只是關注力洪流中的一個小水花。在無數的產品發布、內容分享、新聞更迭中，它不值一提。 但在電腦螢幕的彼端，有個人用上了它。 對他/她來說，這個工具解決了他們的問題。 通過這個我花4個月打磨的「創作」，我們產生了連結。彼此的生活可能因此變得更好。 **而這個對話，只有在交付之後才真正開啟。** ![](https://www.davehuang.io/content/images/2025/12/-------2025-12-07-------5.20.50.png) 無數凌晨，提交著一筆又一筆的 commits，想著「唉，又熬夜了」 --- 我寫的每一篇文章也是如此。有些文章寫完當下就覺得滿意，有些寫完立刻陷入自我懷疑——「這篇根本是垃圾」。 但奇妙的是： **有些我認為最爛的文章，反而在發布後獲得了最多的迴響。** 有些我自信滿滿的文章，卻無人問津。 這個發現改變了我對創作的理解。 我開始明白：**你對自己作品的評價，往往不等於他人的感知。** 在商業世界中，產品的定價永遠不是絕對的——顧客對它的「感知價值」才是真理。在創作世界也是如此。 就像美術館裡那些看似兒童塗鴉的抽象作品，它若能激發觀看者內心深處的某種共鳴，那一刻它就擁有了無法量化的價值。不是因為評論家說它好，而是因為它確實觸動了某個人。 這就是為什麼交付（ship）如此關鍵。 你無法在電腦前預測價值。你只能做出你認為最好的東西，然後放手。讓市場去判斷、去回應、去改變。 過程驅動的人，就是在這個循環中一次次成長。 ## 影響我很深的一篇文章 在過去12週中，有一篇文章改變了我的整個思考方式，那就是《[如何創作有影響力的內容](https://www.davehuang.io/spcl/)》。 故事要從更早說起。我曾經寫過一篇文章，只分享給創作課的同學看。寫的時候很順，寫完也很開心。但發布後我陷入了矛盾：這篇文章太過赤裸、太過個人。它幫得了任何人嗎？還是只是我的自言自語，最終只能淪為網路上的電子雜訊？ 我甚至在群裡問了同學們這個問題： ![](https://www.davehuang.io/content/images/2025/12/IMG_9995.png) **我矛盾的真正來源是什麼？** 我想寫純粹的個人抒發，但同時又想產生影響力。這兩件事能並存嗎？ 這個答案在我寫完《如何創作有影響力的內容》後出現了。 在那篇文章中，我學到了一個框架：**Status、Power、Credibility、Likeness**。簡單說： - **Status** \= 你掌握別人想要的東西 - **Power** \= 你的建議能帶來可驗證的好結果 - **Credibility** \= 你是誰比你說什麼更重要 - **Likeness** \= 人們相信和自己相似的人 而有趣的是，當我看向真正影響我的那些人——Alex Becker、Alex Hormozi、Charlie Morgan——我才明白他們早已把這個「套路」運用的爐火純青： Alex Becker 錄製影片時，後面停著一台藍寶傑尼。 Alex Hormozi 談論商業主題前，先說自己的書賣了幾千幾百萬。 Charlie Morgan 出場前都要先做一個 room tour，展示自己身處的豪宅。 以他們的能力和人格高度，其實不需要這些。但他們明白[**人類是感性驅動的**](https://www.davehuang.io/playground-2/)。當一個陌生人出現在你面前時，最快建立信任的方式就是「物質化的信號」。 - 跑車 = 他有錢（Status的證明） - 賣了X百萬 = 他的方法有效（Power的證明） - 豪宅房間 = 他過著成功的生活（Credibility的證明） 這不是虛偽，我承認我當時也是因為看到這些「表面」才有機會停留，而**我也確實有從他們身上獲得價值**。 但這裡有個更深的層次——**你無法假裝出這些東西，你必須真的成為那樣的人、過著那樣的生活。** 而成為，沒有捷徑。只能通過時間和過程。 我不需要假裝我已經成功，我可以真實地展示我正在創造屬於我自己定義中的成功的過程。 我不需要偽造我的 credibility，我只需要一步步建造它。 這就是為什麼過程驅動如此關鍵——它是唯一無法偽造的東西，那是我們身處 AI 時代的最後護城河。 認知到這一點，我反而獲得了解脫。 因為我知道：**時間是最公平的籌碼。每個人擁有的碼量都一樣。** 我和那些成功的創作者面對同樣的惰性、同樣的多巴胺成癮、同樣的雜訊干擾。唯一的區別是，我能否守住時間，進行專注且高品質的產出。 回到主廚說的那句話——「我們就照平常做的。」 這就是它的全部含義。 ## 結語 我還記得前幾個月，和好友 Darren 在一次飯局中聊天。 他問我關於創業的策略。我很真誠地說出了自己的想法：「如果用最簡化的角度看，創業其實就兩個要素：好的產品 + 被看見的方式。剩下就是無限循環迭代。」 我相信這句話。這是我對創業本質的真實認知。 但我也很清楚地知道：**我需要用實踐來證明它。** 當時的我沒有被市場驗證的產品，沒有用戶數據，沒有任何具體的案例可以拿出來佐證。所以那句話只是我腦中的理論，講出來很「虛」。 向他道別後，心中那股焦躁與冒牌者症候群感受再度襲來，騎著車衝回家，我一心想做的就是：多推幾個 commits、多修幾個 Bug。我急需透過實踐來匹配我的認知。 如果我沒有交付，講什麼都只是理論： - 我沒有 ship Peak Pals，「過程驅動」就只是一個想法 - 我沒有用戶數據，故事再動人也只是故事 - 我沒有踏出那一步，「物質化的信號」就不存在 --- 而這個過程中，我也更深入地理解了為什麼我選擇做軟體，更深入的理解了我的 [Why](https://youtu.be/u4ZoJKF%5FVuA?si=i3xAnfE0mI8a4RDl&ref=davehuang.io)。 在[這篇](https://www.davehuang.io/playground-3/)文章我寫道，自己畢業後第一份工作的面試，主管問：「為什麼想寫軟體？」 我回答：「因為這是最好掌控的介質。」 當時我的感受是，軟體就像樂高積木一樣，能讓我充分表達創意，不受限制。 但在完成 Peak Pals V1 的這一刻，我理解得更清楚了。軟體給了我完全的 **Ownership——**擁有權，也意味著絕對當責。 - 每個設計決策都是我的選擇 - 每個用戶體驗都是我創造的 - 產品的成敗，100% 由我承擔 這個「無法推卸責任」，也是另一種自由。因為當你無處可逃時，你被迫聚焦於最核心的問題：**這個東西是不是真的在解決問題？** 過程驅動不是高大上的理論，而是透過有意識的努力，用實踐去驗證你的認知。最終的事件結果，則是這個世界給你的真實反饋。 我也很期待屬於我的天臺時刻，在一個早晨微笑看著自己的成果，平靜且充實。 ## 本週紀錄 在上週寫完 [Peak Pals v1 發布心得](https://www.davehuang.io/peakpals/) 後的一週內，DAU 再度成長了 15人，來到了 25 DAU！ 這除了讓我感受到 SaaS 的 scalability 威力外，也帶來了興奮與戰戰競競的雙重感受。週六，花了一下午重新擬定了 Peak Pals V2 的 PRD，也藉著 SmartBear [這篇](https://longform.asmartbear.com/opposite-test/?ref=davehuang.io)的方法論，精煉出了更多更 solid 的 value propositions。我已經開始期待 2026年了。 上禮拜回家工作，陪父母，在前往高鐵前，衝去 A13 買了 Sony XM6，我其實好早就想買，因為我對噪音的耐受度很低。雖然我覬覦 XM6 的抗噪能力已久，但我給了自己一個制約——我必須用我自己創造的軟體收益來換得這個寶貝，於是我等到交付了前幾個月幫朋友訂製的客製化軟體案子，得到了這案子的報酬後，才買下了這款耳機。我戴著它，在嘉義公園的射日塔前，坐在石頭桌上開啟降噪模式，完全不受旁邊跳土風舞的老人們音樂影響，順利的產出很多 code。 ![](https://www.davehuang.io/content/images/2025/12/IMG_9983.png) 在嘉義的這幾天，每天都散步、曬太陽。吃飯、工作、睡覺，穩定的日常卻讓我很充實，Peak Pals 上紀錄的心情值也很高。 ![](https://www.davehuang.io/content/images/2025/12/-------2025-12-07-------6.18.13.png) Peak Pals weekly review 我還回台南看了外婆。很開心，抱抱她，聽她說話，看著她玩著寶可夢 Go，珍惜著這些當下。我們一起吃了鱔魚麵，她又夾了好多給我。知道我喜歡吃蘋果，她也特別幫我留了一盤在桌上。 --- 在 Peak Pals 上加我為好友，一起成長！🤝 🚀 [Add Dave on Peak Pals ](https://peakpals.io/profile/dave-huang?ref=davehuang.io) ### What I Learned from Launching Peak Pals V1 URL: https://www.davehuang.io/peakpals-en/ Last updated: 2026-07-24T15:23:23.000Z In February 2024, I came across the idea of a “Peak Performance Partner” while reading [*The Compound Effect*](https://www.amazon.com/dp/159315724X?lv=shuf&channelId=500&plpRedirect=mhFallback&ref=davehuang.io)by Darren Hardy. The setup is simple: meet with a partner for 30 minutes every week, talk through the past week’s wins, failures, struggles, and realizations, ask for feedback, and hold each other accountable. I immediately reached out to a friend who cared just as much about personal growth. He said yes, and that started a weekly ritual that lasted for more than a year. Every Monday at 9 p.m., our phones rang. We rarely missed a week. We treated the call like a mission briefing. Over that year, we went through a few small wins, a huge number of failures, countless problems, and many realizations that were hard to quantify. We grew in our careers, business thinking, and relationships. More importantly, we lived with more intention than we had in previous years. ## The Problem As we kept doing these calls, one problem became hard to ignore: > I needed a tool built around this exact workflow. Over the years, I had developed my own second-brain system: - Heptabase for yearly, monthly, macro planning - Trello for day-to-day task management - A Moleskine notebook for the ritual of writing and reflection - Notion for collecting loose thoughts and organizing files ![](https://www.davehuang.io/content/images/2026/07/image.png) Each tool worked well on its own. But every Monday before 9 p.m., preparing for the call became a mess. I would check Heptabase to review the week’s goals, search Trello for completed tasks, flip through my Moleskine for important realizations, and finally pull everything together in Notion. By the time the call started, I had already spent too much energy jumping between four tools. That defeated the whole point of having a second brain, which was to reduce cognitive load. The Peak Performance Partner system had helped me a lot. If one tool could make the process simpler, it might help other people who believed in the same idea too. I decided to scratch my own itch and build Peak Pals. ## **Designing Peak Pals** Before designing the product, I tried to understand why the partner system worked so well for us. I found two main reasons. First, it encouraged us to live each day with more intention. Writing a daily journal made me ask, “Did I move toward this week’s goal today?” If the answer was no, that was fine. The question still gave me a chance to pause and reflect. Second, it combined the carrot and the stick. Completing a weekly goal gave me a sense of progress and made me want to take on the next one. Knowing that another person would see whether I had followed through created social pressure. I did not want to show up every Monday with nothing to say. Once I understood those two parts, the first version of Peak Pals became clear. I wanted to keep the ritual of a notebook and the clarity of weekly goals, then add asynchronous accountability so people would not need to wait for a weekly call to support each other. After finishing the initial product requirements, I started building. Four months later, Peak Pals was online. I made plenty of mistakes during those months, but I also made a few decisions that worked well. ## **What I Did Well** ### **1\. Setting Up Production CI/CD Early** I chose Render for the infrastructure instead of managing my own VPS. It cost more each month, but it saved a huge amount of time. I did not need to spend my limited energy on DevOps and could focus on shipping the frontend and backend. As a solo developer, my time was better spent creating value for users than maintaining servers. ### **2\. Writing a Focused PRD and Small User Stories** I spent a lot of time turning the product requirements into clear GitHub issues. Each issue was small enough to finish in about 30 minutes. This had two effects I had not expected. Finishing an issue gave me a quick sense of progress, which helped build a positive feedback loop. It also kept the project moving on days when I was tired after work. Even if I did not have the energy for a large feature, I could still fix one bug or make one small improvement. A lot of the time, the problem is not a lack of willpower. The brain simply cannot see a clear path between the goal and its current position. Once I had planned the work and written down the details, I could move through the issues almost on autopilot. > Perfect is the enemy of good. ### **3\. Inviting Beta Users Early** This was probably the best decision I made during development. Seeing the product help real people felt better than anything else in the process. When a beta user found a UX problem or suggested an improvement, I wanted to fix it immediately. It was partly a sense of responsibility, but the stronger feeling was simply, “I want to help you.” Because I had full ownership of the product, that connection and sense of achievement motivated me more than any external reward. > Special thanks to my beta users: Eishin, Jeff, Samara, Circle, JC, and my mom. ### **4\. Working with a Designer** I invited a designer friend to join the project. Her second perspective was valuable. As an engineer, I tended to start with technical feasibility. She started with how the user would feel. By putting those perspectives together, we found a balance that let us ship quickly without giving up basic usability and visual quality. All four decisions helped me maintain momentum. The question behind each one was the same: what will make the product better and get it into users’ hands sooner? ## **What I Could Have Done Better** ### **Technical and Architectural Regrets** On the frontend, I did not plan the foundation carefully enough. My full-time work is mostly in large B2B codebases. When I switched back to building a consumer product, I overlooked many basic concerns: internationalization, notifications, mobile responsive design, dark mode, navigation, landing-page SEO, and loading skeletons. Some of these should have been in place from the beginning. Adding them later requires much more refactoring. They are early architectural decisions whose cost grows as the product gets larger. The backend was a different story. My full-stack experience is roughly 80 percent frontend and 20 percent backend, so Peak Pals was also a chance to practice. I still had a lot to learn about authentication flows, high-level abstractions, user model orchestration, and Redis caching. I would not call those decisions mistakes. I simply had not gone deep enough yet. Since Peak Pals was a side project, I treated that gap as an investment in learning instead of expecting a perfect implementation. ### **1\. I Did Not Design Mobile First** Peak Pals is a daily app. Most users write their journal entries on their phones, but I built the desktop version first and treated mobile as something to add later. I had assumed that reflection and deep work belonged on desktop. That assumption came from my own habits, not from user behavior. Most users still expect a mobile-first experience. Many problems in the flow only became visible when I used the app on an actual phone. If I started again, I would design mobile and desktop together, beginning with the mobile flow. It also would have forced me to think more clearly about which components should work across devices. ### **2\. I Ignored SEO** At the beginning, I thought of Peak Pals as a hobby project, so I did not take SEO seriously. That was a poor fit for the product. Peak Pals depends on people searching for ideas like peak performance partners, goal-tracking tools, accountability systems, and online journals. I should have chosen Next.js and built the foundation for programmatic SEO from the start instead of using a pure single-page application. That early decision now makes it much harder to acquire users through search. ### **3\. I Had No Business Model** This was my biggest mistake. I never planned to charge for Peak Pals. I even imagined keeping it free forever. My reasoning was simple: helping people already felt valuable, and I did not think the product was worth charging for. Later, I realized that giving the product away for free limited what I could build. I could not afford to spend much on LLM tokens, so I had no practical way to add the AI features I had imagined for helping users reflect. I also could not justify the development cost of advanced features for heavy users. The maintenance cost was only around $20 per month for four services and a domain. Even so, that ceiling shaped every decision. Revenue would have given me a reason and the resources to invest more deeply in the product. Charging is about more than making money. A sustainable business model lets a developer keep improving the product. By refusing to charge, I was also giving myself permission to keep Peak Pals at the hobby-project level. That may have reduced the value it could create for users in the long run. Architecture and business decisions both deserve attention early. I read Indie Hackers every week and still managed to make all the classic beginner mistakes. ## **What Comes Next** At the time of writing, Peak Pals has more than ten daily active users. That is a small number, but it still makes me happy. *(07/2026 updates: now DAU at 50+)* There are many product questions I have not solved: 1. Peak Pals is NOT a social network. I want it to record and encourage the authentic process instead of becoming another stage for displaying polished outcomes. 2. It should still be useful when someone uses it alone. The Pals feature should improve the experience, but it should not be required. 3. I want to preserve active human reflection while using automation and AI to reduce the effort. I have not found the right balance. 4. The hierarchy of year, week, and day feels clear. I am still unsure whether month belongs in the system. 5. The onboarding and retention experience both need more work. Working through these questions and bringing Peak Pals closer to the product I have in mind will be the next part of the journey. I recently saw a product called 750 Words featured on Indie Hackers. It is similar to Peak Pals in some ways, and after 17 years of iteration it has reached $26,000 in monthly recurring revenue. I deeply respect what its creators have built. It reminded me that even a small idea can build a good long-tail business if it finds the right people. It also exposed the other side of the problem. A good product is only the baseline. People have to discover it. The technical mistakes and architectural decisions I made can all be fixed. But if nobody knows Peak Pals exists, none of those fixes matter. My next step is not limited to improving the product. I also need to learn how to help the right people find it. That may be harder than optimizing the code. If the idea resonates with you, check out [Peak Pals](https://peakpals.io/?ref=davehuang.io) and let’s grow together. Add me on Peak Pals, let's make progress together! 🤝 🚀 [Add Dave on Peak Pals ](https://peakpals.io/profile/dave-huang?ref=davehuang.io) ## Notes from the Week The pace at my full-time job finally returned to something sustainable. The previous stretch of rushed development and constant disorder only improved after several difficult conversations with my teammates. There was a lot of frustration behind that change, but now I can focus on the work I am good at without being drained by small interruptions and office politics. That rhythm gives me a sense of achievement without exhausting me. On Friday, I finished my management work as quickly as I could and used my lunch break to visit MOA with my cousin. We handled a few new airsoft guns and caught up on each other’s lives. It also brought back memories of following him around as a kid while he played survival games with groups of grown men. Over the weekend, E and I watched *\*Kokuho\**, which was a 10 out of 10 for me. I strongly recommend seeing it without watching the trailer first. Before the film, we sat in a café for a while. I worked on the structure of this article and continued reading Sanmao’s *\*Stories of the Sahara\**. I once told a friend from a writing class that when I still have the patience to enjoy literature, it means my life is under control. My sense of beauty only seems to work when I am in that state. This week, I was. ![](https://www.davehuang.io/content/images/2026/07/image-1.png) ### Peak Pals V1 發佈心得 URL: https://www.davehuang.io/peakpals/ Last updated: 2026-03-19T04:37:32.000Z 2024年2月，我在閱讀《[複利效應](https://www.books.com.tw/products/0010814286?srsltid=AfmBOopnFjXaIwE1hcL-iyM8%5FoxikSexOQJQf3CefO6-d4oHFwObhy-H&ref=davehuang.io)》時讀到了「巔峰表現夥伴」這個概念——每週固定時間，和一位夥伴進行 30分鐘的深度對談，交流彼此在上一週當中所經歷的成功、失敗、困境、頓悟，徵詢必要的回饋，並且要求彼此當責。在看到這個概念的當下，我立刻找了一位同樣渴望自我提升的朋友，來一起執行這個計畫，而他也爽快的答應，從此開啟了我們長達一年的巔峰夥伴計畫。 每週一晚上9點，我們的電話會準時響起，從未間斷。我們都非常重視這個「作戰會議」，把它視為一種儀式。 這一年裡，我們經歷了一些微小的成功、巨量的失敗、數不完的困境，以及難以量化的頓悟時刻。正因為這些跌跌撞撞，我們在職涯、商業思維和人際關係上，也獲得了不少成長。更重要的是，我們活得比以往的每一年都「更有意識」。 ## 痛點浮現 在執行的過程中，一個問題越來越明顯：我需要一個工具來符合「巔峰夥伴」的流程。 長期工作下來，我發展出了一套自己的「第二大腦」系統，每個工具都被我用得淋漓盡致： - Heptabase 組織年、月、週的策略規劃 - Trello 管理日常任務執行 - Moleskine 手帳的儀式感最能驅動自我覺察 - Notion 靈活地堆疊零碎想法，組織檔案結構 ![](https://www.davehuang.io/content/images/2025/12/Untitled.webp) 但每當我要執行巔峰夥伴時，就是手忙腳亂的開始： 每週一晚上9點前，我得先從 Heptabase 回顧我當週的目標是什麼 ⮕ 再到 Trello 回溯完成了哪些任務 ⮕ 再從 Moleskine 手帳裡撈出這週的關鍵醒悟 ⮕ 最後在 Notion 組織零碎想法。 等到我們開始對談時，我早已在四個工具間消耗了心力。這完全違背了我建立第二大腦的初衷——降低心智負擔。 我認為巔峰夥伴真的是一個很好的機制，他著實幫助到我，如果這時有一個工具能夠把它的流程變得更加精簡流暢，那會大幅的幫助到我以及認同這個理念的人。（scratch my own itch） 於是，我決定做出 [Peak Pals](https://peakpals.io/?ref=davehuang.io) 來解決這個流程問題。 ## 設計構思 在設計 [Peak Pals](https://peakpals.io/?ref=davehuang.io) 時，我開始分析巔峰夥伴為什麼有效。 我認為有幾個關鍵要素： 1. 每一天要活得有意識：透過寫日誌，你進而去思考「我今天有沒有朝著這週的目標前進？」，即使沒有也沒關係，這會是一個沈澱的機會 2. 其次是「胡蘿蔔加棍子」組合拳：完成週目標時帶來的正向回饋，改寫多巴胺系統，強化想做好下一個任務的慾望；當有外部友人看著你有沒有好好做每週目標時，那份「被看著」的感覺帶來的社交壓力，會讓你不想丟臉，努力達成 到這一層思考後，Peak Pals 的雛形就很明確了：保留手帳的儀式感與週目標的明確感，加入非同步的當責系統，來讓這幾個核心要素全力運作。 設計明確、PRD開立完畢後，我立刻著手開發。歷經了四個多月，終於把它推上線，在這幾個月的開發中我踩了不少坑，也做對了幾件事。讓我逐一拆解，希望能幫你少走彎路。 ## 做得好的地方 ### 1 - 儘早建立 Production CI/CD 我很快就決定用 [Render](https://render.com/?ref=davehuang.io) 來處理 infrastructure，而不是自己折騰 VPS。這個決策看似伴隨著更高的月費成本，但省下來的時間成本是巨大的——我不用在 DevOps 上消耗心力，可以完全專注在前後端的交付。對於 solo developer 來說，每一分鐘都該用在「創造產品價值」上，而不是運維。 ### 2 - 精練的 PRD & User Stories 我花了不少時間把需求拆成清晰的 GitHub issues，每個 issue 都很小，小到可以在半小時內完成。 這帶來了兩個意想不到的效果：首先，每完成一個 issue，都有一種多巴胺爽感，正向迴圈很快就建立了。其次，即使某天工作很累沒力做大任務，我也會強迫自己至少完成一個 bug fix 或小改進，這樣每天都能提交 commit，保持開發節奏（momentum）。 很多時候我們不是沒有足夠的意志力，而是大腦看不到目標與當前所處位置的明確路徑。一旦規劃明確，開立出該做的任務細節與執行方式，就讓自己的身體進入自動導航，逐一完成目標。 > Perfect is the enemy of good ### 3 - 邀請早期 Beta Users 這可能是整個開發過程中所做出最對的決策。看著自己的產品實際的幫助到用戶，那種感受是無可比擬的。當 beta user 反饋出一個 UX 問題或提出改善建議時，我有一種強烈的動力想立刻幫他們解決。不只是出於責任感，而是真實的「我想幫你」的感覺。 因為我有著這個產品的 100% ownership，這當責的連結感與成就感比任何外部誘因都還強烈。 > Special shoutout to my beta users: Eishin, Jeff, Samara, Circle, JC & my mom. ### 4 - 與設計師協作 我找了一位設計師朋友參與這個專案。她的第二視角非常寶貴——我作為工程師習慣從「技術可行性」出發，而她會從「用戶感受」出發。這兩個視角的碰撞，讓我們找到了一個平衡點：既能快速上線，又不犧牲基本的美感和可用性。 --- 這四件事的共通點是：它們讓我在開發過程中保持了節奏感。每一個決策的背後，都是在問「什麼會讓這個產品變得更好、更快交付到用戶手中」。 ## 沒做好的部分 ### 架構與技術細節的遺憾 #### 前端 我沒有從一開始就完整規劃基礎架構。由於正職大多在大型 B2B code base 打轉，回頭做 2C 的產品反而漏思考了很多細節。 i18n（多語言）、notification system、mobile RWD、dark mode、navigation system、landing page SEO、loading skeleton——這些東西後來補都會很痛苦，應該一開始就建立。我只做了其中一部分，現在回過頭想加，都得重構。這是典型的「early decision」問題，越往後補，技術債越高。 #### 後端 我是 FE:BE = 80:20 的 fullstack，這次開發是練手後端的好機會。所以我在 auth flow、high-level abstraction、user base model orchestration、Redis caching 上都還有很多學習空間。坦白說，這不是「做錯」，而是「做得不夠深」。但既然是 side project，我決定把它當成學習投資而非完美交付。 ### 更深層的三個決策失誤 #### 1 - 沒有 Mobile-First 的設計思路 Peak Pals 本質上是一個日常應用，用戶大部分時間在手機上記錄日誌。但我是先做 desktop 版，後來才開始往 mobile 補足。因為個人認為 deep-work 的使用情境應該是 desktop first，但這種想法太主觀了。 事實上，主流用戶仍舊習慣 mobile first。許多 user flow 的問題只有在真實用手機操作時才會浮現。重來的話，我應該從一開始就 mobile first，同步進行 desktop 和 mobile 開發，這樣才能及早發現流程上的問題。 Cross device component reusability 也會拆的更明確。 #### 2 - 完全忽視 SEO 我一開始的心態是「這是個 hobby project」，所以沒把 SEO 當一回事。但現在回想，Peak Pals 本身就高度仰賴搜尋——「巔峰夥伴」、「目標管理工具」、「當責系統」、「線上手帳」這些搜尋關鍵詞。 我當時應該直接選 Next.js 並建立 programmatic SEO 的基礎架構，而不是用純 SPA。這個決策的代價是，我現在很難透過搜尋引擎獲得新用戶。 #### 3 - 沒有任何商業模式 這是最大的失誤。我完全沒想過收費，甚至想讓它永遠免費。理由很簡單——我覺得它能幫助到人，這份價值感就夠了，我不認為它值得收費。 但事後我才明白，**不收費其實限制了我能做什麼**。首先，我燒不起 LLM token，所以沒有辦法加入 AI 相關功能（我原本想用 AI 來幫助用戶更好地反思）。 其次，我無法為重度用戶開發進階功能——一旦我有營收壓力，就能合理地為核心用戶投注更多技術成本。現在我被「維運成本」（大概是 600 元/月，四隻 services + 網域）給 cap 住了。回頭看，**收費不只是為了賺錢**，而是為了給自己「更好地投資這個產品」的正當理由。沒有收費看似超然，實則是給自己一個理由把它停留在 Hobby Project 的層級，最終為市場帶來的正和反而不是最高的。 --- 架構決策、商業決策，都該儘早思考。就連我這個每週都勤奮看 [Indie Hacker](http://indiehackers.com/?ref=davehuang.io) 文章的人，該犯的 noobie mistakes 一個也沒少犯！ ## 結語 我會持續在 [Peak Pals](https://peakpals.io/?ref=davehuang.io) 上投入開發，希望能為現在和未來的用戶打造更棒的使用體驗。在寫下這篇文章的時間點，Peak Pals 有著 10+ 的日活躍用戶！！不多，但我仍感到開心。 坦白說，Peak Pals 在產品層面還有很多未解的問題： 1. 它終究不是社交媒體——我想要的是記錄並且鼓勵「過程驅動」的工具，而不是展示「美好結果」的舞台。（process driven > event driven） 2. 它應該能 standalone 獨自使用也很有效益，夥伴（Pals）功能只是加分，不是必需。 3. 我既想保留人的主動反思，又想引入自動化和 AI-in-the-loop 來減輕負擔，但這兩者的平衡點在哪裡，我現在還沒找到。 4. 焦點設計——Year > Week > Day 的層級很清楚，但 Month 到底該不該有，我還在猶豫。 5. 最終就是更好的 onboarding 體驗，與 retention。 解決這些問題並且把 Peak Pals 推到我心中該有的完整度，會是接下來的旅程。 --- 我最近看到 [750words](https://750words.com/?ref=davehuang.io) 這款跟 Peak Pals 很像的軟體登上了 Indie Hackers 的版面，它透過 17年的迭代，達到了 $26k MRR的成績，我深感敬佩。它給了我一個啟示：再小的 idea，只要找到對的人，就能在長尾效應下活得很好（[小而美](https://www.books.com.tw/products/0010825335?srsltid=AfmBOopFJZew494P5DavRwQ9ARbk22TlD%5FtV213%5Fg9ouETMeV5oVuerT&ref=davehuang.io)）。 但這也揭露了另一面——產品做得「夠好」只是基礎。真正的挑戰是：你得先被「看到」。我在技術上踩的坑、架構上做的決策，都有辦法補救，但如果沒有人知道 Peak Pals 的存在，一切都是白搭。我的下一步不只是把產品做得更好，而是思考該怎麼讓對的人看見它，這遠比優化代碼更重要。 在 Peak Pals 上加我為好友，一起成長！🤝 🚀 [Add Dave on Peak Pals ](https://peakpals.io/profile/dave-huang?ref=davehuang.io) ## 本週紀錄 正職的工作節奏終於回歸平衡。前陣子的隕石開發與混亂節奏，在我與夥伴的激烈溝通中硬生生開拓出了一條路，這中間的血與淚真的難用三言兩語道盡。現在能高效輸出專業能力，不被瑣碎和辦公室政治消耗，這種節奏讓我很有成就感、不耗能。 週五趕緊把管理的工作忙完，趁著午休的空擋，跑去和表哥逛我們最愛的 [MOA](https://moaexpo.info/?ref=davehuang.io)，摸了幾把新槍，阿嘶...逛展的過程，除了與表哥更新彼此近況，也一起重溫小時候，他帶著我在各大槍隊，跟著一群大漢玩生存遊戲的美好時光。 ![](https://www.davehuang.io/content/images/2025/11/IMG_9880.png) 週末，挑了一天與小e去看《國寶》這部神作（分數：10/10，強烈建議不看預告片直接前往）。在等候國寶開演前，我們找了間咖啡廳坐下來放空，我除了構思這篇文章的架構外，也接續著看三毛的《快樂鬧學去》。我曾跟[創作課](https://www.davehuang.io/start/)認識的朋友說，當我還有閒情逸致去欣賞純文學作品時，代表生活還在可控狀態，唯有在這樣的狀態下，我的美感受器才能正常運作。這一週，算是這樣的狀態。 ![](https://www.davehuang.io/content/images/2025/11/IMG_9915.png) ### 友誼與生活結構 URL: https://www.davehuang.io/friendship/ Last updated: 2025-11-25T16:39:23.000Z 當我第一次聽到亞里斯多德的「友誼三層次」理論時，我有種突然被「命名」的驚喜感。原來我從學生時期就一直在追求的東西——那份對深層人際連結的渴望，早就有人用精確的語言定義過了。功利友誼（Utility）、快樂友誼（Pleasure）和美德友誼（Virtue），這三個概念一下子將我心中模糊的想法變得清晰。([Ref](https://wfhstudy.blogspot.com/2012/07/3%5F15.html?ref=davehuang.io)) 讀著亞里斯多德的論述，我發現自己從有意識地交友開始，就持續追求著「美德友誼」的層次。我嚮往的友誼，是能夠彼此推動著一起變好，同時也能無目的性地共同享受那些簡單而純粹的快樂時光。「快樂友誼」對我來說不夠深刻，「功利友誼」更是令我鄙夷。 但正因為我對美德友誼的追求與嚮往，在思考這篇文章的過程中，我反而更用力的檢視這個想法本身。 在他的觀點中，這三種友誼存在著某種階級性，彷彿美德友誼是終極目標，而其他兩種是低階的過渡。但在我的人生經驗中，這三種友誼與其說是階層排序，更像是隨著生命處境動態交錯、各自展開可能性的進程。有時候，能夠維持一段灑脫的快樂友誼，或是相互尊重的功利關係，已經是當下的生活結構中，一個人能給出的最好人際關係連結了。 ## 陌生的邊界 最近參加的一場讀書會，剛好就在探究人際互動與友誼的本質。在分組討論環節，我帶著一個一直在思考的問題想要與組員討論：當一個朋友在行為或人生決策上有明顯的優化空間時，到底該不該直接跟對方提出自己的觀點？ 這個問題說實在，是觸及個人價值核心的大哉問——關乎信任、關乎坦承，也關乎如何看待彼此的成長。在讀書會當下的場合與情境（context），我找不到時機點與大家討論這個議題，我也知道，若我直接拋出這樣的提問，會相當唐突。 不是問題本身不好，而是因為它需要一種我們還沒有建立起來的信任基礎與互動軌跡。我們彼此還是陌生的，即使交換了名字、簡單聊過背景，但仍只是表象。我們需要經歷足夠的互動與觀察，才能真正理解眼前這個人的本質：他的邏輯、他的價值觀、他面對困境時的選擇。（用 AI 來類比，就是 training data 遠遠不夠。） 要能夠坦誠地探討「我該怎樣批判性地看待你」這類問題，必須先經歷足夠的共同時光、相互理解——小至一個人的用詞習慣與表述偏好，大至他個性中的禁忌與地雷，以及這個人的生命經歷與背景。在這個初次見面的場景裡，這些條件都還不存在。所以我也就沒提出來討論。 > 有趣的是，當我們問 AI 問題時，卻不需要這些「鋪墊」。我們對 AI 的答覆有很高的基礎信任閾值。人類這種生物真的非常奇妙。 ## 生活的結構 相較於上述的這個讀書會，大家都還不認識的場合，在我生活中有另一個群體也經常激發我對於友誼的省思。他們是我在前幾年，因投資與交易的興趣，機緣下認識的一群同齡的優秀友人。他們都是非常有智慧的人，每當我們聚在一起討論投資邏輯、分享市場洞察，我都能從他們身上學到很多。有著這個共同「目標」與「語言」，我們之間的互動非常聚焦，形成了很扎實的節奏。 與這群好友相處的過程中，除了學到很多對於資本世界的的認知，我也觀察到另一個層面：我們的生活結構是截然不同的。在資本量級的進程中，他們遠遠走在我的前頭。他們的一天中，絕大多數的時間是直接與資本打交道，構思著交易策略，在越來越高的資訊鏈中向上探詢。也正因爲用資本賺錢與用時間賺錢的本質差異，我更確信：若要與這群我所欣賞的人有真正的深層連結，我也需要爭取同樣的時間掌控度與生活餘裕。 我深刻認知到，人與人的互動，在昇華成美德友誼前，勢必要有足夠的時間相處、玩樂、討論、互動。這背後不是簡單的「生活在一塊」，而是人與人之間的連結，往往仰賴**關鍵事件**的堆疊——正是在這些堆疊間，我們才能看見彼此真實的樣貌與品德。 有餘裕，就能閱讀更多的書籍、累積智慧；有時間掌握度，就能累積更多的生命經驗來淬煉人格。 改變生活結構、爭取時間自由，不只是為了經濟獨立，更是為了有能力培養與維持真正的美德友誼。 ## 我所欣賞的樣子 回過頭來，除了上面探究的這些環境與時間的條件，我也發現自己在友誼中也有著一些清晰的偏好。 第一，是**成長思維**。我嚮往的朋友，是那些會持續往前的人，在這個世界中有著自己的追求與熱情。面對磨難與考驗，他們不會停滯，也不會受到外部世界的雜音而感到迷茫。正因為彼此都在各自的軌道上奮力前進，更能珍惜每次相處的當下，相互推進與啟發。 第二，是**豐盛心態**。我相信一個人的內心如果有著豐盛（abundance），也就代表著強大的內核——這樣的人更能獨立思考，也更能純粹的連結。豐盛的人不會被社交焦慮綁架，不會陷入無謂的比較，也不會被嫉妒給蠶食。他們有著足夠的覺察與智慧，能看清人類天性的弱點與醜陋，懂得優雅地繞過自己的爬蟲腦 。這樣的人能給出更真誠的反饋，也能接受坦誠的批評。他們懂得欣賞他人的成就，也能為朋友的成長感到由衷的喜悅。 上述這兩點，不只是我在他人身上所欣賞的人格特質，也是我對自己的期許。 最後一點則是**幽默的頻段**。我喜歡政治不正確的黑色幽默，也喜歡不受常規限制的思考與對既有框架的挑戰。說實在這個「度」有點難拿捏，但我覺得這才是有趣之處。 ## 結語 最後，回到我在讀書會上沒有提出來的那個問題：「當一個朋友在行為或人生決策上有明顯的優化空間時，到底該不該直接跟對方提出自己的觀點？」 我目前的答案是：會說。 因為我也希望我的朋友這樣子對我。非常地單純。 但我也意識到，正因為我補足了上面這些對友誼美德的嚮往與體悟——成長思維、豐盛心態、適當的時間與信任基礎——這樣的坦誠在我身上才能成立。換到另一個人身上，同樣的行為可能反而會傷害友誼，甚至導致破裂。 （人類很需要 context，而 context 的補足需要時間。） 所以，這個問題沒有絕對的答案，只有基於你是誰、你想成為誰、以及你與對方之間有著什麼樣的基礎。 我很好奇你的想法。如果你也曾思考過這個問題，歡迎在留言區分享你的觀點，或者私下與我討論！ ### 後記 📅 11/25: 根據朋友給的 Feedback，補充一些想法 #### 1 - 為何選用「生活結構」而非 「生活型態」？ 因為在我的感知，一個人一天的組成，透過 時間 跟 注意力 進行權重分配的過程更像是一種「結構」，如同積木一般能夠抽換、重塑。 而生活「型態」有著更多的有機成分以及外部影響，是逐步生成的，不全然可控。 前者像在蓋房子，後者像在這棟自己蓋好的房子內生活時的整體樣貌。 微觀 vs 宏觀。 #### 2 - 關鍵事件堆疊的兩面性 人與人之間，透過眾多的正向連結，才能堆砌出良善的互動；但這個辛苦建立的連結，往往只需要少少幾次負面事件（大多只需要一次），就足以造成斷裂、崩塌！ ## 本週紀錄 第一點值得紀錄的是，我終於回歸自己泡咖啡的日子，感動！ ![](https://www.davehuang.io/content/images/2025/11/IMG_9811.PNG) CHLIV fat ass crema 這禮拜，我在金馬影展看完了這一輪的最後一部電影《銀翼殺手最終版 (1982) 》，也是我這一輪下來最滿意的一部。我在 IMDb 給了 9/10。 也因為看了這部電影，我獲得了一個極大的幸運爆擊——抽中了與小島秀夫的合影機會！！！殊不知，他因確診了A型流感，臨時取消了見面會。我既覺得可惜，又覺得鬆一口氣，因為我一直沒把《死亡擱淺》玩完，我覺得我沒臉見他... 自從開始寫作、有意識的做獨立開發題材後，我就一直無法進入遊戲的世界，也無法透過玩遊戲感到快樂。這對我來說蠻痛苦的。現在看著我媽玩著 Pokémon GO 玩得那麼開心——入迷到走路都無法專心、家族旅遊整路在抓寶到被我唸、還玩到乾眼症！我是覺得既可愛，又羨慕，能夠有一款投入的遊戲，是很棒的體驗啊！ 小島秀夫承諾會再找機會來台灣，我期許自己在那之前，能再多玩一下死亡擱淺這部我很愛的作品。 除了銀翼殺手以外，我也被推薦去看了《鏈鋸人 - 蕾潔篇》，無懸念地給了 10/10。出場後，片尾曲在腦內循環播放，搭配殘留的畫面與感受，久久無法自己。激推！我應該會二刷。我愛畢姆 🦈，我想跟他當朋友。但我覺得我的個性會讓我在鏈鋸人的世界觀中，活成像阿秋這樣的存在。 ### Peak Pals URL: https://www.davehuang.io/peak-pals-en/ Last updated: 2026-07-24T15:19:52.000Z Peak Pals is your personal growth companion, combining the power of daily journaling with accountability partners. It’s a digital journal that helps you make real progress toward your goals—with friends cheering you on along the way. Focus your goals from the big picture down to daily action: Annual Goals → Weekly Goals → Daily Journaling The key is taking small, consistent steps every day. ## **Core Features** - Daily Journaling - Weekly Goals - Weekly Reviews - Accountability Partners ## **Links** [Peak Pals](https://peakpals.io/?ref=davehuang.io) Add me on Peak Pals, let's make progress together!🤝 🚀 [Add Dave on Peak Pals ](https://peakpals.io/profile/dave-huang?ref=davehuang.io) ### Daily Sec URL: https://www.davehuang.io/daily-sec-en/ Last updated: 2026-07-24T15:18:17.000Z This playlist is a record of my life and personal aesthetic. Every time I create a Daily Sec, it reminds me to stay present and appreciate the people and scenery around me. > 今度は今度、今は今。 ### Daily Sec URL: https://www.davehuang.io/daily-sec/ Last updated: 2025-11-17T18:03:17.000Z 這個播放清單是我的生活紀錄與美學。 每當製作 [Daily Sec](https://www.youtube.com/watch?v=8SrnQ2Jc5lw&list=PLgD9zvYEMjLHddQP2dlcDQHEnUMYfnm37&index=11&ref=davehuang.io) 時，都提醒著我要活在當下，珍惜身邊的人與風景。 > 今度は今度、今は今。 ### Peak Pals URL: https://www.davehuang.io/peak-pals/ Last updated: 2026-07-24T15:19:02.000Z [Peak Pals](https://peakpals.io/?ref=davehuang.io) 是您的個人成長夥伴，結合「每日日誌」與「當責夥伴」的力量。他是真正能幫助您達成目標的數位日記，一路上有朋友為您加油打氣。 從宏觀到微觀聚焦目標：年度目標 → 週目標 → 日誌。 重點在於每日小而持續的執行！ ## 核心功能 - 日誌 - 週目標 - 每週回顧 - 當責夥伴 ## 連結 [Peak Pals](https://peakpals.io/?ref=davehuang.io) 在 Peak Pals 上加我為好友，一起成長！🤝 🚀 [Add Dave on Peak Pals ](https://peakpals.io/profile/dave-huang?ref=davehuang.io) ### Final Sanctuary - 告別類比聖堂 URL: https://www.davehuang.io/sanctuary/ Last updated: 2025-11-18T13:05:09.000Z 這禮拜發生一件我極度難過的事情——我家旁邊的漫畫店要收店了。 一聽到這個消息，我馬上抄起我的相機衝過來，幫老闆娘拍下一些紀念的照片。 按下快門的那刻，我才真正意識到，這個地方要從我的日常地圖上消失了。 ![](https://www.davehuang.io/content/images/2025/11/R0001021-1.JPG) ![](https://www.davehuang.io/content/images/2025/11/R0001018.JPG) ![](https://www.davehuang.io/content/images/2025/11/R0001025.JPG) ## 與這間店的緣分 「怎麼不早點來？幫你留那幾套漫畫呀～」 老闆娘一邊說，一邊在那堆準備低價拋售的漫畫堆中，試著找出我以前常看的那幾套漫畫。就連在收店前，老闆娘還是那麼暖，我感到更加更加的不捨。 回想起來，第一次走進這間漫畫店，已經是五年前。那時剛搬來這一帶，還在探勘附近的機能，無意間看到這間店的當下，我就知道我一定會成為這裡的常客。 店裡擺滿了一堆 Old School 老派漫畫。我抽出了1000元準備加值，老闆娘馬上阻止我：「你先存 200 就好了啦，我們這間店很老了，我怕沒有你們年輕人愛看的東西捏，這樣浪費啦～」 那刻起，這間店在我心中的地位就完整樹立了，但我在那當下還沒有確切詞彙來形容這樣的感覺。 直到現在我才意識到，那一直是我生活中的某種「聖堂」(Sanctuary)。 我從來沒有看過這間店有30歲以下的客人，全部都是50、60歲的老客戶熟面孔，埋首在一些上古小說裡。 這間店的人員配置就只有兩個人——早上是老闆娘，晚上則是一個專業級別的宅男老哥。白天要是遇到老闆娘，我們會聊生活、她會關心我的近況。晚上來遇到老哥，就聊一些二次元的事情，每當我不知道要看啥時，問他準沒錯。 共通點是，他們都看得出我忙，每次來借書時，他們都會偷偷地幫我延長還書期，我其實也都默默惦記著這份人情。 來到這間店的時機點，不外乎是兩種情境：一種是我快被生活節奏壓垮，極需要一些精神上的慰藉與逃避。一種是生活回到了可控的餘裕範圍，我想要悠哉的看點漫畫，對生命的熵值宣示主權。而在中間值波動的大部分時光，反而很少來到這裡。 ## 在這間店追完的幾個作品 在這間店，我遇見了許多以往絕不會拿起的作品。 在當代眾多娛樂選項的競爭中，它們本是豪無立足之地。但走進這個場域，看到這些作品的當下，卻像是某種靈魂綁定——看到的瞬間就覺得非得要追完不可。 ### 聖堂教父 第一套在這間店完追的就是池上遼一的《聖堂教父》。 剛看到這套時，國際氛圍仍極度講求 DEI，這反而讓我更加渴望看見這種 OG 硬派風格、呈現真實人性的作品。這漫畫也完美呈現了父執輩年代的「男子氣概」展現，那種男人間真正的兄弟美意與情懷。 一群兄弟，為了自己理想的聖堂，明知近乎不可能，卻抱持天真向前衝刺拼搏。各種中二台詞與黑社會的狠勁混在一起，毫無懸念成為我人生前三排序的作品。 ### 島耕作系列 另一個我非常愛的作品。從系長一路看著他當上取締役、特別篇回去當學生經歷學運、再一路衝到社長王座。 陪著阿島經歷職場鬥爭、感情波折、內心起伏。在追番的過程，我自己的現實生活也湊巧被捲入職場政治，格外的有帶入感。在低潮時刻，看著阿島的鬆弛感、孤狼性格，都讓我格外欣賞，也藉此在心態上有了很多昇華。他的心態總是澄清自由的。 還記得剛開始從系長篇入坑時，宅男老哥在幫我刷條碼時念念有詞「你這年紀...看這個...可能還不會帶感喔！まだまだ！」這句話跟他的表情我到現在還記得。 ### 頭文字D 一看到就讓我整個ㄉㄧㄠˊ住的作品。用既想看完又不捨看完的複雜心情衝完整套。 我極度喜歡涼介與啟介的關係——那就是「兄長」該有的模樣典範，以及「弟弟」該有的積極與景仰。 更打動我的是文太這位父親的 archetype。父與子透過 DNA 延續，追求著同樣的靈魂渴求。有內心 ego 面的競爭，也有生物性的父愛本質。他知道一些錯就是該犯不該剝奪，也知道如何適時傳遞智慧，加速晚輩的人生進程。 這部作品的男性浪漫爆棚，到讓我特地去買了張 SEGA 頭文字D卡片在那邊跑山練車。也因為這部，我開始研究日本復古喫茶店的文化。每次看到漫畫裡他們在復古喫茶店討論事情，都有種時光凝結的感覺。 ## 聖堂與多巴胺 對我來說，這間實體的漫畫店，是類比時代的集體懷舊。他不只是商業空間，而是某種消逝文明的最後堡壘——如同熱愛底片與拍立得的人眼中，在有限資源下更懂得珍惜當下的那種美。 走進店內，多巴胺吸收旅程就已開始：紙本的氣味，參雜著霉味與菸味。推動老舊書架找書時的力道與手感。拿下一本本書去刷條碼時的重量。結帳時短暫卻帶有溫度的人與人連結。 一切進程，沒有演算法的介入。純粹透過擺設與緣分找到下一部作品。看完一本，就結束這一回合的多巴胺攝取，還有幾本沒看完、下次要再去借的期待感。付出一個小小的金錢支撐這間店營運，還書的時間壓力提醒我要珍惜。 這些都是純淨的多巴胺。有重量、有溫度、有靈魂。 相較著數位時代的廉價多巴胺——即時、離散、冰冷、虛擬、複製、非人造。 我希望老闆娘跟老哥未來順利。我很謝謝他們帶給我的快樂與回憶。更謝謝老闆娘為了這些老客人，在收支打平線上撐了那麼久，卻遲遲不忍心收店的那份溫柔。 這間店是我曾經的 Sanctuary，現在，我只能在記憶裡守護它。 > 或許這間店的消失，正是在提醒我—— 在所有人都在追求「規模化」、「演算法最佳化」、「自動化」的時代， 真正稀缺的反而是那些「不可量化」的東西。 如果我想在獨立創業的路上走得更遠， 我該學會建造屬於自己的 Sanctuary—— 一個不被演算法綁架、不被廉價多巴胺淹沒的創作空間。 ## 本週紀錄 這禮拜是像屎一般的一週。 與 E 去看金馬影展，與內湖英文團好友聚餐，我是開心的。但我對自己不滿意。 漫畫店收起來我已經很難承受了，工作上、創業 project 進度、客製化接案上的種種層面，都不如預期。被惰性與外務束縛，我知道我可以做得更好。 但我仍然很開心終於把 [Peak Pals](https://peakpals.io/?ref=davehuang.io) 推上線。我知道它基本上不可能盈利，但對我來說它也是我的 Sanctuary，在設計這套軟體的過程，我投入了很多自己的構思與看不見的系統設計層面，這是我從 0 打造的作品，它也在我的日常中幫助著我向前推進，所以是個不能不上線的信標。 ![](https://www.davehuang.io/content/images/2025/11/IMG_9751.png) 雨天，在 Starbucks 寫著腳本，很急躁 如果看到這邊，你們也想跟我一起向前進，看到我日常的 struggle & grind，也歡迎在 Peak Pals 上加我成為好友: [https://peakpals.io/profile/dave-huang](https://peakpals.io/profile/dave-huang?ref=davehuang.io) ### 生產力與旅行 URL: https://www.davehuang.io/travel/ Last updated: 2025-11-17T17:09:28.000Z 最近在一場社交聚會上，主辦人問大家「如果接下來去旅行，你們想去哪裡？」來賓們興高采烈地報出一個個目的地和理由，而輪到我時，我的回答打破了現場輕鬆的氛圍：「比起旅遊地點的選擇，我更重視能在旅行的過程維持生產力。」 我接著說：「我希望既能體驗異國風情，也能在遊歷間隙中，隨時進入一種有產出的狀態。」那一刻，不少人內心大概是翻了個白眼，覺得這傢伙在搞什麼工作狂呀。 我知道主持人想藉由這種比較輕鬆的娛樂話題來破冰，但剛好這個議題觸及了我嚮往的一種生活方式，心中的投射「蹦」的一聲，就急著把想達到的理想說了出口。 若要補足當下沒能表述完整的思維，是我對「旅行」與「度假」的定義做了劃分。這兩種定義分別在我的學生時期和第一份工作中逐漸成形，而那些經歷讓我對生產力與旅行的關係有了全新的理解。 學生時期，我很幸運地透過交換學生計畫在瑞典待了一年。那段日子裡，我幾乎把課業擱在一旁，用有限的生活費盡可能地在歐洲旅遊。只需比坐高鐵多一點的錢，就能到達不同的國家，每次都倍加珍惜這樣的機會（因為想著回台灣後就能難再來了）。我總是選擇最便宜的青年旅舍，和十來個陌生人擠在一個通舖裡。每次旅程都超過十天，前半段充滿新鮮感和探險的刺激，但當我看完核心景點後，剩下的日子往往變得漫無目的、令人感到孤獨空虛。直到有一次，我帶著電腦在陌生城市找了間咖啡館坐下，一邊寫部落格一邊思考未來，那種既在旅行中又在創造的感受讓我頓時充實起來。我發現，這種在新奇環境中進行有產值工作的狀態，正是我一直在尋找的，內心也默默期望，未來能把這種狀態活成一種日常。 而出社會後的第一份工作，給了我另一個實踐這個想法的機會。因為部門同事都排斥出差，我英文能力也還不錯，也就獲得了多次去美國出差的機會。作為新人，我急著在部門內證明自己，每次都全力投入、為出差做足準備。我跟前輩通常在前幾天內就能完成工作任務（通常是他 carry 技術層面，我負責當溝通橋樑），然後向HR申請延後個幾天回台灣，藉此在當地遊歷。多出的那幾天中，我最享受的是逛美術館、看建築、像當地人一樣在公園散步，最後坐在某間咖啡館裡，一邊複盤出差的學習成果，一邊記錄這座城市帶給我的感受。工作與旅行的比例恰到好處——因為前面有充分的付出，後面的遊歷時光就能心安理得地享受。 也是在第一份工作期間，我遇到了兩個對生活型態的關鍵啟蒙，讓我開始認真思考如何將生產力融入旅遊，進而把這種不受束縛的生活模式變成日常的可能。 第一個契機來自技術主管的一句話。當部門導入 GitLab 時，他對我說：「你知道嗎，開發這套工具的公司是完全遠端的，所有員工都不需要進辦公室。」那是一個還沒有 Covid、Zoom 連聽都沒聽過的年代，這句話對剛出社會的我如同一道光，彷彿打開了一種從未想像過的生活可能。從那刻起，全遠端工作成為我在選擇後續工作時的核心考量。 第二個契機是閱讀《[一週工作四小時](https://www.books.com.tw/products/0010621037?srsltid=AfmBOooXZdNwasJqYciw3CSAj4A0ksqwZMD4K0HzwLarA%5FBApI98jjnd&ref=davehuang.io)》這本書。作者透過這個概念讓我領悟到，只要打造出完善的商業系統，就能在極少的時間內產出關鍵成果，讓事業持續運轉，同時不受地理位置的束縛。這個想法與我對旅行的憧憬完美契合，更堅定了我追求這種生活模式的決心。 今天在看到 Chris Gimmer 的 [部落格文章](https://chrisgimmer.com/backstory/?ref=davehuang.io) 時，意外地彷彿看到了當年的自己。作者在東南亞旅行後領悟到「我想看更多的世界，但每年幾週的假期根本不夠」，他用了 "transformative experiences" 來形容這樣的震撼，那正是我當時出差時的感受。 他也坦誠的提到，對於當時工作中那種空虛——「毫無意義，只是為了領薪水，用可預測的行動模式過著日復一日」。雖然我對自己現在的工作還是保有熱情，但我很清楚他指的是哪些工作中令人窒息的部分。我們追求的其實是同一種自由——不是為了逃避工作，而是為了在旅行中保有生產力，在工作中保有移動的可能。 當然，我也同意他所說的 “this is super cliché”。尤其在這幾年，自媒體上那些 Fake Guru 們鼓吹著「數位遊牧」，都讓我感到尷尬。他們透過精心剪輯的旅遊照片和輕鬆的敘事，把這種生活方式包裝成彷彿不用付出什麼努力就能享受自由的假象。但事實上，這需要非常有意識的系統打造、一連串正確的決策，以及持續的執行力。我尷尬的不是這種生活本身，而是這種虛假的輕鬆被當作賣夢的口號，卻完全隱去了背後真實的代價與付出。 寫下這篇文章，是一種自我提醒，提醒著我當時為何走上這條路，提醒著自己追求的東西是隨著生命體驗而演化出的有意義延續，而非虛幻的夢想。我正在朝著目標前進。同時也是自我勉勵，raise the bar，對比 Chris Gimmer 的決斷與執行力，我深刻意識到自己最欠缺的不是計劃，而是行動。過度的計劃與拖延只是慣性的保護機制，我需要的是更強大、更專注的執行、執行、執行。 ## 本週紀錄 這禮拜剛與家人從北海道回來，透過這次的「度假」，把出國前接近 burnout 的心態做了個重整，也調適好自己過去幾週的熬夜 bad cycle。在台灣自己製造出的時差，竟然還得在異地才調得回來。這禮拜回來後，努力的重拾工作動能，也自認執行得相當不錯！ ![](https://www.davehuang.io/content/images/2025/11/IMG_9592.png) 北海道的楓葉與銀杏，美的誇張 ![](https://www.davehuang.io/content/images/2025/11/FullSizeRender.png) 在街道上，我是既想遇到熊，又不想遇到熊，很是矛盾 客製化軟體的專案即將到一個尾聲，終於能回頭把 Peak Pals 發布，並且朝下一個專案進攻，心裡既是期待，又給了自己些許的壓力，我希望在 2026 年跨年的瞬間，回想起自己在 2025 年所做的努力，不會對自己感到失望。 ### 生活復盤、雜感、AI URL: https://www.davehuang.io/rand/ Last updated: 2025-11-02T00:00:51.000Z 我是個早上極度難醒來的人。 除了買過一款會模擬陽光照亮房間的鬧鐘還有點效果外（說實話還蠻裝逼的），我幾乎找不到能讓自己自然早起的方法。 ![](https://www.davehuang.io/content/images/2025/10/image-12.png) 賴床救星 偶而能讓我早上自動跳起來的內驅力，大概有三種： 1. 有期待的專案要去執行 2. 昨晚睡前腦中冒出的 Idea，想趁還沒忘記趕快去做 3. 生活累積的焦慮和壓力，等著被我處理 第三種是我最討厭的。當這種情況連續發生一週左右，我就知道是時候好好復盤一下自己的生活系統。 ## 出門散步 接連下雨超過一週，我也連續兩三週都在2\~3am才睡，趕工的節奏讓我連續盯著螢幕十幾個小時。乾眼症再度襲來。 朋友委託的客製化軟體、工作專案，時數與需求都遠超當初預想，把生活硬生生的推向了不可控和不健康。Side Project 也被迫擱置了上線的時間。 一早喚醒我的，再次是焦慮。 體內的雷達告訴我，再這樣下去遲早要 burnout，我得出去走走。 戴上耳機、開啟抗噪、播放股癌 podcast，邊走邊聽。 我想去買杯咖啡坐著看雨、想事情。 下意識的走向附近的星巴克——為的是快速、穩定、明確。但看著店內快速來去的人潮，以及高張力的商業氛圍，提醒了我今天是來釋放壓力的，便找了附近的獨立咖啡館，當作是慢下節奏的前置作業。 走進了一間很有年代感的小小咖啡館。菜單寫在黑板上、字跡有點模糊，店內堆滿了長灰塵的咖啡器材（跟我一樣是器材組的）。老闆看起來是對咖啡有熱情，卻仍在夢想與房租間掙扎的職人大叔。 店內只有兩桌內用座位，一桌被一群大嬸團佔據，六七個人聊得情緒高漲、很開心的樣子。我有點羨慕——既羨慕她們的悠閒，也羨慕能毫無目的性地聚在一起就很快樂的友誼。 點了杯美式，這才意識到這是我今年最長一段沒有自己泡咖啡的日子。 之前不知道看了哪個創業大佬說過「如果你沒辦法從泡一杯咖啡的過程得到快樂，那再多的錢都無法讓你快樂。」蠻雞湯的，標準已經很凱的人才有資格說的話。就在這個念頭閃過時，耳中的 podcast 恰好播到這一段——謝孟恭說道，他現在能夠非常游刃有餘的在市場中賺到巨量金錢，但回想起以前還在求生存的拼搏日子，反而會覺得當下努力的「過程」才是最快樂的。 好巧不巧，腦中的思緒與 podcast 同步地對我進行自我提醒。可能我現在這份「忙」，就是我的「過程」吧。 也想起自己很核心的一個內驅力，是想讓家人更幸福、過上更好的日子。但看著父母逐漸老去，自己前進的速度只怕是跟不上。 當我思緒還在飄移，猶豫著是否要坐在這麼窄小的店內時，後方一個阿姨點了點我的肩膀： 「この紳士～你有沒有200公分呀？」 大嬸軍團的目光瞬間轉向我，開始 high 起來。 「有沒有女朋友呀？」「女朋友多高呀？」「怎麼還不結婚呀？！」「哈哈哈哈！我女兒才156呀！妳們這樣身高差很多哩！要不要介紹一下？」「有沒有打籃球？林書豪多高呀？」「哎呀！頭會撞到拉！」 超歡樂的氛圍瞬間充滿整個2坪不到的內用區，也把我的思緒硬生生斷在那。但我不討厭這種感覺。 那就內用吧。 坐在僅剩的靠窗位，看著外面毛毛細雨和台北防火巷的一隅——那典型的台北老舊巷弄，給我一種銀翼殺手世界觀的感覺。 阿姨們熱情的拿著他們自備的餅乾來分給我（完全無視咖啡店老闆也有在賣小餅乾，這是阿姨軍團無視禁帶外食規定的特權）。我就這樣一邊想事情、一邊跟阿姨團瞎聊，把近期的生活和自省想了一輪。 想寫下這段微小的時光——坐在咖啡館看雨的餘裕，夾雜著內心仍未完全退去的焦躁，那種矛盾的感受。 ![](https://www.davehuang.io/content/images/2025/10/IMG_9184.png) 極小的座位 ![](https://www.davehuang.io/content/images/2025/10/IMG_9191.png) 阿姨給我的餅，她去越南玩買的 ## 總是一樣的結論：時間與選擇 從咖啡館返家的路上，我急著想寫下剛才的感受，同時也想起了幾週前，與從美國回台灣的兄弟在咖啡館的對話。我們聊了許多關於 AI 對工作的影響，他談了很多內心對 AI 強大所帶來的恐懼感與內卷感。 當時我信誓旦旦地跟他說，資深軟體工程師不會被取代，因為我經歷過 AI 也解決不了的問題，也見過不少案例是 AI 一時看似很快，後續卻浪費了更多時間。一方面可能也有對自己專業的自尊吧。但現在回想起來，我兄弟口中的焦慮，並不是純然害怕 AI 會超越人類，更深層的不舒適，應該來自於對「努力」的扼殺。 學生時期的我們，在我心中都是很努力的人。我們該玩的時候玩得瘋，該努力的時候很努力。也因為這樣，我才會與他們結成了一隊漂丿幫。而我們在求學、求職的魷魚遊戲中，一直以來的 edge 就是我們對枯燥乏味的體制的抗性、對努力與目標的自我要求，比整體人力市場多了那麼一個坎，這造就了我們的優勢。 但這份優勢正因 AI 工具的成熟與強大而被抹平。一些看似「取巧」的作法，在過去我們覺得不怎麼「努力」的人手中，可以在更短的時間骰出比我們更好的結果。這種「剝奪感」，才是我兄弟真正在乎的點——而我當時被 ego 蒙蔽，沒懂得共感那份感受。 回到自身角色，我們這些還需要靠著幫人打工、無法單靠資本釋放時間的階段，能做的仍舊非常單純：最大化地把時間用在對的地方、最大化地專注，同時監控著自己的心理健康至少維持在基礎值，別讓他爆掉，然後持續往前。 沒有捷徑。 ![](https://www.davehuang.io/content/images/2025/10/-------2025-10-28-------7.50.30.png) I love you, Claude. ### 如何創作有影響力的內容 URL: https://www.davehuang.io/spcl/ Last updated: 2025-11-17T17:17:36.000Z 我喜歡偷偷觀察朋友們的 Youtube 首頁。不是出自於窺探，而是因為能看見自己沒發現過的創作者，藉此拼湊出對方的興趣版圖。 我很懷念 7、8年前的Youtube。那時演算法還沒把我們的焦點限縮在一個很窄的推薦池裡面，破圈的權重更強。所以你會在獨立樂團、小眾頻道、甚至離奇古怪的內容間漂流——睡前點開一個有趣的影片，一個接著一個往下鑽，一不小心發現凌晨 5 點的自己正在學習如何在家處理有毒的深海魚類生魚片。 去年開始研究 Indie Hacker 創業路徑後，我的 Youtube 首頁現在充斥著相關的創作者。其中幾個人的頻道我常反覆觀看，影響力排序依次是：[Alex Becker](https://www.youtube.com/@alexbeckerbusiness?ref=davehuang.io) \> [Alex Hormozi](https://www.youtube.com/@AlexHormozi?ref=davehuang.io) \> [Charlie Morgan](https://www.youtube.com/@charliemofficial?ref=davehuang.io)。 有趣的是，這些人的內容對我的人生決策帶來的影響，遠超出我的想像。但我從沒深究過底層原因——只是直覺地認同、覺得很有說服力。 直到我開始有意識地寫作後，我才驚覺：這是多麼強大的能力啊。一個創作者能讓我如此自然地吸收他們的價值觀與人生觀，甚至內化成自己的思維方式。 這個發現讓我很想深究這背後的原理，當我看了 Alex Hormozi [這部](https://www.youtube.com/watch?v=dMZ-n2KSlxE&ref=davehuang.io) 關於內容影響力的影片後，我得到了一些答案，這篇文章我會透過自己的理解，分享對於這個框架的學習與思考。 Alex 指出，一個內容要對受眾產生實質影響力，進而 CTA，需要滿足四個條件： - Status - Power - Credibility - Likeness 他稱之為 SPCL 框架。 ## Status：掌握他人在乎的價值 當你身上有著他人想要的「好東西」，而這個好東西有稀缺性時，你便有了地位。 部門主管掌握有限名額的升遷權和調薪權，員工就會聽他的話；班上的 Cool Kid 決定誰能進入他的小圈圈，午餐時坐在 Cool Table，同學就會試著討好他。 ![](https://www.davehuang.io/content/images/2025/10/image-9.png) Cartman 在 Butters 心中有著強大 Status Status 不是靠名號或是頭銜，而是因為你掌握了別人在乎的價值。 但這裡有個關鍵：這種 Status 不是絕對的，而是高度「情境式」和「動態」的。 叱吒風雲的技術主管，在辦公室裡主導專案架構、手握資源調度，絕對的 Status——團隊成員圍繞著他轉。但在一場 team building 的 DJ 派對中，因為不善社交 chit chat，獨自坐在一旁，觀望著同事們狂歡大笑，他的 Status 在這邊並不管用，因為在這個場合，人們在乎的是親和力與幽默感。 回歸內容創作者的視角：你需要清楚地了解你的受眾在乎什麼，然後在那個領域建立自己的實質貢獻或優勢。累積受眾們真正渴望的東西——知識、機會、解決方案，或者新的視角。 ## Power：驗證與信任的累積 要在他人的生命中獲得 Power 有一個簡單的方式：當你的指導與建議，可以為別人帶來可驗證的**正向結果**，人們就會趨向於相信你的指令，並且追隨。 流程上是這樣的： 1. 你提出一個執行方向 2. 有人照著這個方式做之後，生活變好了 3. 他的大腦學到了一個模式「跟隨這個人的建議，會帶來好的結果」 4. 下次你提出請求時，這位受過你影響的人說「好」的可能性大幅提升 這就是 Power 運作的機制，透過一次次的驗證，逐漸獲得人們的信任。 ![](https://www.davehuang.io/content/images/2025/10/image-10.png) 應該沒有比這個更好的例子 我這幾年開始帶軟體團隊後，深刻體會過這樣的驗證循環： 有次，一位對軟體很有熱情、做事積極的 Jr. Engineer 向我提出，希望我多給他一些時間，把分派的功能做得更好更完善。他想按照 Design Pattern 的最佳實踐，大刀闊斧地重寫一個重滿歷史共業的複雜模組。因為我參與了更多的跨部門會議，掌握著更多的資訊——我知道按照團隊的發展方向，這個功能很有可能要面臨根本性的重構。所以我建議他先將實作方式保持彈性，不要把資源放在短期內會被推翻的東西上。 從工程的角度，他的想法 100% 正確，我也曾是個 Clean Code 熱血青年，但從整體 impact 的角度，這不是最佳解。他聽了我的建議，我也看得出來他有點失望。 幾週後，當重構確實發生時，他才明白我當時為何那麼說。那一刻，我在他心中的 Power 提升了，不是因為我在組織圖上身為他的主管，而是因為我的決策被驗證了。 在團隊中，領導者每次下的決策都在動態改變自己在組織內的 Power 值：下錯越多指令，導致成員受苦，就會被鄙視；下對了越多正確指令，為團隊帶來豐碩，就會受景仰。 ![](https://www.davehuang.io/content/images/2025/10/image-11.png) Sobel 很會帶新兵，但不擅長實戰 因此，作為內容創作者，你的 Power 取決於你的內容是否真的對受眾有幫助。 這個幫助可以是知識、視角、情感共鳴，或單純的快樂。無論哪種形式，核心都一樣：受眾因為看了你的內容而獲得了些什麼。 當這種幫助一次次被驗證時，受眾就會回來。他們會持續追蹤你、推薦你、信任你的下一個作品。這就是 Power。反過來，如果內容一次次讓受眾失望，信任也就消散了。 ## Credibility：你是誰，比你說什麼更重要 曾經寫下這篇經典文章「[How to Get Rich (Without Getting Lucky)](https://nav.al/rich?ref=davehuang.io)」（如何不靠運氣致富）的創業家 [Naval](https://x.com/naval?ref=davehuang.io) 曾說過： > Seek wealth, not money or status 這句話沒什麼好反對的。 但同樣一句話，從不同的人口中說出來，你會相信的程度完全不同： ![](https://www.davehuang.io/content/images/2025/10/------3.png) 右邊是用 Nano banana 做的假 Alex Becker 這就是 Credibility。 人們在乎的不是你說了什麼，而是「你是誰」。你的背景、你的成就、你的過往記錄——這些都在無聲地替你的話加權。 Credibility 會放大你的 Status 和 Power，讓受眾更願意相信你。 ## Likeness：共鳴 Likeness 的邏輯很簡單：人們傾向於相信和自己相似的人。 你有沒有過這種經驗？某個創作者講的東西，其實和別人講的差不多，但你就是更想聽他的。為什麼？因為他的說話方式、處事風格、甚至是他吐槽事情的角度，都和你很像。你在他身上看到了自己。那一刻，你不只是在聽內容，你是在聽「一個像我的人怎麼看這件事」。 反過來，再厲害的人，如果你覺得跟他沒什麼共同點，他的 Status、Power、Credibility 都失效了。因為潛意識裡，你會想：「他的經驗對我可能不適用，因為我們根本不一樣。」 我認為身為創作者，在 Likeness 這個範疇其實沒有什麼需要特別去做的。最好的做法反而是更真誠地做自己想做的事、講自己想講的話。不要試圖討好所有人，因為那會讓你失去真實。能夠與你產生共鳴的人，想知道的不是你講了什麼漂亮話，而是你究竟是哪一種人。 ## 行動指南：如何建立內容影響力 根據上面由 Alex Hormozi 提出的 SPCL 框架，我寫出了我能夠實際執行的 action items： ### **第一步：認識你自己，知道你的 Why** 在開始創作之前，問自己：我為什麼要做這件事？是為了粉絲數、是為了金錢？我真實的動機是什麼？這個「Why」會貫穿你所有的內容，也是觀眾能感受到的唯一真實。 ### **第二步：選擇你的領域，建立專業性** Power 來自於你在特定領域的可信結果。不要試圖什麼都講，而是**在某個領域深耕，讓自己成為那個領域的頂尖玩家。** 域名特殊性越高，你在那個領域的 Power 就更有機會越強。 ### **第三步：短內容只是吸引，長內容才能積累** 短影音和社群貼文是前期漏斗——它們幫助觀眾快速判斷「這個人值不值得深入了解」。 真正的影響力，來自於中～長形式的內容。那是你展現思想深度、建立信任、驗證 Power 的地方。 在可見的未來裡，內容會越來越強調「人味」。而人味的本質就是真實的生命軌跡。如果你的內容充斥著虛假的人設和包裝，本質上和 AI 生成的內容沒有差別。觀眾能感受到那種虛偽，會覺得你在污辱他們的時間價值。 ### **第四步：構思你的理想客戶畫像（ICP），專注於他們** 不要試圖說服所有人。相反，清楚地定義你的理想觀眾是誰。 我的 ICP 可能是「追求永續成長的獨立創業者，想在生命中掌握自己的節奏，最終能夠從這個世界 Unscripted 的人」。這群人不想被體制束縛，也不想被傳統的成功定義所限制。他們想要的是自由——時間上的自由、決策上的自由、人生選擇上的自由。 這就是為什麼我的部落格叫「Unscript with Dave」。每一篇內容，都是為了這群人寫的，又或者因為這是我想要的，一方面也是為那些「年輕版本的自己」所寫的。 ## 結語 我曾經跟一起上 [創作課程](https://www.davehuang.io/start/) 的同學討論一個我想不通的困擾：有時候我寫的文章，自己都感受到有種矛盾，我既想純粹的「抒發」，又想達成某種在讀者心中的「效果」，這種渴求也間接地影響了我創作的方式，我不喜歡這種感覺，但又說不上為何。 這現象很明顯，當我純粹地寫下心中想法，我很容易進入心流。反之，我越是想達目的性，寫完的當下我就知道自己不滿意。而我覺得這種不滿意，讀者也一定能感受得到。那是一種「不順」的抽象感受。 在研究這個 Status, Power, Credibility & Likeness 框架時，我才悟得這種矛盾的源頭：如果我寫這個內容是為了「賣」某種東西——不管是商品、觀點還是自己想灌輸的價值觀——我就會感受到一種沉重的「銅臭味」。那一刻，我知道我正在做一場交易，而不是真誠的對話。這讓整個創作都失去了純粹性。 反過來，當創作的本質是真摯的思想交流和想法紀錄時，感覺就完全不同了。 I'm not accumulating my audience for a product; I should be building an audience around a shared problem or interest. 激發思考，進而讓人有機會校正自己執行面的策略。寫出我的困境與省思，讓人有機會共感累積過程的苦澀與孤獨。 獨特領域的價值就是在這過程中一點一滴的打造、打磨。這無法預想，無法預測，只能透過不斷地實踐，有機的生成。 ## 本週紀錄 這禮拜我專注於一個客製化軟體的委託，沒日沒夜，搭配著一整個禮拜的大雨，我索性的也就不去運動了，成天專注的寫 code、工作，還把家裡整理了一番。 年初的時候我有跟我的好友 Circle 說，我今年的目標是用自己寫的軟體賺到第一塊錢，我覺得這個目標可能快要實踐了，心裡有點高興也有點 imposter syndrome。 某天雨變小時，我跟小e跑去台北車站吃飯，然後速速買了一個我很滿意的背包，打算下禮拜帶去日本旅遊的時候使用。我也送了一個背包給小e，我覺得我更滿意我送她的背包>我自己的。 ![](https://www.davehuang.io/content/images/2025/10/IMG_9154.png) 再見了，神秘農場 ### 完美隊友 URL: https://www.davehuang.io/ai-teammate/ Last updated: 2025-10-20T15:08:51.000Z 《魷魚遊戲》這部韓劇講述著一群負債累累的人，被捲入了一場生存遊戲——贏了便能拿走巨額獎金，輸了就是死路一條。 在魷魚遊戲中，有時得獨自作戰擊敗對手，有時則需要找到隊友並肩作戰。而每當來到團隊合作關卡，就會出現最關鍵的時刻——**選隊友**。 幾個有領袖氣質的角色開始挑人，被點名的興奮、被略過的絕望。 還記得當我看到這一段時，自己還很入戲的在想：如果是我，我會選誰？又或者，我會被選嗎？ 在生死關頭，你會看重什麼能力呢？是體力？是智慧？又或是抽象的默契？ 在不同的情境下，有哪些「指標」能夠幫助我們找到「完美隊友」呢？ ## 專項能力 當我們在評估一個隊友時，往往會評估：這個隊友是專才還是通才？ 他是否有深度的「領域知識」，在特定情境下能夠帶來效用。 魷魚遊戲中的拔河遊戲就是個很好的例子。表面上看，這關需要的是「力氣大的人」，但真正讓弱隊逆轉的，是那個懂拔河技巧的老人。他知道重心要放低、節奏要一致、在對手放鬆瞬間全力猛拉。這些「專業知識」讓十個瘦弱的人，擊敗了一隊年輕壯漢。 再看彈珠遊戲。這一關不需要體力，也不需要智商，需要的是「懂人性、會操控情緒」的人。有人用真誠博取信任，有人用演技製造混亂，有人甚至裝失智來降低對手戒心。在這個情境下，一個心理學家可能比一個運動員更有價值。 ## 創造力 這個隊友是否有獨到的見解與創意？能在意想不到的時刻，提出一個看似古怪卻有奇效的創意解方？ 椪糖遊戲就是最好的例子。所有人都在小心翼翼地用針挑、用手剝，深怕一個失手就讓糖餅碎裂。主角更慘，抽到了最難的雨傘圖案——那個彎曲的傘柄簡直是惡夢。眼看時間一分一秒過去，他突然想起小時候買椪糖時的「作弊技巧」：**用口水融化它。** 於是他開始狂舔碰糖**。** 一開始旁邊的人都以為他瘋了，但仔細想想後變成一群人一起狂舔碰糖，真的是又緊張又充滿惡趣味的一幕。這不是寫在規則裡的方法，也不是靠蠻力或智商就能想到的，這是把「兒時調皮的創意」，重組成當下的生存策略。 ## 可靠度 這個隊友是否在面對類似情境時，都能穩定地給出接近範圍的成果？他會不會今天說東、明天說西？跟 A 合作是一個樣，跟 B 合作又變了個人？ **最可怕的不是能力差，而是「不穩定」。** 彈珠遊戲裡，老人看似失智、記憶混亂，但你永遠不知道他是真的忘了，還是在演戲。這種不確定性會摧毀整個團隊的信任基礎。 更危險的是那種「記錯了還很有自信」的隊友。他告訴你玻璃橋第三塊是安全的，語氣篤定、表情真誠，結果一踩就碎。 **在生死關頭，一個錯誤的資訊比沒有資訊更糟——因為你會基於錯誤做決策。** 可靠度不只是「做得好」，更是「做得穩」，而後者往往更難評估。 ## 互相理解的能力 這個隊友能否理解「字面意思」跟「真實意圖」的差距? 拔河遊戲裡，當隊長喊「預備——拉！」有人真的在「預備」時就開始用力，結果整隊節奏全亂（俗稱天兵）。 在高壓情境下，沒人有時間把每個指令說清楚。 更難的是，每個人的溝通習慣天差地別。有人說話直白，有人習慣旁敲側擊；有人的「隨便」就是真的隨便，有人「隨便」其實是心裡有別的答案不好意思說。 一個好隊友往往擅長「讀空氣」。他會觀察你的個性、理解你的習慣，然後在你開口前就知道你要什麼。 ## 隊友揭曉 看到這裡，如果你以為我在教你怎麼選《魷魚遊戲》的隊友，那你只對了一半。 因為現在，我們每個人都在進行一場更真實的「選擇」——不是選人類隊友，而是選擇 AI 協作夥伴。 而評估 AI 的標準，與評估人類隊友的標準，驚人地相似。 --- ![](https://www.davehuang.io/content/images/2025/10/9781098166304.jpg) 當我在閱讀這本《[AI工程](https://www.tenlong.com.tw/products/9786264251358?list%5Fname=lv&ref=davehuang.io)》第四章「評估AI系統」時，作者提出了幾個評估 AI 是否能有效解決問題的評估準則： **1\. 特定領域能力 (Domain-Specific Capability)** 就像玻璃橋需要玻璃工匠、拔河需要懂技巧的教練，AI 也有專精領域。醫療 AI 模型能讀懂 X 光片，但不會寫詩；ChatGPT 擅長寫作，但我通常不會用它來寫 Code。選錯專長，就像帶著運動員去比下棋。 **2\. 生成能力 (Generation Quality)** 就像椪糖遊戲需要創意解法，AI 需要能產出新穎、有用的內容。但這裡有個矛盾：生成能力越強的 AI 模型，往往越容易「幻覺」(Hallucination)。 當 AI 被訓練得更有創造力，它會更敢「腦補」、更願意「聯想」。這在創意工作裡是優點——寫科幻小說時，它能編出不存在的星球；發想行銷標語時，它能組合出意想不到的詞彙。**適度的幻覺，就是創意的本質。** 但在醫療、法律、金融領域，這種「創造力」就變成災難。它可能編出聽起來專業但根本不存在的醫學術語、想像出從未發生過的判例編號。 **3\. 事實一致性 (Factual Consistency)** 當 AI 開始幻覺時，會用無比自信的語氣，告訴你一個根本不存在的統計數據、編造一篇論文標題、虛構一個歷史事件。**而你很難察覺，因為它說得太像真的了。** 我們如何測試事實一致性？給它多個類似問題，看答案是否趨近一致。 但這裡有兩個層次： **「局部一致性」：**同一對話中回答是否穩定？問三次「台北 101 有幾層樓」都該得到相同答案。 **「全域一致性」：**跨對話、跨用戶是否一致？今天告訴 A 用戶某藥物安全，明天卻告訴 B 用戶有致命副作用——**問題是，每個用戶都只看到自己那次「很一致」的回答，沒人知道 AI 在別處說了相反的話。** 在醫療、法律等領域，全域一致性至關重要；但在創意工作裡，適度變化反而是優點。 **4\. 指令遵循能力 (Instruction Following)** 簡單來說，就是「聽得懂人話」的能力。 你說「寫一份簡短的報告」，AI 給你三千字；你說「用專業但易懂的方式解釋」，它卻寫得像教科書一樣枯燥。問題不是 AI 不聽話，而是「字面意思」跟「真實意圖」之間有巨大鴻溝。 AI 面對的真正挑戰是人類的**隱含需求。** 你說「幫我整理會議記錄」，一個低階的 AI 模型會逐字謄打每句話，一個高階的 AI 模型會知道你要的是「重點決策」和「待辦事項」。 這也是為什麼**提示工程**（Prompt Engineering）變得如此重要，本質上，這是在學習用 AI 能理解的方式溝通。 - 不是說「幫我寫得好一點」，而是說「用三個段落、每段 100 字、舉兩個實際案例」 - 不是說「分析這份數據」，而是說「找出前三大趨勢、計算年成長率、用表格呈現」 把隱含的期待，變成明確的指令。 下方是 LMSYS 一個有趣的統計：AI前10大使用情境 | 排名 | 使用案例 | 示例提示 | | -- | ------- | -------------------------- | | 1 | 寫作 | 撰寫一篇關於AI叛亂的短篇科幻小說。 | | 2 | 角色扮演 | 假裝你是一名偵探，解決我的線索之謎。 | | 3 | 推理 | 如果所有A是B，且部分B是C，則A與C的關係是什麼？ | | 4 | 數學 | 求解這個微積分積分：∫ x² dx 從 0 到 1。 | | 5 | 編碼 | 撰寫Python二進制搜索樹的程式碼。 | | 6 | STEM知識 | 簡單解釋量子糾纏。 | | 7 | 人文/社會科學 | 討論文藝復興對現代藝術的影響。 | | 8 | 提取/總結 | 總結這篇關於氣候變化的文章。 | | 9 | 創意頭腦風暴 | 為遠端工作腦力激盪出5個應用程式創意。 | | 10 | 建議/諮詢 | 我該如何談判加薪？ | 這份清單透露一個訊息：**人們期待 AI 既能做高創意的事（寫作、腦力激盪），也能做高精確的事（數學、編碼）。** 但這兩種任務需要完全不同的指令風格，創意任務你要給空間，精確任務你要給限制。能否針對不同任務調整溝通方式，決定了你能否把 AI 用好。 ## 結語 當然，評估 AI 還有其他關鍵準則：安全性（會不會被駭客操控或洩漏機密?）、成本（每次呼叫 API 要燒多少錢?）、延遲（使用者能等30秒還是只能等 3 秒?）。 但上方提到的四個核心能力，讓我深刻感受到，選「AI 隊友」跟選「人類隊友」，本質上是同一件事。 你不會期待找到一個「體力好、智商高、情商高、永遠穩定、還能讀心術」的完美隊友，因為那不存在，就算存在，那個人大概也不會選你。 你只能根據任務需求，選擇「在關鍵指標上夠可靠」的夥伴。 在 AI 時代，人類的 edge 不是比 AI 寫得更好、算得更快，而是： - 理解模糊的真實需求：客戶說「要有質感」是什麼意思？老闆說「再優化一下」具體指什麼？ - 判斷情境的優先順序：這個任務的績效指標是準確度重要還是創意重要？是要質還是量？ - 選擇恰當的工具組合：什麼時候用基礎模型？什麼時候用專業模型？什麼時候根本不該用 AI？ AI 是強大的隊友，但它需要一個好隊長。 那個能把「客戶皺了眉頭」翻譯成「需要更溫暖的語氣」、把「老闆說還可以」解讀成「完全重來」、把一個模糊的商業目標拆解成十個可執行指令的人——那才是 AI 時代最稀缺的能力。 --- ## 本週紀錄 這禮拜更有意識的在 [Peak Pals](https://peakpals.io/?ref=davehuang.io) 上紀錄自己每天進行有效輸出的時間，但我認為是遠遠不足的，也因為這禮拜塞入了許多社交活動（2場慶生、一場高中聚會），讓我覺得自己在工作與獨立創業這一塊的進程沒有達到自己的自我要求，也感到焦躁。 但無論如何，看見重要的朋友、與家人相處，我覺得很開心富足，在每個相處的過程中我也都提醒自己，要活在當下，珍惜這些關係。 ![](https://www.davehuang.io/content/images/2025/10/IMG_9085.png) 與美國回來的好友相聚，喝了許多好的咖啡 ![](https://www.davehuang.io/content/images/2025/10/IMG_9105.png) 與台北朋友一起吃蒙古烤肉、慶生 ![](https://www.davehuang.io/content/images/2025/10/IMG_9109.png) 秋天快來了，我很期待 ### 獨立創業策略（下）：開發循環 URL: https://www.davehuang.io/solopreneur-3/ Last updated: 2025-10-20T15:07:58.000Z 承接上一篇 [獨立創業策略（中）：痛點驗證](https://www.davehuang.io/du-li-chuang-ye-ce-lue-zhu-tong-dian-yan-zheng-kai-fa-xun-huan/)，當你透過決策樹驗證出一個「有效痛點」後，接下來該怎麼做? 這篇將探討如何在有限時間與資源下，高效推進產品開發。 ## Lean Startup 開發循環模型 關於開發循環，最有名的莫過於 Eric Ries 在 2011 年提出的 Lean Startup 方法論。這個方法論的核心是一個三階段循環： > Build → Measure → Learn - Build：快速建造最小可行產品（MVP），用最少資源驗證核心假設 - Measure：透過數據測量用戶行為，追蹤關鍵指標 - Learn：從數據中學習，決定繼續（Persevere）或轉向（Pivot） ![](https://www.davehuang.io/content/images/2025/10/image-7.png) Source: [https://medium.com/@dominic\_11011/build-measure-learn-cycle-ace388a13b4d](https://medium.com/@dominic%5F11011/build-measure-learn-cycle-ace388a13b4d?ref=davehuang.io) 這個循環的核心理念是：最小化每次循環的時間，加速學習速度。理想情況下，你應該能在數週內完成一個完整循環，透過快速迭代找到 Product-Market Fit。 這個方法論賣出超過 100 萬冊，被翻譯成 30 多種語言，成為矽谷創業的「聖經」。但它真的適合所有人嗎？ ### 在軟體新創的經驗 在回答這個問題前，讓我先分享我在新創公司的實際經驗。 我曾在幾間新創公司工作，見證過這個循環如何在「理想條件」下運作： **團隊配置：** - 一個 10-15 人的強大技術團隊（前端、後端、SRE工程師） - 專職的 Product Manager 與 Designer - Data Team 負責數據基礎建設與分析 - C-Suite 高層具備深厚的 Product Sense **典型的開發循環：** **Week 1-2: Build** - PM 根據市場洞察與用戶反饋，定義下一個實驗方向 - Designer 快速產出高保真原型 - 工程團隊並行開發，前後端同步推進 **Week 3: Measure** - Data Team 早已建好完整的追蹤系統（埋點、儀表板、報表） - 產品上線後，即時監控關鍵指標 - 用戶行為、轉化率、留存率，所有數據一目了然 **Week 3-4: Learn** - 每週的產品會議上，團隊檢視數據 - C-Suite 根據數據與市場經驗做決策 - 下一個循環的方向隨即確定 **這樣一個完整循環，快則 2 週，慢則 1.5 個月。** 而且，這是在「已經有產品與用戶基礎」的情況下。團隊不需要從零開始建立追蹤系統，不需要重新設計整套 UI，不需要從無到有招募用戶。我們是在一個「能夠快速獲利的產品」上進行驗證與優化。 最重要的是，**每個人都在全職做這件事**。沒有人需要在晚上或週末才能推進專案，沒有人需要在「維持生計」與「推進產品」之間掙扎。 ### 回到獨立開發者的現實 現在，讓我回到我個人的 [Side Project](https://peakpals.io/?ref=davehuang.io) 經驗。 當我開始打造 Peak Pals 時，我以為自己可以套用在新創學到的方法。以下是我實際的開發循環： **Week 1-2: 規劃與設計** - 寫下 User Story & Happy Path - 根據此寫下 Tech Spec 與架構設計 - 開始製作 Figma 設計稿（這時候才發現有一堆 User Flow 的 edge cases） **Week 3-8: Full-stack Development** - 後端+前端開發 - 串接第三方服務與部屬 - Debug、優化、重構 **Week 9-10: 測試與迭代** - 自己測試（發現一堆 bug、無止盡的 backlog） - 找 5 個 test user 試用，收集反饋 - 持續迭代 MVP，修正問題 **Week 11-12: 準備上線** - 撰寫產品介紹與文案 - 優化 Landing Page - 設定基本的分析追蹤 - 思考如何推廣 **結果：我花了 3 個月，還停留在「Build」階段的尾聲。** 而這是在我有一個「相對能掌控自己時間的全遠端 full-time 工作」的情況下。如果工作進入高壓週期，或是需要常常進辦公室開會、處理突發事件，這個時間會拉得更長。 ### 殘酷的對比 讓我們用數字來對比這兩種情境： | 項目 | 新創團隊 | 獨立開發者 (我) | | ---------- | ------------ | ---------- | | **循環時間** | 2-6 週 | 12 週（3 個月） | | **人力** | 5-10 人全職 | 1 人兼職 | | **每週投入時間** | 200-400 小時 | 15-20 小時 | | **基礎建設** | 完整（追蹤、部署、監控） | 從零開始 | | **用戶基礎** | 已有數千到數萬用戶 | 從 0 開始 | | **數據可靠性** | 高（統計顯著） | 低（樣本太小） | | **決策速度** | 快（團隊協作） | 慢（一人思考） | **比起新創的情境，我慢了 6 倍。** 更殘酷的是： - 我沒獲利 - 也沒獲取足夠的用戶數據（10 個 test user 的反饋根本談不上「數據」） - 我還要維持全職工作來支付生活開銷 - 每次工作上的突發狀況都會打斷我的節奏 ### 核心矛盾 這讓我開始反思一個關鍵問題： **獨立開發者在如此有限的時間、資源下，是否真的有辦法把 Lean Startup 的開發循環跑得這麼完備？** 或者更直接地問： **Lean Startup 方法論，是否真的適合獨立開發者？** ## Lean Startup 模型的反對觀點 就在我反思自己的開發循環時，我讀到了 Daniel Kyne 的這篇文章：[《The Lean Startup is a terrible book for founders》](https://fullstackresearcher.substack.com/p/the-lean-startup-is-a-terrible-book?s=w)。 標題很挑釁，但論點卻讓我深思。 這篇文章指出，Lean Startup 建立在4個錯誤假設之上。 ### 錯誤假設一：「客戶不會告訴你他們想要什麼」 Lean Startup 說：客戶不會告訴你他們要什麼，只能透過行為觀察。 **但真相是：不是客戶不會說，是你不會問。** 如果你問：「你會用這個產品嗎？」你得到的是禮貌性謊言。 但如果你問（參考《[The Mom Test](https://pagerank.ing/product-managers-must-read-the-mom-test/?ref=davehuang.io)》）： - 「上次遇到這問題，你怎麼處理的？」 - 「你為了解決這問題花了多少時間/金錢？」 - 「你現在用什麼工具？為什麼？」 你會得到真實的痛點、使用情境、付費意願。 ### 錯誤假設二：「最好的驗證方式是直接建造 MVP」 Lean Startup 建議：盡快建造 MVP 收集數據。 但建造程式碼是成本最高的驗證方式。即使是在 AI 盛行的現在，你可以看見那些 vibe-code 出來的「產品」往往只能當作 social media 上面吸引眼球販賣焦慮的文案，實際能夠解決 [有效痛點](https://www.davehuang.io/du-li-chuang-ye-ce-lue-zhu-tong-dian-yan-zheng-kai-fa-xun-huan/) 的產品並沒辦法如此無腦的「純 vibe」。 ### 錯誤假設三：你沒有資源「快速失敗」很多次 Lean Startup 強調「Fail Fast」，但這建立在你有足夠資源承受多次失敗。 獨立開發者每次失敗的代價： - 時間：3-6 個月（你還要全職工作維生） - 情緒：每次失敗都消耗熱情，累積 burnout 風險 根據 Indie Hackers 統計： - 只有 5-10% 獨立開發者達到月入 $1000 - 大部分人在 2-3 個失敗專案後放棄 - 每個專案平均投入 6-12 個月 獨立開發者需要的是「聰明驗證」，而非「快速失敗」。 ### 錯誤假設四：早期階段根本沒有足夠數據 Lean Startup 強調「數據驅動決策」，但早期階段你根本沒有足夠數據。 統計學真相：要得到有意義結論，需要至少 100-200 個樣本。 但獨立開發者現實：前 3 個月可能只有 10-50 個用戶。 更危險的是：量化數據只能告訴你「What」（發生了什麼），無法告訴你「Why」（為什麼）。 要回答 Why，你需要質化研究：用戶訪談、觀察使用、開放式問題。 ### 那它到底適合誰？ **適合：** - ✅ 已達 PMF 的產品 - ✅ 有足夠用戶數據的成長期公司 - ✅ 有團隊與資源的團隊 **不適合：** - ❌ Pre-PMF 早期階段 - ❌ 有限資源的獨立開發者 - ❌ 需要深度理解的複雜領域 ## 我的下一步 經過前面的反思，我意識到獨立開發者不能照搬 Lean Startup，而是要建立適合自己的開發循環。 以下是我以 Peak Pals 為例，如果從頭開始，我會怎麼做這個 side project? ### 階段 0：構思 Carol（0-2 週） 在寫任何程式碼前，我會先回答：**誰是我的理想客戶？** 不是「25-35 歲上班族」這種模糊描述，而是一個具體的人——我稱她為 **Carol**。(這個概念來自 Jason Cohen：[《ICP: Ideal Customer Persona》](https://longform.asmartbear.com/icp-ideal-customer-persona/?ref=davehuang.io)) **我會這樣構思 Carol：** **背景與情境：** - 29 歲，在科技公司做 PM，全職遠端工作 - 每天工作很忙，但想要「有意識地成長」 - 試過 Notion、Habitica、Todoist，但都堅持不到一週 **真實痛點：** - 「我不是不知道該做什麼，而是太多工具讓我分心」 - 「設定系統的時間比使用的時間還長」 - 「每次打開 app 都覺得有壓力，因為太複雜」 **使用情境：** - 每天早上通勤時（10 分鐘），快速檢視今天要做什麼 - 完成一個目標時，想要「打勾」的成就感 - 不需要複雜報表，只需要「看見自己在進步」 **付費意願：** - 願意付 $5-10/月 for 簡單但有效的工具 - 重視的是「減少摩擦」而非「功能多」 - 決策邏輯：「能不能每天輕鬆使用」 **如何驗證 Carol？** - 在 Reddit (r/productivity)、Twitter、身邊朋友找 5-10 個「像 Carol 的人」 - 問他們：「你上一個目標追蹤工具為什麼停用？」 - 如果答案一致 → Carol 是真實的 - 如果答案分散 → 重新定義 Carol **為什麼需要 Carol？** 未來每個產品決策，我都問自己： - 「Carol 會用這個功能嗎？」 - 「這個複雜度會讓 Carol 放棄嗎？」 - 「Carol 願意為此付 $X 嗎？」 ### 階段 1：Talk & Design（2-3 週） 有了 Carol，我會用最便宜的方式驗證「她真的需要這個嗎？」 **Week 1-2: 深度訪談** 找 10 個「像 Carol 的人」，每人 30-45 分鐘訪談。 **我會問的問題（The Mom Test 風格）：** - 「你現在用什麼方式追蹤目標？」（了解現狀） - 「你最近一次放棄使用工具是什麼時候？為什麼？」（真實痛點） - 「如果有個工具能讓你『每天只花 2 分鐘』就能追蹤目標，你會願意試試嗎？」（價值主張測試） - 「你願意為這樣的工具付多少錢？」（付費意願） **我要聽到的信號：** - ✅ 至少 7/10 的人提到「現有工具太複雜」 - ✅ 至少 3/10 的人說「如果真的這麼簡單，我願意付費」 - ✅ 沒有人說「我已經有完美的解決方案了」 如果沒聽到這些信號 → 重新思考問題或受眾。 **Week 3: Landing Page MVP** 在寫任何程式碼前，我會做一個 Landing Page。 **內容：** - 一句話價值主張：「2 分鐘追蹤每日目標，不再半途而廢」 - 3 個核心痛點 + 對應解法 - 簡單的 Figma mockup（展示核心流程） - 郵件收集 + waitlist **成本：** - Framer：$0-19 - 網域：$10/年 - 總時間：1-2 天 **驗證標準：** - 至少 30 個郵件收集（來自我主動分享給訪談對象 + 他們的推薦） - 至少 5 個人主動問「什麼時候能用？」 **如果達不到？** - 檢討文案：Carol 真的在乎這個問題嗎？ - 檢討管道：我找的人真的是 Carol 嗎？ ### 階段 2：Build（4-6 週） **到這個階段才開始寫程式碼**，但我只做「核心中的核心」。 **我會問：Carol 的 Happy Path 是什麼？** **核心流程（MVP v1）：** 1. 註冊 / 登入（Google OAuth，不做自己的認證系統） 2. 設定 1-3 個每日目標 3. 每天打開 app，點擊「完成」 4. 看到簡單的進度條（7 天、30 天完成率） **就這樣。沒有其他。** **我會砍掉的功能（留到 v2）：** - ❌ 社群功能（太複雜，且 Carol 不需要） - ❌ 數據分析（Carol 不是數據分析師） - ❌ 客製化主題（nice-to-have，但非必要） - ❌ 推送通知（v1 先不做，v2 再加） - ❌ 桌面版（先專注 mobile web） **技術選型原則：** - 選「無聊的技術」（成熟、穩定、AI 熟悉） - 不追新框架（省學習時間） **開發節奏：** - Week 1-2：核心功能（基本 CRUD） - Week 3-4：用戶認證 + 基本 UI - Week 5-6：測試、修 bug、優化體驗 ### 階段 3：Test with Carol（1-2 週） MVP 完成後，我不會立即公開，而是先給「Carol」們試用。 **找 5-10 個「最像 Carol 的人」：** - 就是階段 1 訪談過的人 - 他們已經知道這個產品，有期待感 **我會這樣做：** 1. **個人化 Onboarding** - 一對一語音/視訊，看著他們第一次使用 - 記錄他們的困惑點、猶豫點 - 不要解釋，只觀察 2. **7 天使用追蹤** - 每天簡單問：「今天用了嗎？為什麼？」 - 不要問「喜不喜歡」，而是觀察行為 3. **深度反饋訪談** - 7 天後，30 分鐘訪談 - 問：「如果這個產品消失，你會想念嗎？」 - 問：「你會推薦給誰？為什麼？」 **成功信號：** - ✅ 至少 5/10 的人持續使用 7 天 - ✅ 至少 2 個人主動說「我願意付費」 - ✅ 至少 1 個人主動推薦給朋友 **如果沒有這些信號：** - 不是「加更多功能」 - 而是回到階段 1：我真的理解 Carol 的痛點嗎？ ### 階段 4：Launch & Iterate（持續進行） 如果階段 3 有好的信號，我會小規模 Launch。 **不是 Product Hunt，而是 Carol 聚集的地方：** - Reddit: r/productivity, r/selfimprovement - Twitter: #productivity 相關討論串 - Discord: 個人成長相關社群 **Launch 策略：** - 不是「推銷產品」，而是「分享故事」 - 標題：「我做了一個『2 分鐘追蹤目標』的 app，因為我討厭複雜系統」 - 內容：真實分享我為什麼做、怎麼做、學到什麼 - CTA：「如果你也討厭複雜工具，歡迎試試」 ### 我不會做的事（刻意選擇） 做了三個月 Peak Pals，我學到：**獨立開發不是「平衡」，而是「刻意取捨」**。 ![](https://www.davehuang.io/content/images/2025/10/image-8.png) 在 Threads 上無意間與 Jason Cohen 的對話，讓我認知到四件重要的概念 ### **1\. 不是找到平衡，而是資源配置** 我沒辦法同時做好全職工作、每週 20+ 小時 side project、運動、社交、睡眠。 我的選擇： - 犧牲：部分社交、娛樂 - 保留：運動（抗 burnout）、睡眠（維持專注）、核心關係（情緒支持） - 優化：全遠端工作、會議能閃則閃、簡化生活（減少熵值） 這不是「標準答案」，而是一個**適合我**的系統。 ### **2\. 這場「遊戲」可以是 Finite 或 Infinite** 設定 MVP 開發期與 PMF 信號。開發期結束後，如果沒有 PMF 信號，我會 pivot 或放下。但我不會後悔，因為學習本身就是價值。 這場 infinite game 的本質是我要享受旅程。就包含寫下這篇文章的同時，我也要感到充實與滿足。 ### **3\. 解放：我不用「Check all the boxes」** 作為獨立開發者，我的優勢不是「什麼都會」，而是： - 深度理解用戶（因為我就是用戶） - 快速決策（不需開會，不用滿足投資人期待） - 靈活調整（沒有包袱） 我可以戰略性地強化這些優勢，而不是焦慮「我不會做超絲滑動畫的 landing page」、「我的API能不能承受的了高併發」、「我不會 viral marketing」。 ### **4.獨立開發 = 時間是終極約束** 問：這個產品的時間需求，我 handle 得了嗎？還是它會不斷吃掉我的時間，永遠做不完？ **✅ 時間可控的產品（正面例子）：** - **Plausible Analytics（網站分析工具）** - 核心功能自動運作，不需人工介入 - 用戶問題可用文檔解決 80% - 規模化不需線性增加工作量 - **ShipFast / LaunchFast（Boilerplate）** - 製作一次，可賣給多人 - 提供完整文檔，用戶自助解決問題 - 偶爾更新即可，不需每日維護 **❌ 時間黑洞的產品（反面例子）：** - **Marketplace 平台（如 Airbnb-like）** - 需要同時招募房東與房客（雞生蛋問題） - 糾紛處理、客服需求高 - 規模越大，客服工作越重 - **內容訂閱平台（如 Substack-like）** - 需要持續產出高品質內容 - 每週/每月都有交付壓力 - 停更 = 用戶流失 **判斷標準：** - 這個產品能「睡後收入」嗎？（我不工作時，它還能運作嗎？） - 100 個用戶 vs 1000 個用戶，我的工作量會增加 10 倍嗎？ - 用戶問題能用文檔/自動化解決嗎？還是需要一對一處理？ 選擇「時間可控」而非「時間黑洞」的產品。 > 參考 Jason Cohen 的文章：[《Conflicting Choices》](https://longform.asmartbear.com/conflicting-choices/?ref=davehuang.io) --- ## 本週紀錄 前幾篇說到，在文章末段也想記錄一下自己這一週的旅程。 ### 回老家 原本在台北的期間被工作的瑣事搞到很心煩，也因此稍微有點失去了自己生命進程的專注力，開始找一些 coping 去做 (參見這篇的 [避開 Coping 陷阱](https://www.davehuang.io/ren-sheng-you-le-chang-xia-jie-jue-tong-ku/))。 回到嘉義後，嘗試慢下腳步，吃著與台北不同──更有溫度的食物，見了許久未見的朋友，與家人相處，並且專注在當下的時光，我覺得我有感到休息。 ![](https://www.davehuang.io/content/images/2025/10/image-5.png) 嘗試一家新的雞肉飯 ### Peak Pals 進程 打開我的 GitHub commits 審視了一下，發現自己上週其實有著蠻不錯的進度，把上線前幾個核心功能都如期完成了: - 完成了手機版的全部畫面 - 完成了個人頁面的開發 (可以讓用戶有一個公開的個人檔案互相加好友) - Notification 功能的完善 ![](https://www.davehuang.io/content/images/2025/10/image-3.png) Peak Pals 的個人檔案 接下來可以專心做上線的最後階段準備了。 原本還想要加入 [Buy me a coffee](https://buymeacoffee.com/?ref=davehuang.io) widget，沒想到 Stripe 跟 PayPal 的收款規定這麼嚴，看來是該撥點時間跟錢來弄一個美國的 LLC，有了收款功能我覺得會讓整體更有「成品」的感覺。 ### 專注力協定 上週，我收到了等待已久的 Solana Seeker，終於能夠進行我想嘗試很久的專注力協定──一支工作用手機，一支多巴胺機: - iPhone: 只安裝工作用 App & 生產力工具 - Android: 安裝 Social Media & Games 平常出門都只帶 iPhone，只有睡前可以拿 Android 出來玩。目前嘗試下來釋放出很多大腦的算力，在外面也更能活在當下。但缺點是有相片想要 po 的時候要先上傳到 Google Drive，晚上回家再用 Android 傳到 social。 ![](https://www.davehuang.io/content/images/2025/10/image-4.png) 等有夠久的 Seeker ### 很開心的事 上一篇引用的方法驗證循環的[作者](https://longform.asmartbear.com/jason-cohen/?ref=davehuang.io)，竟然 follow 了我的 [Threads](https://www.threads.com/@95sailor%5F?ref=davehuang.io)，我欣喜若狂! ![](https://www.davehuang.io/content/images/2025/10/image-6.png) ### 獨立創業策略（中）：痛點驗證 URL: https://www.davehuang.io/solopreneur-2/ Last updated: 2025-10-20T15:07:49.000Z 在上篇 [獨立創業策略（上）：能力＆機會](https://www.davehuang.io/du-li-chuang-ye-ce-lue-shang-neng-li-yu-ji-hui-2/) 中，我們談到了如何培養核心能力、找到機會，以及建立洞見與 Product Sense。但光是這些還不夠，你必須要確認自己看到的「機會」，是否真的存在商業價值。 這就是這篇文章要探討的核心：如何驗證痛點。 （依照慣例，原本想要在這篇文章收尾，但又寫太多，只好分三篇來寫。） ## 發現痛點的路徑 關注獨立開發者領域（[Indie Hacker](https://www.indiehackers.com/about?ref=davehuang.io)）一段時間後，我發現成功的獨立創業者大多遵循兩種主要路徑： ### 路徑一：解決自身痛點（Scratch Your Own Itch） 這是最直覺的方式——你就是產品的第一個用戶，也是最嚴格的評審。 這個路徑的優勢是： - 即時的反饋循環：每個功能、每個細節，你都能立刻感受到是否真正解決問題 - 不怕沒有早期用戶：即使一開始沒人使用，至少你自己在用，產品能實際改善你的生活 - 內驅動機：因為是自己在用，也會想持續優化改良 但陷阱也很明顯：當你過度沈浸在自己的需求中，可能會失去對市場的客觀判斷。「我覺得好用」不等於「其他人覺得好用」，自身的使用經驗不足以代表更廣泛的市場需求。 > 我在進行文字創作時，不時也有這種感覺：我究竟是自己寫爽的？還是這些文字終究能夠幫助到其他人？這兩者之間的界線，有時候比想像中模糊，因為如果我為了寫給別人看，但寫的很痛苦，可能也無法持續下去。 ### 路徑二：複製現有產品 + 獨特利基 (Edge) 這條路就像是使出《獵人》中 [盜賊的極意](https://baike.baidu.com/item/%E7%9B%97%E8%B4%BC%E7%9A%84%E6%9E%81%E6%84%8F/13785197?ref=davehuang.io) 一般，槓桿他人的努力，找到屬於你的切入點。 ![](https://www.davehuang.io/content/images/2025/10/image.png) 團長是我在《獵人》中最喜歡的角色 市場已經驗證了需求，你要做的是： - 找到現有產品的不足之處 - 為特定族群提供更貼合的解法 - 利用長尾效應，培養利基受眾（[niche](https://en.wikipedia.org/wiki/Niche%5Fmarket?ref=davehuang.io)） 但這個方式對 builder 來說，確實少了點「從0到1」的創造感。你在重新造輪子。雖然理性上知道這是更穩健的策略，但內心深處可能還是渴望那份「我創造了全新事物」的成就感。 **但這兩者並非二選一。** 最有效的策略往往是兩者的結合。你從自身痛點出發，在執行過程不斷自問： 「市場上是否已經有類似解法？」 「如果有，我的 edge 在哪？」 「如果沒有，為什麼沒人在在做？」 這樣既保持了內在驅力，又不會陷入閉門造車。 ## 痛點驗證決策樹 發現痛點只是第一步，更關鍵的問題是：這個痛點值得解決嗎？ 很多獨立創業者都經歷過這樣的循環：花了三個月做出了產品，才發現市場根本不存在，或是規模無法支撐商業模式。 為了避免這個陷阱，我根據 Jason Cohen 這篇超讚的 [文章](https://longform.asmartbear.com/problem/?ref=davehuang.io#path-from-problem-viable-business-model) 製作了一個中文版的「有效痛點驗證」的決策樹（Decision Tree），這個框架能幫助你在投入大量時間開發前，先判斷這個痛點是否具備商業價值。 ![](https://www.davehuang.io/content/images/2025/10/image-1.png) 這張圖我用 FigJam 拉了許久 Jason 的文章中，對每一個決策節點都提供了可量化的判斷標準。以下我挑出幾個最關鍵的節點來細究： ### 節點一：市場規模夠大嗎? 決策標準：至少 1000 萬 2C 用戶，或 10 萬 2B 用戶 這個數字看起來很嚇人，但背後的邏輯很單純。一個可持續的商業模式，至少需要 1000 位付費客戶。([Why](https://longform.asmartbear.com/pricing-determines-your-business-model/?ref=davehuang.io)) 那為什麼需要 1000 萬人的市場規模，才能得到 1000 位付費客戶？讓我用數據推導一遍： **曝光 → 點擊 (1%)** 根據 [Hubspot](https://blog.hubspot.com/agency/google-adwords-benchmark-data?utm%5Fsource=longform.asmartbear.com&utm%5Fcampaign=longform.asmartbear.com&utm%5Fmedium=post) 統計，一個廣告的點擊率落在0.3%\~0.5%，若透過有效的 SEO 可以有所提升，這邊就樂觀的抓 1%。 **點擊 → 付費 (1%)** 根據 [這篇](https://www.contentgrip.com/conversion-rate-business-benchmark/?utm%5Fsource=longform.asmartbear.com&utm%5Fcampaign=longform.asmartbear.com&utm%5Fmedium=post) 統計，一個設計良好的商品頁面（landing page）大約有 1% 的付費轉化率。 **計算所需市場規模** 10,000 次曝光 x 1% 點擊率 x 1%轉化率 = 1位付費用戶 因此，要獲得 1000位付費用戶，需要 1000 x 10,000 次曝光 = 1000萬。 這都還是相當樂觀的假設，現實中的點擊跟轉化往往更低，尤其在競爭激烈的領域。 **2B 的邏輯為何不同?** 在企業市場（2B）中，只需要 10 萬次曝光就能達到相同的 1000 位付費客戶門檻。主要有三個原因： - 更高的客單價 — 企業願意為解決方案支付更高的費用（$100/月 vs $10/月） - 更高的轉化率 — 企業決策雖然複雜，但一旦認定你的產品能解決問題，付費意願更強 - 更長的生命週期價值（LTV） — 企業客戶的流失率通常低於個人用戶 當然，2B 市場也有代價。銷售週期更長（可能需要數週到數月），決策流程更複雜（需要說服多個決策者），產品穩定性與支援要求也更高。 #### 節點例外：高單價小眾市場 ＆ 一人公司 這種策略的核心邏輯是，用更高的客單價換取小眾市場的親睞。實際上有不少成功案例。[Gumroad](https://www.gumroad.com/?ref=davehuang.io) 創辦人 Sahil Lavingia 就曾分享過，一人公司只需要幾百位付費客戶就能維持。許多針對專業人士的 SaaS 工具（如法律文件管理、建築設計軟體）也是如此——雖然市場規模不大，但因為客單價極高，依然能建立穩定的商業模式。 而對一人公司來說，這條路還有另一個吸引力：你不需要追求「規模化」，只需要過得好。如果你願意保持簡約，不雇員工，在你自己的條件下工作。這對很多獨立開發者來說，已經是理想的生活方式。 不過這條路並不輕鬆。你的產品必須真正解決高價值問題，而且你得有辦法接觸到那些願意付高價的專業人士。這往往意味著你需要深耕特定領域，建立信任與專業形象。 ### 節點二：用戶自己知道有這個問題嗎？ 用戶是否自己知道自己有著這個「問題」等待被解決？ 舉個簡單的例子：南方公園的阿丿（Eric Cartman）有著明顯的體重過重問題，但他一直覺得他只是「骨架大」。 ![](https://www.davehuang.io/content/images/2025/10/image-2.png) Fat boy 如果用戶根本不認為自己有問題，他自然不會主動尋找解決方案。 **這就是「自覺市場」與「非自覺市場」的差異。** 在自覺市場中，用戶會主動搜尋「如何解決 X 問題」。但在非自覺市場中，你需要先說服他們「你有這個問題」，然後才能推銷解決方案。後者的難度是前者的數倍。 #### **節點例外：你願意教育市場 + 長期主義** 非自覺市場並非完全不能做，但你必須滿足幾個條件： - 你願意成為這個解決方案的*布道者*（evangelist），而不只是產品開發者 - 你有良好的業務與說服能力，能夠教育市場 - 這是你深度在乎的領域，有足夠的熱情支撐長期戰鬥 - 你能接受極度緩慢的客戶增長曲線 換句話說，你不只是在賣產品，你是在「改變用戶的認知」。這需要時間、耐心，以及強大的內在動機。 但好消息是，一旦你成功跨越這道鴻溝，這類客戶往往會成為最忠實的用戶，因為你不只解決了他們的問題，還「開了他們的眼」。 ### 節點三：用戶有預算解決這個問題嗎？ 痛點存在、用戶也知道有問題，但如果他們沒錢買解決方案，商業模式依然無法成立。 舉個經典案例：自媒體課程。 假設某個自媒體課程瞄準「剛畢業的大學生」，承諾教他們如何透過自媒體賺錢。這群人確實對這個主題充滿渴望，但問題是——他們根本沒錢買課程。即使課程定價 $99 美金，對剛畢業、還在找工作的大學生來說，仍是一筆負擔。 反過來說，如果同樣的自媒體課程改為瞄準「有資本的老闆」，教他們如何雇用外部團隊打造自媒體、槓桿既有商業模式，這些人就有足夠的預算（甚至願意付 $5000 美金）來解決這件事。 同樣的「自媒體知識」，因為目標受眾的預算不同，商業模式的可行性天差地別。 #### 節點例外：低成本 + 規模 如果你能做到極低的維護成本，推出一個低價產品（例如 $5/月），並且觸及夠大的潛在市場，這個商業模式依然可能成立。 這在當前的技術環境下變得更可行： - 低成本部署方案 — 透過 no-code / low-code 工具，快速驗證市場而不需要大量開發成本 - 社群媒體流量紅利 — 透過 TikTok、Twitter、YouTube 等平台，以極低成本觸及大量潛在用戶 - AI 輔助開發 — 利用 AI 工具加速開發，降低人力成本 關鍵在於：你的成本結構必須比傳統公司低至少一個數量級。 我自己很震撼的一個案例是 Puff Count（戒菸 App）。創辦人 Steven Cravotta 是個 24 歲的年輕人，主修廣告行銷而非工程背景，透過 TikTok 行銷將這個 App 推到 $40,000 MRR（月經常性收入），更驚人的是這個 App 已經有超過 80 萬用戶。 Steven 的 edge 不在技術，而在於他深刻理解短影音的邏輯，他的 TikTok 影片完全沒有「業配感」，而是娛樂價值優先，最後才用極自然的方式帶出 call-to-action。 這個案例完美詮釋了在當前環境下，低成本開發 + 社群媒體流量紅利 + 精準的內容策略，如何讓一個獨立開發者在「低預算用戶」市場依然能建立穩定的商業模式。（註：Puff Count 在 2024 年底被收購，這也證明了這個商業模式的價值。） ### 節點四：憑什麼是跟「你」買？ 當市場上存在眾多解決相同問題的產品，價格也沒有顯著差異時，客戶憑什麼選擇你？ 這就是商業世界最難回答的問題：你的 X factor 是什麼？ 可能是客戶親自接觸過你，覺得你的個性契合、溝通成本低；可能是他認可你的價值觀，想透過購買你的產品同時解決問題也支持你（雙重價值）。 但無論是哪一種，核心都指向同一件事：信任。 #### **可感知的價值 vs 真實的價值** 在《[Unscripted](https://www.books.com.tw/products/F014003973?srsltid=AfmBOoqeSCNUVVZPG1iJCrqHvgQB8mmBqUe3XH6qm3eIl90NWk1WNhtp&ref=davehuang.io)》這本書中，作者提出「Value Attribute」（價值屬性）的概念——不是你的產品「實際上」有多好，而是客戶「感知到」你的產品有多好。 當用戶來到你的 landing page，他們會在心中進行一連串的「價值評估」： - 這個網站看起來專業嗎？ - 文案有說服力嗎？ - 有「關於我們」頁面嗎？團隊成員有具名嗎？ - 有完善的隱私政策與客服嗎？ - 支付方案多元嗎？有無條件試用期與退費政策嗎？ 這些都還只是在最初階的漏斗階段。每個細節都在累積用戶對你這個品牌與產品的「信任權重」。 更關鍵的是，很多時候[決策來自感性而非理性](https://www.davehuang.io/ren-sheng-you-le-chang-zhong-qu/)。 你的產品可能技術上更優秀，但如果用戶「感覺」競品更值得信任，最終訂單還是會流向對手。 這就是為什麼你必須在整個「價值感知路徑」上，針對每個細節進行優化——不只是做得好，還要讓用戶「感覺到」你做得好。 #### 真正的區隔化：深刻理解用戶 除了建立信任，另一個切入點是「區隔化」。 但這裡有個常見誤區：很多人以為區隔化就是「比競品多 3 個功能」。 實際上並非如此。你可能有 10 個功能，對手只有 7 個，表面上你贏了。但如果用戶真正在意的「核心功能」你只有 2 個，對手有 3 個，最終對手仍然勝出。 真正的區隔化，不是功能多寡，而是你是否真正理解用戶看待痛點的角度。 這需要你有能力與用戶深度溝通、進行有效訪談，然後針對他們真正在意的點提供解決方案。 #### 實際案例：Boilerplate as a Service 一個我認為很聰明的區隔化案例是「Boilerplate as a Service」（技術骨架即服務）。 這類產品販售的不只是一套開箱即用的程式碼模板，更重要的是： - 完全透明的程式碼 — 客戶拿到完整原始碼，可以自由客製化 - 完整的客服配套 — 不只是賣你程式碼就跑，而是在給定時間範圍提供支援 這個組合在「信任」與「價值感知」上做得非常好： - 購買後能立即解決問題（速度） - 即使賣家停止維護，客戶仍能基於穩定版本自行開發（降低風險與信任門檻） - 提供客服支援，但不綁架客戶（自主權） 對一人公司來說，這真的是個聰明的商業模式，設計並維護一個穩定的骨架，並提供諮詢服務。（諮詢本身就是 high-ticket sale。） > 最近看到一個不錯的案例是 [SaaS Rock](https://saasrock.com/?ref=davehuang.io)，它提供了企業級的全端 Web App 模板，依照不同收費區間，有著不同的客服程度與插件支援。而創辦人也是一人公司。 #### 節點例外：你本身就是品牌 如果你已經在某個領域建立了個人品牌（透過寫作、社群媒體、開源貢獻等），那麼「憑什麼跟你買」這個問題就容易得多。 人們會因為認識你、信任你，而願意購買你的產品，即使市場上有更便宜或功能更多的競品。 這也是為什麼很多獨立開發者會選擇「Build in Public」（公開開發過程）的策略： - 在 X / Threads 上分享開發進度 - 寫部落格記錄思考過程 - 在社群中回答問題、提供價值 你不只是在開發產品，你是在建立信任與個人品牌。當產品推出時，你已經有一群「認識你」的潛在客戶。 但這條路也需要時間累積。如果你還沒有個人品牌，就必須回到最基本的：優化每個「價值感知」細節，透過產品本身建立信任。 ## 結語 看到這個決策樹，你可能會想：「要滿足所有主線節點，對個人開發者來說是不是太難了？」 確實很難。但這不是「不可能」，我們需要策略性地選擇戰場。 作為獨立開發者，我們必須同時在多個戰場作戰： - 拓展認知 — 持續學習、理解市場 - 提升技術 — 開發產品、解決問題 - 建立影響力 — 內容創作、社群經營 - 推進業務 — 找到用戶、驗證需求 聽起來很累，對吧？ 這也是為何我非常認同 《Unscripted》 作者 M.J. DeMarco 說的一句話：「致富這件事，是一種嗜好。你必須要時時刻刻喜歡做這件事情，你才走得到終點」 如果你把這條路看成「苦差事」，那確實會很痛苦。但如果你把它看成一場你熱愛的[遊戲](https://www.davehuang.io/ren-sheng-you-le-chang-shang-shi-jie-guan/)，每天的進步都是經驗值的累積，那這個過程本身就值得享受。 回歸到生活的本質，我們必須要極度有意識的管控「時間」與「專注力」，並且問自己，「你是否有享受這過程？」 下一篇，我將探討，找到一個可行痛點後，如何有效的進行開發循環，而這也是我現在正在做的事情。 ### 獨立創業策略（上）：能力＆機會 URL: https://www.davehuang.io/solopreneur-1/ Last updated: 2025-10-20T15:07:40.000Z 這是一份獨立創業（Solopreneur）的策略指南，寫給正在思考或已經踏上獨立創業之路的人。 內容源自我長時間的閱讀與思考，並融合多位創業者的經驗，再經過內化後整理成更易吸收的策略脈絡。 我自己也正沿著這條路徑前行，希望這份整理能為同樣在探索的你提供啟發，也歡迎與我討論你們的想法與觀點。（我往往是生活圈中少數在玩這場「[遊戲](https://www.davehuang.io/ren-sheng-you-le-chang-shang-shi-jie-guan/)」的人，我想找到想跟我玩相同類型遊戲的玩家，一起攻略這個充滿挑戰的副本。） ## 能力是先決條件 在商業世界中，有四項能夠高效創造財富的核心技能（[How to Get Rich](https://www.youtube.com/watch?v=Zeiy22UBsW4&ref=davehuang.io))： 1. **銷售能力** 2. **創造能力** 3. **設計能力** 4. **打獵能力** 我將這四項技能進行職業對照與價值定位，做出了這個矩陣： ![](https://www.davehuang.io/content/images/2025/09/skills_matrix--1-.png) Skills Matrix 對於獨立創業者來說，這四個象限的能力都是必須要有的，因為你無法依賴大公司的資源、團隊與品牌（背後所承擔的風險也不同）。雖然這些都是必要技能，但現實是，時間是有限資源，我們必須要有策略性的選擇自身發展路徑。 > 為什麼是用「高效創造財富」的核心技能當作切入點呢？因為它背後代表的是當前這個世界的 meta 所需要的技能與需求窗口，是市場驗證後的結果，我們不需要重新造輪子或是重新發現一個早已演示在你面前的真實。 ### 主賽道：生存與發展 作為白手起家的獨立創業者，你需要先有一個「核心技能」來替人打工維生，在能夠生存的條件下，持續累積獨立創業的條件。 你需要根據自身興趣與天賦權衡，選定一條「主賽道」進行深度耕耘。 接著，便是將自己擺放到能夠同時練到這些主要技能，且有機會學習到其他附屬技能的高效率團隊之中（好的環境）。在這個階段，時間效率非常重要——待在一個爛的團隊好幾年，比不上在一個好的團隊中衝刺一個季度所能獲得的學習與認知拓展，這都是我在職涯初期深刻感受到的實際 [經驗](https://www.davehuang.io/ren-sheng-you-le-chang-xia-jie-jue-tong-ku/)。 這個「主賽道」除了是你未來創業方向的切入點外，這也是你在職涯初期高效進行工作轉換的「籌碼」，將時間分散在不同賽道上並不會有太高的效益。工作轉換的目的可能是： 1. 從低效率團隊換到高效率團隊 2. 有意識的找尋能夠補足自身能力缺口的環境 你，身為僱員，透過自身專業為這個團隊提供價值，同時換取了公司提供的舞台，藉由公司提供的風險庇護，拓展了個體戶資本量級無法看見的商業視野與認知。 透過 80/20 法則，利用附屬技能，將主技能進行放大創造出優勢。舉例： - Elon 是 創造 與 銷售 的能力複合體 - Steve Jobs 是 設計 與 銷售 的能力複合體 雖然上述兩位神人都是能力複合體下的優勢案例，但單就獨立技能，也都是 PR99 的存在。我們能自我要求的部分是，在主賽道項目達到 PR90 以上，然後附屬項目至少要 PR70\~80。 ### 9-5 & 5-9 想盡辦法加入優質的高效率團隊還有幾個原因： - 高效率團隊通常也是充滿人才的團隊，在這樣的環境下累積出來的履歷不會太差，透過這個表世界的 career portfolio 進行創業路徑的風險對衝（hedge），爆了你還能回去OK的公司上班。 - 高效率團隊通常伴隨高門檻，這樣的團隊能給出優於市場的薪資，這些都是要謹慎守護的創業籌碼，要小心不要陷入消費主義陷阱。（買網域、租虛擬主機、AI token、買書、買知識，樣樣都是在燒自己的錢。） - 高效率團隊能用更短的時間達到更多的 impact，減少無謂的加班與政治內耗，多出來的時間能拿來自由運用 而另一方面，要盡可能的在自己可控的時間內進行嘗試以及知識累積。（而這就是掌握 9 to 5 & 5 to 9的意涵。） - 9am \~ 5pm: 上班，高效率累積技能與拓展認知 - 5pm \~ 9pm: 自己的時間，如何有效運用？ 當然，5 \~ 9 只是一個比喻，隨著每個人的工作型態有所差異，我想表達的是，一天中除了上班外，可支配時間通常就剩這麼多，兼顧運動、吃飯、生活雜務與關係經營，其實很難再榨出更多時間。對於需要上班，而仍有創業想法的人來說，這是一個要兼顧「生存」與「搶時間」的戰鬥。 我自己的策略是： - 找到可以 remote 的工作，省下通勤時間與辦公室 chit chat（機會成本：辦公室政治能力、實體人脈經營機會） - 提高專注力（敵人：social media，高多巴胺娛樂） - 降低生活中的熵值，越簡單越好，避免情緒波動（敵人：drama，people with bad vibe） - 用錢換取時間（盟友：掃地機器人、外送食物、購買高品質知識，背後就是個人財務控管與物欲控制） 說實話對我來說，上述這些策略其實都有情緒債，一方面可能是我天生個性不夠工作狂，仍然有想要耍廢的惰性，內心深處也保有著對於藝文領域的嚮往（浪漫主義），也因為這些矛盾，情緒債累積到一定程度時的終點就是 burnout，而這也是我在這條路上持續挖掘自身後才理出來的一個答案。 未來我會獨立寫一些我自己如何面對 burnout 的文章，但我認為至少，在 burnout 與 burnout 間的衝刺期，我都能像是泰山在森林藤蔓上盪來盪去一般，在情緒的峰值與低谷間，持續向前進。 ## 如何找到機會？ 創業機會存在一個悖論：**當所有人都看得到時，通常已經太晚了。** 真正有價值的機會，往往隱藏在「**專業洞見」、「技術趨勢」**與「**未被滿足的需求」**的交會點上。 ### 洞見與 Product Sense 當你依循前面策略，逐步累積技能、與優秀團隊共事後，會在專業領域累積大量「經驗」。但要注意：經驗不等於「洞見」。 洞見是對經驗進行深度思考後的結果，它大致可以分為三個層次： 1. **現象觀察**：看見他人忽略的模式 2. **本質理解**：理解問題背後的根本原因 3. **趨勢預判**：推測未來可能的變化 那麼，如何從經驗進化到洞見？可以從三個面向著手： - 追溯＆提升資訊鏈：追蹤領域資訊源頭、研究領域專家的思維，並積極參與早期社群討論 - 問題敏感度：記錄反覆出現的痛點，觀察用戶常見的抱怨，思考「為什麼這問題一直存在？」 - 跨領域思維：借鏡其他行業的解法，探索新技術跨界應用，培養「技術遷移」的直覺。（必要時，能夠跨域進行降維打擊） 而「Product Sense」則是將洞見轉化為產品的能力。它不僅是直覺，更是一種結合觀察力、設計思維與市場敏感度的判斷力： - 判斷哪些問題值得解決 - 找出最貼近使用者的解法 - 在資源有限的情況下做出取捨 並能回答三個核心問題： 1. 這個問題對誰重要？ 2. 什麼解法能真正解決？ 3. 在當前市場時機，這個解法是否具備成功條件？ 簡單來說，Product Sense 讓人從「看見問題」走到「打造解決方案」，是創業者不可或缺的核心能力。 ### 選擇前沿領域 在快速變化的前沿環境中，舊解法迅速失效，新需求不斷湧現，這正是機會的溫床。 Paul Graham 在 《[How to Do Great Work](https://www.paulgraham.com/greatwork.html?ref=davehuang.io)》 中寫到： > 「知識像碎形一樣擴展，從遠處看邊緣很平滑，但當你學得足夠多、接近其中一個邊緣時，你會發現它們充滿了缺口。」 前沿領域的價值在於： - 真正的問題尚未被定義 - Outlier ideas 的潛力尚未被看見 - 風險與回報的比值更具吸引力 ### 最後的關鍵 從發現機會到打造解決方案，需要耐心與長期累積。能否堅持下去，往往取決於你對這段旅程的熱情與執著，我知道這說出來很cliché，但這確實是最終造就差異化因素之一。 ## 結語 原本我打算在一個章節中，把整個宏觀策略一次講完，再把重心放在各個面向的執行細節。但寫到這裡才發現，要在幾千字內涵蓋所有想說的內容是不可能的。 接下來的文章，我會繼續探討：**如何驗證「可商業化」的痛點，並高效的推進開發循環。** --- ### Peak Pals 這個 Side Project 對我的意義 我每天都會撥時間開發的 side project —— [Peak Pals](https://peakpals.io/?ref=davehuang.io)，正是我將這套獨立創業策略付諸實踐的場域。 ![](https://www.davehuang.io/content/images/2025/09/image-4.png) Peak Pals 它承載了幾個重要面向： - 時間運用 - 它幫助我更有意識的使用每天有限的時間 - 它幫我辨識我是否有走在我想前進的道路上 - 技能堆疊 - 在開發過程中，主動補齊各種軟體開發上的缺口 - Backend skills / System design / UX design / User onboarding / Marketing - 突破自我侷限 - 實際驗證商業法則，而不是困在理論裡 - 放下完美主義，學會「launch & iterate」 ### 寫下這篇文章的當下 今天我受到一位欣賞的友人邀請，去觀賞了一場由 WBC MuayThai 舉辦的泰拳賽，接連看了近20場的泰拳對決。看比賽的當下我除了被這項運動所展現出的暴力美學給吸引與震懾外，我心中浮現兩個念頭： 1. **我想繼續變強** —— 擂台上的強者帶給我極大的激勵與感動。 2. **在變強的路上要保持謙卑** —— 最強大的人往往最懂得低頭，對這條道路保持崇高敬意。 這個週末我覺得過得非常充實、開心，工作內容有所推進、Side Project 推出了幾個核心功能、在周末與好友相聚。 未來在每篇文章後面也都會附上當週在做的事情，以及寫下讓我開心的瞬間。 ![](https://www.davehuang.io/content/images/2025/09/IMG_8936.png) ### 人生遊樂場（下）：解決痛苦 URL: https://www.davehuang.io/playground-3/ Last updated: 2025-10-20T15:06:37.000Z 寫這篇文章時，我剛把 [Side Project](https://peakpals.io/?ref=davehuang.io) 的 landing page 推上線，看了看時間： 晚上11點，TGIF。 這個時間點讓我想起五年前的自己。 那時剛加入一間心中理想的美國公司，Engineering VP 個個是從 [FAANG](https://en.wikipedia.org/wiki/Big%5FTech?ref=davehuang.io) 出來的神級人物，對工作要求極高。身為一個剛從系統廠練完功過來的新人，每天都戰戰兢兢，產出也常被挑戰。 好幾個週五夜晚都加班到11點才發出 Pull Request（Pull Request 可以想成是軟體世界的開發進度審核），揉著充滿血絲的雙眼下班。走出坐落在信義區的辦公大樓時，看著街上同齡的年輕人在酒吧門口笑鬧、在夜店前排隊，心中總有兩種截然不同的聲音交疊： 「我知道我在做什麼，我有想去的地方，所以我在這裡拼搏。」 「看著大家在 Party，我是不是錯過了什麼二十幾歲該有的體驗？」 時間有限，我們所能體驗的人生路線，終要做出抉擇。 ### 奮鬥者的詛咒 直到某天，我的大哥 [好倫](https://www.youtube.com/@biantai34?ref=davehuang.io) 跟我說：「你這就是所謂的『奮鬥者的詛咒』（Striver's Curse）。」我去查了這個 [概念](https://www.cw.com.tw/article/5126042?ref=davehuang.io)，發現還真有這麼一回事。雖然我的具體情況跟 [原作者](https://www.amazon.com/Strength-Finding-Success-Happiness-Purpose-ebook/dp/B08WCKY8MB/ref=sr%5F1%5F1?crid=1S0CO7ZS7FCD4&keywords=strength+to+strength+arthur+brooks&qid=1652292188&s=books&sprefix=stren%2Cstripbooks%2C134&sr=1-1&ref=davehuang.io) 的定義不完全相同，但我理解這是屬於同一個類別的心理現象： > 越是有目標、越是努力的人，越容易陷入「永遠不夠好」的焦慮迴圈中。他們總是能看到自己與理想間的距離，因此即使客觀上已經做得夠好，主觀上仍然感受到強烈的不滿足感。 這解釋了為什麼我從出社會以來，每天從床上醒來時，都有著這些看似痛苦的「背景程式」在運作： - 我不夠自由 - 我不夠富有 - 我不夠有掌控 - 我不夠有成就 這些聲音像是永不停歇的背景雜訊，即使在客觀上進步了，它們仍然存在。 ### 痛苦的兩種狀態 我認為，人生中的痛苦大致分為兩種： **狀態1—可控的挑戰**： 當人生相對穩定時，我可以專注在想玩的「人生遊戲」上，痛苦變成了「有意義的困難」，就像遊戲中的 Boss 戰，雖然困難但過程充滿成就感。 **狀態2—不可控的混亂：** 但當人生的波動將我們帶到不可控的處境之中，這些不確定性將成為痛苦的來源。此時的痛苦不再有明確的「攻略」，更像是在迷霧中摸索。 我們無法永遠停留在可控狀態。生命中總會有失去、挫折、意外等不可控事件，將我們推入混沌。 ### 解決 vs 共處 面對這些痛苦，主流的建議通常是：「要學會與痛苦共處」。 但我不喜歡這種說法。不是因為它錯誤，而是因為它太被動了，不符我的個性。 我更傾向於主動出擊，既然痛苦存在，那我就要理解它、拆解它，找出可行的應對方案。我不想只是「忍受」或「接受」，我想要有策略地回應。 這不代表我天真地以為能夠消除所有痛苦，而是相信透過更好的框架和工具，我們可以讓自己在面對痛苦時更有準備、更有選擇。 就像在上一篇 [文章](https://www.davehuang.io/ren-sheng-you-le-chang-zhong-qu/) 中，我將遊樂場從1.0升級到2.0一樣——不是否認痛苦的存在，而是承認它，並找出更好的遊玩方式。 那麼，具體該怎麼做？ ## 定義 & 拆解 若要解決一個問題，我們得先定義這個問題，若能拆解它的話，那更好。就像在 debug 程式一樣，你不能對著螢幕上滿滿的紅字錯誤訊息發呆，我們可以一行一行的逐一擊破（[divide and conquer](https://zh.wikipedia.org/zh-tw/%E5%88%86%E6%B2%BB%E6%B3%95?ref=davehuang.io)）。 我們可以把這些痛苦視為三個不同顏色的「信號燈」，每種信號燈背後連結著一些關鍵訊息等著我們去拆解： ### 🟢 必要痛苦（綠燈）：Go，這是成長的代價 - 學習新技能時的挫折感，面對未知的不適 - 健身時肌肉帶來的痠痛 - 建立與他人連結時的脆弱與挫折 綠燈痛苦在提醒你：「專注！有更重要的事在等著你，別浪費時間刷抖音。」 ### 🟡 自製痛苦（黃燈）：Slow down，你在自己整自己 - 滑 IG 看別人炫富帶來的比較心態、看著猛男辣妹帶來的容貌焦慮 - 因為拖延與惰性而產生的自責 - 用完美主義包裝的自我癱瘓 黃燈痛苦在說：「慢下來想想，你是不是搞錯了什麼？」 ### 🔴 存在痛苦（紅燈）：STOP，你只是個人 - 死亡焦慮 - 意義追尋 - 孤獨感 - 無聊感 - 意外 紅燈痛苦在說：「嘿，記住你只是個人類（🐒），你也有極限。」 ### 我的痛苦清單 回到上頭的自身案例，我把自身存在的痛苦向下挖掘，進行信號分類： 🟢 綠燈： - 不夠自由 → 想做更多的 side projects、想隨時見到想見的朋友 - 不夠富有 → 想帶家人去看世界、創造理想的生活環境 - 不夠有掌控 → 想帶領團隊高效地往前進 - 不夠有成就 → 想回應基因造就的自我的期許 這些其實都是有解方的必要痛苦（🟢），我只要專心地往前進就好。 🟡 黃燈： 五年前的我，在比較同齡人在夜店 party 時，那就是黃燈亮起的時候。這時痛苦在提醒我：「你在懷疑自己的選擇，但其實你很清楚自己要什麼。」 🔴 紅燈： 嗯，它會來的，但不是今晚 11 點在我電腦前能去處理的。專心應對，享受旅程。 ## 解決必要痛苦 建立了上述的痛苦分類系統後，我發現：**綠燈痛苦（🟢）才是真正值得投資時間的地方**。因為解決一個綠燈痛苦，往往能連帶解決好幾個黃燈痛苦。 以下是幾個我親身體會並且整理出的幾個解決必要痛苦的切入點： ### 避開 Coping 陷阱 什麼是 Coping Behavior？ 我把它翻譯成「迴避性自我調節」——當我們面對痛苦時，本能採取的各種暫時緩解不適的行為，但這些行為往往治標不治本。 還記得文章開頭那週五晚上 11 點的加班嗎？當時我的綠燈痛苦很明確：技能不夠強，產出被挑戰。 真正的解決方案是深入學習框架、主動請教前輩、研究優秀同事的程式碼。 但當時的我除了這些，還養成了 coping 的壞習慣：一回家就打開英雄聯盟，卯足全力地爬積分，試著在一個錯誤的領域找到一種「我似乎有在前進」的錯覺（當時的勝負欲還特別強，輸了會在那邊生氣）。 其他不同的 coping 血淚史也寫不完： - 看技術文件過程枯燥無趣 → 刷抖音找多巴胺 - 工時拉長充滿壓力 → 報復性熬夜「奪回」時間控制權 - 完美主義作祟 → 不斷換 Side Project 題目，永遠不上線 這些 coping 行為讓痛苦暫時消失，但問題依然存在，甚至變得更糟。 要避免 Coping 陷阱，關鍵是學會識別自己的逃避模式，然後問自己：「我現在是在解決問題，還是在逃避問題？」 當你專注在「做」真正解決問題的行為時，注意力自然從痛苦轉移到進度上。那種專注狀態下的滿足感，比任何 Coping 行為都有效。 （但要小心，不要陷入了有生產力、但不被需要的自 high 型空轉，可參考這篇: [Joy+Skill but not Needed](https://longform.asmartbear.com/fulfillment/?ref=davehuang.io)） ### 意義賦予 x 給定時間軸 必要痛苦最煎熬的地方不是痛苦本身，而是**它彷彿永無止境，而且你不知道為什麼要承受它**。 就像在漆黑的隧道裡走路，你不知道還要走多久，也不確定前方是否真的有光。這種「不確定性」會把原本可以承受的痛苦，放大成令人崩潰的折磨。 我的寫作地獄現場： 就在寫這篇文章的時候，我經歷了一次完美的示範。開頭文思泉湧的寫完第一章節後，就呆坐在電腦前一個小時，游標閃爍，腦袋一片混沌。 於是我打開 Notion，在我的備忘錄裡寫下：「現在是午夜12點，我覺得自己寫不出高價值的內容，很想關掉電腦去睡覺。我寫這篇文章是為了幫助那些和我有類似困擾的人，寫給那些年輕版本的自己。我今天預計寫到凌晨1點，如果還是卡住，就明天繼續。重點不是今晚一定要寫完，而是要推進這個有意義的項目。」 寫完這段話，我的焦慮感瞬間降低了 70%。為什麼這招有效？ 首先，**給痛苦設定終點讓它變得可控**。「不知道要痛多久」比「知道要痛兩小時」可怕太多。 其次，**意義賦予讓痛苦有了價值**。同樣是肌肉痠痛，健身房裡的痠痛讓你興奮（因為知道肌肉在成長），但莫名其妙的痠痛會讓你擔心（因為不知道為什麼）。當你清楚知道承受這個痛苦是為了什麼更大的目標時，忍耐力會大幅提升。 同樣的方法可以套用在任何處境：我現在刷 Leetcode 刷得很痛苦，我覺得這對我的工作所需毫無幫助，但我要趕在未來三個月的求職淡季內準備好自己，這樣便能在求職總人數相對低的時間點高效率的去面試，提升勝率。 ### 創作 這是我近期最意外的發現。 我一直有寫日誌的習慣，主要是紀錄雜亂想法以及過程所學到的心得，但這從來都只是侷限在自我對話的範疇，無法真正的幫助到他人。 當我 [因緣際會](https://www.davehuang.io/qi-dian-chuang-zuo-yu-biao-da/) 開始有意識的進行文字創作，向外輸出時，我感受到了創作過程的愉悅，寫下心中想法的過程帶給我自由、掌控、快樂的感受。點下「發布」按鈕的瞬間，更有種莫名的爽感，彷彿這篇文章帶來了一些可能性。 創作過程除了能夠分享見解，幫助他人，這同時也是寫給當下自己的藍圖，強化了自己的信念同時校正思路。而我相信這也是寫給未來某個時間點的自己，當我在未來感到迷茫時，回頭看看這個階段的自己，說不定能重拾許多被洗刷淡去的自我。 創作也不一定是寫文章，拍照、剪影片、做一個醜醜的手工藝送給朋友，都可以。 ### 建立 Support System 寫在最後的是建立一個自己的支援系統，向與自己同頻的人表達自己的目標與進程。 在三個月前，當我正準備開始著手開發 Peak Pals 時，我便向父母說：「我未來幾個月會比較忙，可能沒時間常下來南部陪你們。我在開發一個我覺得很有意義的 App，到時上線後請幫我多多使用，給我一些用戶回饋！」 我也開始跟身邊的朋友分享自己做這個 App 的理念，以及開發過程所遇到的困難與進度。 原本可能會擔心的問「你怎麼都不回家」的父母，現在會主動關心開發進度。朋友們也會在聚會時，問起開發進度，幫我測試服務、發想新的功能。我不再是一個人在戰鬥。 只有當你明確說出自己正在做什麼、往哪裡前進，旁人才有機會在適當時機給你幫助。 以前我很愛搞苦行僧模式（monk mode），覺得埋頭苦幹很帥很中二。結果卻是搞差了許多關係，自己也孤軍奮戰得很痛苦。這次我學會直接把進程向信任的人說出來，同時這也是讓自己對任務當責的正向強化。 > 歡迎註冊測試名單，Peak Pals 是為有目標且勇於追尋的人而生： > [https://peakpals.io/](https://peakpals.io/?ref=davehuang.io) ## 人生遊樂場的隱藏關卡 人生的前輩曾提醒我，在這個人生遊樂場中，那些提升到下一階段的隱藏道具，往往藏在那些你最不想做的事情背後，當你被痛苦逼迫到你得去面對那些痛苦，並且熬過去時，就會出現等級提升的背景音效。 撰寫這篇人生遊樂場最終章的過程，腦中彷彿回到過去人生的關鍵節點，而這些節點總是與「痛苦」脫離不了關係，但同時，它們又如同「遊樂場」一般有趣，充滿著挑戰與刺激的情緒起伏。 我期望未來的自己更加專注於旅程本身，雖然這是我不斷遺忘、重新想起、再度遺忘的一件事。 而除了享受旅程，也需要建立一套自我校正系統，不能有「自己總是對的」傲慢心態。從認清「我不能傲慢」，到真的做到，其實是兩段截然不同的進程，還待在第一段時常以為自己已經做到，但其實需要過程去迭代。 學習讀懂痛苦的信號、掌握回應的工具，「奮鬥者的詛咒」就成了「奮鬥者的祝福」。期許我們在這個人生遊樂場，少一些無謂的痛苦，多一些有意義的快樂，玩上真正屬於自己的那場遊戲。 ### 人生遊樂場（中）：驅動力 URL: https://www.davehuang.io/playground-2/ Last updated: 2025-10-20T15:06:26.000Z 當我們做決定時，究竟是理性還是感性在主導？ 在上一篇 [文章](https://www.davehuang.io/ren-sheng-you-le-chang-shang-shi-jie-guan/) 中，我提出了「人生如同遊樂場」的類比，文中的敘事框架是基於理性思考，描繪人們如何在理想情境下自我實現，系統化的滿足好奇心。 但在撰寫的過程中，我隱約覺得這個體系缺少了點什麼。 經過一週的自我對話與挖掘，我醒悟到：那些真正改變人生軌跡的關鍵時刻，往往不是來自數據化的邏輯分析，而是發自於內心的渴求與嚮往，甚至是基於內心深層的某種痛苦。 這些感性驅動的決策，才是真正造就我們人生進程與命運改變的核心原因。 ## 理工宅的盲點 身為軟體開發人員，我養成了一個職業病：習慣用數據說話，討論問題時總是直奔核心，用最直接了當的方式表達心中觀點。 這是多年訓練的結果。我知道透過這樣的方式，可以最有效率地跨團隊溝通，讓大家快速解決問題，朝下一個目標前進。 但這套在工作中的溝通模式，換個場景還管用嗎？ 假設我用既有的理性模式，嘗試在市場上推廣自己開發的 App，會是這樣： > 文案一： > > 我的習慣追蹤 App 採用最新技術架構：雙人即時同步進度條、基於機器學習的習慣完成率預測、AI個人化提醒演算法，以及完整的數據分析儀表板。 > > 根據行為心理學研究，習慣養成需要平均66天，我們的演算法會根據個人數據調整最佳提醒頻率。 > > 目前App Store 4.2星評價，已有超過5,000用戶驗證功效，是目前市場上技術最先進的雙人習慣養成解決方案。 技術規格完整，數據漂亮，但如果不是我自己寫的，大概看完第一行就掉頭了... 如果我換個角度，站在那些渴望改變、卻總是半途而廢的用戶立場，會怎麼表達？ > 文案二： > > 你是不是也有過這樣的夜晚？躺在床上懊悔著又荒廢了一天，想起年初信心滿滿立下的目標，現在卻早已拋諸腦後。 > > 那種『又是我一個人在努力』的孤獨感，那種『反正沒人知道我放棄』的自我安慰...但如果有個人跟你一起呢？ > > 當你早上7點半想賴床時，手機傳來訊息：『我已經起床了，你呢？』； > 當你終於完成第21天連續運動時，有個夥伴比你自己還興奮地為你慶祝。 > > 我相信，除了「獨自升級」以外，有更多的可能性，我們可以「一起升級」。 ### 關鍵洞察 兩個文案的差異，不是寫作技巧上的差異，而是反映了大腦運作的本質： **情感是決策的起點，理性是決策的工具。** 第一個文案說服了邏輯腦，第二個文案打動了情感腦。而神經科學告訴我們，真正驅動行動的，往往是後者。 這個原則適用於任何形式的創作：文字、影音、實體產品、數位產品，甚至專業服務。 我們的任務不是說服人們的大腦，而是觸動人們的內心。 ## 改變人類的行為 在分析人類行為時，我想到兩個經典理論的結合： ### 賽門·西奈克（Simon Sinek）的黃金圈 - 操弄：透過恐懼、威脅、獎懲機制等外部手段 - 感召：透過願景、使命等正面激勵 西奈克在 [TED 演講](https://www.youtube.com/watch?v=5oxIJNGYmgI&ref=davehuang.io) 所提出的「黃金圈」理論與他的著作《[先問，為什麼](https://www.books.com.tw/products/0010926506?srsltid=AfmBOorhA5DYxNlSKl6VDx1Pz-5T7TsykvJQXbXAm5eVnZ2JiESmT8RE&ref=davehuang.io)》中提到，影響人類行為的方法有兩種：操弄（manipulate）或感召（inspire）。操弄雖然短期有效，但真正持久的影響力來自感召人心的信念。這也是為什麼，他認為最偉大的領袖都是從「為什麼」開始思考，而非「做什麼」。 ### 東尼·羅賓斯（Tony Robbins）的 Pain/Pleasure 原則 - *逃離痛苦* 的強烈動機 - *追求快樂* 的內在渴望 羅賓斯發現，人類所有決策的核心都基於這個簡單原則：我們會竭盡所能避免痛苦，同時追求快樂。而避免痛苦的驅動力往往比追求快樂更強烈，這也是他著名的 [Dickens Pattern](https://www.youtube.com/watch?v=8awWbuFQL2Q&ref=davehuang.io) 技巧的基礎。 結合這兩個大師所提出的理論，我做出了這個圖表： ![](https://www.davehuang.io/content/images/2025/09/behavior_change_matrix.png) 這圖表補足了「遊戲場理論」中，那些關於「痛苦」的缺口。同時也解答了我在演說當下，在提出人生遊樂場論述時，沒能與現場觀眾產生連結的其中一個原因——來到一個課堂上，並不只是想把人生這場遊戲玩好，如同購買遊戲攻略般，這麼線性、這麼簡單。 ## 遊樂場重塑 在上一篇的 [人生遊樂場](https://www.davehuang.io/ren-sheng-you-le-chang-shang-shi-jie-guan/) 理論中，是遊樂場理論的 1.0 架構，一個基於純粹渴望的：「我想玩什麼遊戲？」 而透過這篇的頗析，延伸出了更完整的遊樂場2.0：「我想玩這個遊戲，同時我也想逃離那些令我痛苦的部分。」 ![](https://www.davehuang.io/content/images/2025/09/image-2.png) 我認同在這個遊樂場中確實存在著許多痛苦成分：挫折、失敗、失去、不如意，這都是遊戲的一部分。 但對我來說，更重要的是如何回應這些痛苦。唯有在可控的範圍內成為更好版本的自己，我們才有能力在這個遊樂場中真正擁有選擇權，與重要的人一起專注在當下的遊玩體驗——也就是旅程本身。 --- 遊樂場1.0廣受客訴：「Hey!!! 你沒跟我提到有這麼多的痛苦！退費！退費！」 於是遊樂場於入口貼了這樣一張告示：「本遊樂場從不承諾沒有任何痛苦！但也有很多好玩的部分，如果你有本事付出代價，就進來玩玩看吧！」 我看了看告示，深吸一口氣，再度入場。 最後，用影響我甚多的心理學家 喬丹·彼得森（Jordan Peterson）的這個演說作為一個結尾。下一篇我想探討，什麼是我的版本的解決痛苦。 0:00 /7:30 1× [Youtube Source](https://www.youtube.com/watch?v=wLvd%5FZbX1w0&ref=davehuang.io) ### 人生遊樂場（上）：世界觀 URL: https://www.davehuang.io/playground-1/ Last updated: 2025-10-20T15:06:12.000Z 在上一篇[文章](https://www.davehuang.io/qi-dian-chuang-zuo-yu-biao-da/)中，我提到了參與《創作與表達》課程的經歷。在課程的個人演出環節，我分享了現階段對世界的理解，希望讓同學們更了解我的價值觀，促進彼此交流。 這篇文章將更明確地記錄當時的論述，並深入思考其中可能存在的盲點。同時，這也是我階段性觀念的快照，未來或許能成為幫助自己或他人解析人生策略的參考。 ## 一個我常問朋友的問題 和許久未見的朋友聚會時，我總會忍不住問他們： 「你現階段的人生，追求的是什麼？」 一開始我沒有想那麼多，就是單純好奇，但隨著我準備著這場演出，我開始思考自己為什麼總是問這個問題。要找到這個動機，我必須先拆解自己對於世界的理解。 ## 我的世界觀：人生遊戲化思維 ![](https://www.davehuang.io/content/images/2025/09/-------2025-09-05-------1.10.00.png) 我自製的精美 mermaid flow ### 一、這個世界是一個巨型遊樂場 我們每個人都獲得了一個名為「生命」的禮物，這份禮物讓我們能夠進入人生遊樂場「一回合」。 在這有限的回合中，我們的目標是盡情玩樂、最大化正向體驗。 ### 二、了解遊戲規則與選擇權 雖然我們身處同一個遊樂場，但每個人想玩的遊戲並不相同。 當你具備足夠的自我覺察和對自身的理解，很自然地會發展出想玩的遊戲方向。你開始在各個領域精進，背後的動機是「你有更想玩的遊戲」，而你想去追尋。 然而，也有一部分的人從學生時期到出社會後，持續按照社會給予的腳本被動地活著。我將他們視為「腳本執行者」，或者說是 [NPC](https://zh.wikipedia.org/zh-tw/%E9%9D%9E%E7%8E%A9%E5%AE%B6%E8%A7%92%E8%89%B2?ref=davehuang.io)。他們不知道自己想玩什麼遊戲，甚至沒有「選擇遊戲」的概念。 > 遊戲間有著不同的風險偏好： > 有人喜歡高風險高報酬，也有人認為背負著高風險所獲得的獎品其實不符合自己的喜好，他人眼中低回報的玩法，其路途的風景對你來說比任何獎勵都更加珍貴，這樣也很好。重點是，你要主動的下場去玩，而不是只當觀眾。 ### 三、不同遊戲、不同代價 即使你知道你想玩什麼遊戲，你發現，有的遊戲是必須要付出額外「代價」才能參與。這代價可能是時間、努力、汗水，以及必要的一點運氣，有了這些籌碼作為代價，你才能登上那個你原本以為想玩的遊戲牌桌。 之所以說「原本以為想玩」，是因為很多遊戲外面看是一回事，真正參與後又是另一種體驗。不付出相應的代價，你永遠不知道真正的遊戲體驗是什麼。 登上牌桌後你可能發現，你努力付出的代價，對其他同桌的玩家來說可能輕而易舉。他們可能擁有你千倍以上的籌碼可以任意的揮霍，反之也有可能，他曾付出比你更巨大的努力，卻往往在運氣這關，輸給了你。 > 關於躺平的思考： > 時下有一種玩法叫做「躺平」，在許多人的現實中是不得已的選擇。表面上不需要付出代價，只需要自動導航，任由多巴胺系統本能地告訴你下一步該做什麼。而事實是，你付出了最寶貴的時間與生命，卻只像是看遊戲實況一般，你並沒有真的去玩。 ### 四、建立個人價值體系 一個遊戲就是一個價值體系，找到適合自己的價值體系非常重要。你可以頻繁換桌，這邊玩玩、那邊看看，但這過程會消耗有限的人生。 同時，你也可以一次玩多種遊戲（多元價值體系），成為「多邊形戰士」自成一格，玩出獨創的玩法。但對多數人來說，越專注地打造一種價值體系，就越有機會成為該遊戲的專家，畢竟時間與注意力是有限的資源。 重要原則：不要與他人比較，不要用別人的遊戲規則來衡量自己。只有你知道自己遊戲的進度條，因為別人的玩法不一定會讓你感到快樂與滿足。 ### 五、雙層遊戲結構：有限賽局 vs 無限賽局 #### **階段性策略 = 有限賽局** 每個人生階段，都可以拆分為一個個關鍵的有限賽局（例如：求學階段、找工作、創業、關係） - 有明確的規則、時間框架、成敗標準 - 每次出手都有學習價值，即使失敗也無妨 - 越早出手，剩餘嘗試次數越多 #### **人生整體 = 無限賽局** - 目標是「持續參與」而非「贏得勝利」 - 沒有最終的遊戲結束（除了生命終點） - 重點是累積經驗、建立關係、持續成長、享受旅途 - 避免做出不可逆的 All-in 導致無法對沖風險 #### 自我提問 - 我當下處於哪個有限賽局？ - 這個賽局裡我還有幾次出手機會？ - 失敗的最壞結果是什麼？不出手的機會成本是什麼？ - 我是否有活在當下，並且享受這場遊戲？ ## 反思：這套體系的盲點 ### 起手條件的差異 有些人在起手時就面臨了更多的困難與障礙，光是能夠有餘裕將人生遊戲化類比、專注於其中有趣的部分，本身就已經一種優勢與特權 (privileged)。 我必須更加的珍惜現有的資源與關係，不能視為理所當然，避免因此產生自負的心態與傲慢。 ### 需要小心的部分 1. 過度簡化風險 - 人生不只是數據化的策略遊戲，還有很多無法量化的元素：愛、意義、精神需求。這套框架有些功利導向，可能會讓人忽略這些重要的面向。 2. 加劇焦慮 - 對於資源有限的人，這套框架可能會加重「我玩不起好遊戲」的挫折感，而非帶來突破認知的解放感。 3. 運氣與不可控因素被低估 - 真實人生充滿著意外和不可控因素，純粹用「選擇遊戲」的邏輯可能會讓人對過程的成敗過度自責。 ### 換個角度思考 當 NPC 其實很舒服：不用做困難的決定，不用承擔過多的責任。很多人即使有機會覺醒，也有足夠能力與資源掌握生命的主控權，仍選擇回到 NPC 狀態。這沒有對錯，只是不同的生活選擇。 一旦意識到自己可以選擇，就再也無法無知地快樂了。所有的成功與失敗都得自己承擔，無法推卸責任。這也是為什麼有些人抗拒成長。 從更宏觀的角度來看，這個社會系統確實需要大量的 NPC 來維持運作。很多人在自己的層級中感覺有主控權，但在更高層級的人眼中也仍是 NPC，我自己又何嘗不是如此？我在某些人眼裡可能也像隻可愛的猴子。 因此，系統中存在許多隱形的力量來維持現狀，阻止人們過度思考。有時候，最大的阻力其實來自我們自己——我們寧願活在舒適的假象中，也不願面對選擇的重量。 ## 結語 在撰寫這套人生遊戲化思維的反思章節時，我更深刻理解到這套體系確實有其局限性，也有許多不完整之處。 對我來說，它能夠幫助我釐清自身在每個階段的選擇與責任。同時我也需要自我提醒，保持開放的心態來持續修正對世界的理解，讓這套體系更加完善，而非成為束縛思考的框架。 下一篇文章，我想深入探討在這個遊戲化的世界中，不只是「玩樂」的那些面向，更多的是遊戲中不可避免的「痛苦」。 ### 起點 —— 《創作與表達》 URL: https://www.davehuang.io/start/ Last updated: 2026-03-13T17:15:53.000Z 今年，我報名了**書店老闆**開設的《創作與表達》課程。書店老闆是我長期訂閱的電子報作者，他獨特的創作視角和深刻洞察讓我每週都期待著他的文字，也曾無數次被他的創作能力與生命故事感動。在文章中我會以「老闆」稱呼這位老師。 課程開始前，老闆給了我們四個問題作為自我介紹的準備： > 我是誰？ > 我的觀眾面臨什麼問題？ > 我如何解決這些問題？ > 因為我，觀眾產生什麼改變？ 這些課前提問，對於正準備走上獨立創業道路的我來說，是非常關鍵的自我提問。 我為什麼要來上這門課？ 還記得第一份工作的面試中，我的主管曾問我，為什麼想寫軟體？我回答： 「因為這是最好掌控的介質，我可以在這個可控的環境內高效率的創造價值」 從此，我就持續在軟體的世界中進行創作，為不同公司、不同團隊，在世界上帶來價值與影響力。而今年，我決定透過自己的產品為世界創造價值，換取我嚮往的生活型態。 然而，在啟動的路上我內心也深知，光靠產品本身是不夠的 —— 我需要各層階的漏斗來讓人看到我的成品。但這也是我自身的矛盾所在： 我內心頑固的認為，只要產品夠好，它自然也能擴散。 我渴望透過獨立創業獲得抽離群眾的自由，也不願受到我無法認可的人的關注，因為這會損耗我的精神，但我也明白，這些個人的偏執對於建立良好的商業模式和產品本身毫無助益。也因為這些 [交錯動機](https://www.youtube.com/watch?v=yVcKshcwM7s&ref=davehuang.io)，以及對自己的高標準要求，我今年特別常掉入 [burnout](https://drawwow.com/burnout/?ref=davehuang.io) 的死循環。 > 當你對他人不感到好奇，別人也就不會對你感到好奇 老闆的這句話點醒了我，是時候該面對這些內在矛盾，將觸角向外延伸。因此我來到這門課：我想學習如何讓自己的產品被更多人看見，同時，在這個過程中重拾創作本身的樂趣，就好像兒時純粹的玩著樂高積木那樣。 ## 預期與獲得 這堂課有許多的地方與我期待有著很大落差，同時，也有很多環節遠遠超出了我的期待。我原以為這是一門以工具傳授為導向的方法論課程，但其實更多的是透過老闆對創作本質的獨特視角進行解構與重塑。 老闆用他自己的方式，將一路走來的創作歷程進行拆解，分享著他走過的旅程、看過的風景、踩過的坑，與犯過的錯。這不是教科書式的理論傳授，而是讓我們進入思辨，與同組的組員透過各自的視角去消化這些知識與素材。 而我看到的另一個面向是，老闆對於刻意留白的掌握與運用。他明白，有些錯是必需要親自經歷的，有些領悟是無法被直接傳授的。這種教學智慧，讓我們有機會在安全的框架內犯那些該犯的錯。（這心思讓我想到藤原文太，他知道，拓海若要往下一個層次邁進，他得先“輸”。最好的老師不是告訴你所有答案的人，而是有耐心等你完賽，在關鍵彎道指引你找到答案。） ![](https://www.davehuang.io/content/images/2025/09/image.png) 藤原文太知道，若拓海要往下一個層次邁進，他得先"輸" ## 台上發光的瞬間 課程的第二天，老闆安排了實作演練環節，每位同學都要上台進行創作演出。這些演出不僅展現了每個人獨特的創作風格，更讓我看到了不同的表達方式和人生故事。以下是幾位讓我印象深刻的同學： ### 大喻 我認為大喻是一個非常有個人特色的創作者，光是看到他的簡報我就知道他有著自己的一套美學，不論是在文字呈現或是對作品視角的切入點，雖然 Marlon 老師覺得他沒特別選字體這件事情可以再優化，但我覺得在充滿各種搶奪關注與複雜視覺體驗的網路世界中，他選的這種原生字體反而更顯得不同（我原以為他是刻意的。可能因為我每天看著前沿的網頁型態與各種視覺設計，看了這種極簡風反而覺得很純粹，讓我專注在內容），他的主觀敘事與人生經驗帶來的故事，我覺得有著非常大的展開空間與可能性。另一點我很欣賞的是他的用字與選詞，讓我感受到一種滂薄、宏大的敘事感，他創造出了一個獨特的世界觀，我很期待拜讀他的作品。 ### 阿佑 我本來就很期待阿佑，因為他很有風格。他在台上的自在感，與令人充滿期待的題材鉤子，都有勾起我想要再深入往下得到答案的一種好奇心，而這好奇心探索的過程，透過他的呈現方式，有著一種詼諧與自信的基調，娛樂性與深度人生體驗的交互呈現，在表演的過程讓我更加的瞭解他這個人，獨特的敘事角度也讓我覺得很新奇有喜感，想繼續向下挖掘。（第二天的午餐一邊看著他 [YT](https://www.youtube.com/watch?v=Z1FtpP6xpA0&ref=davehuang.io) 介紹著無雙，一邊大口吃著鰻魚，真爽，我以前都先把織田信長練到滿等） ![](https://www.davehuang.io/content/images/2025/09/IMG_8626.png) 早上表演完，吃著鰻魚飯幫自己慶祝 ### 隊長 隊長是個很棒的領導人物，有他在的場子我都覺得很可靠，他總讓我想起 [諾曼第大空降](https://zh.wikipedia.org/zh-tw/%E5%85%84%E5%BC%9F%E8%BF%9E?ref=davehuang.io) 的 E連長官，是我會想在吃完一整盤義大利麵後快要撐到吐了，還被拉去跑山路時，想跟在後面跑並且大聲唱軍歌的隊長。透過他帶來的故事，除了娛樂性以外，亦看見他有著一套自身長期累積下來的處世哲學與觀人智慧，恰到好處的語速與互動，讓人想持續地挖掘出更多故事並向他學習。同時，藉由他的經驗，我有機會窺探一個不曾體驗過的世界、另一種職場的處事法則。身處權力意識與階級體現比任何環境更加明確，同時又有著抽象深水區的體系，完全就是一個權謀與自制力的極限修羅場。 ### George George 帶給了我突破我認知的演說以及文字運用技巧，同時也改變了我對他的印象。簡報的俐落與明確表述，搭配恰到好處的類比與自創的優美文句，都讓我震撼，我可以感受到他平時對“美”的積累，所以我最後票選投給了他。 其實從第一天的課程開始我就一直在心中思索，在AI世代，”文本“真的有這麼重要嗎? 這些傳統的純文字渠道已被各種搶奪關注力社群軟體與各種腥羶色暴力政治敘事打得七葷八素，這樣子對文字的追求是否像是幕末的武士一樣，遲遲不肯放下武士刀？但George 的演出打了我一個大大的巴掌，因為我確實是被他的文字感動到了，我覺得命題不應是文本的重要性，反而是如何讓好的文本“被看到”。他的演出，提醒了我蠻多以前曾體會，但後續漸忘的執行細節。 透過老闆對他的點評，我才突然發現，「對耶，其實他沒有提到太多的自己」，雖沒有帶出個人的故事性，但我覺得那也無妨，因為他作品中確實有散發出一種孤獨的氣息，就像森山大道所拍出的照片一般；他的演出，也引發我對福山雅治的興趣，去查了他的背景與生平，知道了他有多神多屌、多有故事性。（他一開始說，要開始聽一段福山雅治的歌，我以為要聽原版音樂，結果他拿起麥克風一陣狂唱，我驚呆了！記憶猶新） ### 老闆的即興炫技 看完 George 的演出，我猜老闆是手癢了，武士刀扛不住了彈出刀鞘。老闆說了一段年少時期創業的過往（我一直以來最愛聽的就是老闆以前創業時期的故事，有點像小時候躺在阿公肚子上，聽他講述著童年的那種感覺），那年少有成的自信，對未來充滿期待同時又有種面對未知恐懼的酸澀，以及那邁向冒險旅途的期待感，搭配著費玉清的[音樂](https://www.youtube.com/watch?v=ttBJAaSRr9M&ref=davehuang.io)（我以前一直覺得這是老人在聽的我聽不太懂，但這次真的覺得很好聽，也讓我改觀，可能因為我也老了），我再度覺得，薑還是老的辣，能把這個生命片段的小品故事講得如此有趣又充滿詩意，太屌了。 #### 老闆的強項 - 讀取速度非常快、容量巨大的 SSD - 非常強大的資料庫索引 [DB indexing](https://zh.wikipedia.org/zh-tw/%E6%95%B0%E6%8D%AE%E5%BA%93%E7%B4%A2%E5%BC%95?ref=davehuang.io)，迅速在腦中找到可以提昇連結性的關鍵素材 - 獨一無二且深厚的生命軌跡 - (2025/9/10 更) 多執行緒，背景有多個反覆優化的背景工具程式同時在跑 ### 陳毅 陳毅上台前卡關投影的設置，我一邊幫著他，一邊感受到他有多希望能夠好好的呈現他所準備的內容，可惜 MSI 耍雷，我以前簡報時也被 MSI 搞過...但當他成功弄好後，一登台，開始講到 [陳吉思汗IV](https://zh.wikipedia.org/zh-tw/%E6%88%90%E5%90%89%E6%80%9D%E6%B1%97%5F%E8%92%BC%E7%8B%BC%E8%88%87%E7%99%BD%E9%B9%BFIV?ref=davehuang.io) 時，眼睛噴出了熱血的光線，我就知道： "It's his show time" 他講述著自己是如何被遊戲設定所吸引，進而一頭跳進一個他深感興趣的領域，他透過新習得的工具 prompt 出了許多有著惡趣味的素材，這些是我從來不可能讓 AI 吐出來的內容，都讓我覺得虧你想得到！同時他一邊卡著關一邊切換著電腦視窗時的那種很 real 的實境感，也讓我想起來許多我願意抖內支持的早期實況主的那種感覺，我給他的回饋是我覺得他真的很有潛力，但確實如老闆所說，他若真要往那個主題做，路上是充滿許多挑戰的，不論是工具使用、素材取得與市場突破，都會是高難度挑戰。 ### Marlon 老師 Marlon 老師的課末分享，成為我這次台中之旅找回生命熱情的關鍵一推。 來台中前，我被工作與獨立創業的雙重壓力夾殺推向倦怠漩渦，雖然覺得就快要調整好這股情緒了，但又覺得哪邊怪怪的、不舒坦，原以為要背負著這股情緒回到台北，慢慢等時間消化。但看著 Marlon 老師分享著他如何拓展生命體驗，擁抱不確定性、珍惜各種可能性的實踐精神，還有每張自拍照中那純粹的笑容，我深受感動，也徹底被點醒。 生命的「活法」本充滿無限可能，並沒有所謂的「最佳化」或「最大化」。 專注於當下，持續往前，用自身步調欣賞著沿途的風景，為各階段身旁的旅伴帶來價值，光是這樣，就已經很棒了。 ### 共通點與不同處 #### 這些表演觸動到我的共通點： 1. 生命體驗（軌跡） 2. Realness 3. Authenticity #### 不同之處： 1. 語言 2. 視角 #### 自我提問： 如果隨機切換表演者外貌 (包含肢體語言和潛溝通) 這些演說是否帶來不同感受? 加上我們這幾天緊密相處、互動協作，這些印象的加乘是否影響對一個人作品的感知? ## 結語 下課後，坐在從台中開往台北的火車上，心中湧起一股久違的腎上腺素，像是一種直面挑戰的刺激愉悅感。 這堂課讓我重新思考創作的本質。 寫軟體的這些年，我很清楚、也早已習慣不去追求完美，因為我知道設計本就是一段不斷修正與迭代的過程，但寫著寫著，我常忘記的是，要試著去享受這段旅程。 ![](https://www.davehuang.io/content/images/2025/09/IMG_8564.png) 這幾天就窩在這個飯店房間角落工作、寫作與思考，我很愛這個房間 ### 後記 1 - 獎品 我們這隊拿到了第一天課的積分第一名，獎品是海賊王的盲盒，而我抽到了卡普，突然覺得...書店老闆其實跟卡普蠻像的，以後寫作時可以放在電腦前當作一個監督者看著我，不認真就會被鐵拳。 ![](https://www.davehuang.io/content/images/2025/09/IMG_8651.png) 如同瑋晟教的，這時候要選側光 ### 後記 2 - 數據 Day 1 同學對我的評語 - 自信: 10/10 - 距離感: 3/10 - 知道自己在做什麼、有想法: 3/10 - **平均分數: 3.3/5** Day 2 同學對我的評語 - 知道自己在做什麼、有想法: 5/10 - 作品排列組合可優化、有斷聯: 4/10 - 過於抽象、部分內容不明白: 3/10 - **平均分數: 3.5/5**