Tiếp theo, hãy nói về vấn đề giảm trí tuệ gần đây của claude code, phản hồi của tôi là, bạn phải có phương pháp để đảm bảo chất lượng phát triển phần mềm ngay cả khi cc không hoạt động. Làm thế nào để đạt được điều đó? Trước tiên, chúng ta không nói về cách làm, mà hãy nói về những thiếu sót thường gặp của vibe, đó là vấn đề mở hộp mù, mỗi lần đều là thao tác hộp đen, phải đi một vòng mới phát hiện ra điều gì đó không đúng, cảm xúc ngay lập tức trở nên khó chịu. Nói đến đây, giải pháp cũng đã rõ ràng. Biến quá trình hộp đen thành quá trình minh bạch, không phải lập tức coding, mà là dành nhiều thời gian hơn cho kế hoạch và giải pháp. 1. Nếu giải pháp có vấn đề, chất lượng coding cơ bản sẽ không tốt đến đâu. 2. Trong giai đoạn giải pháp có nhiều phương pháp, nhiều mô hình review là một công cụ hữu ích, đừng tin vào lời nói của cc, hãy tin vào đánh giá đồng nghiệp. 3. Khi mã đã hoàn thành, dựa trên việc biên dịch thành công và chức năng đáp ứng, hãy thêm một lần đánh giá nữa. Những phương pháp này mọi người có thể mở rộng ra, cc giảm trí tuệ thì sợ gì, tôi còn có warp và cline. Một vấn đề khá huyền bí khác là, khi nào dễ giảm trí tuệ, trực giác có thể là khi sức mạnh tính toán không đủ, cảm giác thời gian làm việc ở +8 khu vực có thể có xác suất cao hơn, vậy hãy thử đổi múi giờ để kiểm tra.

Nói về một quan sát của tôi về o3, thực ra o3 không giỏi trong công việc dẫn dắt, chẳng hạn như để nó chủ động thiết kế kế hoạch, loại công việc này nó làm không tốt lắm. Vậy nó giỏi cái gì? Nó giỏi phê bình, đúng vậy, chính là phê bình. Nếu bạn để nó khởi xướng công việc, chất lượng thì bình thường, nhưng nó là một nhà phê bình xuất sắc, và những nhận xét của nó rất đúng trọng tâm. Nếu có thể, tôi nghĩ quy trình tốt nhất là opus đưa ra kế hoạch, o3 đánh giá, mã viết xong cũng có thể để nó đánh giá. Bạn nói o3 thuộc loại mắt cao hơn tay? Cũng không sai, nhưng mắt cao hơn tay thì đúng rồi, chúng ta cần chính là đôi mắt biết phát hiện của nó, không cần tìm việc cho nó làm.