我用 13 個 Agent 跑完一個 AI 工具站，發現真正難的不是寫代碼

大家好，我係孟健。

呢幾日我用 13 個 Agent 跑完一個真實嘅 AI 工具站，最後發現：出問題最多嘅地方，唔係寫 code，係交接。

而家 Codex、Claude Code、Cursor、Copilot 都喺度向同一個方向行：多 Agent、後台任務、並行執行、遠程接管。

OpenAI 將 Codex App 定位做 "command center for agents"，支援多個 coding agent 並行運行同長任務協作。GitHub Copilot cloud agent 可以直接由 issue 啟動，自動創建 PR，請求人工 review。

Cursor 都喺度向 automations、background agents 方向推，支援 schedule、GitHub、GitLab、Slack、webhook 等多種觸發方式。

工具廠商都喺度將 coding agent 平台化。能力變強之後，新嘅問題都出現咗：多 Agent 嘅時代，邊個負責交接？

01 多 Agent 唔係多開幾個聊天視窗

多開 Agent 好容易。難嘅係每一棒都可以俾下游接住。

一條真正用得嘅 Agent 流程，必須回答 4 個問題：

• 輸入係咩？
   上一棒俾咗啲咩。
• 輸出係咩？
   呢一棒交出啲咩。
• 證據係咩？
   點證明呢棒 DONE 咗。
• 幾時必須停？
   BLOCKED 嘅條件係咩。

呢 4 個問題答得唔清楚，Agent 越多，噪音越大。

Agent 越多，越唔可以靠感覺推進。

02 我真係跑咗一次：aicodingpricing.com

案例係 aicodingpricing.com，一個比較 AI 編程工具定價嘅工具站。

由關鍵詞到上線後覆盤，13 個 Agent 依次接力：市場研究 → SEO 複核 → PRD → 定價 → 合規 → 文案 → 設計 → 前端 → 後端 → QA → 運營 → 數據覆盤，加一個主持台負責節奏同 GO/NO-GO。

每一棒都有明確嘅輸入來源、輸出格式、交接文檔同暫停條件。站整咗出嚟，而且唔止一個首頁，仲包括具體嘅對比頁面：

呢個案例真正有價值嘅地方，係佢暴露咗邊啲位置——如果冇閘門，就會出事。

03 13 個 Agent 點分工

寫成可讀嘅版本：

1. 市場研究
    — 判斷關鍵詞有冇機會
2. SEO 複核
    — 睇 SERP 競爭難度同頁面矩陣
3. PRD
    — 將機會變成頁面、功能、驗收標準
4. 定價
    — 睇競品、成本同套餐邊界
5. 合規
    — 檢查文案聲明、數據風險
6. 文案
    — 生成首頁、功能頁、結果頁 copy
7. 設計
    — 出頁面結構同視覺方向
8. 前端
    — 實現頁面同交互
9. 後端
    — 處理 API、存儲、鑑權、支付
10. QA
     — 功能、異常態、移動端、SEO、合規、埋點
11. 運營
     — 提交目錄、冷啟動、外鏈同渠道
12. 數據覆盤
     — 接管 GSC、Bing、GA4、Plausible、Clarity
13. 主持台
     — 負責節奏、BLOCKED、GO/NO-GO、交接

ShipSolo 將呢 13 個階段封裝成 Skills，每個階段有標準輸入同輸出模板：

一個 Agent 做錯事唔可怕，可怕係錯事俾包裝成 DONE 傳俾下一棒。

04 真正踩坑嘅地方

跑完呢一次，坑主要在 4 處。

