- Trong quá trình triển khai bằng Go thuật toán chữ ký ML-DSA — một thuật toán chữ ký kháng lượng tử do NIST chỉ định — đã phát sinh vấn đề khiến việc xác minh chữ ký thất bại
- Claude Code v2.0.28 đã nhanh chóng tìm ra một lỗi cấp thấp phức tạp chỉ với mã kiểm thử và đường dẫn mã nguồn
- Nguyên nhân được xác định là lỗi gộp hàm ở bước
Verify, nơi các bit cao của w1 bị tính lặp lại
- Trong thí nghiệm thứ hai tiếp theo, Claude cũng lần lượt tìm ra lỗi tính hằng số Montgomery và lỗi không khớp độ dài chữ ký
- Cả ba lần thử đều xác định thành công lỗi, cho thấy tiềm năng ứng dụng AI trong gỡ lỗi cấp thấp
Triển khai ML-DSA và vấn đề ban đầu
- Tác giả đã triển khai mới bằng ngôn ngữ Go ML-DSA (Post-Quantum Signature Algorithm) do NIST chỉ định
- Sau 4 ngày live-coding, trong lúc kiểm thử đã xuất hiện vấn đề hàm Verify từ chối mọi chữ ký
- Trong nhật ký kiểm thử, lỗi
invalid signature liên tục được in ra
- Vì quá mệt, tác giả dừng việc gỡ lỗi và yêu cầu Claude Code phân tích vấn đề
Lần gỡ lỗi đầu tiên của Claude Code
- Claude Code v2.0.28 (mô hình Opus 4.1, không có system prompt) được cung cấp các thông tin sau
- Lệnh chạy kiểm thử (
bin/go test crypto/internal/fips140/mldsa)
- Vị trí mã (
src/crypto/internal/fips140/mldsa)
- Mô tả rằng “chữ ký luôn bị từ chối” cùng gợi ý “w1 khác nhau”
- Chỉ trong vài phút, Claude đã trả về đề xuất sửa lỗi hoàn chỉnh
- Nguyên nhân là sau khi gộp
HighBits và w1Encode thành một, ở Verify kết quả của UseHint — vốn đã tạo ra các bit cao — lại tiếp tục bị lấy bit cao thêm lần nữa
- Tức là một lỗi cấu trúc khiến các bit cao của w1 bị tính hai lần
- Claude đã nắm được nguyên nhân ngay sau khi tải mã và tự viết kiểm thử để xác minh giả thuyết của mình
- Bản sửa được đề xuất không hoàn hảo, nhưng việc xác định đúng nguyên nhân cốt lõi đã rút ngắn thời gian gỡ lỗi
- Sau đó tác giả refactor
w1Encode để nhận bit cao làm đầu vào, đồng thời rút gọn cả quá trình chuyển đổi biểu diễn Montgomery
Thí nghiệm thứ hai: lỗi ở bước tạo chữ ký
- Việc triển khai tạo chữ ký cũng gặp lỗi kiểm thử
- Lỗi đầu tiên: tính sai các hằng số (1, -1) trong miền Montgomery
- Đây là vấn đề khó tìm, cần rất nhiều
printf và phỏng đoán, mất khoảng 1~2 giờ
- Lỗi thứ hai: sai độ dài của giá trị được đưa vào chữ ký (32-bit thay vì 32-byte)
- Do chênh lệch độ dài chữ ký nên tương đối dễ phát hiện
- Tác giả cho rằng hai lỗi này phù hợp để kiểm chứng năng lực của Claude, nên đã chạy lại Claude Code trên phiên bản mã trước đó
Kết quả lần gỡ lỗi thứ hai của Claude Code
- Ở prompt đầu tiên, Claude đã gỡ lỗi bằng
printf và theo dõi giá trị, rồi tìm ra hằng số sai và sửa nó
- Thời gian xử lý ngắn hơn con người, đồng thời xác định chính xác nguyên nhân khiến kiểm thử thất bại
- Ở prompt thứ hai, Claude đã tìm ra vấn đề không khớp độ dài chữ ký
- Sau khi lần theo nhiều hướng, Claude đưa ra đề xuất chỉ sửa độ dài cấp phát
- Bản sửa được đề xuất không hoàn hảo, nhưng đã chỉ đúng vị trí của lỗi cốt lõi
- Trong cả ba lần thử độc lập, Claude đều tự mình tìm ra chính xác nguyên nhân lỗi
Hiệu quả và hàm ý của gỡ lỗi bằng AI
- Cách tiếp cận của Claude tỏ ra hiệu quả như một trợ lý tự động chuyên dò tìm nguyên nhân khiến kiểm thử thất bại
- Người dùng không áp dụng nguyên trạng bản vá của Claude, mà chỉ xác nhận vị trí lỗi rồi tự sửa
- Tác giả đề cập tới nhu cầu về một công cụ kiểu LLM tự động phân tích và thông báo nguyên nhân khi kiểm thử thất bại
- So với chat đơn thuần hay tự động tạo PR, tác giả đánh giá hình thức tác tử gỡ lỗi dựa trên kiểm thử là lý tưởng hơn
Tài trợ và thông tin khác
- Việc bảo trì mã nguồn mở của tác giả được hỗ trợ thông qua Geomys, với sự tài trợ từ
Smallstep, Ava Labs, Teleport, Tailscale, Sentry
- Ava Labs nhấn mạnh tầm quan trọng của phát triển mã nguồn mở bền vững cho các giao thức mật mã
- Teleport giới thiệu nền tảng Teleport Identity nhằm ngăn chặn chiếm đoạt tài khoản người dùng và tăng cường kiểm soát truy cập
Phụ lục: hình ảnh và nhắc tới cá nhân
- Trong bài có xuất hiện Clippy của Microsoft Office cùng bong bóng thoại nói rằng “đã lấy bit cao của w1 hai lần”
- Cuối bài có ảnh mèo, được dùng như một chi tiết hài hước để làm dịu những tranh luận cảm tính về AI
2 bình luận
Gần đây mình có làm một chút về phát triển GPU kernel bằng
tritonhoặc CUDA, và nếu như ở bản 3.5 còn hiếm khi thấy nó chạy cho ra kết quả đúng đắn, thì sang 4.5 đã bắt đầu thấy nó tạo được code và tối ưu hóa tương đối ổn.Ý kiến trên Hacker News
Cách dùng coding agent để truy vết nguyên nhân gốc rễ của bug hoạt động khá tốt
Cả ba lần debug one-shot đều thành công. Điểm cốt lõi là LLM không trực tiếp sửa code, mà chỉ đóng vai trò trợ lý chỉ ra vị trí bug để tôi tự đánh giá và tự sửa
Cách tiếp cận này cũng có thể là điểm khởi đầu tốt cho cả những người hoài nghi LLM. Không cần để nó viết code thay, chỉ giao cho nó nhiệm vụ tìm những bug đau đầu
Đề xuất “phải sửa cái này” không hẳn là sai, nhưng nhiều khi lại không liên quan đến trọng tâm. Kết quả là các đề xuất chỉnh sửa vô ích cứ chồng chất lên nhau, và nếu lập trình viên junior làm theo nguyên xi thì chỉ làm tăng thêm công việc không cần thiết
Tôi cũng dùng các công cụ này, nhưng nhiều lúc có cảm giác “giải thích cho junior còn tốn thời gian hơn”
Việc sinh test cũng làm tốt ở phía thuật toán, nhưng trong các tình huống đồng thời thì vẫn có giới hạn. Dù vậy, cho mục đích “sinh test” hay “debug” thì vẫn đủ giá trị
Xét về refactor code hay bảo trì dài hạn thì vẫn còn thiếu nhiều
Tuy vậy, khi dùng nó như một bug hunter theo gợi ý trong bài blog thì hiệu quả đáng ngạc nhiên. Chỉ trong vài tuần đã bắt được nhiều bug môi trường production
Trước khi đào sâu vào code, để nó viết dài về tài liệu liên quan thì dù có sai sót cũng ít rủi ro hơn, và đây cũng là điểm khởi đầu tốt cho những người còn hoài nghi
Giao toàn bộ quá trình này cho máy móc thì có phần đáng tiếc. Săn bug giúp hiểu sâu cấu trúc hệ thống và về lâu dài sẽ giúp bạn trở thành lập trình viên giỏi hơn
Nếu thiếu trải nghiệm này thì cuối cùng có thể dẫn tới việc ngay cả phán đoán về code của chính mình cũng phụ thuộc vào LLM
Lời khuyên của tôi chỉ có một, AI First
Hãy thử ném vấn đề cho AI trước; làm vậy vừa học được giới hạn của mô hình vừa rèn được khả năng cấu trúc prompt
Các mô hình mới nhất đủ mạnh để có thể đối xử như đồng nghiệp trong phần lớn vấn đề. Nhưng điều quan trọng là phải hiểu kiểu thất bại của chúng và tích lũy trực giác
Mỗi khi có thế hệ mô hình mới ra mắt, tôi khuyên nên bỏ quy trình cũ và thử nghiệm với các mô hình mới nhất như GPT-5-Codex hay Sonnet 4.5
Nếu là chuyên gia trong lĩnh vực thì có thể phân biệt hallucination và lỗi của LLM, còn nếu không thì ngược lại chỉ tốn thời gian
Rốt cuộc các công cụ này hữu ích nhất với chuyên gia, còn với người mới thì chất lượng rất thất thường
Tôi cũng đã dùng Sonnet 4.5, nhưng chỉ thấy khá hơn bản trước một chút. Vẫn thường xuyên lãng phí thời gian
Anthropic đã cung cấp miễn phí cho tôi Claude Max trong vài tháng
Gần đây trên quảng cáo Instagram cũng tràn ngập nội dung liên quan đến Claude. Cứ liên tục thấy các quảng cáo như “cài Claude Code”, đủ để thấy đội marketing đang làm việc rất tích cực
Các lập trình viên thấy Claude Code rất hữu ích, và số người đăng ký gói 200 USD/tháng cũng nhiều. Nếu có lợi nhuận thì đổ tiền vào marketing là điều đương nhiên
LLM giúp ích khi tìm bug, nhưng cũng có lúc đưa ra giải thích lạc hướng khiến mất thời gian
Cuối cùng điều quan trọng là phải giữ tư duy phản biện
LLM là công cụ rất tốt, nhưng lại hay vội vàng kết luận. Chỉ cần con người ngừng suy nghĩ, mô hình sẽ lao đi theo hướng sai ngay
Tôi đồng ý với ý kiến rằng “dùng LLM chỉ ở dạng chat hay autocomplete thì không mấy hiệu quả”
Tôi cũng chỉ thật sự thấy tiềm năng khi dùng Claude Code/Codex. Nếu có chế độ chạy liên tục thì có lẽ còn thú vị hơn
Nó có thể vô tình xóa file hoặc phá hỏng kho Git. Vì thế tôi chỉ thử nghiệm trong môi trường sandbox
Tôi muốn một công cụ cộng tác theo phương pháp Socratic, nơi mô hình đặt câu hỏi cho tôi, còn tôi trực tiếp can thiệp và học hỏi
Cách tiếp cận “tập trung vào tự động hóa” hiện nay có nguy cơ biến lập trình viên thành người mù chữ về code. Ngược lại, nếu được thiết kế tốt thì nó có thể trở thành công cụ khuếch đại khả năng hiểu và trực giác
CLI terminal vẫn là một giao diện mạnh mẽ
Gemini CLI và Qwen Code đều miễn phí, và cũng dễ kết nối API tương thích OpenAI.
Các tác vụ đơn giản có thể tự động hóa, còn phần khó thì xử lý one-shot bằng Grok sẽ hiệu quả. Chỉ với CLI + MCP server + file MD cũng có thể tạo ra chương trình thông minh
Ý tưởng để LLM tự động phân tích nguyên nhân mỗi khi test thất bại khá thú vị
Có thể làm được bằng cách dùng Git hook để chạy Claude CLI.
Có thể xem ví dụ và cheat sheet trong hướng dẫn này
Có vẻ sắp tới sẽ xuất hiện các trường hợp dùng tấn công đối kháng vào dữ liệu huấn luyện LLM để dẫn tới lỗi mật mã học
Việc “bản sửa bao gồm cả thêm một hàm hoàn toàn mới” khiến tôi thấy nguy hiểm trong triển khai mật mã
Có vẻ như bài viết đang đưa ra lời khuyên sai
Code sửa đã bị bỏ đi, và con người tự viết lại. Ngược lại, đây có vẻ là một ví dụ sử dụng thận trọng và có trách nhiệm
Thay vì là “thợ sửa”, LLM nên được dùng như một máy dò rò rỉ khí gas, tức công cụ chỉ ra vị trí có vấn đề
LLM đã nhận diện được các mẫu mơ hồ trong code và loại bỏ nhiều vấn đề nhàm chán
Nhưng điều này đôi khi cũng thành tác dụng phụ. Codebase của tôi trông giống Node.js nhưng thực ra không phải, nên mô hình cứ liên tục nhầm nó là dự án Node