Cách sử dụng đúng “Skill”: 5 điểm suy ngẫm sau khi Anthropic công bố phương pháp nội bộ
Tuyển chọn TechFlowTuyển chọn TechFlow
Cách sử dụng đúng “Skill”: 5 điểm suy ngẫm sau khi Anthropic công bố phương pháp nội bộ
Nhiều người đang sử dụng Skill, nhưng chưa chắc đã thực sự hiểu rõ về Skill.
Chuyên sâu báo cáo Web3Tác giả: A Ying – Chuyên gia sản phẩm AI
Tôi vừa đọc một bài blog do đội ngũ Anthropic viết với tiêu đề “Bài học từ việc xây dựng Claude Code: Cách chúng tôi sử dụng Skill”. Đây có lẽ là bài tổng kết thực tiễn sâu sắc nhất về khái niệm “Skill” mà tôi từng đọc cho đến nay.
Thực ra, bản thân “Skill” không hề phức tạp, nhưng để làm tốt thực sự thì cũng không dễ chút nào.
Tôi còn nhớ lúc “Skill” mới bắt đầu nổi lên, mọi người đặc biệt thích xây dựng đủ loại Skill phong cách văn bản, Skill viết lách… Dường như chỉ cần nhét phong cách viết của mình vào, mô hình sẽ ổn định sinh nội dung theo đúng phong cách đó.
Nhưng sau đó tôi tự thử nghiệm một vòng và phát hiện ra rằng trong nhiều trường hợp điều này hoàn toàn bất khả thi.
Lý do là vì một Skill phong cách văn bản có thể chứa tới vài nghìn hoặc thậm chí hàng chục nghìn ký tự. Khi Skill được tải vào, phần lớn ngữ cảnh (context) đã bị chiếm dụng. Ngữ cảnh càng nặng, khả năng suy luận của mô hình lại càng dễ suy giảm.
Kết quả thường là: phong cách thì học được, nhưng nội dung trở nên nông cạn hơn và năng lực phân tích cũng yếu đi rõ rệt.
Còn một tình huống phổ biến khác:
Nhiều người khi viết Skill thường thích nhét vào đó các hướng dẫn thao tác chi tiết: bước một làm gì, bước hai làm gì, bước ba làm gì… Nhưng khi chạy thử sẽ thấy mô hình thực thi không ổn định.
Sau này tôi mới dần hiểu ra: những công việc lặp đi lặp lại như vậy thực tế phù hợp hơn để chuẩn hóa thành Script, chứ không nên viết thành những đoạn hướng dẫn dài dòng.
Sau khi đọc xong bài viết của Anthropic, cảm nhận mạnh mẽ nhất của tôi là: rất nhiều người thực tế đang dùng Skill, nhưng chưa chắc đã thực sự hiểu Skill.
Về bản chất, Skill chính là Context Engineering. Việc nào nên đưa kiến thức vào Skill, việc nào nên tách thành References, việc nào nên viết thành Script, và việc nào nên dùng Gotchas để ràng buộc hành vi mô hình — tất cả đều hàm chứa rất nhiều kinh nghiệm thực tiễn.
Khi đã nắm rõ nguyên lý vận hành của Skill, quay lại nhìn những Skill xuất sắc, ta sẽ nhận ra rằng chúng không giải quyết vấn đề của prompt, mà thực chất đang giải quyết các vấn đề về ngữ cảnh, tích lũy kinh nghiệm và tái sử dụng năng lực.
Nếu bạn muốn nghiên cứu chuyên sâu về Skill, tôi đặc biệt khuyến khích đọc hai bài viết sau:
https://claude.com/blog/lessons-from-building-claude-code-how-we-use-skills
#01 Đừng viết những lời thừa
Về bản chất, Skill là để lưu trữ “kiến thức ngầm” trong tổ chức. Vì vậy, trong Skill không nên lặp lại những điều hiển nhiên mô hình đã biết. Thông tin thực sự có giá trị chính là những điều mà mô hình hoàn toàn không biết.
Bên trong Anthropic thường nhấn mạnh rằng phần cốt lõi cần viết trong Skill chính là các “Gotchas” — tức là những bẫy hay gặp phải.
Ví dụ:
1. Bảng này KHÔNG được sắp xếp theo trường created_at
2. Việc staging trả về mã trạng thái 200 KHÔNG đồng nghĩa với thành công
3. request_id và trace_id là một thứ
Những thông tin này thường tồn tại trong kinh nghiệm thực tế của nhân viên. Vì vậy, hãy luôn ghi nhớ bản chất thực sự của Skill.
Skill = Ghi lại kinh nghiệm của những người thợ lành nghề.
Thông qua Skill, kinh nghiệm vốn phân tán trong đầu nhiều người giờ đây được hệ thống hóa và lưu trữ tập trung.
#02 Skill thực chất là Context Engineering
Đây có thể là một trong những quan điểm sâu sắc nhất của Anthropic.
Skill không phải là một file markdown đơn thuần, mà là một thư mục. Với những người đã từng dùng Skill, câu này nghe có vẻ như “nói thừa”.
Nhưng trong hai ngày gần đây, tôi liên tục suy ngẫm và dần nhận ra: chính hình thức “thư mục” này là cách họ muốn biểu đạt triết lý về Context Engineering.
Hãy cùng xem lại cấu trúc điển hình của một Skill:
skill/
├── SKILL.md
├── references/ — chứa tài liệu chi tiết, tham khảo API, điều kiện biên
├── scripts/ — chứa các script có thể thực thi
├── examples/ — chứa các ví dụ minh họa
├── assets/ — chứa mẫu biểu, hình ảnh, tài nguyên cố định
Khi gọi một Skill cụ thể, mô hình trước tiên sẽ đọc file SKILL.md. Nếu nhét toàn bộ thông tin vào file này, ngữ cảnh sẽ nhanh chóng “bùng nổ”.
Giả sử đây là một Skill xử lý sự cố thanh toán, trong đó vừa có bảng giải thích mã lỗi Stripe, vừa có các trường hợp sự cố lịch sử, vừa có script kiểm tra và mẫu báo cáo cuối cùng.
Nếu dồn hết mọi thứ vào SKILL.md, mỗi lần gọi Skill, Claude đều phải đọc lại toàn bộ nội dung.
Dù người dùng chỉ muốn xác minh ý nghĩa của một mã lỗi, hay chỉ muốn kiểm tra lý do vì sao trạng thái thanh toán chưa được cập nhật — thì lượng thông tin dư thừa khổng lồ vẫn sẽ bị nhét vào ngữ cảnh cùng lúc.
Trong khi đó, tư duy của Anthropic hoàn toàn khác biệt.
File SKILL.md giống như một trang điều hướng. Nhiệm vụ của nó là hướng dẫn mô hình: khi gặp lỗi Stripe, hãy tìm phần giải thích tương ứng trong thư mục references.
Khi cần tham khảo các trường hợp sự cố trong quá khứ, hãy tra cứu các vấn đề tương tự trong thư mục examples; khi cần thực hiện các bước kiểm tra thực tế, hãy chạy script trong thư mục scripts; và khi tạo báo cáo xử lý sự cố cuối cùng, hãy sử dụng mẫu trong thư mục assets.
Toàn bộ quá trình này là một sự “tiết lộ từng bước” (progressive exposure).
Hình ảnh dưới đây, tôi rất khuyến khích bạn lưu lại.
#03 Ưu tiên dùng script
Đừng để mô hình lãng phí ngữ cảnh hạn chế và năng lực suy luận quý báu vào những công việc lặp lại. Hãy giao những việc này cho script.
Ví dụ: Khi viết Skill, nhiều người thường viết như sau:
1. Truy vấn dữ liệu đăng ký;
2. Truy vấn dữ liệu thanh toán;
3. Tính tỷ lệ chuyển đổi;
4. Phân tích nguyên nhân bất thường.
Cách viết này dĩ nhiên không sai, và mô hình cũng có thể hoàn thành. Nhưng mỗi lần thực thi, nó đều phải đi lại toàn bộ quy trình phân tích từ đầu.
Việc truy vấn dữ liệu, xử lý dữ liệu, xử lý các trường hợp đặc biệt — tất cả đều là những công việc lặp đi lặp lại.
Khi những năng lực này đã được kiểm chứng hàng trăm lần rồi, tại sao lại bắt mô hình “phát minh lại bánh xe”? Thay vào đó, hãy cung cấp trực tiếp các script cụ thể.
Hơn nữa, việc sử dụng script còn giúp thực thi Skill chính xác hơn và tiết kiệm token hơn.
Nhìn từ góc độ này, các script trong Skill thực chất là để tích lũy năng lực của tổ chức. Mỗi script thường phản ánh những bài học thực tiễn tốt nhất, được đúc kết sau vô số lần vấp ngã của cả nhóm.
Khi những năng lực này được chuẩn hóa và cố định lại, Claude mỗi lần làm việc đều có thể dựa trên nền tảng kinh nghiệm sẵn có, chứ không phải bắt đầu từ con số không mỗi lần.
Do đó, tôi ngày càng nhận thấy rõ hơn rằng Instructions và Scripts trong Skill giải quyết hai vấn đề ở hai cấp độ khác nhau.
Instructions cung cấp kinh nghiệm và phán đoán; Scripts cung cấp năng lực và khả năng thực thi.
Ví dụ, trong một Skill xử lý sự cố thanh toán có thể có dòng sau:
“Nếu Stripe trả về mã 200, đừng vội kết luận là thanh toán thành công — cần kiểm tra thêm bảng payment_events.”
Đây là phần Instructions, bởi vì đây là kinh nghiệm. Còn hàm check_payment_events() lại thuộc về Script, bởi vì đây là năng lực thực thi.
Nếu chỉ có Script, mô hình biết cách kiểm tra, nhưng chưa chắc đã hiểu vì sao phải kiểm tra.
Nếu chỉ có Instructions, mô hình biết cần kiểm tra, nhưng mỗi lần đều phải triển khai lại từ đầu. Cả hai thành phần đều không thể thiếu.
#04 Mô tả (Description) giống như một quy tắc định tuyến
Cách nhiều người viết Description cho Skill từ gốc đã sai.
Vì đa số quen viết theo kiểu giới thiệu chức năng. Ví dụ: “PR Management Skill giúp người dùng giám sát trạng thái PR, xử lý các vấn đề CI và tự động hoàn tất merge.”
Nhưng vấn đề nằm ở chỗ: mô hình KHÔNG tìm kiếm Skill dựa trên chức năng. Khi Claude Code khởi động, nó sẽ quét tên và mô tả (Description) của tất cả các Skill.
Sau đó, dựa trên vấn đề hiện tại của người dùng, mô hình sẽ xác định xem nên tải Skill nào.
Vì vậy, thông tin quan trọng nhất trong Description không phải là “Skill này làm được gì”, mà là “trong hoàn cảnh nào nên tải Skill này”.
Mô tả (Description) thực chất đảm nhiệm vai trò định tuyến (routing) cho toàn bộ Skill.
Trong thế giới thực, hiếm khi có người nói: “Hãy giúp tôi gọi công cụ quản lý PR.” Mà họ thường nói: “Giúp tôi theo dõi PR này”, “CI lại bị lỗi rồi”, v.v.
Do đó, một Description tốt nên mô tả tối đa ý định của người dùng, chứ không liệt kê chức năng.
Thậm chí tôi cho rằng có thể dùng một phương pháp cực kỳ đơn giản để kiểm tra.
Sau khi viết xong Description, hãy xóa toàn bộ Skill, chỉ giữ lại dòng Description này. Sau đó tự hỏi: “Khi mô hình nhìn thấy câu hỏi của người dùng, liệu nó có thể biết khi nào nên tải Skill này không?”
Nếu không thể, thì rất có thể bạn vẫn cần chỉnh sửa tiếp.
#05 Quản lý và phân phối Skill
Một vấn đề nữa liên quan đến quản lý Skill.
Khi chỉ một người dùng Skill, việc này thực sự rất đơn giản: tự viết vài Skill, tự bảo trì và tự nâng cấp. Nhưng tôi tin rằng hầu hết các nhóm đều sẽ gặp cùng một vấn đề khi quy mô mở rộng.
Khi số lượng Skill tăng từ vài cái lên vài chục, thậm chí vài trăm, thì nên quản lý, nâng cấp và phân phối chúng cho các thành viên trong nhóm như thế nào?
Kinh nghiệm của Anthropic trong lĩnh vực này rất đáng để tham khảo.
Khi nhóm còn nhỏ, Skill có thể đi kèm trực tiếp với kho mã nguồn. Chỉ cần đặt chúng vào thư mục .claude/skills trong dự án là được. Mọi người cùng chia sẻ một bộ Skill và cùng áp dụng một phương pháp làm việc.
Nhưng khi số lượng Skill ngày càng tăng, một vấn đề mới xuất hiện.
Khi Claude Code khởi động, nó sẽ quét tên và mô tả của tất cả các Skill để xác định nên gọi Skill nào cho tác vụ hiện tại. Số lượng Skill càng nhiều, chi phí định tuyến càng cao.
Đây cũng chính là lý do Anthropic sau này phát triển Marketplace. Nhưng điều thú vị hơn cả là cách họ quản lý Marketplace.
Nhiều công ty khi gặp vấn đề này thường phản ứng đầu tiên là thiết lập một quy trình phê duyệt: ai viết Skill thì phải nộp đơn xin phê duyệt trước; sau khi được duyệt mới đưa vào kho Skill chính thức. Trước đây bên trong chúng tôi cũng từng làm như vậy, nhưng quy trình rất nặng nề — quản lý vì quản lý.
Tôi nhận thấy cách tổ chức của Anthropic lại rất linh hoạt.
Họ để các Skill mới lan truyền trong phạm vi nhỏ trước, để đồng nghiệp tự cài đặt và tự thử nghiệm.
Nếu ngày càng nhiều người bắt đầu sử dụng, điều đó chứng tỏ Skill này thực sự đã giải quyết một vấn đề thực tế. Đến giai đoạn này, tác giả mới chính thức nộp lên Marketplace chính thức.
Vì vậy, họ không tranh luận trước về “Skill này có giá trị hay không”, mà để nó chịu kiểm định trong các tình huống sử dụng thực tế. Khi có đủ người dùng, nó tự nhiên sẽ được đưa vào hệ thống chính thức. Những Skill còn sót lại theo cách này cơ bản đều là những Skill thực sự cần thiết cho cả nhóm.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
