自主迭代優化的聖杯 · AI LEAN STARTUP

這是一份公開草稿。內容還在迭代，歡迎一起把它變得更好。

AI CEO 和專案經理

你有了 AI CEO。

然後你同時跑五個 BML 循環——五個方向在測試，每個都有自己的 Build、Measure、Learn Agent 在動。

問題來了：誰來管這五個？

如果是你，你回到了起點——你就是協調者，你就是瓶頸。

如果是 AI CEO，它每天要接收五份即時反饋、處理五組調整指令、追蹤五條進度——然後還要思考整個系統的優化方向。

一個身兼執行長和專案協調員的角色，通常兩件事都做不好。

沒有中間層，戰略層被日常協調吃掉

AI CEO 的價值在「看全局」——跨越 N 個循環找模式、決定哪個方向加碼、更新讓所有循環受益的執行環境。

但如果它每天在處理每個循環的細節，它就沒有時間和距離做這件事。

結果是：你的 AI CEO 變成一個很聰明的跑腿。戰略層被日常協調消化掉了，沒有人在做最重要的事。

這不是 AI CEO 的問題。是架構的問題。

讓 Codex 擔任專案經理

這就是 Codex 進來的位置。

Codex 擔任 PM（專案經理）——管理 N 個並行 BML 循環的日常執行，讓 AI CEO 做它最值錢的工作。

角色	誰	管什麼
AI CEO（執行長）	Claude Code	全局戰略、Harness Engineering、每日指令、每週復盤
PM（專案經理）	Codex	N 個循環的日常執行、即時協調反饋、每日彙整回報

AI CEO 看趨勢，PM 管細節。各自在對的位置做對的事。

雙層結構跑起來，你的工作長這樣

想像這個架構正常運作的一週。

Codex 每天管著五個循環的細節：哪個 Build Agent 今天有輸出、哪個 Learn Agent 發現了訊號、哪個循環要調整下一輪方向。它處理這些，不需要你，也不需要 AI CEO 盯著。

每天下班前，Codex 把彙整好的報告送給 AI CEO。AI CEO 讀完，做出三到五個決策，指令送回：「加碼 BML #2、調整 BML #4 的假設、暫停 BML #5。」Codex 執行。

每週一早上，AI CEO 的成績單在你桌上等你——不是原始數據，是結論：這週哪個方向有效、AI CEO 做了哪些調整、下週你需要決定什麼。

你看完，給一個方向。

為什麼需要兩個角色，而不是一個

戰略判斷和執行協調，需要不同的「認知距離」。

AI CEO 看趨勢和模式——需要距離，把細節抽象掉，才能看見跨循環的規律。PM 管每個循環的具體狀況——需要貼近，知道每個循環今天在哪裡、卡在哪裡。

同一個角色不可能同時保持距離又貼近細節。你不會讓公司 CEO 兼任每個專案的日常管理——這個分工在傳統組織裡存在了幾十年，是有原因的。

現在你用 AI 把它實現。不是新概念，是讓正確的角色結構，在你的 AI 一人公司裡跑起來。

今天的第一步

打開 Claude Code，輸入：

「我目前用 Agent 在做 [你的業務方向]，我想設計一個 AI CEO + PM 的雙層架構。請幫我：（1）定義 Claude Code 作為 AI CEO 的工作範圍與每日任務；（2）定義 Codex 作為 PM 的工作範圍；（3）兩個角色的協作節奏——每天各做什麼、每週各做什麼。」

這份 SOP，是你整個自主迭代系統的骨架。

自動化的 AgentBML 團隊

有了 AI CEO 和 PM，下一個問題是：

它們實際怎麼運作？誰在什麼時間做什麼？資訊怎麼流動？

這不是理論問題——如果你說不清楚每個角色每天的具體動作，這個系統就只存在於想像裡。

這章把它說清楚。

CH08 的四個角色，CH09 加了什麼

CH08 介紹了 Builder、Measurer、Reporter、Executor。

CH09 的自動化 AgentBML，不是換了新角色，是多了一條閉合回路：

CH08 的 Reporter，產出給你看的報告——你讀，你決定，你更新。

CH09 的 Learn Agent，產出給 PM（Codex）執行的結構化建議——Codex 接到，評估，調整下一輪 Build 的參數。不需要你進來。

這條回路閉合了，系統才開始自己學習。

N 個並行循環，各自獨立

每個循環都是完整的：

Build Agent → 在當前參數下產出
     ↓
Measure Agent → 自動收集數據
     ↓
Learn Agent → 分析數據
           → 即時輸出結構化建議給 PM
           → 只影響自己這個循環