SEO / 合規 NO-GO 唔可以俾情緒壓過去。 aicodingpricing.com 揀詞階段，有幾個關鍵詞搜索量睇落唔錯，但 SERP 前三頁全部都係大廠官網同頭部評測媒體。市場研究 Agent 打出 BLOCKED，原因係短期滲透機會極小，繼續推進只係喺錯誤嘅方向上浪費曬所有後續棒次嘅時間。呢個結論唔好聽，但佢卡住咗。文案同設計冇喺錯誤嘅詞上將功夫用完。合規同理：法務冇畀出明確結論之前，頁面唔可以上承諾性語句，唔可以用 "更便宜" "保證準確" 呢類表述。呢一關含糊過去，後面所有棒都喺度做無效功，上線咗都要全部推翻重來。

PM gate 必須喺設計同研發前卡住。 今次做站，路由合約喺 PRD 階段就固定咗：邊啲係靜態頁、邊啲要接 API、對比表嘅字段定義、結果頁嘅幾種狀態。呢件事冇定，設計稿就係一次過嘅。前端接咗再改字段，要動 API、動組件、動設計，每一層都要返工。路由合約簽完之後，設計先啟動，前端先接任務。呢個順序睇落慢，但佢慳咗嘅係最貴嗰部分——已經整出嚟嘅嘢被推翻。

QA 唔可以缺席，都唔可以提前。 QA 階段覆蓋 6 類檢查：功能邏輯啱唔啱、異常態有冇兜底（空狀態、超長內容、網絡斷開）、移動端係咪走樣、canonical 同 sitemap 係咪正確生成、合規文本係咪同法務稿保持一致、埋點事件係咪真實觸發並攜帶正確參數。每一類都要有截圖存檔，逐項打勾，唔係 "大體冇問題"。"大體冇問題" 呢四個字，上線後會變成 GSC 收錄問題、Clarity 熱圖空白、轉化漏斗斷層。任何一項缺席，上線之後就係黑盒。

數據接管唔可以淨係睇腳本有冇黐貼入去。 GSC、Bing、GA4、Plausible、Clarity 每一個工具都要行四個驗證狀態：未配置 → 已配置冇數據 → 有數據唔可歸因 → 有數據可歸因。呢四態之間嘅跨度可以係幾小時，都可以係幾天，取決於流量體量同工具本身嘅採樣機制。有腳本唔等於有數據，有數據唔等於能做決策。唔提前按狀態逐步對賬，D7 覆盤時面對嘅就係一堆猜測，覆盤等於冇做。

BLOCKED 唔係失敗，係安全閥。

05 9 個硬閘門

每個階段攔得落嘅問題，都要攔喺平嘅時候。

1. Keyword gate
    — 關鍵詞競爭度、搜索意圖、變現路徑，三項同時成立先入 PRD。只有搜索量冇轉化意圖，係最浪費時間嘅方向，比直接做錯仲難發現。
2. Route contract
    — 頁面列表、URL 結構、數據狀態、canonical 規則、sitemap 收錄邏輯，PRD 完成後即刻鎖定，設計同前端共同簽字確認，後續唔允許單方面改。
3. SEO-Copy Freeze
    — SEO 關鍵詞矩陣同文案草稿凍結後，設計先開始排版，前端先接內容。文案改一次，設計稿廢一版，前端改一輪，呢個係三倍代價，要喺呢一關攔住。
4. Content-fit matrix
    — 每個頁面都要答得到：點解存在、目標用戶係邊個、佢哋嚟咗之後要做啲咩。答唔到嘅頁面，整出嚟都冇人睇，SEO 都唔會收錄。
5. Data Contract
    — 埋點事件名、參數結構、口徑定義、四態驗收標準，喺前端開發前寫清楚，QA 按合同逐項驗，唔係上線後發現缺口先補救。
6. PM gate
    — 產品驗收必須覆蓋所有頁面狀態，包括空態、異常態、邊界值，通過後先入大規模實現，唔允許 "先做完再補產品文檔"。
7. QA / SEO / Compliance GO
    — 三者獨立畀出結論，同時通過，先算準備上線。任何一個 NO-GO，整個流程暫停，唔允許帶住問題上線 "先睇睇效果"。
