AILapTrinh.comAI Lập Trình
Tác tử AI và làm việc nhóm

Mô tả pull request có mã AI viết: ghi chú giúp người rà đọc nhanh và đọc đúng chỗ

Cách viết phần mô tả pull request khi có AI tham gia: nêu mức tham gia, chỗ cần đọc kỹ, cách đã kiểm, điều chưa chắc, giúp người rà mã làm nhanh mà không bỏ sót.

Two developers at a long wooden table in a Can Tho coworking space, one jotting on a blank notepad while the other gestures toward a softly blurred laptop

Khi có AI tham gia viết mã, phần mô tả pull request trở thành công cụ quan trọng nhất của người gửi: nó nói cho người rà biết AI làm phần nào, bạn đã tự kiểm những gì, chỗ nào cần đọc kỹ và điều gì bạn chưa chắc. Một mô tả tốt rút thời gian rà xuống đáng kể và giảm hẳn khả năng lỗi lọt qua.

Bài này góc người gửi yêu cầu gộp; cách người rà dùng AI để soát vòng đầu có bài riêng ở danh mục kiểm thử và rà soát. Ở đây bạn sẽ có một mẫu mô tả sáu phần, ví dụ hoàn chỉnh, và những câu nên tránh vì chúng làm người rà tin nhầm. Mẫu dùng được trên mọi nền tảng lưu kho, chỉ cần dán vào tệp mẫu yêu cầu gộp của kho nếu muốn mặc định cho cả nhóm.

Vì sao mã AI viết cần mô tả kỹ hơn

Khi đồng nghiệp tự viết mã, người rà có thể ngầm hiểu nhiều điều: người viết đã nghĩ qua ca biên, đã đọc mã xung quanh, đã chọn cách này vì có lý do. Với mã AI viết, những giả định đó không còn chắc. AI có thể chọn một cách làm chỉ vì nó phổ biến trên mạng, không vì nó hợp dự án; có thể thêm xử lý cho trường hợp không bao giờ xảy ra và bỏ qua trường hợp xảy ra hằng ngày.

Người rà không đọc được suy nghĩ của bạn, càng không đọc được phiên trò chuyện bạn đã có với AI. Thứ duy nhất họ có là diff và phần mô tả. Nếu mô tả chỉ có một dòng "thêm tính năng xuất hoá đơn", họ phải tự dựng lại toàn bộ bối cảnh, và trước một diff ba trăm dòng, hầu hết người rà sẽ đọc lướt.

Mô tả tốt không phải là thú tội rằng AI viết, cũng không phải để đẩy trách nhiệm. Nó là bản đồ: chỗ nào bạn đã kiểm kỹ và tin chắc, chỗ nào bạn chấp nhận theo AI mà chưa hiểu hết, chỗ nào bạn muốn người rà cho ý kiến. Với bản đồ đó, người rà dồn sức vào đúng chỗ.

Mẫu mô tả sáu phần

Không phải yêu cầu gộp nào cũng cần đủ sáu phần. Thay đổi nhỏ có thể gộp lại thành ba bốn câu; thay đổi lớn hoặc chạm vào phần nhạy cảm thì nên đủ.

PhầnViết gìĐộ dài gợi ý
Vì saoVấn đề hay yêu cầu, liên kết tới thẻ công việc bằng mã thẻHai ba câu
Đã làm gìThay đổi chính theo ý, không liệt kê tệpBa đến sáu gạch đầu dòng
AI tham gia thế nàoMức tham gia và phần nàoMột hai câu
Đã kiểm thế nàoKiểm thử mới, kiểm thử chạy lại, thử tay theo bước nàoBa đến năm gạch đầu dòng
Cần đọc kỹTệp hoặc hàm cụ thể, vì saoMột đến ba mục
Chưa chắc, chưa làmĐiểm còn băn khoăn, việc để lần sauTuỳ, có thể trống

Phần "cần đọc kỹ" và "chưa chắc" là hai phần người gửi hay bỏ nhất, vì viết ra cảm giác như tự nhận yếu. Thực tế, người rà tin mô tả có hai phần này hơn, vì nó cho thấy người gửi đã thật sự nghĩ. Một mô tả nói mọi thứ đều ổn với diff ba trăm dòng mới là thứ làm người rà nghi.

Viết phần "AI tham gia thế nào" sao cho có ích

Nói mức, không nói tên công cụ là đủ. Ví dụ "phần chuyển dữ liệu sang định dạng hoá đơn do tác tử viết theo phiếu việc, phần còn lại tự viết có gợi ý dòng". Tên công cụ cụ thể thường không giúp gì cho việc rà, trừ khi nhóm cần thống kê.