每個循環獨立跑，各自學習，各自調整。PM 分開管理，不讓一個循環的失敗影響其他循環。

PM（Codex）的每日工作

① 接收 Learn Agent 的即時建議，調整對應循環。

BML #3 的 Learn Agent 說：「這篇文章開頭沒有具體數字，停留時間低於標準。」Codex 更新 BML #3 的下一輪參數：「下一篇第一段必須含至少一個具體數字。」只影響 #3，其他循環照原樣跑。

② 每天彙整 N 個循環的結果，送給 AI CEO。

不是丟原始數據，是整理成能快速判斷的格式：

BML #1：流量上升 23%，Learn Agent 標記「標題公式有效」
BML #2：轉換率下降，標記「CTA 位置問題」
BML #3：無明顯信號，持續觀察
BML #4：停留時間最高，建議「加碼這個方向」

③ 接收 AI CEO 的指令，執行調整。

「加碼 #4，暫停 #3，重新設計 #2 的假設。」Codex 接到，執行。

AI CEO（Claude Code）的每日工作

AI CEO 不管循環細節。它只做一件事：讀 Codex 的彙整報告，做出跨循環的 Harness 決策。

它看的是跨 N 個循環的比較視角——BML #4 有效，為什麼？#1 和 #4 有什麼共同點？這個共同點，值不值得寫進所有循環的執行環境？

這種跨循環的洞察，個別 Learn Agent 看不到——每個 Learn Agent 只看自己的循環。只有 AI CEO 同時看 N 份報告，才能找到跨循環的模式。

找到有效模式，AI CEO 更新 AGENTS.md——這個更新影響所有循環，讓整體系統受益。

一天的完整資訊流

早上：N 個循環的 Build Agent 開始產出
         ↓
      Measure Agent 自動收集數據（Scheduled Tasks）
         ↓
      Learn Agent 分析 → 即時建議給 Codex
         ↓
      Codex 調整對應循環的下一輪參數

傍晚：Codex 彙整當日成果 → 送 AI CEO
         ↓
      AI CEO 讀報告 → 做出 Harness 決策
         ↓
      指令給 Codex → 執行具體調整
         ↓
      有效模式 → 更新 AGENTS.md（所有循環下一輪受益）

你的角色：每週看一份成績單，做一個方向決定。

今天的第一步

在 Claude Code 裡輸入：

「請幫我設計一個 3 個並行 BML 循環的自動化架構。我的業務是 [描述]，想同時測試的三個方向是：（1）[方向一]；（2）[方向二]；（3）[方向三]。請給我：每個循環的 Build / Measure / Learn 分工、Learn Agent 回傳什麼格式的建議給 Codex、Codex 每天彙整哪些數字。」

從 3 個並行循環開始，不要直接跳到 N 個。

系統跑通了，再擴張。

對齊 PMF 的共同目標

N 個並行 BML 循環，目的是什麼？

直覺的答案：更快驗證、更多實驗、更高效率。

不算錯，但不完整。

N 個並行 BML 的真正目的只有一個：更快找到 PMF（Product-Market Fit）——你的產品和市場之間那個「對了」的交叉點：客戶願意掏錢，你能持續交付。

如果 N 個循環追的不是這個，它們跑得再快，都是在幫你更快地跑偏。

PMF 是 BML 的北極星

PMF 不是一個指標，是一個狀態——你的產品解決了一個真實的問題，而且有足夠多的人願意為這個解法付錢。

在這個狀態到來之前，你做的所有事——MVP、BML、AgentBML 系統——都是在縮短找到它的時間。

找到了，才是真正開始。

這就是為什麼 Part 3 所有的自動化系統，本質上只是工具。工具的目的不是讓你永遠跑 BML，是讓你更快結束「還在測試」，進入「已經找到市場」。

共同目標讓 N 個循環有意義

N 個循環，每個測不同的方向。問題是：這 N 個方向，有沒有共同指向同一個問題——「誰願意為什麼事付錢」？

有，N 個循環是在從不同角度逼近同一個答案，你最終會收斂到一個清晰的 PMF 訊號。

沒有，N 個循環是在同時問 N 個不同的問題——就算每個都跑出結果，你也得不到一個可以決策的答案。

三個實作原則

① 每個循環的假設，都必須回答同一個核心問題。

設計 N 個循環時問自己：這 N 個實驗，是同一個問題的不同切面嗎？

例如核心問題是「誰是我最願意付費的客戶，他們最在意什麼」：BML #1 測「內容創作者」受眾，#2 測「獨立顧問」，#3 測「小型電商主」——三個循環各自跑，但都在回答同一個問題的不同角度。