8. Analytics 四態驗證
    — 逐步確認，每一態截圖存檔。可歸因先做到決策，之前嘅所有狀態都係過渡態，唔算接管完成。
9. D7 / D14 / D30 覆盤
    — 上線唔係結束。D7 睇收錄同首批流量來源，D14 睇關鍵詞排名變化，D30 做完整嘅轉化同收入覆盤。冇呢三個節點，上線等於掟出去唔理。

NO-GO 嘅價值，係將錯誤攔喺平嘅時候。

06 俾想複製嘅人

唔好一開頭就追速度。

先由一個站將 13 個階段完整跑一次。唔求快，求每一棒都可以俾接住。每個階段只要求 4 件事：清楚嘅輸入、明確嘅輸出、可驗證嘅證據、允許 BLOCKED 嘅暫停條件。呢 4 件事到位，邊個 Agent 跑慢咗、邊個階段需要人工介入、喺邊度卡住，都有地方可以查。

呢套流程真正發揮作用嘅時刻，往往係你最想跳過某一關嘅時候。市場研究打出 BLOCKED，你已經諗好咗站名、諗好咗頁面結構，甚至規劃好咗上線時間——但閘門唔開。呢種時候俾攔落嚟，代價最小。繞過去繼續推，代價喺後面，而且越到後面越貴。

aicodingpricing.com 今次，市場研究同 SEO 兩棒都 GO 之後先入 PRD，路由合約鎖定之後文案同設計先同步推進，QA 三項全部 GO 之後先上線。每一棒都有明確嘅交出物，下一棒先有嘢可以接。節奏唔亂，靠嘅係閘門，靠嘅係每一棒都有人接。

領航計劃同 ShipSolo 教嘅係將 AI 編程變成一條可上線、可覆盤、可迭代嘅交付流程。複製嘅係呢套交接邏輯，每一棒嘅輸入輸出要求，同允許 BLOCKED 嘅流程文化。

AI 編程接下來會越來越勁。

勁工具只會放大原來嘅流程。流程清楚，佢放大交付。流程混亂，佢放大混亂。

工具已經夠快喇。而家應該補嘅，係閘門。

🚀 想同更多 AI 愛好者交流，共同成長嗎？

同一班志同道合嘅人，持續精進 AI 嘅每一天

大家好，我是孟健。

這幾天我用 13 個 Agent 跑完了一個真實 AI 工具站，最後發現：出問題最多的地方，不是寫代碼，是交接。

現在 Codex、Claude Code、Cursor、Copilot 都在往同一個方向走：多 Agent、後台任務、並行執行、遠程接管。

OpenAI 把 Codex App 定位成"command center for agents"，支持多個 coding agent 並行運行和長任務協作。GitHub Copilot cloud agent 可以直接從 issue 啓動，自動創建 PR，請求人工 review。

Cursor 也在往 automations、background agents 方向推，支持 schedule、GitHub、GitLab、Slack、webhook 等多種觸發方式。

工具廠商都在把 coding agent 平台化。能力變強後，新的問題也冒出來了：多 Agent 的時代，誰負責交接？

01 多 Agent 不是多開幾個聊天窗口

多開 Agent 很容易。難的是每一棒都能被下游接住。

一條真正能用的 Agent 流程，必須回答 4 個問題：

• 輸入是什麼？
   上一棒給了什麼。
• 輸出是什麼？
   這一棒交出什麼。
• 證據是什麼？
   怎麼證明這棒 DONE 了。
• 什麼時候必須停？
   BLOCKED 的條件是什麼。

這 4 個問題回答不清楚，Agent 越多，噪音越大。

Agent 越多，越不能靠感覺推進。

02 我真實跑了一遍：aicodingpricing.com

案例是 aicodingpricing.com，一個比較 AI 編程工具定價的工具站。

