一人公司怎麼把 Grok 放在 Claude 上面：策略、施工、上線的三層分工
一句話講完：上面那層決定要不要做、做成什麼樣，下面那層決定怎麼寫，上線只有人能按。策略與否決放在 Grok，改程式碼放在 Claude，日常的過與退由施工線自己收，只有要上線或規格有問題才叫人。
一開始我是用一個模型做完全部的事。想清楚要做什麼，也是它；把程式碼寫出來，也是它。這樣跑了一陣子，問題不是它做不到，是來回太多。
原因有兩個。一個是每改一次想法就要重新解釋一次前因後果，上下文長到某個程度，它會開始漏掉前面講過的限制。另一個更麻煩：同一個模型既提案又施工，它不會否決自己。我問「這樣做對嗎」，它多半會告訴我為什麼對，然後開始寫。
所以現在分成兩層。上面那層決定要不要做、做成什麼樣，下面那層決定怎麼寫。Grok 在上面，Claude 在下面。
上面那層負責說不
上層的工作有三件：策略、規格、否決。前兩件很容易理解，第三件才是重點。
我需要一個地方，它的任務不是幫我把事情做出來，而是先判斷這件事該不該做、規格對不對。這個角色跟施工是衝突的，因為施工的獎勵是完成，而完成的最短路徑就是接受你給的前提。你給一個錯的前提，它會把錯的前提做得很完整。
把否決權放到施工之外，是為了讓「不做」變成一個正常的輸出，而不是失敗。
下面那層負責做完，並且證明做完了
下層只做一件事：把上層定好的規格變成能跑的東西，而且要證明它真的在跑。證明的部分佔的比重比想像中大，通常比改動本身還長。
日常不叫人
過與退由施工線自己收。施工線做完，自己用 Grok CLI 送去上層看，過就繼續，退就改。這一段沒有人。
只有兩種情況會叫老闆。第一種是要上線。第二種是施工線認為規格是錯的。
第二種特別重要。施工到一半發現規格有問題是常態，允許的動作是把問題講出來，不允許的是自己改規格然後接著做。
一個今天發生的例子
今天在清官網的對外句子，查到一件事：主站的網址帶上一個給預覽環境用的參數，整個首頁會換成合作方的品牌，而且這個狀態會被記在瀏覽器裡，之後開乾淨的網址還是合作方版本。
這件事三個角色各做各的。判斷「這是必須修的接縫、不是可以排進下一輪的優化」是上層的事。改成正式網域只認網域、參數與瀏覽器記憶限預覽環境使用，是下層的事。決定現在推上去，是老闆的事。
三個角色沒有一個能自己走完全程，這正是我要的。
這樣做省了什麼，沒省什麼
省的是來回。以前一個改動要在同一個視窗裡反覆拉扯，還要防它把前面的限制忘掉。現在方向在上面定完才往下走，下面拿到的是已經被否決過一輪的規格。
沒省的是判斷。上層不是老闆，它是一個會說不的同事。它能擋掉明顯的錯，擋不掉「兩層都同意的錯」。當上層與下層都接受了同一個錯誤前提，這套分工完全沒有保護作用，反而會很有效率地把錯的東西做完。
所以上線那一關留著人。不是因為人比較準，是因為上線是不可逆的，而不可逆的動作需要一個會後悔的人負責。
產品方向
我們要走到人類與 AI 一起經營社群、而且可治理。這是目標，不是今天已上線的功能。今天有的是排程、發布、回覆、監控，以及它們壞掉時有人會知道。
這是實驗室週記，不是產品承諾。
常見問題
為什麼不要用同一個模型做規格又做施工？
因為施工的獎勵是完成，而完成的最短路徑就是接受你給的前提。同一個模型既提案又施工的時候，它不會否決自己：你問「這樣做對嗎」，它多半會告訴你為什麼對，然後開始寫。把否決權放到施工之外，是為了讓「不做」變成一個正常的輸出，而不是失敗。
哪些情況才需要人介入？
兩種。第一種是要上線，因為上線是不可逆的對外動作，程式碼可以回滾，別人已經看到的東西不能。第二種是施工層認為規格是錯的，這時允許的動作是把問題講出來，不允許自己改規格然後接著做，否則規格層等於不存在。其餘的過與退由施工線自己收。
這套分工擋不住什麼？
擋不住「兩層都同意的錯」。當規格層與施工層都接受了同一個錯誤前提，分工完全沒有保護作用，反而會很有效率地把錯的東西做完。所以上線那一關留著人，不是因為人比較準，是因為不可逆的動作需要一個會後悔的人負責。
這樣做實際省到什麼？
省的是來回。以前一個改動要在同一個視窗裡反覆拉扯，還要防模型把前面講過的限制忘掉。現在方向在上層定完才往下走，施工層拿到的是已經被否決過一輪的規格。省的不是判斷，判斷還是在人身上。