🔧 阿川の電商水電行
你可以對「氛圍編碼」（vibe coding）褒貶不一，但它對開源社群來說意義非凡。過去，為陌生的程式碼庫做出貢獻令人望而生畏，這意味著無論專案多麼受歡迎，開源專案的維護者都很難獲得社群的幫助。但現在有了人工智慧編碼工具，貢獻的門檻大大降低。事實上，我們用 Rust 建構的開源人工智慧代理框架goose就面臨截然相反的問題。我們收到的貢獻太多了，難以跟上！這當然是件好事，我們也希望確保貢獻者擁有良好的體驗。但僅靠我們自己審查實在力不從心。幸運的是，GitHub 上已經有Copilot 程式碼審查代理，可以隨時審查每個提交的 PR。
我開啟這個功能的時候以為大家都會喜歡，但說實話，效果並不理想。其他維護人員說評論太多太雜，而且大部分評論價值不高。他們問我們能不能把它關掉。
以下是我從幫助工程師使用人工智慧的經驗中學到的：你不能輕易放棄，不能禁用它，而應該不斷調整，教會模型如何按照你的期望執行，而不是僅僅寄希望於最好的結果。
在評估其部分評論時，我發現問題相當一致：
-
評論很長，而且數量龐大。
-
「或許」和「考慮一下」之類的評論太多，表示信心不足。
-
只有大約五分之一的評論是真正有價值的發現，是投稿者自己可能會錯過的。
我並不怪Copilot。它怎麼會知道我們關心什麼呢？我們又沒告訴它！幸運的是，我們有辦法告訴它。
Copilot 支援透過.github/copilot-instructions.md檔案進行自訂指令。我正是在這個文件中詳細說明了我們希望它如何運作。
哲學評論
我首先教導 Copilot 與我們期望人類審稿者遵循的原則相同的原則。
## Review Philosophy
* Only comment when you have HIGH CONFIDENCE (>80%) that an issue exists
* Be concise: one sentence per comment when possible
* Focus on actionable feedback, not observations
* When reviewing text, only comment on clarity issues if the text is genuinely confusing or could lead to errors.這立即減少了噪音。各種猜測停止了，取而代之的是清晰、可靠的回饋。
優先領域
然後我明確告訴它應該優先考慮哪些方面。這些才是我們在評測中真正關注的領域。再說一遍，如果我不提供這些背景訊息，Copilot 怎麼會知道呢？
## Priority Areas (Review These)
### Security & Safety
* Unsafe code blocks without justification
* Command injection risks (shell commands, user input)
* Path traversal vulnerabilities
* Credential exposure or hardcoded secrets
* Missing input validation on external data
* Improper error handling that could leak sensitive info
### Correctness Issues
* Logic errors that could cause panics or incorrect behavior
* Race conditions in async code
* Resource leaks (files, connections, memory)
* Off-by-one errors or boundary conditions
* Incorrect error propagation (using `unwrap()` inappropriately)
* Optional types that don’t need to be optional
* Booleans that should default to false but are set as optional
* Error context that doesn’t add useful information
* Overly defensive code with unnecessary checks
* Unnecessary comments that restate obvious code behavior
### Architecture & Patterns
* Code that violates existing patterns in the codebase
* Missing error handling (should use `anyhow::Result`)
* Async/await misuse or blocking operations in async contexts
* Improper trait implementations有了這份清單後，Copilot 就不再吹毛求疵，而是開始發現真正的問題。
專案特定背景
Copilot 不會自動了解你的設定。你必須告訴它正在審查的專案類型。
## Project-Specific Context
* This is a Rust project using cargo workspaces
* Core crates: `goose`, `goose-cli`, `goose-server`, `goose-mcp`
* Error handling: Use `anyhow::Result`, not `unwrap()` in production
* Async runtime: tokio
* See HOWTOAI.md for AI-assisted code standards
* MCP protocol implementations require extra scrutiny這樣的背景有助於它理解我們的架構和最重要的模式。
CI 管線上下文
Copilot 會在 CI 完成之前審查 PR，因此如果沒有上下文，它會對 CI 已經檢查過的內容進行評論。我加入了這行程式碼，以便它知道哪些內容已被檢查過。
## CI Pipeline Context
**Important**: You review PRs immediately, before CI completes. Do not flag issues that CI will catch.
### What Our CI Checks (`.github/workflows/ci.yml`)
**Rust checks:**
* cargo fmt --check
* cargo test --jobs 2
* ./scripts/clippy-lint.sh
* just check-openapi-schema
**Desktop app checks:**
* npm ci
* npm run lint:check
* npm run test:run
**Setup steps CI performs:**
* Installs system dependencies
* Activates hermit environment
* Caches Cargo and npm deps
* Runs npm ci before scripts
**Key insight**: Commands like `npx` check local node_modules first. Don't flag these as broken unless CI wouldn't handle it.跳過這些
下一部分至關重要。我告訴它哪些事情不要打擾我們。
## Skip These (Low Value)
Do not comment on:
* Style/formatting (rustfmt, prettier)
* Clippy warnings
* Test failures
* Missing dependencies (npm ci covers this)
* Minor naming suggestions
* Suggestions to add comments
* Refactoring unless addressing a real bug
* Multiple issues in one comment
* Logging suggestions unless security-related
* Pedantic text accuracy unless it affects meaning回覆格式
為了解決冗長的問題，我為它加入了結構。
## Response Format
1. State the problem (1 sentence)
2. Why it matters (1 sentence, if needed)
3. Suggested fix (snippet or specific action)
Example:
This could panic if the vector is empty. Consider using `.get(0)` or adding a length check.何時應該保持沉默
LLMs們都喜歡分享太多。有時候，沉默才是正確的選擇。
## When to Stay Silent
If you’re uncertain whether something is an issue, don’t comment.重點總結
對 Copilot 進行調整後，效果立竿見影。噪音顯著降低，語音提示也變得更實用。
但這並非最終版本。隨著越來越多的 PR 提交，我觀察了 Copilot 如何回應並不斷完善指南。以下是我們目前的程式碼審查指南版本。
如果你決定在自己的程式碼倉庫中實現這一點，也要做好同樣的準備。這並非一勞永逸的解決方案。隨著專案的演進，你需要觀察、調整並持續改進它。
如果人工智慧在你的程式碼庫中不太奏效，不要輕易放棄。遵循以下建議，你或許可以使其為你所用：
-
要具體明確。含糊不清的指示會導致含糊不清的結果。
-
設定置信閾值以降低噪音。
-
告訴它CI已經涵蓋了哪些內容。
-
請提供程式碼庫中的實際範例。
-
透過迭代不斷改進結果。
原文出處：https://dev.to/techgirl1908/how-i-taught-github-copilot-code-review-to-think-like-a-maintainer-3l2c
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
