Chuyển tới nội dung chính

Meta-prompting và thử lỗi skill

Bài trước đã dạy cách đóng gói một prompt tốt thành file SKILL.md, với hai trường bắt buộc name và description. Bài này đi tiếp ba việc: nhờ chính AI viết skill giúp ta, gom nhiều skill thành một bộ công cụ gọn gàng, và quan trọng nhất là thử để skill kích hoạt đúng lúc.

Việc thử quan trọng hơn nó thoạt nghe. Nhiều sinh viên viết xong skill đầu tiên, thấy nó chạy đúng một lần, rồi yên tâm cất đi. Một tuần sau, giữa lúc gấp bài, họ gõ đúng loại yêu cầu mà skill sinh ra để phục vụ, mà skill nằm im. Hoặc tệ hơn, skill bật đúng lúc nhưng chạy sai quy trình, và vì đầu ra trông vẫn gọn gàng nên không ai nhận ra. Skill khác một prompt rời ở chỗ nó tự bật, tức là bạn đã giao cho AI quyền quyết định khi nào dùng nó. Đã giao quyền thì phải kiểm tra xem quyền ấy được dùng ra sao.

Thử ngay: hai thẻ kỹ thuật meta​

Hai kỹ thuật meta của buổi này nằm trong bộ kỹ thuật chung của môn. Bấm vào từng thẻ để xem công thức rút gọn và ví dụ:

Meta-prompting và PE2: nhờ AI tự viết skill​

Viết tay một file SKILL.md cho gọn gàng cũng tốn công. Tin vui là bạn có thể nhờ chính AI làm việc đó. Kỹ thuật để AI sinh hoặc cải thiện một prompt (hay một skill) được gọi là meta-prompting: thay vì dùng prompt để giải một bài toán, ta dùng một prompt để tạo ra một prompt khác.

Meta-prompting là dùng AI để sinh ra hoặc viết lại một prompt, thay vì trực tiếp giải bài toán. Bạn mô tả năng lực mong muốn, AI trả về một prompt hoặc skill có cấu trúc cho năng lực đó. Với chúng ta, mục tiêu khiêm tốn: nhờ AI biến một prompt tốt thành một SKILL.md chỉnh chu.

Bạn là chuyên gia đóng gói skill theo chuẩn SKILL.md.

Dưới đây là một prompt đã chạy tốt của tôi:
<<<
[DÁN PROMPT ĐÃ CHẠY TỐT VÀO ĐÂY]
>>>

Hãy đóng gói nó thành một file SKILL.md hoàn chỉnh:
1. Đặt name ngắn, không dấu, nối bằng gạch.
2. Viết description nêu RÕ làm gì và KHI NÀO dùng, có từ khoá
   tình huống người dùng hay nói.
3. Sắp xếp thân Markdown thành mục: vai trò, đầu vào, quy trình,
   ràng buộc, định dạng đầu ra.
4. Chỉ ra chỗ nào nên thay bằng ô điền [PLACEHOLDER].
5. Đề xuất 1-2 tài nguyên kèm theo nếu cần.

Trước khi viết, nêu ngắn gọn bạn hiểu skill này dùng khi nào,
rồi mới xuất file SKILL.md trong một khối mã.

Sau khi có bản nháp, bạn thường muốn tinh chỉnh thêm một vòng. Đây là lúc dùng ý tưởng PE2, viết đủ là Prompt Engineering a Prompt Engineer: thay vì tự sửa, bạn yêu cầu AI đóng vai một người duyệt prompt khó tính, soi prompt hoặc skill hiện có, chỉ ra điểm yếu rồi đề xuất bản tốt hơn. Nói nôm na, PE2 là meta hoá việc viết prompt: một vòng tự phê và tự sửa do chính AI thực hiện.

Đóng vai kỹ sư prompt khó tính. Dưới đây là một SKILL.md:
<<<
[DÁN SKILL.md HIỆN TẠI VÀO ĐÂY]
>>>

