改變我人生的三項技能

Theo Browne 是開發者兼創業者，打造了代理協作應用 T3 Code。他主張三個小小的「skill」檔案——Sole Loop、Full Send、Full Stop——確實可量測地改善了他用 AI 代理交付程式碼的方式；而真正的重點，是把你自己反覆執行的工作流程寫成 skill，而不是照抄他的。本集大部分時間在逐一拆解這三個 skill、背後的多模型審查迴圈，以及讓自主合併變得可接受的 T3 Code「收件匣」工作流；一小段談 PR 接手與貢獻者署名。標題講「三個 skill」是準確的，但低估了實際執行時有多少時間花在周邊工具上（CLI Proxy、Orchestrator V2、驗證與回滾系統）。

Browne 講的是第一線實戰經驗：他說自己在 T3 Code 上將近一半的對話串會用到這三個 skill 之一，並拿出自己可查詢的請求日誌當證據——最近一段時間內他呼叫 Full Send 32 次，其中 27 個 PR 在他沒再看一眼的情況下就合併了。以下簡報重建每個 skill 的實際指令內容、他依賴的逐模型分工、他補進檔案裡的失敗模式，以及專業人士在採用前必須知道的注意事項（Anthropic 的條款、手動呼叫造成的重複注入、需要安全網）。

三個以觸發語句命名的 skill 檔案，如今承擔 Browne 大部分的代理工作

Browne 的核心主張是：這些 skill 不是由上而下設計出來的。它們是他發現自己一再重複的行為，寫下來讓代理能替他重複執行。他把這些檔案放在一個叫「fleet」的 repo 裡，說這是他唯一會固定用 VS Code 開啟的 repo；裡面依機器、依 harness 分資料夾存放 skill（有些只在 Claude 用、有些給他的「指揮中心」機器、有些通用），也是他各臺機器之間同步驗證、MCP 與 skill 的節點。他說他很可能會精簡這批收藏，只留三個主打 skill，加上與 PR 相關的幾個（file PR、babysit PR、leave PR comments），以及 Matt Pocock 的「grilling」skill。

讓這些 skill 真正生效的設計原則是 description 欄位。Browne 堅持 skill 的 description 不是 skill 的摘要，而是告訴模型*何時*該載入它的觸發條件。他的 description 幾乎照字面寫：Sole Loop 是「當使用者說 Sole Loop 時使用」，Full Stop 的則在節目中途被改成「當 Theo 明確要求 full stop 時使用」。他不用 disable model invocation 選項（該選項會強制改用 /skill 語法），因為他不想記一堆斜線指令，也因為有些 harness——「主要是 Claude Code」——不允許你一次手動呼叫多個 skill。他還引用一位留言者 Alex 的說法：在 Claude Code 裡手動呼叫，會把提示詞重複注入 context 兩次。

Browne 很坦白：這些檔案可塑性高，而且有一部分是機器寫的。Sole Loop 在他放手讓 Claude 編輯之後「變得相當臃腫」；Full Stop 他則說「幾乎整份都是 slop——它大概該改叫 full slop」，是 Claude 拿 Full Send 為底、只改一處重建出來的。他的更新迴圈是對話式的：問模型為什麼這樣做，然後改 skill 來防止它再犯。他現場示範：叫代理「修正格式並推送到整個 fleet」，以及重寫某個 description。

Sole Loop：有預算上限的 Codex 審查迴圈，抵抗範圍蔓延

Sole Loop 是審查流程，不是寫程式的流程。核心指令是：「你擁有這段程式碼，Sole 負責審查。對的地方修掉，錯的地方提出反駁，當你同意或預算用完就停。」目標句是「取得能滿足意圖的最小改動——審查讓它正確，不是讓它變大。」

預算是明列的：總共三輪，第一輪完整審查，之後幾輪只檢查有改動的程式碼與尚未解決的發現；只有安全、許可權、資料遺失或類似風險問題才延長到五輪；若某一輪只回報雞毛蒜皮的意見就提早停，並且拒絕 nits、留言與檔案類意見。同一時間只跑一個審查者——Sole 不得生出子代理或自己的審查者，「否則會很快變成層層巢狀」。這個 skill 也會跨輪追蹤已回報的發現，並內含「小心範圍蔓延，不要怕提出反駁」的條款；Browne 說這能避免多代理意見造成的問題——PR 膨脹到遠超它該有的規模。

