Bài 9: Skills: biến cách làm tốt thành quy trình tái sử dụng

Chị Hạnh ở phòng kinh doanh đã quen với việc giao tác vụ chuẩn hoá biên bản họp cho Work, mỗi tuần một lần gõ lại năm phần: kết quả, bối cảnh, đầu vào, ràng buộc, tiêu chí nghiệm thu. Đến tuần thứ tám, chị nhận ra mình đang gõ gần như y hệt nội dung cũ, chỉ đổi tên file đầu vào và ngày họp. Mỗi lần gõ lại, chị lại quên mất một chi tiết nhỏ, có tuần thiếu mục "Người phụ trách", có tuần quên ghi hạn hoàn thành.

Đây là lúc bạn cần nghĩ đến mục Skills. Một Skill không phải câu lệnh dài bạn phải nhớ nằm lòng, mà là một quy trình bạn đóng gói một lần, để dùng lại nhiều lần với kết quả nhất quán, dù dữ liệu đầu vào mỗi lần khác nhau.

Sau bài này bạn sẽ làm được

• Phân biệt được Skill với "một câu lệnh dài được đặt tên cho oai"
• Nhận ra ba điều kiện cho biết một quy trình nên đóng gói thành Skill
• Viết đủ sáu thành phần của một Skill cụ thể, dùng lại được ngay lần sau
• Chạy thử một Skill hai lần với dữ liệu khác nhau để kiểm tra trước khi tin dùng thật

Skill khác gì một câu lệnh dài đặt tên

Nhiều người nghĩ đóng gói Skill chỉ là lưu lại đoạn hướng dẫn dài rồi đặt tên, ví dụ "Biên bản họp chuẩn". Cách này đỡ gõ lại, nhưng vẫn giữ nguyên nhược điểm của một câu lệnh: dữ liệu đầu vào thiếu thì AI đoán bừa, bạn quên nhắc định dạng thì AI trả về tuỳ hứng.

Một Skill đúng nghĩa có ba lớp: điều kiện gọi, các bước xử lý rõ ràng, và cách kiểm tra đầu ra. Nó không chỉ nói AI "làm gì", mà còn nói rõ khi nào nên dùng, khi nào không, và dựa vào đâu để biết đã làm đúng.

Ba điều kiện nên đóng gói thành Skill

Không phải việc gì lặp lại cũng cần đóng gói. Bạn kiểm đủ ba điều kiện sau trước khi bỏ công viết một Skill.

• Hẹp — quy trình chỉ làm đúng một việc rõ ràng, ví dụ "chuẩn hoá biên bản họp thành 4 mục", không phải "giúp tôi làm việc tốt hơn"
• Lặp lại — bạn thực hiện việc này thường xuyên, mỗi tuần hoặc mỗi tháng, không phải một lần rồi thôi
• Đo được — bạn biết chính xác thế nào là kết quả đạt, ví dụ "đủ 4 mục, mỗi việc cần làm có tên người phụ trách và hạn hoàn thành"

Việc chuẩn hoá biên bản họp của chị Hạnh khớp cả ba: chỉ làm một việc, lặp lại mỗi tuần, và có tiêu chí rõ để biết đạt hay chưa. Ngược lại, việc viết một bài phát biểu khai giảng chỉ xảy ra một lần mỗi năm học, không đáng đóng gói thành Skill, làm trực tiếp trong Chat hoặc Work là đủ.

Chọn đúng công cụ cho đúng việc

Trước khi đóng gói, bạn so nhanh bốn lựa chọn đang có trong tay.

• Câu giao việc thường — việc chỉ làm một lần, không lặp lại
• Projects (đã học ở Bài 6) — ngữ cảnh chung cho cả một dự án dài hơi, như giọng văn của toàn bộ công việc lớp 7A3
• Skill — một quy trình hẹp, lặp lại, có tiêu chí đạt rõ ràng, như chuẩn hoá biên bản họp
• App — quy trình đã quá phức tạp, cần giao diện riêng, không còn gói gọn trong vài bước AI thực hiện được

Chị Hạnh không cần App riêng, dùng Projects cũng không đúng vì phạm vi đó rộng hơn một quy trình, nên Skill là lựa chọn vừa đủ.

Sáu thành phần của một Skill

Một Skill đóng gói tốt cần đủ sáu phần sau, viết một lần và giữ nguyên cho các lần dùng sau.

1. Mục tiêu — Skill này làm đúng việc gì, ví dụ "biến ghi chú họp thô thành biên bản có cấu trúc"
2. Điều kiện gọi — khi nào nên dùng, và quan trọng không kém: khi nào KHÔNG nên dùng, ví dụ không dùng cho họp có nội dung mật
3. Đầu vào — phần bắt buộc (ghi chú họp thô) và phần tuỳ chọn (danh sách người tham dự, nếu có)
4. Các bước — thứ tự xử lý cụ thể, ví dụ đọc ghi chú, gom theo chủ đề, tách riêng quyết định và việc cần làm
5. Đầu ra — hình thức kết quả cuối, ví dụ biên bản một trang với đúng 4 mục
6. Giới hạn — Skill này không tự làm gì, ví dụ không tự suy đoán người phụ trách nếu ghi chú không nêu rõ

