Mô hình AI cố vấn: để AI rẻ cầm lái, Claude chỉ góp ý

Mô hình AI cố vấn là cách tôi đang chuyển sang để hết cảnh cháy hạn mức Claude: một AI giá rẻ cầm lái, tự đọc code, tự sửa, tự chạy test; Claude chỉ làm cố vấn, được gọi khoảng 2 lần mỗi việc với một gói ngữ cảnh nhỏ. Cách cũ để Claude điều phối hàng trăm lượt, mỗi lượt khoảng 250 nghìn token. Cách mới chỉ còn vài lần gọi, mỗi lần vài chục nghìn.

Ở bài trước, tôi đã đo và thấy phần đắt nhất là phiên điều phối. Bài này nói cách đảo vai để bớt phần đó.

Ý tưởng này từ đâu ra?

Một người bạn làm dev hỏi tôi: dạo này nhiều người bỏ kiểu «spawn sub-agent», vì tốn và vì ngữ cảnh giữa các agent không liên kết được với nhau. Bạn ấy gợi ý tôi xem các harness kiểu oh-my-pi, nơi có một vai rất đáng chú ý: advisor, tức cố vấn.

Ý chính của các dự án này:

• Model mặc định, thường rẻ hoặc nhanh, làm việc hằng ngày và giữ toàn bộ ngữ cảnh.
• Một model mạnh hơn đứng ngoài, thỉnh thoảng mới được gọi để bắt lỗi thiết kế, ràng buộc bị bỏ sót, hướng đi phí công.
• Người lái luôn là người lái, cố vấn luôn chỉ góp ý.

Tôi mới đọc mô tả các dự án này qua trang giới thiệu, chưa dùng chính chúng. Thứ tôi lấy về là cách chia vai, áp vào bộ công cụ sẵn có.

Hai mô hình khác nhau thế nào?

	Nhạc trưởng – thợ (cũ)	AI cố vấn (mới)
Ai giữ ngữ cảnh dài	Claude Opus, tài khoản chính	AI rẻ cầm lái
Claude được gọi	hàng trăm lượt, mỗi lượt khoảng 250 nghìn token	khoảng 2 lần mỗi việc, mỗi lần vài chục nghìn token
Thợ hiểu việc qua	một file đề bài tóm tắt, dễ mất chi tiết	chính hội thoại với người dùng, đủ đầu đuôi
Chỗ yếu	tốn, ngữ cảnh đứt giữa nhạc trưởng và thợ	chất lượng phụ thuộc AI cầm lái, nên cần cổng kiểm

Điểm hay thứ hai ít người để ý: ở mô hình cũ, đề bài là bản tóm tắt nên thợ không biết những gì đã bàn. Ở mô hình mới, AI cầm lái nói chuyện trực tiếp với tôi nên hiểu đủ đầu đuôi. Đỡ tốn và đỡ đứt ngữ cảnh cùng lúc.

Cố vấn được gọi vào những mốc nào?

Tôi chỉ đặt hai mốc:

1. Trước khi code: duyệt kế hoạch. AI cầm lái đọc code, viết kế hoạch ngắn (sửa file nào, cách làm, ca biên), rồi gửi cho Claude. Claude trả về nhận xét tối đa 20 dòng và kết luận ĐẠT hoặc CẦN SỬA. Sai thiết kế bị chặn ở đây là rẻ nhất.
2. Sau khi code: soát diff file nhạy cảm. Khi typecheck và test đã xanh, chỉ những file về tiền, phân quyền, chứng từ, parser, schema mới gửi patch cho Claude soát. Giao diện và chữ thì không cần.

Việc vặt như sửa câu chữ hay chỉnh một nút thì bỏ qua cố vấn hoàn toàn.

Gọi Claude làm cố vấn bằng cách nào?

Claude Code có chế độ không tương tác: claude -p nhận một yêu cầu, trả lời một lần rồi thoát, không mang theo lịch sử phiên nào. Tôi gói nó vào một script nhỏ:

• Đầu vào: đề bài cộng kế hoạch, hoặc đề bài cộng file patch.
• Tắt công cụ để Claude chỉ đọc và nhận xét, không tự đi dò code.
• Hướng dẫn hệ thống ngắn: đóng vai cố vấn khó tính, chỉ ra lỗi cụ thể, không viết lại code.
• Đầu ra: nhận xét tối đa 20 dòng, ghi vào file để AI cầm lái đọc.

Lần gọi này vẫn trừ vào hạn mức tài khoản chính, nhưng chỉ cỡ vài chục nghìn token, so với hàng chục triệu của một phiên điều phối dài.

Gõ yêu cầu ở đâu thì nơi đó thành người điều phối. Muốn Claude chính rẻ thì đừng gõ việc vào Claude chính.

AI nào nên cầm lái?

Ứng viên tốt là AI chạy được trong một harness nạp đủ quy tắc của repo. Tôi ưu tiên chính Claude Code nhưng thay bộ não bằng model rẻ có cổng tương thích Anthropic, như DeepSeek hay GLM. Như vậy AI cầm lái đọc đủ CLAUDE.md, quy tắc theo mảng và skill như phiên Claude bình thường. Chi tiết tôi viết ở bài harness là gì. Các lựa chọn khác như Codex CLI hay OpenCode cũng làm được, chỉ cần cấu hình cho chúng đọc quy tắc của repo.

Những gì mô hình này chưa giải được?

• AI cầm lái yếu thì cố vấn không cứu hết. Cố vấn chỉ chặn được lỗi nằm trong kế hoạch hoặc trong patch nó được xem.
• Giao diện vẫn phải kiểm bằng mắt. Typecheck và test xanh không có nghĩa là màn hình hiển thị đúng.
• Việc thiết kế lớn, cắt ngang nhiều module tôi vẫn làm trực tiếp với Claude. Đó là chỗ đáng tiền nhất của model mạnh.

Tóm tắt và bước tiếp theo

• Mô hình AI cố vấn đảo vai: AI rẻ cầm lái và giữ ngữ cảnh, Claude chỉ góp ý ở 2 mốc.
• Mốc 1 là duyệt kế hoạch trước khi code, mốc 2 là soát diff file nhạy cảm sau khi test xanh.
• Gọi cố vấn bằng claude -p, gói ngữ cảnh nhỏ, đầu ra ngắn có kết luận rõ.

Bước tiếp theo: chọn một việc vừa phải mà bạn định giao tuần này, làm thử theo hai mốc trên, rồi so hạn mức tuần với tuần trước. Đó là cách đánh giá nhanh nhất mô hình có hợp với cách làm của bạn không.