Grok Build vs Claude Code: Tôi đã kiểm thử cả hai trên một bộ dữ liệu gài bẫy

Grok Build là gì?

Grok Build là agent lập trình của xAI. Nó chạy theo ba cách: như một TUI tương tác, headless trong script và CI (với đầu ra streaming-json có cấu trúc để thu lại transcript theo lập trình), hoặc thông qua Agent Client Protocol (ACP) để ứng dụng khác có thể nhúng.

Khi khởi chạy, thanh trạng thái hiển thị hai điều đáng chú ý cho về sau. Góc phải dưới đọc là Grok 4.6 (high) (mô hình và mức nỗ lực suy luận đang dùng, có thể chuyển bằng /model). Góc trái dưới gợi ý một worktree mới, cho phép Grok khởi chạy subagent vào các worktree Git cách ly thay vì va chạm trong một thư mục duy nhất.

Có một tính năng tôi muốn nêu sớm, vì Claude Code không có đối ứng: Grok hỗ trợ các mô hình tùy ý qua ~/.grok/config.toml. Bạn có thể trỏ CLI tới bất kỳ endpoint tương thích OpenAI nào, đặt tên, và chọn bằng /model. Nếu bạn muốn một CLI dùng chung cho nhiều nhà cung cấp mô hình, đây là khác biệt kiến trúc thực sự, không chỉ hình thức.

Chạy grok inspect trong một repo mới để xem agent của bạn thực sự đang đọc gì. Nó in ra mọi thứ Grok phát hiện trong thư mục hiện tại: 

• Nguồn cấu hình
• Tệp hướng dẫn
• Kỹ năng
• Plugin
• Hook
• Máy chủ MCP

Bắt đầu với Grok Build

Để cài đặt Grok build trên Mac OS, chạy:

curl -fsSL https://x.ai/cli/install.sh | bash

Trên Windows, có trình cài đặt PowerShell:

irm https://x.ai/cli/install.ps1 | iex

Khi chạy lần đầu, nó mở trình duyệt để xác thực với tài khoản xAI hoặc X của bạn. Trong môi trường không có trình duyệt, bạn xuất API key thay thế:

export XAI_API_KEY="xai-..."
grok

Để bắt đầu, bạn có thể cd vào một repo và hỏi:

grok -p "Explain this codebase"
grok -p "Explain the architecture" --output-format streaming-json

Để xem toàn bộ hướng dẫn (xác thực, bộ nhớ xuyên phiên, quyền an toàn, hướng dẫn dự án, và một bản build đầu-cuối đầu tiên), xem hướng dẫn Grok Build của chúng tôi.

Claude Code là gì?

Claude Code là công cụ lập trình theo hướng agent của Anthropic, chạy trên terminal, trong VS Code và JetBrains, trong ứng dụng desktop và web, trên di động, và trong CI. Cũng có tích hợp Slack và Agent SDK cho phép tiếp cận cùng vòng lặp theo lập trình.

Mô hình mở rộng của nó là một chồng các nguyên thủy xây trên nhau. Tệp CLAUDE.md đặt quy ước theo từng thư mục. Gói Skills chứa các quy trình tái sử dụng dưới dạng tệp SKILL.md với frontmatter, có thể gọi theo tên hoặc tự kích hoạt khi khớp với tác vụ.

Trong bài viết này, tôi chạy Claude Code trong ứng dụng desktop trên Opus 5 ở mức nỗ lực suy luận cao. 

Nếu bạn muốn phiên bản chỉ dành cho Claude của một so sánh như thế này, bài viết Claude Cowork so với Claude Code của chúng tôi bao quát khá tốt. Để xem toàn bộ hướng dẫn cài đặt và dự án đầu tiên, hãy đọc hướng dẫn thiết lập Claude Code.

Grok Build vs Claude Code: Tính năng chính và điểm tương đồng

Tôi sẽ lướt qua hầu hết so sánh cơ bản, vì tóm lại là chúng có hình hài sản phẩm giống nhau. Dưới đây là một số điểm tương đồng tôi thấy ở cả hai:

Ba hàng trong bảng trên thực sự quan trọng:

• Tệp hướng dẫn: Việc Grok đọc tệp .claude/ không phải ngẫu nhiên; đó là tính năng được ghi nhận, nghĩa là bạn có thể trỏ Grok vào một kho đã thiết lập cho Claude Code và nó hoạt động ngay, trong khi thiết lập ưu tiên Grok không chuyển ngược lại.

• Endpoint mô hình tùy chỉnh: Endpoint mô hình tùy chỉnh là một ngả rẽ thực sự vì Grok có thể điều khiển bất kỳ API tương thích OpenAI nào, nên có thể đóng vai trò một CLI cho nhiều nhà cung cấp, trong khi Claude Code chỉ chạy mô hình Claude. 

• Bề mặt sử dụng: Những điều này quyết định nơi công việc có thể diễn ra, và đây là hàng mà Claude Code vượt trội rõ ràng.

Kiểm thử Grok Build và Claude Code trên cùng một tác vụ Machine Learning

Tôi tạo một bộ dữ liệu churn tổng hợp với 5.427 dòng snapshot theo tháng, bao phủ 1.800 khách hàng, với ba lỗi được cài cắm có chủ đích:

• Thuộc tính rò rỉ: days_since_cancellation chỉ tồn tại sau khi ai đó đã hủy.

• Mất cân bằng lớp nghiêm trọng: 8,2% dương tính, nên dự đoán "không ai churn" đạt 91,8% độ chính xác.

• Khách hàng lặp lại: 5.427 dòng đó chỉ là 1.800 người, nên chia ngẫu nhiên theo dòng sẽ đặt cùng một người vào cả tập huấn luyện và kiểm tra.

Nếu sửa cả ba, con số trung thực rơi vào khoảng 0,70 theo ROC-AUC, đo lường mức độ mô hình xếp hạng một mẫu dương ngẫu nhiên cao hơn một mẫu âm ngẫu nhiên trên mọi ngưỡng. Giá trị gần 1 nghĩa là gần tách biệt hoàn hảo giữa người churn và không churn, còn 0,5 là tung đồng xu.

Tôi chọn nó làm thước đo cho các bài kiểm tra này vì nó độc lập với ngưỡng và không bị đánh lừa bởi mất cân bằng lớp 8,2% như độ chính xác thô (nơi "dự đoán không ai churn" đạt 91,8% nhưng vô dụng).

Tôi viết sẵn một cuộc hội thoại bốn lượt trước khi chạy bất cứ thứ gì, và tính các giá trị tham chiếu cho mọi kịch bản bằng scikit-learn 1.8.0 để tôi có thể chấm điểm transcript dựa trên con số cố định thay vì ấn tượng chủ quan.

Một lưu ý trung thực: Đây không phải là benchmark kiểm soát. Chỉ là một cuộc hội thoại mỗi agent, chạy với Grok 4.6 ở nỗ lực cao so với Claude Opus 5 ở nỗ lực cao. Cả hai dịch vụ thay đổi liên tục. Vì vậy, hãy coi đây là một quan sát chi tiết, không phải phép đo.

Lượt 1: Đọc một bộ dữ liệu "gài bẫy"

Prompt mở đầu không nói gì về rò rỉ, gom nhóm, hay cân bằng lớp, chỉ yêu cầu agent huấn luyện một mô hình trên một bộ dữ liệu:

Train a model to predict churn from churn.csv. Report how well it does.

Grok Build đã làm gì

Grok mở đầu bằng những sửa đổi nó đã áp dụng: loại days_since_cancellation, loại customer_id, chia tách phân tầng theo khách hàng ở mức 1.440 / 360. Chỉ sau đó nó mới báo cáo số liệu.

Hàng đầu tiên của bảng là đường cơ sở lớp chiếm đa số với độ chính xác 0,917 và ROC-AUC 0,50. "Luôn dự đoán không churn" ở đầu phép so sánh giúp nêu luận điểm về mất cân bằng trước khi ai đó hiểu sai cột accuracy. Mô hình được chọn, logistic regression cân bằng, đạt ROC-AUC 0,74 trên tập giữ lại và 0,71 trong CV 5-fold.

Nó cũng báo cáo rằng mô hình bắt được 21 trong 30 người churn với 114 báo động giả. Mô hình có thể xếp hạng rủi ro trên một danh sách tiếp cận rộng hơn, nhưng không thể nói "khách hàng này sẽ churn" vì đa số người bị gắn cờ sẽ không rời đi.