② AI CEO 的決策，以「PMF 訊號」為優先標準。

不是哪個循環流量最高就加碼。是哪個循環出現了「有人願意付錢」的訊號就加碼。

流量是指標。付費意願才是 PMF 訊號。這個優先順序，要寫進 AI CEO 的執行環境。

③ 你每週的一個決定：哪個方向離 PMF 最近。

你每週看成績單，最重要的判斷不是「哪個數字最好」，是「哪個方向有人真的想付錢」。根據這個判斷，告訴 AI CEO 下週的加碼方向。

Part 3 和 Part 4 的接縫

Part 3 講 BML 自動化——讓系統跑得快、跑得聰明。Part 4 講 PMF 實戰——當系統出現 PMF 訊號，你怎麼接住它，把它轉化成真正的收入。

這一章是橋接點：你建了這麼複雜的系統，不是為了永遠跑實驗。是為了更快找到那個值得押注的方向。

找到了，Part 4 告訴你下一步。

今天的第一步

拿出你正在跑（或想設計）的 BML 循環，對每一個問：

這個循環在測試的東西，如果有了明確的正面結果，我會願意把接下來三個月押在這個方向上嗎？

答案是「不確定」或「不會」——這個循環的假設有問題：它在驗證你好奇的事，不是你願意去做的事。

把這個問題帶給 AI CEO，讓它審查每個循環的假設是否真的對齊你的 PMF 目標。

方向對齊了，系統才跑得有意義。

讓 Agent 做對的事

系統自動在跑，數字也不錯——流量上升、互動率提高、每天都有輸出。

但三週之後你發現，有互動的都是不會付錢的人。

系統很努力，跑得很快，方向偏了三週。

這不是 Agent 的問題。是沒有人在監控「系統是否在追對的事」。

讓 Agent 做對的事，不是一次設定就好的問題。是 AI CEO 和 PM 持續分工合作的日常工作。

PM 的職責：讓每個循環按設計跑

PM 管執行層的準確性。每天三件事：

① 確認 Learn Agent 的反饋被正確執行。 Learn Agent 建議「下一輪標題要更具體」，Build Agent 下一輪真的更具體了嗎？PM 不是假設 Agent 做了，是確認 Agent 做了。

② 標記異常，不自己解讀。 某個循環流量突然掉 40%，或 Learn Agent 連續三天沒有建議——PM 不分析原因，它標記：「BML #3 數據異常，需要 AI CEO 判斷。」

③ 彙整每日成果，格式標準化。 哪個循環有信號、哪個有異常、哪個正常跑、主要建議是什麼。格式固定，AI CEO 才能快速讀完、快速判斷。

AI CEO 的職責：確保系統追對的目標

AI CEO 管方向層的準確性。每天兩件事：

① 讀 PM 的報告，做跨循環的決策。 看的不是細節，是比較：哪個循環出現了 PMF 訊號（有人問價格、要試用、主動分享）？哪個循環流量很好但沒有 PMF 訊號？

有 PMF 訊號的加碼。沒有的，即使數字好看也要重新評估。這個判斷用 PMF 優先標準來做，不是用「哪個數字最大」。

② 把有效模式寫進 AGENTS.md。 某個循環出現有效的標題公式，AI CEO 確認後更新 AGENTS.md——所有循環的 Build Agent 下一輪都用這個更好的公式。

有效的發現不留在單一循環。它成為整體系統的新標準。

每週：復盤與成績單

每天調整細節。每週重新審視整體。

每週復盤（AI CEO ↔ PM）：這週的整體走向有沒有值得押注的方向？有沒有循環該整個重新設計假設？AGENTS.md 的更新有沒有讓品質可見地提升？下週的配置要不要調整？

每週成績單（AI CEO → 你），三件事：

這週的結果——哪些循環有 PMF 訊號、哪些被調整，用你能直接判斷的語言說。 AI CEO 的決策——更新了什麼、為什麼、效果如何。下週需要你決定的事——超出 AI CEO 判斷範圍的戰略問題，例如「#2 和 #4 都有 PMF 訊號但方向不同，你想集中在哪一個？」

你的工作：看完，做一個決定，繼續。

Boss Engineering 品質，是這一切的地基

AI CEO 和 PM 再有效率，有一個前提：你給的 Boss Engineering SOP 必須清楚。

PMF 標準是什麼、哪些指標是真正的信號、什麼叫「有效」——這些在 Boss Engineering 裡模糊，AI CEO 就無法做出準確的決策，PM 也不知道要標記什麼為異常。

系統的上限，是你的 Boss Engineering 品質。

不是要你一開始寫出完美的 SOP。是每週看完成績單之後，更新一條定義——讓 AI CEO 下週的判斷更精準一點。

