Grok lập trình: Prompt, quy trình và thói quen an toàn

Grok có thể đọc stack trace, viết hàm, lên khung test và giải thích tệp code phức tạp. Bạn vẫn nắm quyền kiểm soát kết quả. Hướng dẫn này chỉ bạn những gì cần dán, cách hỏi và những chỗ cần kiểm tra.

9 phút đọcĐã cập nhật

Grok là một cộng sự lập trình đắc lực cho các công việc thường ngày: đọc thông báo lỗi, viết một hàm nhỏ, phác thảo test case, giải thích một tệp lạ lẫm hay biến ý tưởng sơ khai thành phiên bản đầu tiên. Trong khung chat của chúng tôi, mô hình không thể chạy mã, mở kho lưu trữ (repository) hay tra cứu tài liệu mới nhất hôm nay của bạn. Vì vậy, chất lượng hỗ trợ phụ thuộc vào ngữ cảnh bạn dán vào và mức độ kỹ lưỡng khi bạn kiểm tra kết quả trả về. Hướng dẫn này sẽ bao quát cả hai khía cạnh đó.

Grok xử lý tốt những gì, và hạn chế ở đâu

Grok phát huy hiệu quả nhất với các vấn đề gói gọn được trong một cuộc hội thoại. Điểm mạnh:

  • phân tích stack trace hoặc lỗi trình biên dịch và gợi ý các nguyên nhân khả dĩ;
  • viết một hàm độc lập, script, truy vấn SQL hoặc biểu thức chính quy (regex);
  • giải thích chi tiết một đoạn mã hoạt động như thế nào, từng dòng một nếu bạn cần;
  • viết nháp unit test, bao gồm cả các trường hợp biên (edge cases) bạn có thể chưa nghĩ tới;
  • review nhanh một đoạn diff ngắn để tìm lỗi, tên biến khó hiểu và các điểm thiếu kiểm tra;
  • chuyển đổi mã nguồn giữa các ngôn ngữ hoặc giữa các phiên bản thư viện.

Điểm hạn chế: những thay đổi đụng chạm tới nhiều tệp mà mô hình chưa từng thấy, bất kỳ điều gì phụ thuộc vào trạng thái chính xác của hệ thống máy bạn, và các câu hỏi về phiên bản thư viện mới hơn thời điểm dữ liệu huấn luyện. Mô hình cũng không thể tự chạy thử nghiệm. Mọi đoạn mã nó viết ra đều chưa được kiểm thử cho đến khi bạn tự chạy.

Cung cấp ngữ cảnh như thể đang giao việc cho đồng nghiệp mới

Lý do phổ biến nhất khiến câu trả lời lập trình trở nên vô dụng là thiếu ngữ cảnh. Trước khi hỏi, hãy gom đủ:

  1. Ngôn ngữ và phiên bản. "Python 3.12, pandas 2" hoặc "Node 22, Express 5". Sự khác biệt giữa các phiên bản là nguyên nhân của phần lớn câu trả lời sai.
  2. Đoạn mã liên quan. Hàm bị lỗi và các thành phần nó gọi trực tiếp, không cần gửi cả dự án.
  3. Chính xác lỗi gặp phải. Sao chép toàn bộ thông báo và stack trace; đừng tự diễn giải lại.
  4. Kỳ vọng và thực tế. Đáng lẽ phải ra kết quả gì, thực tế lại ra sao, và bạn đã thử xử lý thế nào.
  5. Các giới hạn. Không dùng thêm thư viện ngoài (dependencies), phải tương thích với phiên bản cũ, hoặc mã phải dễ hiểu cho người mới bắt đầu.
Kém hiệu quả:
code cua toi khong chay, sua ho toi voi

Hiệu quả:
Python 3.12. Hàm này cần trả về giá trị đơn hàng trung bình của mỗi
khách hàng, nhưng khách chỉ có 1 đơn lại nhận kết quả NaN. Kỳ vọng:
trả về đúng giá trị của đơn hàng duy nhất đó. Dưới đây là hàm và dữ liệu
mẫu. Hãy giải thích nguyên nhân trước, sau đó đưa ra hàm đã sửa. Không
cài thêm thư viện mới.
---
[hàm]
[năm dòng dữ liệu mẫu]

Cách hỏi hiệu quả sẽ cho Grok biết rõ ngôn ngữ, hiện tượng lỗi, kết quả kỳ vọng và các ràng buộc cần tuân thủ, đồng thời yêu cầu giải thích trước khi sửa để bạn hiểu rõ mình sai ở đâu.

Câu lệnh (prompt) mẫu cho các tác vụ lập trình phổ biến

Đọc hiểu một lỗi

