大多數關於獨自經營企業的建議，都在教你「做少一點」。但這篇文章恰恰相反。它談的是那些你早就知道該做、卻始終沒時間做的事，以及如何將它們自動化，讓它們在你每次啟動之前就自行運轉。
我花了一個下午建構了整個系統，並用真實檔案實際運作。以下是這個系統的設定方式、運作結果，以及那些讓我驚訝的部分。
本文涵蓋內容：
- 將業務劃分為不同「車道」
- 一次性撰寫背景脈絡
- 劃定審核界線
- 為每個車道下達簡報，附上五個可直接套用的範例
- 設定排程
- 第一天實際運作的結果
- Uber、Spotify 和 Stripe 的相同模式
- 建置清單
總共五個步驟，按順序進行。前三步完全與 AI 無關，只用到 Slack 和一個檔案資料夾，這是刻意為之。大部分的工作量落在第二步和第三步，而這也是人們最常跳過的環節——正因如此，這類系統往往在第二週就宣告失敗。
步驟 1. 將業務劃分為車道
最常見的錯誤是：只用一個助手搭配一個龐大的提示詞，期望它能處理所有事情。真正有效的做法恰恰相反：一個車道、一項任務、一個專屬的運作空間。
對於服務型企業來說，五個車道幾乎涵蓋了一切：
客戶。 掌握每位客戶處於哪個階段、本週要交付什麼、遇到什麼阻礙、以及卡在誰手上。
潛在客戶。 針對符合條件的公司進行研究，並草擬初步接觸的文案。這裡不會實際寄出任何東西。
交付。 實際的工作產出，無論你的業務內容是什麼。
報告。 從你的平台拉取數據，並草擬成可供審閱的報告。
財務。 草擬發票，以及每週的財務摘要，包含已開立、已付款和逾期款項。
每個車道在 Slack 或 Teams 中都擁有自己的頻道，而不是資料夾、分頁或頻道。原因是：頻道本身就帶有歷史紀錄，而這些歷史紀錄就是不需要任何人重新解釋的脈絡。
圖 1. 五個車道、每個車道的產出，以及它絕對不被允許做的一件事。
步驟 2. 一次性撰寫背景脈絡
這一步決定了整個系統能否成功，但也是大家最常跳過的環節。
每個車道都有一則置頂訊息。把它想像成你為一個實際做這份工作的人所寫的職位描述——如果你必須寫下來，而不是花三週時間慢慢解釋。
這則訊息需要包含四項內容：
我們賣什麼，賣給誰。 一兩行即可。所有後續工作都取決於此。
這個車道交付什麼。 具體的產出名稱，而不是負責的領域。
什麼情況需要升級處理。 那些需要停下來請示的狀況。
絕不讓步的規則。 簡短扼要，最多五六行。
以下是我系統中財務車道的置頂訊息，未經修改：
預付聘金於每月一號開立帳單。專案工作則於交付時開立帳單。金額與條款皆記錄在 Google Drive 的客戶資料庫中。
在此處建立發票草稿並發布以供審閱。切勿完成最終版本、切勿寄出、切勿將任何款項標記為已付款。
每週五下午 4:00 發布摘要：已開立發票、已付款發票、逾期發票（含逾期天數）、本月至今總額。不超過 10 行。
任何逾期超過 14 天的款項，請在摘要頂部單獨標示，並附上客戶名稱與金額。
請注意它的結構：事實、交付物、節奏，最後是限制。我撰寫的每個車道都遵循這個模式，而最後一段永遠是一個限制。
裁決檔案。 除了置頂訊息之外，另外維護一個檔案，每次修正都只以一行文字記錄。這不是一份寫完就放著的檔案，而是一個持續更新的清單。當你修正某件事時，修正內容就記錄在這裡，每個車道在開始工作前都會讀取它。
我的檔案裡有像這樣的內容：
每次預約諮詢的成本是關鍵指標，而不是每個潛在客戶的成本。任何廣告活動都不得在未暫停的狀態下建立，無論在哪個帳戶、基於任何理由。報告中的每個數字都必須附上來源和日期範圍，否則該數字不得納入報告。
這個檔案能讓一次修正變成永久性的規則，而不是一而再、再而三地重複修正。它是整個系統中槓桿效益最高的一環，而你只需要每次花一行文字的成本。
圖 2. 潛在客戶車道中的一則置頂脈絡訊息，上方是主題行。
步驟 3. 劃定審核界線，並且永不移動它
有些工作是可逆的，有些則是不可逆的。一次性將所有行動歸類到這兩個類別中，其餘的設定就會變得簡單。
無需請示即可執行。 閱讀、研究、草擬、總結、以暫停狀態建構東西。如果錯了，刪掉就好。
必須等你批准。 寄送、發布、花費、完成最終版本、上線。如果錯了，你就得向客戶道歉。
實際上，這意味著我的五個頻道中有三個在置頂訊息中明確指出：任何東西都不得從這裡寄出。潛在客戶頻道甚至完全沒有連接任何寄送工具，這是刻意為之。當能力本身不存在時，規則更容易被遵守。
當你覺得這個規則太嚴格的那一天，正是它發揮作用的那一天。
圖 3. 根據犯錯成本分類的每項行動，以及之後會出現的兩個陷阱。
步驟 4. 像對待同事一樣為每個車道下達簡報
脈絡是持續存在的背景資訊。簡報則是針對特定任務的指示。複製以下內容並填入括號中的資訊。
客戶。 讀取客戶資料庫，然後發布本週計畫：每個客戶、其所處階段、本週要交付什麼、最大的阻礙是什麼。然後每個工作日早上 8:00 發布站會：昨天完成了什麼、今天要做什麼、遇到什麼阻礙。不超過 8 行，每一行都要標明客戶名稱。
潛在客戶。 研究 10 家符合 [你的客戶輪廓] 的公司。針對每家公司，告訴我他們做什麼、他們自家網站上可見的具體缺口，以及一個信心度備註，說明這個缺口是真實存在的，還是你的猜測。如果是猜測，請明確說出來。為其中最強的 5 家公司草擬初步接觸文案。兩段簡短的文字，開頭寫「我在貴公司業務中發現了……」。
報告。 從成效檔案中為 [客戶] 建立 [月份] 報告。每個數字都必須附上其來源和涵蓋的日期範圍。如果缺少某個數字，請說明是哪個數字，然後停止。
財務。 為 [客戶、里程碑、金額] 建立發票草稿，發布於此以供審閱，切勿完成最終版本。每週五下午 4:00 發布財務摘要。
交付。 用兩行文字向我總結這個提案，讓我知道你理解了。然後提出計畫並等待我的批准。在我批准後，以暫停狀態建構所有內容。
五個車道都遵循相同的模式：先確認脈絡、指定交付物、設定節奏，並對任何涉及金錢或外部世界的事項設置關卡。
步驟 5. 設定排程
工具和車道之間的區別在於：車道會自行啟動。
排程只是簡報中的一句話。「每個工作日早上 8:00」就是全部的設定。一旦設定完成，在你打開筆電之前，站會報告就已經送達，你的早晨從做出決定開始，而不是從提出問題開始。
這也是你一天工作節奏改變的地方。車道的產出速度遠快於你的閱讀速度，因此你不再需要逐一處理任務清單，而是開始清理一個審核佇列。每天只需兩個時段來處理就足夠了。
當 AI 員工實際運作時，結果如何
我在 Viktor 上運行了這個系統。Viktor 是一個 AI 員工，它能以工作區成員的身份加入 Slack 或 Teams，並連接到企業既有的營運工具。設定只花了一個下午。
第一天有五件事值得報告，其中三件是「拒絕執行」。
Viktor 不會憑空捏造他缺少的數據。 在我連接 Google Drive 之前，我請他發布站會報告。他檢查了，沒找到資料，又檢查了第二個來源，發現一個空的資料庫，然後他選擇什麼都不發布，而不是發布一個看起來合理的狀態板。他的原話是：不會根據猜測來重建資料。
他不會回答數據無法支持的問題。 我請他找出為什麼每次預約成本從 7 月的 84 美元上升到 8 月的 103 美元。他回覆說他無法找出原因：7 月沒有任何匯出檔案，唯一的 7 月數據是一則沒有來源的筆記，而且檔案中沒有日期欄位，因此無法驗證「週末效應」的假設。接著他指出，103 美元只是一個廣告活動的數字，而整個帳戶的綜合數字是 131.17 美元，他同時報告了這兩個數字，而不是只挑一個。
圖 4. 當被問及每次預約成本上升的原因時，他解釋了為什麼數據無法回答這個問題。
他應用了一條沒有人提醒他的規則。 在我的客戶檔案中，有一行文字提到某個客戶曾詢問過更高的預算上限，但尚未達成任何協議，並且不要根據這個上限來建構任何東西。他在一份不相關的摘要中自行發現了這一點，並表示他不會根據提高後的上限來建構任何東西。
他交付的是完成品，而不是對話。 報告以一份排版精美的 PDF 格式回傳，附有封面，並標明為「草稿，不得對外發布」。在第二頁、任何數字出現之前，有一個章節叫做「本月數據的三項限制」。
圖 5. 8 月報告，以 PDF 格式交付，開頭就說明了數據無法支持什麼。
他建立了一個可運作的儀表板。 包含四個客戶卡片、一個財務區塊，每個數字都標註了來源檔案，並提供一個我可以打開的 URL。他在頁首添加了一行我沒有要求過的文字：「快照，非自動更新，重新發布以刷新」。
影片 1. 他建立的工作室儀表板，從客戶卡片到財務區塊一應俱全。
分析
有些工作需要來自你自身檔案之外的即時資訊。在此之前，這意味著兩個選擇：自己動手去查，或者串接一個 API 並持續維護它。
Viktor 會自行瀏覽網頁。他會在真實的瀏覽器中打開頁面，讀取當下的內容，並在過程中截圖。
我想了解 Duolingo 如何運作其付費獲客策略，所以我請他針對他們目前正在運行的廣告活動提供一份報告，並附上他的分析。
結果回傳的內容是：廣告資料庫被打開並截圖，發現被分為三個標籤區塊。「已驗證」，表示他親自載入了該頁面。「推斷」，表示根據他所看到的內容做出的合理推測。「猜測」，並標明「不可引用」。最後附上一則關於他使用的方法以及該方法侷限性的備註。
他首先提出的觀察是：他解析的每個目標連結都指向應用程式商店頁面，沒有一個指向官方網站。
圖 6. Duolingo 廣告活動分析
排程任務
車道只有在能自行啟動時才有效。以下是設定方法。
在頻道中說出來。 在工作發生的地方，用一句話輸入排程：每天 8:00 在 #general 頻道發布每日彙報。不需要打開任何建置工具，也不需要選擇觸發條件。它會自動出現在「任務」中，並附帶排程。
打開它一次，閱讀他寫的內容。 這是值得做的一步。那句話會變成一個完整的任務，包含四個部分，而且全部都可以編輯：
來源，表示在撰寫任何內容之前需要讀取的頻道和檔案。
時間範圍，表示要關注自上次執行以來的活動，而不是今天的活動。
格式，包含嚴格的長度限制，以及「不得填充內容」的指示。
規則，重申與置頂脈絡相同的限制。
先修正時間範圍。 如果不這麼做，你每天早上都會看到昨天的內容被重複一遍。我的設定是，只有在阻礙仍然存在時才再次提及，並說明它已經存在多久了。
安排排程的順序，讓它們可以互相讀取。 站會報告在 7:55 執行，每日彙報在 8:00 執行，因為彙報會從站會報告發布的頻道中提取資料。間隔五分鐘，順序固定。
檢查他做了什麼假設。 他將自己的既有假設歸類在一個標題為「請驗證，勿假設此仍為真」的區塊下。當其中一個假設不再成立時，它會顯示在「受阻」那一行，而不是悄悄地破壞輸出結果。
三個排程任務就能涵蓋大部分服務型企業的需求：每天早上跨所有車道的彙報、車道內含截止日期的站會報告，以及週五下午的財務摘要。
圖 7. 三個常駐任務
大型團隊最終也採用了相同的模式
以上所述並非一人企業的專利。它是那些擁有數千名工程師的公司獨立發展出的精簡版本。
Uber 曾公布，其超過 70% 的 Pull Request 現在由 Agent 負責，工程師撰寫了超過 3,600 個 Agent 技能，每天約執行 30,000 次技能。Spotify 運行一個背景編碼 Agent，它只在建置和測試通過後才開啟 Pull Request，並報告 73% 的 Pull Request 由 AI 撰寫。Stripe 建立了一個內部助手，預設不載入任何東西，模型會在引入任何工具之前，先判斷請求需要哪些技能。
規模不同，但核心概念相同：每個 Agent 負責一項任務、脈絡存在於對話之外、以及為任何不可逆的操作設置關卡。
結構從來都不是最難的部分。難的是找到能執行它的人。
建置清單
儲存這個清單。每個車道執行一次。
- 每個車道一個頻道，永遠不要只用一個助手處理所有事
- 每個頻道一則置頂訊息：我們賣什麼、這個車道交付什麼、什麼情況需要升級、絕不讓步的規則
- 一個裁決檔案，每次修正都以一行文字記錄
- 一次性分類行動：可逆的自行執行，不可逆的等待批准
- 當規則很重要時，移除能力本身，而不是依賴規則
- 排程優先於提示詞。「每個工作日早上 8:00」就是全部的設定
- 只有當上一個車道能在你無需啟動的情況下自行產出時，才建立下一個車道
跳過裁決檔案，你每週都得修正同樣的問題。跳過審核界線，你就會知道它為什麼存在。
從一個車道開始，從那個讓你耗費最多時間的車道開始，讓它為你贏得建立第二個車道的資格。
「他每個月的訂閱費用可能感覺有點貴，但他是我雇過最便宜的員工，而且是唯一一個會按照我半夜的指示行動的員工。」—— Jacob Aldridge，Como Business Coaching 創辦人
感謝 @viktor_com 贊助本文！
在 @viktor_com 免費試用。提供 100 美元額度，無需信用卡。連結：viktor.com
付費合作夥伴關係