Nói AI làm phần nào, bạn làm phần nào. Người rà sẽ đọc kỹ hơn ở phần AI viết mà bạn chỉ sửa nhẹ, và đọc theo lối khác ở phần bạn tự viết. Không cần chính xác từng dòng, theo khối là đủ.

Nói kiểm thử do ai viết. Nếu AI viết cả mã lẫn kiểm thử, nói rõ, kèm bạn đã kiểm kiểm thử thế nào, ví dụ đã thử sửa sai mã để xem kiểm thử có đỏ không. Kiểm thử AI viết cho mã AI viết có nguy cơ cùng hiểu sai một chỗ.

Không dán nguyên phiên trò chuyện. Người rà không có thời gian đọc. Nếu có quyết định quan trọng hình thành trong phiên, chép kết luận và lý do ngắn gọn vào mô tả là đủ.

Ví dụ một mô tả hoàn chỉnh

Ví dụ giả định cho một yêu cầu gộp thêm chức năng xuất hoá đơn ra tệp bảng tính trong phần mềm bán hàng:

Vì sao: kế toán cần xuất hoá đơn theo tháng để đối chiếu, hiện đang chép tay; thẻ công việc mã HD-142. Đã làm gì: thêm nút xuất ở trang danh sách hoá đơn; thêm hàm tạo tệp bảng tính theo khoảng ngày; giới hạn tối đa một tháng mỗi lần xuất để tránh treo máy chủ. AI tham gia: hàm tạo tệp và kiểm thử của nó do tác tử viết theo phiếu việc, đã đọc lại và sửa phần định dạng ngày; phần giao diện tự viết. Đã kiểm: kiểm thử mới cho tháng có không hoá đơn, tháng có hoá đơn huỷ, hoá đơn có tên khách chứa dấu tiếng Việt; đã sửa sai thử một dòng trong hàm để chắc kiểm thử bắt được; thử tay xuất tháng trước trên dữ liệu thử nghiệm và mở bằng hai chương trình bảng tính.

Cần đọc kỹ: hàm lọc theo khoảng ngày, vì múi giờ máy chủ khác múi giờ người dùng; xin ý kiến cách xử lý hoá đơn tạo lúc gần nửa đêm. Chưa chắc: chưa kiểm hiệu năng với tháng có trên mười nghìn hoá đơn; đề xuất làm ở thẻ khác nếu cần.

Mô tả này khoảng hai trăm chữ, mất mười phút để viết. Người rà biết ngay phải mở hàm lọc ngày trước, biết kiểm thử đã được thử bắt lỗi, biết hiệu năng chưa kiểm nên sẽ không mặc định là ổn. Chú ý rằng phần kiểm thử nhắc tên khách có dấu tiếng Việt: đó là loại ca biên AI hay bỏ qua khi tạo tệp, vì phần lớn ví dụ nó từng thấy dùng chữ không dấu. Ghi ra cho người rà thấy bạn đã nghĩ tới bối cảnh riêng của sản phẩm.

Những câu nên tránh trong mô tả

Có những câu nghe vô hại nhưng làm người rà tin nhầm hoặc mất thời gian:

  • "Đã kiểm thử đầy đủ": đầy đủ là bao nhiêu, kiểm cái gì. Thay bằng danh sách cụ thể.
  • "AI viết, chắc ổn" hoặc ngược lại "AI viết nên chưa chắc lắm": cả hai đều đẩy việc đánh giá sang người rà. Bạn là người phải đánh giá trước.
  • "Sửa vài chỗ nhỏ" khi diff có thay đổi định dạng hàng loạt: người rà sẽ thấy ngay và mất lòng tin vào phần còn lại của mô tả.
  • "Theo đề xuất của AI" như lý do cho một lựa chọn thiết kế: người rà cần lý do kỹ thuật, không cần nguồn gốc ý tưởng.
  • Bản mô tả do AI tự sinh mà không đọc lại: thường liệt kê tệp, nói chung chung, và đôi khi nói những điều mã không làm.

Về mục cuối: nhờ AI viết nháp mô tả từ diff là cách tiết kiệm thời gian hợp lý, nhưng bạn phải sửa lại, nhất là thêm phần cần đọc kỹ và chưa chắc. AI không biết bạn đang băn khoăn điều gì. Và khi đưa diff vào công cụ AI để viết nháp, nhớ quy ước dữ liệu của nhóm: diff có khoá hay dữ liệu thật thì che trước.

Trả lời góp ý của người rà khi mã do AI viết

