My workflow with AI - Phần 1 - Command hay skill? Ba luồng làm việc với AI agent

Khi làm việc với AI agent trên một repo Rails lớn, mình nhận ra vấn đề thường không nằm ở chỗ AI "giỏi" hay "dở". Vấn đề là AI có được làm việc theo đúng cách của team hay không.

Series này tổng hợp lại buổi chia sẻ nội bộ của mình về cách tổ chức rule, command, skill, hook và công cụ my-ai, để agent làm việc an toàn và dễ kiểm soát hơn. Ở phần đầu tiên, mình sẽ nói về "bộ khung": khi nào gọi command, khi nào dùng skill, và ba luồng làm việc tương ứng với ba loại việc hay gặp nhất.

Ý tưởng chính của cả series: mỗi repo tự viết rule, command và skill riêng, và AI sẽ làm việc theo đúng những gì repo đã viết.

1. Hai thời điểm, hai công cụ khác nhau

Mình chia công việc với AI thành hai lớp: Khi bắt đầu một việc → gọi đúng command. Khi đang code (phạm vi đã rõ) → dùng đúng skill của repo.

• Có việc mới thì đừng vội mở chat và nhờ AI sửa ngay.
• Xác định trước đây là tính năng mới, lỗi hay góp ý review. Mỗi loại đi một luồng riêng, đừng trộn lẫn.
• Chỉ khi phạm vi đã rõ mới dùng skill của repo. Từ sơ đồ trên, ta có ba lối vào. Phần còn lại của bài sẽ đi qua từng lối một.

2. Tính năng mới: yêu cầu còn mơ hồ thì phân loại trước

Việc nhỏ có thể bỏ qua bước thiết kế. Nhưng spec chưa ổn thì chưa viết code.

Khi nào spec được coi là đạt? Phải đủ cả ba điều kiện:

1. Điểm tổng ≥ 7/10.
2. Không còn lỗi CRITICAL và HIGH: thiếu mục đích, persona, user story, tiêu chí thành công, hoặc chưa rõ edge case, quy tắc phân quyền.
3. Không còn câu hỏi PO nào chặn việc triển khai.

Điểm do người review chấm tổng thể theo checklist, không có công thức cộng điểm.

Khi nào cần thiết kế? Khi có ít nhất một dấu hiệu sau:

• Việc vừa hoặc lớn.
• Sửa từ 2 tầng code trở lên (controller, service, model, job, view, client gọi API ngoài…).
• Có pattern mới.
• Có quyết định kỹ thuật chưa rõ (sync hay async, jsonb hay bảng mới).

3. Lỗi production: tiếp nhận trước, sửa sau

Với lỗi thì ngược lại: không cần spec, nhưng cần hiểu lỗi trước khi động vào code. Đọc lại các lỗi team đã ghi nhận trước đó. Postmortem chỉ dành cho các incident nghiêm trọng, và được viết sau khi đã sửa xong.

• Đọc tài liệu về các lỗi đã biết để tránh mất công với lỗi đã có cách xử lý.
• Tiếp nhận lỗi, đừng đi theo quy trình viết spec của tính năng mới.
• Đã rõ file cần sửa chưa? Ví dụ: stack trace đã chỉ rõ class bị lỗi. Nếu chưa rõ thì đánh giá ảnh hưởng trước.
• Viết test rồi sửa, dù đi nhánh nào. Test tái hiện lỗi trước, rồi mới sửa cho test pass.
• Postmortem chỉ dành cho sự cố nghiêm trọng, viết sau khi bản sửa đã ship.

Postmortem là bản tổng kết sau sự cố: chuyện gì đã xảy ra, vì sao, ảnh hưởng thế nào, và cần làm gì để không lặp lại. Mục đích là rút kinh nghiệm, không phải đổ lỗi.

4. Luồng review và merge: code xong, test local pass rồi, làm gì tiếp?

Dù đi từ tính năng mới hay từ sửa lỗi, cuối cùng cả hai đều đổ về cùng một luồng.

• Test local pass chưa có nghĩa là xong. Đây là test chạy trên máy, chưa phải CI; CI được kiểm ở bước merge.
• Tự đọc lại phần thay đổi trước khi nhờ người khác review.
• Có góp ý thì xử lý lần lượt từng góp ý: có thể sửa, phản hồi, hỏi lại, hoặc tạo ticket để làm sau. Developer quyết định sửa hay chỉ phản hồi. Nếu không đồng ý thì ghi rõ lý do.
• Sửa xong thì tự review lại. Vòng này lặp cho đến khi không còn góp ý.
• Khi không còn góp ý mới merge, và vẫn cần CI pass cùng người duyệt approve.
• Nếu hành vi sản phẩm thay đổi thì cập nhật tài liệu trong repo. Refactor, đổi tên hay sửa typo thì không cần.

Tóm lại và phần tiếp theo

Ở phần này, chúng ta đã có bộ khung: gọi command khi bắt đầu việc, dùng skill khi đang code, cùng ba luồng cho tính năng mới, lỗi production và review trước khi merge. Nhưng có một câu hỏi còn bỏ ngỏ. Trong cả ba luồng đều có bước "đánh giá ảnh hưởng" và "sửa đúng phạm vi". Với một repo Rails đã phát triển nhiều năm, đầy callback và job, làm sao agent biết đoạn code mình sắp sửa liên quan đến những gì? Grep thì không đủ. Phần 2 sẽ giới thiệu my-ai, công cụ mình dùng như một "mục lục" của repo để agent tra cứu trước khi sửa và kiểm tra sau khi sửa. Hẹn gặp mọi người ở phần sau nhé!

Tác giả: : Le Thanh Viet ー SHIP Vietnam