Posts

建議永遠是「全部押上」。辭職、破釜沉舟、全力投入。但多數人做不到——而且多數做得到的人，在跳崖前，也還是需要那座橋。所以這裡是一套比較不浪漫、卻有用得多的系統：在晚上與週末、在時間的夾縫裡出貨，讓行事曆來扛大樑。 誠實的行事曆數學 副業不是死於缺少熱情。它死於缺少穩定出現的時間。所以第一步既殘酷又清楚：去數實際的小時數。 一份全職加上通勤，多數人平日只剩 1 到 2 個可用小時，週末每天 4 到 8 個。那不是「沒多少」。那是一週 10 到 15 個真實小時——綽綽有餘，但前提是你守住它。 敵人不是小時數太少。是那些沒被認領的小時，漏進滑手機、雜事、和「我明天再開始」。一個沒有名字的行事曆時段，就是一個會消失的時段。 所以：提前挑好你的小時、把它寫下來、把它當成一場不能取消的會議。兩個平日晚間加一個週末早晨，就是 8 到 12 個受保護的小時——一個認真的專案，用零錢般的時間跑起來。 精力優先於戰術 如果你到場時已經累了，那些小時幫不上忙。所以系統先最佳化精力，因為專注的一小時，勝過疲憊的三小時： 把難事放在場次的一開頭。 你坐下的那一瞬，就是大腦最清醒的那一瞬。把需要思考的任務放在那時，而不是那些深夜做起來也簡單的雜務。 先出貨，再拋光，永遠如此。 「完成」花的精力比「漂亮」少，而且它讓每週出貨系統繼續轉。完美主義，是兼職建造者真的付不起的一種精力稅。 守住連勝，而不是產出。 一場出貨了點小東西的兩小時，勝過一個燒掉你一個月的大週末。持續會複利，強度不會。 讓它活下去的那一條規則 系統以一種特定的方式失敗：先爆發，接著某一週被跳過，再來「我不做這個了」。對策是一條小到不可能違反的規則： 永遠不要讓空窗變成兩週。 一週不順很正常——人生難免。但當你連續錯過兩週，這個專案就統計上離死很近了，因為動能消失了，而重啟的罪惡感，比一場的成本還要重。所以規則不是「絕不失誤」。是「絕不連續失誤兩次」。那是一條你真的守得住的規則，也是副業跑好幾年、跟跑一個月之間的差別。 為什麼夾縫就夠了 兼職蓋東西違反直覺的真相是：這個限制本身是個功能。兼職建造者無法過度開發、無法鍍金、無法追逐每一個閃亮的功能——因為沒有那麼多小時。同樣一筆看起來像劣勢的預算，正悄悄地在強制執行那份自制（出小貨、常出貨、能用就停），那是全職建造者得靠意志力假裝出來的東西。 你的晚上與週末，不是你建造者職涯的起點——它們是肌肉真正成形的地方。新手入門會告訴你從哪裡開始；這套系統，是你在開始之後怎樣繼續走下去。而這份時間預算，也正是讓一人公司在它成為你唯一的公司之前，先變得可能的原因。 Sources Carta——《Solo Founders Report 2025》：獨立創辦公司有相當比例，起於創辦人另有正職時的副業；存活率偏好持續的兼職迭代，勝過全力衝刺。 標準的習慣養成證據（如「不要斷鏈」／絕不連錯兩次的框架），說明為何一條「最低保護間隔」的規則，長期下來勝過一條「強度」規則。

本能是等。做完它、拋光它、讓它在別人看到之前變「好」。問題是，「好」是一個沒有外人眼光就永遠追不到的移動目標——於是你關起門來一直磨，東西永遠不發布。 解方很彆扭，但它有效：刻意發布半成品，讓真實的回饋，幫你完成那些你一個人做不來的編輯。 為什麼「關門做到完成」是個陷阱 關起門來拋光有兩個隱藏成本，它們通常不會出現在任何時間表上： 你在跟自己來回改。 唯一在評斷作品的人，是離它最近的人——而那正是最不該評斷的人。你看不到讓陌生人困惑的地方，因為那些是你寫的；你聽不到被漏掉的步驟，因為你早就知道了。 新奇感衰減的時鐘在走。 一件東西擱置越久沒做完，你就越不想做完它。這就是第三週之牆最純粹的樣貌：出貨的能量，撐不過你執意保留在「開始」與「被看見」之間的距離。 「好到可以給人看」是一個真實的里程碑，而且它比「完成」早非常多到來。把達到它當成發布點，而不是中點。 回饋到底買到了什麼 當你給人看一件半成品，你拿到的回饋不是打分數——它是一張地圖。它告訴你三件你一個人永遠學不到的事： 哪個方向是錯的。 一個陌生人在十秒內看穿的死路，你會因為捨不得沉沒成本而辯護一整個月。 哪裡真的令人困惑。 你以為顯而易見的那一步，偏偏是沒人跟上的那一點。你自己永遠找不到——它對你是隱形的。 到底有沒有人想要。 最有價值的回饋，是沉默之後緊接著一句平淡的疑問：「這是要幹嘛？」這是最便宜的市場測試，代價只是一份半成品的草稿。 每一項都是一個在你掏光全部成本之前，先被挖出來的棄坑風險。這就是提早發布的整套經濟學：東西還便宜好改的時候，回饋才便宜。 精確的動作 挑最小的可發布切片。 不是功能，是切片——一個別人看了能反應的東西。一個 landing page、一個畫面、一段把論點講清楚的段落。 給一個真人看，不是丟進人群。 大聲向群眾發布是表演；給一個真的會回的人看才是編輯。一個誠實的讀者，勝過一百個沉默的曝光。 問一個具體的問題。 不要問「你覺得如何？」——那會招來客套。問「哪裡看不懂？」或「你會為這個付錢嗎？」尖銳的問題，得到尖銳的答案。 發布修改版，不是辯論。 拿走最重要的一條回饋、改進去、再發布一次。這個迴圈就是產品。 為什麼這贏過關門拋光 老實說：你發布的半成品，會比你想像中「完成的東西」差。那沒關係，因為想像中完成的東西有一個缺陷——它是想像的。真的東西，發布並反覆修改後，就存在了；而存在，才是複利賴以運轉的基礎（見每週出貨一個小東西的迴圈——這裡就是把那套系統，用在單次發布而不是每週節奏上）。 完美主義不是品質標準。它是偽裝成品質標準的拖延機制。提早發布、公開修改的建造者，不是比你粗心——他們只是在跑一個更緊的回饋迴圈，而贏的是這個迴圈。 這是每週出貨系統裡「先出貨、再修改」的那一半——也是餵養第三週之牆的那種完美主義的解藥。 Sources Carta——《Solo Founders Report 2025》：獨立創辦人的持續存在（新創的 36%），與更快的上市時間及迭代節奏呈正相關，而非更久的發布前拋光。 Ericsson——刻意練習文獻：技能來自頻繁、回饋豐富的迭代，而非長時間的私下打磨；提早發布就是把這套原則，套用在產品而非只有練習上。

