Bài 3: Viết Instruction/System Prompt cho riêng mình: xây "luật chơi" cá nhân hoá

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:

  1. 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...).
  2. 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ệ.
  3. 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.
  4. 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é.

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.