Phần 1: Yêu cầu Từ Khách Hàng – Đánh Giá PR-Agent và việc sử dụng PR-agent trong review code và hướng tới tích hợp vào dự án

Vậy PR-Agent là gì?

PR-Agent là một công cụ mã nguồn mở do CodiumAI phát triển, được thiết kế để tự động hóa và nâng cao quy trình review Pull Request (PR). Nó hoạt động như một trợ lý AI, có khả năng tự động phân tích các thay đổi trong code, tạo mô tả chi tiết cho PR, đưa ra các đề xuất cải thiện về chất lượng code, và tuân thủ các tiêu chuẩn lập trình. Mục tiêu chính của PR-Agent là giúp các nhóm phát triển tiết kiệm thời gian, nâng cao chất lượng mã nguồn và tăng tốc chu trình phát triển phần mềm.

Nhiệm vụ chi tiết:

1. Thử thách PR-Agent: Tích hợp và đánh giá hiệu quả của nó với bộ quy tắc 7 file gần 2000 dòng.
2. Cải thiện và Đề xuất: Tìm cách tối ưu, hoặc nếu không, hãy tìm một con đường khác tốt hơn.
3. Mục tiêu cuối cùng: Tích hợp một giải pháp AI review code đáng tin cậy vào dự án hiện tại.

Phần 2: Cuộc Thử Nghiệm Đầu Tiên – Những Con Số Không Biết Nói Dối

Để có một câu trả lời công bằng cho PR-Agent, tôi cần dữ liệu, không phải cảm tính. Tôi tạo ra hai kịch bản chính:

• PR phức tạp: Một Pull Request với 30 lỗi.
• PR đơn giản: Một Pull Request chỉ với 6 lỗi.

Với mỗi kịch bản, tôi cho PR-Agent “thi đấu” ở ba hạng mục:

• Rules gốc: Không có rules tùy chỉnh.
• Rules tối giản: Sử dụng bộ rules gốc gần 2000 dòng của khách hàng.
• Không rules: Sử dụng bộ rules đã được tôi tối giản, chắt lọc lại theo dạng gạch đầu dòng cho AI “dễ tiêu hóa” hơn.

Cảm giác của tôi lúc đó là hy vọng. Tôi đã cố gắng “mớm” cho AI một cách dễ dàng nhất có thể. Nhưng kết quả lại phũ phàng hơn tôi nghĩ.

Khi PR-Agent “Bối Rối”

Với PR 30 lỗi:

• Rules gốc: Chỉ tìm thấy 6/30 lỗi(hầu hết là các lỗi cơ bản). Tệ hơn, nó hoàn toàn “quên” mất yêu cầu song ngữ và chỉ trả lời bằng tiếng Anh.
• Rules tối giản: Khá hơn một chút, tìm được 10/30 lỗi và giữ được khả năng song ngữ.
• Không rules: Tìm được 5 lỗi, vẫn có song ngữ.

Điều này cho thấy, bộ rules đồ sộ gần như không giúp ích gì, thậm chí còn làm AI “nhiễu” hơn.

Với PR 6 lỗi:

• Rules gốc: Tìm được 5/6 lỗi, nhưng lại không đưa ra được bất kỳ suggestion sửa lỗi nào. Khả năng song ngữ thì lúc được lúc không.
• Rules tối giản: Đây là điểm sáng duy nhất. Nó tìm thấy 6/6 lỗi, đưa ra 6/6 suggestion và hoạt động song ngữ hoàn hảo.

Kết luận ban đầu của tôi: PR-Agent không phải là một công cụ tồi, nhưng nó không được sinh ra để “thực thi” một bộ luật phức tạp. Nó giống một người trợ lý đưa ra “gợi ý” dựa trên những chỉ dẫn ngắn gọn hơn là một reviewer khó tính. Với gần 2000 dòng quy tắc, nó đã bị quá tải.

