# 策展 · X (Twitter) 🔥🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：PostHog (@posthog) · 平台：X (Twitter) · 日期：2026-07-11

> 原始來源：https://x.com/posthog/status/2075645235724767739

## 中文摘要

# 別再讓自己成為程式碼審查的瓶頸

Agent 撰寫程式碼的速度，早已超越任何人類所能審查的極限。

最單純的解決方案是讓開發者審查得更快，但「500 IQ」的做法是讓開發者盡可能少審查程式碼。

如果你必須參與每一項程式碼審查，那你永遠都會是瓶頸。相反地，應該透過建立一個能將任務委派給 Agent 的管線（pipeline），讓自己跳脫出程式碼審查的迴圈。

我們詢問了 PostHog 的工程師，了解他們如何審查 AI 生成的程式碼，在維持品質的同時保持快速交付。

以下是四個你可以直接套用的工作流程變更（包含 Prompt），能讓你的工作輕鬆許多。

# 1. 讓 Agent 代替你審查程式碼

如果你還沒這麼做，首要任務就是加入一套讓 Agent 代替你審查程式碼的機制。

![一則關於開發者如何審查 AI 生成程式碼的討論串截圖，其中一位使用者以迷因圖幽默回應。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/dab2d5e412372bb3.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">截圖顯示一個線上討論串，內容如下：
- Jina Yoon 於 6 月 25 日下午 3:53 發文：「question for devs! how do you make reviewing agent-generated code less painful in your own workflows?」（給開發者的問題！你們在自己的工作流程中，是如何讓審查 AI 代理生成的程式碼變得不那麼痛苦的？）
- 該貼文下方有 6 則回覆。
- Georges-Antoine 於 6 月 26 日上午 5:32 回覆了一張迷因圖，圖中人物表情困惑，配文為：「YOU GUYS ARE REVIEWING CODE?」（你們這些人還在審查程式碼嗎？）
- 該回覆下方有 7 個表情符號反應。</div></details>

目標是將較簡單的審查工作卸載給 Agent，並在真正需要人類介入時才發出警示。

關鍵在於，撰寫程式碼的 Agent 不能同時負責審查它自己的產出。Agent 很難檢查自己的工作，因為它們通常無法察覺自身的盲點。

基於同樣的原因，最好擁有多個具備不同指令與目標的 Agent 來覆蓋更多漏洞，並針對不同的審查者使用不同的模型與供應商。

以下是我們的工程師 @pauldambra 如何讓他的自訂 Agent 審查系統運作：

![這是一張展示「QA-SWARM」自動化程式碼審查工作流程的架構圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/466cb76ea2045c6f.png)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">該圖表描述了一個迭代式的程式碼審查流程，主要分為三個階段：
1. **QA-SWARM（頂層）**：負責並行啟動 4 個審查者，並發布行內 PR 評論與一個置頂摘要。
   - 下轄四個子代理：
     - **QA-TEAM**：負責資料庫、效能等技術性審查（使用 Fable）。
     - **SECURITY-AUDIT**：負責漏洞審查，如 SQL 注入或提示詞注入（使用 Fable）。
     - **PAUL-REVIEWER**：以 Paul 的語氣進行審查，針對命名、發布等（使用 Opus）。
     - **XP-REVIEWER**：應用極限程式設計（Extreme Programming）視角進行審查（使用 Opus）。
2. **REVIEW-TRIAGE（中層）**：負責分類所有未解決的討論串，確保最終狀態為已修復、已解決或已延後。
3. **處理結果（底層）**：
   - **ACTIONABLE → FIX &amp; PUSH**：針對明確、單一檔案、高確定性的問題。
   - **NIT → RESOLVE &amp; REPLY**：針對風格、重複或範圍外問題。
   - **AMBIGUOUS → PAUL-PAIR**：針對模糊問題，進入自動化階梯門控。
左側箭頭標示此流程為「ITERATES UNTIL COMPLETE」（迭代直到完成）。</div></details>

1. 首先，`qa-swarm` 會生成四個審查 Agent，每個都有其特殊的指令：
   - `qa-team`：生成技術子 Agent，專門搜尋安全性、資料庫、效能等問題。
   - `security-audit`：探測 SQL 注入或 Prompt 注入等漏洞。
   - `paul-reviewer`：模仿 Paul 的語氣，專注於可觀測性、發布流程與命名規範。
   - `xp-reviewer`：運用極限程式設計（Extreme Programming）的視角進行審查。

2. 接著，`review-triage` 會對這些審查結果進行分類，將討論串分為三類：
   - `actionable`（可執行）：進行修復並推送。
   - `nits`（小問題）：解決並回覆評論。
   - `ambiguous`（模糊）：升級並排序，留待 Paul 稍後與 Agent 一起處理。

3. 外層迴圈會迭代最多三次，直到沒有新的 `actionable` 討論串出現為止。

之後，你可以將此流程連接到另一個負責引導 PR 直到合併的迴圈——這部分會在下一節詳細說明。

> 重點：透過讓 Agent 互相審查來節省審查程式碼的時間。這能解決掉較簡單的審查，讓只有真正需要人類關注的 PR 才會被標記出來。

## 直接套用

你可以查看並複製 Paul 的 `qa-swarm` 與 `review-triage` skill，或者使用以下 Prompt 根據他的設計來規劃你自己的審查迴圈：

```
Read Paul D'Ambra's qa-swarm skill, plus its sibling review-triage in the same folder, then help me design my own version: https://github.com/pauldambra/dotfiles/blob/main/ai/skills/qa-swarm/SKILL.md

It should take in a single PR, spawn a reviewer panel, triage every finding and existing PR thread into actionable / nit / ambiguous, and keep going until nothing's left but the ambiguous ones flagged for me.  

Interview me about my stack, tooling, available models, and how autonomous it should be — what gets auto-fixed vs. only reported, and what it may post to GitHub — before writing the final SKILL.md, then install it.
```

話雖如此，這些系統可能會消耗大量的 token：

> 「我大約 60% 的 token 支出都花在自動化處理 CI 和審查的瑣事上，但我一點也不後悔。」—— Paul

因此，如果你的團隊無法執行多個 Agent 或迴圈，可以考慮像 Kun Chen 設計的那種單一 Agent 架構。

# 2. 將 PR 的瑣事委派給迴圈

Agentic 程式開發帶來的脈絡切換（context switching）非常耗神。減少這種疲勞的一個簡單方法，就是自動化那些不需要你關注、與程式碼審查相關的任務。

例如，照看單一 PR 可能涉及繁瑣的任務，如監控 CI、重新執行不穩定的測試（flaky tests）、檢查評論通知，以及保持分支更新。

既然可以將這些全部委派給迴圈，何必浪費你最寶貴的資源——你的精力呢？

> 重點：透過將 PR 照看等簡單任務委派給迴圈，來減少脈絡切換與疲勞。

## 直接套用

你可以根據 @haacked 的 `babysit-prs`，使用下方的 Prompt 實作你自己的 PR 保母 skill。（如果你已經從上一節建立了審查迴圈 skill，這會運作得更好。）

```
Read https://github.com/haacked/dotfiles/blob/main/ai/skills/babysit-prs/SKILL.md and adapt it for me: same sweep/state design, but it dispatches my own single-PR review skill via a spawned agent per unreviewed PR. 

Before writing SKILL.md, interview me on: which skill it dispatches and where my skills live, my stack/tooling/models, and which extra tasks to include — CI monitoring, branch freshness, flaky-test reruns, lint/format autofix, regenerating drifted artifacts, description sync. 

Ground the interview in  facts you can discover yourself (my open PRs, gh auth, clone layout) rather than asking about them.
```

# 3. 加入 PR 自動蓋章機

節奏快速的團隊會產生許多小型、低風險的 PR，而每一個在 GitHub 上都需要核准（也就是所謂的「蓋章」）。

![一隻戴著眼鏡、手持放大鏡的刺蝟正在檢查從機器中輸出的文件。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/85459e43d43202f9.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">這是一張卡通風格的插圖，畫面中有一隻擬人化的刺蝟，戴著眼鏡並手持放大鏡，正在專注地檢查一張紙本文件。刺蝟旁邊有一台類似伺服器或工業機器的設備，機器上方有螢幕顯示著圖形介面，並正持續輸出成疊的文件。畫面整體呈現簡約的向量繪圖風格，背景為淺藍色。圖中並無任何可轉錄的文字內容。</div></details>

在 PostHog，我們過去是在 Slack 的 `#dev-stamp-exchange` 頻道中處理這件事，將 PR 丟進去，然後等待某人快速核准並回覆一個蓋章表情符號。我們甚至還為此建立了排行榜。

這確實有效，但每次蓋章都需要另一位工程師中斷手邊的工作，去核准一個他們幾乎沒有脈絡的變更。

現在，這些工作大部分都由我們的 `StampHog` Agent 完成。僅僅一個季度，它就為我們主儲存庫中約三分之一的合併 PR 蓋下了最終核准章。

我們的工程師會在 GitHub 的 PR 上加上 `stamphog` 標籤，它會根據以下條件進行幾項安全檢查：

- PR 狀態：沒有合併衝突或變更請求。
- 影響範圍（Blast radius）：拒絕清單關鍵字（如 auth、secrets、billing、public APIs 等）。
- Diff 大小：少於 500 行程式碼且少於 20 個檔案。
- 簡單的 LLM 檢查：針對基本的阻礙性問題。

如果 Agent 核准了，它會留下一個純粹的 GitHub 核准，不會有行內評論。

否則，它會拒絕或升級並附上 1-2 句原因、風險等級評估以及後續步驟。通常這意味著根據 `CODEOWNERS` 和 `git-blame` 的熟悉度，將任務路由給相關領域的專家。

當 Agent 無法自動接受或路由時，我們仍會使用 `#dev-stamp-exchange`，但現在它的活躍度已經大幅降低。上個月，`StampHog` Agent 獨自處理了 1.6K 個 PR——這意味著我們的工程師少了 1.6K 次被 Slack 打斷的機會。

> 重點：讓 Agent 處理低脈絡的 PR 核准與路由，以減少干擾。使用確定性的檢查將敏感程式碼路由給人類。

## 直接套用

`StampHog` 的程式碼可以在這裡找到。它的許多內部運作方式是針對 PostHog 的，所以與其直接複製，不如使用這個 Prompt 根據我們的版本為你的儲存庫進行客製化：

```
Read https://github.com/PostHog/posthog/blob/master/tools/pr-approval-agent/README.md and build the equivalent for the repo at <path>. 

Copy the architecture; preserve its safety invariants exactly (fail closed, never request changes or merge, LLM can tighten gates but never loosen). 

Their deny-list and thresholds are calibrated to their codebase — re-derive mine: mine my git history for high-blast-radius deny candidates and calibrate size/tier ceilings from my merged PRs, then propose the full gate config for my sign-off before writing any code. 

At the same time, ask me whatever you can't derive from the repo — at minimum the CI system and trigger label, escalation routing if there's no CODEOWNERS, and which LLM/SDK to use and how CI gets its credentials. 

Leave the result as uncommitted files on my working tree.
```

# 4. 透過觀察驗證，而非推理

Agent 很擅長解釋為什麼他們的程式碼能運作。這些解釋通常很有說服力……但也往往是錯的。

如果你將程式碼進行端到端執行，你經常會發現 Agent 從未推理到的錯誤，或者輸出的結果與你要求的略有出入。

這就是為什麼 Daniel Visca 的經驗法則是以「可觀測性」優先於「推理」。當你可以親眼看著程式碼運作時，就不要接受「程式碼能運作」的論點。

黃金標準是你可以直接觀察到的事物，例如發送真實的 API 請求並讀取回應。如果行為就在你眼前，你根本不需要信任 Agent 的邏輯。但這有一個擴展性問題，因為 3,000 行的 PR 很難進行信任與觀察。

他的方法是讓 Agent 將工作拆解。例如，針對大型變更（如端到端建立指標管線），他會指示 Agent 產生一堆小型、單一用途的 PR，然後使用 Graphite 的「堆疊（stacking）」功能。這使得每個 diff 都能獨立執行並被觀察：

![這張截圖顯示了在 Graphite 上，針對 posthog-js 專案進行的一系列關於 CLI 分析功能的程式碼變更與合併請求堆疊。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/e8e0009b85f4ddcf.jpg)

<details class="chart-data"><summary>展開畫面重點</summary><div class="me-note">畫面顯示的是 Graphite 上的開發者工作流程介面，主要內容為 posthog-js 專案的合併請求（Pull Request）堆疊（Stack），共包含 5 個相關的變更項目：
1. #3894 feat(cli-analytics): instrument() handle and commander adapter
2. #3893 feat(cli-analytics): event capture pipeline
3. #3892 feat(cli-analytics): anonymous identity, session, and consent
4. #3891 feat(cli-analytics): detect AI agents driving the CLI
5. #3890 feat(cli-analytics): scaffold @posthog/cli-analytics package

頁面頂部顯示該合併請求由 Daniel Visca 發起，分支從 `posthog-code/cli-analytics-instrument` 合併至 `posthog-code/cli-analytics-pipeline`，共涉及 5 個檔案變更，新增 645 行程式碼，更新時間為 5 天前。每個項目右側標示了討論串數量（例如 0/4）以及狀態為「Draft」（草稿）。</div></details>

在堆疊的每一步，你都可以執行真實檢查，確認輸出符合預期。然後，隨著你由下而上合併，每一層都只建立在已經過驗證的行為之上。

透過這種方式，早期的錯誤不會累積，且當某處出錯時，你是在除錯一個小的 diff，而不是整個變更。

額外的好處是，這能讓第 3 節提到的 `StampHog` 自動核准那些小型且聚焦的 PR。最終你會得到兩種不同的檢查：Agent 先對程式碼進行推理，而人類則觀察其實際行為。

> 重點：當你無法信任 Agent 的推理時，不要去讀更多的程式碼；將變更拆解，直到你可以觀察每個部分的運作。觀察比審查更具擴展性。

## 直接套用

你可以使用 Graphite 來堆疊由你的 Agent 產生的較小 PR，並使用以下指令來設定：

```
Split work into a stack of small PRs, each under 400 changed lines and focused on a single change, building only on the PRs below it. 

Every PR must ship with its own tests and end with a way to observe it working directly — a command to run and the output I should expect.
```

這種方法對於前端工作特別有價值，因為確定性的測試並不總是能捕捉到你所追求的視覺或行為功能。

Pawel Cebula 表示，讓 Agent 為每個步驟拍攝截圖和 GIF 是非常節省時間的做法，可以使用類似這樣的指令：

```
For each PR with frontend work, run the affected screens and capture evidence from the branch's final state: a screenshot of each relevant state (empty, loading, error, populated) and a GIF of the key interaction end to end. Where behavior changes, include before/after. 

Attach it all to the PR so the change can be reviewed by observation, not by reading the diff — and re-capture if the code changes after.
```

本文由 @jinayoon_ 撰寫，據她所言，她本人正是這篇文章的瓶頸。

## 標籤

Agent, 教學資源, 自動化, PostHog