Làm ba việc:
1. Chấm điểm description: nó có nêu rõ KHI NÀO dùng không? Nếu mơ
   hồ, vì sao AI có thể kích hoạt nhầm hoặc bỏ quên skill này?
2. Chỉ ra 3 điểm yếu lớn nhất của thân chỉ dẫn.
3. Xuất lại bản SKILL.md đã sửa, gạch đầu dòng những gì đã đổi.
Vẫn phải đọc lại

Meta-prompting và PE2 giúp đi nhanh, nhưng AI vẫn có thể viết description kêu mà rỗng, hoặc thêm bước thừa. Luôn đọc lại bản skill AI sinh ra, nhất là description, và thử kích hoạt vài lần trước khi tin dùng.

Khi nào meta-prompting giúp được, khi nào không​

Meta-prompting mạnh ở phần hình thức và yếu ở phần nội dung. Nó giỏi việc sắp xếp một mớ chỉ dẫn lộn xộn thành các mục rõ ràng, nghĩ ra từ khoá tình huống mà bạn quên, hay phát hiện một ràng buộc bị nói hai lần theo hai cách mâu thuẫn. Nhưng nó không biết skill của bạn thật sự dùng khi nào, vì chỉ mình bạn biết công việc của mình. Đưa cho nó một mô tả mơ hồ, bạn sẽ nhận về một SKILL.md trông rất chuyên nghiệp mà description vẫn rỗng nghĩa. Nó cũng hay thêm bước cho đầy, vì quy trình bảy bước nghe uy tín hơn ba bước, dù ba bước mới là đúng.

Vì vậy, cách dùng hợp lý là đưa cho AI một prompt đã chạy tốt rồi nhờ đóng gói, chứ đừng đưa một ý tưởng mơ hồ rồi nhờ sáng tác. Bạn giữ phần biết việc, AI lo phần trình bày.

Kết hợp nhiều skill và tổ chức thư mục​

Khi bạn có vài skill, sức mạnh thật sự lộ ra: AI có thể phối hợp chúng. Ví dụ làm đồ án, bạn có thể có một skill giai-thich-loi-bien-dich-c để gỡ lỗi, một skill tom-tat-bai-bao để đọc tài liệu, và một skill viet-bao-cao-do-an để dựng báo cáo. Trong một buổi làm việc, AI lần lượt kích hoạt skill phù hợp cho từng yêu cầu của bạn, mỗi cái mang ra đúng năng lực của nó.

Để AI chọn đúng và không lẫn, mỗi skill nên làm tốt một việc và có description phân biệt rõ với các skill khác. Đừng nhồi mọi thứ vào một skill khổng lồ; chia nhỏ theo việc thì AI khớp chính xác hơn.

Về cách cất giữ, mỗi skill là một thư mục riêng, bên trong có một file SKILL.md và các tài nguyên kèm theo. Các thư mục skill cùng nằm chung dưới một thư mục mẹ (thường tên là skills):

skills/
├── tro-ly-on-thi/
│   ├── SKILL.md
│   ├── rubric-cham.md
│   └── loi-thuong-gap.md
├── giai-thich-loi-bien-dich-c/
│   ├── SKILL.md
│   └── ma-loi-gcc.md
└── viet-bao-cao-do-an/
    ├── SKILL.md
    └── mau-bao-cao.md
Ghi nhớ

Mỗi skill làm tốt một việc, có description phân biệt rõ, sống trong thư mục riêng cùng tài nguyên. Nhiều skill gom dưới một thư mục mẹ skills/ thành bộ công cụ cá nhân: AI tự lấy đúng cái cho từng yêu cầu.

Thử và gỡ lỗi skill​

Đóng gói xong một SKILL.md chưa phải là hết việc. Một skill chỉ thật sự hữu ích nếu nó được kích hoạt đúng lúc: bật lên khi tình huống cần, và nằm yên khi tình huống không liên quan. Mà như đã nói ở bài trước, việc kích hoạt hoàn toàn dựa vào trường description. Vì vậy, viết xong skill thì phải thử, đúng như ta thử chạy một đoạn code trước khi tin nó chạy đúng.

