Hiểu đúng về AI Skills: Đây là đặc tả bộ nạp, không phải Prompt – Tại sao kiến trúc lại quyết định tất cả

Khi lần đầu tiên làm quen với định dạng SKILL.md của Anthropic, nhiều lập trình viên – bao gồm cả tôi – thường mắc một sai lầm tai hại: coi đó đơn giản là một đoạn prompt (câu lệnh) dài.

Tôi đã từng viết một file SKILL.md khổng lồ lên tới 1.200 dòng, chứa đựng mọi thứ từ quy trình làm việc, sơ đồ mã nguồn, cho đến các ví dụ và lưu ý. Nó hoạt động, nhưng cái giá phải trả là tốn tới 20% cửa sổ ngữ cảnh (context window) chỉ để tải các chỉ dẫn này, trước khi AI thực hiện bất kỳ công việc gì.

Sau khi tái cấu trúc, tôi thu gọn file chính xuống còn 180 dòng và tham chiếu đến các file phụ. Kết quả? Chi phí ngữ cảnh giảm xuống còn chỉ 7%. Nội dung hướng dẫn thì không đổi, chỉ có kiến trúc thay đổi.

Điều này dẫn đến một sự thật cốt lõi: AI Skills là các chương trình nhỏ với đặc tả bộ nạp (loader spec), không phải là những đoạn văn bản tĩnh.

Mô hình kiến trúc của AI Skills

Skills hoạt động như một chương trình

Một Skill thực chất có ba giai đoạn thực thi tương ứng với ba loại nội dung được tải tại các thời điểm khác nhau. Nguyên tắc này được Anthropic gọi là "tiết lộ dần dần" (progressive disclosure).

Hãy tưởng tượng một căn bếp trong giờ cao điểm:

• Bảng thông báo (Level 1 - Metadata): Chứa tên món ăn và mô tả ngắn gọn. Đầu bếp nhìn vào nó liên tục để quyết định món nào cần nấu. Đây là phần YAML frontmatter trong SKILL.md, luôn được tải trong mọi lượt hội thoại để AI quyết định xem Skill đó có liên quan hay không.
• Sổ tay công thức (Level 2 - SKILL.md Body): Chứa hướng dẫn chế biến chi tiết. Nó chỉ được lấy xuống khi khách đã gọi món. Đây là phần thân của file SKILL.md, chỉ được tải khi AI xác định Skill cần được kích hoạt.
• Kệ tài liệu và máy móc (Level 3 - References & Scripts): Các tài liệu tham khảo hoặc đoạn mã thực thi. Chúng chỉ được đọc hoặc chạy khi công thức yêu cầu cụ thể.

Nếu bạn nhầm lẫn giữa các cấp độ này, bạn sẽ gặp phải những "bệnh" phần mềm điển hình: trôi dạt môi trường, lỗi phiên bản và những thất bại âm thầm.

Các sai lầm điển hình (Antipatterns)

Dưới đây là những lỗi phổ biến mà tôi đã gặp phải khi xây dựng Skills, và cách khắc phục chúng.

1. Skill khổng lồ (Monolithic Skill)

Đây là câu chuyện về việc giảm từ 20% xuống 7% chi phí ngữ cảnh mà tôi đã đề cập. Việc nhồi nhét mọi thứ vào một file SKILL.md duy nhất khiến hệ thống phải tải toàn bộ thông tin thừa thãi mỗi lần Skill được gọi.

Giải pháp: Chia nhỏ. Hãy để SKILL.md đóng vai trò là "xương sống", tham chiếu đến các file tài liệu chi tiết khác. Điều này giúp giảm thiểu chi phí tính toán và tăng tốc độ phản hồi.

2. Mã hóa cứng đường dẫn (Hardcoded Paths)

Tôi từng chia sẻ một Skill cho đồng nghiệp và nó thất bại vì tôi đã chỉ dẫn: "Di chuyển đến modules/web và chạy build". Trong kho của tôi thì đúng, nhưng của đồng nghiệp thì đường dẫn là packages/frontend/web.

Giải pháp: Đừng ra lệnh tuyệt đối. Hãy hướng dẫn AI "tìm kiếm" cấu trúc dự án, xác định module bằng package.json hoặc đọc cấu trúc workspace trước khi hành động. Hãy viết các chỉ dẫn trừu tượng để tăng tính di động.

3. Thiếu phần "Gotchas" (Các bẫy cần tránh)

Môi trường của bạn thường không "chuẩn" như mặc định của AI. Ví dụ, trong monorepo dùng Turborepo của tôi, lệnh build phải chạy từ thư mục gốc repo, nếu không sẽ bị lỗi cache. AI thường có xu hướng chạy build từ bên trong thư mục module – điều đúng với 90% dự án khác, nhưng sai với dự án của tôi.

Giải pháp: Hãy tạo một mục riêng gọi là Gotchas. Đây là nơi bạn ghi lại những ngoại lệ, những quy tắc ngầm của môi trường riêng biệt mà AI không thể biết từ dữ liệu huấn luyện chung.

4. Không đánh giá (Evals) khi nâng cấp mô hình

Tôi từng tinh chỉnh một Skill viết văn trên mô hình Sonnet 4.6 và nó hoạt động tuyệt vời. Nhưng khi nâng cấp lên Opus (mô hình mạnh hơn), kết quả lại tệ hơn. Opus hiểu theo nghĩa đen các chỉ dẫn "viết câu ngắn", khiến văn bản trở nên gãy gọn, thiếu nhịp điệu.

Một Skill được tinh chỉnh trên một mô hình sẽ được hiệu chuẩn theo đặc tính tuân thủ của mô hình đó. Mô hình mạnh hơn không phải lúc nào cũng tốt hơn, đôi khi chúng "diễn giải" chỉ dẫn của bạn thay vì làm theo.

Giải pháp: Hãy xây dựng một bộ "Golden Set" – các bài kiểm thử mẫu. Chạy lại bộ kiểm thử này mỗi khi thay đổi mô hình hoặc chỉnh sửa Skill để đảm bảo kết quả không bị trôi dạt.

Quy trình xử lý và tải dữ liệu

Kết luận

Bốn điều chính cần ghi nhớ khi làm việc với AI Skills:

1. Skills là đặc tả bộ nạp: Bạn đang mô tả cái gì cần có trong ngữ cảnh, khi nào và tốn bao nhiêu chi phí. Cấu trúc quan trọng hơn nội dung văn bản.
2. Kiến trúc quyết định chi phí: Cùng một chỉ dẫn nhưng cấu trúc sai có thể tốn gấp 3 lần ngữ cảnh. Sửa chữa cấu trúc hiệu quả hơn việc chỉnh sửa văn bản.
3. Môi trường của bạn là đặc biệt: AI có các giả định hợp lý về mặc định, nhưng môi trường của bạn thì không. Phần "Gotchas" là cầu nối giữa hai thế giới này.
4. Nâng cấp mô hình không miễn phí: Một Skill tinh chỉnh cho mô hình này có thể bị hỏng trên mô hình khác. Hãy đo lường (evals) mọi thứ.

Hiểu rõ runtime và kiến trúc của Skills sẽ thay đổi hoàn toàn cách bạn xây dựng và tối ưu hóa các tác nhân AI, giúp chúng không chỉ thông minh hơn mà còn hiệu quả và tiết kiệm hơn.