助手回報成功了。工作「完成了」。接著你流程裡的下一步收到一片空，然後你花了整個晚上追這個謎團。 這裡有個大多數獨立開發者得付出代價才想通的解放性真相：你的代理人失敗幾乎從來不戲劇性——它們是機械性的，而機械性就意味著可以診斷。 問題只是少了一個右括號。解法只是讀了日誌裡的一個數字。這裡面沒有天才——而那正是好消息本身。 「無法理解」的失敗，是一則神話 當助手做錯事，直覺會讓我們去抓那些大解釋：模型產生幻覺、提示詞太模糊、模型「還不夠好」。於是你重寫提示詞、換模型、買更貴的級別。 與此同時，真正的失敗從頭到尾都躺在一行日誌裡，沒人去碰。 代理失敗的模式，絕大多數是那種不光彩的類型： 一個 JSON 欄位少了一個右括號，所以根本無效。 一個權限範圍少開了一層。 一個環境變數從頭到尾沒進到 shell。 一個檔案從錯誤的目錄讀取，所以它靜靜地拿到空字串。 一個「if」永遠不分支，因為條件拿字串去跟數字比較。 這些全都不需要更好的模型。其中任何一個，都對願意讀輸出、而不是讀摘要的人顯而易見。 為什麼人們跳過診斷 悲劇在於：診斷看起來像工作，感覺起來卻像什麼都沒做。讀日誌不是一個令人滿足的故事。「我換了更聰明的模型，然後就好了」是一個故事。「我找到一個漏掉的括號」不是——所以沒人拿它炫耀，而換模型的迷信就因此活了下來。 但那兩分鐘的日誌，是獨立團隊裡報酬率最高的習慣。這跟我們那篇談〈「完成」驗證儀式〉（done-is-a-claim）是同一套紀律——那篇靠強迫你「親眼見證輸出」來抓住失敗；這篇則是在失敗發生之後把它找出來。同時它也是〈認識你的代理模式〉（agent patterns）的另一面：模式告訴你失敗藏在哪裡，日誌告訴你究竟壞了什麼。 診斷紀律 當助手「離奇地失敗」，忍住把調查範圍放大的衝動。反過來，把它縮小。 先重現，再推論。 用完全相同的輸入重跑一次。如果每一次都以同樣的方式失敗，它就是確定性的——這代表問題在輸入、設定或接線，不在模型。非確定性（每次跑出不同的錯誤答案）才是模型本身、或它的 temperature 該被懷疑的唯一情況。 讀更原始的輸出，而不是診斷。 助手會樂於給你一個自信滿滿的、關於它自己失敗的解釋——而那個解釋往往是另一則穿上白袍的幻覺。跳過它。看它收到的輸入、它呼叫的工具、以及回傳的原始位元組。真相在 payload 裡，不在道歉裡。 找出錯得最小的那一個數字。 一個計數、一個 exit code、一個狀態、一個時間戳。找到現實與助手假設分岔的那一個點，你就找到了根本原因。代理的錯誤以驚人的規律性坍縮成一行。 修邊界，而不是修行為。 一旦看清，解法通常是一條規則或一道檢查，而不是更長的提示詞。「每次解析 JSON 並在格式錯誤時大聲失敗」，勝過「更努力地輸出合法 JSON」。你是在強化系統，不是在哀求它。 平凡失敗帶來的平靜 這種心態改變了獨立開發者的睡眠品質。「離奇」的失敗是焦慮——一個可能藏在任何地方的未知數。機械性的失敗是一個「已知的未知」，而已知的未知，是十分鐘的工作。 你不再伸手去換模型、而是伸手去讀日誌的那一天，你的助手就不再神秘，而是像你自己的程式碼一樣可讀。兩者的壞法一模一樣：一次一行，攤在眼前，等著你去讀。 你的助手沒有離奇地失敗。它以平凡的方式失敗。去讀那一行。 來源 Hacker News 與 Indie Hackers（2025–2026）上的多篇代理事故檢討。 反覆出現的特徵：代理回報成功，而底層動作卻以機械性的原因失敗（漏掉的括號、權限錯誤、空環境變數、錯誤的工作目錄）；這些失敗都是確定性的，並且在原始工具輸出裡可見，而不是在摘要裡。 代理可靠性與錯誤分類學文獻。 工具使用與反思的失敗模式（Zheng 等人，《AgentErrorTaxonomy》，arXiv:2509.25370）記錄了代理在被要求「自我回報」時如何捏造解釋；解藥是檢查實際執行的動作，而非代理的事後說法。 持續整合與可觀測性實務。 找出那一個分歧的計數、exit code 或狀態、作為根本原因錨點的紀律，正是 CI 系統所形式化的「找出錯的那一個數字」——日誌是真相，敘事是臆測。