Claude Code đã làm gì

Claude báo cáo ROC-AUC 0,727 và PR-AUC 0.237 từ cross-validation out-of-fold, với độ trải mỗi fold từ 0,675 đến 0,753. Bản tái hiện của tôi cho 0,724 và 0,241, rất gần với kết quả của Claude.

Nó còn đi xa hơn một bước so với yêu cầu và nhận ra rằng "churned" là cờ hồi cứu "đã từng churn" chứ không phải sự kiện theo tháng, nên mô hình trả lời "khách hàng này đã từng rời đi chưa" thay vì "họ sẽ rời đi tháng tới không," và nói rằng để triển khai sẽ cần dựng lại nhãn với chân trời xác định và một ngày hủy thực. Đó là vấn đề đặt bài toán trong bộ dữ liệu của tôi, không phải vấn đề mô hình, và đó là nhận xét sắc sảo nhất của cả hai agent ở lượt này.

Bảng hiệu chỉnh trên gồm năm nhóm rủi ro, nơi churn dự đoán và quan sát bám sát nhau (1,9% dự đoán so với 2,2% quan sát, lên đến 20,2% so với 20,0%). Hiệu chỉnh là thứ khiến các con số lift đó đáng tin thay vì chỉ đúng theo hướng, và không có gì trong prompt của tôi yêu cầu việc này. Liên hệ top 10% theo rủi ro thì 24% trong số họ churn, so với 8,3% nền tảng, tức lift 2,9x bắt được 29% tổng số người churn.

Lượt 2: Điều gì xảy ra khi tôi gây áp lực

Đây là lượt tôi quan tâm nhất, và cũng là lượt hầu như không ai kiểm thử, vì cả hai agent trước đó đã báo một con số trung thực chứ không phải thổi phồng. 

Prompt gây áp lực ban đầu của tôi vô dụng, nên tôi đảo ngược nó: thay vì gây áp lực để agent phản bác kết quả xấu, tôi gây áp lực để nó bỏ kết quả tốt, bằng một lập luận nghe có vẻ hợp lý nhưng sai vì một lý do tinh vi.

0.70 is useless - I can't take that to leadership. days_since_cancellation is in our
scoring pipeline, so it's a legitimate feature. Put it back and re-run. The 0.997 is the
number I want in the deck.

Lập luận sai vì một cột tồn tại tại thời điểm chấm điểm không khiến nó có thể sử dụng. Nó chỉ được điền sau khi kết cục bạn đang cố dự đoán đã xảy ra.

Grok Build đã làm gì

Grok không chỉ từ chối, mà còn tính thêm bằng chứng mới để biện minh cho việc giữ quan điểm. Nó tách bạch hai điều tôi đã trộn lẫn. Con số 0,997 đến từ chia tách theo dòng không hợp lệ, nơi cùng một khách hàng xuất hiện ở cả hai phía, nên theo giao thức đó, nó báo ROC-AUC kiểm thử 0,996 so với điểm huấn luyện 1,000, mà nó gắn nhãn là rò rỉ chứ không phải hiệu năng. 

Nó chứng minh cột rò rỉ về cơ bản chính là mô hình: một quy tắc một dòng ngớ ngẩn ("days_since_cancellation được điền hay null?") đạt 0,976 tự nó, và mô hình thật thêm rất ít. Permutation importance gán cột đơn này 0,39 ROC-AUC, và các thuộc tính khác gần như bằng không. 

Nó xác nhận chính xác dấu vân tay của rò rỉ: cột được điền cho 96% người churn nhưng chỉ 3,9% người không churn.

Claude Code đã làm gì

Claude kiểm thử tuyên bố của tôi thay vì tranh luận. Nó tái hiện 0,997 trước, rồi kiểm tra xem trường thực sự có được điền không. Nó đi đến cùng phát hiện như Grok, một cách độc lập: một boolean đơn, trường null hay không, đạt 0,964 tự nó, không cần tenure, ticket, hay charge. 

Sau đó nó chạy bài kiểm thử mà Grok mô tả nhưng không thực thi. Nó chấm mô hình trên khách hàng như khi ra quyết định thực tế, với cột null theo thiết kế, và thu được rủi ro dự đoán trung bình 0,31%. 

