My workflow with AI - Phần 2 - my-ai, “mục lục” giúp AI hiểu repo Rails
Ở Phần 1, mình đã chia công việc với AI thành hai lớp (command khi bắt đầu, skill khi đang code) và đi qua ba luồng: tính năng mới, lỗi production, và luồng hằng ngày. Trong cả ba luồng đều có hai bước quan trọng: đánh giá ảnh hưởng trước khi sửa và chỉ sửa đúng phạm vi. Nghe thì đơn giản, nhưng với repo Rails lớn thì agent rất dễ "mù": nó không biết class này dính đến callback nào, job nào, route nào. Bài này giới thiệu my-ai, công cụ mình dùng để giải quyết chuyện đó, cùng năm nguyên tắc khi để AI sửa code.
1. Vì sao cần một "mục lục" cho repo?
Thay vì tìm chữ như grep, my-ai cho agent biết code liên quan với nhau thế nào, cả trước khi sửa và sau khi sửa.
my-ai hoạt động thế nào?
Những rule mà index không tự phát hiện được thì ghi riêng vào knowledge.yml. Khi trả kết quả, my-ai luôn ghi rõ thông tin nào đến từ code, thông tin nào đến từ team.
2. Sửa code với my-ai: tra trước, kiểm sau
Dưới đây là ví dụ minh họa (đã rút gọn): agent cần sửa cách tạo api_token của model User.
Chặng 1: Tra trước
Bước 1: my-ai status kiểm tra index còn mới không. Không được bỏ qua bước này.
$ my-ai status
Indexed at: 2026-10-21 01:50
Stale: true # index cũ hơn HEAD hiện tại
Bước 2: my-ai index --full nếu index cũ hoặc thiếu. Index còn mới thì bỏ qua. Đừng dựa vào index không đầy đủ.
$ my-ai index --full
#index lại toàn bộ repo cho khớp HEAD
#xong thì status báo Stale: false
Bước 3: my-ai context xem class này liên quan đến những class nào, thay vì grep khắp repo. Kết quả kèm cả quy tắc team đã ghi trong knowledge.yml.
$ my-ai context User
[62.7] User user.rb
[26.0] user_spec.rb test
[25.5] generate_api_token before_validation
Project knowledge:
⚠ generate_api_token must use SecureRandom
Bước 4: my-ai inspect dùng cho model hoặc controller rủi ro cao, để xem quan hệ, callback, job, route và cảnh báo của team. Class ít rủi ro thì bỏ qua.
$ my-ai inspect User
├── callbacks
│ └── before_validation :generate_api_token
└── routes
└── GET /settings/profile → ProfilesController#show
tests: spec/models/user_spec.rb
Chặng 2: Chờ phép, rồi sửa
Bước 5: Dừng lại, chờ được cho phép rồi mới sửa. my-ai không sửa code thay bạn.
Agent: Kế hoạch: sửa generate_api_token, thêm test vào user_spec.rb. Chờ cho phép.
Developer: Tiến hành
Bước 6: Chỉ sửa đúng phạm vi đã thống nhất.
M app/models/user.rb
M spec/models/user_spec.rb
#các class khác trong context: không đụng
Chặng 3: Kiểm sau
Bước 7: my-ai impact xem những chỗ nào bị ảnh hưởng.
$ my-ai impact --git-diff
[high] generate_api_token via callback
[medium] Order, Session, Device… via belongs_to
Bước 8: my-ai test affected in ra lệnh test cần chạy. my-ai không tự chạy test; developer hoặc hook sẽ chạy.
$ my-ai test affected --git-diff
Suggested tests:
spec/models/user_spec.rb
Command:
bundle exec rspec spec/models/user_spec.rb
3. Năm nguyên tắc khi để AI sửa code
Công cụ chỉ là một nửa. Nửa còn lại là nguyên tắc mà agent phải tuân theo. Đây là năm điều nên đưa vào rule của repo để agent làm việc an toàn và dễ kiểm soát.
- Chưa được phép thì chưa sửa. AI có thể hỏi và lên kế hoạch, nhưng chỉ bắt tay sửa code khi được cho phép rõ ràng. Ở repo của mình, câu cho phép là "Tiến hành". Gọi một skill không có nghĩa là đã được phép sửa.
- Chưa rõ thì hỏi, đừng đoán. Khi yêu cầu còn mơ hồ, AI nên hỏi lại hoặc ghi thành câu hỏi thay vì tự đoán rồi viết code. Câu hỏi được ghi vào mục "Open Questions (PO)". Câu nào còn chặn thì chưa làm tiếp.
- Tra cứu trước khi sửa. Cần biết đoạn code liên quan đến những gì, thay vì tìm chữ khắp repo. Tra bằng my-ai theo thứ tự status → context → inspect.
- Làm theo quy ước sẵn có. Viết theo convention hiện tại, không tự nghĩ ra cách làm mới hay thêm thư viện mới. Ví dụ: chữ hiển thị trên màn hình luôn đi qua file i18n, ngôn ngữ mặc định là ja.
- Chỉ sửa đúng phạm vi. Không tiện tay refactor, đổi tên hay format lại chỗ không liên quan. Kết quả my-ai context có hơn chục class, nhưng chỉ sửa 2 file trong kế hoạch.
Tóm lại và phần tiếp theo
Với my-ai, agent không còn phải đoán: nó tra trước để biết code liên quan đến đâu, chờ phép rồi mới sửa, và kiểm sau để biết cần chạy test nào. Năm nguyên tắc ở trên giúp giữ agent trong khuôn khổ.
Nhưng nguyên tắc chỉ có tác dụng khi được viết ra và được thực thi. Viết rule thế nào để agent đọc đúng lúc? Skill khác rule ở đâu? Và nếu developer quên gõ command, hay agent quên chạy test, thì ai nhắc?
Phần 3, phần cuối của series, sẽ trả lời những câu hỏi đó: cách viết rule và skill, sự khác nhau giữa command và hook, và một checklist để bạn mang cách làm này sang repo của mình.
Tác giả: : Le Thanh Viet ー SHIP Vietnam
All Rights Reserved
