Cách Karpathy gợi ý: viết như sổ tay bảo dưỡng máy bay để đọc câu trả lời của AI nhanh hơn

Ngày 2 tháng 10, Andrej Karpathy đăng một gợi ý về cách đọc câu trả lời của mô hình ngôn ngữ. Gợi ý đầu tiên của ông là bắt mô hình viết theo chuẩn tiếng Anh kỹ thuật của ngành hàng không. Chuẩn đó có tên ASD-STE100, ra đời năm 1986 cho sổ tay bảo dưỡng máy bay.

Thang bốn bậc của Karpathy

Karpathy là một trong những người sáng lập OpenAI và từng phụ trách mảng AI tại Tesla. Lập luận của ông bắt đầu từ một sự thay đổi đơn giản. Mô hình ngôn ngữ, tức LLM, viết nhanh hơn con người đọc. Nút thắt không còn nằm ở khâu viết câu trả lời. Nút thắt nằm ở khâu con người tiếp nhận và kiểm chứng câu trả lời đó.

Từ đó, ông xếp bốn dạng kết quả theo mức độ dễ tiếp nhận, từ khó nhất tới dễ nhất. Bậc một là văn bản viết theo lối kiểm soát chặt chẽ. Bậc hai là sơ đồ, để thấy các phần nối với nhau ra sao. Bậc ba là trang web tương tác, để kéo thanh trượt và xem kết quả thay đổi. Bậc bốn là video giải thích đặt riêng cho từng chủ đề, dạng video mà ông tỏ ra hào hứng nhất.

Bài này chỉ đi sâu vào bậc một. Đây là bậc bạn dùng mỗi ngày, và cũng là bậc rẻ nhất để sửa.

ASD-STE100 là gì

ASD-STE100 là tên đầy đủ của Simplified Technical English, tạm dịch là tiếng Anh kỹ thuật đơn giản hóa. Chuẩn này ra mắt năm 1986 dưới tên AECMA Simplified English Guide, do ngành hàng không châu Âu xây dựng. Sau này, khi tổ chức AECMA đổi tên thành ASD, chuẩn này mang tên ASD-STE100.

Lý do ra đời chuẩn này rất thực tế. Nhiều thợ bảo dưỡng máy bay không phải người bản ngữ tiếng Anh. Một câu đọc được theo hai cách thì sớm muộn cũng có người đọc sai cách. Trong công việc bảo dưỡng, đọc sai có thể gây hậu quả thật. Ngành hàng không vì thế viết một bộ quy tắc cho câu văn. Bộ quy tắc này giới hạn từ vựng được phép dùng, giới hạn độ dài câu, và bắt mỗi từ chỉ mang một nghĩa.

Hai con số đáng nhớ nhất là giới hạn độ dài câu. Câu hướng dẫn thao tác dài khoảng 20 từ. Câu mô tả dài khoảng 25 từ. Vượt quá giới hạn đó, câu phải tách ra.

Ba quy tắc mang lại phần lớn lợi ích

Bạn không cần học toàn bộ chuẩn. Ba quy tắc dưới đây đã mang lại phần lớn lợi ích khi áp vào câu trả lời của chatbot.

Một câu, một ý

Một câu chỉ nên mang một chỉ dẫn hoặc một dữ kiện. Câu dài thường giấu hai việc trong một câu, và người đọc phải tự tách chúng ra trong đầu.

Ví dụ, thay vì viết một câu dài về việc kiểm tra biến môi trường rồi chạy lại quá trình triển khai, hãy tách thành hai câu ngắn. Câu đầu nêu việc kiểm tra. Câu sau nêu việc chạy lại. Người đọc kiểm tra từng câu một, và biết ngay câu nào sai nếu có sai.

Thể chủ động, nêu rõ ai làm gì

Câu bị động giấu người thực hiện công việc. Câu "Cấu hình phải được kiểm tra trước khi hệ thống khởi động" không nói ai kiểm tra. Câu chủ động nói rõ việc đó. Bạn kiểm tra cấu hình. Sau đó bạn khởi động hệ thống. Hai câu chủ động trả lời ngay hai câu hỏi: ai làm, và làm gì.

Quy tắc này quan trọng với câu trả lời của mô hình. Mô hình rất giỏi viết câu nghe có vẻ chắc chắn trong khi không nêu rõ ai chịu trách nhiệm làm gì. Buộc mô hình nêu tên người thực hiện sẽ lộ ra những chỗ nó đang lảng tránh.

Một từ, một nghĩa

Đây là quy tắc dễ bị xem nhẹ nhất. Trong một câu trả lời, mô hình thường đổi tên khái niệm liên tục. Một khái niệm lúc đầu gọi là "hàm", sau đó thành "thủ tục", rồi thành "phương thức". Hàm ở đây là một khối mã có tên riêng, dùng để thực hiện một việc. Người đọc có lý do chính đáng để thắc mắc: đây là ba thứ khác nhau, hay chỉ là một thứ với ba tên gọi.

