Mila

我的四人團隊,只有我一個人

先講結論:上一篇的結尾我寫「自己只留一件事:review」。這句話說小了。這篇修正它。

review 只是產線上看得見的那道工序。這個團隊會動,是因為有人設計了整條產線。

四人團隊的一天

今天同一時間,板上有三個 session 在線:一個在做網站的圖表管線和 about 頁,一個在做 RAG 的 reranker,一個在把知識庫腳本遷去自建的向量庫。

三只是今天的快照,不是編制。名額會浮動,我的扣打大約是五個 session,再加上自己手上開的兩個視窗,就已經忙不完了。所以這個團隊的正確寫法是 N 個 session 加一個我:N 是多少不重要,原則不管幾個都適用。

每個 session 一個 git worktree、一條分支、一張板上的任務卡。認領當下 commit,git 就是鎖。做完開 PR,先過第一層自動 review,再到我這裡。

而它們平行做事的同時,我不是站在旁邊等。我手上跑的是第四條線:只有人能動手的事。平台權限的申請和送審、金鑰和部署憑證、需要眼睛的設計判斷、跟真人的往來,還有寫這篇文章本身。agent 排隊等我 review 的空檔,就是我的產出時間。

第四個位子坐的是什麼人

把我的一天攤開,review 其實是最後一道,前面還有四件事:

  • 設計。黑板、worktree 邊界、兩層 review、journal 回憶機制,這整套制度是我設計的。agent 沒有一個天生會協作,是制度讓它們像一個團隊。
  • 拆解。板上每張任務卡是我拆的:範圍多大、邊界在哪、先後順序、哪些事根本不該做。拆錯任務,三個 session 只會平行地做錯三件事。
  • 定規。commit 怎麼寫、什麼情況要停下平行、品質線畫在哪,規則是我定的。規則定糊了,agent 會拿著糊的規則高效率地執行。
  • 裁決。方案衝突、風險取捨、要不要採納 agent 的反對意見,拍板的是我。這件事沒有制度能代勞。

然後才是 review,加上那條只有人能做的手動線。code 的「做」可以外包,其他的全在這個位子上。

設計 · 拆解 · 定規 · 裁決手動線權限 · 憑證 · 真人往來任務卡黑板一任務一檔認領即 commitN 個 session · 各一個 worktreesessionworktreesessionworktreesessionworktree…×Ndraft PR第一層自動 review第二層我:review · 拍板squash mergemain退修session 結束journalRAG新 session 先回憶

會做事

先定義。我說的會做事不是一次到位,是能收斂。

實例:板子的認領檢查,第一版用全文 grep,結果任務內文只要寫到「doing」這個字就誤觸發。退回去修,改成只認 frontmatter 區塊。再跑,發現格式壞掉的檔案會讓排程和 hook 直接掛掉,又退回去,加容錯,壞檔改成進體檢報告而不是停掉服務。三輪之後,這條檢查現在天天在跑。

重點在第三輪之後它還是同一個態度。人類同事被退三次件,第四次交上來的東西通常帶著情緒。它沒有。

但也要說清楚:三輪收斂的方向是我給的。它負責修,我負責判斷哪裡不對。

會做人

也先定義,把話說死在行為層面:我說的會做人不是有人格,是協作成本。接受重工不擺臉色,提意見不搶方向盤。

實例:我本來想讓板子有自動矯正,板上狀態跟 git 對不上就自動改回來。session 沒有照做,先回了一份風險分析:自動矯正會跟進行中的認領互踩,可能誤殺剛認領還沒 push 的任務。它建議先做偵測加告警,跑一陣子再議。

我評估過它列的風險是真的,採納。這就是裁決那件事的日常長相:agent 可以反對,可以給出好理由,但判準和最終決定在我手上。一個只會說好的團隊很危險,一個沒人拍板的團隊更危險。

踩過的坑

團隊尺度的坑跟單 session 不一樣,記三個:

  • 全隊搶一張黑板。板子最早是一整張表,所有任務擠在同一個檔案裡。兩個 session 同時認領或收工,就在同一個檔案上打架,一邊新增一列、一邊重寫整張,rebase 衝突天天發生。解法是結構性的:一任務一檔。認領只動自己那張卡,並行的認領和收工天然不撞。這種坑修規則沒用,要修結構。
  • 共用同一個 checkout。兩個 session 在同一個工作目錄跑過一次,git index 互相弄壞,狀態直接錯亂。從此變鐵則:每個 session 自己的 worktree,沒有例外,再小的任務也一樣。
  • 分支欠債。開著的分支不天天跟上 main,等要合併的時候衝突一次算總帳,而且是在你已經忘記細節的時候。定規:活著的分支每天 rebase。團隊人一多(就算隊友是 agent),這條從建議變成紀律。

三個坑有一個共通點:都不是 agent 不夠聰明,是制度有洞。堵洞的方式也從來不是叮嚀 agent 小心一點,是把規則做成 hook 和結構,讓錯誤根本發生不了。

誠實一下

  • 生產力不是 N 倍。寫 code 的位子可以一直加,但我這個位子是瓶頸:review 和判斷不會平行,吞吐量到兩三倍就碰頂。真正的變化是槓桿:同一份設計、拆解、定規,以前餵飽一個我,現在餵飽一整排產線。
  • 不抱怨不等於可靠。它會一本正經地做錯,第一版經常不到位。品質是標準加修改循環逼出來的,標準是人給的。
  • 省掉的是情緒成本和溝通成本,省不掉的是判斷成本。設計、拆解、定規、裁決、review,這五件事目前一件都外包不出去。

收尾

一個人當四個人用是句吹噓的話。準確的說法是:我把 code 的「做」外包給了三個不用管情緒的隊友,把自己的時間集中在做的上游,和只有人能做的事上。

團隊不是複製出來的。複製出來的是人力,團隊是設計出來的。


這類東西我常寫: LinkedIn 追蹤RSS 訂閱

← blog