Grok cho lập trình viên

Grok là một "chú vịt cao su" (rubber duck) đắc lực có thể phản hồi bạn. Trên grok.online, công cụ này hoàn toàn miễn phí và không cần tài khoản: Grok 4.20 phản hồi nhanh cho các câu hỏi ngắn, Grok 4.3 Thinking tư duy logic trước khi trả lời và rất thích hợp để tìm lỗi, còn Grok 4.7 — mô hình mới nhất — sẵn sàng giải quyết những bài toán hóc búa nhất với 10 trong số 30 tin nhắn mỗi ngày của bạn. Cả ba mô hình đều có thể đọc ảnh chụp màn hình. Dưới đây là bảy cách dùng kèm prompt mẫu mà bạn có thể mở trực tiếp trong khung chat và tùy chỉnh.

Tìm và sửa lỗi

Phần lớn thời gian gỡ lỗi (debug) là để hiểu chuyện gì đang xảy ra. Các prompt này sẽ giúp bạn đẩy nhanh quá trình đó.

Giải mã stack trace

Hãy dán toàn bộ thông báo lỗi — đừng diễn giải lại — cùng các dòng code mà lỗi trỏ tới. Hãy yêu cầu giải thích nguyên nhân bằng ngôn ngữ dễ hiểu trước khi đưa ra cách sửa để bạn có thể tự đánh giá.

Tôi đang dùng [ngôn ngữ và phiên bản] với [framework]. Đây là toàn bộ thông báo lỗi và stack trace: [dán lỗi]. Đây là phần code liên quan: [dán code]. Hãy giải thích ngắn gọn, dễ hiểu chuyện gì đã xảy ra và tại sao, chỉ ra nguyên nhân có khả năng cao nhất trước, sau đó đưa ra cách sửa đổi tối thiểu nhất để giải quyết vấn đề.

Mở prompt này trong chat. Công cụ Code Assistant cũng hỗ trợ tính năng tương tự trong một giao diện tiện lợi.

Nắm bắt cấu trúc code bạn không tự viết

Nhận lại một file code không có dòng chú thích nào là trải nghiệm mà lập trình viên nào cũng từng gặp. Trước khi thay đổi bất cứ điều gì, hãy yêu cầu một bản tổng quan chỉ ra các phần dễ rủi ro.

Tôi vừa tiếp nhận file [ngôn ngữ] này và cần chỉnh sửa [tính năng]. Hãy cho tôi một bản tóm tắt nhanh: nhiệm vụ chính của file, các hàm quan trọng theo thứ tự thực thi, các global state hoặc side effect cần lưu ý, và vị trí an toàn nhất để tôi thực hiện thay đổi: [dán code]

Nhận bản tóm tắt, sau đó hỏi thêm về bất kỳ hàm nào bạn thấy chưa rõ.

Săn lỗi logic bằng mô hình tư duy (thinking model)

Khi chương trình không báo lỗi (crash) nhưng kết quả lại sai, bạn cần theo dõi từng bước thực thi (trace). Grok 4.3 Thinking sẽ phân tích logic qua từng dòng code trước khi trả lời, rất phù hợp cho các lỗi lệch 1 đơn vị (off-by-one) hay điều kiện rẽ nhánh bị sai.

Hàm [ngôn ngữ] này lẽ ra phải [hành vi mong muốn], nhưng với đầu vào [input] nó lại trả về [kết quả thực tế] thay vì [kết quả mong muốn]. Hãy trace từng bước thực thi với đầu vào đó, hiển thị giá trị của các biến chính tại mỗi bước, và chỉ ra chính xác dòng code gây ra lỗi: [dán hàm]

Trace code với Grok 4.3 Thinking.

Sửa lỗi giao diện (CSS) từ ảnh chụp màn hình

Đính kèm ảnh chụp màn hình giao diện hiện tại bị lỗi, dán đoạn HTML và CSS liên quan, rồi mô tả giao diện mong muốn.

Tôi có đính kèm ảnh chụp màn hình trang web đang bị lỗi [mô tả vấn đề, ví dụ: sidebar bị đè lên nội dung trên màn hình nhỏ]. Đây là HTML và CSS của phần đó: [dán code]. Hãy giải thích nguyên nhân và đưa ra đoạn CSS đã sửa, hạn chế thay đổi cấu trúc cũ nhiều nhất có thể.

Mở prompt này và đính kèm ảnh chụp màn hình của bạn.

Lập kế hoạch tái cấu trúc (refactor) an toàn

Tái cấu trúc một module phức tạp là lúc mô hình mới nhất phát huy tối đa giá trị số tin nhắn giới hạn mỗi ngày của bạn. Hãy yêu cầu một kế hoạch cụ thể thay vì viết lại toàn bộ ngay lập tức.