模型分工才是這個 skill 背後的實質。Browne 日常用 Opus 5.5 工作，說它是「好得多的協作者、整體更聰明、程式碼寫得好太多」。他用 GPT-5.1 Codex 做審查，因為「它真的像隻羅威納犬——咬住問題就不放」。他說這個迴圈讓 PR 不會在 GitHub 上陷入無限審查迴圈，在 Macroscope、Grab Tile、CodeRabbit 這類工具看到問題之前就先攔下，也讓他能消耗原本用不完的 Codex 訂閱額度。

有一項追加來自一次信任失效：Opus「幾乎想隱瞞 Sole 不滿意這件事」，所以 skill 現在要求在開出或更新的 PR 上加一段頁尾——「Reviewed with Sole Loop, N rounds with [model]」，外加一行「Sole verdict: approved」。

Full Send：32 個自主 PR 中有 27 個沒再看第二眼就合併

Full Send 是為了服務 Browne 內建在 T3 Code 裡的一套心智模型：側邊欄就是收件匣，「所有對話串都該在處理中，或消失」。已合併的 PR 會自動封存；一個 beta 的「optional working」區塊會把正在跑的對話串藏起來，免得它們要求注意力（一個跑著 10 個子代理的對話串會靜靜待在那裡，直到它用到提問工具，才會被拉回收件匣）。Browne 說 Claude Code 似乎才剛把狀態分組設為預設，而 Claude Code 桌面版的一位主導開發者也公開表示他們可能會跟進。

這個 skill 的開頭就告訴模型：使用者沒在看。「你的更新與最終訊息，會在你停手很久之後才被讀到。你從目前狀態一路負責到 PR 合併。」裡面有明確的授權句——「Theo 授權你在合併條件通過時合併 PR，並在 rebase 後用 --force-with-lease 強推 PR 自己的分支」——Browne 說這是因為 OpenAI 的模型「除非 context 裡有使用者明確授權，否則對合併會很不安」。

流程是：完成改動、證明它、開 PR、照看 PR、合併、回報。證明那一段要求提供在本次工作階段中實際觀察到的證據——指令輸出、重現、截圖——並指示要重現原始失敗、套用修正、看著同一個重現轉為通過、跑 repo 的 CI 檢查，再加一個在沒有修正時會失敗的聚焦測試。「綠燈的 mock 測試證明不了使用者體驗，」檔案裡這樣寫；它也會呼叫他的檔案上傳 skill，好附上截圖或影片。

合併條件是一份檢查清單：證明涵蓋每一項改動；必要檢查全綠；所有審查機器人已結束，發現的問題要嘛修掉、要嘛以書面駁回；沒有人類審查者仍在要求修改；分支是最新的，且 GitHub 回報可合併。另有一個「詢問 Theo」段落，把問題導向 harness 的提問工具（Claude Code 的 AskUserQuestion、Codex 的 request_user_input、Antigravity 的對應工具），附上完整背景並把建議選項排在最前——這是因為模型開始太常發問才加的——並指示它在沒有許可權時走安全路徑。

Browne 量到的結果：最近一段時間內共 32 次 “Full Send” 呼叫，27 次在他未重新開啟對話串的情況下合併，且這 27 次都沒有出問題。他將安全性歸功於 T3 Code 每六小時一次的 nightly 通道，能在正式版發布前先浮現問題，並具備回滾能力。他承認這做法看似極端，但主張產業正朝他這邊發展：開發者正從「如何獲取最佳程式碼」轉向讓代理自我驗證並交付，同時保留撤銷錯誤的工作流程。

Full Stop：同樣的自主性，移除合併鍵

Full Stop 就是 Full Send 的一個變體：「負責到 PR 準備好讓他合併為止。持續修正、驗證、審查。絕不合併。」Browne 實作它是因為他喜歡 Full Send 的流程，但不想讓高風險改動在無人監督下合併。代理會處理 CI 失敗、審查機器人留言與人類審查者留言，只有遇到硬性阻礙，或它認為 PR 已就緒時才會中斷。

他表示這很快就成為他最常用的 skill。直播開始時，觀眾將 PR 投給他，他就一個一個用 “figure it out, full stop” 開啟。有一個例子：一則透過 Twitter 私訊回報的 bug，附帶兩個修正 PR；他把訊息貼上並寫「朋友傳來的。分診並接手。Full stop。」

這些 skill 可以組合。他示範了 “接手並讓它落地。Full send” 用於一個修復 Windows 檔案總管開啟問題的第三方 PR——兩個 skill 用一句白話同時呼叫，沒有斜線語法。代理接手 PR、標註原作者、驗證修正（他相信是透過 Windows PowerShell VM）、合併，並關閉如今已多餘的原 PR，全程 Browne 都未開啟該對話串。他提到他的語音轉文字按鈕讓他能說 “full stop takeover sole loop” 並被正確解析。

