我有多年產品出海的經驗，我很清楚什麼叫「慢」。
SaaS 產品開發的第一週，老實說，是整個過程中最痛苦的部分。
你整天都在自己的腦袋裡切換各種角色，一刻不得閒。
創辦人、研究員、產品經理、設計師、工程師、品保測試、行銷人員。
同一顆腦袋，卻要同時扮演七個完全不同領域的工作，而且還看不到任何進展。
我認識的大多數創辦人，整個第一週都在「思考如何思考」。他們打開一個空白文件，寫下三行要點，闔上筆電，泡杯咖啡，回來後刪掉那三行要點，然後重新開始。一週結束了，什麼具體成果都沒有，只留下一股日益增長的焦慮感和一個充滿半成品、毫無進展的筆記應用程式。
上個月，我受夠了這個循環，決定試試一個完全不一樣的方法。
我不再只用一個 AI 模型來處理所有事，而是開始像管理一個實際團隊那樣來使用 AI。
我利用 Kimi Agent Swarm 建立了七個專業化的 Agent，並賦予每個 Agent 一個特定的任務、一個要產出的特定成果，以及一條不容逾越的特定跑道。
一個下午。一個 SaaS 點子。七個 Agents 平行運作。一份完整的 MVP 藍圖在晚餐前就擺在我面前了。
以下就是我實際的做法，以及它有效的原因。
我交給它們執行的點子
這個產品概念是專為本地商家設計的「AI 網站審計 SaaS」。
這個問題顯而易見。五百萬家本地商家的網站看起來像是 2011 年蓋好之後就再也沒更新過。沒有預約按鈕、沒有手機版版面、沒有信任信號、沒有明確的行動呼籲、沒有評論區塊。什麼都沒有，無法將訪客轉換成電話。
一個水電工可能真的很會修水管，但卻因為網站看起來像廢棄的一樣，每天都在流失客戶。工作的品質和線上呈現的品質完全是兩回事。這個差距，就是機會。
這個 SaaS 的概念很簡單。只要輸入任何本地商家的網址，應用程式就會執行審計、產出分數、指出問題所在及原因，並產生一封準備好要寄給商家老闆的開發信。
目標用戶是自由工作者、網頁設計師和本地 SEO 代理商。任何向本地商家推銷網站和服務，並且需要更快速開啟對話的人。
讓這個點子成立的關鍵洞見是：審計本身不是產品，審計是銷售武器。
一封什麼都沒說、千篇一律的開發信，每次都會被忽略。但一封寫著「你的手機預約按鈕故障了，你的首頁沒有信任信號，而你街對面的競爭對手有比你多三百篇評論和更快的預約流程」的信，真的會得到回覆。具體，才能讓人們願意注意。而這個 SaaS 能在六十秒內自動產出這種具體性。
為什麼大多數人完全用錯了 AI 來做開發
在進入工作流程之前，這部分很重要，因為它說明了這個方法為什麼有效。
大多數創辦人把 AI 當成一個稍微強大的聊天機器人來用。他們給同一個模型一個巨型提示詞，要求它同時研究市場、設計 UI、開發後端、撰寫登陸頁面、規劃產品發布。
結果產出的內容很膚淺，因為它本質上就是膚淺的。
一個模型在同一個對話中切換七種完全不同的思考模式，只會在每一種模式中產出平庸的結果。這不是模型品質的問題，這是結構性的問題。
研究員的思考方式和設計師不同。後端工程師的思考方式和行銷人員不同。品保測試員的思考方式和產品經理不同。這些不僅是不同任務，更是截然不同的認知模式。當這些模式在同一個對話視窗內彼此競爭時，就無法產出更好的成果。
Agent 群組（Agent Swarm）背後的核心洞見很直接：專業化產出的成果優於通用化。這並不是什麼新觀念，這正是公司會雇用團隊，而不是只找一個人做所有事的根本原因。
Kimi Agent Swarm 將同樣的邏輯應用在 AI 上。與其要求一個模型幫你建立一個 SaaS，不如圍繞任務建立一個小型的 AI 公司。每個 Agent 負責一個角色。每個 Agent 產出一個成品。創辦人負責管理整個系統並審查產出，而不是親手做每一項任務。
這個轉變聽起來很微小，但在實務上，它徹底改變了整個一週的感覺。
我建立的七個 Agents
Agent 1 是研究 Agent。它的工作是驗證市場、找出真正的目標客戶、描繪競爭格局、並浮現出核心使用案例。其他什麼都不做。
Agent 2 是產品經理 Agent。它的工作是用近乎殘酷的誠實態度定義 MVP 的範圍，砍掉所有非必要的功能，描繪核心用戶旅程，並設定定價模式。其他什麼都不做。
Agent 3 是 UX Agent。它的工作是設計頁面結構、用戶流程、儀表板佈局和報告佈局。其他什麼都不做。
Agent 4 是前端工程師 Agent。它的工作是建立 UI 計畫並定義完整的元件結構。其他什麼都不做。
Agent 5 是後端工程師 Agent。它的工作是設計審計邏輯、評分系統、API 結構和資料模型。其他什麼都不做。
Agent 6 是 QA Agent。它的工作是攻擊整個計畫、找出錯誤、浮現缺失狀態、識別邊界案例、揭露所有未來可能出問題的假設。其他什麼都不做。
Agent 7 是發布 Agent。它的工作是撰寫登陸頁面文案、發布貼文、開發信模板和產品定位。其他什麼都不做。
每個 Agent 先獨立運作，然後再將所有產出合併成一個完整的建置計畫。
這就是它和與單一 AI 模型進行長時間對話的根本區別。沒有上下文切換，沒有某個章節說的話和另一個章節的假設之間存在隱含的矛盾。每個 Agent 堅守自己的跑道，並從那個跑道產出清晰的成果。
我用來啟動的主要提示詞
這就是我提供給 Kimi 開啟會話的提示詞。你可以把它當作起點，並根據你要建立的東西進行調整。
<code-segment id="0" lang="text">
為本地服務業商家建立一個 AI 網站審計 SaaS。目標用戶是自由工作者、代理商老闆、本地 SEO 顧問，以及向水電工、暖通空調公司、屋頂修繕公司、電工和牙醫推銷服務的網頁設計師。核心工作流程：使用者輸入本地商家網址，應用程式審計網站，產出分數、問題清單、改善核對清單、客戶報告和開發信。將此任務拆分給七個專業 Agent。研究 Agent 負責驗證市場和客戶。產品 Agent 負責定義 MVP 範圍、功能和定價。UX Agent 負責設計用戶流程、儀表板和報告佈局。前端 Agent 負責定義 UI 結構和元件。後端 Agent 負責設計評分邏輯、審計系統和 API。QA Agent 負責識別邊界案例、缺失狀態和失敗模式。發布 Agent 負責撰寫登陸頁面、發布貼文、開發信和產品定位。每個 Agent 先獨立運作，然後將所有產出合併成一個最終的 MVP 計畫。
</code-segment>
大多數人只會寫一個版本，然後等待一個大答案。而群組的意義在於，每個 Agent 都能從自己的角度產出一個真實的成品，而不知道其他 Agent 在做什麼。研究員不會去思考按鈕顏色。UX 設計師不會去創造定價模式。QA 測試員會攻擊而不是防守。發布 Agent 不會碰觸後端。分離就是這個系統的關鍵。
每個 Agent 實際產出的內容
研究 Agent 找到了四個重要的真實客戶群體：向本地商家推銷網站改版服務的網頁設計師、以月費方式提供審計保留服務的 SEO 代理商、利用開發信尋找新客戶的自由工作者，以及將潛在客戶生成服務產品化的獨立創辦人。
它浮現出的最重要洞見，就是我之前提過、但值得一再強調的：審計本身不是產品，審計是銷售武器。向本地商家推銷服務的人需要一個更快的方法，來建立個人化且具體的審計報告，讓他們有一個值得一讀的理由去接觸客戶。研究 Agent 在還沒設計任何一個畫面之前，就將此定位為整個產品的核心。
產品經理 Agent 毫不留情地縮減了範圍。
第一個版本只需要五個畫面：首頁、審計輸入頁面、載入與進度頁面、審計結果頁面、報告匯出頁面。
沒有團隊帳號、沒有帳務整合、沒有 CRM 連接、沒有瀏覽器擴充功能、沒有市集、沒有第三方 API 存取。通通都沒有。
只有一個能順暢運作的單一工作流程：輸入網址、取得審計、發送報告、贏下案子。
核心的 MVP 功能很直接：網站 URL 輸入、商家類別選擇器、0 到 100 分的審計分數、轉換核對清單、行動裝置就緒核對清單、信任信號核對清單、CTA 核對清單、報告摘要、開發信產生器，以及給發送報告的自由工作者參考的建議服務定價。
這對第一個版本來說已經足夠了。一個 SaaS 的 MVP 不需要完整，它需要證明一個工作流程能夠從頭到尾不中斷地運作。
UX Agent 設計的五步驟用戶旅程清晰明瞭，這通常需要人類設計師花一整天才能完成。
步驟一：貼上網址並選擇商家類型。步驟二：應用程式執行審計，並顯示可視化的進度條。步驟三：查看總體分數。步驟四：以白話文查看具體哪裡有問題及原因。步驟五：下載報告並取得準備好發送的開發信。
UX Agent 產出的報告佈局，是真正讓我驚豔的部分。
網站分數：62 分（滿分 100 分）。讓您流失客戶的原因：沒有可見的預約按鈕、手機版佈局薄弱、沒有 Google 評論區塊、沒有緊急服務 CTA、頁面頂部信任建立速度慢。快速致勝點：加入點擊通話按鈕、將評論移到頁面頂部、加入服務區域說明、加入前後對比照片、加入預約表單。商業影響：您的網站正在流失準備好立即來電的手機用戶。
不技術、不充滿行話。清楚到讓水電工能在三十秒內閱讀並理解。這就是自由工作者要發送的內容。這就是能幫你預約到會議的內容。
後端 Agent 建立了橫跨五個類別的評分系統，每個類別內部都有特定的加權檢查項目。
設計清晰度：20 分。行動裝置就緒度：20 分。轉換就緒度：25 分。信任信號：20 分。本地 SEO 基礎：15 分。總分 100 分，每一分都能追溯到網站上一個特定的、可觀察的功能。
這一點比它看起來的更重要。分數必須是可解釋的，才會有可信度。一個無法追溯的「黑箱 AI 分數」感覺很假，會被忽略。一個有具體明確理由附在每一個分項後面的分數，感覺很有用，而且會被轉發給商家老闆，並附上一段備註。
QA Agent 是整個群組中價值最高的 Agent，而且遙遙領先。
QA Agent 只擅長一件事：攻擊。而一個專門攻擊計畫的 Agent，對之前的工作成果沒有任何情感依戀。
Kimi 的 QA Agent 立刻浮現出那些未來會造成真正損害的問題。如果網址錯誤或輸入錯誤怎麼辦？如果網站完全封鎖網路爬蟲怎麼辦？如果網站幾乎沒有文字內容可以分析怎麼辦？如果商家在任何地方都沒有評論怎麼辦？如果兩個審計類別產出矛盾的結果怎麼辦？如果產生的開發信聽起來太咄咄逼人，在關係開始前就破壞了自由工作者的商譽怎麼辦？
這些問題中的每一個，都揭示了計畫中的一個缺口，需要在撰寫任何一行程式碼之前就解決。
它建議的修正方案非常具體：針對封鎖爬蟲的網站設計備用狀態、加入人工備註欄位，讓自動審計無法驗證時可以進行人工覆寫、為每個發現結果附加一個信心分數，讓自由工作者知道哪些是可靠的、哪些需要檢查、為不同情況提供語氣較溫和的郵件選項，以及在任何外展郵件實際發送前，加入一個人為審查步驟。
最後這一點很重要，我想直接說清楚：你不希望有五百封平庸的開發信自動附上你的名字發送出去。你希望有五百封高品質的草稿，經過人為審查和批准後才發出。群組負責處理繁重的工作，創辦人則擔任編輯的角色。
發布 Agent 用一句話就產出了產品定位，這比我自己思考了兩天寫出來的任何東西都要好。
「把糟糕的本地商家網站，變成客戶機會。」
這在任何方面都比「AI 網站審計工具」強太多了。沒有人一早醒來是為了想要一個審計工具，他們是為了想要客戶。這個定位反映了用戶真正想要的東西，而不是產品技術上做了什麼。
Agent 寫的登陸頁面標題和副標題同樣簡潔有力：「把糟糕的本地商家網站，變成客戶機會。輸入任何網址。立即取得審計。發送個人化報告。成交。沒有任何廢話，沒有掩蓋價值的聰明文字遊戲，只是清楚地陳述承諾。」
那個下午總共產出了什麼
當所有七個 Agents 完成工作，並將所有產出合併成一份文件時，我得到了以下成果：
- 一個經過驗證的市場和真實的目標客戶輪廓
- 一個範圍嚴謹、只有五個畫面、完全沒有功能蔓延的 MVP 範圍
- 一個逐步描繪好的完整用戶旅程
- 一個滿分 100 分、每個分項都有特定檢查項目的評分系統
- 一個 UI 結構和完整的元件清單
- 一個以客戶為中心、以清晰白話文為設計目標的報告佈局
- 一份涵蓋 Agents 能識別出的所有邊界案例的 QA 核對清單
- 可立即使用的登陸頁面文案
- 一篇產品發布當天的發布貼文
- 一封針對本地商家老闆個人化的開發信模板
這不是一個已經成立的公司。沒有人這樣聲稱。
但這比大多數創辦人在獨自思考一整個星期後所擁有的還要多，而我只花了一個下午，而不是七天。
群組做不到的事，以及你依然重要的地方
我想直接說明這點，因為大多數關於 AI 工具的文章都會完全跳過，而這種不誠實正是讓人們什麼都不相信的原因。
Kimi 並沒有建立一個 SaaS。它建立了一個 SaaS 的藍圖。其中的差異是真實且重大的。
一個可運作的產品仍然需要撰寫並測試產品級程式碼。它需要真實的使用者來嘗試，並以沒有人預料到的方式來破壞它。它需要金流處理、主機託管和妥善的錯誤處理。它需要在出問題時提供客戶支援。它需要一套不會在你停止推廣時就停止運作的經銷策略。它需要針對真人、真金白銀進行定價測試。在任何東西對外發布前，都需要手動 QA。
有些網站會封鎖爬蟲，需要一個備用方案。有些審計結果在發送給客戶前需要人工驗證。有些郵件在發出前需要再讀一遍。
這不是「按個按鈕就能致富」。任何告訴你相反說法的人，都是在兜售某樣東西。
老實說，它的真正價值比這更實際。群組取代了過去需要花一整個星期、盯著空白文件、並在七種不同思維模式間切換的、那混亂的前 70% 產品思維工作。創辦人仍然掌握品味、判斷力和實際產品交付的責任。改變的是起點。
你不再從一個空白頁面和一個焦慮的循環開始，而是從一份研究報告、一份產品規格、一個評分系統、一個 UI 流程和一個發布計畫開始。認知負擔立刻下降。早期決策變得更快，因為思考已經被結構化了。從第一個小時開始，這一週的感覺就完全不同了。
可儲存並使用的工作流程
步驟一：寫下一個清晰的點子，包含問題、特定用戶和核心工作流程。一個段落就好，不要更多。
步驟二：開啟 Kimi Agent Swarm。
步驟三：指派七個 Agents，賦予特定角色和特定產出。不是一般性指示，而是來自各自跑道的具體交付物。
步驟四：讓每個 Agent 完全獨立地產出它的成品，不參考其他 Agents。
步驟五：讓 QA Agent 對完整的合併計畫進行攻擊，對任何工作成果都不帶感情。
步驟六：將所有產出合併成一份 MVP 藍圖文件。
步驟七：只建立能證明核心工作流程可以從頭到尾順暢運作的最小產品版本。
步驟八：在加入任何一個額外功能之前，先用五個真實使用者進行測試。真實的使用者會打破沒有任何 Agent 能浮現出的假設，因為假設只會在現實中破滅。
大多數創辦人的錯誤是要求 AI 建立一切。更好的做法是要求 Agents 消除開始時的混亂，讓思維在開始建構之前就先被結構化。
研究變得清晰。範圍變得清晰。畫面變得清晰。風險變得清晰。發布角度變得清晰。所有通常需要一整個星期混亂切換的工作，都被壓縮成一個專注的下午。
正在發生的轉變
這是我在執行這個方法並仔細思考後，真心相信的事情。
下一代的創辦人將不僅僅是用 AI 來撰寫文案或摘要文件。他們將會像創辦人管理團隊一樣管理群組。一個 Agent 研究市場。一個 Agent 設計產品。一個 Agent 建立後端計畫。一個 Agent 測試假設。一個 Agent 撰寫發布文案。
創辦人不再是執行每一項任務的人，而是開始成為指導系統、審查產出、運用品味和判斷力，並決定什麼可以發布的人。
這不是一個微小的改變。這是一個根本性的轉變，改變了產品建構第一週的樣貌，以及在任何一行產品級程式碼被寫出來之前，可能達成的成果。
首先弄清楚這一點的創辦人，相較於那些仍然在一個疲憊的腦袋中切換七種角色的人，將擁有不公平的優勢。
以前：一個創辦人在七種角色間切換，寫一行程式碼之前先浪費一週，將認知能量消耗在結構而非實質上。
之後：七個 Agents 平行運作，在一天結束前就交回一份完整的 MVP 藍圖，創辦人的精力則保留給那些真正需要人類判斷的決策。
過去這需要獨自掙扎一整個星期。
現在，從一個提示詞和一個下午開始。
追蹤我，了解更多真正能改變你建構方式的實戰系統。