Dán toàn bộ trace log và các dòng mã được chỉ ra, sau đó hỏi: "Hãy liệt kê 3 nguyên nhân khả dĩ nhất, xếp theo mức độ từ cao xuống thấp, và hướng dẫn tôi cách xác minh từng nguyên nhân." Bạn sẽ nhận được một kế hoạch chẩn đoán ngắn gọn thay vì một phỏng đoán vu vơ.

Viết một hàm

Mô tả đầu vào (input), đầu ra (output) và các trường hợp biên bằng từ ngữ thông thường, sau đó yêu cầu viết mã kèm 2-3 ví dụ gọi hàm cùng kết quả kỳ vọng. Các ví dụ này sẽ đóng vai trò như bài kiểm tra nhanh để bạn chạy thử ngay.

Viết kiểm thử (tests)

Hãy viết các bài test bằng pytest cho hàm dưới đây. Bao quát các trường hợp:
đầu vào bình thường, đầu vào rỗng, chỉ có một phần tử, số rất lớn và sai kiểu dữ liệu.
Mỗi trường hợp một test riêng với tên rõ ràng. Không sửa hàm gốc.
---
[hàm]

Tự review mã nguồn của mình

Yêu cầu review có trọng tâm rõ ràng, ví dụ: "Chỉ review đoạn mã này để tìm bug và lỗi chưa được xử lý; bỏ qua phần phong cách viết mã (style)." Đánh giá có trọng tâm sẽ ngắn gọn và dễ áp dụng hơn. Hãy thử dùng prompt review với đoạn mã của bạn.

Tìm hiểu đoạn mã lạ

"Hãy giải thích đoạn mã này làm gì, giải thích theo hướng tôi đã biết JavaScript nhưng chưa từng dùng thư viện này. Sau đó liệt kê những chỗ tiềm ẩn rủi ro hoặc đã lỗi thời." Đòi hỏi chỉ ra rủi ro sẽ biến một lời giải thích thông thường thành một buổi review mã thu nhỏ.

Quy trình làm việc giúp bạn luôn nắm quyền kiểm soát

  1. Thống nhất phương án trước. Với bất kỳ tác vụ nào lớn hơn một hàm đơn lẻ, hãy yêu cầu phác thảo hướng tiếp cận trước khi viết mã. Chốt xong phương án rồi mới yêu cầu sinh mã.
  2. Làm từng phần nhỏ. Mỗi tin nhắn chỉ xử lý một hàm hoặc một thay đổi. Câu trả lời quá dài dễ che giấu lỗi và có thể bị cắt cụt do giới hạn độ dài phản hồi.
  3. Tự chạy thử. Dán kết quả hoặc lỗi mới xuất hiện ngược lại vào cùng đoạn chat. "Đây là kết quả khi tôi chạy thử" là phản hồi tiếp nối hữu ích nhất.
  4. Đọc kỹ từng dòng trước khi giữ lại. Nếu bạn không thể giải thích dòng mã đó cho đồng nghiệp, hãy nhờ Grok giải thích lại, hoặc tự viết lại theo cách của bạn.
  5. Commit từng bước nhỏ. Hệ thống quản lý phiên bản (Git) giúp bạn dễ dàng hoàn tác nếu gợi ý của AI không hoạt động như mong muốn.

Công cụ trợ lý lập trình tích hợp sẵn các thói quen này vào một giao diện trực quan: chọn tác vụ, dán mã và nhận câu trả lời có cấu trúc. Trang dành cho nhà phát triển của chúng tôi có thêm nhiều cách ứng dụng Grok mỗi ngày, và danh sách prompt lập trình luôn sẵn sàng để bạn sử dụng.

Nên chọn mô hình Grok nào để viết code

  • Grok 4.20 (mặc định) phản hồi nhanh, phù hợp để giải thích, viết đoạn mã ngắn, biểu thức chính quy (regex) và mã mẫu (boilerplate).
  • Grok 4.3 Thinking có bước suy luận trước khi trả lời, rất hữu ích khi truy tìm các lỗi hóc búa, xử lý câu hỏi về thuật toán và logic nhiều điều kiện.
  • Grok 4.7 là mô hình mới nhất trong khung chat của chúng tôi, được xAI đánh giá là mô hình flagship cho lập trình và các tác vụ dạng tác tử (agentic). Bạn có tối đa 10 tin nhắn mỗi ngày với mô hình này, hãy gom bài toán khó nhất cùng đầy đủ ngữ cảnh vào trong một tin nhắn.

Bài viết hướng dẫn về mô hình suy luận (reasoning models) sẽ giải thích khi nào thời gian suy nghĩ bổ sung mang lại giá trị xứng đáng.

