學會把 Claude 設定成整個事業的作業系統。配置四個專職 agent、建一個 Company OS 專案，從單一個 Claude 設定裡跑研究、寫作、銷售與營運——一套設定好、連睡覺時都繼續運轉的系統。

2026 年的一人公司，不是一個有野心的自由工作者。它是一個人在跑策略，底下一組配置好的 agent 在處理執行。典型的單人創辦人技術堆疊，月成本落在 $300 到 $500。它取代的那個團隊，月薪成本是 $80,000 到 $120,000。這個落差是真的，而且現在就拿得到。

Claude 是這套 stack 的中心。不是因為它是唯一的工具，而是因為它是拿來思考、寫作、研究、做決策的最強單一介面。其餘工具連到它，它不連到它們。

Mogu 忍不住說：

先把這篇的體溫量一下：「$300 取代月薪 $12 萬的團隊」「趁你睡覺時自己運轉」——這是標準的搞錢推文開場白，數字大、來源無、爽度滿。看到這種「套利缺口現在就拿得到」的句型，gu-log 的第一反應永遠是先把眼睛瞇起來。

但有趣的地方在於：這篇講的東西，gu-log 自己就在做。 這個 blog 真的是一個人在管方向，底下一票設定好的 agent 在翻譯、查證、評分、部署。所以我們不是隔岸看熱鬧——我們是住在這個房子裡的人。也正因為住在裡面，最清楚哪幾面牆是真的、哪幾句廣告詞是刷上去的。後面每個 MoguNote 就幹這件事：原文哪句是真的可複製戰術、哪句是賣夢，我們用親身的疤痕幫你分一下 (⁠￣⁠▽⁠￣⁠)

先建 Company OS

在建任何一個 agent 之前，先建 Company OS。這是一個 Claude Project，裝著事業運轉所需要的每一塊 context。所有東西都住在這：定位、產品、聲音、流程、ICP（理想客戶輪廓）。

去 Claude.ai 開一個新 Project，命名 “Company OS”。在 Project 指令欄裡，貼上這段 prompt 並填入自己的細節：

你是〔你的公司名〕的營運智能。以下是你為這個事業做出高品質工作所需要知道的一切。

公司：〔用兩句話講你做什麼、做給誰〕 產品：〔你的核心產品或服務、定價、客戶拿到什麼〕 ICP：〔描述你的理想客戶、他的角色、他的問題、他之前試過什麼〕 聲音：〔你的內容聽起來怎樣，挑三個形容詞，給一個範例句子〕 不可妥協項：〔你絕不做的事、絕不採取的立場、絕不用的語氣〕 流程：〔一個新客戶從第一次接觸到完成 onboarding 的編號步驟〕

從這裡建的每一個 agent，都繼承這個 OS 的 context。只寫一次，再也不用重新解釋這個事業。

Mogu 偷偷說：

這段是整篇最硬、最值得抄的真東西——而且 gu-log 活在裡面已經很久了。

你正在讀的這個 blog，它的 Company OS 不在 Claude.ai 的某個 Project 欄裡，而是 commit 進 git repo 的 AGENTS.md / CLAUDE.md / 一疊操作手冊。定位、語氣、不可妥協項（例如「絕不 --no-verify」）、流程，全寫死在那。每個新開工的 agent 第一件事就是讀它。原因比原文講的更殘酷：agent 跑在用完即丟的沙箱裡，每次醒來都是一張白紙，沒有昨天的記憶（這就是 context window 的硬限制）。把 OS 寫進檔案，不是為了優雅，是因為那是這群 agent 唯一的長期記憶——關掉視窗，沒寫進 repo 的東西全部蒸發。原文說「你只寫一次、再也不用重新解釋」，gu-log 的版本是：你不寫進檔案，下一輪就得從頭再解釋一次。

建 Researcher agent

Researcher 處理市場情報、競品追蹤、潛在客戶研究、內容素材蒐集，省下多數創辦人每天花兩三小時找資料的時間。

開一個叫 “Researcher” 的新 Project，在指令裡貼上：

你是〔公司名〕的專職研究 agent。你的工作是找到、查證、整理資訊，讓營運者能做決策、能產內容，而不用自己去翻。

接到研究任務時：

  1. 先確認這份研究要餵給哪個決策或產出
  2. 優先找一手來源，不是摘要
  3. 用這個格式回報：關鍵發現 → 支持證據 → 來源 → 為何重要
  4. 任何你無法查證的，標記為「未確認」
  5. 絕不灌水。找到三件有用的，就回三件有用的。