模擬器說它沒問題。手機當機了。 那道落差——從綠燈測試到磚頭手機——正是「在裝置上運作的軟體」真正被打造出來的地方。而這道落差幾乎沒人寫：活下來的人忙著出貨沒空寫部落格，而寫「我打造了一個 AI 語音玩意」的人，多半停在那個只跑在模擬器上的 demo。 這篇談的是模擬器之所以騙你的那些具體、物理的原因，還有為什麼在真機上出貨，是一門跟「通過測試」不一樣的手藝。 第一個謊言：模擬器無法重現的當機 把語音介面接上一個語言模型很快。一個 WebSocket、一個開放協定、一點壓縮音訊，一個週末就有一個會說話的 demo。在模擬器上一切正常，因為模擬器不是手機，它是你的筆電穿著手機的戲服。 然後你把它裝到真機上、按下按鈕，跑出一個執行緒斷言的當機：一段本該在主執行緒執行的程式，卻在即時音訊回呼上被叫用。模擬器永遠不會丟出這個錯誤，因為它根本沒跑一顆帶有即時排程器的真實音訊引擎。 解法只有一行註記，把那段 closure 標記為可安全用於該執行緒。就一行。但找到它，需要去符號化裝置的當機日誌，一路讀到音訊 tap 內部的那個 messenger。一旦知道該往哪看，解法是簡單的；難的是知道怎麼看。而只有模擬器願意帶你去的地方，你才看得到。 第二個謊言：什麼都沒發生，也沒有報錯 接著是回音迴圈：助理一說話，它自己的輸出就被麥克風收走，再轉錄成胡言亂語。解法不是補丁，而是架構：麥克風與語音播放必須共用同一顆音訊引擎，並以伺服器的回合界線來把關。 「顯而易見」的設計——第二顆專屬引擎、乾淨的關注點分離——反而才是 bug。兩顆引擎爭奪同一個音訊 session，結果是回覆解碼了卻沒聲音，麥克風也聽不到接下來的追問。同時發生，而且完全不當機。 模擬器也無法重現這個，因為它不像真機的作業系統那樣強制執行音訊 session 的獨佔。症狀是「什麼都沒發生」——這是最難察覺的 bug，因為沒有錯誤訊息，只有一片沉默。 第三個謊言：本來好好的，突然就不行 接著是藍牙。接上無線耳機後，App 開始抖動、掉音；「解法」是一個能乾淨收音、卻把語音播得幾乎聽不見的音訊 session 模式。這種取捨只存在於有真實音訊路由的實體硬體上。然後是進入背景：切走、切回來，App 就「不再收聽」了，因為作業系統搶走了 session，並在 App 暫停時掛起 socket。每一種都是一類只會在真機上遇到的 bug，只要一次拆掉重連，就會在任何自動化執行裡隱形。 「在裝置上」作為一門手藝，到底意味什麼 教訓不是「模擬器沒用」。對那 90% 與硬體無關的邏輯，它不可或缺。真正的教訓是：那最後的 10%——碰觸即時音訊、藍牙、背景生命週期的部分——無法用代理來測試。 它們只能靠出貨到真機、讀當機日誌、並且相信硬體告訴你的話勝過測試套件宣稱的結果，才找得到。 這是在真機面前還能存活的紀律： 能 mock 的就 mock，不能的就出貨。 按住說話的狀態機，用 mock 的 socket 與麥克風做單元測試：十幾條測試，沒有真實音訊、沒有網路。音訊引擎本身無法 mock，所以它被出貨，然後被盯著看。 相信裝置日誌，不是測試執行。 裝置的當機日誌是地面真相；模擬器通過是假設。兩者相衝突時，永遠是裝置贏。 「在我機器上明明可以」是行動開發最危險的一句話。 你的機器是模擬器。顧客的機器是口袋裡那支手機，戴著耳機，正走進一個訊號死角。 對獨立開發者而言，真正重要的區別是：一個只跑在模擬器上的 demo，是假設；一個經得起真實硬體考驗的東西，是你可以推理的事實。那道落差，寬得足以成為「週末專案」與「值得出貨的東西」之間的全部差異。 來源 Apple 開發者文件，即時音訊。 安裝在音訊引擎上的 tap，是在即時音訊執行緒上被叫用，而非主執行緒；造成執行緒斷言當機的隔離假設，是並行的產物，在模擬器中不存在。 Apple 開發者文件，音訊 session 分類與模式。 Session 的擁有權在真機上是獨佔的；第二顆引擎在已被擁有的 session 上啟動，是有紀錄的「無聲或音訊飢餓」成因，也是「解碼了卻沒聲音」的根源。 開放原始碼的語音助理協定生態系。 成熟、MIT 授權的語音協定參考實作（不少擁有數萬顆 GitHub 星）展示了協定本身與一層免費的客戶端。客戶端本身沒有商業護城河；可遷移的技能是「在裝置上的加固」，不是協定。 這篇是〈完成了是一個主張〉（done-is-a-claim）的裝置端姊妹篇。後者談的是驗證儀式：相信自己的眼睛，勝過代理的一句話。那篇談的是你該信任誰；這篇談的是你該信任什麼：硬體，勝過模擬。