Quy tắc một từ một nghĩa cấm việc đổi tên đó. Bạn đặt tên cho khái niệm một lần, rồi giữ nguyên tên đó tới cuối câu trả lời. Nghi ngờ biến mất, và câu trả lời ngắn lại vì không cần giải thích thêm.

Vì sao gọi tên một chuẩn tốt hơn nói "hãy ngắn gọn"

Điểm thú vị nhất của bài viết gốc không nằm ở ba quy tắc. Điểm đó nằm ở cách ra lệnh cho mô hình. Tác giả bài viết gốc nhấn mạnh đây là quan điểm của riêng anh, không phải điều bài đăng của Karpathy chứng minh.

"Hãy ngắn gọn" là một tính từ. Mô hình phải tự đoán: ngắn tới mức nào, ngắn cho ai đọc, và ngắn với cái giá nào về độ đầy đủ. Mỗi mô hình đoán một kiểu khác nhau. Sau vài lượt trò chuyện, câu trả lời lại trôi về lối viết mặc định dài dòng.

"Viết theo ASD-STE100" là một chỉ dẫn tới một chuẩn có thật, có tài liệu công khai. Mô hình không phải tự nghĩ ra ý nghĩa của chỉ dẫn, vì ý nghĩa đó đã tồn tại sẵn trong dữ liệu huấn luyện của nó. Bạn có thể kiểm tra kết quả theo chuẩn, thay vì tranh cãi xem thế nào là đủ ngắn.

Tác giả bài viết gốc so sánh việc này với việc thuê thợ xây. Nói "làm móng cho chắc" là một yêu cầu mơ hồ. Nói "làm móng theo tiêu chuẩn xây dựng địa phương" là một yêu cầu có thể kiểm tra được. Bài học rộng hơn cũng tương tự. Khi bạn muốn một phong cách viết, hãy tìm một chuẩn có tên gọi cho phong cách đó. Hướng dẫn viết rõ ràng, quy tắc văn phong của một tờ báo, hay định dạng báo cáo thí nghiệm đều dùng được theo cùng một logic.

Ví dụ làm việc: viết lại một câu trả lời dài

Hãy lấy một tình huống quen thuộc: bạn hỏi chatbot vì sao bản triển khai thất bại và cần làm gì. Dưới đây là dạng câu trả lời dài dòng thường gặp, do chính bài này viết ra để minh họa.

Có thể vấn đề nằm ở chỗ biến môi trường chưa được cấu hình một cách chính xác, và điều này về cơ bản có thể dẫn tới việc quá trình triển khai không thể hoàn thành được. Nhìn chung, bạn có thể cân nhắc việc kiểm tra lại các giá trị cấu hình trước khi bạn thử chạy lại quá trình triển khai một lần nữa. Tóm lại, việc kiểm tra kỹ lưỡng thường giúp tránh được nhiều lỗi tương tự trong tương lai.

Bây giờ là bản viết lại theo ba quy tắc trên.

Bản triển khai thất bại vì thiếu biến môi trường. Bạn mở tệp cấu hình của môi trường triển khai. Bạn kiểm tra tên biến và giá trị biến. Bạn bổ sung biến còn thiếu. Sau đó bạn chạy lại quá trình triển khai.

Bản thứ hai không thông minh hơn bản thứ nhất. Bản thứ hai dễ kiểm tra hơn. Bạn đọc từng câu và biết ngay câu nào đúng, câu nào sai, việc nào làm trước, việc nào làm sau. Đó chính là mục tiêu của chuẩn này: không phải viết hay hơn, mà là viết sao cho người đọc kiểm chứng được nhanh hơn.

Đoạn prompt bạn có thể dán ngay

Dưới đây là bản rút gọn, dựa trên gợi ý trong bài viết gốc. Bạn dán đoạn này vào phần hướng dẫn tùy chỉnh của chatbot, hoặc đặt ở đầu một cuộc trò chuyện dài.

Write in ASD-STE100 style, about 80 percent compliance.
- One idea per sentence. Keep sentences short.
- Use active voice. Name who does what.
- Use one word for one meaning.
- Answer first. Do not repeat my question. Do not add a summary.
- If unsure, say so in one plain sentence.

Dịch nôm na từng dòng: viết theo phong cách ASD-STE100, đạt khoảng 80 phần trăm chuẩn. Mỗi câu một ý, câu ngắn. Dùng thể chủ động, nêu rõ ai làm gì. Một từ chỉ một nghĩa. Trả lời ngay, không nhắc lại câu hỏi, không thêm phần tóm tắt. Nếu không chắc, nói rõ điều đó trong một câu đơn giản.

Dòng "trả lời ngay" không thuộc chuẩn ASD-STE100 gốc. Dòng này nhắm đúng thói quen gây khó chịu nhất của chatbot: nhắc lại câu hỏi, rồi tóm tắt lại ở cuối. Dòng "một từ một nghĩa" cũng làm nhiều việc hơn vẻ ngoài của nó. Nó ngăn mô hình đổi tên khái niệm giữa chừng, và nhờ đó câu trả lời ngắn lại mà không mất thông tin.

