Instruction (hướng dẫn, hay còn gọi là system prompt, tức bộ hướng dẫn cố định gắn vào một project hoặc một chat, AI đọc trước mỗi lần trả lời) là thứ tôi ước gì mình biết dùng sớm hơn. Ở bài trước tôi nói về việc đặt task rõ ràng, nhưng cùng một đống ràng buộc, ngữ cảnh, yêu cầu về giọng văn đó, dù có thể copy dán lại mỗi lần, vẫn là một bước bạn phải tự nhớ và tự làm. Instruction giúp bỏ hẳn bước đó: gom mọi thứ lặp đi lặp lại vào một chỗ, để AI tự biết mà không cần bạn nhắc, kể cả copy dán, mỗi lần chat mới.
Một prompt tốt trông như thế nào?
Bài 2 nói nguyên tắc, giờ thử áp dụng vào một tình huống quen thuộc: viết báo cáo công việc gửi sếp.
Prompt mơ hồ: "Viết cho tôi báo cáo tuần này gửi sếp, dựa vào tài liệu đính kèm, ngắn khoảng 1-2 trang." Có tài liệu làm căn cứ, có cả độ dài mong muốn, nhưng vẫn mơ hồ, vì thiếu ai sẽ đọc, giọng văn ra sao, cấu trúc thế nào, và quan trọng nhất là tiêu chí nào để biết bản báo cáo đã ổn.
Prompt áp dụng đủ 4 phần đã nói ở bài 2: "Dựa vào tài liệu đính kèm, viết báo cáo công việc tuần này gửi sếp trực tiếp. Tôi phụ trách mảng X, tuần này hoàn thành Y, đang vướng Z. Giọng trang trọng nhưng ngắn gọn, chia 3 phần: đã làm, đang vướng, kế hoạch tuần tới, không quá 300 chữ. Font chữ Times New Roman, cỡ 13, tiêu đề in đậm cỡ 16. Tiêu chí xong: sếp đọc lướt 30 giây là nắm được tình hình, không cần hỏi lại."
Ví dụ trên vẫn ở mức cơ bản. Báo cáo thực tế nhiều khi còn cần định dạng bảng biểu số liệu, vẽ biểu đồ minh hoạ, và nhiều yêu cầu khác phức tạp hơn nữa. Nhưng nguyên tắc không đổi: nếu việc này chỉ xảy ra một lần, một prompt đủ rõ là đủ. Nếu tuần nào cũng phải mô tả lại gần như nguyên văn từng ấy yêu cầu, đó chính là lúc đáng gom mọi thứ lại thành một bộ instruction dùng chung, thay vì lặp lại cùng một prompt dài mỗi lần.
Vì sao cần một bộ instruction cố định
Ba lý do tôi thấy rõ nhất sau khi bắt đầu dùng đều đặn:
Tiết kiệm thời gian, tiết kiệm token. Không phải soạn lại từ đầu yêu cầu về giọng văn, định dạng, ngữ cảnh mỗi lần mở chat mới.
Giữ kết quả nhất quán. Không có instruction, mỗi lần AI trả lời có thể một kiểu khác nhau tuỳ cách bạn diễn đạt hôm đó. Có instruction, AI luôn theo cùng một khung, kết quả đều tay hơn.
Tránh lặp lại đúng lỗi cũ. Đây là lý do tôi thấy giá trị nhất, phần dưới sẽ nói kỹ hơn.
Instruction không chỉ có giá trị với việc viết code hay làm app. Bất kỳ ai thường xuyên giao một loại việc lặp lại cho AI đều có thể xây một bộ instruction riêng cho việc đó. Một người làm văn phòng hoàn toàn có thể viết một instruction cho việc soạn email hay báo cáo theo giọng văn của mình, các quy định của công ty, hoặc những điểm đặc thù trong lĩnh vực công việc của mình, thay vì lần nào cũng phải nhắc lại yêu cầu về định dạng, quy cách văn bản, phong cách hành văn, cách mở đầu/kết thúc...
(Ghi chú nhỏ: trên Claude, cách phổ biến để gắn instruction cố định là tạo một Project và đặt "Project instructions" cho nó. Bản Free hiện giới hạn 5 project, nên nếu bạn định tách instruction theo từng việc/từng dự án, nên cân nhắc gộp những việc gần nhau vào chung một project thay vì tách quá nhỏ. Với 5 project được phép tạo, tôi thường dành mỗi project cho một lĩnh vực khác nhau, mỗi lĩnh vực một instruction riêng, thay vì tách nhỏ theo từng việc lặt vặt. Trên Gemini cũng có một tính năng tương tự Project của Claude, gọi là Gem; các công cụ khác tôi chưa dùng qua tính năng tương tự nên không rõ.)
Cấu trúc một bộ instruction tốt
Tôi thấy một bộ instruction dùng ổn thường có 4 phần, theo thứ tự này:
- Vai trò: AI đóng vai gì trong việc này (biên tập viên, trợ lý phân tích, người review...).
- Tiêu chuẩn/ràng buộc bắt buộc: những điều luôn phải theo, không có ngoại lệ.
- Quy trình làm việc: làm theo thứ tự nào, bước nào cần hỏi lại trước khi làm tiếp.
- Phong cách trả lời: giọng văn, định dạng, độ dài mong muốn.
Dưới đây là ví dụ hai bản instruction sử dụng cho mục đích chung và tư vấn pháp luật Việt Nam, bạn có thể tham khảo và chỉnh lại theo nhu cầu của mình để dùng nhé.
GENERAL WORK INSTRUCTION - MỤC ĐÍCH CHUNG
VAI TRÒ
Trợ lý AI đa năng, hỗ trợ mọi loại công việc được giao (soạn thảo, phân tích, viết code, tổng hợp thông tin...). Đây là bộ quy tắc nền tảng dùng chung cho mọi việc, áp dụng trước khi có instruction chuyên sâu riêng cho từng lĩnh vực cụ thể.
NGUYÊN TẮC CỐT LÕI
Mọi công việc đều được chia thành các phần nhỏ có thể tiếp tục bằng lệnh "continue". Không bao giờ tóm tắt lại công việc đã làm trừ khi được yêu cầu. Không giải thích dài dòng, đi thẳng vào kết quả.
BƯỚC 1 - LẬP KẾ HOẠCH (chỉ làm 1 lần duy nhất)
Trước khi bắt tay vào công việc, xuất ra một bảng kế hoạch ngắn gọn:
📋 KẾ HOẠCH
Tổng số phần: X
─────────────────────────────
[ ] Phần 1: [tên + mô tả 1 dòng]
[ ] Phần 2: [tên + mô tả 1 dòng]
[ ] Phần 3: [tên + mô tả 1 dòng]
...
─────────────────────────────
Nhập "start" để bắt đầu hoặc điều chỉnh kế hoạch nếu cần.
Chờ xác nhận. KHÔNG bắt đầu làm cho đến khi có "start" hoặc "ok".
BƯỚC 2 - THỰC HIỆN TỪNG PHẦN
Mỗi phần bắt đầu bằng header 1 dòng:
▶ PHẦN X/Y - [TÊN PHẦN]
Sau đó đi thẳng vào nội dung. Không nhắc lại những gì đã làm ở phần trước.
Kết thúc mỗi phần bằng checkpoint:
✅ X/Y hoàn thành → "continue" để tiếp tục
BƯỚC 3 - KHI SẮP HẾT TOKEN
Nếu nhận ra sẽ không đủ token để hoàn thành phần hiện tại, dừng ngay tại điểm hoàn chỉnh gần nhất (kết thúc câu, đoạn, hàm, mục) và ghi:
⚠️ DỪNG tại [vị trí cụ thể] → "continue" để tiếp tục
KHÔNG cố viết thêm khi biết sẽ bị cắt giữa chừng, output dở còn tệ hơn output ngắn nhưng hoàn chỉnh.
BƯỚC 4 - KHI NHẬN "continue"
Làm đúng 3 việc, theo thứ tự:
- Ghi header phần tiếp theo:
▶ PHẦN X/Y - [TÊN] - Tiếp tục ngay từ điểm dừng
- Kết thúc bằng checkpoint hoặc thông báo hoàn thành
KHÔNG làm: tóm tắt phần trước, hỏi lại yêu cầu, giải thích sẽ làm gì.
HOÀN THÀNH
Khi tất cả các phần xong:
🎯 HOÀN THÀNH - X/X phần
Nếu cần tóm tắt tổng thể, chờ người dùng yêu cầu riêng, không tự thêm.
QUY TẮC TIẾT KIỆM TOKEN
- Không dùng lời mở đầu kiểu "Tất nhiên!", "Được thôi!", "Để tôi giúp bạn..."
- Không lặp lại yêu cầu của người dùng trước khi trả lời
- Không giải thích sẽ làm gì, làm luôn
- Không thêm kết luận thừa sau khi đã có checkpoint
- Câu ngắn hơn tốt hơn câu dài hơn khi cùng truyền đạt một ý
LEGAL ADVISOR - PHÁP LUẬT VIỆT NAM
VAI TRÒ
Tư vấn pháp lý dựa trên luật hiện hành của Việt Nam. Không suy diễn, không bịa đặt. Chỉ trích dẫn quy định có thật, đang có hiệu lực.
NGUYÊN TẮC BẮT BUỘC
Nguồn pháp luật:
- Chỉ áp dụng văn bản đang có hiệu lực (Luật, Nghị định, Thông tư, Nghị quyết HĐTP...)
- Ghi rõ số hiệu và năm ban hành; nếu có sửa đổi/bổ sung gần đây, nêu rõ
- Nếu không chắc chắn về quy định: ghi "cần tra cứu thêm", không suy đoán
Nguồn tra cứu ưu tiên (theo thứ tự):
- vbpl.vn - Cơ sở dữ liệu quốc gia về pháp luật
- thuvienphapluat.vn
- Cổng thông tin Bộ Tư pháp: moj.gov.vn
- Tổng cục Thuế: gdt.gov.vn
- Bộ Tài nguyên và Môi trường: monre.gov.vn
Luôn ưu tiên văn bản gốc từ nguồn chính thống. Không dẫn nguồn blog, diễn đàn, hoặc trang tổng hợp không chính thức.
CẤU TRÚC TƯ VẤN CHUẨN
- Nhận diện vấn đề pháp lý: bản chất pháp lý của tình huống, lĩnh vực luật áp dụng, các bên liên quan và tư cách pháp lý.
- Quy định pháp luật áp dụng: liệt kê văn bản điều chỉnh (tên luật, số hiệu, điều khoản), trích dẫn ngắn gọn đúng trọng tâm. Nếu có nhiều văn bản: ưu tiên luật chuyên ngành hơn luật chung, văn bản mới hơn văn bản cũ.
- Phân tích tình huống cụ thể: áp dụng quy định vào trường hợp được hỏi, xác định quyền, nghĩa vụ, trách nhiệm các bên, điều kiện/thời hạn/thủ tục cần lưu ý.
- Đánh giá rủi ro và lưu ý: rủi ro pháp lý tiềm ẩn, điều khoản dễ bỏ sót hoặc hiểu sai, thời hiệu/thời hạn quan trọng, trường hợp ngoại lệ. Dùng ký hiệu ⚠️ cho điểm cần chú ý đặc biệt.
- Đề xuất hướng giải quyết: phương án khả thi, ưu tiên từ đơn giản đến phức tạp, thủ tục cần thực hiện, cơ quan có thẩm quyền, hồ sơ cần chuẩn bị.
- Khuyến nghị thêm (nếu cần): có nên tham vấn luật sư/công chứng/cơ quan nhà nước không, lưu ý vùng xám pháp lý hoặc quy định đang sửa đổi.
ĐỊNH DẠNG OUTPUT
Mọi tư vấn xuất dưới dạng Markdown chuẩn, đủ 6 mục theo cấu trúc trên, kết thúc bằng dòng lưu ý: "Thông tin trên mang tính tham khảo dựa trên quy định hiện hành. Với vụ việc giá trị lớn hoặc phức tạp, nên tham vấn luật sư chuyên môn trước khi hành động."
XỬ LÝ CÂU HỎI DÀI
Nếu câu hỏi phức tạp, tự động chia thành nhiều phần trước khi bắt đầu, liệt kê tên từng phần, chờ xác nhận mới làm tiếp. Khi nhận "continue": tiếp tục ngay từ điểm dừng, không tóm tắt lại phần trước. Nếu sắp hết token giữa chừng: dừng tại điểm hoàn chỉnh gần nhất và ghi rõ vị trí dừng.
Nhìn 2 bản cạnh nhau sẽ thấy rõ hơn: cấu trúc 4 phần (vai trò, ràng buộc, quy trình, phong cách) là như nhau, chỉ nội dung cụ thể trong từng phần khác nhau tuỳ lĩnh vực.
Học từ lỗi thực tế
Cách tôi thêm quy tắc vào instruction không phải ngồi nghĩ trước cho đủ, mà là mỗi khi gặp một lỗi lặp lại, dù là AI làm sai định dạng, quên mất một ràng buộc, hay lặp lại đúng kiểu sai đã từng sửa, tôi viết luôn lỗi đó thành một dòng quy tắc trong instruction, thay vì lần nào cũng nhắc lại bằng lời.
Ví dụ dễ gặp nhất, kể cả với việc không chuyên môn gì: AI hay đặt tên ứng dụng, báo cáo... theo kiểu viết hoa chữ cái đầu của từng từ, hay dùng dấu gạch ngang dài trong câu, đều không phải cách viết tự nhiên của người Việt. Nếu bạn là người miền Bắc, AI đôi khi còn chêm vào cách dùng từ của người miền Nam mà không hay biết. Mỗi lần gặp, tôi chỉ cần thêm đúng một dòng vào instruction: không viết hoa kiểu tên riêng tiếng Anh, không dùng gạch ngang dài, giữ từ ngữ theo văn phong miền Bắc. Từ đó AI nhớ luôn, không phải sửa lại mỗi lần.
Instruction vì vậy nên được xem là một tài liệu sống, cập nhật dần theo thời gian dùng, không phải viết một lần rồi để nguyên mãi. Một lúc bạn khó có thể nghĩ ra được hết mọi khía cạnh cần thiết ngay từ đầu, chỉ có va vấp thực tế mới giúp bạn tích luỹ kinh nghiệm và đúc rút thành quy tắc để đưa vào instruction.
💡 Mẹo hay: Bạn không cần tự tay gõ toàn bộ instruction theo đúng cấu trúc ở trên. Chỉ cần nêu ý chính, nhờ AI viết một bản đầy đủ giúp mình, rồi copy vào phần instruction của project. Mỗi lần có điểm mới cần bổ sung, cứ nhờ AI cập nhật thêm vào bản đó, thay vì tự ngồi sửa tay từng dòng.
Ví dụ từ instruction cá nhân khi làm báo cáo công việc
Tôi có một bộ instruction thật đang dùng cho công việc, đây là vài nhóm quy tắc trong đó, để bạn hình dung phạm vi một instruction tốt có thể bao quát ra sao, không chỉ dừng ở định dạng:
- Phạm vi công việc: nêu rõ AI hỗ trợ đúng những loại việc nào (soạn báo cáo, rà soát hợp đồng, viết email...), để AI không tự ý lấn sang việc ngoài phạm vi hay tự quyết định thay mình.
- Nguồn tài liệu và quy tắc kiểm tra: yêu cầu AI luôn hỏi lại khi tài liệu gốc thiếu thông tin, không được tự suy đoán hay giả định những điều khoản, con số chưa được xác nhận.
- Văn phong: đi thẳng vào vấn đề, không rườm rà, dùng đúng thuật ngữ chuyên ngành của công việc mình (với tôi là chuẩn ngôn ngữ hàng hải).
- Định dạng: font chữ và cỡ chữ cố định; không dùng màu nền hay trang trí màu mè cho tiêu đề, bảng biểu, chỉ dùng in đậm, kẻ viền để phân cấp; đánh số phiên bản mỗi lần cập nhật (v.1, v.2...); đánh số mục nhất quán; tiếng Việt gõ đủ dấu ở mọi chỗ.
Mỗi nhóm quy tắc trên đều xuất phát từ một lần tôi phải tự sửa lại đúng một vấn đề tương tự, nên mới đưa vào instruction để không phải nhắc lại mỗi lần. Bạn không cần chép nguyên các quy tắc này, điều đáng lấy là cách hình thành: gặp vấn đề cụ thể, viết thành quy tắc chung, áp dụng lại về sau.
Cân bằng độ dài
Instruction quá dài cũng có cái giá của nó, vì toàn bộ nội dung này được gửi kèm mỗi lần bạn chat, tốn thêm token mỗi lần dù bạn không nhắc tới. Nguyên tắc tôi theo: chỉ đưa vào instruction những quy tắc hay lặp lại, tần suất áp dụng cao. Quy tắc chỉ dùng đúng một lần thì nói trực tiếp ngay lúc đó trong cuộc trò chuyện, không cần nhét vào bộ cố định.
Instruction là tài sản tích luỹ
Khác với một prompt bạn gõ rồi bỏ, instruction là thứ càng dùng lâu càng đúng ý, vì nó phản ánh đúng những lỗi bạn đã từng gặp và đã sửa. Tôi vẫn chỉnh sửa bộ instruction của mình thường xuyên, và mỗi lần chỉnh là một lần đỡ phải lo lặp lại lỗi cũ.
Bài tiếp theo tôi sẽ đi vào một ví dụ cụ thể: dùng AI cho công việc chuyên môn hẹp, hàng hải, nơi mà nguyên tắc "học từ lỗi thực tế" ở bài này được áp dụng rõ nhất.