Anthropic cuối cùng đã công bố phương pháp luận Kỹ năng nội bộ của họ

Xem một bài blog do đội ngũ Anthropic viết có tựa đề 《Lessons from building Claude Code: How we use skills》. Đây có lẽ là tổng kết thực tiễn về Skill sâu sắc nhất mà tôi đã từng đọc đến nay.

Skill thực ra không phức tạp lắm, nhưng để làm tốt Skill, tôi nghĩ cũng không dễ dàng như vậy.

Tôi còn nhớ khi Skill mới nổi lên, mọi người rất thích làm các Skill về phong cách viết, kỹ năng viết. Có vẻ chỉ cần nhét phong cách viết của mình vào, mô hình có thể ổn định xuất ra theo phong cách đó.

Nhưng sau này tôi thử một vòng, phát hiện nhiều lúc hoàn toàn không khả thi.

Bởi vì một phong cách viết Skill có thể nhét vào vài nghìn đến vài vạn từ nội dung. Khi Skill được tải vào, ngữ cảnh sẽ chiếm phần lớn. Ngữ cảnh quá lớn, khả năng suy nghĩ của mô hình lại giảm đi rõ rệt.

Kết quả thường gặp phải là: phong cách đã học được, nhưng nội dung trở nên nông cạn, khả năng phân tích cũng yếu đi.

Còn có một tình huống phổ biến khác.

Nhiều người khi viết Skill, thích nhét vào đó các hướng dẫn thao tác. Bước 1 làm gì, bước 2 làm gì, bước 3 làm gì. Kết quả chạy thử thì phát hiện, mô hình thực thi không ổn định.

Sau này tôi mới dần hiểu ra, nhiều công việc lặp đi lặp lại kiểu này thực ra phù hợp hơn để thành Script, chứ không phải viết thành các Instructions dài dòng.

Xem xong bài viết của Anthropic, tôi cảm nhận rõ nhất là, nhiều người thực ra đang dùng Skill, nhưng chưa chắc đã hiểu đúng về Skill.

Skill về bản chất là làm về Kỹ thuật Ngữ cảnh (Context Engineering). Khi nào nên đưa kiến thức vào Skill, khi nào nên tách thành References, khi nào viết thành Script, khi nào dùng Gotchas để ràng buộc mô hình, trong đó thực ra có rất nhiều kinh nghiệm.

Hiểu được nguyên lý hoạt động của Skill rồi, khi nhìn lại các Skill xuất sắc, sẽ thấy chúng không phải giải quyết vấn đề về prompt, mà là giải quyết về ngữ cảnh, tích lũy kinh nghiệm và khả năng tái sử dụng.

Nếu ai muốn nghiên cứu sâu về Skill, đặc biệt khuyên xem hai bài viết sau:

#01 Đừng viết lời vô nghĩa

Bản chất của Skill là tích lũy kiến thức ngầm trong tổ chức. Vì vậy, trong Skill đừng lặp lại những kiến thức đã biết. Những gì thực sự có giá trị là những thông tin mà mô hình hoàn toàn không biết.

Trong nội bộ Anthropic thường nhấn mạnh, Skill thực sự cần viết là Gotchas, tức là những lỗi thường gặp.

Ví dụ:

1. Bảng này không được sắp xếp theo created_at

2. Trả về 200 từ staging không đồng nghĩa thành công

3. request_id và trace_id là cùng một thứ

Bởi vì những thông tin này thường nằm trong kinh nghiệm của nhân viên. Vì vậy, cần nhớ rõ bản chất của Skill là gì.

Skill = Viết lại kinh nghiệm của thợ lành nghề.

Thông qua Skill, tích lũy lại những kinh nghiệm từng rải rác trong đầu các người khác nhau.

#02 Skill thực ra là Kỹ thuật Ngữ cảnh

Đâ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 tệp markdown, mà là một thư mục. Đối với người đã dùng Skill rồi, câu này nghe có vẻ vô nghĩa.

