Điểm nổi bật
- Engagement: 113 points, 31 comments.
- Luận điểm chính 1: AI chỉ hữu ích trong thiết kế mạch khi có bộ kiểm chứng bên ngoài như SPICE, scope hoặc script phân tích.
- Luận điểm chính 2: nhiều kỹ sư đồng tình rằng model dễ “tự khen mình” và hallucinate nếu không có ground truth rõ ràng.
- Luận điểm chính 3: thread chuyển từ demo sang bàn sâu về verifier design, model drift, local LLM và chi phí token trong các vòng debug.
Biểu đồ
Tóm tắt
Thread này thu hút vì nó không quảng bá AI như cây đũa thần, mà cho thấy nơi AI bắt đầu có ích trong kỹ thuật phần cứng: khi model bị ép làm việc trong một vòng lặp có dữ liệu kiểm chứng độc lập. SPICE simulation và dữ liệu từ oscilloscope đóng vai trò như test suite cho mạch điện, tương tự unit test trong coding.
Phần tranh luận sôi nổi nhất đến từ các kỹ sư từng thử cho model tự thiết kế mạch hoặc diễn giải file schematic. Nhiều người chia sẻ trải nghiệm rất giống nhau: model có thể mô tả tốt, tóm tắt tốt, nhưng dễ bịa pin, bịa khả năng của board hoặc chọn giải pháp điện tử rất tệ nếu không có verifier ép nó quay về thực tế.
Chi tiết
Điểm trung tâm của thread là một thông điệp khá chín chắn: trong những bài toán vật lý như mạch điện, model ngôn ngữ không thể tự xác nhận mình đúng. Một bình luận được đồng thuận mạnh cho rằng khi câu hỏi là “board này có chạy không”, bản thân model không sở hữu ground truth nên nó thường trượt về giọng điệu lạc quan, tự tin và giàu diễn giải hơn là đúng kỹ thuật. Vì vậy, giá trị thật của workflow mà tác giả trình bày không nằm ở việc Claude Code “giỏi điện tử” mà ở chỗ SPICE simulation và dữ liệu scope tạo ra lớp phản hồi mà model không thể tranh cãi bằng ngôn từ.
Nhiều người dùng khác xác nhận điều này bằng kinh nghiệm đau thương. Có người kể từng để Claude với Opus thiết kế board, kết quả là model “hallucinate” khả năng phần cứng và đưa ra những tuyên bố gần như vô nghĩa. Người khác nói AI khá tốt khi đọc file thô rồi mô tả những gì đang có, nhưng xuống tay tối ưu mạch hay suy luận từ nguyên lý vật lý thì nhanh chóng lạc hướng. Một kỹ sư khác mô tả cách sửa bài toán: không cho model đọc trực tiếp file KiCad rồi suy diễn, mà viết Python analyzer xuất JSON có cấu trúc, biến môi trường kỹ thuật thành thứ model khó hiểu sai hơn.
Thread cũng kéo cuộc tranh luận sang một hướng rất thực dụng: phần tốn token nhất không hẳn là thiết kế, mà là lúc verifier hoặc môi trường lỗi. SPICE convergence failure, missing model card, sai đường dẫn include, script bị security policy chặn, tất cả khiến agent đốt lượt suy luận vào lỗi hệ thống lặp đi lặp lại. Điều này rất quan trọng với doanh nghiệp đang cân nhắc AI cho engineering workflow, vì nó cho thấy chi phí vận hành agent không chỉ đến từ model, mà đến từ độ sạch của toolchain và chất lượng feedback loop.
Một lớp ý kiến khác nhìn thread như tín hiệu chuyển dịch sang local LLM hoặc ít nhất là mô hình dễ kiểm soát hơn. Khi service model thay đổi chính sách, tăng giá hoặc bị đánh giá là “anti-user”, kỹ sư trong thread lập tức quay lại câu hỏi nền tảng: nếu quy trình kiểm chứng đã chuẩn hóa bằng SPICE, scope và script, liệu có thể thay model backend bằng local model để giữ quyền kiểm soát hay không. Đồng thuận không nói local đã thắng, nhưng rất rõ một điều: AI chỉ đáng tin hơn khi nó bị ràng buộc vào phép đo, log và test, không phải khi nó được nói nhiều hơn.