# 策展 · X (Twitter) 🔥

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

> 作者：Delba (@delba_oliveira) · 平台：X (Twitter) · 日期：2026-06-04

> 原始來源：https://x.com/delba_oliveira/status/2062203743387459836

## 中文摘要

# 回饋迴圈：協助 Claude Code 以更少的監管完成艱鉅任務

隨著我們將更多艱鉅的任務委派給 Claude，它能否自行驗證工作成果變得越來越重要。

Claude 具備越強的自我驗證能力：

- 它就能越獨立地處理長期執行的任務
- 最終成果的品質就越好
- 達成目標所需的來回溝通次數就越少

好消息是，Claude 已經能針對確定性訊號（如型別錯誤、Lint 錯誤、測試失敗和執行階段錯誤）進行自我驗證。隨著模型不斷改進，這方面的能力只會越來越強。

Claude 無法總是推斷出你在它回應後，以及在將程式碼合併到正式環境前所進行的手動檢查。

你將這些檢查流程編碼得越多，Claude 的第一次回應就會越接近你心目中的最終成果。

如此一來，你花在監管上的時間變少了，而當你在處理其他事務時，Claude 也能持續運作。

## 寫下你的流程

一個好的開始是將你或你的團隊目前執行的最佳實踐寫下來。

以前端開發為例，通常包含：啟動開發伺服器、開啟瀏覽器、檢查主控台是否有錯誤、像使用者一樣點擊操作，並留意版面位移（layout shift）或頁面載入緩慢等問題。

每個領域都有各自的檢查方式。針對這些步驟中的每一項，通常都有 Claude 可以用來進行驗證的工具：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780542513528-diaHJ4Z1TJXAAEfjGjpg.jpg)

## 將你的流程編碼為 skill

一旦流程明確，請盡可能將其編碼為 skill。安裝 `skill-creator` plugin，然後請 Claude 採訪你：

```plaintext
/skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow.
```

如果你難以用文字描述你的流程，請先詢問 Claude 該領域的最佳實踐，並讓它展示端到端驗證流程看起來會是什麼樣子。

品味與判斷力很難被編碼，但許多檢查都有 Claude 可以衡量的標準：例如效能預算、無障礙檢查清單、設計系統規則，以及好與壞的範例。

例如，前端 skill 可能包含透過 Chrome DevTools MCP 或 Agent 瀏覽器擷取效能追蹤的指令。

```markdown
---
name: frontend-verify
description: Verify frontend changes in a browser. Run whenever 
a UI (page, component, typography, CSS style) change is made.
---

# Frontend verify

- Run a two-step verification pass in a real browser. 
- Fix issues and re-verify before responding to the user. 

## Step 1 — Verify the change behaves as expected

1. Open the URL in a browser:
   - In the Claude Code desktop app, use the embedded preview.
   - In the CLI, use the Chrome DevTools MCP.
2. Interact with the new element and confirm it renders and 
   behaves as expected.

## Step 2 — Verify the change passes a mobile audit

1. Open the URL in a new page via the Chrome DevTools MCP
2. Run a performance trace and audit Core Web Vitals

```

有些檢查比起「通過/失敗」更偏向定性分析，例如將資料與歷史基準進行比較。針對這類檢查，你可以與 Claude 合作，設定一套評估輸出的準則。

## 在合併前使用第二個 Agent 進行程式碼審查

上述所有步驟都在 Agentic 迴圈內完成。在合併前的那個瞬間，還有第二個驗證步驟，你可以要求另一個 Agent 進行審查。

新的 Agent 不會帶有編寫程式碼的那個 Agent 的偏見。它擁有自己的 context，且不受先前對話的影響。這種隔離性使審查更加客觀，並能抓出第一個 Agent 可能遺漏的問題。

以下提供幾種選擇，從手動到自動化皆有：

- `/review` (內建 skill) - 在你的終端機中快速進行一次 PR 審查。

- `/code-review` (可安裝的 plugin) - 同時啟動多個子 Agent，每個 Agent 從不同角度閱讀差異（diff），為發現的問題評估信心分數，並將結果發布在 PR 上。

- Claude Code Review - 一項託管服務，針對 Team 和 Enterprise 方案，會在 GitHub 上的每個 PR 自動執行。

無論你選擇哪一種，在合併到正式環境前擁有一道最後防線都非常有幫助。

## 整合運用

現在你擁有了兩層防護：

- Claude 在建置時執行的驗證
- 由未參與編寫程式碼的 Agent 在合併前進行的審查

兩者都屬於同一個開發生命週期。思考一下你目前的手動步驟：進行變更、清理程式碼、確認功能正常、提交（commit）、開啟 PR、等待審查，以及觀察 CI 狀態。

你可以透過編寫一個呼叫其他 skill 的 skill，將這些步驟整合進同一個工作流程中。例如，Claude Code 團隊在開發功能時會執行一個 skill，它整合了以下步驟：

1. 使用 `/simplify` skill 來清理 diff
2. 使用自訂的 `/verify` skill 來確認變更已完成端到端驗證
3. 如果 diff 涉及 UI，則進行設計檢查
4. 開啟並訂閱 PR 的步驟
5. 監控 CI 並在失敗時自動修復的 skill

雖然你的工作流程可能有所不同，但建立回饋迴圈並整合 skill，能讓 Claude 更全面地進行端到端的驗證與執行工作。

## 標籤

Claude Code, Agent, 功能更新, 自動化, Anthropic, Claude