Dưới đây là một module [ngôn ngữ] đang ngày càng khó bảo trì: [dán code]. Đừng viết lại code ngay. Hãy phân tích các nhiệm vụ của nó, các dependency ẩn, và lập kế hoạch refactor theo từng bước nhỏ sao cho code vẫn chạy bình thường sau mỗi bước. Hãy cho tôi biết cần viết thêm những test case nào trước khi bắt đầu bước đầu tiên.

Lập kế hoạch với Grok 4.7, sau đó gửi từng bước cho Grok 4.20 xử lý.

Viết các phần bổ trợ xung quanh code

Unit test, câu truy vấn SQL, review code và tài liệu là những phần thường bị bỏ qua khi deadline cận kề.

Viết test cho các trường hợp biên (edge cases) bạn đã bỏ qua

Hãy yêu cầu danh sách các trường hợp cần kiểm thử trước rồi mới viết code test sau. Danh sách ca kiểm thử chính là phần giá trị nhất.

Đây là hàm viết bằng [ngôn ngữ]: [dán hàm]. Trước tiên hãy liệt kê các edge case đáng để viết test (như dữ liệu rỗng, giá trị biên, kiểu dữ liệu không hợp lệ), giải thích ngắn gọn lý do cho mỗi trường hợp trong một dòng. Sau đó viết test bằng [test framework], mỗi case một test riêng với tên gọi rõ ràng.

Tạo bộ test, chạy thử và giữ lại những test bắt đúng lỗi thực tế.

Nhận code review khắt khe từ "senior khó tính"

Grok sẵn sàng đóng vai một reviewer dày dạn kinh nghiệm đã gặp mọi loại bug trên đời. Khắt khe cũng tốt, nhưng phải rõ ràng, vì vậy hãy yêu cầu chỉ rõ số dòng.

Hãy review bản diff này như một senior engineer khó tính nhưng công tâm. Hãy chỉ ra các bug tiềm ẩn, cách đặt tên chưa rõ ràng, các chỗ thiếu xử lý lỗi và bất kỳ yếu tố nào có thể gây rắc rối sau sáu tháng nữa. Mỗi nhận xét cần đi kèm số dòng và gợi ý cách khắc phục. Sắp xếp các vấn đề theo mức độ nghiêm trọng và bỏ qua những lỗi vụn vặt về phong cách trình bày: [dán diff]

Yêu cầu review code trước khi gửi cho đồng đội kiểm tra.

Chuyển schema thành truy vấn SQL và tài liệu README

Cung cấp cấu trúc bảng (schema) cùng yêu cầu truy vấn bằng ngôn ngữ tự nhiên, kèm theo giải thích ngắn gọn cho câu query.

Đây là cấu trúc bảng của tôi trong [cơ sở dữ liệu, ví dụ: PostgreSQL]: [dán schema]. Hãy viết câu truy vấn để [kết quả bạn cần bằng ngôn ngữ tự nhiên]. Giải thích ngắn gọn từng phép join và filter trong một dòng, đồng thời cho biết nên tạo index nào để tối ưu khi bảng đạt hàng triệu bản ghi.

Viết câu truy vấn, sau đó yêu cầu tạo thêm mục README để làm tài liệu mô tả các bảng.

Những điều cần tránh

• Dán thông tin nhạy cảm. API key, mật khẩu, token xác thực và dữ liệu khách hàng tuyệt đối không đưa vào bất kỳ khung chat nào. Hãy thay thế chúng bằng dữ liệu mẫu.
• Tin tưởng tuyệt đối vào chi tiết thư viện. Các mô hình có giới hạn thời gian cập nhật dữ liệu và không kết nối internet thời gian thực, vì vậy một số hàm hoặc tùy chọn có thể đã lỗi thời hoặc do AI tự suy diễn. Hãy đối chiếu lại với tài liệu chính thức.
• Sử dụng code mà chưa qua kiểm thử. Đoạn code trông có vẻ chuẩn xác vẫn có thể chạy sai. Hãy luôn chạy thử, viết test và kiểm tra kỹ lưỡng.
• Gửi toàn bộ mã nguồn dự án. Tin nhắn quá dài sẽ bị cắt bớt. Bạn chỉ nên gửi đúng hàm hoặc đoạn code cần xử lý.

Trang liên quan

• Khám phá thêm 20 gợi ý mở đầu trong danh sách prompt lập trình.
• Xem hướng dẫn lập trình cùng Grok và bài viết giải thích về mô hình tư duy (reasoning models).
• Bạn đang tự xây dựng ứng dụng riêng? Tìm hiểu thêm về Grok API.