Các lỗi thường gặp cần lưu ý

  • Tự bịa hàm (ảo giác). Đôi khi Grok gọi một phương thức hoặc tham số nghe rất hợp lý nhưng thực ra không hề tồn tại. Nếu thấy lạ, hãy tra cứu lại trong tài liệu chính thức.
  • Phiên bản cũ. Kiến thức của mô hình có mốc giới hạn thời gian. Thư viện có thể đã đổi tên hoặc loại bỏ tính năng từ đó đến nay. Hãy nêu rõ phiên bản bạn dùng và kiểm tra changelog khi chưa chắc chắn.
  • Chỉ viết mã cho trường hợp lý tưởng. Bản nháp đầu tiên thường bỏ qua dữ liệu rỗng, tệp không tồn tại, múi giờ và lỗi mất mạng. Hãy hỏi thêm: "Đầu vào nào có thể làm đoạn mã này bị crash?"
  • Tự ý sửa đổi mã xung quanh. Khi sửa một lỗi, mô hình có thể tiện tay "dọn dẹp" chỗ khác. Hãy yêu cầu chỉ thay đổi tối thiểu, hoặc chỉ xuất ra các dòng có sự khác biệt.
  • Lỗ hổng bảo mật. Cảnh giác với các câu truy vấn ghép chuỗi trực tiếp, thiếu kiểm tra dữ liệu đầu vào và các thông tin bí mật bị hardcode vào mã. Hãy hỏi thẳng: "Đoạn này đã an toàn trước lỗi SQL injection chưa?"
Hãy yêu cầu viết test case gây lỗi trước. Trước khi yêu cầu sửa lỗi, hãy bảo Grok viết một bài test tái hiện lại chính bug đó. Nếu test fail trên máy bạn, bạn đã xác định đúng vấn đề; khi test pass sau khi sửa mã, bạn có bằng chứng chắc chắn là giải pháp đã hiệu quả.

Tuyệt đối không đưa thông tin nhạy cảm vào chat

Trước khi dán mã, hãy loại bỏ API key, mật khẩu, token, chuỗi kết nối cơ sở dữ liệu, dữ liệu khách hàng và tên miền nội bộ. Thay thế chúng bằng các giá trị giữ chỗ như YOUR_API_KEY. Nếu công ty bạn có quy định về việc chia sẻ mã nguồn với các dịch vụ bên ngoài, hãy tuân thủ nghiêm ngặt; khi chưa chắc chắn, hãy rút gọn vấn đề thành một ví dụ tối giản có hành vi tương tự mà không chứa phần mã riêng tư. Thường thì chính ví dụ tối giản đó đã giúp bạn tự nhìn ra lỗi rồi. Hướng dẫn về quyền riêng tư và an toàn của chúng tôi sẽ giải thích cách tin nhắn được xử lý qua hệ thống chat.

Câu hỏi thường gặp

Grok có chạy được mã của tôi trực tiếp trong khung chat không?

Không. Mô hình chỉ đọc và viết mã chứ không thực thi, nên không thể thấy kết quả chạy thực tế. Bạn hãy tự chạy mã trên máy rồi dán kết quả hoặc lỗi lại vào chat.

Tôi có thể gửi ảnh chụp màn hình thông báo lỗi không?

Được, cả ba mô hình đều có khả năng đọc hình ảnh. Tuy nhiên dán văn bản trực tiếp vẫn tốt hơn nếu có thể, vì Grok có thể trích dẫn chính xác từng từ mà không sợ nhận diện nhầm.

Mô hình hỗ trợ những ngôn ngữ lập trình nào?

Grok rất thành thạo các ngôn ngữ phổ biến: Python, JavaScript, TypeScript, Java, C#, C++, Go, PHP, SQL, shell script và nhiều ngôn ngữ khác. Với các ngôn ngữ ít dùng hoặc framework đặc thù, mô hình có thể nhầm lẫn nhiều hơn nên bạn cần kiểm tra kỹ lại.

Tại sao đoạn mã đang trả lời lại bị dừng giữa chừng?

Câu trả lời có giới hạn độ dài. Bạn chỉ cần nhắn: "viết tiếp phần còn lại, bắt đầu từ hàm đang dừng dở", hoặc yêu cầu tạo từng phần nhỏ của chương trình.

Dùng mã do AI viết trong công việc có ổn không?

Điều đó phụ thuộc vào quy định của công ty bạn và giấy phép bản quyền (license) của dự án. Hãy xem mã do AI tạo ra như bất kỳ nguồn đóng góp nào từ bên ngoài: luôn review kỹ, viết test và đảm bảo bạn có quyền sử dụng nó.

Sẵn sàng hỏi Grok điều gì đó?

Không cần tài khoản, không cần tải về, không cần thẻ. Mở chat, nhập câu hỏi và theo dõi câu trả lời của Grok hiển thị trực tiếp.

Mở đoạn chat