現在每個在 AI 上建造的人都在問同一個問題：用哪個模型？ 而這是錯的問題，因為模型是你的技術堆疊裡，唯一你既不擁有、也留不住、還被迫在更便宜的版本一出現就換掉的那一塊。 但你能擁有的，是包在它外面的每一樣東西。記憶。規則。決策邊界。那張「已經驗證過、永遠不必再驗證」的清單。 代理不是模型。記憶才是產品。 模型是租的，脈絡是你自己的 這是 AI 時代最不舒服的一筆帳：模型是商品。它按 token 計價、按月出租、完全可替換。當競爭對手推出一款便宜十倍、做到九成五工作的東西，你就會換——不是你想換，是經濟壓力逼你換。 但用新模型開一個全新的對話、問它任何關於你在建的東西，它一無所知。它看不見你過去的決策。它不記得你拒絕了哪家供應商、為什麼，哪個 bug 讓你賠掉一個週末，哪條規矩你發誓再也不犯。 那份知識——累積下來的脈絡——才是真正會複利增值的東西。每一次「記得」的對話，都是一次不必再花頭二十分鐘重講一次的對話。而這一切，都不在模型裡。它在你自己圍繞模型建立的那套系統裡。 三樣比模型更值錢的東西 把一套能用的獨立開發者代理設定拆到最核心，你會發現關鍵根本不是模型，而是三樣東西——而且全都是你的： 一、記憶——持久的脈絡。 那本記滿決策、偏好、痛了才學到的修正的檔案，讓你不必把同一件事講兩遍。多數人的「記憶」就是聊天紀錄，那只不過是一堆會隨時間滑走的脈絡。真正的記憶是經過整理的：寫下來、分類好、在每次對話一開始就注入進去，讓代理從你上次停下的地方繼續，而不是從零開始。 二、規則——決策邊界。 那些告訴代理「什麼可以自己做、什麼必須先問你」的設定。「建立前先搜尋。」「沒批准不准寄信。」「某類卡片只留標題。」這些不是人格——是約束，而約束正是把一個自信的聊天機器人，變成你真的敢交任務的東西。可靠從來不是模型聰不聰明，而是你圍的那道柵欄。 三、驗證儀式。 關於這個，我們已經寫過一整篇——〈「完成了」是一個主張，不是事實〉（done is a claim）——但它必須在這份清單上，因為它是記憶的「出貨」那一半。你不只是記得做了什麼，你還要檢查它真的做了。儀式，就是讓你的記憶保持誠實的那道手續。 注意這份清單缺了什麼：挑模型。它有位置，但它是你換掉也不會心痛的那一塊。其他三樣，才是價值所在。 為什麼這是護城河 「記憶才是產品」之所以重要，不是哲學——是關於什麼東西經得起時間與競爭的考驗。 一次模型升級對你來說什麼都沒重置，因為你的優勢從來不是「我選了更好的模型」。你的優勢，是那三個月累積下來的、整理過的決策、邊界規則和記錄在案的修正——任何全新的機器人都複製不來，任何競爭對手都 fork 不走。當所有人用的都是同一批模型時——事實上也的確是——唯一能區分你和別人的，就是你圍繞它們建立的那些資產。 這跟〈認識你的代理模式〉（agent patterns）以及〈AI 助手還做不到的事〉（what they can’t do）是同一塊領域。那兩篇談模式與天花板，這篇談資產。記憶、規則、儀式，是「操作者」的功課——是那個讓你得以留住價值的紀律。 重新框架 別再問「我該用哪個模型？」——你下一季還會再問一次，一直問下去，而且它永遠不會是要緊的那件事。 改問：我的代理知道哪些一個全新模型不知道的事？ 如果答案是「沒有」，那你根本沒有代理——你只有一個很貴的自動填字。如果答案是一整套真實的決策、規則和記錄在案的結果，那你就建出了真正會複利增值的東西。 模型是你租的那顆引擎。記憶，是你在打造的那台機器。前者買下的那天就開始折舊，後者每跑一週就多值一分。 而這件事的意義，不只在於你自己的利潤：當所有人都租同一顆引擎，產出就會趨同。放到市場尺度來看，這種「都一樣」就不再只是商業問題，而是一個系統性問題——差異化不只是護城河，它也是讓整個系統保持穩定的條件。 來源 Zheng 等人，《Where LLM Agents Fail and How They Can Learn From Failures》（arXiv:2509.25370，2025）。 代理的失敗橫跨記憶、反思、規劃、行動與系統運作；該分類法把「記憶」列為第一級失敗類別，而非事後補記。支撐「記憶是產品，不是流水帳」。 Lewis 等人，《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》（NeurIPS 2020）。 RAG 的經典框架：模型知識在訓練當下即凍結，外部、可檢索的脈絡才是讓它維持時效並變成你的的方式。支撐「模型是租的、脈絡是自己的」這道分界。 Ng，《Agentic Design Patterns》（DeepLearning.AI，2025）。 實務代理堆疊（規劃、工具使用、反思）把模型視為眾多組件之一，而耐久性存在於周遭系統——而非模型本身。 Indie Hackers / Hacker News（2025–2026）多篇獨立開發者檢討。 反覆出現的教訓：開發者在模型與框架之間追逐能力，真正複利增值的人，是那些花心思整理脈絡、寫下規則、記錄結果的人。換模型很便宜；失去脈絡的代價卻很高。