從關鍵詞到上線後覆盤，13 個 Agent 依次接棒：市場研究 → SEO 複核 → PRD → 定價 → 合規 → 文案 → 設計 → 前端 → 後端 → QA → 運營 → 數據覆盤，加一個主持台負責節奏和 GO/NO-GO。

每一棒都有明確的輸入來源、輸出格式、交接文檔和暫停條件。站做出來了，而且不止一個首頁，還包括具體的對比頁面：

這個案例真正有價值的地方，是它暴露了哪些位置——如果沒有閘門，就會出事。

03 13 個 Agent 怎麼分工

寫成可讀的版本：

1. 市場研究
    — 判斷關鍵詞有沒有機會
2. SEO 複核
    — 看 SERP 競爭難度和頁面矩陣
3. PRD
    — 把機會變成頁面、功能、驗收標準
4. 定價
    — 看競品、成本和套餐邊界
5. 合規
    — 檢查文案聲明、數據風險
6. 文案
    — 生成首頁、功能頁、結果頁 copy
7. 設計
    — 出頁面結構和視覺方向
8. 前端
    — 實現頁面與交互
9. 後端
    — 處理 API、存儲、鑑權、支付
10. QA
     — 功能、異常態、移動端、SEO、合規、埋點
11. 運營
     — 提交目錄、冷啓動、外鏈和渠道
12. 數據覆盤
     — 接管 GSC、Bing、GA4、Plausible、Clarity
13. 主持台
     — 負責節奏、BLOCKED、GO/NO-GO、交接

ShipSolo 把這 13 個階段封裝成 Skills，每個階段有標準輸入和輸出模板：

一個 Agent 做錯事不可怕，可怕的是錯事被包裝成 DONE 傳給下一棒。

04 真正踩坑的地方

跑完這一遍，坑主要在 4 處。

SEO / 合規 NO-GO 不能被情緒壓過去。 aicodingpricing.com 選詞階段，有幾個關鍵詞搜索量看起來不錯，但 SERP 前三頁全是大廠官網和頭部評測媒體。市場研究 Agent 打出 BLOCKED，原因是短期滲透機會極小，繼續推進只是在錯誤的方向上浪費所有後續棒次的時間。這個結論不好聽，但它卡住了。文案和設計沒有在錯誤的詞上把功夫用完。合規同理：法務沒有給出明確結論之前，頁面不能上承諾性語句，不能用"更便宜""保證準確"這類表述。這一關含糊過去，後面所有棒都在做無效功，上線了也要全部推翻重來。

PM gate 必須在設計和研發前卡住。 這次做站，路由合約在 PRD 階段就固定了：哪些是靜態頁、哪些要接 API、對比表的字段定義、結果頁的幾種狀態。這件事沒有定，設計稿就是一次性的。前端接了再改字段，要動 API、動組件、動設計，每一層都要返工。路由合約簽完之後，設計才啓動，前端才接任務。這個順序看起來慢，但它省掉的是最貴的那部分——已經做出來的東西被推翻。

QA 不能缺席，也不能提前。 QA 階段覆蓋 6 類檢查：功能邏輯對不對、異常態有沒有兜底（空狀態、超長內容、網絡斷開）、移動端是否跑偏、canonical 和 sitemap 是否正確生成、合規文本是否與法務稿保持一致、埋點事件是否真實觸發並攜帶正確參數。每一類都要有截圖存檔，逐項打勾，不是"大體沒問題"。"大體沒問題"這四個字，上線後會變成 GSC 收錄問題、Clarity 熱圖空白、轉化漏斗斷層。任何一項缺席，上線之後就是黑盒。

數據接管不能只看腳本有沒有粘貼進去。 GSC、Bing、GA4、Plausible、Clarity 每一個工具都要走四個驗證狀態：未配置 → 已配置無數據 → 有數據不可歸因 → 有數據可歸因。這四態之間的跨度可以是幾小時，也可以是幾天，取決於流量體量和工具本身的採樣機制。有腳本不等於有數據，有數據不等於能做決策。不提前按狀態逐步對賬，D7 覆盤時面對的就是一堆猜測，覆盤等於沒做。

