Mô hình chat và tác nhân code là hai công cụ khác nhau
Đáng để tách bạch ngay từ đầu, vì hai thứ này hay bị nhầm lẫn. Một công cụ code dạng tác nhân (agent) sống trong trình soạn thảo hoặc terminal của bạn, đọc repository và ghi file. Một không gian chat là nơi bạn suy nghĩ: bạn dán một stack trace, tranh luận về cách tiếp cận, review một diff, tìm hiểu một thư viện chưa từng dùng và soạn tài liệu thiết kế.
Hầu hết lập trình viên dùng cả hai, và phía chat là nơi việc chọn mô hình quan trọng nhất, vì bạn đang đọc phần suy luận chứ không phải diff. Đó cũng là lúc việc trả tiền cho ba gói thuê bao riêng để so sánh ba mô hình không còn hợp lý.
| Bạn đang làm gì | Xu hướng của mô hình | Ghi chú |
|---|---|---|
| Suy luận khó: đồng thời (concurrency), một race điều kiện tinh vi, đánh đổi kiến trúc | Claude và GPT khác nhau đáng kể | Hỏi cả hai. Đây là trường hợp một ý kiến thứ hai đáng giá |
| Tốc độ triển khai trên nền tảng quen thuộc | GPT | Nhanh, đúng phong cách, giỏi việc lặp lại và chuyển đổi |
| Đọc một codebase lạ lớn hoặc một spec dài | Gemini | Cửa sổ ngữ cảnh lớn nhất, nên chứa được nhiều hệ thống hơn cùng lúc |
| Giải thích một lỗi hoặc một khái niệm | Bất kỳ cách diễn giải nào phù hợp | Các mô hình giải thích khác nhau, và đó chính là điểm hay |
| Đầu ra có cấu trúc nghiêm ngặt: config, JSON, schema | GPT | Đáng tin cậy nhất khi phải tuân thủ đúng định dạng |
Các câu lệnh gỡ lỗi hay hơn việc chỉ dán stack trace
Dán một lỗi và hỏi cái gì sai tạo ra một phỏng đoán. Phỏng đoán đó thường đúng, và khi sai bạn mất hai mươi phút chạy theo một bản sửa nghe có vẻ hợp lý cho một vấn đề bạn không hề gặp phải. Những câu lệnh sau đây thay đổi hình dạng của câu trả lời.
Câu lệnh: giả thuyết trước khi sửa
Đây là lỗi, đoạn code, và những gì tôi đã loại trừ. Đừng đưa bản sửa ngay. Liệt kê bốn nguyên nhân khả dĩ nhất theo thứ tự xác suất, và với mỗi nguyên nhân, cách kiểm tra rẻ nhất để xác nhận hoặc loại trừ nó. Lỗi: [dán vào]. Code: [dán vào]. Đã loại trừ: [liệt kê].
Câu lệnh: lỗi chỉ xảy ra thỉnh thoảng
Lỗi này xảy ra ngắt quãng, khoảng [tần suất], trong [điều kiện]. Đây là đoạn code liên quan và những gì tôi biết về môi trường. Liệt kê các nhóm lỗi ngắt quãng có thể gây ra triệu chứng cụ thể này (thời gian, thứ tự, cạn kiệt tài nguyên, phụ thuộc bên ngoài, rò rỉ trạng thái giữa các lần chạy, đồng hồ hoặc múi giờ, cache). Với mỗi nhóm, cho biết bằng chứng nào trong những gì tôi đưa ra ủng hộ hoặc phản bác nó, và tôi nên ghi log gì để phân biệt chúng.
Câu lệnh: giải thích bản sửa trước khi tôi dùng nó
Giải thích vì sao bản sửa này hoạt động, nó không sửa được gì, và nó có thể làm hỏng gì. Nếu nguyên nhân gốc nằm ở chỗ khác và đây chỉ là bản vá triệu chứng, hãy nói thẳng ra.
Câu lệnh cuối đó bắt được loại hỗ trợ AI tốn kém nhất: một thay đổi khiến triệu chứng biến mất trong khi lỗi thật vẫn còn nằm trong codebase.
Hai mô hình cùng một vấn đề, đây không phải chiêu trò
Khi câu trả lời đã rõ ràng, một mô hình là đủ. Kỹ thuật này chỉ đáng giá với những vấn đề bạn không chắc chắn, và nó hiệu quả vì các mô hình thất bại theo cách khác nhau chứ không giống hệt nhau.
Cách dùng hữu ích không phải là hỏi cả hai rồi chọn cái bạn thích. Mà là hỏi một mô hình, rồi đưa câu trả lời đó cho mô hình kia:
Câu lệnh: review đối kháng cho một câu trả lời
Một kỹ sư khác đề xuất giải pháp này cho vấn đề này. Tìm ra điểm sai của nó: tính đúng đắn ở các trường hợp biên, đồng thời (concurrency), xử lý lỗi, hiệu năng ở [quy mô], hoặc một cách tiếp cận đơn giản hơn đã bị bỏ lỡ. Nếu nó thực sự ổn, hãy nói thẳng thay vì bịa ra phản bác. Vấn đề: [dán vào]. Giải pháp đề xuất: [dán vào].
Có hai kết quả, cả hai đều hữu ích. Hoặc mô hình thứ hai tìm ra một lỗ hổng thật, mà giờ bạn biết trước khi merge, hoặc nó đồng ý, đây là bằng chứng thật sự vì nó có mọi động lực để phản đối. So sánh điều đó với việc lặp lại cùng một mô hình, vốn có xu hướng đồng ý với chính nó.
Cùng mẫu này áp dụng cho các quyết định thiết kế:
Câu lệnh: bênh vực phía còn lại
Tôi đang chọn [cách tiếp cận A] thay vì [cách tiếp cận B] cho [bối cảnh và ràng buộc]. Hãy đưa ra lập luận mạnh nhất cho B. Ràng buộc của chúng ta cần phải như thế nào để B là lựa chọn đúng, và có điều nào trong số đó đúng ở đây không?
Tính năng so sánh song song của Whizi tồn tại chính vì mục đích này, và được ghi lại trong so sánh mô hình song song.
Review code và đọc code lạ
Câu lệnh: review một diff như một reviewer khó tính
Hãy review diff này. Các nhóm, theo thứ tự: lỗi đúng sai, vấn đề bảo mật, các trường hợp lỗi chưa xử lý, race condition, rồi mới đến style. Với mỗi phát hiện, cho mức độ nghiêm trọng, dòng cụ thể, và vì sao nó quan trọng ở đây chứ không phải nói chung chung. Đừng bình luận về định dạng. Nếu diff ổn, hãy nói vậy. Bối cảnh: codebase này dùng [stack và quy ước]. Diff: [dán vào].
Câu lệnh: hiểu một codebase bạn vừa được giao
Đây là các file mã nguồn chính. Hãy tạo ra: các điểm vào (entry point), luồng dữ liệu từ request đến response, trạng thái nào được chia sẻ và bị thay đổi ở đâu, các phụ thuộc bên ngoài và điều gì xảy ra khi mỗi cái không khả dụng, và ba phần có khả năng chứa lỗi nhất dựa trên độ phức tạp và mức độ liên kết. Hãy nói rõ những gì bạn không thể xác định từ những gì tôi đưa ra.
Câu lệnh cuối đó quan trọng hơn vẻ ngoài của nó. Các mô hình sẽ vui vẻ mô tả hành vi của một file bạn chưa dán vào, suy luận từ tên của nó. Buộc phải liệt kê rõ ràng những điều chưa biết sẽ cho bạn biết nên đọc gì tiếp theo.
Câu lệnh: viết bài test bạn chưa nghĩ tới
Hãy viết các test case cho hàm này, tập trung vào các đầu vào tôi có thể chưa xem xét: biên, rỗng và null, unicode, giá trị rất lớn, gọi đồng thời, và bất kỳ giả định ngầm nào trong cách triển khai. Với mỗi test, nêu rõ giả định nó đang kiểm tra. Hàm: [dán vào].
Những kiểu lỗi thực sự tốn thời gian
API bịa ra. Các mô hình tự tin tạo ra tên phương thức, tham số và khóa cấu hình không hề tồn tại, đặc biệt với các thư viện vừa thay đổi gần đây hoặc ít phổ biến. Chữ ký hàm sẽ trông có vẻ đúng. Hãy kiểm tra tài liệu thật trước khi xây dựng dựa trên bất cứ thứ gì bạn chưa quen.
Bản sửa sai nhưng tự tin. Giọng điệu không có tín hiệu gì cả. Một bản sửa giải quyết đúng vấn đề của bạn và một bản sửa tạo ra một lỗi mới tinh vi được đưa ra với sự tự tin y hệt nhau. Luôn hỏi thay đổi đó có thể làm hỏng gì.
Các mẫu code lỗi thời. Dữ liệu huấn luyện nghiêng về khối lượng code được viết cho một framework, mà thường là phiên bản lớn trước đó. Nếu câu trả lời cảm giác như từ vài năm trước, thì có lẽ đúng vậy. Hãy nói rõ bạn đang dùng phiên bản nào, ngay trong câu lệnh.
Phình phạm vi âm thầm. Yêu cầu một bản sửa và bạn thường nhận lại một bản tái cấu trúc (refactor). Thêm câu thay đổi càng ít càng tốt, và liệt kê mọi dòng bạn đã thay đổi cùng lý do để giữ diff dễ review.
Kịch bản bảo mật hình thức. Một mô hình có thể nêu tên các nhóm lỗ hổng trong code của bạn, điều này thực sự hữu ích cho một lượt kiểm tra đầu tiên, nhưng đó không phải là một cuộc audit. Nó không biết mô hình đe dọa, cách triển khai hay mức độ nhạy cảm dữ liệu của bạn.
Vị trí của việc này trong bộ công cụ còn lại của bạn
Nó không thay thế phần tích hợp trong trình soạn thảo hay công cụ code dạng tác nhân của bạn. Nó thay thế ba tab trình duyệt nơi bạn từng so sánh câu trả lời, cộng với hai gói thuê bao cần thiết để mở những tab đó cùng lúc.
Thiết lập thực tế mà hầu hết lập trình viên dùng: một mô hình mặc định cho các câu hỏi nhanh, một mô hình thứ hai bạn chuyển sang khi câu trả lời đầu tiên chưa thuyết phục, và Gemini khi bạn cần đưa một lượng lớn code hoặc một bản đặc tả dài vào trước một mô hình cùng lúc. Tất cả trong một luồng hội thoại, để bối cảnh bạn đã thiết lập được mang theo qua mỗi lần chuyển đổi thay vì phải dán lại.
Để tìm hiểu sâu hơn, xem AI cho lập trình, so sánh các lựa chọn thay thế tập trung vào coding, và bộ prompt coding của Claude. Cách vận hành thiết lập đó bên trong Whizi có trong viết và gỡ lỗi code với nhiều mô hình.
- Yêu cầu các giả thuyết xếp hạng và cách kiểm tra rẻ trước khi hỏi bản sửa
- Đưa câu trả lời của mô hình đầu tiên cho một mô hình khác và yêu cầu nó tìm lỗ hổng
- Luôn hỏi một bản sửa đề xuất có thể làm hỏng gì, và liệu đó có phải bản vá triệu chứng
- Nêu rõ ngôn ngữ, framework và phiên bản trong câu lệnh để tránh các mẫu code lỗi thời
- Xác minh mọi API lạ với tài liệu thật trước khi xây dựng dựa trên nó
- Thêm "thay đổi càng ít càng tốt và liệt kê mọi thay đổi" để giữ diff dễ review
- Dùng mô hình có ngữ cảnh lớn khi câu hỏi bao trùm nhiều code hơn mức vừa trong một prompt bình thường
Câu hỏi thường gặp
Vì sao không chỉ gắn bó với một mô hình coding?
Với công việc thường ngày, một mô hình là đủ. Giá trị xuất hiện ở những vấn đề bạn thực sự không chắc chắn, vì các mô hình thất bại ở những chỗ khác nhau chứ không phải cùng một chỗ. Đưa giải pháp đề xuất của mô hình A cho mô hình B và yêu cầu nó tìm lỗi hoặc là phát hiện ra vấn đề thật trước khi bạn merge, hoặc cho bạn sự xác nhận có ý nghĩa. Lặp lại với một mô hình duy nhất chủ yếu chỉ tạo ra sự đồng ý với chính nó.
Đây có phải là thứ thay thế cho công cụ code dạng tác nhân không?
Không, chúng giải quyết những vấn đề khác nhau. Một tác nhân (agent) sống trong repository của bạn và chỉnh sửa file. Một không gian chat là nơi bạn suy luận: stack trace, tranh luận thiết kế, review diff, tìm hiểu một thư viện lạ và soạn tài liệu thiết kế. Hầu hết lập trình viên dùng cả hai, và việc chọn mô hình quan trọng hơn ở phía chat vì bạn đang đánh giá phần suy luận chứ không phải diff kết quả.
Mô hình nào tốt nhất cho việc code?
Còn tùy vào tác vụ, đó là câu trả lời trung thực và cũng là lý do trang này tồn tại. GPT có xu hướng nhanh hơn và đúng phong cách hơn với công việc triển khai trên nền tảng quen thuộc. Claude có xu hướng mạnh hơn ở suy luận tinh vi, kiến trúc lạ, và giải thích vì sao thứ gì đó hoạt động theo cách đó. Gemini thắng khi câu hỏi cần giữ một lượng lớn code hoặc đặc tả cùng lúc. So sánh chúng trên các vấn đề thật của chính bạn trong một tuần sẽ hơn bất kỳ benchmark nào.
Tôi có thể dán code độc quyền không?
Whizi không huấn luyện trên các cuộc hội thoại của bạn, và chính sách dữ liệu của mỗi nhà cung cấp đều có thể xem trước khi bạn bật mô hình đó. Chính sách của công ty bạn thường là ràng buộc quyết định và nó rất khác nhau, nên hãy kiểm tra. Ở nơi có hạn chế, cách thực tế là tái tạo vấn đề trong một ví dụ tối giản chứa cấu trúc nhưng không có logic nghiệp vụ, điều này thường cho câu trả lời tốt hơn.
Làm sao để nó ngừng viết lại mọi thứ?
Hãy chỉ định rõ ràng: thay đổi càng ít càng tốt, giữ nguyên cấu trúc và cách đặt tên hiện có, và liệt kê mọi dòng bạn đã thay đổi kèm một dòng lý do. Việc tái cấu trúc không được yêu cầu là lý do chính khiến gợi ý AI trở nên khó review, và giới hạn diff tạo ra khác biệt giữa một thay đổi bạn có thể suy luận và một thay đổi bạn phải đọc lại từ đầu.