Nhưng tôi đã suy nghĩ đi nghĩ lại trong hai ngày qua, dần nhận ra: họ muốn dùng dạng thư mục để thể hiện ý tưởng về Kỹ thuật Ngữ cảnh.

Chúng ta xem lại cấu trúc điển hình của một Skill:

skill/ ├── SKILL.md ├── references/ chứa hướng dẫn chi tiết, API tham khảo, điều kiện biên ├── scripts/ chứa script có thể thực thi ├── examples/ chứa ví dụ ├── assets/ chứa mẫu, hình ảnh, tài nguyên cố định

Khi gọi một Skill, mô hình đầu tiên đọc là SKILL.md. Nếu tất cả thông tin đều nhét vào file này, sẽ rất nhanh gây bội thực ngữ cảnh.

Giả sử đây là một Skill về xử lý lỗi thanh toán, trong đó có mô tả mã lỗi Stripe, các trường hợp lỗi lịch sử, script xử lý và mẫu báo cáo cuối cùng.

Nếu tất cả nội dung này đều nhét vào SKILL.md, mỗi lần gọi Skill, Claude phải đọc lại toàn bộ.

Ngay cả khi người dùng chỉ muốn xác nhận ý nghĩa của một mã lỗi, hay xem lý do tại sao trạng thái thanh toán không cập nhật, thì lượng thông tin không cần thiết cũng sẽ bị nhồi vào ngữ cảnh.

Trong khi đó, ý tưởng của Anthropic hoàn toàn khác.

SKILL.md giống như một trang dẫn hướng. Nhiệm vụ của nó là thông báo cho mô hình, khi gặp lỗi Stripe thì tìm trong references để xem hướng dẫn tương ứng.

Khi cần tham khảo các trường hợp lịch sử, vào trong examples để tra các vấn đề tương tự, cần thực thi các script trong scripts, và cuối cùng khi tạo báo cáo xử lý lỗi, dùng mẫu trong assets.

Toàn bộ quá trình này là dần dần tiết lộ thông tin.

Dưới đây là hình ảnh, rất khuyên mọi người nên lưu lại.

#03 Tối đa dùng script

Đừng để mô hình lãng phí khả năng ngữ cảnh và suy luận hạn chế vào việc lặp lại. Hãy giao việc đó cho script.

Ví dụ. Nhiều người khi viết Skill, thường làm 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 đương nhiên không sai. Mô hình cũng có thể làm được. Nhưng mỗi lần chạy, nó phải làm 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 tình huống biên đều là công việc lặp đi lặp lại.

Vì những khả năng này đã được kiểm chứng qua vô số lần, tại sao lại bắt mô hình tự phát minh lại lần nữa? Thay vào đó, tốt hơn là cung cấp sẵn script cụ thể.

Hơn nữa, qua script, việc thực thi Skill sẽ chính xác hơn, và tiết kiệm Token hơn.

Từ góc độ này, Scripts trong Skill thực ra là tích lũy năng lực tổ chức. Mỗi script đều là kết quả tổng kết từ nhiều lần mắc lỗi, rút ra các thực hành tốt nhất của nhóm.

Sau khi cố định những khả năng này, Claude mỗi lần đều có thể làm việc dựa trên kinh nghiệm đó, chứ không phải bắt đầu từ con số 0.

Vì vậy, tôi ngày càng tin rằng, trong Skill, Instructions và Scripts giải quyết hai vấn đề khác nhau.

Instructions cung cấp kinh nghiệm và phán đoán, Scripts cung cấp khả năng và thực thi.

Ví dụ, trong một Skill xử lý lỗi thanh toán, có thể có câu:

Nếu Stripe trả về 200, đừng vội nghĩ là thanh toán thành công, cần kiểm tra thêm bảng payment_events.

Đây là Instructions, vì là kinh nghiệm. Còn check_payment_events() là Script, vì là khả năng thực thi.

Nếu chỉ có Script, mô hình biết cách tra, nhưng chưa chắc biết tại sao phải tra.

Nếu chỉ có Instructions, mô hình biết cần tra, nhưng mỗi lần đều phải tự làm lại. Cần cả hai mới tối ưu.