BLOCKED 不是失敗，是安全閥。

05 9 個硬閘門

每個階段能攔下的問題，都要攔在便宜的時候。

1. Keyword gate
    — 關鍵詞競爭度、搜索意圖、變現路徑，三項同時成立才進 PRD。只有搜索量沒有轉化意圖，是最浪費時間的方向，比直接做錯還難發現。
2. Route contract
    — 頁面列表、URL 結構、數據狀態、canonical 規則、sitemap 收錄邏輯，PRD 完成後立刻鎖定，設計和前端共同簽字確認，後續不允許單方面改。
3. SEO-Copy Freeze
    — SEO 關鍵詞矩陣和文案草稿凍結後，設計才開始排版，前端才接內容。文案改一次，設計稿廢一版，前端改一輪，這是三倍代價，要在這一關攔住。
4. Content-fit matrix
    — 每個頁面都要能回答：為什麼存在、目標用戶是誰、他們來了之後要做什麼。答不上來的頁面，做出來也沒人看，SEO 也不會收錄。
5. Data Contract
    — 埋點事件名、參數結構、口徑定義、四態驗收標準，在前端開發前寫清楚，QA 按合同逐項驗，不是上線後發現缺口再補救。
6. PM gate
    — 產品驗收必須覆蓋所有頁面狀態，包括空態、異常態、邊界值，通過後才進大規模實現，不允許"先做完再補產品文檔"。
7. QA / SEO / Compliance GO
    — 三者獨立給出結論，同時通過，才算準備上線。任何一個 NO-GO，整個流程暫停，不允許帶着問題上線"先看看效果"。
8. Analytics 四態驗證
    — 逐步確認，每一態截圖存檔。可歸因才能做決策，之前的所有狀態都是過渡態，不算接管完成。
9. D7 / D14 / D30 覆盤
    — 上線不是結束。D7 看收錄和首批流量來源，D14 看關鍵詞排名變化，D30 做完整的轉化和收入覆盤。沒有這三個節點，上線等於扔出去不管了。

NO-GO 的價值，是把錯誤攔在便宜的時候。

06 給想複製的人

不要上來就追速度。

先從一個站把 13 個階段完整跑一遍。不求快，求每一棒都能被接住。每個階段只要求 4 件事：清楚的輸入、明確的輸出、可驗證的證據、允許 BLOCKED 的暫停條件。這 4 件事到位，哪個 Agent 跑慢了、哪個階段需要人工介入、在哪裏卡住，都有地方可查。

這套流程真正發揮作用的時刻，往往是你最想跳過某一關的時候。市場研究打出 BLOCKED，你已經想好了站名、想好了頁面結構，甚至規劃好了上線時間——但閘門不開。這種時候被攔下，代價最小。繞過去繼續推，代價在後面，而且越到後面越貴。

aicodingpricing.com 這次，市場研究和 SEO 兩棒都 GO 之後才進 PRD，路由合約鎖定之後文案和設計才同步推進，QA 三項全部 GO 之後才上線。每一棒都有明確的交出物，下一棒才有東西可以接。節奏不亂，靠的是閘門，靠的是每一棒都有人接。

領航計劃和 ShipSolo 教的是把 AI 編程變成一條可上線、可覆盤、可迭代的交付流程。複製的是這套交接邏輯，每一棒的輸入輸出要求，和允許 BLOCKED 的流程文化。

AI 編程接下來會越來越強。

強工具只會放大原來的流程。流程清楚，它放大交付。流程混亂，它放大混亂。

工具已經夠快了。現在該補的，是閘門。

🚀 想要與更多AI愛好者交流，共同成長嗎？

和一羣志同道合的人，持續精進 AI 的每一天