返回列表

部落格

使用 Tactic Remote 自動化程式碼審查

設定 AI 驅動的程式碼審查工作流程,在程式碼進入團隊的 Pull Request 佇列之前捕捉錯誤、安全問題和品質問題。

發布於 標籤: 入門教學 / code-review / workflow / quality
部落格

繼續查看該欄目下的產品與工程更新。

瀏覽此分類

程式碼審查對軟體品質至關重要,但也非常耗時。開發者估計每週花費 6-8 小時審查同事的程式碼——這些時間本可以用來開發功能。AI 驅動的程式碼審查並非取代人工審查者,而是處理機械性的面向(捕捉錯誤、風格違規、缺少錯誤處理),讓人工審查者能專注於架構、設計和業務邏輯。

本教學將向您展示如何使用 Tactic Remote 設定 AI 驅動的程式碼審查工作流程。

審查工作流程

以下是我們要設定的工作流程:

  1. 開發者在功能分支上完成工作。
  2. 在建立 Pull Request 之前,從手機啟動一個 Claude Code 審查 session。
  3. Claude Code 分析與主分支的差異,產生全面的審查報告。
  4. 開發者從手機處理審查結果(核准修復或註記例外)。
  5. 整理後的程式碼被推送,並建立附帶 AI 審查摘要的 PR。

這能捕捉到 60-80% 在人工審查中才會發現的問題,大幅縮短審查循環時間。

步驟 1:準備您的審查提示

在專案根目錄建立一個名為 .claude-review-prompt.md 的檔案。這將作為 AI 審查的指令集:

# Code Review Instructions
 
Review all changes on the current branch compared to the `main` branch.
 
## What to Check
 
### Critical Issues (must fix before merge)
 
- **Logic errors**: Code that doesn't do what it claims
- **Security vulnerabilities**: SQL injection, XSS, auth bypasses, credential exposure
- **Data loss risks**: Missing transactions, incorrect cascade deletes, race conditions
- **Breaking changes**: API contract violations, backwards-incompatible modifications
 
### Warnings (should fix, but not blocking)
 
- **Missing error handling**: Uncaught exceptions, unhandled promise rejections
- **Performance concerns**: N+1 queries, unnecessary re-renders, missing memoization
- **Missing validation**: User input not validated before processing
- **Test coverage gaps**: New code paths without corresponding tests
 
### Suggestions (nice to have)
 
- **Readability improvements**: Unclear variable names, complex logic that could be simplified
- **Documentation gaps**: Public APIs without JSDoc/TSDoc comments
- **Potential refactoring**: Duplicated logic, overly long functions
 
## Output Format
 
For each finding, provide:
 
1. **Severity**: CRITICAL / WARNING / SUGGESTION
2. **File**: Exact file path and line numbers
3. **Description**: What the issue is, in one sentence
4. **Explanation**: Why it matters, with context
5. **Fix**: Concrete code suggestion to resolve the issue
 
At the end, provide:
 
- Summary: X critical, Y warnings, Z suggestions
- Overall assessment: Is this branch ready for human review?
 
## What NOT to Flag
 
- Style preferences covered by our linter (ESLint/Prettier handle this)
- Import ordering (automated)
- Whitespace or formatting (automated)
- Type annotations that TypeScript can infer

這個提示是刻意寫得具體的。模糊的審查指令會產生模糊的審查結果。具體的指令會產生可操作的發現。

步驟 2:從手機執行審查

當您準備好審查一個分支時,開啟 Tactic Remote 並啟動一個指向專案目錄的 session。發送:

Checkout branch feature/user-dashboard.
Follow the review instructions in .claude-review-prompt.md.

Claude Code 會:

  1. 切換到該分支
  2. 計算與 main 的差異
  3. 根據您的審查標準分析每個變更的檔案
  4. 輸出結構化的審查報告

這通常需要 3-8 分鐘,取決於差異的大小。完成後您會收到通知。

步驟 3:查看審查結果

審查輸出會出現在您的終端機檢視中。以下是典型的審查結果範例:

🔴 CRITICAL — src/api/routes/users.ts:47-52

