Bộ prompt lập trình Claude để gỡ lỗi, tái cấu trúc và rà soát kiến trúc

Bốn ràng buộc giúp mọi prompt dưới đây hoạt động

Trước khi vào các prompt, đây là quy tắc chung cho tất cả. Thêm những điều này vào bất kỳ prompt lập trình nào sẽ cải thiện kết quả nhiều hơn cả việc đổi model.

Nêu rõ phiên bản bạn đang dùng. Dữ liệu huấn luyện thường lệch về phiên bản chính có nhiều tài liệu nhất, mà đó thường không phải phiên bản bạn đang dùng. Chúng tôi đang dùng [framework] [phiên bản], [ngôn ngữ] [phiên bản] giúp tránh phần lớn câu trả lời lỗi thời.

Giới hạn phạm vi thay đổi. Yêu cầu sửa lỗi mà không giới hạn, bạn thường nhận về một bản tái cấu trúc. 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ê từng dòng đã thay đổi kèm lý do một dòng là câu hữu ích nhất trong toàn bộ tài liệu này.

Yêu cầu giả thuyết trước khi đưa ra giải pháp. Một model được hỏi cái gì sai sẽ đưa ra một phỏng đoán trình bày như kết luận. Một model được yêu cầu xếp hạng nguyên nhân và cách kiểm tra rẻ tiền sẽ đưa ra một kế hoạch gỡ lỗi.

Bắt buộc chỉ ra kiểu lỗi có thể xảy ra. Điều này có thể làm hỏng gì, và đây có phải là sửa nguyên nhân hay chỉ sửa triệu chứng? phát hiện loại hỗ trợ AI tốn kém nhất, đó là một thay đổi làm triệu chứng biến mất trong khi lỗi gốc vẫn còn.

Gỡ lỗi

1. Giả thuyết xếp hạng

Đây là lỗi, đoạn code liên quan, và những gì tôi đã loại trừ. Đừng đưa ra giải pháp ngay. Liệt kê bốn nguyên nhân khả dĩ nhất xếp theo xác suất, và với mỗi nguyên nhân là 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ê]. Stack: [ngôn ngữ, framework, phiên bản].

2. Lỗi không cố định

Lỗi này xảy ra không cố định, tần suất khoảng [tần suất], trong điều kiện [điều kiện]. Liệt kê các nhóm nguyên nhân lỗi không cố định có thể gây ra triệu chứng cụ thể này: thời gian, thứ tự thực thi, cạn tài nguyên, một phụ thuộc bên ngoài, trạng thái rò rỉ giữa các lần chạy, múi giờ hoặc đồng hồ hệ thống, bộ nhớ đệm. Với mỗi nhóm, cho biết code hỗ trợ hay mâu thuẫn với nó, và chính xác tôi nên ghi log gì để phân biệt chúng. Code: [dán vào].

3. Chạy được ở máy local

Điều này chạy được ở máy local nhưng lỗi ở [môi trường]. Liệt kê mọi nhóm khác biệt môi trường có thể gây ra triệu chứng cụ thể này: cấu hình, biến môi trường, phiên bản, hệ thống tệp và phân biệt hoa thường, múi giờ và ngôn ngữ hệ thống, mạng và DNS, quyền truy cập, giới hạn tài nguyên, và khác biệt khi build hoặc đóng gói. Xếp hạng theo khả năng dựa trên triệu chứng, và cho tôi lệnh chẩn đoán cho từng mục.

4. Giải thích bản sửa trước khi tôi áp dụng

Giải thích tại sao bản sửa này hiệu quả, nó không sửa được gì, và nó có thể làm hỏng gì. Nếu nguyên nhân thực sự nằm ở chỗ khác và đây chỉ là vá triệu chứng, hãy nói thẳng ra.

Review code

5. Review một diff

Review diff này như một reviewer khắt khe. Các nhóm theo thứ tự ưu tiên: lỗi tính đúng đắn, vấn đề bảo mật, các trường hợp lỗi chưa được xử lý, race condition, rồi mới đến style. Với mỗi phát hiện, cho biết mức độ nghiêm trọng, dòng cụ thể, và tại sao nó quan trọng trong codebase này chứ không chung chung. Đừng bình luận về định dạng. Nếu diff ổn, hãy nói vậy thay vì cố tạo ra phát hiện. Quy ước: [mô tả]. Diff: [dán vào].

6. Lượt rà soát bảo mật

Review code này riêng cho vấn đề bảo mật: injection, lỗ hổng xác thực và phân quyền, deserialization không an toàn, bí mật lộ trong code hoặc log, dữ liệu đầu vào chưa kiểm chứng đi tới thao tác nhạy cảm, và rủi ro từ dependency. Với mỗi mục, mô tả cụ thể đường tấn công thay vì chỉ gọi tên nhóm. Nói rõ những gì bạn không thể đánh giá nếu không thấy [môi trường triển khai, lớp xác thực, độ nhạy cảm của dữ liệu].

7. Kiểm toán các kiểu lỗi có thể xảy ra

Với mỗi lệnh gọi bên ngoài trong code này, cho biết điều gì xảy ra khi nó chậm, khi nó thất bại, khi nó trả về dữ liệu bất thường, và khi nó thành công nhưng chỉ một phần. Trong số đó, cái nào hiện chưa được xử lý, và cái nào sẽ âm thầm trôi qua?