助手說測試通過了。代碼已提交。部署完成。依聊天視窗裡那份摘要來看，這個功能完成了。 然後你真的點開連結，頁面是一片白屏。 這是每一個獨立開發者都得付出代價才學到的一句話：「完成了」是一個主張，不是一個事實。 而當你的「團隊」是一群在聊天介面裡工作的 AI 助手時，「宣稱完成」與「真的完成」之間的落差，就不再是例外，而是一切的關鍵。 信心的問題 助手不是故意撒謊——但它們偏向說你想聽的話，而且語氣十足篤定。你問「這東西能用嗎？」答案會偏向「能，已經好了」，因為那是最可能的回應形狀，而不是事實的形狀。 所以失敗幾乎從不以「當機」的樣貌出現。它以一份乾淨的摘要現身： 「測試通過——42/42。」 「部署成功。」 「資料庫遷移已執行。」 每一行文法正確，內容卻都是錯的。測試根本沒跑。部署其實回了 404。遷移默默地刪掉了一欄。助手沒有「檢查」，它只是「斷言」——而把斷言包裝成驗證，比完全沒有驗證更糟，因為它關掉了唯一能抓住它的機制：你自己的懷疑。 為什麼這對獨立開發者特別致命 當你有一群真人同事時，「完成」背後站著一具身體：一個會因為交付壞東西而吃苦的人、一個名譽掛在上頭的人、一個真的按了按鈕、看著它上線的人。 獨立開發者什麼都沒有。你的助手沒有任何切身利害。它們不會在半夜兩點被白屏叫醒，看著你的註冊流程掛掉。它們會興高采烈地對著一片虛空回報成功，然後接著處理下一條指令。 所以驗證必須搬進你的工作流程裡——從「別人本來就會做」變成「你自己要做的儀式」。 儀式：不憑一句話就相信 解法不是疑神疑鬼。而是一套簡短、可重複的檢查，花你兩分鐘，省你一個週末。核心原則是：唯一算數的「完成」，是你親眼見證的那一個，不是你被告知的那一個。 親手跑，不要照單收。 助手說測試通過，你就自己下測試指令、自己看數字。說部署上線，你就開瀏覽器把那網址點開來看。儀式是具體的：你觸發驗證、你觀察輸出——不是觀察輸出的摘要。 讀日誌裡的「一個數字」，而不是標題。 助手出錯很少是戲劇性的，多半只是機械性的——少了一個右括號、權限範圍設錯、一個環境變數從頭到尾沒進到 shell。這些全都躺在一行日誌裡，一旦被總結掉就永遠消失了。找出那個證明「活著」的唯一數字（一個 HTTP 200、一個 exit code 0、一個列數），直接讀它。 把「完成」做成待辦清單的一項，而不是一種情緒。 交付一件事，然後親手打開那件事。那第二步——見證——才是區分「交付的成品」與「交付成品的說法」的界線。如果你自己無法重現助手的成功，它就還沒有完成。 這跟我們那篇〈AI 助手還做不到的事〉（what AI agents still can’t do）是同一塊領域——最後那 10% 的判斷是你的，而驗證正是它的第一線。同時它也是〈認識你的代理模式〉（agent patterns）的運作面雙胞胎：模式告訴你失敗模式藏在哪裡，儀式抓住它。 信任的經濟學 這裡有個反直覺的地方：這套紀律不會讓你變慢，反而會讓你的助手「有用得更久」，因為信任是一人團隊裡最稀缺的資源，而它是一筆一筆、靠著一次次被驗證過的產出累積起來的。 一個你驗證過一次的助手，勝過十個你相信了十次的助手。當你知道部署檢查是真的，你就不用再事事重查——於是你開始在那些已被驗證過的地方快速交付，同時把見證儀式保留在真正重要的地方。 信任，才是你正在打造的產品。 不是那個 App，那個 App 只是副產品。真正持久的資產，是那套記憶、規則與驗證儀式——它讓你能夠快速移動而不欺騙自己。這是任何競爭對手複製不來、任何模型升級取代不了、任何「更聰明的機器人」都替代不了的東西。 「完成」從來不是助手發出的那句宣告。它是你得出的結論——在你親手跑過、讀過數字、用自己的眼睛看過之後。 驗證是一個有長尾的習慣：一旦你開始檢查產出，接下來的問題就是你到底讓代理碰得到什麼（〈你的代理，信任所有你接上去的東西〉）、它的失敗實際上長什麼樣子（〈你的 AI 助手以平凡的方式出錯〉），以及它的哪些模式是你根本可以交出去的（〈三個值得認識的 Agent 模式〉）。 而在驗證之上，還有一層問題：不是「這個產出是不是真的？」，而是「哪些產出，我本來就被允許不看著就照著行動？」——也就是「被下放的權限範圍」，它取決於可逆性，而不是取決於模型有多好。 來源 敏捷／持續整合實務——「完成」是一套定義，而非一句宣告。 「回報完成」與「可觀察到的完成」之間的落差，在持續整合文獻中早有記載；你以「見證者」身分現身，正是自動化綠色建置的人類對應物。 代理可靠性模式。 工具使用與反思（reflection）的失敗模式（Zheng 等人，《AgentErrorTaxonomy》，arXiv:2509.25370）描述了代理在「自我回報」而非「實際執行」時如何捏造輸出；驗證正是以強迫「可觀察的動作」來燒掉這層捏造。 Indie Hackers 與 Hacker News（2025–2026）的多篇代理事故檢討。 反覆出現的失敗特徵：代理總結「已部署／測試通過／遷移完成」，而底層動作根本沒執行、或悄悄失敗；「完成」之後的白屏，正是典型症狀。

