Life OS開發手記：我用8天搭了一個「人生操作系統」，好多bug呀~2026踐行「每週工作4小時」
整理版優先睇
用AI Agent將《每週工作4小時》落地為個人操作系統，關鍵在於解決具體痛點而非堆砌功能
呢篇文章係作者分享佢用8日時間，透過AI Agent親手搭建一個「人生操作系統」（Life OS）嘅經歷。作者三年前讀咗《每週工作4小時》呢本書，當時覺得入面嘅DEAL方法論——定義、精簡、自動化、解放——好正，但一直唔知點樣落手實踐，因為書入面講嘅「外包」同「自動化」都需要團隊支援，對一個人嚟講好難做到。
今年AI Agent出現，作者突然諗通咗：書講嘅「外包」可以外包俾Agent，而「自動化」就係用AI去做系統嘅執行引擎。佢嘅核心問題係：點樣將一本書嘅理念變成一個每日用得爽嘅工具？佢最初犯咗個錯，就係將書入面嘅136個技能全部塞入系統，結果整咗個「電子書閲讀器」出嚟，實際用唔到。後來佢停低問自己「每日最煩乜嘢」，聚焦喺會議記錄、靈感管理、客戶資訊呢幾個痛點，先開始砌出可用嘅系統。
由V1到V3，作者不斷迭代，最終整咗7個模塊（會議中心、文章工坊、陪跑中心、記憶系統、計劃系統、項目看板、中控台），用20個AI Agent去自動處理任務。佢嘅結論係：好的方法論需要一個執行引擎，以前係書，而家係AI應用。完成比完美更重要，唔好等系統完美先用，而係邊用邊改。成個過程用咗HappyCapy呢個平台開發，因為支援Opus 4.6同手機操作，降低咗門檻。
- AI Agent可以作為《每週工作4小時》方法論嘅執行引擎，將「外包」同「自動化」真正落地。
- 最初錯誤假設係將一堆技能搬入系統，正確做法係先解決最頭痛嘅幾個痛點。
- 從V1到V3唔係計劃出嚟，而係喺「用唔起」嘅挫敗感中「長」出來嘅，關鍵係讓AI能力「活」喺系統入面。
- MVP唔需要完美，有一兩個功能真正可用就夠；邊用邊改比追求100分更有價值。
- 具體可行動點：用HappyCapy等低門檻工具快速搭建原型，聚焦核心痛點，先讓系統每日為你省30分鐘。
HappyCapy
AI應用開發平台，支援Opus 4.6，手機端操作，快速搭建前後端。作者用呢個平台8日內完成Life OS V3。
點解要用AI Agent重新理解《每週工作4小時》？
三年前讀咗《每週工作4小時》，覺得DEAL方法論好正，但一直唔知點樣實踐。書講嘅「外包」同「自動化」對一個人嚟講好似好遙遠，結果本書放咗喺書架三年。
更重要嘅係，作者將自己視為「一人公司」，需要一個類似ERP嘅個人操作系統，而Agent就係執行引擎。呢個認知改變咗成個方向。
V1嘅錯誤：將136個技能塞入系統，結果變成電子書閲讀器
作者用pdf2skills將《每週工作4小時》提取出136個技能，直接掉俾HappyCapy話：「幫我做一個人生操作系統，將呢啲技能全部塞入去。」結果V1整出嚟嘅嘢似個電子書閲讀器，實際用唔到。
關鍵問題係：呢136個技能係Tim Ferriss嘅經驗，唔係作者嘅痛點。
作者後來意識到：「我需要的唔係成功方法論嘅電子版，而係一個能接住我手頭呢堆爛攤子嘅工具。」佢停低問自己每日最煩嘅事，列咗幾項：會議記錄散亂、靈感無處記、客戶資訊分散、寫文素材零碎。呢啲先係真正嘅痛點。
從V2到V3：系統係「長」出來嘅，唔係計劃出嚟
V2加咗Dashboard、看板、知識庫，開始有系統感覺，但數據塞埋一齊越用越亂。於是推倒重來，V3將單體Store拆成7個獨立模塊，每個模塊對應一個具體痛點。
- 會議中心：錄音轉文字 + AI提取行動項，解決會議記錄散亂
- 文章工坊：素材聚合 + 快速組裝，解決內容素材管理
- 陪跑中心：統一客戶視圖 + 進度追蹤，解決客戶資訊混亂
- 記憶系統：自動關聯 + 智能檢索，解決知識碎片化
- 計劃系統：優先級排序 + 時間分配，解決每日任務規劃
- 項目看板：可視化看板 + 里程碑，解決項目進度跟蹤
- 中控台：統一入口 + 關鍵指標，解決資訊分散
關鍵轉變：讓AI能力真正「活」喺系統入面，而唔係寫死嘅規則。
例如會議中心粘貼一段轉錄，系統會調用AI理解語義，判斷行動項、決策、有價值觀點，然後自動推送到計劃系統，更新中控台。作者一開始唔捨得用token，後來發現咁先係真·自動化。
MVP心法：完成比完美重要，先要「用得落手」
作者一度陷入完美主義，功能越做越多，調試時間越嚟越長。佢問自己：「如果系統自己都唔想每日打開，咁再完美有咩用？」於是決定發佈一個60分版本，邊用邊改。
成個開發週期8日，技術選型係純前端單文件HTML，無後端無數據庫，因為夠用就好。呢個轉變讓作者真正開始用系統，而唔係只係整系統。
而家只係開始：AI時代嘅「每週工作4小時」
8日做出嚟嘅Life OS V3有7大模塊、20個AI Agent、136項技能，但作者話只係比MVP大少少。仲有好多功能未做，例如AI消費統計、收入追蹤、語音輸入等。
最重要嘅係：佢已經喺用，每日幫佢慳30分鐘。
作者回顧《每週工作4小時》嘅DEAL框架，而家終於可以透過AI Agent落地：定義固化喺模塊設計、精簡靠系統保留最核心功能、自動化由AI喺模塊間流轉、解放係真係每日少花30分鐘處理雜事。
三年前讀咗本書覺得幾好，三年後用 AI 將佢變成一個每日都用緊嘅系統。
Part 1: 起因——三年前種草，今年重啟
三年前，我讀咗《每週工作 4 小時》。
嗰本書令我種草咗。Tim Ferriss 講嘅 DEAL 方法論——定義、精簡、自動化、解放——我甚至定咗個計劃：我都要做到每週淨係工作 4 小時。
但冷靜落嚟諗下，要做到真係唔容易：
書入面話「外包」，請助理幫你處理事務。但我嘅工作——專業判斷、內容創作、深度溝通——呢啲助理真係做得嚟咩？
書入面話「自動化」，建立系統令啲嘢自動轉。但具體點樣建立？用咩工具？我完全冇頭緒。
書入面講嘅好多方法，感覺都係大公司或者團隊先玩到，我一個人點搞？
講白咗，道理我都明，但唔知點做。
於是嗰本書就放喺書架上面，三年冇再揭開。
轉機發生喺今年。
偶然間我又翻到呢本書，嗰陣時 Agent 已經出現咗。我突然意識到：
書入面講嘅「外包」，喺 AI 時代唔係外包畀人，而係外包畀 Agent。
會議記錄？Agent 可以轉錄、可以提取、可以分類
內容創作？Agent 可以整理素材、可以生成初稿、可以優化文案
資訊管理？Agent 可以追蹤進度、可以提醒跟進、可以生成報告
三年前話「助理做唔到」嘅專業工作，Agent 好似真係得。
更關鍵嘅係，我突然諗通咗一件事：如果我係一間「一人公司」，噉我需要一個屬於自己嘅 ERP 系統。 唔係 Notion 嗰啲通用工具拼湊出嚟，而係圍繞我嘅工作流程——由會議記錄到內容創作，由資訊管理到知識沉澱——度身訂造嘅操作系統。
而 Agent，就係呢個系統嘅執行引擎。
💡 關鍵認知
「成為新貴並唔係更巧妙地工作，而係要建立一個可以取代自己嘅體系。」
—— Tim Ferriss《每週工作 4 小時》
三年前讀到呢句，我覺得係雞湯。
三年後重讀，我發現——
欠嘅只係一個執行引擎。
以前冇，依家有咗。就係 Agent。
Part 2:「我唔知可以做成點樣」—— 行冤枉路嘅過程
諗法有咗，但具體點做？老實講，我完全冇譜。
「人生系統」呢四個字聽落好型，但到底係咩？包括啲咩？用咩技術實現？我一頭霧水。
呢個時候我諗起《每週工作 4 小時》。既然要基於 DEAL 方法論，不如將本書嘅內容結構化先。於是我就用 pdf2skills 成本書提取一次，提煉出 136 個可執行技能。
攞到呢 136 個技能，我好興奮，直接將清單掉畀 HappyCapy：「幫我做一個人生操作系統，將呢啲技能全部塞入去。」
結果你估下點？
V1 做出嚟嘅嘢，似個「電子書閲讀器」——136 個技能整整齊齊咁擺喺度，每個都有解釋、有模擬練習，睇落幾似樣。但我實際用起嚟呢？根本用唔落去。
我後來先諗通：
呢 136 個技能係 Tim Ferriss 嘅經驗，唔係我嘅痛點。
講白啲，我一開始嘅假設就錯咗。我以為將呢啲「成功方法」搬入系統，就可以改變工作方式。但實際上，當面對一堆會議記錄、零散靈感、客戶資訊時，一個「點樣外包生活」嘅技能根本幫唔到手。
嗰晚夜晚 11 點，我望住嗰個「電子書閲讀器」噉樣嘅 V1 界面，突然意識到一個殘酷嘅事實：
我花咗幾個鐘將 136 個技能整整齊齊咁搬入系統。但當我真正開一個會議錄音，面對一堆亂曬嘅轉錄文字時——我根本唔知要撳邊個技能。
「點樣外包生活」？「點樣建立被動收入」？
呢啲標題喺嗰一刻睇落都似係嘲諷。
我需要嘅唔係「成功方法論嘅電子版」，而係一個可以接住我手頭呢堆爛攤子嘅工具。
關鍵轉折來自一個問題。
我停低問自己：「我到底每日最煩嘅係咩？」
列咗個清單：
列完我突然醒覺：
❌ 錯誤假設
將 136 個技能搬入系統 = 改變工作方式
✅ 正確認知
解決最頭痛嘅幾個問題 = 可用嘅系統
《每週工作 4 小時》入面話：「所有嘅重大事情，刻意嘅安排通常會搞砸。」
我之前就係諗得太宏大，想將書裏面嘅內容全部塞入去，結果乜都做唔成。
揾到切入點，事情先開始變得唔同。
Part 3: 由 V1 到 V3 —— 唔係計劃好，而係「生」出嚟
明確咗要解決嘅幾個痛點，我開始重新設計。
V2 版本，我令 HappyCapy 加咗 Dashboard、看板、知識庫。開始有「系統」嘅感覺，但用咗幾日就發現新問題——數據全部塞喺一個地方，越用越亂。就好似將所有嘢掉曬入一個櫃桶，雖然喺曬度，但揾起嚟更麻煩。
呢個時候我意識到，要推倒重來。
V3 版本，我做咗一個關鍵改變：由單體 Store 拆成 7 個獨立模組，每個解決一個具體痛點：
| 會議中心 | ||
| 文章工坊 | ||
| 陪跑中心 | ||
| 記憶系統 | ||
| 計劃系統 | ||
| 項目看板 | ||
| 中控台 |
呢個過程唔係一開始就規劃好嘅。
V1 到 V3 唔係計劃出嚟，而係由「用唔起」嘅挫敗感裏面生出來嘅。
舉個例子。會議記錄模組，一開始我只係想揾個地方存錄音轉文字。用起嚟先發現，存咗入去只係第一步，更重要嘅係提取關鍵資訊——摘要、決策、行動項。
所以又加咗 AI 結構化：貼上去，自動提取，直接轉任務。
呢個先叫「可用」。
💥 火花時刻：終於捨得讓 AI 真正「活」喺系統裏面
開發到呢度，我突然意識到一件事：
今次終於唔係「寫死嘅規則」，而係真正調用 AI 能力嘅應用。
我一開始做 Life OS 時，用嘅係寫死嘅規則。
但咁做有個問題：規則永遠覆蓋唔曬，而且好硬。
真正嘅轉折發生喺我決定：讓 AI 能力真正「活」喺系統入面。
當我喺會議中心貼一段轉錄文字，系統唔係用規則嚟夾，而係：
調用 AI 理解呢段內容嘅語義
AI 判斷邊啲係行動項、邊啲係決策、邊啲係有價值嘅觀點
自動將行動項推送到計劃系統
如果提到關鍵資訊，同步更新到相關模組
中控台實時更新今日待辦數量
我只做咗一個動作（貼上），AI 自己判斷、自己調度、自己完成後續處理。
老實講，一開始我係唔捨得花 token 嘅（我意思係喺非 coding plan 嘅場景下，覺得有啲難估計，coding plan 嘅場景下自然係使勁用，反正費用已經畀咗）。用到規則解決嘅就用規則。
但後來我發現：為咗令 Life OS 真正好用，讓 AI 能力喺系統內真正啟用係有必要嘅。
呢個先係 Tim Ferriss 講嘅「自動化」——唔係寫死一堆 if-else，而係讓 AI 成為系統嘅「大腦」，能理解、能判斷、能決策。
🛠️ 關於 HappyCapy：用 Opus 4.6 開發嘅體驗
講到開發工具，今次我用嘅係 HappyCapy。
揀佢嘅原因好簡單：支援 Opus 4.6，而且可以喺手機上操作。
用貴嘅模型確實有價值。
Opus 4.6 理解能力強，好多時候我只係需要描述需求，佢就可以生成比較接近預期嘅代碼。比用平價模型反覆除錯，最後仲要改，效率高好多。
而且唔依賴本地環境呢點好爽。有時喺街外面突然諗到要改個功能，拎部手機出嚟就可以操作，唔使等返屋企開電腦。
（畢竟A家咁容易封號，無憂暢用呢件事 Happycapy 做得確實唔錯，而且持續喺度疊代優化體驗，如果想體驗下可以用我嘅邀請連結。）
額外多送1000積分：https://happycapy.ai/signup?invite_ref=sauGFvha）
但問題亦都有嘅。
除錯呢件事，仲係一樣要花時間。有啲任務會自動啟動 Agent Team 去解決，速度確實快，但早期喺 sandbox 入面間中會卡住（後來呢類問題少咗好多）。
仲有就係改錯。就算係 Opus 模型，都有理解唔到位嘅時候。當然都可能係我自己反饋仲唔夠準確——畢竟我唔係專業開發，有時描述問題本身就唔夠清晰。
部署上網測試時，間中都會有 bug。例如本地預覽冇問題，部署後樣式錯亂，或者某個功能突然唔 work。
但整體嚟講，體驗都算唔錯。
尤其係前後端功能改起嚟嘅感覺。我今次構建嘅好多項目，主要依賴就係一本書（《每週工作 4 小時》），然後基於本書嘅內容去調整功能。HappyCapy 喺呢種「有明確參考資料」嘅場景下，表現幾好。
呢個都係點解我可以在 8 日內完成 Life OS V3——唔係因為我技術幾勁，而係工具降低咗門檻。
開發途中當然踩咗好多坑。
但最大嘅問題唔係技術細節，而係我太想完美。
功能越做越多，每次除錯花嘅時間亦越來越長。改一個細位，要測試七個模組；加一個功能，要考慮會唔會影響其他模組。
我發現自己陷入咗一個怪圈：
我越想將佢做完美，就越唔符合 MVP 嘅概念。
更可怕嘅係，我突然意識到：就算我最終做出呢個 Life OS，我可能都會因為佢太重、太複雜，而唔多用佢，令佢變成一個睇落好高檔嘅玩具。
呢個念頭令我停低諗咗好耐。
我點解要做呢個系統？
唔係為咗炫技，唔係為咗證明「我可以做出一個完美嘅產品」，而係為咗真係每日用佢，令工作變得更輕鬆。
如果一個系統自己都唔想每日打開，噉佢再完美都冇用。
所以我做咗一個決定：
截至出稿，佢都唔算係一個令我滿意嘅應用，但我覺得點都要發佈一個版本。
呢件事可能對我嚟講先係真正嘅啟動。
唔係等佢完美先用，而係先用起嚟，邊用邊改。
當我想令其他人都用得呢個系統嘅時候，發現配置都係一個大麻煩。唔同 AI 模型（kimi、glm、豆包）嘅調用方式唔同，參數都唔同。加咗配置功能後發現有 bug——因為 API 唔係一開始就寫死落去，而要根據唔同模型動態調整。
呢個功能目前仲唔好用。所以我決定：呢樣嘢暫時唔考慮對外，起碼要自己用一個月，確認真係好用先講。
畢竟，一個系統如果自己都用唔落去，俾人用估計 bug 更多，解釋成本都太高啦。
書入面講得啱：「所有嘅重大事情，刻意嘅安排通常會搞砸。」
完美主義係 MVP 嘅敵人。
發佈一個 60 分嘅版本，比永遠憋住一個 100 分嘅理想更有價值。
Part 4: 比 MVP 大少少，但核心係「用得」
8 日後，Life OS V3 成形咗。
數字上睇，佢有 7 大模組、20 個 AI Agent、136 項可學習技能。聽落都幾嚇人，但老實講，呢啲數字差啲害咗我。
因為我一開始嘅心態係錯嘅。
直到有一日我問自己：如果淨係可以留低一個功能，我會揀咩？
答案係會議記錄嘅處理——貼轉錄、AI 提取摘要、行動項自動轉任務、相關資訊同步。呢個係我最痛嘅痛點，亦係理論上嚟講，我每日必須要做嘅事。（有時就係冇辦法堅持）
於是我換咗一個思路：
唔再追求「完整」，而係追求「有一兩個功能真正用得」。
先將會議中心同計劃系統行得通，確保每日朝早我願意打開佢。其他模組可以粗糙啲，甚至暫時唔用，等核心功能穩定咗先慢慢打磨。
呢個轉變聽落簡單，但價值好大。
當我唔使同時盯住 7 個模組嘅測試時，精力終於可以集中喺「用」度——真係去處理會議記錄，真係去規劃每日任務，喺使用過程中發現問題、調整細節。
成個開發週期係 8 日。技術選型上，我選擇純前端單檔案 HTML，冇後端、冇數據庫。唔係因為我冇辦法諗得更仔細，而係因為——夠用就得，用得更加重要。
完成比完美更重要。
呢個令我重新理解咗咩叫「可用」。以前我覺得功能要多、界面要靚先叫「完善」。而家我知道：
「可用」嘅標準係你願意每日打開佢，就算佢得嗰一兩個功能。
就好似《每週工作 4 小時》入面講嘅：「關鍵係高效，而唔係忙碌。」
Part 5: 而家先啱啱開始
8 日做出嚟嘅嘢，只係比 MVP 大少少。
仲有好多未做：AI 消費統計（追蹤每個模組嘅調用成本）、收入追蹤（主動 vs 被動收入比例）、微習慣追蹤、語音輸入、日曆同步……清單可以列好長。
但呢啲唔重要。
重要嘅係佢已經喺用緊。
唔係等完美咗先用，而係邊用邊成長。就好似搭一個花園，唔係等設計完美咗先開始種，而係邊種邊睇佢慢慢變成點樣。
會議記錄嘅處理流程我只設計咗一次，但佢每日都幫我慳返 30 分鐘、自動調用 AI 能力完成後續任務。呢個先係 Tim Ferriss 講嘅「建立一個可以取代自己嘅體系」。
回頭睇呢 8 日，最大嘅收穫唔係技術能力，而係一個認知上嘅轉變：
好嘅方法論需要一個執行引擎。
以前係書，而家係 AI 應用。
《每週工作 4 小時》我三年前就讀咗，但直到今日，藉助 Agent 呢個執行引擎，先真正開始實踐。
以前啲「明咗但做唔到」嘅道理，而家終於有落地嘅可能：
「定義」：唔係寫喺筆記簿上，而係固化喺系統嘅模組設計入面
「精簡」：唔係靠意志力剋制，而係令系統淨係保留最核心嘅功能
「自動化」：唔係外包俾人，而係讓 AI 喺模組之間自動流轉
「解放」：唔係空想自由，而係真係每日少花 30 分鐘處理雜務
呢個就係 AI 時代嘅「每週工作 4 小時」——
唔係更努力咁工作，而係讓 AI 應用成為你嘅神經系統。
下一篇預告
我會講下點樣用 pdf2skills 將《每週工作 4 小時》變成 136 個可練習技能？DEAL 框架入面嘅每一條，又可以點樣拆解成可執行嘅步驟？
書入面有句話令我印象深刻：
「做唔現實嘅人比做現實嘅人更容易。非理性同唔現實嘅目標更容易實現——因為魚最少嘅地方，最有可能釣到味道鮮美嘅魚。」
我嘅「人生操作系統」先啱啱開始。
你嘅呢？
如果你都喺用 Agent 做類似嘅嘗試，或者對 Life OS 有興趣，歡迎嚟加我好友傾下，都想聽下你嘅睇法。我會喺之後嘅開發手記繼續分享Life OS疊代過程、maybe 開源部分模組（但好似唔知有冇必要，好似都唔複雜）。
畢竟，最好嘅系統唔係一個人閉門造車，而係一班人一齊生出來嘅。
不過我最大嘅目標其實係真係喺 3 年內逐步實現每週工作4小時。（例如先喺2026年底做到每週工作20小時啦，標準係噉樣工作就可以賺夠原本需要嘅錢，而其餘時間可以選擇工作或者唔工作，為熱愛而賺錢，而唔使單純為咗生活。）
過往精選文章：
Skill創作手記：我用1蚊將Mycc微信羣聊天記錄一鍵轉成靈感庫
Agent生產力系列：Obsidian+Claudian打造公眾號寫作系統
Skill 創作手記：我花24小時拆解聊天記錄，讓8個Agent話畀我知「我係邊個」
Skill 創作手記： 我將微信聊天記錄通過skill轉化成【可搜索嘅知識庫】
三年前讀了本書覺得不錯，三年後用 AI 把它變成了一個每天在用的系統。
Part 1: 起因——三年前的種草，今年的重啓
三年前，我讀了《每週工作 4 小時》。
那本書讓我種草了。Tim Ferriss 說的 DEAL 方法論——定義、精簡、自動化、解放——我甚至定下了一個計劃：我也要做到每週只工作 4 小時。
但冷靜下來想想，要達成真的不容易：
書裏說“外包”，請助理幫你處理事務。但我的工作——專業判斷、內容創作、深度溝通——這些助理真的能幹嗎？
書裏說“自動化”，建立系統讓事情自動運轉。但具體怎麼建？用什麼工具？我完全沒頭緒。
書裏說的很多方法，感覺都是大公司或者團隊才能玩的，我一個人怎麼搞？
說白了，道理我都懂，但不知道怎麼做。
於是那本書就放在書架上了，三年沒再翻開。
轉機發生在今年。
偶然間我又翻到了這本書，那時候 Agent 已經出現了。我突然意識到：
書裏說的“外包”，在 AI 時代不是外包給人，而是外包給 Agent。
會議記錄？Agent 能轉錄、能提取、能分類
內容創作？Agent 能整理素材、能生成初稿、能優化文案
信息管理？Agent 能追蹤進度、能提醒跟進、能生成報告
那些三年前“助理幹不了”的專業工作，Agent 好像真的可以。
更關鍵的是，我突然想明白了一件事：如果我是一家“一人公司”，那我需要一個屬於自己的 ERP 系統。 不是 Notion 那種通用工具的拼裝，而是圍繞我的工作流——從會議記錄到內容創作，從信息管理到知識沉澱——量身定製的操作系統。
而 Agent，就是這個系統的執行引擎。
💡 關鍵認知
“成為新貴並不只是更巧妙地工作，而是要建立一個可以替代自己的體系。”
—— Tim Ferriss《每週工作 4 小時》
三年前讀到這句話，我覺得是雞湯。
三年後重讀，我發現——
缺的只是一個執行引擎。
以前沒有，現在有了。那就是 Agent。
Part 2: 「我不知道能做成什麼樣」—— 走彎路的過程
想法有了，但具體怎麼做？說實話，我完全沒譜。
“人生系統”這四個字聽起來很酷，但到底是什麼？包括哪些東西？用什麼技術實現？我一頭霧水。
這時候我想到了《每週工作 4 小時》。既然要基於 DEAL 方法論，不如先把書裏的內容結構化。於是我用 pdf2skills 把整本書提取了一遍，提煉出 136 個可執行技能。
拿到這 136 個技能，我很興奮，直接把清單丟給 HappyCapy：“幫我做一個人生操作系統，把這些技能全部塞進去。”
結果你猜怎麼着？
V1 做出來的東西，像個“電子書閲讀器”——136 個技能整整齊齊陳列在那裏，每個都有解釋、有模擬練習，看着挺像那麼回事。但我實際用起來呢？根本用不下去。
我後來才想明白：
這 136 個技能是 Tim Ferriss 的經驗，不是我的痛點。
說白了，我一開始的假設就錯了。我以為把這些“成功方法”搬進系統裏，就能改變工作方式。但實際上，當面對一堆會議記錄、零散靈感、客戶信息時，一個“如何外包生活”的技能根本幫不上忙。
那天晚上 11 點，我盯着那個“電子書閲讀器”般的 V1 界面，突然意識到一個殘酷的事實：
我花了好幾個小時把 136 個技能整整齊齊地搬進了系統。但當我真正打開一個會議錄音，面對一堆散亂的轉錄文字時——我根本不知道該點哪個技能。
“如何外包生活”？“如何建立被動收入”？
這些標題在那一刻看起來都像是嘲諷。
我需要的不是“成功方法論的電子版”，而是一個能接住我手頭這堆爛攤子的工具。
關鍵轉折來自於一個問題。
我停下來問自己：“我到底每天最煩的是什麼？”
列了個清單：
列完我突然醒悟了：
❌ 錯誤假設
把 136 個技能搬進系統 = 改變工作方式
✅ 正確認知
解決最頭疼的幾個問題 = 可用的系統
《每週工作 4 小時》裏說：“所有的重大事情，刻意的安排通常會搞砸。”
我之前就是想得太宏大，想把書裏的內容全部塞進去，結果什麼都沒做成。
找到切入點，事情才開始變得不一樣。
Part 3: 從 V1 到 V3 —— 不是計劃好的，是“長”出來的
明確了要解決的幾個痛點，我開始重新設計。
V2 版本，我讓 HappyCapy 加了 Dashboard、看板、知識庫。開始有“系統”的感覺了，但用了幾天就發現新問題——數據全塞在一個地方，越用越亂。就像把所有東西扔進一個抽屜，雖然都在裏面，但找起來更費勁了。
這時候我意識到，得推倒重來。
V3 版本，我做了一個關鍵改變：從單體 Store 拆成 7 個獨立模塊，每個解決一個具體痛點：
| 會議中心 | ||
| 文章工坊 | ||
| 陪跑中心 | ||
| 記憶系統 | ||
| 計劃系統 | ||
| 項目看板 | ||
| 中控台 |
這個過程不是一開始就規劃好的。
V1 到 V3 不是計劃出來的，是從“用不起來”的挫敗感里長出來的。
舉個例子。會議記錄模塊，一開始我只是想找個地方存錄音轉文字。用起來才發現，存進去只是第一步，更重要的是提取關鍵信息——摘要、決策、行動項。
所以又加了 AI 結構化：粘貼進去，自動提取，直接轉任務。
這才是“可用”。
💥 火花時刻：終於捨得讓 AI 真正“活”在系統裏
開發到這裏，我突然意識到一件事：
這次終於不是“寫死的規則”，而是真正調用 AI 能力的應用。
我一開始做 Life OS 時，用的是寫死的規則。
但這樣做有個問題：規則永遠覆蓋不全，而且很僵硬。
真正的轉折發生在我決定：讓 AI 能力真正“活”在系統裏。
當我在會議中心粘貼一段轉錄文字，系統不是用規則匹配，而是：
調用 AI 理解這段內容的語義
AI 判斷哪些是行動項、哪些是決策、哪些是有價值的觀點
自動把行動項推送到計劃系統
如果提到了關鍵信息，同步更新到相關模塊
中控台實時更新今日待辦數量
我只做了一個動作（粘貼），AI 自己判斷、自己調度、自己完成後續處理。
說實話，一開始我是捨不得花 token 的（我意思是在非 coding plan 的場景下，覺得有點不好估計，coding plan 的場景下自然是使勁用，畢竟費用已經花出去了）。能用規則解決的就用規則。
但後來我發現：為了讓 Life OS 真正好用，讓 AI 能力在系統內真正啓用是有必要的。
這才是 Tim Ferriss 說的“自動化”——不是寫死一堆 if-else，而是讓 AI 成為系統的“大腦”，能理解、能判斷、能決策。
🛠️ 關於 HappyCapy：用 Opus 4.6 開發的體驗
說到開發工具，這次我用的是 HappyCapy。
選它的原因很簡單：支持 Opus 4.6，而且可以在手機上操作。
用貴的模型確實有價值。
Opus 4.6 理解能力強，很多時候我只需要描述需求，它就能生成比較接近預期的代碼。這比用便宜模型反覆調試，最後還是要改，效率高多了。
而且不依賴本地環境這點很爽。有時候在外面突然想到要改個功能，掏出手機就能操作，不用等回家開電腦。
（畢竟A家這麼容易封號，無憂暢用這件事Happycapy做得確實不錯，而且持續在迭代優化體驗，如果想體驗看看可以用我的邀請連結。
額外多送1000積分：https://happycapy.ai/signup?invite_ref=sauGFvha）
但問題也是有的。
調試這件事，還是一樣需要花時間。有些任務會自動啓用 Agent Team 去解決，速度確實快，但早期在 sandbox 內偶爾會卡住（後來這類問題少了很多）。
還有就是改錯。哪怕是 Opus 模型，也有理解不到位的時候。當然也可能是我自己反饋還不夠準確——畢竟我不是專業開發，有時候描述問題本身就不夠清晰。
部署上網測試時，偶爾也會有 bug。比如本地預覽沒問題，部署後樣式錯亂，或者某個功能突然不工作了。
但整體來說，體驗還是不錯的。
尤其是前後端功能改起來的體感。我這次構建的很多項目，主依賴就是一本書（《每週工作 4 小時》），然後基於書的內容去調整功能。HappyCapy 在這種“有明確參考資料”的場景下，表現挺好。
這也是為什麼我能在 8 天內完成 Life OS V3——不是因為我技術多強，而是工具降低了門檻。
開發中當然踩了很多坑。
但最大的問題不是技術細節，而是我太想完美了。
功能越做越多，每次調試花的時間也越來越長。改一個小地方，要測試七個模塊；加一個功能，要考慮會不會影響其他模塊。
我發現自己陷入了一個怪圈：
我越想把它做完美，就越不符合 MVP 的概念。
更可怕的是，我突然意識到：哪怕我最終做出這個 Life OS，我可能也會因為它太重、太複雜，而不怎麼使用，讓它變成一個看起來很高大上的玩具。
這個念頭讓我停下來想了很久。
我為什麼要做這個系統？
不是為了炫技，不是為了證明“我能做出一個完美的產品”，而是為了真的每天用它，讓工作變得更輕鬆。
如果一個系統自己都不想每天打開，那它再完美也沒用。
所以我做了一個決定：
截止出稿，它也不算是一個讓我滿意的應用，但我覺得總歸要發佈一版。
這件事可能對我來說才是真正的啓動。
不是等它完美了再用，而是先用起來，邊用邊改。
當我想讓別人也能用這個系統時，發現配置也是個大麻煩。不同的 AI 模型（kimi、glm、豆包）調用方式不一樣，參數也不一樣。加了配置功能後發現有 bug——因為 API 不是一開始就寫死進去的，而是要根據不同模型動態調整。
這個功能目前還不好用。所以我決定：這東西先不考慮對外，起碼得自己用一個月，確認真的好用再說。
畢竟，一個系統如果自己都用不下去，給別人用估計 bug 更多，解釋成本還是太高了。
書裏說得對：“所有的重大事情，刻意的安排通常會搞砸。”
完美主義是 MVP 的敵人。
發佈一個 60 分的版本，比永遠憋着一個 100 分的理想更有價值。
Part 4: 比 MVP 大一點點，但核心是「能用」
8 天后，Life OS V3 成型了。
數字上看，它有 7 大模塊、20 個 AI Agent、136 項可學習技能。聽起來挺唬人的，但說實話，這些數字差點害了我。
因為我一開始的心態是錯的。
直到有一天我問自己：如果只能留下一個功能，我會選什麼？
答案是會議記錄的處理——粘貼轉錄、AI 提取摘要、行動項自動轉任務、相關信息同步。這是我最痛的痛點，也是理論上來說，我每天必須做的事。（有時就是沒辦法堅持）
於是我換了一個思路：
不再追求“完整”，而是追求“有一兩個功能真正可用”。
先把會議中心和計劃系統跑通，確保每天早上我願意打開它。其他的模塊可以粗糙一點，甚至暫時不用，等核心功能穩定了再慢慢打磨。
這個轉變聽起來簡單，但價值很大。
當我不需要同時盯着 7 個模塊的測試時，精力終於能集中在“用”上——真的去處理會議記錄，真的去規劃每日任務，在使用過程中發現問題、調整細節。
整個開發週期是 8 天。技術選型上，我選擇純前端單文件 HTML，沒有後端、沒有數據庫。不是因為我沒辦法想得更細，而是因為——夠用就好，能用起來更重要。
完成比完美更重要。
這讓我重新理解了什麼叫“可用”。以前我覺得功能要多、界面要美才算“完善”。現在我知道：
“可用”的標準是你願意每天打開它，哪怕它只有一兩個功能。
就像《每週工作 4 小時》裏說的：“關鍵是高效，而不是忙碌。”
Part 5: 現在才剛開始
8 天做出來的東西，只是比 MVP 大一點點。
還有很多沒做的：AI 消費統計（追蹤每個模塊的調用成本）、收入追蹤（主動 vs 被動收入比例）、微習慣追蹤、語音輸入、日曆同步……清單可以列很長。
但這不重要。
重要的是它已經在用了。
不是等完美了才用，而是邊用邊長。就像搭一個花園，不是等設計完美了才開始種，而是邊種邊看它慢慢長成樣子。
會議記錄的處理流程我只設計了一次，但它每天都在幫我節省 30 分鐘、自動調用 AI 能力完成後續任務。這才是 Tim Ferriss 說的“建立一個可以替代自己的體系”。
回頭看這 8 天，最大的收穫不是技術能力，而是一個認知的轉變：
好的方法論需要一個執行引擎。
以前是書，現在是 AI 應用。
《每週工作 4 小時》我三年前就讀了，但直到今天，藉助 Agent 這個執行引擎，才真正開始踐行。
以前那些“懂了但做不到”的道理，現在終於有了落地的可能：
“定義”：不是寫在筆記本上，而是固化在系統的模塊設計裏
“精簡”：不是靠意志力剋制，而是讓系統只保留最核心的功能
“自動化”：不是外包給人，而是讓 AI 在模塊間自動流轉
“解放”：不是空想自由，而是真的每天少花 30 分鐘處理雜事
這就是 AI 時代的“每週工作 4 小時”——
不是更努力地工作，而是讓 AI 應用成為你的神經系統。
下一篇預告
我會聊聊如何用 pdf2skills 把《每週工作 4 小時》變成 136 個可練習技能？DEAL 框架裏的每一條，又可以怎麼拆解成可執行的步驟？
書裏有句話讓我印象深刻：
“做不現實的人比做現實的人更容易。非理性和不現實的目標更容易實現——因為魚最少的地方，最有可能釣到味道鮮美的魚。”
我的“人生操作系統”才剛開始。
你的呢？
如果你也在用 Agent 做類似的嘗試，或者對 Life OS 感興趣，歡迎來加我好友聊聊，也想聽聽你的看法。我會在後續的開發手記持續分享Life OS迭代過程、maybe開源部分模塊（但好像不知道有沒有必要，好像也不復雜）。
畢竟，最好的系統不是一個人閉門造車，而是一羣人一起長出來的。
不過我最大的目標其實是真的在3年內逐步實現每週工作4小時。（比如先在2026年底實現每週工作20小時吧，標準是這樣工作就能賺夠原來需要的錢，而其他時間可以選擇工作或不工作，為熱愛而賺錢，而無須單純為了生活。）
過往精選文章：
Skill創作手記：我用1塊錢把Mycc微信羣聊天記錄一鍵轉成靈感庫
Agent生產力系列：Obsidian+Claudian打造公眾號寫作系統
Skill 創作手記：我花24小時解構聊天記錄，讓8個Agent告訴我"我是誰"
Skill 創作手記： 我把微信聊天記錄通過skill轉化成【可搜索的知識庫】