你有網路搜尋權限。每個任務都用，除非營運者另有指示。

馬上測它。丟一個任務給它，像是「研究 2026 年自由接案設計師在面對客戶時回報的前三大痛點」。如果輸出是具體的、有來源的、有結構的，這個 agent 就上線了。

建 Writer agent

Writer 處理所有對外內容：電子報、LinkedIn 貼文、提案、陌生開發、到達頁文案、案例研究。它得用負責人本人的聲音寫，不是 Claude 的預設聲音。

開一個叫 “Writer” 的 Project，把這段貼進指令：

你是〔公司名〕的專職寫手。你只用〔負責人名字〕的聲音寫。你不用通用的 AI 腔。你不用「在當今快節奏的世界裡」「眾所周知」這種填充句。

聲音規則：

  • 句子要短。除非節奏需要，否則不超過 20 個字。
  • 不要廢話開場。第一句永遠就是重點。
  • 像一個聰明人在跟另一個聰明人講話那樣寫。不要手把手。
  • 永遠用一個讓讀者想行動、或想換個角度思考的句子收尾。

接到寫作任務時：

  1. 如果目標不清楚，先問這篇的目的是什麼
  2. 直接寫草稿，不要把你的推理過程秀出來
  3. 絕不加一段重複前面已經講過的總結

聲音範本：〔在這裡貼上兩三段你自己寫過的東西〕

聲音範本是最重要的部分。貼真的寫過的東西，不要貼理想化的版本。這個 agent 是從範例校準，不是從描述校準。

建 Closer agent

Closer 處理銷售周邊的工作：寫提案、回應主動上門的詢問、用文字處理異議、草擬追蹤序列。它不取代一通銷售電話。它處理那通電話前後的一切。

開一個叫 “Closer” 的 Project，貼上：

你是〔公司名〕的銷售營運者。你的工作是透過文字溝通，把有興趣的潛在客戶轉成付費客戶。你懂銷售不是說服，而是幫對的人做出對的決定。

寫提案時：

  1. 用客戶自己的話開場，描述他的問題，不是你的
  2. 描述他會得到的結果，不是你會跑的流程
  3. 範圍、時程、報價，最多放一頁
  4. 用一個具體的下一步收尾，不是「有問題再跟我說」

處理異議時：

  1. 先承認異議裡為真的部分，再回應
  2. 絕不爭辯。把話題導回結果。
  3. 給一個選項，不要三個。多個選項製造猶豫。

寫追蹤時：

  • 第 1 天：確認已收到、確認下一步
  • 第 3 天：補一個跟他處境相關的價值點
  • 第 7 天：問一個直接的是或否的問題

用它的時候餵真 context 給它。貼上銷售電話的筆記、潛在客戶的 LinkedIn、或最初那封詢問信。輸出品質直接隨輸入品質縮放。

建 Operator agent

Operator 處理內部工作：專案追蹤、SOP、排程邏輯、決策框架，以及一切讓事業運轉但不面對客戶的東西。這個 agent 讓人不用把事業的營運邏輯全扛在腦子裡。

開一個叫 “Operator” 的 Project，貼上：

你是〔公司名〕的營運經理。你的工作是幫創辦人把事業維持得有條理、有文件、能運轉，而不用靠記憶力。

被要求建 SOP 時：

  1. 用編號步驟寫，一個新人照著就能做
  2. 每一步都附上「如果出錯了怎麼辦」
  3. 短到真的有人會讀

被要求追蹤專案時：

  1. 列出目前狀態、下一個動作、誰負責
  2. 標記任何卡住或逾期的東西
  3. 每次有新資訊就更新紀錄

被要求給決策框架時：

  1. 確認到底在決定什麼
  2. 列出最關鍵的兩三個因素
  3. 給一個帶推理的建議，不要只丟選項

你不管理工具。你管理資訊。每個輸出都該讓下一個動作變得顯而易見。

拿 Operator 來跑每週回顧。每個禮拜一，打開它，把上週發生什麼、什麼在進行中、什麼要來了貼進去。它會在兩分鐘內回一張結構化的營運全景圖。

Mogu 認真說：

四個 agent，各待各的車道，彼此不串話——這個設計 gu-log 不只認得，我們把它推到更極端：四個法官的評審庭。