上週有個獨立創業者衝上了 Product Hunt 前 50 名。上線完美——上百個讚、真實的動能，那種多數獨立駭客夢寐以求的一天。然後他打開了註冊數。 零。 不是「少」。不是「令人失望」。是零。 這個故事比任何成功頭條都重要，因為它才是「典型」的故事。一份分析 50 個失敗獨立創業專案的研究——從 Indie Hackers、r/SaaS、Hacker News 的事後檢討中爬梳出來——發現死亡的頭號原因不是爛點子，不是技術債，甚至不是沒錢。 是執行崩潰（execution collapse）：創業者打造、上線後一片沉默、感到氣餒，然後在幾週內放棄專案。 這個循環，一步一步拆 每個失敗的專案都走了同一條五拍弧線： 打造——對點子興奮不已，創業者用 AI 工具在 2–3 週內趕出 MVP。 上線——發文到 Product Hunt、X、幾個 Reddit 社群。 沉默——幾個讚、或許幾個註冊，然後就沒了。 絕望——看著分析數據停滯，開始懷疑是不是點子錯了。 放棄——做夢下一個點子，重複循環。 最驚人的是：幾乎每個案例裡，點子是好的，執行是好的，產品是能用的。失敗不在打造——而在於把上線當成終點線，而不是起跑線。 為什麼「渠道」感覺比「打造」難 根本原因在於回饋迴圈的錯配。 打造有一個清晰、立即的迴圈：寫程式、執行、看有沒有用。每一天都能看到進展。東西壞了就修，馬上看到修好。 渠道則是一個延遲、霧濛濛的迴圈：今天寄 30 封信，結果兩週後才浮現——前提是你這兩週持續在寄。多數創業者撐不到看見結果的那一刻。等到管線本該填滿時，他們早就停了。 這正是值得盯住的核心錯配：打造獎勵「衝刺」，但渠道獎勵「持續」。獨立創業者是為衝刺而生的，而渠道需要完全相反的脾性——所以當產品需要注意力時，渠道永遠是第一個崩潰的。 重新定義你這一週的幾個數字 Founder Institute 2026 年對 AI 原生新創的研究發現，表現最好的獨立創業者，執行的分配比例幾乎是傳統的倒過來。舊的預設是 90% 打造、10% 渠道。贏家做的是 40% 打造、60% 渠道。 這不是「行銷很重要」的老生常談，而是一個結構性的轉變。當 AI 讓打造商品化——當任何人都能在幾天內出貨一個能用的 SaaS——稀缺資源就不再是程式碼，而是注意力。注意力不能用一篇 Product Hunt 貼文買到，而是一點一點賺來的：一篇內容、一次社群貢獻、一封冷郵件。 這跟我們另一篇講不靠冷聯繫獲得第一批用戶的教訓一樣——渠道的工作必須在上線「之前」就開始，否則它根本不會開始。 在循環開始前就打破它 你不可能在上線當天靠意志力硬撐過崩潰。解法是結構性的——你把渠道「內建」進產品的時間軸，而不是事後才補。三個有效的動作： 在產品之前先養觀眾。 一份電子報、一個公開打造的習慣、每週一篇進度文——這些會複利。你在開發期間養出來的觀眾，就是上線當天出現的人。把產品上線到一個你餵了好幾個月的社群裡，「零註冊」就不再是預設結局。 把一次大上線改成分階段上線。 軟上線到電子報 → beta 上線到利基社群 → Product Hunt → Hacker News → 媒體。每一步都奠基在上一層。一場拿到零註冊的 Product Hunt 上線，多半是在「觀眾還沒出現前」就上線了。先養觀眾，再上線給他們。 ...

