Năm Giai Đoạn Để Tự Động Hóa Tác Vụ AI Thực Sự Hiệu Quả (Phần 2)

06 tháng 4, 2026·5 phút đọc

Bài viết này đi sâu vào quy trình gồm năm giai đoạn chuyển đổi, biến một yêu cầu (ticket) sơ khai thành Pull Request (PR) đã được hợp nhất mà vẫn đảm bảo sự giám sát của con người. Thay vì để AI viết code ngay lập tức, phương pháp này nhấn mạnh vào việc chuyển giao có cấu trúc và các cổng kiểm soát để tối ưu hóa hiệu quả làm việc.

Năm Giai Đoạn Để Tự Động Hóa Tác Vụ AI Thực Sự Hiệu Quả (Phần 2)

Trong phần 1, chúng ta đã tìm hiểu về kiến trúc tổng thể: JIRA webhooks → GitHub → Cursor agent. Hôm nay, tôi sẽ đi sâu vào quy trình — năm giai đoạn giúp biến một ticket sơ khai thành một Pull Request (PR) đã được hợp nhất mà không làm mất đi sự giám sát của con người.

Đa số các đội nhóm thường thử cách tiếp cận "ticket → AI → code" và thất bại. Tác nhân AI thường hiểu sai yêu cầu, hoặc các lập trình viên mất niềm tin sau một PR tồi. Giải pháp không nằm ở việc viết prompt tốt hơn, mà là ở các bước chuyển giao có cấu trúc.

Năm Chuyển Đổi

Chúng tôi đã xây dựng quy trình này với hai giai đoạn của tác nhân AIba cổng kiểm soát của con người. Các tác nhân không bao giờ nhảy từ một ticket mơ hồ thẳng vào việc triển khai mã nguồn.

1. Chỉnh sửa (Con người)

Một thành viên trong nhóm (BA, PO hoặc dev) viết ticket ban đầu. Nó có thể khá sơ sài:

"Thêm xử lý lỗi cho trường hợp timeout của webhook thanh toán."

Trạng thái: Refinement (Chỉnh sửa). Bước tiếp theo: tác nhân AI sẽ định dạng lại.

2. Agent: Refine (Tác nhân AI: Chỉnh sửa)

Một tác nhân Cursor sẽ đọc ticket và tạo ra:

  • Tiêu chí chấp nhận (Acceptance criteria): Các điều kiện đạt/không đạt.
  • Định nghĩa Hoàn thành (Definition of Done): Danh sách kiểm tra: kiểm thử, tài liệu, triển khai.
  • Cách kiểm thử: Phác thảo thủ công hoặc tự động.
  • Kế hoạch triển khai: Phân tích từng file, giống như chế độ plan của Cursor.

Tất cả mọi thứ được lưu vào một trang Confluence được liên kết từ JIRA. Tác nhân làm rõ chúng ta đang xây dựng cái gì, nhưng chưa viết code.

Ticket chuyển sang: Plan: Review (Xem xét kế hoạch).

3. Plan: Review (Con người)

Nhóm xem xét kế hoạch trên Confluence. Nếu có gì sai lệch — cách tiếp cận sai, thiếu trường hợp ngoại lệ, tiêu chí không rõ ràng — chúng tôi sẽ nhận xét trong JIRA hoặc Confluence.

Sau đó, chúng tôi chuyển ticket quay lại Agent: Refine. Tác nhân sẽ đọc phản hồi, cập nhật kế hoạch. Vòng lặp này có thể chạy nhiều lần.

Khi được phê duyệt, ticket chuyển sang: Agent: Implement.

4. Agent: Implement (Tác nhân AI: Triển khai)

Tác nhân viết code dựa trên kế hoạch Confluence. Chạy kiểm thử (nếu được cấu hình), mở một pull request.

PR được liên kết với ticket JIRA và kế hoạch Confluence. Người xem xét sẽ thấy yêu cầu, cách tiếp cận và thay đổi code — tất cả đều được kết nối với nhau.

Nếu PR cần thay đổi, các dev sẽ nhận xét trên GitHub và chuyển ticket quay lại Agent: Implement. Tác nhân đọc phản hồi trên PR, cập nhật code, đẩy commit mới.

5. Review (Con người)

Quy trình xem xét code tiêu chuẩn. Nếu tốt, hãy hợp nhất (merge). Nếu không, gửi lại bước 4 với phản hồi.

Sau khi hợp nhất, ticket chuyển sang Test (Kiểm thử) (nằm ngoài quy trình này), sau đó là Done (Hoàn thành).

Tại Sao Phương Pháp Này Hiệu Quả

Tác nhân làm việc từ các kế hoạch đã được phê duyệt. Chúng không đoán mò. Khi sai, chúng sẽ lặp lại dựa trên phản hồi có cấu trúc.

Con người xem xét trước khi code được viết. Bước 3 (xem xét kế hoạch) bắt gặp các cách tiếp cận sai sớm. Một buổi xem xét 10 phút tiết kiệm hàng giờ sửa chữa sau này.

Vòng lặp phản hồi rẻ. Việc gửi ticket quay lại "Agent: Refine" hoặc "Agent: Implement" chỉ mất vài phút. Tác nhân chạy lại với ngữ cảnh đầy đủ. Không cần can thiệp của senior dev.

Niềm tin được xây dựng dần dần. Bắt đầu với các ticket nhỏ. Mở rộng sang các công việc phức tạp khi nhóm có thêm tự tin.

Bài Học Kinh Nghiệm

  • Rovo không đáp ứng được. Công cụ AI của Atlassian không thể sử dụng được cho quy trình của chúng tôi. Các tác nhân Cursor + GitHub đã mang lại sự kiểm soát cần thiết.
  • Xem xét kế hoạch là bắt buộc. Bỏ qua bước 3 luôn gây phản tác dụng. Đó là cổng rẻ nhất và mang lại lợi nhuận đầu tư (ROI) cao nhất.
  • Nhận xét trên PR tốt hơn nhận xét trên ticket cho phản hồi triển khai. Các dev đã viết nhận xét trên PR. Tác nhân đọc chúng một cách tự nhiên. Không cần lớp chuyển đổi.
  • Confluence là nơi lưu trữ kế hoạch then chốt. Các trường mô tả trong JIRA quá hạn chế. Confluence cung cấp lịch sử phiên bản, nhận xét nội tuyến và không gian cho một lộ trình triển khai thực sự.

Tiếp Theo Sẽ Là Gì

Trong phần 3, tôi sẽ đi sâu vào giai đoạn Agent: Implement — cách chúng tôi cấu hình tác nhân Cursor, cấu trúc kho lưu trữ (quy tắc, kỹ năng, tác nhân) và cách nó tạo ra các PR không cần viết lại quá nhiều.

Cho đến lúc này, nếu bạn đang tự động hóa công việc phát triển bằng AI: Đừng để tác nhân viết code cho đến khi bạn đã xem xét kế hoạch của chúng. Cổng kiểm soát duy nhất đó sẽ giúp bạn tiết kiệm nhiều thời gian gỡ lỗi hơn bất kỳ sự tối ưu hóa nào khác.

Bài viết được tổng hợp và biên soạn bằng AI từ các nguồn tin tức công nghệ. Nội dung mang tính tham khảo. Xem bài gốc ↗