Một AI Skill chỉ thực sự sẵn sàng khi nó làm đúng việc trong nhiều tình huống, không kích hoạt sai và biết dừng khi thiếu dữ liệu. Vì vậy, kiểm thử không nên chỉ là chạy một câu lệnh thuận lợi rồi kết luận “đã hoạt động”. Bạn cần kiểm tra cả điều kiện kích hoạt, các bước thực hiện, tệp hỗ trợ, chất lượng đầu ra và tình huống lỗi.
Nếu bạn chưa quen với khái niệm này, hãy đọc trước bài AI Skill là gì?. Khi cần rà lại cách tổ chức tệp, bài Cấu trúc thư mục AI Skill chuẩn sẽ giúp bạn phân biệt vai trò của `SKILL.md`, `scripts`, `references` và `assets`.
Kiểm thử AI Skill là gì?
Kiểm thử AI Skill là quá trình dùng một tập tình huống có chủ đích để xác minh ba điều: Skill có được gọi đúng lúc hay không, có thực hiện đúng quy trình hay không và đầu ra có đạt tiêu chuẩn hay không.
Khác với việc đọc lại hướng dẫn bằng mắt, kiểm thử buộc Skill phải xử lý những yêu cầu gần với thực tế. Một bộ kiểm thử tốt có cả trường hợp đúng, trường hợp mơ hồ, trường hợp thiếu dữ liệu và trường hợp nằm ngoài phạm vi.
Tài liệu OpenAI về đánh giá Agent Skills khuyến nghị kết hợp tín hiệu xác định — chẳng hạn tệp có được tạo, lệnh có được chạy và thứ tự có đúng không — với đánh giá định tính theo rubric. Cách tiếp cận này giúp phát hiện cả lỗi kỹ thuật lẫn lỗi chất lượng mà một tiêu chí đạt hoặc không đạt đơn giản có thể bỏ sót.
Vì sao Skill chạy được một lần vẫn chưa đủ?
Một lần chạy thành công thường chỉ chứng minh rằng Skill xử lý được một đầu vào thuận lợi trong một môi trường cụ thể. Nó chưa trả lời được những câu hỏi quan trọng:
- Skill có tự kích hoạt khi người dùng không gọi đúng tên không?
- Skill có kích hoạt nhầm với yêu cầu gần giống nhưng khác mục tiêu không?
- Khi thiếu tệp, sai định dạng hoặc không đủ quyền, Skill có dừng đúng chỗ không?
- Các bước bắt buộc có bị bỏ qua khi nhiệm vụ dài hơn không?
- Đầu ra có nhất quán giữa nhiều lần chạy không?
- Skill có tạo thêm tệp rác hoặc thay đổi dữ liệu ngoài phạm vi không?
Kiểm thử giúp biến những câu hỏi này thành tiêu chí có thể quan sát và lặp lại. Mục tiêu không phải loại bỏ hoàn toàn mọi biến động của AI, mà là giới hạn biến động trong phạm vi chấp nhận được.
Xác định “đạt chuẩn” trước khi bắt đầu test
Nếu không có định nghĩa hoàn tất, bạn rất dễ đánh giá kết quả theo cảm giác. Trước khi viết câu lệnh kiểm thử, hãy tạo một rubric ngắn cho Skill.
Tiêu chí kích hoạt
Ghi rõ các tình huống Skill phải được dùng, có thể được dùng và không được dùng. Phần `name` và `description` trong `SKILL.md` là tín hiệu quan trọng để hệ thống nhận diện Skill, vì vậy mô tả quá rộng dễ gây kích hoạt nhầm, còn mô tả quá hẹp khiến Skill bị bỏ qua.
Tiêu chí quy trình
Liệt kê những bước bắt buộc, thứ tự quan trọng, tệp cần đọc và công cụ cần gọi. Nếu một bước chỉ áp dụng trong điều kiện nhất định, hãy nêu rõ điều kiện đó thay vì buộc mọi lần chạy đều làm giống nhau.
Tiêu chí đầu ra
Mô tả kết quả tối thiểu phải có: định dạng, trường dữ liệu, cấu trúc, giọng điệu, độ chính xác và các nội dung không được xuất hiện. Tiêu chí nên đủ cụ thể để hai người kiểm tra độc lập có thể đưa ra kết luận gần giống nhau.
Tiêu chí an toàn và dừng
Xác định hành động nào cần xin xác nhận, dữ liệu nào không được gửi ra ngoài và trường hợp nào Skill phải báo thiếu thông tin. Đây là nhóm tiêu chí không nên đánh đổi chỉ để quy trình hoàn tất nhanh hơn.
Tạo bộ tình huống kiểm thử nhỏ nhưng có chủ đích
Bạn không cần hàng trăm câu lệnh ngay từ đầu. Một bộ từ 10 đến 20 tình huống được chọn kỹ thường đủ để phát hiện những lỗi lớn trong giai đoạn đầu. Khi gặp lỗi mới trong thực tế, hãy bổ sung chính trường hợp đó vào bộ kiểm thử để ngăn lỗi quay lại.
Kích hoạt trực tiếp
Gọi đúng tên Skill trong yêu cầu. Trường hợp này kiểm tra Skill có được nhận diện, đọc đúng hướng dẫn và hoàn tất luồng cơ bản hay không.
Ví dụ: “Dùng Skill kiểm thử AI Skill để đánh giá thư mục này trước khi đóng gói.”
Kích hoạt ngầm
Mô tả đúng nhu cầu nhưng không nhắc tên Skill. Đây là bài test quan trọng cho `description`, vì người dùng thực tế thường nói mục tiêu thay vì biết chính xác tên công cụ.
Ví dụ: “Hãy kiểm tra xem quy trình này có xử lý đúng khi thiếu tệp tham chiếu không.”
Yêu cầu có thêm ngữ cảnh
Đặt nhiệm vụ trong một tình huống dài hơn, có thông tin phụ nhưng vẫn cần Skill. Trường hợp này kiểm tra xem tín hiệu kích hoạt có đủ rõ giữa một yêu cầu nhiều chi tiết hay không.
Negative control
Tạo yêu cầu gần giống nhưng không nên kích hoạt Skill. Nếu Skill vẫn được gọi, mô tả đang quá rộng hoặc chưa nêu ranh giới.
Ví dụ: một Skill tạo dự án mới không nên tự kích hoạt khi người dùng chỉ muốn sửa giao diện của dự án hiện có.
Đầu vào thiếu hoặc sai
Loại bỏ tệp bắt buộc, dùng sai định dạng, để trống trường quan trọng hoặc đưa dữ liệu mâu thuẫn. Skill đạt chuẩn cần phát hiện vấn đề, giải thích điều còn thiếu và tránh tạo ra kết quả đoán mò.
Quy trình kiểm thử AI Skill từng bước
Bước 1: Kiểm tra cấu trúc và đường dẫn
Xác minh Skill có đúng một `SKILL.md`, phần front matter có `name` và `description`, các liên kết đến tài liệu phụ tồn tại và đường dẫn tương đối vẫn hoạt động sau khi đổi máy hoặc đóng gói.
Nếu có `scripts`, hãy kiểm tra tên tệp, quyền thực thi cần thiết và thông báo lỗi. Nếu có `references` hoặc `assets`, hãy chắc rằng `SKILL.md` chỉ dẫn rõ khi nào cần đọc hoặc sử dụng chúng.
Bước 2: Chạy luồng thuận lợi tối thiểu
Dùng một đầu vào đầy đủ và dễ hiểu. Mục tiêu của bước này là xác nhận luồng chính hoạt động từ đầu đến cuối, không phải chứng minh Skill đã hoàn thiện.
Ghi lại các hành động quan trọng: Skill được kích hoạt bằng tín hiệu nào, đã đọc tệp gì, gọi script nào, tạo tệp nào và kết quả cuối nằm ở đâu. Nhật ký này trở thành mốc để so sánh những lần kiểm thử sau.
Bước 3: Kiểm tra khả năng kích hoạt
Chạy lần lượt nhóm trực tiếp, ngầm, có ngữ cảnh và negative control. Với mỗi trường hợp, ghi hai cột: “có nên kích hoạt” và “thực tế có kích hoạt”.
Nếu Skill bỏ lỡ nhiều yêu cầu đúng, hãy làm rõ đối tượng và tình huống sử dụng trong `description`. Nếu kích hoạt nhầm, bổ sung ranh giới hoặc ví dụ về trường hợp không nên dùng.
Bước 4: Kiểm tra việc tuân thủ quy trình
Đừng chỉ đọc câu trả lời cuối. Hãy kiểm tra các mốc bắt buộc: AI có đọc đúng nguồn, chạy đúng công cụ, xin xác nhận ở bước cần thiết và kiểm tra kết quả sau hành động hay không.
Những tiêu chí xác định nên được tự động hóa khi có thể. Ví dụ: tệp đầu ra có tồn tại, định dạng JSON có hợp lệ, thư mục tạm đã được dọn và lệnh bắt buộc có xuất hiện trong nhật ký.
Bước 5: Kiểm tra tình huống lỗi
Thử thiếu tài liệu, đường dẫn sai, script trả lỗi, đầu vào vượt phạm vi và yêu cầu mơ hồ. Một Skill tốt không nhất thiết tự sửa được mọi vấn đề, nhưng phải phản ứng có kiểm soát.
Kết quả mong muốn có thể là dừng lại, yêu cầu thêm dữ liệu, đề xuất lựa chọn an toàn hoặc ghi rõ phần chưa thể hoàn tất. Tự ý đoán thông tin để tiếp tục không được xem là xử lý lỗi thành công.
Bước 6: Chấm chất lượng bằng rubric
Sau các kiểm tra xác định, hãy đánh giá phần khó đo bằng mã: tính rõ ràng, độ tự nhiên, tính đúng thương hiệu, khả năng sử dụng và mức độ tuân thủ mục tiêu.
Một rubric thực tế có thể dùng thang 0–2 cho từng tiêu chí:
| Điểm | Ý nghĩa |
|---|---|
| 0 | Không đạt hoặc thiếu hoàn toàn |
| 1 | Có thực hiện nhưng chưa ổn định hoặc cần sửa đáng kể |
| 2 | Đạt yêu cầu và có thể sử dụng |
Không nên gom mọi thứ thành một điểm tổng duy nhất. Hãy giữ kết quả từng tiêu chí để biết chính xác phần nào cần sửa.
Bước 7: Chạy lại sau mỗi thay đổi
Mỗi lỗi đã sửa nên trở thành một ca kiểm thử cố định. Khi thay đổi `description`, thứ tự bước hoặc tài liệu tham chiếu, hãy chạy lại toàn bộ bộ test cốt lõi thay vì chỉ chạy trường hợp vừa sửa.
Đây là kiểm thử hồi quy: bảo đảm một cải tiến mới không làm hỏng hành vi đã hoạt động trước đó.
Kiểm tra riêng từng thành phần trong thư mục Skill
SKILL.md
- `name` ngắn gọn và nhất quán với tên thư mục.
- `description` nêu cả chức năng và thời điểm nên dùng.
- Hướng dẫn có thứ tự, điều kiện dừng và tiêu chuẩn hoàn tất.
- Không chứa quy tắc mâu thuẫn hoặc yêu cầu đọc mọi tài liệu trong mọi lần chạy.
- Các bước có rủi ro nêu rõ khi nào cần người dùng xác nhận.
Bạn có thể xem cách Markdown hỗ trợ tổ chức hướng dẫn trong bài File .MD là gì?.
scripts
- Script nhận đầu vào rõ ràng và trả mã lỗi hoặc thông báo có thể hiểu.
- Chạy lặp lại không tạo tác dụng phụ ngoài dự kiến.
- Không ghi đè dữ liệu quan trọng nếu chưa có điều kiện bảo vệ.
- Kết quả có thể được kiểm tra bằng điều kiện xác định.
references
- Tài liệu được gọi đúng ngữ cảnh, không tải toàn bộ một cách máy móc.
- Có một nguồn chính khi nhiều tệp nói về cùng chủ đề.
- Nội dung hết hạn hoặc phụ thuộc phiên bản được ghi rõ.
- Quy tắc quan trọng không bị giấu trong tài liệu mà Skill không biết phải đọc.
assets
- Tên tệp mô tả đúng chức năng và không gây nhầm phiên bản.
- Mẫu không chứa dữ liệu riêng tư hoặc nội dung mẫu chưa được thay thế.
- Định dạng tương thích với công cụ sẽ sử dụng.
- Đầu ra không phụ thuộc vào đường dẫn tuyệt đối trên máy của người tạo.
Mẫu bảng ghi kết quả kiểm thử
| ID | Tình huống | Nên kích hoạt | Kết quả mong đợi | Kết quả thực tế | Trạng thái |
|---|---|---|---|---|---|
| T01 | Gọi đúng tên Skill | Có | Chạy đủ luồng cơ bản | Ghi sau khi test | Chờ kiểm tra |
| T02 | Mô tả đúng nhu cầu, không gọi tên | Có | Skill tự nhận diện | Ghi sau khi test | Chờ kiểm tra |
| T03 | Yêu cầu gần giống nhưng ngoài phạm vi | Không | Không kích hoạt Skill | Ghi sau khi test | Chờ kiểm tra |
| T04 | Thiếu tệp bắt buộc | Có | Dừng và yêu cầu bổ sung | Ghi sau khi test | Chờ kiểm tra |
| T05 | Đầu vào hợp lệ nhưng nhiều ngữ cảnh | Có | Hoàn tất đúng quy trình | Ghi sau khi test | Chờ kiểm tra |
Bảng này không nhằm thay thế nhật ký chi tiết. Nó là lớp tóm tắt giúp bạn nhận ra xu hướng: Skill đang bỏ lỡ kích hoạt, kích hoạt quá mức hay thường sai ở cùng một bước.
Checklist trước khi đóng gói AI Skill
- Cấu trúc thư mục đúng và chỉ có một `SKILL.md`.
- Front matter hợp lệ; `name` và `description` phản ánh đúng phạm vi.
- Đã chạy ca kích hoạt trực tiếp, kích hoạt ngầm và có thêm ngữ cảnh.
- Có ít nhất một negative control để phát hiện kích hoạt nhầm.
- Đã kiểm tra đầu vào thiếu, sai định dạng và mâu thuẫn.
- Các bước bắt buộc được quan sát, không chỉ đánh giá câu trả lời cuối.
- Script xử lý lỗi rõ ràng và không tạo thay đổi ngoài phạm vi.
- References và assets được gọi đúng lúc, không có đường dẫn hỏng.
- Rubric chất lượng có tiêu chí cụ thể thay vì nhận xét chung chung.
- Mọi lỗi đã sửa đều được thêm vào bộ kiểm thử hồi quy.
- Không còn tệp tạm, dữ liệu thật hoặc thông tin nhạy cảm trong gói.
- File ZIP chứa đúng một thư mục cấp cao nhất và mở được sau khi đóng gói.
Câu hỏi thường gặp
Cần bao nhiêu tình huống để kiểm thử một AI Skill?
Không có con số cố định cho mọi Skill. Với phiên bản đầu, một tập nhỏ từ 10 đến 20 tình huống có chủ đích thường đủ để phát hiện lỗi kích hoạt và quy trình quan trọng. Hãy mở rộng bộ test từ các lỗi thực tế thay vì thêm nhiều câu lệnh giống nhau.
Negative control là gì?
Negative control là yêu cầu gần với phạm vi của Skill nhưng không nên kích hoạt Skill. Nó giúp phát hiện mô tả quá rộng và giảm tình trạng AI dùng sai quy trình cho một nhiệm vụ chỉ có vẻ tương tự.
Có cần tự động hóa toàn bộ việc kiểm thử không?
Không. Những kiểm tra như tệp tồn tại, định dạng hợp lệ hoặc lệnh đã chạy phù hợp với tự động hóa. Các yếu tố như giọng văn, tính hữu ích và độ phù hợp thương hiệu thường cần rubric định tính hoặc người đánh giá.
Khi nào một AI Skill sẵn sàng để đóng gói?
Skill sẵn sàng khi vượt qua bộ test cốt lõi, không còn lỗi nghiêm trọng, phản ứng an toàn khi thiếu dữ liệu và đầu ra đạt rubric đã thống nhất. Các giới hạn còn lại cần được ghi rõ thay vì che giấu.
Kết luận
Kiểm thử AI Skill không phải bước trang trí trước khi tạo file ZIP. Đây là cách biến một quy trình “có vẻ chạy được” thành công cụ có hành vi quan sát được và có thể cải thiện theo thời gian.
Hãy bắt đầu bằng định nghĩa đạt chuẩn, tạo bộ tình huống nhỏ gồm cả trường hợp đúng và sai, kiểm tra hành động thực tế rồi chấm chất lượng bằng rubric. Mỗi lỗi được phát hiện nên trở thành một ca kiểm thử hồi quy. Nhờ vậy, phiên bản sau không chỉ có thêm tính năng mà còn đáng tin cậy hơn phiên bản trước.