Cách thử rất đơn giản và không cần công cụ gì đặc biệt. Bạn chuẩn bị vài tình huống đầu vào mẫu, lần lượt đưa cho AI, rồi quan sát xem skill có được gọi ra hay không. Quan trọng là phải thử cả hai phía:

  • Tình huống nên gọi. Đưa vài đầu vào đúng kiểu mà skill sinh ra để phục vụ, rồi kiểm tra AI có kích hoạt và chạy theo đúng quy trình trong thân không.
  • Tình huống không nên gọi. Đưa vài đầu vào gần giống nhưng thật ra nằm ngoài phạm vi skill, để chắc rằng nó không kích hoạt bừa và lấn sang việc của skill khác.

Khi thử, bạn thường gặp một trong ba tình trạng, và cả ba đều truy ngược về description:

  • Kích hoạt đúng. Đầu vào nên gọi thì skill bật, đầu vào không nên gọi thì nó nằm im. Đây là đích cần đạt.
  • Kích hoạt nhầm. Skill bật lên cả khi không nên, vì description quá rộng nên khớp với mọi thứ. Cách sửa: thu hẹp lại, nêu rõ điều kiện và loại đầu vào mà skill phục vụ.
  • Bỏ sót không kích hoạt. Đáng lẽ phải bật mà skill nằm im, vì description quá hẹp hoặc mơ hồ nên AI không nhận ra. Cách sửa: bổ sung từ khoá tình huống và một ví dụ đầu vào tiêu biểu.
Mẹo viết description để kích hoạt đúng

Nêu rõ khi nào dùng cộng dấu hiệu nhận biết đầu vào. Tức là vừa nói tình huống ("khi sinh viên dán lỗi biên dịch"), vừa nói dấu hiệu cụ thể của đầu vào ("thông báo có chữ error: của gcc hoặc clang"). Hai thứ này cho AI căn cứ chắc chắn để khớp.

Hãy thử với skill giai-thich-loi-bien-dich-c. Ta chuẩn bị hai đầu vào, một cái nên gọi và một cái không nên gọi.

Đầu vào A (nên gọi). Sinh viên dán vào một thông báo lỗi của trình biên dịch, có chữ error: và dòng số. Đúng dấu hiệu đầu vào mà description nêu, nên skill nên kích hoạt và chạy quy trình giải thích lỗi.

Đầu vào B (không nên gọi). Sinh viên hỏi một câu lý thuyết chung như "con trỏ trong C là gì và khi nào nên dùng". Không có thông báo lỗi nào để giải thích, nên skill này không nên kích hoạt; nếu nó vẫn bật lên thì description đang quá rộng và cần thu hẹp.

Nếu đầu vào B làm skill kích hoạt nhầm, cách sửa là thêm vào description một điều kiện rõ hơn, chẳng hạn "chỉ dùng khi có thông báo lỗi cụ thể của trình biên dịch, không dùng cho câu hỏi lý thuyết chung". Ngược lại, nếu đầu vào A không kích hoạt được skill, hãy bổ sung các từ khoá đầu vào hay gặp (error:, gcc, clang, "không build được") vào description. Chỉ vài vòng thử và chỉnh như vậy là đủ để skill bật đúng lúc. Đây cũng là tinh thần kiểm chứng đầu ra mà ta sẽ nói kỹ ở buổi 5.

Hỏng ở nhãn hay hỏng ở ruột​

