Hầu hết mọi người viết Skill đều sai: 5 điểm suy ngẫm sau khi Anthropic công khai phương pháp luận nội bộ

Tác giả: Sản phẩm AI Á Ánh

Đã xem một bài blog của đội 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 thấy cho đến nay.

Skill này thực ra không phức tạp, nhưng muốn 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, mọi người rất thích làm các Skill về phong cách văn viết, kỹ năng viết lách. Có vẻ chỉ cần đưa phong cách viết của mình vào, mô hình có thể ổn định theo phong cách đó để xuất ra.

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 văn viết Skill có thể chỉ cần vài nghìn đến vài vạn từ nội dung. Khi Skill được nạp vào, ngữ cảnh sẽ chiếm một phần lớn. Ngữ cảnh càng lớn, khả năng suy nghĩ của mô hình lại càng giảm.

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 hơn, khả năng phân tích cũng yếu đi.

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

Nhiều người khi viết Skill, thích chèn 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 để tích lũy thành Script, chứ không phải viết thành các Instructions dài dằng dặc.

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 đã thực sự hiểu về Skill.

Skill về bản chất là làm về Quản lý 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 rõ nguyên lý hoạt động của Skill rồi, quay lại nhìn những Skill xuất sắc, sẽ thấy chúng không phải là vấn đề về prompt, mà là giải quyết các vấn đề về ngữ cảnh, tích lũy kinh nghiệm và khả năng tái sử dụng.

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

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

Skill về bản chất là tích lũy "kiến thức ẩn" trong tổ chức. Vì vậy, trong Skill không nên 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 tồn tại 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 = ghi 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à Quản lý Ngữ cảnh (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 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ĩ 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ề Quản lý 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ồi vào file này, sẽ rất nhanh gây bùng nổ 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 của 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 đẩy vào SKILL.md, mỗi lần gọi Skill, Claude đều 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 chỉ muốn 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ị đẩy 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 phần mô tả tương ứng.

Khi cần tham khảo các trường hợp lỗi lịch sử, vào trong examples để tra vấn đề tương tự, khi cần thực hiện thao tác xử lý, chạy script trong scripts, cuối cùng khi tạo báo cáo 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 những công việc lặp đi lặp lại. Hãy giao những việc này 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 thực thi, nó đều 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? Thay vì đó, tốt hơn là cung cấp script cụ thể.

Hơn nữa, qua cách dùng script, việc thực thi Skill sẽ chính xác hơn, 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ả của quá trình đội nhóm trải qua nhiều lỗi, rút ra các thực hành tốt nhất.

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, Instructions và Scripts trong Skill 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 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. Bởi vì đây 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 cứu, nhưng chưa chắc biết tại sao phải tra cứu.

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

#04 Mô tả giống như 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 Merge.

Nhưng vấn đề là, mô hình không tìm Skill qua chức năng, 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 của 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 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, CI bị lỗi, v.v.

Vì vậy, một Description 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 vấn đề 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ì khả năng cao là vẫn cần chỉnh sửa tiếp.

#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, chuyện này khá đơ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, thậm chí 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.

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

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

Claude Code khởi động, 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 thú vị hơn là cách họ quản lý Marketplace.

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, nộp đơn xin; sau khi duyệt, mới đưa vào kho 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ý.

Tôi nhận thấy tổ chức của Anthropic 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 ngày càng nhiều người bắt đầu dùng, chứng tỏ Skill này thực sự giải quyết vấn đề thực tế nào đó. Đế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ế, dùng nhiều người, tự nhiên sẽ vào hệ thống chính thức. Skill nào còn phù hợp với nhu cầu thực tế của đội nhóm, thì sẽ được giữ lại.