Phần 3: Ngõ Cụt và Tia Sáng Mới – Ý Tưởng về Copilot và MCP Server

Cảm giác đâm đầu vào tường thật không dễ chịu. Nhưng chính những lúc như vậy, những ý tưởng điên rồ nhất lại nảy ra. Tôi tự hỏi: “Nếu không thể dạy một công cụ có sẵn, tại sao không tự xây dựng một thứ cho riêng mình?”.

Tôi đề xuất với khách hàng một hướng đi hoàn toàn mới, một kiến trúc mà tôi tin rằng sẽ giải quyết được vấn đề từ gốc rễ: Sử dụng GitHub Copilot trong IDE, kết hợp với một GitHub MCP Server chạy local.

Nghe có vẻ phức tạp, nhưng ý tưởng cốt lõi lại rất mạnh mẽ:

✅ Tích hợp Mạnh Mẽ: MCP server sẽ là cầu nối trực tiếp giữa Copilot và GitHub. Copilot không chỉ đọc diff, nó có thể truy cập toàn bộ repository, sử dụng mọi công cụ phân tích mà một lập trình viên có.

✅ Workflow Tự Nhiên: AI sẽ hoạt động như một reviewer con người thực thụ: đọc thay đổi, phân tích từng file, và để lại comment chi tiết trên từng dòng code.

Tất nhiên, có một sự đánh đổi: chúng tôi sẽ mất đi sự tiện lợi của tích hợp CI/CD. Đây là một công cụ thủ công, không phải một cỗ máy tự động.

Khách hàng đã bị thuyết phục. Họ cho tôi “bật đèn xanh” để triển khai thử nghiệm.

Phần 4: “Ngọc Bất Trác, Bất Thành Khí” – Khi Github Copilot Là Viên Ngọc Thô

Sở hữu GitHub Copilot trong tay giống như có được một viên ngọc thô quý giá. Tôi đã quá tự tin vào tiềm năng của nó mà quên mất rằng ‘ngọc không mài không sáng’. Cách tiếp cận đầu tiên của tôi rất ‘con người’: tôi xây dựng một prompt duy nhất, thật dài, giải thích cặn kẽ từng bước và kỳ vọng Copilot sẽ tự mình giải quyết tất cả.

Và tôi đã thất bại… một lần nữa.

Kết quả còn tệ hơn cả PR-Agent. Với 30 lỗi, Copilot chỉ tìm ra được 7-8 lỗi. Vấn đề nằm ở đâu?

• AI “Lười Biếng”: Nó chỉ đọc vài dòng đầu của các file rules rồi bỏ qua phần còn lại.
• AI “Hay Quên”: Context quá lớn khiến nó thường xuyên “mất trí” giữa chừng, đang phân tích thì nhảy thẳng đến kết luận.
• AI “Sáng Tạo” Quá Mức: Mỗi lần chạy, nó lại chọn một công cụ khác nhau, một con đường khác nhau, dẫn đến kết quả không thể đoán trước.

Tôi đã nhận ra một bài học xương máu: Không thể đối xử với một Agent AI mạnh mẽ như một chatbot thông thường. Đưa cho nó một “tờ sớ” dài ngoằng và hy vọng nó sẽ ngoan ngoãn làm theo là một sai lầm.

Và rồi, khoảnh khắc “Aha!” đã đến. Tôi nhận ra rằng, ẩn sau lớp vỏ ngôn ngữ tự nhiên, Copilot cũng có những “hàm” (tools) mà tôi có thể gọi và truyền đối số vào, giống như trong lập trình vậy! Một số các tools tôi có thể kể như:

• read_file({ filePath, startLine, endLineNumber }): Đọc nội dung một phần của file.
• file_search({ query, maxResults }):Tìm file theo glob pattern.
• grep_search({ query, includePattern, isRegexp, maxResults }) : Tìm kiếm chuỗi văn bản trong file.
• semantic_search({ query }): Tìm kiếm thông minh theo ngữ nghĩa trong workspace.
• …