Không phải lỗi nào cũng nằm ở description. Khi kết quả không như ý, hãy tách đôi câu hỏi trước khi sửa bất cứ thứ gì. Skill có bật không? Nếu không bật, lỗi ở nhãn ngoài hộp, tức là description. Nếu có bật mà đầu ra vẫn sai, lỗi ở ruột, tức là thân chỉ dẫn: quy trình thiếu bước, ràng buộc mâu thuẫn, hoặc không nói rõ định dạng. Hai chỗ hỏng này cần hai cách sửa khác hẳn nhau, nên đoán nhầm chỗ là loay hoay cả buổi mà không nhúc nhích. Cách tách nhanh nhất là bảo AI nói ra nó đang dùng skill nào trước khi trả lời: nếu nó không nhắc tới skill của bạn, hãy nghi description trước đã. Nhưng đừng chỉ tin lời AI tự khai, vì nó có thể nói là đã dùng trong khi thực ra không. Chắc ăn hơn thì cài sẵn trong thân chỉ dẫn một dấu hiệu chỉ skill đó mới có, chẳng hạn một dòng tiêu đề cố định ở đầu đầu ra: thấy dấu hiệu là skill đã bật thật, không thấy là nó chưa bật.

Chu trình sửa gồm bốn bước. Giả sử skill viet-bao-cao-do-an bật đúng nhưng đầu ra lần nào cũng thiếu mục tài liệu tham khảo. Một, tái hiện lỗi trên đúng một đầu vào mẫu. Hai, đoán một nguyên nhân duy nhất, ở đây là thân chỉ dẫn không hề liệt kê mục đó. Ba, sửa đúng một chỗ. Bốn, chạy lại chính đầu vào cũ. Nếu vẫn thiếu thì quay lại bước hai với giả thuyết khác. Quy tắc sống còn: mỗi vòng chỉ đổi một thứ, vì đổi ba thứ cùng lúc thì dù hết lỗi bạn cũng không biết thứ nào đã cứu mình.

Ba lỗi thường gặp khi gỡ skill
  • Chỉ thử ca thuận. Đưa vài đầu vào mà skill phải bật, thấy nó bật, rồi kết luận là xong. Không thử ca nghịch thì bạn không bao giờ phát hiện skill đang bật bừa.
  • Sửa nhiều chỗ một lúc. Đổi cả description lẫn thân chỉ dẫn trong cùng một vòng thì bạn mất khả năng quy kết: không biết thay đổi nào có tác dụng.
  • Nhồi chữ vào thân khi lỗi nằm ở nhãn. Thân dài thêm không giúp skill bật đúng lúc, vì AI chỉ đọc description để quyết định có mở thân ra hay không.

Biết khi nào dừng sửa​

Vòng thử và sửa có thể kéo dài vô tận nếu bạn không đặt trước tiêu chí dừng. Đích không phải một skill hoàn hảo, mà là một skill đủ ổn định, nên hãy chốt một mốc cụ thể trước khi bắt đầu: skill bật đúng trên toàn bộ ca thuận và nằm im trên toàn bộ ca nghịch trong bộ thử của bạn, lặp lại hai lần liên tiếp mà không lộ lỗi mới. Đạt mốc đó thì dừng, đừng sửa tiếp cho đẹp. Sửa quá tay có cái giá riêng: mỗi lần thu hẹp description để chặn một ca nghịch, bạn có nguy cơ vô tình chặn luôn một ca thuận gần đó, thành ra vá chỗ này thủng chỗ kia. Vì vậy sau mỗi lần sửa, hãy chạy lại cả bộ thử chứ không riêng ca vừa hỏng, để chắc rằng bản vá không kéo lùi những ca đang chạy đúng.

Điểm tự tin không phải thước đo

Đừng kết thúc vòng lặp bằng cách hỏi mô hình "tự chấm skill này đã tốt chưa, cho điểm 0 đến 100". Điểm tự tin mô hình đưa ra gần như không tương quan với mức đúng thật: nó có thể chấm chín mươi điểm cho một đầu ra thiếu hẳn một mục, chỉ vì đầu ra trông gọn gàng và trôi chảy. Con số tự chấm ấy tạo cảm giác an tâm giả. Tiêu chí dừng đáng tin phải quan sát được từ bên ngoài: skill có bật đúng ca không, đầu ra có đủ các mục bạn liệt kê không, có dấu hiệu cố định bạn cài trong thân không. Hãy đếm những thứ kiểm được đó, đừng đếm lời mô hình tự khen.