Khi nào dùng 80 phần trăm, khi nào dùng 100 phần trăm, khi nào bỏ hẳn

Karpathy gợi ý mức khoảng 80 phần trăm, không phải 100 phần trăm. Bài viết gốc đồng ý với mức này, và lý do đáng nghe. Chuẩn đầy đủ rất nghiêm ngặt. Nó hạn chế từ vựng, cấm nhiều dạng động từ, và cho ra văn phong phẳng như một tấm thẻ hướng dẫn. Văn phong đó hợp với hướng dẫn thao tác, nhưng hơi nặng nề với bài giải thích hay bài trình bày quan điểm.

Một quy tắc thực dụng là: nhiệm vụ càng mang tính chỉ dẫn, bạn càng đẩy gần tới 100 phần trăm. Hướng dẫn, danh sách kiểm tra và các bước khắc phục sự cố xứng đáng với mức nghiêm ngặt nhất. Bài giải thích và bài trình bày quan điểm nên ở mức 80 phần trăm. Mức này giữ lại thuật ngữ chuyên môn cần thiết, và cho phép một câu dài hơn khi câu ngắn làm ý bị vỡ vụn.

Có hai trường hợp nên bỏ hẳn chỉ dẫn này. Thứ nhất là viết sáng tạo và viết thuyết phục, nơi nhịp điệu và sự đa dạng từ ngữ là một phần của nghề. Thứ hai là khi bạn cần mô hình suy luận sâu trong vòng lặp của agent, tức chương trình tự động dùng mô hình để làm việc. Trong trường hợp đó, cách làm an toàn hơn là để agent suy luận ở dạng đầy đủ, và chỉ áp phong cách đơn giản ở bước cuối, khi con người đọc kết quả.

Một lưu ý thực tế nữa: sau vài lượt trò chuyện, mô hình có thể trôi về lối viết mặc định. Khi đó, bạn nhắc lại chỉ dẫn trong một dòng, thay vì thêm hàng loạt quy tắc mới.

Hai cạm bẫy cần nhớ

Cạm bẫy thứ nhất: rõ ràng không có nghĩa là đúng. Mô hình có thể trình bày một dữ kiện sai bằng tiếng Anh cực kỳ rõ ràng. Văn bản rõ ràng thậm chí còn làm dữ kiện sai trông đáng tin hơn. Chuẩn này chỉ sửa cách trình bày, không sửa nội dung. Bất cứ điều gì quan trọng vẫn cần kiểm chứng từ nguồn khác.

Cạm bẫy thứ hai: chuẩn này vốn không sinh ra cho văn xuôi chung. Trang hỏi đáp của nhóm duy trì chuẩn ASD-STE100 cũng nói rõ điều đó. Bạn mượn các nguyên tắc của chuẩn, như câu ngắn, một ý một câu và thể chủ động, chứ không áp nguyên xi bộ quy tắc của sổ tay bảo dưỡng máy bay vào mọi loại văn bản. Dùng sai chỗ, bạn được một văn bản khô cứng mà không rõ ràng hơn bao nhiêu.

Danh sách kiểm tra trước khi dùng

Trước khi giữ đoạn prompt này trong phần hướng dẫn tùy chỉnh, bạn hãy thử nó với một câu hỏi mà bạn đã biết đáp án. Sau đó đối chiếu kết quả với năm điểm sau.

• Câu trả lời có đi thẳng vào đáp án, hay vẫn nhắc lại câu hỏi của bạn.
• Mỗi câu có chỉ mang một ý, hay vẫn nhồi hai việc vào một câu.
• Mỗi hành động có nêu rõ ai làm, hay vẫn giấu người thực hiện trong câu bị động.
• Mỗi khái niệm có giữ một tên duy nhất từ đầu tới cuối, hay vẫn đổi tên giữa chừng.
• Những dữ kiện quan trọng trong câu trả lời có kiểm chứng được từ nguồn khác, hay chỉ nghe có vẻ đúng vì viết rõ ràng.

Nếu cả năm điểm đều đạt, bạn giữ lại đoạn prompt. Nếu văn bản nghe quá cứng, bạn hạ mức từ 80 phần trăm xuống 70 phần trăm. Ngành hàng không đã mất nhiều thập kỷ để tìm ra câu nào khiến người đọc hiểu sai. Bạn có thể mượn kết quả đó chỉ bằng vài dòng hướng dẫn.

Nguồn tham khảo

• Bài viết gốc trên DEV Community: The Aircraft Manual Prompt That Cuts AI Waffle: ASD-STE100 for ChatGPT and Claude, tác giả blobxiaoyao, đăng ngày 2026-10-25.
• Trang chính thức của chuẩn ASD-STE100, nơi công bố lịch sử và các ấn bản của chuẩn.
• Bài phân tích về bài đăng ngày 2/10/2026 của Andrej Karpathy trên Search Engine Journal, đối chiếu độc lập với bài viết gốc.
• Bài phân tích trên FourWeekMBA về cùng bài đăng của Karpathy, xác nhận thang bốn bậc và lập luận về chi phí hiểu kết quả.