Description: SQL query constructed with string concatenation, vulnerable to injection.

Explanation: The search query parameter is interpolated directly into the SQL
string without parameterization. An attacker could craft a search input that
modifies the query logic, potentially extracting or modifying data.

Fix: Use parameterized query:
  // Before (vulnerable)
  const results = db.query(`SELECT * FROM users WHERE name LIKE '%${search}%'`)

  // After (safe)
  const results = db.query('SELECT * FROM users WHERE name LIKE ?', [`%${search}%`])

針對每個發現,您可以從手機上選擇三個選項:

套用修復: 提示 Claude Code 實作建議的修復:

Apply the fix for the SQL injection issue in users.ts:47.

略過: 如果您不同意該發現或它是誤報,記下來稍後處理並繼續。

討論: 如果您不確定,向 Claude Code 詢問更多上下文:

Explain the SQL injection risk in more detail. Is this exploitable given
our authentication middleware that runs before this route?

步驟 4:自動套用修復

對於有多個發現的審查,您可以批次套用修復:

Apply fixes for all CRITICAL and WARNING findings from the review.
For each fix, run the relevant tests to verify the fix doesn't break anything.
Report which fixes were applied and which tests passed.

Claude Code 會系統性地處理這些發現,套用修復並執行測試。這是另一個您可以放下手機等待通知的任務。

重要: 在提交之前審查已套用的修復。AI 產生的修復通常是正確的,但「通常」對於正式環境的程式碼來說不夠好。使用終端機檢視來確認差異:

Show me the complete git diff of all changes made during this review.

步驟 5:產生 PR 摘要

修復套用並驗證完成後,產生一份適合 PR 的摘要:

Create a pull request description that includes:
1. What this branch does (based on the commit history)
2. Summary of the AI review findings and how they were addressed
3. Any remaining suggestions that were intentionally deferred
4. Test results

將此包含在您的 PR 描述中。這讓人工審查者相信程式碼已經過預先審查,並告訴他們應該關注什麼。

進階:持續審查 Session

對於長期運行的功能分支,定期執行審查而不是只在 PR 時才做:

Review all commits since the last review marker.
After completing the review, create a git tag 'last-ai-review' at HEAD.

透過每天執行審查,您可以在問題被引入時就近捕捉。這比在開發一週後才發現問題更容易修復。

與 CI/CD 整合

對於想要將 AI 審查正式化的團隊,您可以在分支被推送時自動觸發審查 session。工作流程如下:

  1. CI webhook 觸發 Tactic Remote Mac companion app。
  2. Companion app 在更新後的分支上啟動一個 Claude Code session。
  3. Claude Code 執行審查提示。
  4. 結果以評論形式發布在 Pull Request 上。

這需要在 Mac 端進行腳本編寫(companion app 提供了用於 session 管理的 API),詳細資訊請參閱我們的進階整合文件。

衡量影響

採用 AI 程式碼審查後,追蹤這些指標:

  • 審查花費時間: 應減少 30-50%,因為人工審查者花更少時間在機械性檢查上。
  • 審查中捕捉到的問題 vs. 正式環境中的問題: 應向左移——更多問題在 AI 審查中被捕捉,更少問題流入正式環境。
  • 審查循環時間: 從 PR 建立到核准的時間應該減少,因為 PR 在提交時已經過預先審查。
  • 開發者滿意度: 審查者應報告更少的乏味感和更多對有意義的架構回饋的專注。

AI 程式碼審查不是要取代人類判斷。它是要確保人類判斷被花在最重要的問題上——架構、設計和業務邏輯——而非捕捉打字錯誤和缺少的 null 檢查。

從單一專案開始,根據結果改進您的審查提示,然後在校準方法後擴展到整個團隊。在好的審查提示上的投資會在每次使用它的審查中產生回報。

立即體驗 Tactic Remote

用手機遠端操作程式開發 Agent

連線到 Mac、Windows 或 Linux 電腦上的 Claude Code、Codex 等 Agent,在 iPhone 或 iPad 上查看進度並傳送下一個請求。