Bạn có thể nói gì về việc lập trình theo cảm hứng, nhưng nó thực sự tuyệt vời cho mã nguồn mở.
Việc đóng góp vào các codebase không quen thuộc từng rất đáng sợ, điều đó có nghĩa là những người bảo trì dự án mã nguồn mở nhận được rất ít sự giúp đỡ từ cộng đồng bất kể dự án đó phổ biến đến đâu.
Nhưng giờ đây với các công cụ lập trình AI, rào cản để đóng góp đã thấp hơn nhiều.
Trên thực tế, chúng tôi gặp phải vấn đề hoàn toàn ngược lại vớigoose, một framework agent AI mã nguồn mở được xây dựng bằng Rust.
Chúng tôi nhận được quá nhiều đóng góp đến mức khó có thể theo kịp!
Đó là một vấn đề tuyệt vời để có, và chúng tôi muốn đảm bảo những người đóng góp có trải nghiệm tốt.
Nhưng chỉ riêng chúng tôi thì không thể xem xét hết được.
May mắn thay, đã có mộtagent Copilot Code Reviewsẵn sàng trên GitHub để xem xét mọi PR ngay khi nó được mở.
Tôi đã bật nó lên và nghĩ rằng mọi người sẽ thích nó, nhưng thật lòng mà nói, mọi chuyện không diễn ra tốt đẹp.
Những người bảo trì khác nói rằng các đánh giá quá ồn ào và hầu hết các nhận xét đều có giá trị thấp.
Họ hỏi liệu chúng tôi có thể tắt nó đi không.
Đây là điều tôi biết được từ việc hỗ trợ các kỹ sư làm việc với AI:
bạn không bỏ cuộc.
Bạn không vô hiệu hóa.
Bạn điều chỉnh.
Bạn dạy cho mô hình cách bạn muốn làm việc, không chỉ hy vọng vào kết quả tốt nhất.
Khi đánh giá một số bài đánh giá của nó, tôi có thể thấy các vấn đề khá nhất quán:
- Các nhận xét dài dòng và choáng ngợp
- Có quá nhiều nhận xét “có thể” và “cân nhắc” cho thấy độ tin cậy thấp
- Chỉ khoảng 1 trong 5 nhận xét thực sự là những phát hiện tốt mà người đóng góp có thể đã bỏ sót
Tôi không đổ lỗi cho Copilot về bất kỳ điều gì trong số này.
Làm sao nó biết chúng tôi quan tâm đến điều gì?
Chúng tôi đã không nói với nó!
May mắn thay, có một cách để làm điều đó.
Copilot hỗ trợhướng dẫn tùy chỉnhthông qua tệp.github/copilot-instructions.md.
Đó là nơi tôi chỉ định chính xác cách chúng tôi muốn nó hoạt động.
Nội dung chính
Triết lý Đánh giá
Tôi bắt đầu bằng cách dạy Copilot những nguyên tắc tương tự mà chúng tôi mong đợi từ những người đánh giá là con người.
## 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. Điều này ngay lập tức cắt giảm sự ồn ào.
Nó ngừng suy đoán và bắt đầu tập trung vào phản hồi rõ ràng, tự tin.
Các Khu vực Ưu tiên
Sau đó, tôi nói với nó chính xác những gì cần ưu tiên.
Đây là những lĩnh vực chúng tôi thực sự quan tâm trong các đánh giá.
Một lần nữa, làm sao Copilot có thể biết điều đó trừ khi tôi cung cấp ngữ cảnh này?
## 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 Một khi có danh sách này, Copilot đã ngừng bới lông tìm vết và bắt đầu phát hiện những vấn đề thực sự.
Ngữ cảnh Cụ thể cho Dự án
Copilot không biết một cách kỳ diệu về thiết lập của bạn.
Bạn phải nói cho nó biết đó là loại dự án gì mà nó đang đánh giá.
## 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 Ngữ cảnh này giúp nó hiểu kiến trúc của chúng tôi và các mẫu quan trọng nhất.
Ngữ cảnh Pipeline CI
Copilot đánh giá các PR trước khi CI hoàn tất, vì vậy nếu không có ngữ cảnh, nó sẽ nhận xét về những thứ mà CI đã kiểm tra.
Tôi đã thêm phần này để nó biết những gì đã được bao phủ.
## 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. Bỏ qua Những Điều Này
Phần tiếp theo là rất quan trọng.
Tôi đã nói với nó những điềukhôngnên làm phiền chúng tôi.
## 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 Định dạng Phản hồi
Để khắc phục sự dài dòng, tôi đã cung cấp cho nó một cấu trúc.
## 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. Khi nào nên Im lặng
Các LLM thích chia sẻ quá mức.
Đôi khi im lặng là lựa chọn đúng đắn.
## Khi Nào Nên Giữ Im Lặng Nếu bạn không chắc điều gì đó có phải là vấn đề hay không, đừng bình luận. Điểm Chính Rút Ra
Sau khi điều chỉnh Copilot, sự khác biệt là ngay lập tức.
Tiếng ồn giảm đáng kể và các bình luận trở nên hữu ích hơn.
Nhưng đây không phải là hình thức cuối cùng của nó.
Khi nhiều PR hơn được gửi đến, tôi đã quan sát cách Copilot phản hồi và tinh chỉnh các hướng dẫn mỗi lần.
Đây là phiên bản hiện tại củahướng dẫn đánh giá mãcủa chúng tôi.
Nếu bạn quyết định thiết lập điều này cho kho lưu trữ của riêng mình, hãy mong đợi làm điều tương tự.
Đây không phải là một bản sửa lỗi một lần.
Bạn sẽ cần quan sát, điều chỉnh và tiếp tục dạy nó khi dự án của bạn phát triển.
Nếu AI không hoạt động tốt cho cơ sở mã của bạn, đừng loại bỏ nó.
Bạn có thể khiến nó hoạt động có lợi cho mình bằng cách làm theo những mẹo sau:
- Hãy cụ thể.
Hướng dẫn mơ hồ dẫn đến kết quả mơ hồ. - Đặt ngưỡng độ tin cậy để giảm tiếng ồn.
- Cho nó biết những gì CI đã bao phủ.
- Bao gồm các ví dụ thực tế từ cơ sở mã của bạn.
- Lặp lại để tiếp tục cải thiện kết quả theo thời gian.