Áp cho ví dụ chị Hạnh, Skill "Chuẩn hoá biên bản họp" có thể viết như sau:

Mục tiêu: biến ghi chú họp thô thành biên bản có cấu trúc, dùng cho họp giao ban phòng kinh doanh.
Điều kiện gọi: dùng khi có file ghi chú họp thô cần chuẩn hoá. Không dùng cho họp có nội dung liên quan nhân sự nhạy cảm hoặc số liệu mật.
Đầu vào bắt buộc: file ghi chú họp thô. Đầu vào tuỳ chọn: danh sách người tham dự.
Các bước: đọc hết ghi chú, tách các câu thành hai nhóm quyết định và việc cần làm, với mỗi việc cần làm xác định người phụ trách và hạn nếu ghi chú có nêu.
Đầu ra: biên bản một trang gồm đúng 4 mục Quyết định, Việc cần làm, Người phụ trách, Hạn.
Giới hạn: không tự đoán người phụ trách hoặc hạn nếu ghi chú không nói rõ, để trống và đánh dấu "cần bổ sung".

Từ tuần sau, chị Hạnh chỉ cần gọi Skill này và đưa ghi chú họp mới, không phải gõ lại toàn bộ năm phần như hồi còn dùng Work từ đầu.

Chạy thử hai lần trước khi tin dùng

Viết xong Skill chưa có nghĩa là dùng được ngay. Bạn phải chạy thử ít nhất hai lần, với hai bộ ghi chú họp khác nhau, rồi dùng cùng một checklist để so sánh kết quả. Đây là bước bắt buộc để phát hiện Skill có đang bỏ sót trường hợp nào không, không phải bước làm cho có.

Ví dụ checklist so sánh cho Skill biên bản họp: cả hai lần chạy có đủ 4 mục không, mục "Người phụ trách" có bị bỏ trống dù ghi chú đã nêu rõ tên không, mục "Hạn" có bị Skill tự suy đoán ngày dù ghi chú không ghi ngày không. Sai một tiêu chí ở lần nào, bạn sửa lại phần "các bước" hoặc "giới hạn" rồi chạy thử lại, chưa vội đưa vào dùng thật.

An toàn khi dùng Skill

Nếu bạn cài một Skill người khác chia sẻ hoặc tải từ nguồn ngoài, đọc kỹ cả sáu phần trước khi dùng, đừng chỉ thấy tên nghe hợp lý là bấm dùng ngay. Với dữ liệu nhạy cảm như thông tin công dân hay số liệu nội bộ cơ quan, cán bộ nhà nước cần nhớ nguyên tắc bảo vệ dữ liệu cá nhân theo Nghị định 13/2023, không đưa dữ liệu thật vào Skill khi đang thử nghiệm. Bạn cũng nên biết cách gỡ hoặc tạm vô hiệu hoá một Skill không còn dùng tốt, thường nằm trong mục Settings; nếu chia sẻ Skill trong Workspace cho đồng nghiệp, chỉ chia cho đúng nhóm cần dùng, không mặc định mở cho toàn bộ tổ chức.

Lỗi thường gặp

• Đóng gói một việc chỉ xảy ra một lần thành Skill. Kiểm lại ba điều kiện hẹp, lặp lại, đo được trước khi bỏ công viết Skill.
• Viết Skill thiếu phần "khi nào KHÔNG gọi". Bổ sung rõ để đồng nghiệp dùng chung cũng biết giới hạn, không dùng sai chỗ.
• Tin dùng Skill ngay sau lần chạy thử đầu tiên. Luôn chạy thêm lần thứ hai với dữ liệu khác, so sánh bằng cùng một checklist.
• Chia sẻ Skill cho cả Workspace mà không nghĩ tới phạm vi. Chỉ chia cho nhóm thật sự cần dùng, đặc biệt nếu Skill có đụng tới dữ liệu nội bộ.

Checklist trước khi làm

• Đã kiểm quy trình này đủ hẹp, lặp lại, và đo được trước khi đóng gói thành Skill
• Đã viết đủ sáu thành phần: mục tiêu, điều kiện gọi, đầu vào, các bước, đầu ra, giới hạn
• Đã ghi rõ cả điều kiện KHÔNG nên gọi Skill này
• Đã chạy thử Skill hai lần với hai bộ dữ liệu khác nhau, dùng cùng một checklist so sánh
• Đã thay dữ liệu thật bằng dữ liệu giả lập khi thử nghiệm nếu việc có thông tin nhạy cảm
• Đã biết cách gỡ hoặc vô hiệu hoá Skill này nếu sau này không còn phù hợp

Đóng gói được một Skill tốt, bạn không còn phải gõ lại từ đầu mỗi lần lặp việc, và kết quả cũng ổn định hơn vì đã có sẵn tiêu chí kiểm tra rõ ràng. Bài tiếp theo sẽ đưa bạn đi xa hơn: thiết kế một workflow nhiều bước có điểm duyệt ở giữa, nối nhiều Skill và tác vụ Work lại thành một quy trình lớn hơn.