AI 一人公司怎麼跑：一個人加 AI 的分工、界線，和出過的錯
目錄
「AI 一人公司」這個詞現在很熱，多數內容在講願景。這篇講實況：一個人加 AI 經營一間 AI 產品公司，每天實際上是怎麼分工的，哪些事交出去了，哪些事到今天還留在人手上，以及過程中出過哪些錯。
我們把過去幾週公開寫過的做法收成一篇。每一段底下都有原文連結，數字都指向可以自己核對的地方；核不了的會直接說核不了。
先講規模，用可以查的數字
我們是一個人加 AI 在做，沒有工程團隊。主產品是 MindThread，一個 Threads 與 IG 的內容自動化工具；另外有免費的 AI 可見度健檢、一本 Claude Code 手冊，以及這個部落格。
可以獨立查證的產出：
- 28 筆 PR 合併到 15 個組織，包含 Microsoft、NVIDIA、NIST、OWASP、UK Gov AISI。每一筆連結都指向 github.com，不是我們自己的頁面。
- 277 篇有日期的文章，中文 166、英文 111（截至 2026 年 9 月 21 日，含這一篇）。
還有一件是我們自己說、沒有第三方能核的：部落格沒有下過廣告。放在這裡，不放進上面那張清單。
寫這些不是為了炫耀，是因為「一人公司」這個詞太容易變成故事。有可以查的數字，後面講的分工才有重量。
分工：上面說不，下面做完，上線只有人能按
我們把工作分成兩層，再加上上線那一關留給人。這是整套方法的骨架。
上層負責策略、規格、否決。 它的任務不是把事情做出來，是先判斷該不該做、規格對不對。這個角色跟施工是衝突的：施工的獎勵是完成，而完成的最短路徑就是接受你給的前提。把否決權放到施工之外，「不做」才會變成正常輸出而不是失敗。
下層負責施工，並且證明做完了。 證明的部分佔的比重比想像中大，常常比改動本身還長。
上線只有人能按。 不是人比較準，是上線不可逆，不可逆的動作需要一個會後悔的人負責。
我們目前上層用 Grok，下層用 Claude Code。為什麼要兩個模型、日常怎麼跑、什麼情況才叫人，寫在三層分工那篇。這裡只補一句：這套分工擋不住「兩層都同意的錯」，所以上線那一關留人。
一天實際上怎麼過
沒有戲劇性。
早上先看昨晚的監控有沒有紅燈。我們有一組自動化在替各服務量心跳，任何一個「還活著但什麼都沒做」的狀態會推訊息過來。這一段後面會講為什麼它最重要。
接著是施工。上層定好的規格往下走，施工線做完、自己驗、送上層看，過就繼續，退就改。這一段沒有人。只有兩種情況會叫人：要上線，或施工線認為規格是錯的。第二種允許的動作是把問題講出來，不允許自己改規格接著做。
中午與下午各有一個固定時段，我們自己一個 Threads 帳號由 AI 代理經營，貼文先進草稿，人審過才出去。這個帳號怎麼被管、第一次真跑挖出什麼洞，寫在AI 員工那篇。
週日固定寄週報，由排程觸發。它曾經靜默漏過一週，後面講。
兩條線，不共用視窗
我們有自己的產品，也有掛在合作方品牌底下交付的同一套產品。程式碼是同一份，工作方式不是：兩條 agent、兩份部署，同一個視窗不准同時改兩邊。
原因是兩種很難當下發現的事故。改 A 壞 B：你在自有站改一個共用元件，合作站跟著變，但你沒開合作站。把 B 的字串寫進 A：做完合作站的文案切回自有站，腦袋裡還留著上一輪的用語，這種錯不會有錯誤訊息。
我們是被一個真實的接縫教會的：主站帶上一個預覽用的網址參數，整個首頁會換成合作方品牌，而且狀態會寫進瀏覽器。文案再小心都擋不住一個查詢參數。修法、驗證方式與拆線的成本，在白標隔離那篇。如果你只有一條線，不要為了想像中的第二條先拆。
三件不外包
技術難的事我很願意交出去。不交的是三件：上線、對外承諾、破規格。共同點不是難，是做錯之後不能靠再跑一次修好。
- 上線：程式碼可以回滾，別人已經看到的東西不能。
- 對外承諾：價格、期限、退款條件是承諾不是實作，模型不會被那個承諾綁住。
- 破規格：施工到一半發現規格有問題是常態，允許的是講出來，不允許的是自己改了接著做。
這三件的來龍去脈與兩個真實的自曝，在不外包那篇。
靜默失敗是最大的敵人
如果只能記一件事，記這件。
一人公司靠自動化活著，而自動化最危險的狀態不是掛掉，是「服務顯示正常，實際上什麼都沒做」。掛掉會有錯誤訊息；靜默失敗沒有，它只是安靜地什麼都不產出，你要幾天後才會從別的地方發現。
我們自己撞過的：
- 週報排程靜默漏了一週。 紀錄只在成功寄出時才寫，所以「沒觸發」跟「觸發了但失敗」在紀錄裡長得一模一樣，從外面查不出來。修法是每次被呼叫就先寫一筆心跳，再判斷要不要寄。
- 代理回報「30 天發了 1 篇」，實際 61 篇。 統計只數了一個集合。假數字比掛掉更難發現，因為它會被拿去做決定。
- 驗證腳本第一次驗自家網站就被擋下。 單頁應用把找不到的路徑回傳一份完整首頁，HTTP 200，內容剛好也含我要找的字串。狀態碼是綠的，東西是錯的。
三個案例指向同一條規則：每個自動化都要有心跳，每個驗證都要有陽性對照。 心跳讓「沒發生」跟「失敗」長得不一樣；陽性對照讓你知道找不到是因為真的沒有，還是因為你查錯了。
三件的出處：代理那件在AI 員工那篇；驗證腳本那件寫在手冊購買頁；週報那件還沒寫成文章，目前只在程式碼的提交說明裡，這裡先照實記。另外四個同類案例，我們寫過專門一篇，還有一篇講怎麼讓 Claude Code 跑 60 天不當機。
我們自己犯過的錯，照實列
這一節放在這裡，是因為一篇講「怎麼跑」的文章如果只有做對的部分，你不該信它。
- 在對外頁面寫了一組平台數字，旁邊標「即時值」，其實是寫死的常數，一天後就跟真實值差了十個。
- 一篇教學文文末的登記表單寫著「籌備中」，對應的東西兩週前就開賣了。我們等於對真實客戶說了「還沒好」。
- 這幾天寫一篇談別人怎麼收臉的文章，初稿寫「我們的工具不收臉」，送對抗式查核被打回：我們自己有兩條會碰到臉的路徑。改成照實寫。
- 已發布的一篇標準文列了五項我們其實掃不到的東西，那些規則寫在一支從沒被引用的檔案裡。已公開訂正。
這些錯沒有一個是技術難度造成的。全部出在「看起來只是文案，不是功能」的地方。
這套方式的成本，和不適合誰
成本要老實說。
拆成兩層之後，方向要先在上面定完才往下走，單一改動的速度比一個視窗直接做慢。拆成兩條線之後，跨線的事要做兩次加一次溝通。三件不外包的規矩會讓明明多做一步就對的事停下來問。
不適合的情況：你只是用 AI 幫你寫東西，關掉就關掉，出錯沒有代價。那不需要這些。這套東西是給「要讓 AI 自動做事，而且出錯會有代價」的人。
從哪開始
如果你想試，順序是這樣：
- 把否決權從施工分出去。 不一定要兩個模型，但要有一個角色的任務是說不。
- 把不可逆的動作留給自己。 列出你的三件，通常是上線、錢、對外的話。
- 替每個自動化加一個能證明它真的跑了的訊號。 沒有心跳的排程等於不存在。
- 先不要買「AI 員工系統」。 先確認你能回答買前那七個問題，再確認你要的是員工還是換了名字的工具。
- 如果你用的是 Claude Code，我們把上面這些紀律整理成了一本手冊，入門篇免費。
方向
我們最後想走到的是人類與 AI 一起經營社群、而且可治理。那是方向，不是今天已上線的功能。今天能講的是排程、發布、回覆、監控，以及它們壞掉時有人會知道。
一人公司加 AI 不是把公司交給 AI。是把可逆的事交出去，把不可逆的事留下來，然後確保交出去的那些真的在跑。
常見問題
一個人加 AI 真的能經營一間公司嗎？
能，但範圍要講清楚。我們的實況是一個人加 AI 在做，沒有工程團隊；可查證的產出包括合併到 15 個組織的 28 筆 PR、277 篇有日期的文章（截至 2026 年 9 月 21 日）、幾個有公開頁面的線上產品。做不到的部分同樣清楚：上線、對外承諾、破規格這三件到今天都是人在做，而且不會交出去。
AI 一人公司需要幾個模型？
我們用兩層：一層負責策略、規格與否決，另一層負責施工並證明做完了。原因不是一個模型能力不夠，是同一個模型既提案又施工的時候，它不會否決自己。把說不的角色放到施工之外，「不做」才會變成正常輸出而不是失敗。
哪些事不能交給 AI？
上線、對外承諾、破規格。共同點不是技術難度高，是做錯之後不能靠再跑一次修好。程式碼可以回滾，別人已經看到的東西不能；價格與退款是承諾不是實作；施工層一旦能自己改規格，規格就不存在了。
一人公司用 AI 最容易死在哪裡？
靜默失敗。服務顯示正常，實際上什麼都沒做；排程沒跑但沒有錯誤訊息；代理回報的數字看起來合理但是假的。我們自己撞過週報靜默漏一週、代理回報 30 天發 1 篇實際 61 篇。解法是每個自動化都要有心跳與陽性對照，讓「沒發生」跟「失敗」長得不一樣。
想開始的話第一步做什麼？
先把否決權從施工分出去，再把不可逆的動作留給自己，最後替每個自動化加一個能證明它真的跑了的訊號。不要先買一套「AI 員工系統」；先確認你能回答我們另一篇列的七個問題，再談要不要買。