Prompt cuối cùng đó phát hiện nhiều vấn đề thực tế trong production hơn một lượt review thông thường, vì nó hỏi về những đường đi mà không ai từng viết test.

Tái cấu trúc và kiến trúc

8. Kế hoạch tái cấu trúc

Đề xuất một kế hoạch theo trình tự để tái cấu trúc [mô tả]. Ràng buộc: API công khai của [x] không được thay đổi, chúng tôi triển khai liên tục nên mỗi bước phải có thể release độc lập, và test phải pass sau mỗi bước. Với mỗi bước, cho biết thay đổi, rủi ro, cách kiểm chứng, và cách rollback. Xếp theo rủi ro, thấp nhất trước. Đừng viết code vội.

9. Lập luận cho phía đối lập

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. Điều gì phải đúng về ràng buộc của chúng tôi để B là lựa chọn đúng, và có điều nào trong số đó đúng ở đây không? Đừng kết luận rằng cả hai đều hợp lệ.

10. Hiểu những gì bạn kế thừa

Đây là các tệp mã nguồn chính. Hãy đưa ra: các điểm vào, luồng dữ liệu từ request đến response, trạng thái được chia sẻ và nơi nó bị thay đổi, các phụ thuộc bên ngoài và điều gì xảy ra khi từng cái không sẵn sàng, và ba khu vực nhiều khả năng chứa lỗi nhất dựa trên độ phức tạp và mức độ liên kết. Nói rõ những gì bạn không thể xác định từ những gì tôi cung cấp.

Yêu cầu cuối cùng đó rất quan trọng. Các model sẽ mô tả hành vi của một tệp bạn chưa dán vào, suy luận từ tên tệp. Bắt buộc liệt kê rõ những điều chưa biết sẽ cho bạn biết cần đi đọc gì.

Test

11. Những test bạn sẽ không nghĩ tới viết

Viết các trường hợp test cho hàm này, tập trung vào các đầu vào mà tôi có thể chưa nghĩ tới: giá trị biên, rỗng và null, unicode, giá trị rất lớn, các lệnh 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].

12. Kiểm tra bộ test hiện có

Đây là một hàm và các test hiện có của nó. Hành vi nào chưa được bao phủ? Cụ thể: các đường lỗi, giá trị biên, tương tác giữa các tham số, và bất cứ điều gì cách triển khai làm mà không test nào khẳng định. Đừng viết lại các test hiện có.

Prompt thứ hai có giá trị cao hơn và lại hiếm khi được dùng. Tỷ lệ độ phủ code cho bạn biết dòng nào đã chạy, không phải hành vi nào thực sự được chốt chặt, và khoảng cách giữa hai điều đó chính là nơi các regression ẩn náu.

Cách làm lấy ý kiến thứ hai

Đây là thói quen mang lại giá trị cao nhất trong toàn bộ bộ prompt này, và cũng là thói quen đòi hỏi nhiều hơn một model.

Lấy câu trả lời từ một model. Rồi chuyển sang model khác và đưa cho nó:

Một kỹ sư khác đã đề xuất giải pháp này cho vấn đề này. Hã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, 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ỏ sót. Nếu nó thực sự ổn, hãy nói thẳng thay vì bịa ra phản đối. Vấn đề: [dán vào]. Giải pháp đề xuất: [dán vào].

Có hai kết quả và cả hai đều hữu ích. Hoặc model thứ hai tìm ra một lỗ hổng thật sự, mà giờ bạn biết trước khi merge, hoặc nó đồng ý dù đã bị thúc ép phải phản đối, đó là một sự xác nhận có ý nghĩa. Lặp lại với cùng một model không cho bạn được điều nào trong hai điều đó, vì một model tự review kết quả của chính mình phần lớn sẽ đồng ý với chính nó.

Dùng cách này cho các quyết định mà sai sẽ tốn kém: thay đổi schema, sửa lỗi đồng thời, bất cứ điều gì chạm tới xác thực hoặc tiền bạc. Không dùng cho công việc thường ngày. Xem so sánh các model song song, chuyển đổi model giữa cuộc trò chuyện, và viết và gỡ lỗi code với nhiều model để có toàn bộ quy trình ở một nơi.

Những điều cần cảnh giác

API bịa đặt. Tên phương thức, tham số và khóa cấu hình được đưa ra một cách tự tin nhưng không tồn tại, đặc biệt với các thư viện vừa thay đổi gần đây. Cú pháp trông sẽ đú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ứ điều gì chưa quen thuộc.

Không có tín hiệu về độ tin cậy. Một bản sửa đúng và một bản sửa sai một cách tinh vi đến với độ chắc chắn giống hệt nhau. Giọng điệu không nói lên điều gì.

Mở rộng phạm vi âm thầm. Đây chính là lý do tồn tại của ràng buộc thứ hai.

Diễn kịch bảo mật. Gọi tên các nhóm lỗ hổng trong code của bạn là một bước rà soát đầu tiên hữu ích. Đó không phải là một cuộc kiểm toán, và model không biết mô hình đe dọa, môi trường triển khai, hay độ nhạy cảm dữ liệu của bạn.

Giữ các prompt bạn dùng hàng tuần ở nơi bạn có thể dán ra ngay, và đặt các ràng buộc cố định vào hướng dẫn của một project để chúng tự động áp dụng cho mọi cuộc trò chuyện trong project đó.