Giao việc cho tác tử AI lập trình khác hẳn hỏi một chatbot: bạn không chờ từng câu trả lời mà để nó tự đọc kho mã, tự sửa nhiều tệp, tự chạy lệnh trong mười mấy phút. Vì vậy thứ quyết định kết quả là tờ phiếu việc viết trước khi bấm chạy. Một phiếu tốt trả lời đủ sáu câu: làm gì, vì sao, được đụng vào đâu, thế nào là xong, kiểm bằng lệnh gì, và gặp tình huống nào thì phải dừng lại hỏi.
Bài này dành cho lập trình viên và trưởng nhóm đã cài một tác tử (chạy trong trình soạn thảo hay dòng lệnh đều được) và thấy nó lúc làm rất gọn, lúc lại sửa lan ra cả chục tệp không liên quan. Phần lớn chênh lệch đó đến từ cách giao việc, không phải từ mô hình. Cuối bài có khung phiếu việc để bạn chép vào ghi chú của nhóm.
Vì sao câu lệnh một dòng hợp với chatbot nhưng hỏng với tác tử
Khi hỏi chatbot, bạn đứng giữa mỗi vòng: nó trả lời, bạn đọc, bạn hỏi tiếp. Câu hỏi thiếu ý thì vòng sau bù. Tác tử thì ngược lại, nó chạy một chuỗi dài hành động mà không chờ bạn: mở tệp, tìm kiếm, sửa, chạy kiểm thử, sửa tiếp. Mỗi chỗ mơ hồ trong yêu cầu trở thành một lần nó tự đoán, và các lần đoán đó cộng dồn. Đến cuối phiên, bạn nhận về một bản sửa rất tự tin nhưng đi theo hướng bạn không định.
Ví dụ giả định: bạn gõ "sửa lỗi đăng nhập chậm". Tác tử có thể hiểu là thêm bộ nhớ đệm, đổi thuật toán băm mật khẩu cho nhẹ hơn, hay viết lại câu truy vấn. Cách thứ hai làm giảm an toàn, và nó không biết điều đó quan trọng với bạn. Nếu bạn ghi thêm một dòng "không đổi cách băm mật khẩu, chỉ xem phần truy vấn và bộ nhớ đệm", cả một nhánh rủi ro biến mất.
Thêm một khác biệt: tác tử có giới hạn ngữ cảnh. Phiên càng dài, những gì bạn dặn ở đầu càng dễ bị lấn bởi kết quả lệnh và nội dung tệp. Phiếu việc ngắn, rõ, có tiêu chí kiểm được bằng lệnh, giúp nó tự quay lại đối chiếu thay vì dựa vào trí nhớ của phiên. Đó cũng là lý do nên chia việc lớn thành nhiều phiếu nhỏ chứ không nhồi vào một phiếu dài.
Sáu mục của một phiếu việc
Không cần biểu mẫu cầu kỳ. Một đoạn văn bản thuần với sáu đề mục là đủ; bạn dán nó làm tin nhắn đầu tiên của phiên, hoặc lưu thành tệp trong kho để tác tử đọc.
| Mục | Trả lời câu hỏi | Ví dụ giả định |
|---|---|---|
| Mục tiêu | Xong việc thì người dùng hoặc hệ thống thấy gì khác | Trang danh sách đơn hàng tải dưới hai giây với 5.000 đơn |
| Bối cảnh | Vì sao cần, đã thử gì, tệp nào là điểm bắt đầu | Chậm do truy vấn trong vòng lặp; bắt đầu từ tệp xử lý trang đơn hàng |
| Phạm vi | Được sửa ở đâu, không được đụng vào đâu | Chỉ thư mục đơn hàng và kiểm thử của nó; không đổi lược đồ cơ sở dữ liệu |
| Tiêu chí xong | Điều kiện kiểm được, không cảm tính | Mọi kiểm thử hiện có qua; thêm một kiểm thử cho số câu truy vấn |
| Lệnh kiểm | Lệnh cụ thể để chạy trước khi báo xong | Lệnh chạy bộ kiểm thử của dự án và lệnh kiểm định dạng mã |
| Điểm dừng | Khi nào phải dừng lại hỏi thay vì tự quyết | Cần thêm thư viện, cần sửa ngoài phạm vi, kiểm thử cũ phải đổi kỳ vọng |
Mục dễ bị bỏ nhất là điểm dừng, và đó lại là mục cứu bạn nhiều nhất. Tác tử được thiết kế để hoàn thành việc; nếu không ai bảo khi nào nên dừng, nó sẽ chọn cách hoàn thành, kể cả bằng việc sửa luôn kiểm thử cho khớp với mã sai.
Viết phạm vi và tiêu chí xong sao cho tác tử tự kiểm được
Phạm vi nói bằng đường dẫn, không bằng tính từ. Viết "chỉ sửa trong thư mục xử lý thanh toán và thư mục kiểm thử tương ứng" thay vì "sửa gọn thôi". Tác tử đối chiếu được đường dẫn; nó không đối chiếu được chữ "gọn".
Nói rõ thứ không được đổi. Lược đồ cơ sở dữ liệu, tệp cấu hình triển khai, giao diện hàm công khai mà nhóm khác đang gọi, tệp khoá phiên bản thư viện. Một dòng "không đụng" rẻ hơn rất nhiều so với một buổi chiều gỡ lại.
Tiêu chí xong phải chạy được bằng lệnh. "Chạy đúng" là cảm tính. "Lệnh chạy kiểm thử trả về không lỗi, và kiểm thử mới cho trường hợp giỏ hàng rỗng tồn tại và qua" là thứ tác tử tự xác minh được trước khi báo cáo.
Ghi cả tiêu chí về hình thức thay đổi. Ví dụ: không quá một tệp mới, không đổi tên hàm sẵn có, mỗi thay đổi một lần ghi nhận (commit) riêng có lời mô tả. Những ràng buộc này giúp bạn đọc lại nhanh hơn ở bước cuối.
Đừng đưa lời giải nếu bạn chưa chắc. Nếu bạn chỉ đoán nguyên nhân, hãy ghi là đoán. "Có thể do truy vấn trong vòng lặp, cần xác nhận trước khi sửa" để tác tử đo trước, thay vì lao vào sửa theo giả thuyết của bạn rồi báo là xong.
Điểm dừng: những tình huống tác tử phải hỏi thay vì tự quyết
Danh sách dưới đây nên nằm sẵn trong tệp hướng dẫn dự án để khỏi chép lại mỗi lần, nhưng với việc nhạy cảm thì nhắc lại trong phiếu. Câu lệnh mẫu: "Nếu gặp một trong các tình huống sau, dừng lại, mô tả tình huống và đề xuất hai phương án, chưa sửa gì thêm."
- Cần cài thêm thư viện hoặc nâng phiên bản thư viện đang có.
- Cần sửa tệp nằm ngoài phạm vi đã ghi, dù chỉ một dòng.
- Một kiểm thử cũ thất bại và cách sửa là đổi kỳ vọng của kiểm thử đó, chứ không phải sửa mã.
- Cần chạy lệnh có tác dụng ra ngoài máy: gọi dịch vụ thật, gửi thư, ghi vào cơ sở dữ liệu dùng chung, đẩy mã lên kho từ xa.
- Cần đổi lược đồ dữ liệu hoặc viết tệp chuyển đổi dữ liệu (migration).
- Đã thử ba hướng mà kiểm thử vẫn đỏ: dừng và báo lại những gì đã thử, không thử hướng thứ tư.
- Phát hiện khoá bí mật, mật khẩu hoặc dữ liệu khách hàng thật trong mã hay trong tệp nhật ký.
Mục cuối cùng quan trọng hơn vẻ ngoài của nó. Tác tử đọc được mọi thứ trong thư mục làm việc; nếu nó tình cờ gặp khoá bí mật, việc đúng là báo bạn để xoay khoá, chứ không phải lặng lẽ dùng khoá đó cho lệnh kiểm thử. Trước khi giao việc, bạn cũng nên kiểm thư mục có tệp chứa bí mật nào không cần thiết thì dời ra.
Nhận bàn giao: bốn bước trước khi coi việc là xong
Tác tử báo "đã hoàn thành" chỉ là lời khai của nó. Bước bàn giao là lúc bạn biến lời khai đó thành sự thật đã kiểm.
- Đọc bản tóm tắt tác tử viết: nó đã đổi gì, vì sao, còn gì chưa làm. Nếu tóm tắt không nhắc đến tiêu chí xong, yêu cầu nó đối chiếu lại từng tiêu chí.
- Xem danh sách tệp thay đổi bằng git status và git diff --stat. Tệp nào nằm ngoài phạm vi phiếu là cờ đỏ, đọc kỹ trước tiên.
- Tự chạy lại lệnh kiểm trên máy mình, không tin dòng "kiểm thử đã qua" trong báo cáo. Có những lần tác tử chạy một tập kiểm thử con, hoặc chạy trước lần sửa cuối.
- Đọc diff từng tệp như đọc mã của đồng nghiệp: đặt tên, xử lý lỗi, chỗ nào thêm mà không cần. Phần đọc rà chi tiết có bài riêng ở danh mục kiểm thử và rà soát của trang.
Nếu một trong bốn bước thấy lệch, đừng sửa tay rồi bỏ qua. Ghi lại lệch ở đâu, thêm một dòng vào phiếu mẫu hoặc tệp hướng dẫn dự án. Sau vài tuần, phiếu của nhóm sẽ chứa đúng những bài học riêng của kho mã mình.
Khung phiếu việc mẫu để chép dùng ngay
Dưới đây là một phiếu việc hoàn chỉnh cho ví dụ giả định ở trên. Bạn thay nội dung, giữ nguyên các đề mục:
Mục tiêu: trang danh sách đơn hàng trong khu quản trị tải dưới hai giây khi có khoảng năm nghìn đơn. Bối cảnh: người dùng báo chậm từ khi số đơn tăng; nghi do mỗi đơn lại truy vấn riêng thông tin khách hàng, chưa xác nhận. Điểm bắt đầu là tệp điều khiển trang đơn hàng. Phạm vi: chỉ sửa trong thư mục đơn hàng và thư mục kiểm thử của nó; không đổi lược đồ, không thêm thư viện. Tiêu chí xong: mọi kiểm thử hiện có qua; thêm một kiểm thử khẳng định số câu truy vấn không tăng theo số đơn; giao diện trang giữ nguyên. Lệnh kiểm: chạy bộ kiểm thử của dự án và trình kiểm định dạng mã. Điểm dừng: theo danh sách chuẩn của nhóm; ngoài ra dừng hỏi nếu cần thêm chỉ mục cơ sở dữ liệu.
Cuối phiếu thêm một câu yêu cầu cách báo cáo: "Khi xong, liệt kê tệp đã sửa, lý do từng thay đổi, kết quả lệnh kiểm, và những gì bạn chưa chắc." Câu cuối đó buộc tác tử nói ra chỗ yếu, thứ nó thường không tự nói. Nếu phiếu có dán đoạn nhật ký lỗi hay dữ liệu mẫu, nhớ che tên khách, số điện thoại, địa chỉ và mọi khoá truy cập trước khi đưa vào.
Những lỗi giao việc hay gặp ở nhóm mới dùng tác tử
Giao cả tính năng trong một phiếu. Một tính năng gồm giao diện, xử lý, dữ liệu và kiểm thử nên tách thành ba bốn phiếu nối nhau. Mỗi phiếu xong thì bạn duyệt rồi mới mở phiếu sau, nhờ vậy lỗi hướng đi bị chặn sớm.
Để tác tử tự đặt tiêu chí xong. Khi không có tiêu chí, tác tử dừng lúc mã chạy được. Chạy được và đúng yêu cầu là hai chuyện khác nhau.
Giao việc mà chính bạn chưa hiểu. Nếu bạn không tự tóm tắt được vấn đề trong ba câu, phiên đầu nên là phiên tìm hiểu: yêu cầu tác tử đọc mã và giải thích, chưa sửa gì. Phiếu sửa viết sau.
Không đọc tóm tắt, chỉ xem kiểm thử xanh. Màu xanh nói rằng các kiểm thử đang có không bắt được lỗi, không nói rằng không có lỗi. Đọc tóm tắt để biết tác tử có tự sửa kiểm thử hay không.
Câu hỏi thường gặp
Phiếu việc nên dài bao nhiêu là vừa?
Thường từ mười đến hai mươi dòng. Ngắn hơn thì thiếu phạm vi hoặc tiêu chí xong; dài hơn nhiều thì có lẽ bạn đang nhồi nhiều việc vào một phiếu, nên tách ra. Thông tin dùng chung cho mọi phiếu như quy ước đặt tên, lệnh kiểm chuẩn thì đưa vào tệp hướng dẫn dự án.
Có nên viết phiếu bằng tiếng Anh cho tác tử hiểu tốt hơn?
Các mô hình phổ biến hiện nay hiểu yêu cầu tiếng Việt khá tốt. Điều quan trọng hơn là giữ nguyên tên tệp, tên hàm, thông báo lỗi đúng như trong mã. Nhóm đọc phiếu bằng tiếng Việt nhanh hơn thì cứ viết tiếng Việt, rồi xem kết quả trên vài việc thật để quyết.
Tác tử cứ sửa ra ngoài phạm vi dù phiếu đã ghi rõ thì làm sao?
Kiểm xem công cụ có chế độ hỏi trước khi sửa tệp hay giới hạn thư mục làm việc không, vì đó là hàng rào chắc hơn lời dặn. Ngoài ra, nhắc lại phạm vi ngay trong điểm dừng và yêu cầu tác tử liệt kê tệp định sửa trước khi bắt đầu.
Có cần viết phiếu cho việc nhỏ như đổi tên một biến?
Không. Việc nhỏ, phạm vi tự hiển nhiên thì một câu là đủ. Phiếu sáu mục dành cho việc chạm vào nhiều tệp, có rủi ro làm hỏng thứ khác, hoặc sẽ chạy lâu mà bạn không ngồi canh từng bước.
Lưu phiếu việc ở đâu để cả nhóm dùng lại?
Nhiều nhóm lưu ngay trong phần mô tả của thẻ công việc trên công cụ quản lý việc, rồi dán vào phiên tác tử. Như vậy người rà mã sau này đọc được tác tử đã được giao gì, và so được kết quả với yêu cầu gốc.
Tác tử báo đã chạy kiểm thử nhưng thực ra chưa chạy thì nhận ra thế nào?
Yêu cầu báo cáo kèm phần đầu ra thật của lệnh kiểm, rồi bạn tự chạy lại trên máy mình. Nếu kết quả hai bên khác nhau, xem tác tử có chạy trước lần sửa cuối hay chỉ chạy một phần bộ kiểm thử không.