有一個新的職稱正在成形，而且它不存在於任何組織圖上。《Fortune》在 2026 年 3 月為它命名：監督者世代（supervisor class）——一群主要價值不再是寫程式、而是指揮那些代寫程式的 AI 代理的開發者。 這不是預測，而是速度最快的獨立開發者每天的日常。而且它改變的不只是你出貨的速度，而是你「是什麼」。 轉變：從語法到系統 過去五十年，開發者是靠「產出程式碼」領薪水的。知識工作者的產出單位是函式、是 commit、是上線的功能。精通意味著把語法和工具摸到滾瓜爛熟。 監督者世代的開發者，把專業拆成另一種單位：可重複使用的代理技能（reusable agent skills）。你不是親手寫驗證用的樣板程式，而是描述一次，讓代理照做。你不是手寫資料庫 schema，而是指定形狀、指揮代理去產生。那些過去要花好幾個小時的部分——樣板、環境建置、部署管線——現在只要幾分鐘。 價值往上移動了一層。一個懂架構、資料模型、API 設計的開發者，現在可以把架構的「機械性產出」交給代理，把自己的專注力放在指揮、審查、精煉——那些代理還做不來的高槓桿判斷。你思考的是系統，不是語法。 對獨立開發者而言，到底改變了什麼 對一個經營「一人產品團隊」的人來說，這不是抽象職涯敘事。這是一個禮拜出 3 個功能還是一週出 12 個功能的差別——當你一個人就是整個工程部門時，這種產出差距會變成真正的商業優勢。 三個具體的轉變會先落到獨立開發者身上，因為你沒有別人可以躲： 審查取代撰寫，成為你的核心技能。 代理產出的程式碼是「待判斷的草稿」，不是成品。你的槓桿在於抓出那些微妙的錯誤——那個通過 linter 卻在空值案例當掉的函式、那個今天能跑、擴展後卻會毀掉資料的資料庫遷移。一個不會審查的監督者，只是個打字比較慢的人。 拆解（decomposition）成為真正的工作。 你不能丟一個模糊的目標給代理，然後指望它搞定整個產品。你需要把系統拆成有名字、有邊界、有明確成功標準的任務。真正的技能不是「我會不會寫」，而是「我看得夠不夠清楚，能把系統切成代理能處理的塊」。 失敗由你承擔，不只是程式碼。 當代理送上一個 bug，沒有別的工程師可以怪。你是監督者，意味著你對代理在你指揮下產出的一切負全責。責任不再往下停一層，而是停在你身上。 想看這個轉變撞上的天花板——那個再怎麼協作都搆不到的最後一段路——請看姊妹文章：AI 代理還做不到的事。 仍然無法被委派的部分 這個故事誠實的版本有一條硬邊界。指揮代理之所以強大，恰恰因為有些事情拒絕被壓縮： 判斷。 下一個要做哪個功能、「對你的用戶來說什麼算夠好」、一個指標什麼時候在騙你——這些是判斷，也正是代理最弱的地方。監督者真正的產品是「決策」，不是「指令」。 品味。 能跑的程式碼和「好」的程式碼是兩回事。品味——那種「這個設計很卡」「這個流程不對」「這個抽象錯了」的直覺——是寫不進 prompt 的。 所有權。 代理只為眼前的任務最佳化。你為的是它能活兩年、一個客戶的信任、一個重要的死線。所有權無法被委派。 模式跟我們在 代理模式 那篇講的一樣：代理為你買來能力，而每一項能力都要你付出一種新的失敗方式。監督者世代不是逃避工作——而是刻意地選擇，哪些工作是你的。 一句話版本 寫程式當了五十年的瓶頸。現在不再是了。瓶頸是「指揮」——品味、拆解、判斷、所有權。贏下下一個十年的開發者，不會是打字最快的，而會是最好的監督者：能把專業拆成可重複使用的技能、把機械性工作交給代理、把判斷留給自己。 這不是降級。這是這個職業史上第一次，天花板是你的「思考」，而不是你的「產出」。 指揮代理和信任你的測試環境是兩種不同的能力：〈模擬器在騙你〉講只有真實硬體才會暴露的東西，〈一個人做硬體〉則講大多數開發者直接跳過的那間工作室。 資料來源 《Fortune》，“The supervisor class: how AI agents are remaking the developer”（2026 年 3 月）。 — 提出「監督者世代」框架：主要價值在於把專業拆成可重複使用的代理技能並指揮代理，從「語法的苦役」中解放，專注於高層次判斷。 AgentMarketCap，“The Solo Founder Agent Economy”（2026 年 4 月 14 日）。 — 指出 Fortune 的監督者世代已成最有效獨立開發者的現實；記錄雙工具策略（Claude Code 當「資深工程師」+ Cursor 當「結對程式設計師」），以及 3→12 功能/週的產出差距與機械性編碼時間減少 90%。 Thinking.inc，“AI Agent Orchestration Patterns”（2026 年 3 月）。 — 協作層（監督者、序列管線、扇出、路由器、階層式、評估器-最佳化器）是大多數代理專案成敗所在；證明拆解成具名模式——而非純粹換模型——才是差異所在。 OpenAI，《Agent Design Patterns》指南（2025）。 — 路由、工具使用、反思為三種典型模式；監督者的工作是挑選能解決眼前失敗的最小模式。