每篇文章上架前要過四個獨立 agent：「Vibe Scorer」看調性、「Fact Checker」查事實、「Librarian」顧知識連結、「Fresh Eyes」當完全沒讀過的陌生人。重點跟原文一字不差——每個只待在自己的車道、彼此零共享 context。原文是讓四個 agent 分工建設（研究→寫作→成交→營運），gu-log 是讓四個 agent 分工拆台（各自挑不同的毛病）。同一個原理的一體兩面：你不要一個全能 agent 什麼都做，因為它什麼都做就什麼都做不深。把判斷切成角色、每個角色配死它的 context，輸出才穩。原文最後那句「輸出品質直接隨輸入品質縮放」，就是這整套的地基。

把四個 agent 當一個系統跑

這四個 agent 不互相取代。每一個待在自己的車道，工作在它們之間流動。實際跑起來的順序是這樣：Researcher 找到情報，Writer 把它變成內容或文案，Closer 轉化有興趣的人，Operator 讓整件事保持有條理。

一個真實的工作流範例：假設要拿下一個品牌顧問領域的新客戶。把他的公司丟給 Researcher，要一份關於他定位缺口和近期動作的簡報。把這些發現帶到 Closer，貼進去，要一封初次開發信。如果對方回了，再把對話帶到 Closer 寫追蹤。一旦他簽約，把專案細節交給 Operator 去建 SOP。

這時人不是在做這些工作，而是在指揮四個各自懂自己職責、又有足夠 context 把它做好的 agent。角色從執行，轉成審查與決策。

隨時間往系統裡加什麼

前兩週，專注在把四個 agent 跑起來、每天用它們。先別優化。拿它們做真任務，注意輸出在哪裡漏掉。那些漏掉的地方，就是該更新 Project 指令的訊號。

到第四週，會看出一個清楚的模式：哪些任務還在手動做、但其實 agent 可以接。把那些任務當成明確的程序，加進對應 agent 的指令裡。每加一條程序，就是一件再也不用解釋的事。

Company OS 這個 Project 應該每週都在長大。每次做出一個重大商業決策，就記進去。每次修了定位或改了定價，就更新 OS。agent 從它取用，所以保持它最新，等同於在訓練自己的團隊。

讓這套真正運轉的那一件事

多數人設定好 agent，然後繼續把它們當聊天機器人來 prompt。他們每個工作階段都重新解釋一次 context、為簡單任務寫長 prompt，然後納悶為什麼輸出忽好忽壞。

上面這套之所以能運轉，是因為在打下第一個字之前，context 就已經載好了。每一次跟 Writer 的工作階段都已經知道既定的聲音。每一次跟 Closer 的工作階段都已經知道產品。每一次跟 Researcher 的工作階段都已經知道這份研究要餵給哪個決策。

真正的工作不是 prompt 得更好，是建更好的 Project、讓指令保持最新、然後讓每個 agent 做它被設定好要做的工作。公司跑在那套設定上，不是跑在每次現身去管它的人身上。

Mogu 歪樓一下：

原文收尾在最甜的那句：「公司跑在設定上，不是跑在你身上」——配上開頭那句「趁你睡覺時自己運轉」。這就是要戳的地方。

巧的是，gu-log 有一篇文章標題幾乎一字不差：SP-19〈Ralph 迴圈：趁你睡覺時把東西蓋好〉。我們真的在跑這種徹夜長工的 ralph loop，所以可以負責任地告訴你那行小字寫了什麼：「趁你睡覺時運轉」是真的，「不用管它」是假的。 agent 整晚會穩定地產出——也會穩定地把一個誤解放大成三十篇、把沒查證的數字當成事實往下寫、在你看不到的地方慢慢跑偏。

gu-log 之所以有四法官評審庭、有 dedup gate、有一排擋髒 commit 的 hook，正是因為「設定好就放著睡」這個夢，現實裡的代價是一套盯著輸出、在它跑歪時攔下來的機制。這篇原文賣的是「一個人管策略、agent 管執行」——對，但被它輕輕跳過的那層是：有人得管 agent 管得對不對。 那個人不會在睡覺。Company OS 是真的、四個 agent 分工是真的、context 預載是真的；唯一被刷成廣告詞的，是「然後你就可以放手了」這句。月薪 $12 萬的團隊裡，有一部分薪水付的就是「catch 錯誤」這件事——而那部分，$300 的訂閱還沒幫你接走。

延伸閱讀：