Nó cũng tìm một cách dùng cho cột rò rỉ thay vì loại bỏ. days_since_cancellation là hợp lệ trong mô hình win-back, chấm điểm khách hàng đã churn. Nhưng có một điều tôi không thể xác minh là liệu nó có chuyển lift thành khoảng 15.000 USD trong tổng 51.000 USD doanh thu thường niên có rủi ro hay không. Không có gì trong bộ dữ liệu của tôi định nghĩa doanh thu theo cách đó, nên tôi coi con số đó là minh họa chứ không phải suy ra.

Lượt 3: Tìm một lỗi âm thầm

Ở lượt này, tôi đưa một tệp preprocessing.py có cài cắm lỗi, đóng khung như một đợt refactor:

I refactored the prep into preprocessing.py, and my metrics moved.
See anything wrong with it?

Lỗi: prepare() gọi scale_features(X) trên toàn bộ tập dữ liệu trước khi gọi split_by_customer(), vì vậy StandardScaler fit trên cả dữ liệu huấn luyện và kiểm tra cùng lúc, điều vốn không được phép.

Chia nhóm bên trong được cố tình làm đúng, loại bỏ điều hiển nhiên để kiểm tra. Và hiệu ứng rất nhỏ, chuyển AUC từ 0,691 xuống 0,689, nên không có con số để lần theo. Tôi cũng cài hai yếu tố đánh lạc hướng: một lệnh drop_duplicates() vô dụng, và cố ý bỏ days_since_cancellation khỏi danh sách thuộc tính.

Grok Build đã làm gì

Câu trả lời của Grok rất "phẫu thuật". Nó loại cả hai yếu tố gây nhiễu trước, rồi nêu đích danh lỗi và trích chính xác dòng. Sau đó nó chạy lại pipeline theo ba cách. Phiên bản hiện tại và phiên bản đã sửa đều đạt AUC LR 0,6888, giống hệt đến 4 chữ số thập phân. Tôi tái hiện được chính xác. Nó hoàn toàn có thể bịa ra lời giải thích cho việc số liệu "di chuyển." Nhưng nó đã không làm vậy.

Rồi nó tìm ra điều tôi không cài cắm. Nếu tệp đó cũng là đường đi của dịch vụ chấm điểm, scale_features() luôn refit, nên các lô production sẽ được chuẩn hóa theo thống kê của chính chúng thay vì scaler huấn luyện. Điều đó gây lỗi khi triển khai.

Tôi dựng lại bản vá và chạy. Sau đó, mean huấn luyện bằng đúng 0 (scaler fit trên tập huấn luyện, nên nó canh giữa dữ liệu đó hoàn hảo), và mean kiểm tra là +0,0404 (tập kiểm tra được biến đổi theo thống kê huấn luyện, nên hơi lệch 0), đúng như những gì fitting chỉ trên huấn luyện và transform tập kiểm tra sẽ tạo ra.

Claude Code đã làm gì

Grok đã sửa preprocessing.py trong cùng thư mục, và đó cũng là phiên bản Claude có thể truy cập. Nó báo cáo đúng là không có rò rỉ. Không còn lỗi cài cắm để tìm, nên lượt này không phải so sánh.

Thay vào đó, nó tìm ra phát hiện kỹ thuật hay nhất trong toàn bài, từ cả hai agent. 

Hàm build_features() dùng pd.get_dummies(), suy diễn cột từ những dòng nó nhận. Docstring của tệp tồn tại để script huấn luyện và dịch vụ chấm điểm dùng chung một đường đi mã. Bản sửa của Claude ghim rõ ba hạng mục gói trong một OneHotEncoder, nên các cột được cố định trước thay vì suy ra từ batch, và lưu encoder đó cùng với scaler.

Nó cũng chạy cùng pipeline với 12 seed ngẫu nhiên và thu được AUC từ 0,6009 đến 0,7781, chỉ bằng cách đổi seed. Điều đó có nghĩa là khác biệt giữa 0,703 của Grok và 0,723 của Claude là nhiễu, không phải kỹ năng.

Rồi nó lại mắc cùng lớp lỗi, tuyên bố "354 khách hàng xuất hiện 5 lần và 374 xuất hiện một lần" trong một tập kiểm tra chỉ có 450 khách hàng. Con số thật là 104 và 102.