每週進步一條。三個月後，你的 Boss Engineering 是完全不同等級的東西。

今天的第一步

打開你的 CLAUDE.md（或你的 Boss Engineering 文件），找到你給 AI CEO 的成功標準——你怎麼定義「一個 BML 循環有效」？

問自己：這個標準，能分辨「流量好但沒人付錢」和「有 PMF 訊號」嗎？

不能，今天就更新這一條。加入具體的 PMF 訊號定義：什麼樣的用戶行為，才算是你在找的訊號？

更新這一條，AI CEO 明天的決策就更準了。

你睡覺的時候，系統在進化

有一種放鬆，不是因為沒有事情在發生。是因為事情在發生，而且不需要你。

你睡著的時候，Build Agent 在產出。Measure Agent 在收數據。Learn Agent 在分析，把建議送給 PM。PM 把調整指令送給對應的循環。

你醒來，系統已經跑完一輪，比昨天更好一點點。

這不是比喻。這是你把 Part 3 的東西部署起來之後，真實會發生的事。

某個週一早晨

第八週的週一。

你打開 Notion，AI CEO 的週報在那裡等你。二十分鐘讀完。

五個並行循環的成果：兩個有明確 PMF 訊號，一個被 AI CEO 暫停（連續兩週無信號），兩個還在跑。

AI CEO 這週的決策：把有 PMF 訊號的方向的產出頻率提高，把一個有效的標題公式寫進了 AGENTS.md，所有循環下週都會用。

需要你決定的事只有一件：「BML #2 的 PMF 訊號來自獨立顧問族群，BML #4 來自電商主族群，下週你想集中資源在哪一個？」

你想了五分鐘，選了獨立顧問方向，在週報裡更新一行指令。

關掉電腦。

這是你今天和系統互動的全部。

十二週的複利

第 1 週：你啟動三個 BML 循環，一切都很粗糙。Learn Agent 第一次的建議很基本——「標題太模糊」「結尾沒有行動步驟」。AI CEO 更新了兩條規則。

第 3 週：失敗案例累積到十幾個，AGENTS.md 從三條規則長到八條。Build Agent 的輸出開始出現可見的結構升級。你在週報裡第一次看到「有人詢問價格」。

第 6 週：你存進系統的三篇好文章，被 AI CEO 拆解成五個可複製的技法，寫進寫作模板。同一個 Build Agent，在更好的環境裡跑，輸出已經不是第一週的水準。

第 8 週：你每週花在系統上的時間，從五小時縮到三十分鐘。這三十分鐘全部用在一件事：看週報，給一個方向決定。

第 12 週：兩個 PMF 方向確認了，資源自動集中，其他循環暫停或重新設計。你準備好進入 Part 4——直接向客戶收錢。

你的輸入在遞減，系統的輸出在提升。

這就是複利。

你唯一要持續做的事

整個系統跑起來之後，有一件事沒辦法委託給任何 Agent：

告訴系統什麼是好的。

你偶爾讀到一篇讓你覺得「這篇很好」的文章，存起來。看到一個「這個 CTA 有效」的範例，存起來。在週報裡更新一行 PMF 訊號的定義，讓 AI CEO 的判斷更準。

AI CEO 拿你存進去的東西，拆解技法，更新環境，讓 Build Agent 下一輪的輸出更靠近你的品味。

你的品味，是這個系統的唯一上限。Claude Code，是把你的品味轉成系統規則的工程師。

這個上限只有你能拉高。而且你拉高一次，所有循環都受益。

Part 3 的終點，不是終點

CH07 你學了怎麼當 AI 的老闆。CH08 你建起了讓 Agent 工作的系統。CH09 你讓這個系統開始自己進化。

你從 BML 的執行者，走到了 BML 的設計者。

但「系統在跑」不是你的目標。「系統找到對的市場」才是。

當 PMF 訊號出現，你進入 Part 4：第一筆真的進來的錢。

今天的第一步

選一件你現在用 Agent 跑的重複性工作，問三個問題：

這個 Agent 上週的輸出，和第一週有什麼不同？（沒有不同，代表沒有 Learn 回路。）上週的失敗，這週有沒有可能再發生？（有，代表沒有環境更新。）如果讓 AI CEO 每週看一次這個 Agent 的輸出，它會更新哪一條規則？

第三個問題的答案，就是你的 Harness Engineering 起點。

一個 AGENTS.md，一個 Learn Agent 回路，一份每週成績單。從這三件事開始。

三個月後，你的系統和第一天已經不是同一個等級。不是因為模型升級了——是因為它生活的環境，每週都在變好。