Phần mô tả chỉ là nửa đầu. Nửa sau là cách bạn trả lời góp ý. Cám dỗ lớn nhất là chép góp ý của người rà vào công cụ AI, nhận bản sửa và câu giải thích, rồi dán thẳng câu giải thích đó làm câu trả lời. Người rà nhận ra kiểu trả lời này rất nhanh: dài, lịch sự quá mức, và thường không trả lời đúng câu họ hỏi.

Cách tốt hơn: đọc góp ý, tự quyết bạn đồng ý hay không, rồi mới nhờ AI sửa nếu cần. Câu trả lời viết bằng lời của bạn, ngắn: đã sửa ở lần ghi nhận nào, hoặc không sửa vì lý do gì. Nếu góp ý chỉ ra chỗ bạn chưa hiểu, nói thẳng là chưa hiểu, đã đọc lại và giờ hiểu thế này. Điều đó tốt hơn nhiều so với một lời giải thích trôi chảy mà bạn không đứng sau được.

Mỗi lượt sửa theo góp ý nên là lần ghi nhận riêng, lời mô tả nhắc tới góp ý nào. Người rà chỉ cần xem phần thay đổi mới thay vì đọc lại cả yêu cầu gộp. Nếu bản sửa kéo theo thay đổi ở chỗ khác mà người rà chưa nhắc, ghi chú rõ để họ không bị bất ngờ ở vòng sau.

Đặt mẫu mặc định cho cả kho

Để cả nhóm viết đều mà không cần nhắc, đưa mẫu vào kho:

  1. Tạo tệp mẫu yêu cầu gộp theo cách nền tảng lưu kho của bạn quy định; hầu hết nền tảng đều hỗ trợ một tệp mẫu trong một thư mục ẩn của kho.
  2. Viết sáu đề mục như bảng trên, mỗi đề mục kèm một câu gợi ý ngắn viết dưới dạng chú thích để không hiện khi đăng.
  3. Thêm một hộp đánh dấu "đã tự chạy kiểm thử trên máy" và "đã đọc lại toàn bộ diff".
  4. Trong tệp hướng dẫn dự án cho AI, ghi rằng khi tác tử mở yêu cầu gộp thì phải điền theo mẫu này, kể cả phần chưa chắc.
  5. Sau một tháng, nhìn lại vài yêu cầu gộp, xem phần nào người ta luôn để trống và hỏi vì sao.

Mẫu không nên dài hơn một màn hình điện thoại. Người rà thường đọc thông báo trên điện thoại trước khi mở máy tính; một mô tả gọn, rõ đề mục giúp họ quyết định ngay là rà luôn hay để sau.

Câu hỏi thường gặp

Có bắt buộc phải ghi rằng AI đã tham gia không?

Tuỳ quy ước nhóm. Nhiều nhóm yêu cầu một dòng ngắn vì nó giúp người rà phân bổ sự chú ý. Nếu nhóm không yêu cầu, bạn vẫn nên ghi khi AI viết phần đáng kể, đặc biệt là kiểm thử.

Ghi AI tham gia có làm người rà khắt khe với mình hơn không?

Có thể lúc đầu. Nhưng nếu mô tả cho thấy bạn đã kiểm kỹ và chỉ rõ chỗ cần xem, người rà thường tin hơn. Vấn đề không nằm ở việc dùng AI mà ở việc gửi mã chưa hiểu hết.

Mô tả dài quá có làm người rà ngại đọc không?

Có, nếu dài vì liệt kê. Mô tả nên ngắn ở phần đã làm và cụ thể ở phần cần đọc kỹ. Với yêu cầu gộp nhỏ, ba bốn câu là đủ. Nếu mô tả buộc phải dài, có lẽ yêu cầu gộp nên tách ra.

Có nên dán câu lệnh đã dùng với AI vào mô tả?

Thường không cần. Chỉ dán khi câu lệnh chứa ràng buộc quan trọng mà người rà nên biết, hoặc khi nhóm đang sưu tầm câu lệnh hay. Khi dán, kiểm lại không có khoá hay dữ liệu thật trong đó.

Người rà nên làm gì nếu mô tả thiếu phần cần đọc kỹ?

Hỏi lại người gửi trước khi rà: chỗ nào bạn ít chắc nhất. Câu hỏi này mất một phút và thường chỉ ngay ra chỗ có vấn đề. Lặp lại vài lần, người gửi sẽ tự viết phần đó.

Cần tư vấn cụ thể cho trường hợp của bạn?

Chúng tôi sẽ liên hệ trong vòng 24 giờ.

Đăng ký tư vấn ngay

Bài viết liên quan

Bạn cần hỗ trợ thêm?

Để lại thông tin, chúng tôi sẽ liên hệ trong 24 giờ.

hoặc
Gọi ngay 0926 138 138