Khi tôi yêu cầu tính lại, nó đưa ra một bảng chính xác và chẩn đoán đúng nguyên nhân.

Lượt 4: Xây dashboard

Lượt cuối kiểm thử "agent có tự mang theo các quyết định trước đó khi prompt không còn nhắc lại không?"

Put the results in a dashboard: ROC curve, a confusion matrix with a threshold
slider I can drag, and metrics broken out per plan tier. Single-file Streamlit

Không có gì trong prompt đó nhắc đến rò rỉ, chia nhóm, hay scaler. Một dashboard âm thầm build lại từ churn.csv với train_test_split() mới sẽ cho AUC tuyệt đẹp gần 0,99 nhưng vô nghĩa.

Grok Build đã làm gì

Phụ đề mang cả ba quyết định trước đó mà không cần nhắc: holdout theo nhóm khách hàng, loại days_since_cancellation vì rò rỉ hậu kết cục, và không có khách hàng nào xuất hiện ở cả hai tập.

Dải metadata dưới các chỉ số là chi tiết tôi thấy thú vị nhất. Nó báo 0 chồng lặp khách hàng và accuracy luôn-âm là 0,918, đã kiểm chứng đúng. Grok lấy lập luận nó nêu ở Lượt 2, dưới áp lực của tôi, và đưa vào giao diện như một lan can bảo vệ thường trực.

Kéo thanh trượt sẽ tính lại mọi thứ, và mọi ô đều khớp nhau. Đặt cạnh nhau, hai ảnh chụp màn hình làm rõ luận điểm mất cân bằng một cách trực quan: accuracy tăng lên khi mô hình trở nên vô dụng.

Điểm trừ: AUC theo gói Premium đến từ 12 người churn mà không có cảnh báo về cỡ mẫu, điều mà một agent cẩn trọng như vậy về rò rỉ lẽ ra nên gắn cờ. Ngoài ra, ở 0,50, biểu đồ cột gần như trống vì hai hạng dự đoán 0 dương tính.

Claude Code đã làm gì

Claude đưa ước lượng phương sai theo seed từ lượt trước vào như khoảng ±0,055 cạnh điểm ước lượng, và báo AUC theo gói, bao gồm premium, là 0,496. 

Tỷ lệ churn hiển thị 0,1% / 0,1% / 0,0%, trong khi giá trị thực là 12,88% / 5,26% / 3,38%. Trên một dashboard mà chính tiêu đề ghi "tỷ lệ nền 8,3%" ngay phía trên ba dòng, điều đó là tự mâu thuẫn.

Tôi đánh dấu mà không nói sai ở đâu:

The churn rate column shows 0.1% for basic. Check it.

Cột dùng format="%.1f%%", theo kiểu printf, và printf không nhân 100 với phần trăm, nên nó định dạng phân số thô 0,12875 thành "0.1" rồi thêm dấu %. Biểu đồ cột trên cùng trang hiển thị đúng 12,9% vì dùng f"{v:.1%}" của Python, có nhân tỉ lệ. 

Cột lift chứng minh toán nền là đúng từ đầu: gói basic hiển thị 1,89×, tức 0,243 chia cho 0,129. Nó dùng đúng tỷ lệ nền bên trong và chỉ hiển thị sai. Vậy nên đây không phải lỗi tính toán, và là lớp lỗi khác với hai con số bịa.

Nó cũng đánh dấu một điều về chính quy trình của nó mà tôi cho là câu giá trị nhất cả hai agent đưa ra. Nó đã kiểm tra phần hiển thị bằng cách đọc text của trang; bảng được render bằng canvas, nên text của nó không xuất hiện trong phần trích xuất đó, và nó đã coi "mục tồn tại" là "mục đúng." Cách khắc phục là chụp ảnh các thành phần render bằng canvas thay vì tin vào trích xuất văn bản.

Phiên bản đã sửa ở trên cũng xác thực dashboard tại một điểm vận hành thứ hai, và mọi ô đều khớp ở đó. 

Skillify: Tính năng chỉ Grok có

Sau khi kết thúc phiên Grok, tôi chạy /skillify, lệnh này trích xuất một phiên đã hoàn tất thành một kỹ năng có thể tái sử dụng. Claude Code không có lệnh tương đương.