Bài tập​

Bài 1. Chữa một description hỏng

Đề. Một skill có description là "Trợ lý học tập mạnh mẽ, giúp sinh viên học tốt hơn". Nó bật lên với gần như mọi câu hỏi. Vì sao, và sửa thế nào?

Lời giải. Kích hoạt nhầm do mô tả quá rộng: không nêu việc cụ thể, không nêu dấu hiệu đầu vào, nên khớp với mọi thứ. Bản sửa phải nói rõ làm gì, khi nào dùng, và cả điều kiện loại trừ: "Lập kế hoạch ôn thi cuối kỳ từ một đề cương môn học. Dùng khi người dùng dán đề cương hoặc danh sách chương và hỏi nên ôn phần nào trước. Không dùng cho câu hỏi kiến thức lẻ."

Bài 2. Khoanh vùng nguyên nhân

Đề. Skill tom-tat-bai-bao bật đúng lúc, nhưng bản tóm tắt lần nào cũng dài gấp ba mức bạn muốn. Hỏng ở nhãn hay ở ruột, và sửa ở đâu?

Lời giải. Skill đã bật, nên nhãn không có lỗi. Hỏng ở ruột: thân chỉ dẫn thiếu ràng buộc độ dài. Sửa bằng một giới hạn cụ thể và kiểm được, ví dụ mỗi mục tối đa ba câu, thay vì viết chung chung là "tóm tắt ngắn gọn". Và nhớ chỉ đổi đúng chỗ đó rồi chạy lại cùng bài báo cũ.

Bài 3. Đặt tiêu chí dừng

Đề. Bạn đang chỉnh skill giai-thich-loi-bien-dich-c và cứ sửa mãi không thấy dừng. Hãy đặt một tiêu chí dừng cụ thể, và nói vì sao không nên lấy câu "nhờ mô hình tự chấm điểm từ 0 đến 100" làm tiêu chí.

Lời giải. Tiêu chí dừng nên quan sát được từ bên ngoài, ví dụ: skill bật trên cả ba ca thuận (mỗi ca có error: của gcc hoặc clang) và nằm im trên cả ba ca nghịch (câu hỏi lý thuyết không kèm lỗi), lặp lại hai lần liên tiếp mà không lộ lỗi mới. Không dùng điểm tự chấm, vì điểm tự tin của mô hình không tương quan với mức đúng: nó có thể chấm cao cho một lần giải thích đã bỏ sót bước sửa, chỉ vì câu trả lời trôi chảy.

Tự kiểm Buổi 4​

Tự kiểm Buổi 40/5 đúngchưa trả lời
  1. 1Hai trường nào bắt buộc trong frontmatter của một file SKILL.md?
  2. 2AI dựa vào đâu để tự quyết định có kích hoạt một skill hay không?
  3. 3Một description chỉ viết chung chung kiểu "skill rất mạnh giúp học tốt hơn" thường gây hậu quả gì?
  4. 4Meta-prompting nghĩa là gì?
  5. 5Khi thử mà một skill bật lên cả với đầu vào không liên quan (kích hoạt nhầm), cách sửa hợp lý nhất là?

Tóm tắt​

Meta-prompting nhờ AI viết bản nháp skill, PE2 nhờ AI tự soi và sửa bản nháp đó, nhưng phần biết việc vẫn là của bạn. Mỗi skill làm một việc, sống trong thư mục riêng cùng tài nguyên, và bật lên nhờ đúng một trường description. Viết xong thì phải thử cả ca thuận lẫn ca nghịch, tách rõ hỏng ở nhãn (skill không bật) với hỏng ở ruột (bật mà chạy sai), rồi sửa từng thứ một cho tới khi hành vi ổn định.