Từ prompt tới skill
Bốn buổi trước, chúng ta học cách hỏi AI cho khéo: từ bốn thành phần cơ bản, tới suy luận từng bước, rồi tới những prompt có cấu trúc chuyên nghiệp như trợ lý ôn thi cuối kỳ ở buổi 3. Mỗi lần như vậy, bạn gõ ra một đoạn văn bản dài, AI trả lời tốt, bạn vui mừng, rồi đóng cửa sổ chat. Hôm sau cần lại đúng năng lực đó, bạn phải nhớ ra mình đã viết gì, mò lại lịch sử chat, hoặc gõ lại từ đầu. Buổi này giải quyết đúng nỗi khổ đó: làm sao biến một prompt tốt thành một thứ dùng đi dùng lại được, chia sẻ được cho bạn cùng nhóm, và để AI tự biết khi nào nên mang ra dùng. Thứ đó gọi là skill.
Vấn đề của prompt rời rạc
Hãy hình dung bạn đã mất nửa buổi tối ở buổi 3 để mài giũa một prompt trợ lý ôn thi: có vai trò, có quy trình ra đề, có yêu cầu chấm và giải thích đáp án. Nó chạy rất tốt. Nhưng prompt ấy bây giờ đang ở đâu? Nó nằm lẫn trong một cửa sổ chat cũ, giữa hàng chục đoạn hội thoại khác. Một tuần sau, khi ôn môn khác, bạn muốn dùng lại nhưng không tìm ra, nên đành gõ vội một phiên bản rút gọn kém hơn hẳn.
Prompt giỏi mà chỉ sống trong một cửa sổ chat thì như công thức nấu ăn ngon nhưng không ghi lại. Nấu xong là quên. Lần sau làm lại không còn đúng vị. Người khác cũng không nấu lại được.
Khi gom lại, prompt rời rạc gặp bốn vấn đề lặp đi lặp lại:
- Khó tìm lại. Prompt tốt trộn lẫn trong lịch sử chat, không có tên, không có chỗ cố định để tra.
- Khó tái dùng. Mỗi lần dùng phải sao chép, dán, sửa tay vài chỗ; dễ quên một ràng buộc quan trọng.
- Khó chia sẻ. Muốn đưa cho bạn cùng nhóm thì gửi qua tin nhắn một khối chữ dài, người nhận không biết nó dùng để làm gì và khi nào nên dùng.
- Khó kèm tài nguyên. Prompt hay đi cùng vài thứ phụ trợ: một bảng tiêu chí chấm, một danh sách lỗi thường gặp, một mẫu bảng kết quả. Dán tất cả vào một đoạn chat thì rối, mà tách ra thì lạc mất.
Lời giải tự nhiên: đừng để prompt là một đoạn chữ vứt trong chat, hãy đóng gói nó thành một đơn vị có tên, có mô tả, có chỗ chứa cố định và mang theo được cả tài nguyên. Đơn vị đóng gói đó là skill.
Khi nào một prompt đáng đóng gói thành skill
Trước khi học cách làm skill, phải trả lời một câu hỏi dễ bị bỏ qua: có phải prompt nào cũng nên thành skill không. Câu trả lời là không. Đóng gói tốn công: đặt tên, viết mô tả kích hoạt cho chuẩn, sắp xếp thân prompt thành các mục, tách tài nguyên ra file riêng, rồi thử xem nó có bật đúng lúc không. Công sức ấy chỉ hoàn vốn khi bạn còn dùng lại nhiều lần về sau. Một câu hỏi bạn chỉ hỏi đúng một lần trong đời thì gõ thẳng vào chat là xong.
Có bốn dấu hiệu cho thấy một prompt đã chín để thành skill.
Bạn đã gõ lại nó lần thứ hai. Đây là tín hiệu rõ nhất và cũng dễ áp dụng nhất: một việc đã lặp hai lần thì xác suất rất cao nó sẽ lặp lần thứ ba.
Prompt đã chạy ổn định qua vài lần thử. Skill dùng để cố định một thứ đã tốt. Đóng gói sớm quá thì bạn chỉ đang bảo quản một lỗi cho nó sống lâu hơn.
Có quy trình và ràng buộc dễ quên. Prompt một câu thì nhớ lại không khó, đóng gói chẳng lợi gì. Nhưng khi nó có bốn bước quy trình, ba ràng buộc, một mẫu định dạng, thì mỗi lần gõ lại bạn sẽ rơi rụng vài thứ và chất lượng tụt dần mà không nhận ra.
Có tài nguyên đi kèm: bảng tiêu chí chấm, danh sách lỗi thường gặp, biểu mẫu. Những thứ này không sống nổi trong lịch sử chat, chúng cần một thư mục.
Ngược lại, không nên đóng gói việc chỉ làm một lần, việc mà mỗi lần làm lại đổi cách hoàn toàn (chưa có quy trình ổn định để cố định), và việc đơn giản tới mức viết mô tả kích hoạt còn tốn hơn gõ lại prompt.
Lần đầu gặp một việc, cứ gõ prompt tay và tập trung làm cho xong. Đến lần thứ hai, khi bạn thấy mình đang mò lại lịch sử chat để tìm prompt cũ, hãy dừng lại và đóng gói ngay lúc đó. Đó là thời điểm bạn còn nhớ rõ nhất prompt cần có gì, và cũng là lúc bạn có bằng chứng nó đáng được giữ.
Skill là gì
Một skill là một năng lực được đóng gói: một thư mục gọn gồm bốn phần.
- Tên (
name): định danh ngắn, ví dụtro-ly-on-thi. - Mô tả khi nào dùng (
description): một câu nêu skill làm gì và dùng trong tình huống nào. - Chỉ dẫn (thân Markdown): prompt tốt đã mài giũa, viết lại mạch lạc.
- Tài nguyên kèm theo (tuỳ chọn): file phụ trợ như bảng tiêu chí, biểu mẫu, đặt cùng thư mục.
Cách dễ nhớ nhất: một prompt tốt trả lời câu hỏi làm việc này như thế nào. Một skill bọc thêm hai câu hỏi nữa: năng lực này tên là gì và khi nào thì lôi nó ra dùng. Chính hai câu hỏi thêm này biến một đoạn chữ dùng một lần thành một công cụ dùng nhiều lần.
Prompt là nội dung của một lần hỏi. Skill là cái hộp đặt tên cho nội dung đó, dán nhãn khi nào dùng, kèm vài dụng cụ phụ. Có hộp rồi thì cất gọn, tìm nhanh, chia sẻ được, và để AI tự lấy đúng lúc.
Chuẩn SKILL.md
Để các skill thống nhất một khuôn và để AI đọc được, người ta quy ước mỗi skill là một
thư mục có một file tên SKILL.md. File này gồm hai phần xếp trên dưới:
- Phần đầu (frontmatter): một khối YAML nằm giữa hai dòng ba gạch nối. Tối thiểu
có hai trường bắt buộc là
namevàdescription. Đây là phần AI đọc trước để quyết định có dùng skill hay không. - Thân (body): viết bằng Markdown bình thường, chứa toàn bộ chỉ dẫn chi tiết. Đây chính là chỗ đặt prompt tốt của bạn, trình bày thành các mục cho dễ theo.
Quan trọng về tên trường: name nên viết thường, không dấu, nối các từ bằng gạch nối
(slug ASCII, ví dụ tro-ly-on-thi), vì nó cũng thường là tên thư mục chứa skill.
description là trường có sức nặng nhất, ta sẽ bàn kỹ ở mục sau.
Khuôn tối thiểu của một file SKILL.md trông như sau:
---
name: ten-ngan-khong-dau
description: làm gì + khi nào dùng
---
# Tiêu đề skill
(thân Markdown: vai trò, quy trình, ràng buộc, định dạng, tài nguyên)
Ví dụ hoàn chỉnh: đóng gói trợ lý ôn thi
Nhớ lại buổi 3, ta đã dựng một prompt trợ lý ôn thi cuối kỳ theo Prompt Canvas: có vai
trò gia sư, có quy trình ra đề và chấm, có ràng buộc bám sát đề cương. Bây giờ ta đóng
gói đúng năng lực đó thành một file SKILL.md hoàn chỉnh.
---
name: tro-ly-on-thi
description: >
Tạo bộ câu hỏi ôn tập và chấm bài theo đề cương môn học.
Dùng khi sinh viên dán vào đề cương hoặc danh sách chủ đề và muốn
luyện tập trước kỳ thi, cần đề mẫu kèm đáp án và giải thích.
---
# Trợ lý ôn thi cuối kỳ
## Vai trò
Bạn là gia sư kiên nhẫn, ra đề bám sát đề cương, giải thích rõ ràng
ở mức độ sinh viên năm 1 đến năm 3, không đánh đố.
## Đầu vào cần có
- Đề cương môn học hoặc danh sách chủ đề (sinh viên dán vào).
- Số câu hỏi mong muốn và mức độ khó (dễ / trung bình / khó).
## Quy trình
1. Đọc đề cương, liệt kê các chủ đề chính trước khi ra đề.
2. Với mỗi chủ đề, sinh câu hỏi theo mức độ đã chọn.
3. Trộn các dạng: trắc nghiệm, điền khuyết, tự luận ngắn.
4. Cuối mỗi câu, kèm đáp án và một đoạn giải thích ngắn gọn.
## Ràng buộc
- Chỉ ra câu trong phạm vi đề cương, không thêm chủ đề lạ.
- Nếu đề cương không nêu, hỏi lại thay vì tự đoán.
- Không tiết lộ đáp án trước khi sinh viên yêu cầu "xem đáp án".
## Định dạng đầu ra
Mỗi câu đánh số, theo mẫu:
**Câu N (chủ đề, mức độ):** nội dung câu hỏi
> Đáp án: ...
> Giải thích: ...
## Tài nguyên kèm theo
- `rubric-cham.md`: bảng tiêu chí chấm câu tự luận theo thang 10.
- `loi-thuong-gap.md`: danh sách lỗi sinh viên hay mắc để nhắc nhở.
Hãy để ý: phần thân không có gì xa lạ, nó chính là prompt buổi 3 được sắp xếp lại thành
mục rõ ràng. Cái mới nằm ở phần frontmatter đầu file. Nhờ chúng, năng lực này giờ có
tên tro-ly-on-thi, có lời tự giới thiệu về việc nó làm gì và khi nào dùng, và có chỗ
trỏ tới hai tài nguyên đi kèm.
Thân SKILL.md bạn có thể viết tiếng Việt có dấu thoải mái. Chỉ riêng name nên giữ
không dấu, viết thường, nối bằng gạch (slug ASCII) vì nó thường trùng tên thư mục skill.
Cơ chế description quyết định kích hoạt
Đây là ý quan trọng nhất của buổi học, và cũng là điểm khiến skill khác hẳn một đoạn prompt thường.
Khi bạn có nhiều skill cùng nằm trong một thư mục, AI không nạp toàn bộ chỉ dẫn của mọi
skill vào đầu cùng lúc, vì như vậy vừa tốn vừa rối. Thay vào đó, AI chỉ đọc trước phần
description của từng skill, giống như đọc nhãn dán ngoài hộp. Khi bạn đặt một yêu cầu,
AI so yêu cầu của bạn với các nhãn đó để tự quyết định: tình huống này khớp với skill nào
thì kích hoạt skill ấy, tức mới mở hộp ra đọc phần chỉ dẫn chi tiết bên trong.
Mô hình đọc description để tự quyết định có dùng skill hay không. Vậy nên đừng dùng
chỗ này để khoe skill hay tới đâu. Hãy nêu rõ điều kiện: skill làm gì và khi nào dùng.
Hệ quả rất thực tế: một description viết lan man hoặc chỉ nói chung chung sẽ khiến AI
hoặc bỏ quên skill khi đáng lẽ phải dùng, hoặc lôi nó ra nhầm lúc. Hãy so sánh hai cách
viết cho cùng một skill.
Bản yếu:
description: Một skill rất mạnh giúp bạn học tốt hơn và đạt điểm cao.
Nghe kêu nhưng vô dụng cho việc quyết định: AI không biết tình huống nào thì khớp, vì câu này đúng với cả chục skill khác nhau.
Bản mạnh:
description: Tạo bộ câu hỏi ôn tập và chấm bài theo đề cương môn học. Dùng khi sinh viên dán vào đề cương hoặc danh sách chủ đề và muốn luyện tập trước kỳ thi.
Nêu rõ làm gì (ra đề và chấm theo đề cương) và khi nào (khi có đề cương và muốn luyện trước thi). AI khớp được ngay.
descriptionLàm gì cộng khi nào dùng, kèm vài từ khoá tình huống người dùng hay nói (như "đề cương", "ôn thi", "luyện tập"). Viết một tới ba câu, đủ phân biệt với skill khác.
Hình dung một sinh viên gõ: "giúp mình ôn thi môn cấu trúc dữ liệu, đây là đề cương". Với mô tả mạnh, AI thấy ngay "ôn thi" và "đề cương" khớp, nên kích hoạt đúng skill. Với mô tả yếu, AI không có gì để bám, dễ trả lời chung chung và bỏ quên quy trình ra đề bạn đã viết.
Phạm vi mô tả: quá rộng thì bật nhầm, quá hẹp thì không bật
Viết description là bài toán căn chỉnh phạm vi, và nó hỏng ở cả hai đầu.
Mô tả quá rộng thì skill bật cả những lúc không nên:
description: Hỗ trợ sinh viên trong mọi việc học tập và làm bài.
Câu này khớp với gần như mọi yêu cầu bạn gõ. Nhờ dịch một đoạn tiếng Anh hay nhờ sửa một lỗi biên dịch, AI cũng lôi skill ôn thi ra và cố ép việc của bạn vào khuôn ra đề trắc nghiệm. Tệ hơn, nhiều skill cùng mô tả rộng như vậy sẽ giẫm chân nhau. Triệu chứng: skill bật ở những lúc bạn không hề mong, đầu ra có mùi lạc đề.
Mô tả quá hẹp thì skill gần như không bao giờ bật:
description: Ra 10 câu trắc nghiệm mức khó cho chương 3 môn Cấu trúc dữ liệu tại lớp 22IT1.
Mô tả này chỉ khớp khi bạn gõ gần đúng từng chữ ấy. Hỏi "cho mình vài câu ôn chương cây nhị phân" là nó nằm im, dù đây đúng là việc của nó. Triệu chứng: bạn biết mình có skill phù hợp mà AI cứ trả lời tay không, phải gọi đích danh tên skill nó mới chịu dùng.
Điểm cân bằng: mô tả nêu đúng loại việc cộng điều kiện nhận biết, dùng chính những từ
người dùng sẽ gõ, chứ không nêu chi tiết của một lần dùng cụ thể. Cách kiểm nhanh gồm hai câu
hỏi. Có việc nào không thuộc skill này mà vẫn khớp mô tả không? Có thì mô tả đang quá rộng.
Có cách diễn đạt tự nhiên nào của đúng việc này mà không khớp mô tả không? Có thì mô tả
đang quá hẹp. Sửa tới khi cả hai câu đều trả lời là không. Mẹo phụ trợ: chèn vài từ khoá
tình huống người dùng hay gõ và vài dấu hiệu trong dữ liệu vào, ví dụ skill giải thích
lỗi biên dịch nói rõ nó dùng khi đầu vào chứa dòng error: hoặc warning:.
Thử xem skill có thật sự bật hay không
Viết xong mô tả, phải thử, bằng hai nhóm câu. Nhóm nên bật: năm cách diễn đạt tự nhiên khác nhau của cùng việc đó, viết như một sinh viên thật sẽ gõ chứ không mượn từ ngữ trong mô tả. Nhóm không nên bật: năm yêu cầu gần gần nhưng thuộc việc khác, để xem skill có lấn sân không. Một mô tả tốt phải bật hết nhóm một và im lặng với cả nhóm hai.
Khi bạn hỏi "bạn có dùng skill tro-ly-on-thi không?", câu trả lời "có, tôi đã dùng skill
đó" không phải là bằng chứng. Mô hình đang sinh ra một câu văn nghe hợp lý, chứ không tra
cứu nhật ký của chính nó. Nó có thể khẳng định đã dùng skill trong khi thực tế không hề nạp,
và ngược lại.
Bằng chứng thật phải đến từ bên ngoài lời nói của mô hình: dấu hiệu kích hoạt do chính công cụ hiển thị, hoặc dấu vết đặc trưng trong đầu ra mà chỉ skill của bạn mới tạo ra. Một mẹo rất thực dụng là cài một dấu vân tay vào thân skill, ví dụ bắt nó luôn mở đầu bằng một dòng tiêu đề đặc thù hoặc luôn theo đúng một mẫu định dạng lạ. Thấy dấu vân tay đó trong đầu ra thì bạn biết skill đã bật; không thấy thì nó chưa bật, bất kể mô hình nói gì.
Skill so với prompt dán tay: được gì, đánh đổi gì
Skill không phải lúc nào cũng thắng, nó là một đánh đổi.
Cái được: tính bền (prompt dán tay chết theo cửa sổ chat, skill nằm trong một thư mục có
tên, tìm lại được sau ba tháng); tính chia sẻ (gửi cả thư mục cho bạn cùng nhóm, người
nhận đọc description là biết nó làm gì và khi nào dùng, thay vì nhận một khối chữ không
nhãn); tự kích hoạt (bạn không phải nhớ ra mình có nó).
Cái mất cũng thật: chi phí thiết lập ban đầu, không bao giờ hoàn vốn với việc dùng một lần; độ trễ khi sửa, vì đổi một chi tiết cho lần dùng đặc biệt có thể vô tình phá vỡ những lần dùng khác; và rủi ro kích hoạt sai, khi một mô tả rộng quá khiến skill chen vào việc không phải của nó, gây phiền hơn là không có.
Nguyên tắc kết hợp: skill giữ phần bất biến, chat giữ phần của lần này. Quy trình, ràng buộc, định dạng đầu ra là thứ lặp lại nên cho vào skill. Tên môn, số câu, dữ liệu cụ thể là thứ đổi mỗi lần nên gõ vào chat. Nếu bạn thấy mình phải sửa file skill mỗi lần dùng, tức là bạn đã nhét phần khả biến vào nhầm chỗ.
Quản lý phiên bản skill
Skill không đứng yên. Dùng vài lần bạn sẽ thấy mô tả bật nhầm, quy trình thiếu một bước, định dạng chưa vừa ý. Sửa là bình thường, nhưng sửa bừa thì hôm nay tốt lên mà tuần sau tệ đi mà không hiểu vì sao. Vài thói quen đơn giản, không cần công cụ phức tạp.
Đặt skill vào git. Mỗi lần sửa là một commit ghi rõ đổi gì và vì sao; bản mới tệ hơn thì
quay lại được. Không dùng git thì tối thiểu giữ một mục Lịch sử thay đổi ngay trong thân
SKILL.md, ghi ngày và nội dung sửa.
Chỉ đổi một thứ mỗi lần. Vừa sửa description, vừa thêm hai bước quy trình, vừa đổi định
dạng, rồi thấy kết quả khác đi thì bạn không biết thứ nào gây ra. Sửa một thứ, thử lại bằng
bộ câu đã chuẩn bị ở phần trên, rồi mới đi tiếp.
Giữ lại bộ câu thử. Hai nhóm câu nên bật và không nên bật chính là bộ kiểm thử của skill. Chạy lại toàn bộ sau mỗi lần sửa, để không rơi vào cảnh sửa cho việc A tốt lên thì việc B hỏng đi mà bạn không hay.
Đừng để skill phình to. Gặp tình huống lạ, ta hay nhét thêm một ràng buộc vào skill. Làm mãi thì thân skill dài ra, mâu thuẫn nội bộ xuất hiện, mô tả phải nới rộng để bao hết. Khi một skill bắt đầu làm ba việc, hãy tách nó thành ba skill, mỗi cái một mô tả hẹp và rõ.
Vòng đời: từ prompt tốt tới skill tái dùng
Bạn không viết skill từ con số không. Cách làm tự nhiên là dùng một prompt đã chạy tốt rồi nâng cấp nó lên thành skill. Vòng đời gồm bốn bước, lặp lại mỗi khi bạn thấy mình hỏi AI cùng một kiểu việc lần thứ hai.
- Prompt tốt. Bạn đã có một prompt chạy ổn (ví dụ trợ lý ôn thi buổi 3). Đừng đóng gói vội cái chưa chạy thử.
- Trích thành mẫu. Thay những chi tiết của một lần cụ thể (tên môn, số câu) bằng ô
điền dạng
[MON_HOC],[SO_CAU]. Mẫu là prompt đã bỏ phần riêng của một lần dùng. - Đóng gói
SKILL.md. Thêm frontmatter vớinamevàdescription, sắp xếp thân thành mục, và tách các tài nguyên phụ ra file riêng cùng thư mục. - Tái dùng. Đặt thư mục skill vào chỗ AI đọc được. Từ nay khi tình huống khớp, AI tự kích hoạt; bạn chỉ cần đưa dữ liệu của lần này.
Dùng vài lần rồi quay lại mài giũa description và chỉ dẫn cho sắc hơn: vòng đời này lặp
lại chứ không dừng ở lần đóng gói đầu tiên.
- Đóng gói một prompt chưa chạy thử. Bạn chỉ đang bảo quản một lỗi cho nó sống lâu hơn.
- Viết
descriptionđể khoe thay vì nêu điều kiện. "Một skill rất mạnh" không giúp máy quyết định gì; "dùng khi sinh viên dán đề cương và muốn luyện thi" thì có. - Nhét phần khả biến vào skill. Tên môn, số câu, dữ liệu của lần này phải nằm ở chat, chứ không nằm trong file skill.
- Một skill ôm ba việc. Mô tả buộc phải nới rộng để bao hết, và rồi nó bật nhầm khắp nơi. Hãy tách ra.
- Tin lời tự khai của mô hình rằng nó đã dùng skill. Chỉ dấu vết trong đầu ra hoặc chỉ báo của công cụ mới là bằng chứng.
- Sửa nhiều thứ cùng lúc rồi không biết cái nào có tác dụng. Mỗi lần một thay đổi, thử lại, rồi mới đi tiếp.
Luyện tập
Bài tập 1: chữa một description bật nhầm
Đề bài. Một bạn làm skill tóm tắt bài báo khoa học với mô tả sau. Triệu chứng bạn ấy gặp: skill bật cả khi bạn ấy chỉ nhờ dịch một đoạn tiếng Anh, cả khi nhờ sửa lỗi chính tả trong báo cáo, và đầu ra lần nào cũng bị ép về khuôn tóm tắt. Hãy chẩn đoán và viết lại.
description: Skill hỗ trợ đọc và xử lý văn bản học thuật cho sinh viên.
Lời giải. Chẩn đoán: mô tả quá rộng. Cụm "xử lý văn bản học thuật" bao trùm cả dịch, cả sửa chính tả, cả tóm tắt, nên mọi yêu cầu dính tới một đoạn văn học thuật đều khớp, đúng như triệu chứng. Bản viết lại thu hẹp về một loại việc, nêu điều kiện nhận biết, và loại trừ tường minh:
description: >
Tóm tắt một bài báo khoa học thành bản cô đọng theo nhiều vòng
tăng dần mật độ thông tin, giữ đúng tên phương pháp và số liệu.
Dùng khi người dùng dán vào abstract, phần kết luận hoặc toàn văn
một bài báo và yêu cầu tóm tắt, rút gọn, hoặc viết phần tổng quan
tài liệu. Không dùng cho việc dịch thuật hay sửa lỗi chính tả.
Cách kiểm: câu "dịch giúp mình đoạn này" không còn khớp (đã loại trừ), còn câu "tóm tắt bài báo này giúp mình để viết related work" thì khớp rõ. Hai đầu phạm vi đều đã được chặn.
Bài tập 2: chữa một description không bao giờ bật
Đề bài. Một bạn làm skill giải thích lỗi biên dịch C với mô tả dưới đây. Triệu chứng: khi bạn ấy dán một traceback rồi gõ "sao nó lỗi vậy", skill nằm im, phải gọi đích danh tên skill nó mới chạy. Hãy chẩn đoán và viết lại.
description: Giải thích lỗi undefined reference khi biên dịch bằng gcc 11 trên Ubuntu cho bài tập tuần 5 môn Kỹ thuật lập trình.
Lời giải. Chẩn đoán: mô tả quá hẹp. Nó khoá vào một thông điệp lỗi cụ thể (undefined reference), một trình biên dịch, một hệ điều hành, một tuần học, một môn học. Sinh viên gõ
"sao nó lỗi vậy" kèm một lỗi khác thì không có gì khớp, đúng như triệu chứng: skill nằm im,
phải gọi tên mới bật. Bản viết lại nâng lên đúng loại việc và bổ sung dấu hiệu nhận biết
trong dữ liệu vào:
description: >
Giải thích nguyên nhân lỗi biên dịch C/C++ và đề xuất bản sửa
tối thiểu. Dùng khi người dùng dán vào thông báo của trình biên
dịch, thường chứa nhãn "error:" hoặc "warning:", và hỏi vì sao
lỗi hoặc cách sửa. Áp dụng cho mọi loại lỗi biên dịch C/C++, không
giới hạn ở một bài tập hay một trình biên dịch cụ thể.
Bây giờ dấu hiệu error: trong dữ liệu dán vào đủ để máy khớp, dù người dùng chỉ gõ đúng bốn
chữ "sao nó lỗi vậy".
Câu hỏi tự kiểm
- 1Vì sao `description` là trường có sức nặng nhất của một skill?
- 2Một `description` quá rộng, kiểu "hỗ trợ mọi việc học tập của sinh viên", gây triệu chứng gì?
- 3Bạn hỏi mô hình "bạn có dùng skill tro-ly-on-thi không?" và nó đáp "có, tôi đã dùng". Điều này...
- 4Nguyên tắc "skill giữ phần bất biến, chat giữ phần của lần này" nghĩa là gì?
Tóm tắt buổi
Prompt là nội dung của một lần hỏi; skill là cái hộp đặt tên cho nội dung ấy, dán nhãn khi
nào dùng, kèm tài nguyên phụ. Không phải prompt nào cũng đáng đóng gói: áp luật lần thứ hai,
và chỉ đóng gói thứ đã chạy ổn. description là bộ phận quyết định vì máy đọc nó để tự chọn
có bật skill hay không, nên phải nêu làm gì cộng khi nào dùng và giữ đúng phạm vi: rộng
quá thì bật nhầm khắp nơi, hẹp quá thì nằm im. Thử bằng hai nhóm câu nên bật và không nên
bật, và nhớ rằng lời mô hình tự khai đã dùng skill không phải bằng chứng, chỉ dấu vết thật
trong đầu ra mới là. Cuối cùng, skill giữ phần bất biến còn chat giữ phần của lần này; sửa
từng thứ một, giữ lại bộ câu thử, và tách skill khi nó bắt đầu ôm quá nhiều việc.
Skill là cái hộp đặt tên cho một prompt tốt, kèm nhãn description nói rõ làm gì và khi
nào dùng. Chuẩn SKILL.md gồm frontmatter YAML (bắt buộc name và description) cộng
thân Markdown chứa chỉ dẫn. Buổi sau ta sẽ nhờ chính AI sinh và tinh chỉnh skill, rồi học
cách thử cho nó kích hoạt đúng lúc.