Chính nhờ khả năng này mà tôi không cần phải nhờ AI “đọc file” một cách chung chung nữa, thay vào đó, tôi có thể ra lệnh trực tiếp: “dùng tool read_file với một đường dẫn cụ thể.”

Bạn có thể yêu cầu Github Copilot hay các AI coding agent khác list danh sách các công cụ khả dụng của chúng chỉ bằng câu lệnh:

List tools hiện tại bạn có thể sử dụng(tên hàm, đối số, tác dụng, cách dùng)

Phần 5: “Chia Để Trị” – Lập Trình AI Với Hai Agent Chuyên Biệt

Khám phá về khả năng sử dụng tools của Copilot đã thay đổi hoàn toàn cuộc chơi. Tôi nhận ra sai lầm của mình không nằm ở công cụ, mà ở cách tôi sử dụng nó. Prompt ban đầu trong file review_pr.prompt.md của tôi thất bại vì nó quá “con người” – tôi cố gắng giải thích mọi thứ bằng ngôn ngữ tự nhiên và mong đợi AI sẽ tự suy luận.

Ví dụ về prompt ban đầu không hiệu quả:
Về cơ bản, tôi đã yêu cầu AI thực hiện một loạt các bước cấp cao, giống như giao việc cho một nhân viên mới thay vì ra lệnh cho một cỗ máy:

Using the GitHub MCP server, perform a comprehensive review of pull request #[PR_NUMBER] in repository [OWNER/REPO] following this DYNAMIC RULES-FIRST process:

 

STEP 1: Get PR Information

STEP 2: DYNAMICALLY LOAD TEAM RULES (PRIMARY PRIORITY)

STEP 3: APPLY LOADED RULES TO CODE CHANGES

STEP 4: APPLY STANDARD CODING PRACTICES (SECONDARY)

STEP 5: Categorize Issues by Team Standards

…

Cách tiếp cận này tỏ ra quá mơ hồ và không hiệu quả. Tôi cần một chiến lược mới, một chiến lược “chia để trị”. Tôi đã chia nhỏ quy trình thành hai Agent riêng biệt, mỗi Agent có một prompt chuyên dụng, hoạt động giống như các hàm được định nghĩa rõ ràng: Nhà Phân Tích (Analyst) và Người Báo Cáo (Reporter).

Prompt 1: Nhà Phân Tích

Prompt analyst.prompt.md được thiết kế để trở thành một chuyên gia phân tích thuần túy. Nó không cần phải giao tiếp với con người. Nhiệm vụ của nó là thực thi một chuỗi các lệnh gọi tool một cách có hệ thống để “bóc tách” 2000 dòng rules, phân tích code thay đổi, và tạo ra một danh sách các vi phạm có cấu trúc (dạng JSON). Nó không “đọc” và “hiểu” theo cách của con người, nó thực thi.

Ví dụ về một phần trong prompt “Nhà Phân Tích”:
Prompt này ra lệnh cho AI một cách chính xác phải làm gì, dùng công cụ nào, với tham số nào.

#### 1.1 AUTO-DETECT RULES STRUCTURE

“””

# TOOL: file_search

# Discover rules directory (project-agnostic)

file_search(query: “**/*rules*/**”)

→ Set RULES_DIRECTORY = first_found_directory

“””

#### 1.2 COMPREHENSIVE RULES FILE DISCOVERY

“””

# TOOL: file_search

# Find all rules files with various formats