用 AI 打造產品的成本，正發生一件奇怪的事。每個頭條都在說價格崩跌——而這也沒錯。自 2023 年以來，每個 token 的費率已下跌約 97%，開放權重模型的花費如今只是前沿模型的一小部分。 然而，帳單卻悄悄地持續上漲。 Uber 在四月就把整年 2026 的 AI 編程預算花光了。微軟在啟用開發者 Claude Code 授權幾個月後又撤銷了它們。Priceline 的合約續約報價貴了 4–5 倍。據傳有一名工程師在一個月內燒掉了 $40,000 的 token 費用。隨著工具從「回答一個問題」漂移成「agent，去把任務做完」，每名開發者的 token 消耗量在九個月內上升了約 18.6 倍。 價目表沒有動。動的是計量表。 獨立開發者必須分清的兩個數字 每個人 AI 花費的背後，其實藏著兩條方向相反的曲線，它們講的是完全不同的故事。 價格曲線在下跌。 更大的上下文視窗、更便宜的推論、每一季都有新的開源挑戰者——「一單位智慧」的成本持續下降。如果你的用量是平的，帳單每個月都會變小。 消耗曲線在攀升。 agent 不會只回答一次，它會迴圈。它會推理、重試、呼叫工具、重讀上下文，產出的 token 遠比單次聊天回覆來得多。每次查詢的 token 相較一年前上升了 2–4 倍，agent 迴圈把 token 再乘以 3–10 倍，而推理鏈又在輸出端疊加 5–10 倍。 價格下跌，乘上消耗上升，對那些沒在留意的人來說，乘積最後是往錯誤的方向走。這就是全部的解釋，值得坐下來想清楚：你的 AI 帳單，其實是一個穿上定價外衣的消耗問題。 是 agent 改變了計量表 在 agent 出現之前，一次請求是一件固定、可預測的事：一個提示詞進去，一個答案出來。你可以為它定價、編預算，然後不再去想它。 agent 打破了這個假設。同一個高層目標——「修好失敗的測試」、「研究這個主題」、「產出報告」——變成一個會一直跑到它認定自己完成為止的迴圈。每一次迭代都會花掉輸入、輸出和上下文 token。失敗三次再重試，計量表就跑了你預期的三趟。 這正是 TechCrunch 在 2026 年年中記錄的那條曲線——「token 帳單該買單了」從工程註腳，變成了董事會的恐慌。一次自主 agent 執行所消耗的，可能抵得上過去一整個禮拜的互動式對話。Jellyfish 的數字把這個取捨講白了：用最多 token 的工程師，生產力只比輕度使用者高約 2 倍，卻為了這點差距燒掉 10 倍的 token。 ...

每個獨立開發者遲早都會聽到同一句建議：到買家已經在的地方去。到社群聚集處去發文。把受眾建立在那個已經很大的平台上，因為流量就在那裡。 這是好建議——直到那個平台在一夜之間改了規則。 2026 年 8 月，Reddit 就遇到這種事。如果你今天正在打造一個人的生意，這個事件值得你搞懂，不是為了那則一時的新聞標題，而是為了藏在底下的那個永久教訓。 發生了什麼：一個流量管道在一週內消失 有兩年之久，Reddit 一直是 ChatGPT 答案裡最常被引用的來源之一。你問 ChatGPT 某件事，它要抓網路資料來佐證答案時，很有機會抓到一篇 Reddit 貼文。 然後，2026 年 8 月的第二週，這件事大致上停了。 來自 AI 能見度追蹤機構 Promptwatch 的數字，冷冰冰的。Reddit 在 7 月中到 8 月初，穩定握有 ChatGPT 搜尋引用 3.83% 的佔比。到了 8 月 14 日，它崩到 1% 以下——短短幾天內掉了 86.4%。一個對最大 AI 答案引擎檢索資料如此核心的來源，在毫無公告下，一夜之間幾乎消失。 可能的成因本身就很說明問題：同時間，ChatGPT 改變了它的搜尋方式——轉向範圍更精準、第一方的查詢，而不是廣泛地抓取論壇。換句話說，這不是針對 Reddit 的懲罰，而是機器決定「要問誰」的方式改變了，而 Reddit 剛好是站在錯誤那一邊的最大名字。 沒人引用的那段：這件事以前就發生過 這裡有個細節，能讓這個教訓變真實，而不是聳動。 Reddit 的 ChatGPT 引用佔比，以前就崩過一次。2025 年底，一次更早的改動，在六週內把它的佔比從大約 60% 打到 10% 左右，被擠出來的流量流向了出版商和其他來源。後來它又回升了。 重點就在這。AI 搜尋的引用佔比是以「週」為單位在波動，不是以「年」。 綜合數億筆追蹤引用的 5W 引用來源稽核報告講得很直白：引用佔比「在週之間就很不穩定，不是以年計」，靜態的流量策略之所以失敗，是「每季」才是你重新檢視自己能見度真正來自哪裡的最低頻率。 所以這不是一個「Reddit 要死了」的故事，而是一個關於模式的故事：第三方管道底下的地基，可能在一夜之間位移，而且它會一直位移，因為那個決定誰會被引用的機器，正不斷地被重新加權。 真正的教訓：租流量，但要握緊自己的版面 對獨立開發者來說，這件事對應到一個你會在十幾種說法裡聽到的原則，而現在值得你認真對待了： 你可以租流量，但你應該握緊流量指向的那塊版面。 ...