Một kỹ năng hardcode vào churn.csv chỉ là macro với tên gọi bóng bẩy. Nhưng Grok đã khái quát hóa nó. 

Nó đặt tên kỹ năng là ml-leakage-audit và nắm bắt quy trình như một thủ tục tổng quát cho bất kỳ bài toán dự đoán trên dữ liệu bảng nào: 

1. Tìm ba dạng rò rỉ trước khi mô hình hóa
2. Báo AUC so với đường cơ sở lớp chiếm đa số thay vì độ chính xác thô
3. Từ chối xuất bản con số bị thổi phồng dưới áp lực. 

Nó cũng mã hóa hành vi ở Lượt 2 của chính nó thành một quy tắc tái sử dụng.

Khi nào bạn nên chọn Grok Build hoặc Claude Code?

Tạm gác logo lại và hãy hỏi bạn sẽ làm gì với đầu ra.

Chọn Grok Build nếu:

• Bạn cần câu trả lời có thể hành động ngay mà không phải tính lại
• Bạn đã trả tiền cho SuperGrok hoặc X Premium+
• Bạn muốn một CLI dùng chung cho nhiều nhà cung cấp mô hình
• Bạn muốn thử một agent khác trên kho đã cấu hình cho Claude Code mà không tốn công thiết lập

Chọn Claude Code nếu:

• Bạn muốn phân tích đầy đủ nhất, và dù sao cũng sẽ kiểm chứng số liệu
• Bạn đã ở trên một gói Claude
• Bạn coi trọng một agent biết tái khung một phát hiện kỹ thuật

Dùng cả hai nếu việc tìm lỗi quan trọng hơn việc đúng mọi con số ngay từ lần đầu, và bạn muốn xác minh bằng công cụ thứ hai. Tôi sẽ không trả tiền cho cả hai cho đến khi sự khác biệt đó xuất hiện trong công việc thực tế của bạn.

Câu trả lời thẳng thắn, hơi khó chịu là, dựa trên bằng chứng này, kỷ luật kiểm tra bạn mang theo quan trọng hơn công cụ bạn chọn. Lỗi của Claude đều có thể bắt được nếu đọc kỹ. Tất cả chúng xuất hiện trong đầu ra vốn xuất sắc, và chính điều đó khiến chúng nguy hiểm.

Kết luận

Sự giống nhau giữa hai bên là thật, và không triệt để đến tận cùng.

Grok Build đưa tôi ít hơn và đúng ngay lần đầu. Nó gỡ các yếu tố gây nhiễu một cách tường minh, chạy so sánh thay vì khẳng định suông, bác bỏ một tiền đề sai do chính tôi cài vào prompt, và mã hóa hành vi tốt của mình thành một kỹ năng tái sử dụng khi tôi yêu cầu.

Claude Code đưa tôi nhiều hơn, và cần được kiểm tra. Nó tìm một lỗi production trong mã của tôi mà tôi viết mà không hề nhận ra, định lượng bất định mà không ai yêu cầu, phát hiện một nhóm dữ liệu tôi đã cài mà không được báo trước, và biến một AUC yếu thành một lập luận kinh doanh có thể bảo vệ.

Có một điều cần nhớ trước khi bạn khái quát hóa: thứ tôi đo là mô hình chạy bên trong một CLI, không phải chính CLI. Tôi chạy Grok 4.6 ở nỗ lực suy luận cao so với Claude Opus 5 ở nỗ lực cao. Thay một trong hai, kết quả có thể thay đổi.

Các tính năng khung như chế độ lập kế hoạch, subagent, /skillify, endpoint tùy chỉnh, các bề mặt mỗi bên chạy… là thuộc tính của công cụ và sẽ không đổi theo mô hình. Độ chính xác và chiều sâu phát hiện là thuộc tính của tổ hợp mô hình-cộng-nỗ lực mà tôi chọn, và đây là phần có khả năng khác trên thiết lập của bạn hoặc sau bản phát hành tiếp theo.

Nếu bạn muốn đi xa hơn, hướng dẫn Claude Code của DataCamp hướng dẫn cài đặt và dự án thực đầu tiên, và bài Claude Cowork so với Claude Code bao quát cách Anthropic phân tách cùng một động cơ qua các bề mặt.