file_search(query: “{RULES_DIRECTORY}/*.md”)

→ Set RULES_FILES = all_discovered_files

“””

# TOOL: read_file

# Read each rules file completely

“””

FOR each file in RULES_FILES:

  read_file(filePath: file, startLineNumber: 1, endLineNumber: 9999)

“””

…

Prompt 2: Người Báo Cáo

Sau khi Nhà Phân Tích hoàn thành công việc và trả về một danh sách các vi phạm có cấu trúc, Agent thứ hai, report.prompt.md, sẽ vào cuộc. Nhiệm vụ của nó rất đơn giản: lấy dữ liệu đã được cấu trúc và trình bày nó một cách chuyên nghiệp. Nó sử dụng một template nghiêm ngặt để tạo ra các bình luận song ngữ Anh-Nhật và đăng chúng chính xác vào dòng code bị lỗi trên Pull Request.

Ví dụ về template trong prompt “Người Báo Cáo”:
Template này đảm bảo mọi bình luận đều nhất quán, rõ ràng và chứa đầy đủ thông tin cần thiết.

🚨 CODING RULE VIOLATION: [RULE_TITLE] – Rule violation / ルール違反

**Rule Source / ルールソース:** .rules/[FILENAME].md

**Rule Description / ルール説明:**

EN: [ENGLISH_RULE_EXPLANATION]

JP: [JAPANESE_RULE_TEXT_FROM_FILE]

**Violating Code / 違反コード:**

“””[language]

[actual code block that violates the rule]

“””

**Code-Compliant Fix / ルール準拠修正:**

“””[language]

[suggested fix for the specific code block based on rule requirements]

“””

…

Kết quả thật mỹ mãn.

• Với PR 6 lỗi: Phát hiện 6/6 lỗi, có tham chiếu đến rule, comment trực tiếp vào dòng lỗi, và đưa ra suggestion sửa lỗi chi tiết.
• Với PR 30 lỗi: Phát hiện 22/30 lỗi. Một bước nhảy vọt so với tất cả các thử nghiệm trước đó!

Tôi biết rằng con số 22/30 vẫn có thể được cải thiện nếu có thêm thời gian để tối ưu, nhưng nó đã chứng minh được một điều: cách tiếp cận có cấu trúc, “lập trình” cho AI mang lại hiệu quả vượt trội.

Phần 6: Cái Kết Thực Tế và Bài Học Rút Ra

Khách hàng, sau khi xem xét tất cả, đã đưa ra một quyết định mà tôi cho là vô cùng khôn ngoan và thực tế:

• Tiếp tục triển khai PR-Agent: Nó vẫn sẽ được tích hợp vào CI/CD để thực hiện các review cơ bản, tự động.
• Tích hợp giải pháp Github Copilot + Github MCP: Công cụ này sẽ được đưa vào dự án như một công cụ để chính khách hàng có thể sử dụng khi PR phức tạp cần cần độ chính xác và tuân thủ rules.

Bài Học Lớn Nhất: Từ “Ra Lệnh” đến “Lập Trình” Cho AI

Hành trình này đã dạy cho tôi một bài học vô giá. Kỷ nguyên của AI không chỉ dừng lại ở việc viết ra những câu lệnh bằng ngôn ngữ tự nhiên. Chúng ta không còn chỉ hy vọng vào một “phép màu”, mà chủ động thiết kế và kiểm soát quá trình để đạt được kết quả mong muốn. Đây không phải là sự thụt lùi, mà là một cách tiếp cận khác đi trong cách chúng ta tương tác với AI. Để khai thác được sức mạnh thực sự của chúng, chúng ta, những lập trình viên, phải học cách “lập trình” cho chúng.

Chúng ta cần chuyển tư duy từ việc hướng dẫn một trợ lý, sang việc kiến tạo một cỗ máy thông minh. Điều này có nghĩa là:

• Chia nhỏ vấn đề: Thay vì một yêu cầu lớn, hãy chia thành các tác vụ nhỏ, rõ ràng.
• Chỉ định công cụ: Ra lệnh chính xác cho AI sử dụng công cụ nào cho từng tác vụ.
• Điều phối quy trình: Xây dựng một luồng làm việc có cấu trúc, nơi đầu ra của bước này là đầu vào của bước tiếp theo.