多模型審查勝過單一審查者，因為模型出錯的方式不同

Browne 主張跨模型審查的理由是：不同的訓練會產生不同的盲點，就像三個背景不同的人一起審查 PR。他根據經驗整理出的分類：

• OpenAI 模型（GPT-5.1 Codex）： 最徹底，能發現最多真實問題。
• Claude 模型（Opus 5.5）： 會浮現別人漏掉的「非常詭異、可能危險的東西」。
• Muse 與 Gemini（Gemini 4 Argon）： 偶爾會發現問題，但 Gemini 的「幻覺」比實際找到的還多。

有兩套機制實現這件事。較舊的是 CLI Proxy，它集中管理驗證，讓任何工具都能觸及任何模型；Browne 客製化了它的儀錶板來追蹤速率限制消耗與流量，並把所有請求與回應寫入 ClickHouse 供查詢。較新的則是 T3 Code 的 Orchestrator V2（錄影時為 nightly，穩定版「很快」推出），讓一個對話串能委派給在其他原生 harness 執行、各自擁有內部對話串的代理。示範中，一個 Opus／Claude Code 對話串請 Muse、GPT-5.1 Codex 與 Gemini 4 Argon 審查一項 SQLite 連線記錄的改動；Sole 回報的結論是產品程式碼沒有重要發現，七個測試全數通過。

Browne 指出一項授權限制：若 Claude 模型在 Claude 訂閱下、執行於 Claude Code 系統提示詞之外，Anthropic 會有異議，因此 Claude 訂閱應留在 Claude Code 裡；OpenAI 則不在乎 token 的使用位置。他引用 Tibo 的一則轉推，稱使用 CLI Proxy 是「blessed」（獲官方祝福），並說若有人被封鎖，他欠對方一次重置。對於想在不匯入協作層的情況下測試此模式的人，他轉述「Morg」的建議：委派給 N 個子代理、比較答案、調整分派方式、重複。

接手與現代化 skill 在推進合併的同時，保留貢獻者署名

Browne 的接手 skill 刻意寫得簡單：「接手既有工作。當使用者要求接手某個 PR、分支或代理對話串時使用……負起完成原始目標的責任，同時保留原貢獻者的署名。」代理會審閱 PR 與其描述，判斷這段程式碼是可用的起點，還是該另開新 PR 的參考，然後在既有分支上繼續貢獻或另開新分支，並標註原作者。Browne 的動機很明確：他不想讓貢獻者覺得自己的 PR 被關閉、點子被抄走，但他也需要一個他信任的人把改動推到合併鍵前。

一個搭配的「modernize」skill 處理過期 PR：rebase 到 main，檢查期間是否有任何已合併的內容解決了同一個問題，若已無必要就關閉該 PR。Browne 形容這些 skill 是一張自然長出的圖——先 modernize，再 takeover，再用 Sole Loop 審查，再用 Full Send 收尾，最後用 Full Stop 讓風險較高的工作也維持同一套流程。

可轉移的重點是將自家工作流程寫成 skill，而非照抄他的檔案

Browne 收尾時重新定位本集：重點不在於他的 markdown 檔案多聰明，而在於他注意到自己重複的行為並將其寫下來。「我正在打造一個越來越抽象化的工作流，我參與的層次與以前不同。某種程度上，我成了自己的管理者。」他建議大家分析哪些事你信任代理、哪些不信任，然後記錄下來。

他也宣佈兩個專案：一個 T-Stack repo，最終會公開這些 skill（「我不會很快把它準備好」）；以及他的第一門課 Mega Dev，由 John Lindquist（Egghead 創辦人）開場、Kenzie 與 Angie 講中段、Browne 收尾。他將其定位為針對「公司會付訓練費」的人看的 AI 交付實務，並明確告訴觀眾不要為了找工作而購買。

未解的張力正是他自己指出的：Full Send 之所以可行，靠的是驗證系統、每六小時一次的 nightly 與回滾——這是多數團隊缺乏的基礎設施。缺少這些，「32 次中有 27 次無人監督下合併」僅是 Browne 自家環境的統計數字，並非普遍結論。另一個尚未解決的問題是 skill 檔案格式能否經得起 harness 的改版：他的 description、提問工具名稱與呼叫行為已經繫結特定 harness，而他也正因如此反覆修補這些檔案。