#04 Mô tả như một quy tắc định tuyến

Cách mọi người viết Skill Description thường sai ngay từ đầu.

Bởi vì mọi người quen viết giới thiệu chức năng. Ví dụ: PR Management Skill giúp theo dõi trạng thái PR, xử lý vấn đề CI, tự động hợp nhất.

Nhưng vấn đề là, mô hình không dựa vào chức năng để tìm Skill, khi Claude Code khởi động, nó sẽ quét tên và mô tả của tất cả Skill.

Sau đó dựa vào vấn đề của người dùng hiện tại, xác định nên tải Skill nào.

Vì vậy, nội dung quan trọng nhất trong Description không phải là Skill này làm gì, mà là trong tình huống nào nên tải nó.

Description thực ra đảm nhận vai trò định tuyến cho toàn bộ Skill.

Trong thế giới thực, ít ai nói: giúp tôi gọi một công cụ quản lý PR. Mọi người thường nói: giúp tôi theo dõi PR này, hoặc CI bị lỗi, v.v.

Vì vậy, một mô tả tốt nên mô tả rõ ý định của người dùng, chứ không phải liệt kê chức năng.

Tôi thậm chí nghĩ ra một cách kiểm tra đơn giản.

Viết xong Description, xóa bỏ toàn bộ Skill, chỉ giữ lại dòng Description này. Rồi tự hỏi: sau khi mô hình thấy câu hỏi của người dùng, có thể biết khi nào nên tải Skill này không.

Nếu không làm được, thì có lẽ cần tiếp tục chỉnh sửa.

#05 Quản lý và phân phối Skill

Còn một vấn đề nữa là quản lý Skill.

Khi một người dùng Skill, thực ra rất đơn giản. Viết vài Skill, tự duy trì, tự nâng cấp là xong. Nhưng tôi tin phần lớn các nhóm sau này sẽ gặp phải vấn đề chung.

Khi Skill từ vài cái lên hàng chục, hàng trăm, thì làm thế nào để quản lý? Làm thế nào để nâng cấp? Làm thế nào phân phối cho thành viên trong nhóm?

Kinh nghiệm của Anthropic trong lĩnh vực này tôi nghĩ rất đáng tham khảo.

Trong quy mô nhỏ, Skill theo mã nguồn. Đặt trong thư mục .claude/skills của dự án. Mọi người chia sẻ chung một bộ Skill, chung một phương pháp làm việc.

Nhưng khi số Skill ngày càng nhiều, xuất hiện vấn đề mới.

Khi Claude Code khởi động, nó sẽ quét tất cả tên và mô tả Skill, rồi xác định xem nhiệm vụ hiện tại nên gọi Skill nào. Skill càng nhiều, chi phí định tuyến càng cao.

Đây cũng là lý do tại sao Anthropic bắt đầu xây dựng Marketplace. Nhưng cách quản lý Marketplace của họ còn thú vị hơn.

Nhiều công ty gặp vấn đề này, phản ứng đầu tiên thường là xây dựng quy trình phê duyệt. Ai viết Skill, gửi đơn xin; sau khi duyệt, mới đưa vào thư viện Skill chính thức. Trước đây chúng tôi cũng làm như vậy, nhưng rất nặng nề. Quản lý để quản lý.

Còn Anthropic thì tổ chức rất nhẹ nhàng.

Để Skill mới trước tiên lan truyền trong phạm vi nhỏ, để đồng nghiệp tự cài đặt, tự thử nghiệm.

Nếu càng ngày càng nhiều người bắt đầu dùng, chứng tỏ Skill đó thực sự giải quyết vấn đề thực. Đến giai đoạn này, tác giả mới nộp vào Marketplace chính thức.

Vì vậy, họ không đặt nặng việc Skill có giá trị hay không, mà để nó trải qua thử nghiệm thực tế. Người dùng nhiều, tự nhiên sẽ vào hệ thống chính thức. Skill nào được giữ lại đều là những Skill thực sự cần thiết của nhóm.