Các lời nhắc Claude mã: 25 lời nhắc sẵn sàng để sao chép và cách viết lời nhắc của riêng bạn

Khách hàng sử dụng phiếu giảm giá đã hết hạn sẽ nhận được lỗi 500 khi thanh toán. Kiểm tra tệp @src/checkout/coupons.ts và các bài kiểm thử của nó. Hành vi mong đợi là hiển thị thông báo "phiếu giảm giá không hợp lệ" mà không tạo đơn đặt hàng. Viết một bài kiểm thử thất bại để tái hiện lỗi, sau đó sửa lỗi mà không thay đổi hành vi của mã giảm giá hợp lệ. Chạy lệnh [checkout test] và hiển thị kết quả trước và sau khi sửa. Nếu bạn không thể tái hiện lỗi, hãy báo cáo những gì bạn đã kiểm tra trước khi thay đổi thực hiện.

Thêm bộ chọn ngày vào [đường dẫn biểu mẫu đặt lịch]. Tuân thủ các quy ước về thành phần và xác thực trong @src/components/TimeSelect.tsx. Người dùng phải có thể lựa chọn [các ngày được phép], trong khi [các ngày không khả dụng] vẫn bị vô hiệu hóa. Không thêm thư viện. Chạy [lệnh kiểm thử thành phần] và [lệnh kiểm tra kiểu], đồng thời báo cáo bất kỳ tiêu chí nào mà các kiểm tra này không bao phủ.

Chia tệp @src/reports/export.py thành các hàm nhỏ hơn mà vẫn giữ nguyên các tham số đầu vào, định dạng đầu ra và cách xử lý lỗi. Chạy lệnh [export test command] trước khi chỉnh sửa và báo cáo bất kỳ lỗi nào hiện có. Sau khi tái cấu trúc, chạy lại các bài kiểm thử và hiển thị cả hai kết quả. Không thay đổi giao diện công khai hoặc các tệp không liên quan.

“Claude kiểm tra từng thay đổi mà tôi triển khai lên claude.ai/code bằng phần mở rộng Claude cho Chrome. Nó mở trình duyệt, kiểm tra giao diện người dùng và lặp lại quá trình cho đến khi mã hoạt động và trải nghiệm người dùng (UX) trở nên tốt. ”

Kiểm tra tệp README, cấu hình dự án và cấu trúc thư mục cấp cao nhất của kho lưu trữ này. Chỉ tham khảo các tài liệu tham khảo khi cần thiết để giải thích:Ứng dụng thực hiện chức năng gìCác mục nhập chính và các thành phần chính của ứng dụngVị trí của các bài kiểm thử và các lệnh mà kho lưu trữ định nghĩa để chạy chúngTrích dẫn các đường dẫn tệp hỗ trợ cho lời giải thích của bạn. Phân biệt rõ ràng giữa hành vi được tài liệu hóa và các suy luận của riêng bạn, đồng thời đánh dấu bất kỳ điều gì bạn không thể xác định được. Không được đọc các tệp chứa thông tin bí mật hoặc tệp cấu hình môi trường, không kiểm tra các phụ thuộc đã cài đặt, cũng như không thay đổi bất kỳ tệp nào. Kết thúc bằng việc liệt kê ba tệp mà tôi nên đọc trước tiên và lý do tại sao.

Xem lại lịch sử Git của [tệp, hàm hoặc lớp], tập trung vào [câu hỏi về hành vi hoặc thiết kế]. Xác định các commit đã giới thiệu hoặc thay đổi đáng kể hành vi này. Đối với mỗi commit liên quan, cung cấp mã băm (hash) của nó, tóm tắt thay đổi và giải thích bất kỳ lý do nào được ghi trong thông điệp commit hoặc cuộc thảo luận liên quan mà bạn có thể truy cập. Nhãn các lý do suy luận là “suy luận”. Nếu lịch sử không giải thích được một quyết định, hãy nêu rõ điều đó. Không sửa đổi tệp hoặc lịch sử Git.

Theo dõi những gì xảy ra khi [hành động của người dùng hoặc sự kiện hệ thống], bắt đầu từ [lộ trình, trình xử lý hoặc thư mục đã biết]. Theo dõi các cuộc gọi liên quan qua các bước xác thực, logic nghiệp vụ và bất kỳ thao tác ghi vào cơ sở dữ liệu hoặc yêu cầu bên ngoài nào. Liệt kê các tệp và hàm theo thứ tự thực thi, kèm theo tham chiếu dòng mã nếu có. Giải thích các đường dẫn lỗi chính và xác định các bài kiểm thử hiện có bao phủ luồng này. Đánh dấu bất kỳ kết nối nào mà bạn không thể xác nhận từ mã nguồn. Không thực thi luồng, gọi các dịch vụ bên ngoài hoặc chỉnh sửa tệp.

Lập kế hoạch triển khai [tính năng] trong [khu vực kho lưu trữ]. Hành vi mong đợi là [yêu cầu], và các khu vực sau phải được giữ nguyên: [hạn chế]. Kiểm tra mã nguồn liên quan và các bài kiểm thử hiện có. Xác định các tệp cần thay đổi, thứ tự triển khai, cũng như các rủi ro về tương thích hoặc di chuyển dữ liệu. Phối hợp từng yêu cầu với một bài kiểm thử đề xuất hoặc bước xác minh khác. Danh sách công việc liệt kê riêng các câu hỏi chưa được giải quyết và các giả định. Chưa triển khai tính năng này. Gửi lại kế hoạch để tôi xem xét.

Tôi muốn xây dựng [mô tả ngắn gọn] cho [người dùng và trường hợp sử dụng]. Hãy đọc [các tệp hoặc yêu cầu liên quan] trước, sau đó sử dụng AskUserQuestion để làm rõ các quyết định có thể ảnh hưởng đáng kể đến việc triển khai. Tập trung vào các trường hợp ngoại lệ, xử lý dữ liệu, quyền truy cập, hành vi giao diện người dùng dự kiến và các sự đánh đổi. Đừng đặt những câu hỏi mà bối cảnh được cung cấp đã trả lời. Khi các quyết định chính đã được giải quyết, hãy soạn thảo một bản đặc tả bao gồm các yêu cầu, tiêu chí chấp nhận, các ràng buộc và những gì nằm ngoài phạm vi. Đánh dấu bất kỳ giả định nào còn lại. Hãy cho tôi xem bản đặc tả trước khi lưu nó vào [đường dẫn đặc tả] và đừng ghi đè lên tệp hiện có mà không có sự chấp thuận.

Đánh giá tác động của việc thay đổi [hàm, thành phần hoặc giao diện] từ [hành vi hiện tại] sang [hành vi đề xuất]. Tìm kiếm trong [phạm vi kho lưu trữ hoặc thư mục] để xác định định nghĩa, các hàm gọi trực tiếp, các lệnh nhập và các bài kiểm thử liên quan. Liệt kê các tệp có khả năng cần thay đổi và giải thích cách mỗi tệp có thể bị ảnh hưởng, kèm theo tham chiếu tệp và dòng mã (nếu có). Đánh dấu các lệnh gọi được giải quyết động, các thành phần bên ngoài hoặc các phụ thuộc khác mà bạn không thể xác minh. Xác định bất kỳ vấn đề tương thích nào cần được giải quyết trước khi triển khai. Không thay đổi tệp; gửi báo cáo đánh giá tác động và chờ tôi xem xét.

Thêm [tính năng] vào [tệp hoặc trang] với hành vi này: [tiêu chí chấp nhận]. Kiểm tra [cách triển khai hiện có] và tuân theo các quy ước của nó về việc lấy dữ liệu, xử lý lỗi và tổ chức các thành phần. Chỉ sử dụng các thư viện đã được cài đặt sẵn trong dự án. Giữ các thay đổi trong phạm vi [scope] và duy trì [hành vi hiện có hoặc giao diện công khai]. Thêm hoặc cập nhật các bài kiểm thử cho các tiêu chí chấp nhận. Chạy [lệnh kiểm thử] và [lệnh kiểm tra kiểu hoặc lint], sau đó báo cáo các tệp đã thay đổi, kết quả và bất kỳ kiểm tra nào bạn không thể hoàn thành. Nếu mẫu hiện có xung đột với yêu cầu, hãy giải thích xung đột đó trước khi tiếp tục.

Thực hiện [tên hàm] trong [tệp] để đáp ứng [yêu cầu]. Bao quát [trường hợp bình thường], [trường hợp biên] và [hành vi khi đầu vào không hợp lệ]. Chạy [lệnh kiểm thử liên quan] trước tiên và báo cáo bất kỳ lỗi nào hiện có. Viết các bài kiểm thử cho hành vi được yêu cầu, sau đó chạy chúng trước khi triển khai. Xác nhận rằng các bài kiểm thử mới thất bại vì lý do dự kiến. Triển khai hàm và chạy lại các bài kiểm thử. Không được làm yếu các điều kiện kiểm tra, bỏ qua các bài kiểm tra hoặc thay đổi hành vi dự kiến để khiến chúng vượt qua. Nếu các yêu cầu mâu thuẫn với các bài kiểm tra hiện có, hãy dừng lại và giải thích mâu thuẫn đó. Hiển thị kết quả trước và sau.

Triển khai thiết kế tệp đính kèm trong [thành phần hoặc trang], sử dụng các thành phần và kiểu dáng hiện có của dự án. Giữ nguyên [hành vi bắt buộc] và tránh các thay đổi ngoài [phạm vi]. Sử dụng [trình duyệt đã cấu hình hoặc công cụ ảnh chụp màn hình] để ghi lại [đường dẫn cục bộ] ở [kích thước khung nhìn] với [dữ liệu thử nghiệm và trạng thái giao diện người dùng]. Nếu công cụ hoặc ứng dụng không khả dụng, hãy báo cáo những gì cần thiết thay vì khẳng định đã kiểm tra trực quan. So sánh ảnh chụp với bản tham chiếu, tập trung vào [bố cục, không gian, kiểu chữ hoặc các tiêu chí chấp nhận khác]. Thực hiện tối đa [số lần] chỉnh sửa, sau đó báo cáo các khác biệt còn lại. Không được thay đổi hình ảnh tham chiếu. Chạy [các bài kiểm tra thành phần liên quan] và [lệnh kiểm tra kiểu hoặc lệnh xây dựng]. Bao gồm ảnh chụp màn hình đã thu được và kết quả kiểm tra thực tế trong bản tóm tắt của bạn.

Người dùng gặp phải [triệu chứng] khi [yếu tố kích hoạt hoặc đầu vào]. Hành vi mong đợi là [kết quả mong đợi]. Bắt đầu bằng cách kiểm tra [thư mục, hàm hoặc luồng] và các bài kiểm tra liên quan. Tạo một bài kiểm tra thất bại có thể tái hiện hành vi đã báo cáo. Nếu bạn không thể tái hiện được, hãy giải thích những gì bạn đã kiểm tra và thông tin nào còn thiếu trước khi thay đổi cách triển khai. Sau khi tái hiện được, khắc phục nguyên nhân mà không thay đổi [hành vi phải được giữ nguyên]. Chạy bài kiểm tra mới và [lệnh kiểm tra liên quan]. Hiển thị lỗi trước khi khắc phục, kết quả sau đó và bất kỳ lỗi nào còn lại.

[Lệnh xây dựng] thất bại trong [môi trường cục bộ hoặc CI] với kết quả như sau: [nhật ký lỗi đã được làm sạch]. Kiểm tra mã nguồn và cấu hình liên quan để xác định nguyên nhân. Kiểm tra sự khác biệt về môi trường hoặc phụ thuộc nếu lỗi không tái hiện được trên môi trường cục bộ. Thực hiện thay đổi nhỏ nhất để khắc phục nguyên nhân. Đừng vô hiệu hóa các kiểm tra, ẩn lỗi, bỏ qua các bài kiểm tra hoặc nới lỏng cài đặt trình biên dịch chỉ để có được một bản dựng thành công. Chạy lại bản dựng sau khi thay đổi. Nếu vẫn thất bại sau [số] lần cố gắng khắc phục, hãy dừng lại và báo cáo những gì bạn đã thử, lỗi hiện tại và bước chẩn đoán tiếp theo. Tóm tắt nguyên nhân và bao gồm kết quả xây dựng thực tế.

Giúp tôi thu hẹp phạm vi lỗi trước khi đề xuất cách khắc phục. Hành vi quan sát được: [điều gì xảy ra] Hành vi mong đợi: [điều gì nên xảy ra] Khi nào xảy ra: [điều kiện hoặc tần suất] Những gì tôi đã thử: [các bước và kết quả] Hãy đặt một câu hỏi tại một thời điểm, chọn câu hỏi có thể phân biệt rõ nhất giữa các nguyên nhân có khả năng xảy ra. Đừng lặp lại những câu hỏi mà thông tin đã cung cấp đã trả lời. Khi đã có đủ bằng chứng, hãy tóm tắt giả thuyết hàng đầu, những điều vẫn chưa rõ ràng và thử nghiệm nhỏ nhất có thể xác nhận hoặc loại trừ giả thuyết đó. Đừng chỉnh sửa tệp ngay lúc này.

Sử dụng một subagent để kiểm tra [sự khác biệt hoặc nhánh so với bản gốc] so với [kế hoạch đã được phê duyệt hoặc tệp yêu cầu]. Nếu các yêu cầu bị thiếu hoặc không rõ ràng, hãy báo cáo điều đó trước khi đánh giá tính đầy đủ. Kiểm tra xem mỗi yêu cầu có được triển khai hay không, các trường hợp ngoại lệ liên quan có được kiểm thử hay không, và liệu có bất kỳ thay đổi nào nằm ngoài phạm vi đã thỏa thuận hay không. Kiểm tra mã xung quanh khi cần thiết để hiểu sự khác biệt. Báo cáo các vấn đề về tính chính xác và các yêu cầu chưa được đáp ứng kèm theo tham chiếu đến tệp và dòng mã, tác động của chúng, cùng bằng chứng hỗ trợ cho từng phát hiện. Phân biệt các vấn đề đã được xác nhận với các câu hỏi chưa được giải quyết. Không được bịa đặt các phát hiện để đạt chỉ tiêu hoặc đưa vào các sở thích về phong cách không liên quan. Không được chỉnh sửa tệp.

Kiểm tra [tệp hoặc diff] để phát hiện các rủi ro tiêm mã độc, thiếu kiểm tra ủy quyền, thông tin bí mật bị lộ và việc xử lý đầu vào của người dùng không an toàn. Kiểm tra các hàm gọi liên quan và logic xác thực trước khi báo cáo phát hiện. Đối với mỗi vấn đề, xác định tệp và dòng mã bị ảnh hưởng, các điều kiện cần thiết để kích hoạt vấn đề, tác động có thể xảy ra và đề xuất cách khắc phục. Phân biệt giữa một đường dẫn đã được xác nhận là dễ bị tấn công và một vấn đề cần kiểm tra thêm. Không được sao chép các giá trị bí mật trong báo cáo, sửa đổi tệp hoặc thử nghiệm trên các dịch vụ đang hoạt động. Nêu rõ những khu vực bạn đã xem xét và những gì nằm ngoài phạm vi.

Tóm tắt cách bạn đã xác minh thay đổi đã hoàn thành so với [tiêu chí chấp nhận]. Đối với mỗi tiêu chí, liệt kê các bước kiểm tra đã thực hiện, lệnh chính xác (nếu có) và kết quả quan sát được. Bao gồm kết quả đầu ra liên quan, đồng thời che giấu các thông tin bí mật và dữ liệu nhạy cảm. Xác định riêng các lỗi đã tồn tại từ trước. Phân biệt rõ ràng giữa các bước kiểm tra đã vượt qua, các bước kiểm tra đã thất bại và các bước kiểm tra chưa được thực hiện. Giải thích lý do bỏ qua bất kỳ bước kiểm tra nào hoặc các giới hạn trong phạm vi kiểm tra. Không được mô tả toàn bộ thay đổi là đã được xác minh nếu vẫn còn một số tiêu chí chưa được kiểm tra.

Tái cấu trúc [tệp hoặc mô-đun] để đạt [mục tiêu cụ thể, chẳng hạn như tách một hàm lớn hoặc loại bỏ các hàm gọi lại lồng nhau]. Giữ nguyên giao diện công khai, giá trị trả về, hành vi khi gặp lỗi và các tác động phụ của nó. Chạy [lệnh kiểm thử liên quan] trước khi chỉnh sửa để thiết lập điểm chuẩn. Nếu kiểm thử thất bại, hãy báo cáo các lỗi trước khi tiếp tục. Xác định bất kỳ hành vi nào mà các bài kiểm thử hiện có chưa bao phủ và thêm các bài kiểm thử tập trung vào những phần cần thiết. Thực hiện việc tái cấu trúc mà không gây ra các thay đổi không liên quan hoặc tạo ra các phụ thuộc mới. Không làm suy yếu các khẳng định hiện có để phù hợp với triển khai. Chạy lại các bài kiểm thử và [lệnh kiểm tra kiểu hoặc lint]. Hiển thị kết quả trước và sau, tóm tắt các thay đổi về cấu trúc và đánh dấu bất kỳ hành vi nào bạn không thể xác minh.

Tìm các vị trí sử dụng [API hoặc thư viện cũ] trong [phạm vi thư mục], loại trừ các tệp được tạo tự động và tệp được cung cấp sẵn. Danh sách các tệp bị ảnh hưởng cùng bất kỳ cấu hình chung hoặc phụ thuộc nào mà quá trình di chuyển có thể tác động đến. Đề xuất ba tệp đại diện cho quá trình di chuyển thử nghiệm sang [API hoặc phiên bản mới], sử dụng [hướng dẫn di chuyển hoặc ví dụ hiện có]. Giải thích lý do lựa chọn chúng và đánh dấu bất kỳ thay đổi hành vi nào cần thiết. Chờ sự chấp thuận của tôi trước khi chỉnh sửa. Sau khi được chấp thuận, chỉ di chuyển các tệp thử nghiệm và các phụ thuộc chung đã được chấp thuận rõ ràng. Chạy [các bài kiểm thử liên quan] và [lệnh xây dựng hoặc kiểm tra kiểu]. Không mở rộng quá trình di chuyển sang các tệp khác. Báo cáo sự khác biệt, kết quả kiểm thử, các vấn đề tương thích và bất kỳ thay đổi nào cần thiết đối với phương pháp di chuyển. Dừng lại để xem xét trước khi tiếp tục với các tệp còn lại.

Kiểm tra nhánh hiện tại, trạng thái Git và diff cho [tính năng hoặc bản sửa lỗi]. Xác định các tệp thuộc về thay đổi này và liệt kê riêng các tệp không liên quan hoặc chưa được theo dõi. Soạn thảo thông điệp commit theo định dạng của 10 commit gần nhất. Chuẩn bị mô tả Yêu cầu Hợp nhất bao gồm những gì đã thay đổi, lý do, các bài kiểm tra đã thực sự chạy và bất kỳ giới hạn nào còn lại. Hiển thị danh sách tệp đề xuất, thông điệp cam kết và mô tả yêu cầu kéo trước khi đưa vào giai đoạn chờ hoặc xuất bản bất kỳ thứ gì. Chờ sự chấp thuận của tôi. Sau khi được chấp thuận, chỉ đưa các tệp đã thỏa thuận vào giai đoạn chờ, commit trên [nhánh tính năng], đẩy lên [máy chủ từ xa] và mở Yêu cầu Hợp nhất đối với [nhánh cơ sở]. Không sửa đổi các commit hiện có, không đẩy cưỡng chế hoặc hợp nhất. Trả lại mã băm commit và liên kết Yêu cầu Hợp nhất.

Soạn thảo phần README cho [module] dành cho [độc giả, chẳng hạn như kỹ sư backend mới tham gia dự án]. Bao gồm các điều kiện tiên quyết, thiết lập, ba lệnh mà họ sẽ sử dụng nhiều nhất và các lỗi phổ biến được hỗ trợ bởi mã hoặc tài liệu hiện có. Xác minh tên lệnh và các tùy chọn dựa trên [tập lệnh gói, Makefile, trợ giúp CLI hoặc cấu hình CI]. Đánh dấu bất kỳ điều gì bạn không thể xác nhận. Kiểm thử các lệnh cục bộ an toàn trong [môi trường thử nghiệm] nếu có sẵn. Trước khi chạy các lệnh cài đặt phụ thuộc, xóa tệp, di chuyển dữ liệu, triển khai hoặc truy cập dịch vụ bên ngoài, hãy giải thích tác động của chúng và xin phê duyệt. Phân biệt rõ ràng giữa các lệnh đã chạy thành công và các lệnh chỉ được kiểm tra dựa trên cấu hình hoặc tài liệu. Hiển thị phần README đề xuất trước khi chỉnh sửa [đường dẫn tài liệu] và giữ nguyên nội dung không liên quan.

Kiểm tra [đường dẫn đến CLAUDE.md] so với cấu trúc hiện tại của kho lưu trữ, các tập lệnh và quy ước. Chưa chỉnh sửa tệp này. Xác định các hướng dẫn lỗi thời, trùng lặp, mâu thuẫn và các quy tắc có thể suy ra một cách đáng tin cậy từ mã nguồn. Giải thích từng đề xuất loại bỏ thay vì chỉ cắt bớt hướng dẫn để rút gọn tệp. Chỉ đề xuất các lệnh xây dựng hoặc kiểm thử còn thiếu khi bạn có thể xác minh chúng trong các tập lệnh dự án, tệp Makefile, cấu hình CI hoặc tài liệu hiện có. Trích dẫn nguồn cho mỗi nội dung bổ sung. Trả về bản diff đề xuất mà vẫn giữ nguyên các ràng buộc quan trọng của dự án. Đánh dấu các hướng dẫn cụ thể cho từng công việc mà sẽ phù hợp hơn trong một quy tắc thuộc phạm vi kỹ năng hoặc đường dẫn, và chờ phê duyệt trước khi áp dụng các thay đổi.

Đề xuất một hook lệnh Claude Code để chạy [lệnh định dạng hiện có] sau khi thực hiện thay đổi bằng Edit hoặc Write đối với [các mẫu tệp]. Trước tiên, hãy kiểm tra cấu hình hiện có trong tệp claude/settings.json và cấu hình của trình định dạng. Sử dụng cấu hình PostToolUse phù hợp với phiên bản Claude Code đã cài đặt. Chỉ định dạng tệp bị ảnh hưởng, xử lý đường dẫn một cách an toàn và loại trừ [các tệp được tạo tự động hoặc các đường dẫn bị loại trừ khác]. Không cài đặt các phụ thuộc hoặc thay thế các hook hiện có. Hiển thị sự khác biệt (diff) của các cài đặt được đề xuất và giải thích cách báo cáo các lỗi của trình định dạng. Chờ phê duyệt trước khi áp dụng. Sau khi được phê duyệt, hãy thử nghiệm với một tệp tạm thời trong dự án và báo cáo kết quả. Nêu rõ các đường dẫn chỉnh sửa nào được bao phủ và các đường dẫn nào không, bao gồm cả các thay đổi được thực hiện thông qua lệnh shell.

Kiểm tra [công cụ] –help và phần trợ giúp cho các lệnh con liên quan đến [công việc]. Không cài đặt công cụ nếu nó thiếu; thay vào đó, hãy báo cáo yêu cầu tiên quyết đó. Đề xuất các lệnh chính xác cần thiết để hoàn thành công việc. Giải thích đầu vào, đầu ra của chúng và liệu chúng có ghi tệp, thay đổi tài nguyên từ xa hay sử dụng thông tin đăng nhập hay không. Bao gồm tùy chọn chạy thử (dry-run) nếu công cụ có tài liệu hướng dẫn về tùy chọn này. Đánh dấu các cấu hình hoặc quyền truy cập còn thiếu, và yêu cầu làm rõ thay vì đoán tên tài nguyên hoặc đích đến. Chờ phê duyệt trước khi chạy các lệnh của công việc. Sau khi được phê duyệt, chỉ chạy các lệnh đã được đồng ý và báo cáo kết quả thực tế của chúng, bao gồm bất kỳ lỗi hoặc bước chưa hoàn thành nào.

So sánh [invoices.csv] và [thanh toán.csv] bằng cách sử dụng [ID hóa đơn hoặc khóa khớp]. Không sửa đổi các tệp nguồn. Áp dụng các quy tắc sau: [tiền tệ và dung sai làm tròn], [phân bổ thanh toán một phần] và [xử lý hoàn tiền, tín dụng và thanh toán thừa]. Nếu thiếu quy tắc hoặc kết quả khớp không rõ ràng, hãy đánh dấu thay vì tự động gán khoản thanh toán. Giữ nguyên ID hàng nguồn. Đối với mỗi hóa đơn, hiển thị số tiền hóa đơn, các khoản thanh toán đã áp dụng và số dư còn lại. Báo cáo các ID trùng lặp, hóa đơn không khớp, khoản thanh toán không khớp và số dư nằm ngoài ngưỡng cho phép. Đối chiếu tổng số hóa đơn và tổng số thanh toán riêng biệt. Tính toán từng hàng nguồn mà không tính trùng lặp; nếu một khoản thanh toán được chia cho nhiều hóa đơn, hãy hiển thị từng khoản phân bổ và xác nhận rằng các khoản phân bổ đó không vượt quá tổng số thanh toán. Ghi kết quả vào [đường dẫn đầu ra mới] và tóm tắt các trường hợp ngoại lệ cần xem xét.

Viết một tập lệnh tóm tắt [export.csv] cho khoảng thời gian từ [ngày và giờ bắt đầu, bao gồm cả ngày và giờ này] đến [ngày kết thúc, không bao gồm ngày và giờ này], sử dụng [múi giờ] và [cột ngày]. Nhóm các bản ghi theo [quy tắc phân loại] và tính toán [các chỉ số bắt buộc]. Xử lý các ID trùng lặp và các giá trị thiếu theo [quy tắc]. Không sửa đổi tệp đầu vào. Chạy tập lệnh trên [tệp đầu vào chính xác]. Báo cáo số lượng hàng được bao gồm và bị loại trừ, tổng số theo danh mục và các bản ghi không thể phân loại. So sánh kết quả cho [ba danh mục] với số lượng đã được kiểm tra độc lập trong [tệp tham chiếu]. Nếu không có số lượng đó, hãy cho biết rằng việc xác nhận độc lập vẫn chưa được thực hiện. Hiển thị các điểm khác biệt và lưu báo cáo vào [đường dẫn đầu ra mới].

Đọc [các tệp hoặc thư mục được chỉ định] và soạn thảo một [loại tài liệu và độ dài] dành cho [đối tượng], bao quát [các câu hỏi hoặc chủ đề]. Hỗ trợ mỗi khẳng định sự thật trong tài liệu bằng tên tệp và tham chiếu trang, phần hoặc dòng (nếu có). Phân biệt trích dẫn trực tiếp với diễn giải lại, và không coi một đề xuất hoặc tài liệu đã lỗi thời là quyết định hiện tại đã được xác nhận. Ghi chú các nguồn mâu thuẫn, thông tin thiếu sót và các khẳng định mà bạn không thể xác minh. Không được lấp đầy các khoảng trống bằng các giả định hoặc chỉnh sửa các tệp nguồn. Gửi lại bản nháp kèm theo các tham chiếu và một danh sách ngắn các câu hỏi chưa được giải quyết cho người đánh giá.

Để tùy chỉnh một mẫu, hãy thay thế các trường giữ chỗ bằng thông tin chi tiết từ dự án của bạn và quyết định việc cần làm trước khi thực hiện các thay đổi. Sử dụng các bước này để chuẩn bị yêu cầu và xem xét kết quả.

Đối với một thay đổi nhỏ và được xác định rõ ràng, bạn có thể yêu cầu Claude thực hiện trực tiếp. Đối với mã nguồn chưa quen thuộc, các thay đổi liên quan đến nhiều tệp hoặc các yêu cầu chưa được làm rõ, hãy bắt đầu bằng việc lập kế hoạch.

Nhấn Shift+Tab cho đến khi chế độ Lập kế hoạch xuất hiện, hoặc khởi chạy Claude Code bằng lệnh claude --quyền truy cập cao kế hoạch. Trong chế độ này, Claude có thể kiểm tra các tệp và thực thi các lệnh chỉ đọc mà không chỉnh sửa mã nguồn của bạn. Xem xét các tệp, phụ thuộc và bài kiểm thử được đề xuất trước khi phê duyệt triển khai. Nhấn Ctrl+G để mở kế hoạch được đề xuất trong trình chỉnh sửa của bạn.

Cung cấp cho Claude các bằng chứng cần thiết để hiểu công việc: tham chiếu tệp, nhật ký lỗi đã được làm sạch, ảnh chụp màn hình hoặc tài liệu yêu cầu. Sử dụng ký tự @ kèm theo đường dẫn tệp để bao gồm nội dung của tệp đó.

Chọn tập hợp nguồn nhỏ nhất nhưng vẫn hữu ích. Việc bao gồm toàn bộ nhật ký hoặc thư mục có thể thêm vào các thông tin không liên quan và làm mất bối cảnh. Loại bỏ thông tin đăng nhập và dữ liệu nhạy cảm trước khi chia sẻ nhật ký, đồng thời kiểm tra xem Claude có các công cụ cần thiết để truy xuất bất kỳ URL tài liệu nào bạn cung cấp hay không.

Ví dụ: lệnh `cat lỗi.log | claude -p "Giải thích lỗi này"` sẽ gửi nhật ký dưới dạng yêu cầu không tương tác. Chỉ nên sử dụng lệnh này sau khi đã kiểm tra nội dung của tệp. Đây chính là giá trị thực tiễn của trí tuệ nhân tạo bối cảnh: cung cấp cho mô hình thông tin liên quan đến công việc.

Khi thêm một tính năng, hãy xác định một thành phần hoặc hàm tương tự trong kho lưu trữ. Hướng dẫn Claude tuân theo các quy ước nào, chẳng hạn như client API, logic xác thực, xử lý lỗi hoặc cấu trúc kiểm thử.

“Theo dõi cách @src/widgets/Weather.tsx lấy và lưu trữ dữ liệu” cung cấp cho Claude một tham chiếu cụ thể. Đồng thời, hãy nêu rõ bất kỳ sự khác biệt nào mà tính năng mới yêu cầu để tránh sao chép các hành vi không còn phù hợp. Các quy ước này nên phản ánh quy trình phát triển phần mềm của nhóm bạn.

Đối với các thay đổi mã nguồn, hãy chỉ định lệnh kiểm thử, lệnh xây dựng hoặc lệnh lint liên quan cùng với hành vi cần kiểm tra. Đối với nghiên cứu, hãy yêu cầu tham chiếu tệp hoặc ID commit. Đối với công việc liên quan đến giao diện người dùng (UI), hãy cung cấp hình ảnh tham chiếu và cách thức đã được cấu hình để chụp lại bản triển khai trong cùng một khung nhìn.

Yêu cầu Claude báo cáo những gì nó đã thực sự kiểm tra, bao gồm cả các lỗi và các kiểm tra bị bỏ qua. Kiểm tra xem bằng chứng có đáp ứng yêu cầu hay không; việc xây dựng thành công không đảm bảo rằng mọi hành vi được yêu cầu đều hoạt động đúng.

Đối với các công việc dài hơn, Claude Code còn cung cấp điều kiện /goal và các hook dừng (Stop hooks). Bộ đánh giá mục tiêu (goal evaluator) sẽ đánh giá các bằng chứng xuất hiện trong cuộc hội thoại thay vì kiểm tra các tệp hoặc chạy các bài kiểm thử một cách độc lập. Một hook dừng đã được cấu hình có thể ngăn chặn việc hoàn thành công việc, nhưng nó có giới hạn về việc chặn lặp lại. Cả hai đều không thể thay thế cho các bài kiểm thử thích hợp và việc đánh giá của con người.

Nếu việc sửa lỗi lặp đi lặp lại vẫn không giải quyết được vấn đề, hãy dừng lại và xác định xem yêu cầu ban đầu còn điểm nào chưa rõ ràng. Lưu lại các phát hiện hữu ích, trạng thái Git hiện tại và công việc còn lại trước khi xóa cuộc hội thoại.

Hướng dẫn thực hành tốt nhất của Anthropic khuyến nghị nên bắt đầu lại từ đầu sau hai lần sửa lỗi không thành công đối với cùng một vấn đề. Sử dụng lệnh /clear, sau đó cung cấp một lời nhắc đã được sửa đổi bao gồm những gì bạn đã học được. Việc xóa lịch sử cuộc hội thoại sẽ không làm hủy bỏ các thay đổi trên tệp.

Nhấn phím Esc để ngắt một phản hồi đang chạy. Khi ô nhập lệnh trống, nhấn phím Esc hai lần để mở menu quay lại và chọn nội dung cần khôi phục. Chức năng quay lại không hủy bỏ mọi tác động bên ngoài, do đó hãy sử dụng các điểm kiểm tra Git và các quy trình khôi phục riêng biệt cho các thay đổi đối với cơ sở dữ liệu hoặc dịch vụ từ xa.

Lưu hướng dẫn chung cho toàn dự án trong tệp CLAUDE.md, các quy trình có thể lặp lại trong các kỹ năng (skills) và hướng dẫn cho các tệp cụ thể trong các quy tắc có phạm vi theo đường dẫn. Sử dụng các hook cho các hành động liên kết với các sự kiện cụ thể, chẳng hạn như chạy công cụ định dạng sau khi chỉnh sửa.

Chọn dựa trên thời điểm mà hướng dẫn đó nên được áp dụng:

Yêu cầu đối với một tính năng thường nên được đưa vào lời nhắc công việc hoặc thông số kỹ thuật của tính năng đó, thay vì trong tệp CLAUDE.md. Việc thêm các hướng dẫn tạm thời vào tệp áp dụng cho toàn dự án sẽ khiến chúng khó phân biệt hơn với các quy ước cần được áp dụng trên toàn bộ kho lưu trữ.

Ví dụ: lưu lệnh kiểm thử của dự án trong tệp CLAUDE.md, đặt các quy ước cụ thể cho từng thành phần vào quy tắc có phạm vi đường dẫn và lưu quy trình đánh giá định kỳ dưới dạng kỹ năng. Hãy xem lại các tệp này khi lệnh hoặc quy ước thay đổi, giống như cách bạn làm với các tài liệu dự án khác.

Các lời nhắc, tệp CLAUDE.md và hướng dẫn kỹ năng định hướng hành vi của Claude; chúng không đảm bảo rằng một chỉ thị sẽ được tuân thủ. Các hook có thể thực hiện kiểm tra tại các sự kiện đã được cấu hình, nhưng độ tin cậy của chúng phụ thuộc vào loại hook và cách triển khai.

Một hook lệnh thực thi một skript. Một prompt hoặc hook đại lý dựa vào phán đoán của mô hình. Như hướng dẫn thực hành tốt nhất của Anthropic giải thích: “Một prompt hoặc hook đại lý yêu cầu một mô hình khác đưa ra quyết định, do đó nó cũng không mang tính xác định.” Đối với một quy tắc cần được áp dụng, hãy sử dụng các biện pháp kiểm soát quyền truy cập phù hợp và kiểm thử hook lệnh hoặc HTTP liên quan, bao gồm cả cách nó xử lý các trường hợp lỗi.

Các subagent tùy chỉnh là một cách khác để tổ chức công việc lặp lại. Hãy định nghĩa một chuyên gia trong thư mục `claude/agents/` khi cần một vai trò đánh giá riêng biệt hoặc phạm vi công cụ cụ thể, thay vì thêm từng hướng dẫn chuyên gia vào phiên làm việc chính. Các hướng dẫn về mô hình Claude tốt nhất cho công việc và các loại tác nhân AI này cung cấp thêm bối cảnh.

Nếu nhóm của bạn duy trì các lời nhắc trên nhiều sản phẩm AI khác nhau, hãy tham khảo các công cụ thiết kế lời nhắc này để quản lý thư viện ngoài Claude Code.

Khi một phiên làm việc cho ra kết quả chưa hoàn chỉnh hoặc không phù hợp, hãy kiểm tra xem yêu cầu có để lại những quyết định quan trọng chưa được giải quyết hay không. Năm sai lầm này có thể khiến việc chẩn đoán và đánh giá công việc trở nên khó khăn hơn.

“Khám phá kho lưu trữ” không cung cấp cho Claude nhiều hướng dẫn về những tệp nào quan trọng hoặc khi nào nên dừng lại. Bạn có thể nhận được một bản tóm tắt chung chung mà không có câu trả lời cho vấn đề đã dẫn đến yêu cầu đó.

Đặt tên cho hành vi hoặc quyết định mà bạn cần hiểu, xác định địa điểm bắt đầu và xác định kết quả đầu ra mong đợi. Ví dụ: “Theo dõi cách điểm cuối này kiểm tra quyền truy cập và trích dẫn các hàm liên quan.” Nếu bạn sử dụng các tác nhân phụ, hãy đưa ra cho mỗi tác nhân một câu hỏi có giới hạn thay vì giao cho chúng cùng một nhiệm vụ tìm kiếm không giới hạn.

Việc chuyển đổi giữa một tính năng, một lỗi không liên quan và một yêu cầu tài liệu khiến cuộc hội thoại mang theo bối cảnh có thể không áp dụng cho công việc hiện tại. Các tham chiếu như “tập tin đó” hoặc “cách tiếp cận trước đây” trở nên mơ hồ.

Sử dụng các phiên làm việc riêng biệt cho các công việc không liên quan. Nếu nhiều phiên làm việc sẽ chỉnh sửa kho lưu trữ, hãy sử dụng các Git worktrees riêng biệt để chúng không sửa đổi cùng một thư mục làm việc. Một câu hỏi phụ ngắn gọn: lệnh /btw của Claude Code giúp giữ cuộc trao đổi này tách biệt khỏi lịch sử cuộc hội thoại chính.

Một bản dựng có thể vượt qua kiểm tra trong khi một tính năng lại hoạt động không chính xác. Một bộ kiểm thử có thể vượt qua vì nó chưa bao giờ thử nghiệm với đầu vào gây lỗi. Yêu cầu Claude “chạy các bài kiểm thử” không xác định được yêu cầu nào mà các bài kiểm thử đó đang xác minh.

Liên kết các tiêu chí chấp nhận với các bước kiểm tra cụ thể. Đối với việc sửa lỗi, yêu cầu bằng chứng cho thấy bài kiểm tra tái hiện đã thất bại trước khi thực hiện thay đổi và thành công sau đó. Giữ các tiêu chí chưa được kiểm tra ở trạng thái hiển thị thay vì coi một lệnh thành công là bằng chứng xác minh cho toàn bộ thay đổi.

Một tệp CLAUDE.md đang được mở rộng có thể chứa các lệnh đã lỗi thời, các quy tắc trùng lặp và các hướng dẫn mâu thuẫn với các yêu cầu cụ thể của công việc. Việc thêm các từ ngữ mạnh mẽ hơn sẽ không giải quyết được những mâu thuẫn đó.

So sánh tệp với kho lưu trữ hiện tại. Loại bỏ các hướng dẫn đã lỗi thời, làm rõ các quy tắc mâu thuẫn và chuyển các hướng dẫn chỉ áp dụng trong phạm vi hẹp sang các quy tắc hoặc kỹ năng có phạm vi áp dụng theo đường dẫn. Nếu một yêu cầu cần được thực thi, hãy cấu hình và kiểm thử các biện pháp kiểm soát phù hợp thay vì dựa vào các lời nhắc nhở lặp đi lặp lại.

Một lần đánh giá có thể chỉ ra các lỗi thực sự, các vấn đề chưa rõ ràng và các đề xuất tái cấu trúc tùy chọn cùng một lúc. Việc áp dụng mọi đề xuất có thể làm mở rộng phạm vi thay đổi mà không cải thiện được hành vi mong muốn.

Yêu cầu cung cấp bằng chứng và đánh giá tác động đằng sau mỗi phát hiện. Ưu tiên các vấn đề về tính chính xác và các yêu cầu chưa được đáp ứng, điều tra các tuyên bố chưa rõ ràng, và loại bỏ các cải tiến không liên quan khỏi bản diff hiện tại. Người đánh giá nên có thể báo cáo không có phát hiện nào cần xử lý khi bằng chứng hỗ trợ kết luận đó.

Để tùy chỉnh một mẫu, hãy thay thế các trường giữ chỗ bằng thông tin chi tiết từ dự án của bạn và quyết định việc cần làm trước khi thực hiện các thay đổi. Sử dụng các bước này để chuẩn bị yêu cầu và xem xét kết quả.

Đối với một thay đổi nhỏ và được xác định rõ ràng, bạn có thể yêu cầu Claude thực hiện trực tiếp. Đối với mã nguồn chưa quen thuộc, các thay đổi liên quan đến nhiều tệp hoặc các yêu cầu chưa được làm rõ, hãy bắt đầu bằng việc lập kế hoạch.

Nhấn Shift+Tab cho đến khi chế độ Lập kế hoạch xuất hiện, hoặc khởi chạy Claude Code bằng lệnh claude --permission-mode plan. Trong chế độ này, Claude có thể kiểm tra các tệp và thực thi các lệnh chỉ đọc mà không chỉnh sửa mã nguồn của bạn. Xem xét các tệp, phụ thuộc và bài kiểm thử được đề xuất trước khi phê duyệt triển khai. Nhấn Ctrl+G để mở kế hoạch được đề xuất trong trình chỉnh sửa của bạn.

Cung cấp cho Claude các bằng chứng cần thiết để hiểu công việc: tham chiếu tệp, nhật ký lỗi đã được làm sạch, ảnh chụp màn hình hoặc tài liệu yêu cầu. Sử dụng ký tự @ kèm theo đường dẫn tệp để bao gồm nội dung của tệp đó.

Chọn tập hợp nguồn nhỏ nhất nhưng vẫn hữu ích. Việc bao gồm toàn bộ nhật ký hoặc thư mục có thể thêm vào các thông tin không liên quan và làm mất bối cảnh. Loại bỏ thông tin đăng nhập và dữ liệu nhạy cảm trước khi chia sẻ nhật ký, đồng thời kiểm tra xem Claude có các công cụ cần thiết để truy xuất bất kỳ URL tài liệu nào bạn cung cấp hay không.

Ví dụ: lệnh `cat lỗi.log | claude -p "Giải thích lỗi này"` sẽ gửi nhật ký dưới dạng yêu cầu không tương tác. Chỉ nên sử dụng lệnh này sau khi đã kiểm tra nội dung của tệp. Đây chính là giá trị thực tiễn của trí tuệ nhân tạo dựa trên ngữ cảnh: cung cấp cho mô hình thông tin liên quan đến công việc.

Khi thêm một tính năng, hãy xác định một thành phần hoặc hàm tương tự trong kho lưu trữ. Hướng dẫn Claude tuân theo các quy ước nào, chẳng hạn như client API, logic xác thực, xử lý lỗi hoặc cấu trúc kiểm thử.

“Theo dõi cách @src/widgets/Weather.tsx lấy và lưu trữ dữ liệu” cung cấp cho Claude một tham chiếu cụ thể. Đồng thời, hãy nêu rõ bất kỳ sự khác biệt nào mà tính năng mới yêu cầu để tránh sao chép các hành vi không còn phù hợp. Các quy ước này nên phản ánh quy trình phát triển phần mềm của nhóm bạn.

Đối với các thay đổi mã nguồn, hãy chỉ định lệnh kiểm thử, lệnh xây dựng hoặc lệnh lint liên quan cùng với hành vi cần kiểm tra. Đối với nghiên cứu, hãy yêu cầu tham chiếu tệp hoặc ID commit. Đối với công việc liên quan đến giao diện người dùng (UI), hãy cung cấp hình ảnh tham chiếu và cách thức đã được cấu hình để chụp lại bản triển khai trong cùng một khung nhìn.

Yêu cầu Claude báo cáo những gì nó đã thực sự kiểm tra, bao gồm cả các lỗi và các kiểm tra bị bỏ qua. Kiểm tra xem bằng chứng có đáp ứng yêu cầu hay không; việc bản dựng thành công không đồng nghĩa với việc mọi hành vi được yêu cầu đều hoạt động đúng.

Đối với các công việc dài hơn, Claude Code còn cung cấp điều kiện /goal và các hook dừng (Stop hooks). Bộ đánh giá mục tiêu (goal evaluator) sẽ đánh giá các bằng chứng xuất hiện trong cuộc hội thoại thay vì kiểm tra các tệp hoặc chạy các bài kiểm thử một cách độc lập. Một hook dừng đã được cấu hình có thể ngăn chặn việc hoàn thành công việc, nhưng nó có giới hạn về số lần chặn lặp lại. Cả hai đều không thể thay thế cho các bài kiểm thử thích hợp và việc đánh giá của con người.

Nếu việc sửa lỗi lặp đi lặp lại vẫn không giải quyết được vấn đề, hãy dừng lại và xác định xem yêu cầu ban đầu còn điểm nào chưa rõ ràng. Lưu lại các phát hiện hữu ích, trạng thái Git hiện tại và công việc còn lại trước khi xóa cuộc hội thoại.

Hướng dẫn thực hành tốt nhất của Anthropic khuyến nghị nên bắt đầu lại từ đầu sau hai lần sửa lỗi không thành công đối với cùng một vấn đề. Sử dụng lệnh /clear, sau đó cung cấp một lời nhắc đã được sửa đổi bao gồm những gì bạn đã học được. Việc xóa cuộc hội thoại sẽ không làm hủy bỏ các thay đổi trên tệp.

Nhấn phím Esc để ngắt một phản hồi đang chạy. Khi ô nhập lệnh trống, nhấn phím Esc hai lần để mở menu quay lại và chọn nội dung cần khôi phục. Chức năng quay lại không hủy bỏ mọi tác động bên ngoài, do đó hãy sử dụng các điểm kiểm tra Git và các quy trình khôi phục riêng biệt cho các thay đổi đối với cơ sở dữ liệu hoặc dịch vụ từ xa.

Lưu hướng dẫn chung cho toàn dự án trong tệp CLAUDE.md, các quy trình có thể lặp lại trong các kỹ năng (skills) và hướng dẫn cho các tệp cụ thể trong các quy tắc có phạm vi theo đường dẫn. Sử dụng các hook cho các hành động liên kết với các sự kiện cụ thể, chẳng hạn như chạy công cụ định dạng sau khi chỉnh sửa.

Chọn dựa trên thời điểm mà hướng dẫn cần được áp dụng:

Yêu cầu đối với một tính năng thường nên được đưa vào lời nhắc công việc hoặc thông số kỹ thuật của tính năng đó, thay vì trong tệp CLAUDE.md. Việc thêm các hướng dẫn tạm thời vào tệp áp dụng cho toàn dự án sẽ khiến chúng khó phân biệt hơn với các quy ước cần được áp dụng trên toàn bộ kho lưu trữ.

Ví dụ: lưu lệnh kiểm thử của dự án trong tệp CLAUDE.md, đặt các quy ước cụ thể cho từng thành phần vào quy tắc có phạm vi đường dẫn và lưu quy trình đánh giá định kỳ dưới dạng kỹ năng. Hãy xem lại các tệp này khi lệnh hoặc quy ước thay đổi, giống như cách bạn làm với các tài liệu dự án khác.

Các lời nhắc, tệp CLAUDE.md và hướng dẫn kỹ năng định hướng hành vi của Claude; chúng không đảm bảo rằng một chỉ thị sẽ được tuân thủ. Các hook có thể thực hiện kiểm tra tại các sự kiện đã được cấu hình, nhưng độ tin cậy của chúng phụ thuộc vào loại hook và cách triển khai.

Một hook lệnh thực thi một skript. Một prompt hoặc hook đại lý dựa vào phán đoán của mô hình. Như hướng dẫn thực hành tốt nhất của Anthropic giải thích: “Một prompt hoặc hook đại lý yêu cầu một mô hình khác đưa ra quyết định, do đó nó cũng không mang tính xác định.” Đối với một quy tắc cần được áp dụng, hãy sử dụng các biện pháp kiểm soát quyền truy cập phù hợp và kiểm thử hook lệnh hoặc HTTP liên quan, bao gồm cả cách nó xử lý các trường hợp lỗi.

Các subagent tùy chỉnh là một cách khác để tổ chức công việc lặp lại. Hãy định nghĩa một chuyên gia trong thư mục `claude/agents/` khi cần một vai trò đánh giá riêng biệt hoặc phạm vi công cụ cụ thể, thay vì thêm từng hướng dẫn chuyên gia vào phiên làm việc chính. Các hướng dẫn về mô hình Claude tốt nhất cho công việc và các loại tác nhân AI này cung cấp thêm bối cảnh.

Nếu nhóm của bạn duy trì các lời nhắc trên nhiều sản phẩm AI khác nhau, hãy tham khảo các công cụ thiết kế lời nhắc này để quản lý thư viện ngoài Claude Code.

Khi một phiên làm việc cho ra kết quả chưa hoàn chỉnh hoặc không phù hợp, hãy kiểm tra xem yêu cầu có để lại những quyết định quan trọng chưa được giải quyết hay không. Năm sai lầm này có thể khiến việc chẩn đoán và đánh giá công việc trở nên khó khăn hơn.

“Khám phá kho lưu trữ” không cung cấp cho Claude nhiều hướng dẫn về những tệp nào quan trọng hoặc khi nào nên dừng lại. Bạn có thể nhận được một bản tóm tắt chung chung mà không có câu trả lời cho vấn đề đã dẫn đến yêu cầu đó.

Đặt tên cho hành vi hoặc quyết định mà bạn cần hiểu, xác định địa điểm bắt đầu và xác định kết quả đầu ra mong đợi. Ví dụ: “Theo dõi cách điểm cuối này kiểm tra quyền truy cập và trích dẫn các hàm liên quan.” Nếu bạn sử dụng các tác nhân phụ, hãy đưa ra cho mỗi tác nhân một câu hỏi có giới hạn thay vì giao cho chúng cùng một nhiệm vụ tìm kiếm không giới hạn.

Việc chuyển đổi giữa một tính năng, một lỗi không liên quan và một yêu cầu tài liệu khiến cuộc hội thoại mang theo bối cảnh có thể không áp dụng cho công việc hiện tại. Các tham chiếu như “tập tin đó” hoặc “cách tiếp cận trước đây” trở nên mơ hồ.

Sử dụng các phiên làm việc riêng biệt cho các công việc không liên quan. Nếu nhiều phiên làm việc sẽ chỉnh sửa kho lưu trữ, hãy sử dụng các Git worktrees riêng biệt để chúng không sửa đổi cùng một thư mục làm việc. Một câu hỏi phụ ngắn gọn: lệnh /btw của Claude Code giúp giữ cuộc trao đổi này tách biệt khỏi lịch sử cuộc hội thoại chính.

Một bản dựng có thể vượt qua kiểm tra trong khi một tính năng lại hoạt động không chính xác. Một bộ kiểm thử có thể vượt qua vì nó chưa bao giờ thử nghiệm với đầu vào gây lỗi. Yêu cầu Claude “chạy các bài kiểm thử” không xác định được yêu cầu nào mà các bài kiểm thử đó đang xác minh.

Liên kết các tiêu chí chấp nhận với các bước kiểm tra cụ thể. Đối với việc sửa lỗi, yêu cầu bằng chứng cho thấy bài kiểm tra tái hiện đã thất bại trước khi thực hiện thay đổi và thành công sau đó. Giữ các tiêu chí chưa được kiểm tra ở trạng thái hiển thị thay vì coi một lệnh thành công là bằng chứng xác minh cho toàn bộ thay đổi.

Một tệp CLAUDE.md đang được mở rộng có thể chứa các lệnh đã lỗi thời, các quy tắc trùng lặp và các hướng dẫn mâu thuẫn với các yêu cầu cụ thể của công việc. Việc thêm các từ ngữ mạnh mẽ hơn sẽ không giải quyết được những mâu thuẫn đó.

So sánh tệp với kho lưu trữ hiện tại. Loại bỏ các hướng dẫn đã lỗi thời, làm rõ các quy tắc mâu thuẫn và chuyển các hướng dẫn chỉ áp dụng trong phạm vi hẹp sang các quy tắc hoặc kỹ năng có phạm vi áp dụng theo đường dẫn. Nếu một yêu cầu cần được thực thi, hãy cấu hình và kiểm thử các biện pháp kiểm soát phù hợp thay vì dựa vào các lời nhắc nhở lặp đi lặp lại.

Một lần đánh giá có thể chỉ ra các lỗi thực sự, các vấn đề chưa rõ ràng và các đề xuất tái cấu trúc tùy chọn cùng một lúc. Việc áp dụng mọi đề xuất có thể làm mở rộng phạm vi thay đổi mà không cải thiện được hành vi mong muốn.

Yêu cầu cung cấp bằng chứng và đánh giá tác động đằng sau mỗi phát hiện. Ưu tiên các vấn đề về tính chính xác và các yêu cầu chưa được đáp ứng, điều tra các tuyên bố chưa rõ ràng, và loại bỏ các cải tiến không liên quan khỏi bản diff hiện tại. Người đánh giá nên có thể báo cáo không có phát hiện nào cần xử lý khi bằng chứng hỗ trợ kết luận đó.

Để tùy chỉnh một mẫu, hãy thay thế các trường giữ chỗ bằng thông tin chi tiết từ dự án của bạn và quyết định việc cần làm trước khi thực hiện các thay đổi. Sử dụng các bước này để chuẩn bị yêu cầu và xem xét kết quả.

Đối với một thay đổi nhỏ và được xác định rõ ràng, bạn có thể yêu cầu Claude thực hiện trực tiếp. Đối với mã nguồn chưa quen thuộc, các thay đổi liên quan đến nhiều tệp hoặc các yêu cầu chưa được làm rõ, hãy bắt đầu bằng việc lập kế hoạch.

Nhấn Shift+Tab cho đến khi chế độ Lập kế hoạch xuất hiện, hoặc khởi chạy Claude Code bằng lệnh claude --quyền truy cập cao kế hoạch. Trong chế độ này, Claude có thể kiểm tra các tệp và thực thi các lệnh chỉ đọc mà không chỉnh sửa mã nguồn của bạn. Xem xét các tệp, phụ thuộc và bài kiểm thử được đề xuất trước khi phê duyệt triển khai. Nhấn Ctrl+G để mở kế hoạch được đề xuất trong trình chỉnh sửa của bạn.

Cung cấp cho Claude các bằng chứng cần thiết để hiểu công việc: tham chiếu tệp, nhật ký lỗi đã được làm sạch, ảnh chụp màn hình hoặc tài liệu yêu cầu. Sử dụng ký tự @ kèm theo đường dẫn tệp để bao gồm nội dung của tệp đó.

Chọn tập hợp nguồn nhỏ nhất nhưng vẫn hữu ích. Việc bao gồm toàn bộ nhật ký hoặc thư mục có thể thêm vào các thông tin không liên quan và làm mất bối cảnh. Loại bỏ thông tin đăng nhập và dữ liệu nhạy cảm trước khi chia sẻ nhật ký, đồng thời kiểm tra xem Claude có các công cụ cần thiết để truy xuất bất kỳ URL tài liệu nào bạn cung cấp hay không.

Ví dụ: lệnh `cat lỗi.log | claude -p "Giải thích lỗi này"` sẽ gửi nhật ký dưới dạng yêu cầu không tương tác. Chỉ nên sử dụng lệnh này sau khi đã kiểm tra nội dung của tệp. Đây chính là giá trị thực tiễn của trí tuệ nhân tạo dựa trên ngữ cảnh: cung cấp cho mô hình thông tin liên quan đến công việc.

Khi thêm một tính năng, hãy xác định một thành phần hoặc hàm tương tự trong kho lưu trữ. Hướng dẫn Claude tuân theo các quy ước nào, chẳng hạn như client API, logic xác thực, xử lý lỗi hoặc cấu trúc kiểm thử.

“Theo dõi cách @src/widgets/Weather.tsx lấy và lưu trữ dữ liệu” cung cấp cho Claude một tham chiếu cụ thể. Đồng thời, hãy nêu rõ bất kỳ sự khác biệt nào mà tính năng mới yêu cầu để tránh sao chép các hành vi không còn phù hợp. Các quy ước này nên phản ánh quy trình phát triển phần mềm của nhóm bạn.

Đối với các thay đổi mã nguồn, hãy chỉ định lệnh kiểm thử, lệnh xây dựng hoặc lệnh lint liên quan cùng với hành vi cần kiểm tra. Đối với nghiên cứu, hãy yêu cầu tham chiếu tệp hoặc ID commit. Đối với công việc liên quan đến giao diện người dùng (UI), hãy cung cấp hình ảnh tham chiếu và cách thức đã được cấu hình để chụp lại bản triển khai trong cùng một khung nhìn.

Yêu cầu Claude báo cáo những gì nó đã thực sự kiểm tra, bao gồm cả các lỗi và các kiểm tra bị bỏ qua. Kiểm tra xem bằng chứng có đáp ứng yêu cầu hay không; việc bản dựng thành công không đảm bảo rằng mọi hành vi được yêu cầu đều hoạt động đúng.

Đối với các công việc dài hơn, Claude Code còn cung cấp điều kiện /goal và các hook dừng (Stop hooks). Bộ đánh giá mục tiêu (goal evaluator) sẽ đánh giá các bằng chứng xuất hiện trong cuộc hội thoại thay vì kiểm tra các tệp hoặc chạy các bài kiểm thử một cách độc lập. Một hook dừng đã được cấu hình có thể ngăn chặn việc hoàn thành công việc, nhưng nó có giới hạn về số lần chặn lặp lại. Cả hai đều không thể thay thế cho các bài kiểm thử thích hợp và việc đánh giá của con người.

Nếu việc sửa lỗi lặp đi lặp lại vẫn không giải quyết được vấn đề, hãy dừng lại và xác định xem yêu cầu ban đầu còn điểm nào chưa rõ ràng. Lưu lại các phát hiện hữu ích, trạng thái Git hiện tại và công việc còn lại trước khi xóa cuộc hội thoại.

Hướng dẫn thực hành tốt nhất của Anthropic khuyến nghị nên bắt đầu lại từ đầu sau hai lần sửa lỗi không thành công đối với cùng một vấn đề. Sử dụng lệnh /clear, sau đó cung cấp một lời nhắc đã được sửa đổi bao gồm những gì bạn đã học được. Việc xóa cuộc hội thoại sẽ không làm hủy bỏ các thay đổi trên tệp.

Nhấn phím Esc để ngắt một phản hồi đang chạy. Khi ô nhập lệnh trống, nhấn phím Esc hai lần để mở menu quay lại và chọn nội dung cần khôi phục. Chức năng quay lại không hủy bỏ mọi tác động bên ngoài, do đó hãy sử dụng các điểm kiểm tra Git và các quy trình khôi phục riêng biệt cho các thay đổi đối với cơ sở dữ liệu hoặc dịch vụ từ xa.

Lưu hướng dẫn chung cho toàn dự án trong tệp CLAUDE.md, các quy trình có thể lặp lại trong các kỹ năng (skills) và hướng dẫn cho các tệp cụ thể trong các quy tắc có phạm vi theo đường dẫn. Sử dụng các hook cho các hành động liên kết với các sự kiện cụ thể, chẳng hạn như chạy công cụ định dạng sau khi chỉnh sửa.

Chọn dựa trên thời điểm mà hướng dẫn cần được áp dụng:

Yêu cầu đối với một tính năng thường nên được đưa vào lời nhắc công việc hoặc thông số kỹ thuật của tính năng đó, thay vì trong tệp CLAUDE.md. Việc thêm các hướng dẫn tạm thời vào tệp áp dụng cho toàn dự án sẽ khiến chúng khó phân biệt hơn với các quy ước cần áp dụng trên toàn bộ kho lưu trữ.

Ví dụ: lưu lệnh kiểm thử của dự án trong tệp CLAUDE.md, đặt các quy ước cụ thể cho từng thành phần vào quy tắc có phạm vi đường dẫn và lưu quy trình đánh giá định kỳ dưới dạng kỹ năng. Hãy xem lại các tệp này khi lệnh hoặc quy ước thay đổi, giống như cách bạn làm với các tài liệu dự án khác.

Các lời nhắc, tệp CLAUDE.md và hướng dẫn kỹ năng định hướng hành vi của Claude; chúng không đảm bảo rằng một chỉ thị sẽ được tuân thủ. Các hook có thể thực hiện kiểm tra tại các sự kiện đã được cấu hình, nhưng độ tin cậy của chúng phụ thuộc vào loại hook và cách triển khai.

Một hook lệnh thực thi một skript. Một prompt hoặc hook đại lý dựa vào phán đoán của mô hình. Như hướng dẫn thực hành tốt nhất của Anthropic giải thích: “Một prompt hoặc hook đại lý yêu cầu một mô hình khác đưa ra quyết định, do đó nó cũng không mang tính xác định.” Đối với một quy tắc cần được áp dụng, hãy sử dụng các biện pháp kiểm soát quyền truy cập phù hợp và kiểm thử hook lệnh hoặc HTTP liên quan, bao gồm cả cách nó xử lý các trường hợp lỗi.

Các subagent tùy chỉnh là một cách khác để tổ chức công việc lặp lại. Hãy định nghĩa một chuyên gia trong thư mục `claude/agents/` khi cần một vai trò đánh giá riêng biệt hoặc phạm vi công cụ cụ thể, thay vì thêm từng hướng dẫn chuyên gia vào phiên làm việc chính. Các hướng dẫn về mô hình Claude tốt nhất cho công việc và các loại tác nhân AI này cung cấp thêm bối cảnh.

Nếu nhóm của bạn duy trì các lời nhắc trên nhiều sản phẩm AI khác nhau, hãy tham khảo các công cụ thiết kế lời nhắc này để quản lý thư viện ngoài Claude Code.

Khi một phiên làm việc cho ra kết quả chưa hoàn chỉnh hoặc không phù hợp, hãy kiểm tra xem yêu cầu có để lại những quyết định quan trọng chưa được giải quyết hay không. Năm sai lầm này có thể khiến việc chẩn đoán và đánh giá công việc trở nên khó khăn hơn.

“Khám phá kho lưu trữ” không cung cấp cho Claude nhiều hướng dẫn về những tệp nào quan trọng hoặc khi nào nên dừng lại. Bạn có thể nhận được một bản tóm tắt chung chung mà không có câu trả lời cho vấn đề đã dẫn đến yêu cầu đó.

Đặt tên cho hành vi hoặc quyết định mà bạn cần hiểu, xác định địa điểm bắt đầu và xác định kết quả đầu ra mong đợi. Ví dụ: “Theo dõi cách điểm cuối này kiểm tra quyền truy cập và trích dẫn các hàm liên quan.” Nếu bạn sử dụng các tác nhân phụ, hãy đưa ra cho mỗi tác nhân một câu hỏi có giới hạn thay vì giao cho chúng cùng một nhiệm vụ tìm kiếm không giới hạn.

Việc chuyển đổi giữa một tính năng, một lỗi không liên quan và một yêu cầu tài liệu khiến cuộc hội thoại mang theo bối cảnh có thể không áp dụng cho công việc hiện tại. Các tham chiếu như “tập tin đó” hoặc “cách tiếp cận trước đây” trở nên mơ hồ.

Sử dụng các phiên làm việc riêng biệt cho các công việc không liên quan. Nếu nhiều phiên làm việc sẽ chỉnh sửa kho lưu trữ, hãy sử dụng các Git worktrees riêng biệt để chúng không sửa đổi cùng một thư mục làm việc. Một câu hỏi phụ ngắn gọn: lệnh /btw của Claude Code giúp giữ cuộc trao đổi này tách biệt khỏi lịch sử cuộc hội thoại chính.

Một bản dựng có thể vượt qua kiểm tra trong khi một tính năng lại hoạt động không chính xác. Một bộ kiểm thử có thể vượt qua vì nó chưa bao giờ thử nghiệm với đầu vào gây lỗi. Yêu cầu Claude “chạy các bài kiểm thử” không xác định được yêu cầu nào mà các bài kiểm thử đó đang xác minh.

Liên kết các tiêu chí chấp nhận với các bước kiểm tra cụ thể. Đối với việc sửa lỗi, yêu cầu bằng chứng cho thấy bài kiểm tra tái hiện đã thất bại trước khi thực hiện thay đổi và thành công sau đó. Giữ các tiêu chí chưa được kiểm tra ở trạng thái hiển thị thay vì coi một lệnh thành công là bằng chứng xác minh cho toàn bộ thay đổi.

Một tệp CLAUDE.md đang được mở rộng có thể chứa các lệnh đã lỗi thời, các quy tắc trùng lặp và các hướng dẫn mâu thuẫn với các yêu cầu cụ thể của công việc. Việc thêm các từ ngữ mạnh mẽ hơn sẽ không giải quyết được những mâu thuẫn đó.

So sánh tệp với kho lưu trữ hiện tại. Loại bỏ các hướng dẫn đã lỗi thời, làm rõ các quy tắc mâu thuẫn và chuyển các hướng dẫn chỉ áp dụng trong phạm vi hẹp sang các quy tắc hoặc kỹ năng có phạm vi áp dụng theo đường dẫn. Nếu một yêu cầu cần được thực thi, hãy cấu hình và kiểm thử các biện pháp kiểm soát phù hợp thay vì dựa vào các lời nhắc nhở lặp đi lặp lại.

Một lần đánh giá có thể chỉ ra các lỗi thực sự, các vấn đề chưa rõ ràng và các đề xuất tái cấu trúc tùy chọn cùng một lúc. Việc áp dụng mọi đề xuất có thể làm mở rộng phạm vi thay đổi mà không cải thiện được hành vi mong muốn.

Yêu cầu bằng chứng và tác động đằng sau mỗi phát hiện. Ưu tiên các vấn đề về tính chính xác và các yêu cầu chưa được đáp ứng, điều tra các tuyên bố không rõ ràng và loại bỏ các cải tiến không liên quan khỏi bản diff hiện tại. Người đánh giá nên có thể báo cáo không có phát hiện nào cần xử lý khi bằng chứng hỗ trợ kết luận đó.

Để tùy chỉnh một mẫu, hãy thay thế các trường giữ chỗ bằng thông tin chi tiết từ dự án của bạn và quyết định việc cần làm trước khi thực hiện các thay đổi. Sử dụng các bước này để chuẩn bị yêu cầu và xem xét kết quả.

Đối với một thay đổi nhỏ và được xác định rõ ràng, bạn có thể yêu cầu Claude thực hiện trực tiếp. Đối với mã nguồn chưa quen thuộc, các thay đổi liên quan đến nhiều tệp hoặc các yêu cầu chưa được làm rõ, hãy bắt đầu bằng việc lập kế hoạch.

Nhấn Shift+Tab cho đến khi chế độ Lập kế hoạch xuất hiện, hoặc khởi chạy Claude Code bằng lệnh claude --permission-mode plan. Trong chế độ này, Claude có thể kiểm tra các tệp và thực thi các lệnh chỉ đọc mà không chỉnh sửa mã nguồn của bạn. Xem xét các tệp, phụ thuộc và bài kiểm thử được đề xuất trước khi phê duyệt việc triển khai. Nhấn Ctrl+G để mở kế hoạch được đề xuất trong trình chỉnh sửa của bạn.

Cung cấp cho Claude các bằng chứng cần thiết để hiểu công việc: tham chiếu tệp, nhật ký lỗi đã được làm sạch, ảnh chụp màn hình hoặc tài liệu yêu cầu. Sử dụng ký tự @ kèm theo đường dẫn tệp để bao gồm nội dung của tệp đó.

Chọn tập hợp nguồn nhỏ nhất nhưng vẫn hữu ích. Việc bao gồm toàn bộ nhật ký hoặc thư mục có thể thêm vào các thông tin không liên quan và làm mất bối cảnh. Loại bỏ thông tin đăng nhập và dữ liệu nhạy cảm trước khi chia sẻ nhật ký, đồng thời kiểm tra xem Claude có các công cụ cần thiết để truy xuất bất kỳ URL tài liệu nào bạn cung cấp hay không.

Ví dụ: lệnh `cat lỗi.log | claude -p "Giải thích lỗi này"` sẽ gửi nhật ký dưới dạng yêu cầu không tương tác. Chỉ nên sử dụng lệnh này sau khi đã kiểm tra nội dung của tệp. Đây chính là giá trị thực tiễn của trí tuệ nhân tạo dựa trên ngữ cảnh: cung cấp cho mô hình thông tin liên quan đến công việc.

Khi thêm một tính năng, hãy xác định một thành phần hoặc hàm tương tự trong kho lưu trữ. Hướng dẫn Claude tuân theo các quy ước nào, chẳng hạn như client API, logic xác thực, xử lý lỗi hoặc cấu trúc kiểm thử.

“Theo dõi cách @src/widgets/Weather.tsx lấy và lưu trữ dữ liệu” cung cấp cho Claude một tham chiếu cụ thể. Đồng thời, hãy nêu rõ bất kỳ sự khác biệt nào mà tính năng mới yêu cầu để tránh sao chép các hành vi không còn phù hợp. Các quy ước này nên phản ánh quy trình phát triển phần mềm của nhóm bạn.

Đối với các thay đổi mã nguồn, hãy chỉ định lệnh kiểm thử, lệnh xây dựng hoặc lệnh lint liên quan cùng với hành vi cần kiểm tra. Đối với nghiên cứu, hãy yêu cầu tham chiếu tệp hoặc ID commit. Đối với công việc liên quan đến giao diện người dùng (UI), hãy cung cấp hình ảnh tham chiếu và cách thức đã được cấu hình để chụp lại bản triển khai trong cùng một khung nhìn.

Yêu cầu Claude báo cáo những gì nó đã thực sự kiểm tra, bao gồm cả các lỗi và các kiểm tra bị bỏ qua. Kiểm tra xem bằng chứng có đáp ứng yêu cầu hay không; việc xây dựng thành công không đảm bảo rằng mọi hành vi được yêu cầu đều hoạt động.

Đối với các công việc dài hơn, Claude Code còn cung cấp điều kiện /goal và các hook dừng (Stop hooks). Bộ đánh giá mục tiêu (goal evaluator) sẽ đánh giá các bằng chứng xuất hiện trong cuộc hội thoại thay vì kiểm tra các tệp hoặc chạy các bài kiểm thử một cách độc lập. Một hook dừng đã được cấu hình có thể ngăn chặn việc hoàn thành công việc, nhưng nó có giới hạn về việc chặn lặp lại. Cả hai đều không thể thay thế cho các bài kiểm thử thích hợp và việc đánh giá của con người.

Nếu việc sửa lỗi lặp đi lặp lại vẫn không giải quyết được vấn đề, hãy dừng lại và xác định xem yêu cầu ban đầu còn điểm nào chưa rõ ràng. Lưu lại các phát hiện hữu ích, trạng thái Git hiện tại và công việc còn lại trước khi xóa cuộc hội thoại.

Hướng dẫn thực hành tốt nhất của Anthropic khuyến nghị nên bắt đầu lại từ đầu sau hai lần sửa lỗi không thành công đối với cùng một vấn đề. Sử dụng lệnh /clear, sau đó cung cấp một lời nhắc đã được sửa đổi bao gồm những gì bạn đã học được. Việc xóa cuộc hội thoại sẽ không làm hủy bỏ các thay đổi trên tệp.

Nhấn phím Esc để ngắt một phản hồi đang chạy. Khi ô nhập lệnh trống, nhấn phím Esc hai lần để mở menu quay lại và chọn nội dung cần khôi phục. Chức năng quay lại không hủy bỏ mọi tác động bên ngoài, do đó hãy sử dụng các điểm kiểm tra Git và các quy trình khôi phục riêng biệt cho các thay đổi đối với cơ sở dữ liệu hoặc dịch vụ từ xa.

Lưu hướng dẫn chung cho toàn dự án trong tệp CLAUDE.md, các quy trình có thể lặp lại trong các kỹ năng (skills) và hướng dẫn cho các tệp cụ thể trong các quy tắc có phạm vi theo đường dẫn. Sử dụng các hook cho các hành động liên kết với các sự kiện cụ thể, chẳng hạn như chạy công cụ định dạng sau khi chỉnh sửa.

Chọn dựa trên thời điểm mà hướng dẫn đó nên được áp dụng:

Yêu cầu đối với một tính năng thường nên được đưa vào lời nhắc công việc hoặc thông số kỹ thuật của tính năng đó, thay vì trong tệp CLAUDE.md. Việc thêm các hướng dẫn tạm thời vào tệp áp dụng cho toàn dự án sẽ khiến chúng khó phân biệt hơn với các quy ước cần được áp dụng trên toàn bộ kho lưu trữ.

Ví dụ: lưu lệnh kiểm thử của dự án trong tệp CLAUDE.md, đặt các quy ước cụ thể cho từng thành phần vào quy tắc có phạm vi đường dẫn và lưu quy trình đánh giá định kỳ dưới dạng kỹ năng. Hãy xem lại các tệp này khi lệnh hoặc quy ước thay đổi, giống như cách bạn làm với các tài liệu dự án khác.

Các lời nhắc, tệp CLAUDE.md và hướng dẫn kỹ năng định hướng hành vi của Claude; chúng không đảm bảo rằng một chỉ thị sẽ được tuân thủ. Các hook có thể thực hiện kiểm tra tại các sự kiện đã được cấu hình, nhưng độ tin cậy của chúng phụ thuộc vào loại hook và cách triển khai.

Một hook lệnh thực thi một skript. Một prompt hoặc hook đại lý dựa vào phán đoán của mô hình. Như hướng dẫn thực hành tốt nhất của Anthropic giải thích: “Một prompt hoặc hook đại lý yêu cầu một mô hình khác đưa ra quyết định, do đó nó cũng không mang tính xác định.” Đối với một quy tắc cần được áp dụng, hãy sử dụng các biện pháp kiểm soát quyền truy cập phù hợp và kiểm thử hook lệnh hoặc HTTP liên quan, bao gồm cả cách nó xử lý các trường hợp lỗi.

Các subagent tùy chỉnh là một cách khác để tổ chức công việc lặp lại. Hãy định nghĩa một chuyên gia trong thư mục `claude/agents/` khi cần một vai trò đánh giá riêng biệt hoặc phạm vi công cụ cụ thể, thay vì thêm từng hướng dẫn chuyên gia vào phiên làm việc chính. Các hướng dẫn về mô hình Claude tốt nhất cho công việc và các loại tác nhân AI này cung cấp thêm bối cảnh.

Nếu nhóm của bạn duy trì các lời nhắc trên nhiều sản phẩm AI khác nhau, hãy tham khảo các công cụ thiết kế lời nhắc này để quản lý thư viện ngoài Claude Code.

Khi một phiên làm việc cho ra kết quả chưa hoàn chỉnh hoặc không phù hợp, hãy kiểm tra xem yêu cầu có để lại những quyết định quan trọng chưa được giải quyết hay không. Năm sai lầm này có thể khiến việc chẩn đoán và đánh giá công việc trở nên khó khăn hơn.

“Khám phá kho lưu trữ” không cung cấp cho Claude nhiều hướng dẫn về những tệp nào quan trọng hoặc khi nào nên dừng lại. Bạn có thể nhận được một bản tóm tắt chung chung mà không có câu trả lời cho vấn đề đã dẫn đến yêu cầu đó.

Đặt tên cho hành vi hoặc quyết định mà bạn cần hiểu, xác định địa điểm bắt đầu và xác định kết quả đầu ra mong đợi. Ví dụ: “Theo dõi cách điểm cuối này kiểm tra quyền truy cập và trích dẫn các hàm liên quan.” Nếu bạn sử dụng các tác nhân phụ, hãy đưa ra cho mỗi tác nhân một câu hỏi có giới hạn thay vì giao cho chúng cùng một nhiệm vụ tìm kiếm không giới hạn.

Việc chuyển đổi giữa một tính năng, một lỗi không liên quan và một yêu cầu tài liệu khiến cuộc hội thoại mang theo bối cảnh có thể không áp dụng cho công việc hiện tại. Các tham chiếu như “tập tin đó” hoặc “cách tiếp cận trước đây” trở nên mơ hồ.

Sử dụng các phiên làm việc riêng biệt cho các công việc không liên quan. Nếu nhiều phiên làm việc sẽ chỉnh sửa kho lưu trữ, hãy sử dụng các Git worktrees riêng biệt để chúng không sửa đổi cùng một thư mục làm việc. Một câu hỏi phụ ngắn gọn: lệnh /btw của Claude Code giúp giữ cuộc trao đổi này tách biệt khỏi lịch sử cuộc hội thoại chính.

Một bản dựng có thể vượt qua kiểm tra trong khi một tính năng lại hoạt động không chính xác. Một bộ kiểm thử có thể vượt qua vì nó chưa bao giờ thử nghiệm với đầu vào gây lỗi. Yêu cầu Claude “chạy các bài kiểm thử” không xác định được yêu cầu nào mà các bài kiểm thử đó đang xác minh.

Liên kết các tiêu chí chấp nhận với các bước kiểm tra cụ thể. Đối với việc sửa lỗi, yêu cầu bằng chứng cho thấy bài kiểm tra tái hiện đã thất bại trước khi thực hiện thay đổi và thành công sau đó. Giữ các tiêu chí chưa được kiểm tra ở trạng thái hiển thị thay vì coi một lệnh thành công là bằng chứng xác minh cho toàn bộ thay đổi.

Một tệp CLAUDE.md đang được mở rộng có thể chứa các lệnh đã lỗi thời, các quy tắc trùng lặp và các hướng dẫn mâu thuẫn với các yêu cầu cụ thể của công việc. Việc thêm các từ ngữ mạnh mẽ hơn sẽ không giải quyết được những mâu thuẫn đó.

So sánh tệp với kho lưu trữ hiện tại. Loại bỏ các hướng dẫn đã lỗi thời, làm rõ các quy tắc mâu thuẫn và chuyển các hướng dẫn chỉ áp dụng trong phạm vi hẹp sang các quy tắc hoặc kỹ năng có phạm vi áp dụng theo đường dẫn. Nếu một yêu cầu cần được thực thi, hãy cấu hình và kiểm thử các biện pháp kiểm soát phù hợp thay vì dựa vào các lời nhắc nhở lặp đi lặp lại.

Một lần đánh giá có thể chỉ ra các lỗi thực sự, các vấn đề chưa rõ ràng và các đề xuất tái cấu trúc tùy chọn cùng một lúc. Việc áp dụng mọi đề xuất có thể làm mở rộng phạm vi thay đổi mà không cải thiện được hành vi mong muốn.

Yêu cầu cung cấp bằng chứng và đánh giá tác động đằng sau mỗi phát hiện. Ưu tiên các vấn đề về tính chính xác và các yêu cầu chưa được đáp ứng, điều tra các tuyên bố chưa rõ ràng, và loại bỏ các cải tiến không liên quan khỏi bản diff hiện tại. Người đánh giá nên có thể báo cáo không có phát hiện nào cần xử lý khi bằng chứng hỗ trợ kết luận đó.

Để tùy chỉnh một mẫu, hãy thay thế các trường giữ chỗ bằng thông tin chi tiết từ dự án của bạn và quyết định việc cần làm trước khi thực hiện các thay đổi. Sử dụng các bước này để chuẩn bị yêu cầu và xem xét kết quả.

Đối với một thay đổi nhỏ và được xác định rõ ràng, bạn có thể yêu cầu Claude thực hiện trực tiếp. Đối với mã nguồn chưa quen thuộc, các thay đổi liên quan đến nhiều tệp hoặc các yêu cầu chưa được làm rõ, hãy bắt đầu bằng việc lập kế hoạch.

Nhấn Shift+Tab cho đến khi chế độ Lập kế hoạch xuất hiện, hoặc khởi chạy Claude Code bằng lệnh claude --permission-mode plan. Trong chế độ này, Claude có thể kiểm tra các tệp và thực thi các lệnh chỉ đọc mà không chỉnh sửa mã nguồn của bạn. Xem xét các tệp, phụ thuộc và bài kiểm thử được đề xuất trước khi phê duyệt triển khai. Nhấn Ctrl+G để mở kế hoạch được đề xuất trong trình chỉnh sửa của bạn.

Cung cấp cho Claude các bằng chứng cần thiết để hiểu công việc: tham chiếu tệp, nhật ký lỗi đã được làm sạch, ảnh chụp màn hình hoặc tài liệu yêu cầu. Sử dụng ký tự @ kèm theo đường dẫn tệp để bao gồm nội dung của tệp đó.

Chọn tập hợp nguồn nhỏ nhất nhưng vẫn hữu ích. Việc bao gồm toàn bộ nhật ký hoặc thư mục có thể thêm vào các thông tin không liên quan và làm mất bối cảnh. Loại bỏ thông tin đăng nhập và dữ liệu nhạy cảm trước khi chia sẻ nhật ký, đồng thời kiểm tra xem Claude có các công cụ cần thiết để truy xuất bất kỳ URL tài liệu nào bạn cung cấp hay không.

Ví dụ: lệnh `cat lỗi.log | claude -p "Giải thích lỗi này"` sẽ gửi nhật ký dưới dạng yêu cầu không tương tác. Chỉ nên sử dụng lệnh này sau khi đã kiểm tra nội dung của tệp. Đây chính là giá trị thực tiễn của trí tuệ nhân tạo dựa trên ngữ cảnh: cung cấp cho mô hình thông tin liên quan đến công việc.

Khi thêm một tính năng, hãy xác định một thành phần hoặc hàm tương tự trong kho lưu trữ. Hướng dẫn Claude tuân theo các quy ước nào, chẳng hạn như client API, logic xác thực, xử lý lỗi hoặc cấu trúc kiểm thử.

“Theo dõi cách @src/widgets/Weather.tsx lấy và lưu trữ dữ liệu” cung cấp cho Claude một tham chiếu cụ thể. Đồng thời, hãy nêu rõ bất kỳ sự khác biệt nào mà tính năng mới yêu cầu để tránh sao chép các hành vi không còn phù hợp. Các quy ước này nên phản ánh quy trình phát triển phần mềm của nhóm bạn.

Đối với các thay đổi mã nguồn, hãy chỉ định lệnh kiểm thử, lệnh xây dựng hoặc lệnh lint liên quan cùng với hành vi cần kiểm tra. Đối với nghiên cứu, hãy yêu cầu tham chiếu tệp hoặc ID commit. Đối với công việc liên quan đến giao diện người dùng (UI), hãy cung cấp hình ảnh tham chiếu và cách thức đã được cấu hình để chụp lại bản triển khai trong cùng một khung nhìn.

Yêu cầu Claude báo cáo những gì nó đã thực sự kiểm tra, bao gồm cả các lỗi và các kiểm tra bị bỏ qua. Kiểm tra xem bằng chứng có đáp ứng yêu cầu hay không; việc bản dựng thành công không đồng nghĩa với việc mọi hành vi được yêu cầu đều hoạt động đúng.

Đối với các công việc dài hơn, Claude Code còn cung cấp điều kiện /goal và các hook dừng (Stop hooks). Bộ đánh giá mục tiêu (goal evaluator) sẽ đánh giá các bằng chứng xuất hiện trong cuộc hội thoại thay vì kiểm tra các tệp hoặc chạy các bài kiểm thử một cách độc lập. Một hook dừng đã được cấu hình có thể ngăn chặn việc hoàn thành công việc, nhưng nó có giới hạn về số lần chặn lặp lại. Cả hai đều không thể thay thế cho các bài kiểm thử thích hợp và việc đánh giá của con người.

Nếu việc sửa lỗi lặp đi lặp lại vẫn không giải quyết được vấn đề, hãy dừng lại và xác định xem yêu cầu ban đầu còn điểm nào chưa rõ ràng. Lưu lại các phát hiện hữu ích, trạng thái Git hiện tại và công việc còn lại trước khi xóa cuộc hội thoại.

Hướng dẫn thực hành tốt nhất của Anthropic khuyến nghị nên bắt đầu lại từ đầu sau hai lần sửa lỗi không thành công đối với cùng một vấn đề. Sử dụng lệnh /clear, sau đó cung cấp một lời nhắc đã được sửa đổi bao gồm những gì bạn đã học được. Việc xóa cuộc hội thoại sẽ không làm hủy bỏ các thay đổi trên tệp.

Nhấn phím Esc để ngắt một phản hồi đang chạy. Khi ô nhập lệnh trống, nhấn phím Esc hai lần để mở menu quay lại và chọn nội dung cần khôi phục. Chức năng quay lại không hủy bỏ mọi tác động bên ngoài, do đó hãy sử dụng các điểm kiểm tra Git và các quy trình khôi phục riêng biệt cho các thay đổi đối với cơ sở dữ liệu hoặc dịch vụ từ xa.

Lưu hướng dẫn chung cho toàn dự án trong tệp CLAUDE.md, các quy trình có thể lặp lại trong các kỹ năng (skills) và hướng dẫn cho các tệp cụ thể trong các quy tắc có phạm vi theo đường dẫn. Sử dụng các hook cho các hành động liên kết với các sự kiện cụ thể, chẳng hạn như chạy công cụ định dạng sau khi chỉnh sửa.

Chọn dựa trên thời điểm mà hướng dẫn cần được áp dụng:

Yêu cầu đối với một tính năng thường nên được đưa vào lời nhắc công việc hoặc thông số kỹ thuật của tính năng đó, thay vì trong tệp CLAUDE.md. Việc thêm các hướng dẫn tạm thời vào tệp áp dụng cho toàn dự án sẽ khiến chúng khó phân biệt hơn với các quy ước cần được áp dụng trên toàn bộ kho lưu trữ.

Ví dụ: lưu lệnh kiểm thử của dự án trong tệp CLAUDE.md, đặt các quy ước cụ thể cho từng thành phần vào quy tắc có phạm vi đường dẫn và lưu quy trình đánh giá định kỳ dưới dạng kỹ năng. Hãy xem lại các tệp này khi lệnh hoặc quy ước thay đổi, giống như cách bạn làm với các tài liệu dự án khác.

Các lời nhắc, tệp CLAUDE.md và hướng dẫn kỹ năng định hướng hành vi của Claude; chúng không đảm bảo rằng một chỉ thị sẽ được tuân thủ. Các hook có thể thực hiện kiểm tra tại các sự kiện đã được cấu hình, nhưng độ tin cậy của chúng phụ thuộc vào loại hook và cách triển khai.

Một hook lệnh thực thi một skript. Một prompt hoặc hook đại lý dựa vào phán đoán của mô hình. Như hướng dẫn thực hành tốt nhất của Anthropic giải thích: “Một prompt hoặc hook đại lý yêu cầu một mô hình khác đưa ra quyết định, do đó nó cũng không mang tính xác định.” Đối với một quy tắc cần được áp dụng, hãy sử dụng các biện pháp kiểm soát quyền truy cập phù hợp và kiểm thử hook lệnh hoặc HTTP liên quan, bao gồm cả cách nó xử lý các trường hợp lỗi.

Các subagent tùy chỉnh là một cách khác để tổ chức công việc lặp lại. Hãy định nghĩa một chuyên gia trong thư mục `claude/agents/` khi cần một vai trò đánh giá riêng biệt hoặc phạm vi công cụ cụ thể, thay vì thêm từng hướng dẫn chuyên gia vào phiên làm việc chính. Các hướng dẫn về mô hình Claude tốt nhất cho công việc và các loại tác nhân AI này cung cấp thêm bối cảnh.

Nếu nhóm của bạn duy trì các lời nhắc trên nhiều sản phẩm AI khác nhau, hãy tham khảo các công cụ thiết kế lời nhắc này để quản lý thư viện ngoài Claude Code.

Khi một phiên làm việc cho ra kết quả chưa hoàn chỉnh hoặc không phù hợp, hãy kiểm tra xem yêu cầu có để lại những quyết định quan trọng chưa được giải quyết hay không. Năm sai lầm này có thể khiến việc chẩn đoán và đánh giá công việc trở nên khó khăn hơn.

“Khám phá kho lưu trữ” không cung cấp cho Claude nhiều hướng dẫn về những tệp nào quan trọng hoặc khi nào nên dừng lại. Bạn có thể nhận được một bản tóm tắt chung chung mà không có câu trả lời cho vấn đề đã dẫn đến yêu cầu đó.

Đặt tên cho hành vi hoặc quyết định mà bạn cần hiểu, xác định địa điểm bắt đầu và xác định kết quả đầu ra mong đợi. Ví dụ: “Theo dõi cách điểm cuối này kiểm tra quyền truy cập và trích dẫn các hàm liên quan.” Nếu bạn sử dụng các tác nhân phụ, hãy đưa ra cho mỗi tác nhân một câu hỏi có giới hạn thay vì giao cho chúng cùng một nhiệm vụ tìm kiếm không giới hạn.

Việc chuyển đổi giữa một tính năng, một lỗi không liên quan và một yêu cầu tài liệu khiến cuộc hội thoại mang theo bối cảnh có thể không áp dụng cho công việc hiện tại. Các tham chiếu như “tập tin đó” hoặc “cách tiếp cận trước đây” trở nên mơ hồ.

Sử dụng các phiên làm việc riêng biệt cho các công việc không liên quan. Nếu nhiều phiên làm việc sẽ chỉnh sửa kho lưu trữ, hãy sử dụng các Git worktrees riêng biệt để chúng không sửa đổi cùng một thư mục làm việc. Một câu hỏi phụ ngắn gọn: lệnh /btw của Claude Code giúp giữ cuộc trao đổi này tách biệt khỏi lịch sử cuộc hội thoại chính.

Một bản dựng có thể vượt qua kiểm tra trong khi một tính năng lại hoạt động không chính xác. Một bộ kiểm thử có thể vượt qua vì nó chưa bao giờ thử nghiệm với đầu vào gây lỗi. Yêu cầu Claude “chạy các bài kiểm thử” không xác định được yêu cầu nào mà các bài kiểm thử đó đang xác minh.

Liên kết các tiêu chí chấp nhận với các bước kiểm tra cụ thể. Đối với việc sửa lỗi, yêu cầu bằng chứng cho thấy bài kiểm tra tái hiện đã thất bại trước khi thực hiện thay đổi và thành công sau đó. Giữ các tiêu chí chưa được kiểm tra ở trạng thái hiển thị thay vì coi một lệnh thành công là bằng chứng xác minh cho toàn bộ thay đổi.

Một tệp CLAUDE.md đang được mở rộng có thể chứa các lệnh đã lỗi thời, các quy tắc trùng lặp và các hướng dẫn mâu thuẫn với các yêu cầu cụ thể của công việc. Việc thêm các từ ngữ mạnh mẽ hơn sẽ không giải quyết được những mâu thuẫn đó.

So sánh tệp với kho lưu trữ hiện tại. Loại bỏ các hướng dẫn đã lỗi thời, làm rõ các quy tắc mâu thuẫn và chuyển các hướng dẫn chỉ áp dụng trong phạm vi hẹp sang các quy tắc hoặc kỹ năng có phạm vi áp dụng theo đường dẫn. Nếu một yêu cầu cần được thực thi, hãy cấu hình và kiểm thử các biện pháp kiểm soát phù hợp thay vì dựa vào các lời nhắc nhở lặp đi lặp lại.

Một lần đánh giá có thể chỉ ra các lỗi thực sự, các vấn đề chưa rõ ràng và các đề xuất tái cấu trúc tùy chọn cùng một lúc. Việc áp dụng mọi đề xuất có thể làm mở rộng phạm vi thay đổi mà không cải thiện được hành vi mong muốn.

Yêu cầu cung cấp bằng chứng và đánh giá tác động đằng sau mỗi phát hiện. Ưu tiên các vấn đề về tính chính xác và các yêu cầu chưa được đáp ứng, điều tra các tuyên bố chưa rõ ràng, và loại bỏ các cải tiến không liên quan khỏi bản diff hiện tại. Người đánh giá nên có thể báo cáo không có phát hiện nào cần xử lý khi bằng chứng hỗ trợ kết luận đó.

Để tùy chỉnh một mẫu, hãy thay thế các trường giữ chỗ bằng thông tin chi tiết từ dự án của bạn và quyết định việc cần làm trước khi thực hiện các thay đổi. Sử dụng các bước này để chuẩn bị yêu cầu và xem xét kết quả.

Đối với một thay đổi nhỏ và được xác định rõ ràng, bạn có thể yêu cầu Claude thực hiện trực tiếp. Đối với mã nguồn chưa quen thuộc, các thay đổi liên quan đến nhiều tệp hoặc các yêu cầu chưa được làm rõ, hãy bắt đầu bằng việc lập kế hoạch.

Nhấn Shift+Tab cho đến khi chế độ Lập kế hoạch xuất hiện, hoặc khởi chạy Claude Code bằng lệnh claude --permission-mode plan. Trong chế độ này, Claude có thể kiểm tra các tệp và thực thi các lệnh chỉ đọc mà không chỉnh sửa mã nguồn của bạn. Xem xét các tệp, phụ thuộc và bài kiểm thử được đề xuất trước khi phê duyệt triển khai. Nhấn Ctrl+G để mở kế hoạch được đề xuất trong trình chỉnh sửa của bạn.

Cung cấp cho Claude các bằng chứng cần thiết để hiểu công việc: tham chiếu tệp, nhật ký lỗi đã được làm sạch, ảnh chụp màn hình hoặc tài liệu yêu cầu. Sử dụng ký tự @ kèm theo đường dẫn tệp để bao gồm nội dung của tệp đó.

Chọn tập hợp nguồn nhỏ nhất nhưng vẫn hữu ích. Việc bao gồm toàn bộ nhật ký hoặc thư mục có thể thêm vào các thông tin không liên quan và làm mất bối cảnh. Loại bỏ thông tin đăng nhập và dữ liệu nhạy cảm trước khi chia sẻ nhật ký, đồng thời kiểm tra xem Claude có các công cụ cần thiết để truy xuất bất kỳ URL tài liệu nào bạn cung cấp hay không.

Ví dụ: lệnh `cat lỗi.log | claude -p "Giải thích lỗi này"` sẽ gửi nhật ký dưới dạng yêu cầu không tương tác. Chỉ nên sử dụng lệnh này sau khi đã kiểm tra nội dung của tệp. Đây chính là giá trị thực tiễn của trí tuệ nhân tạo dựa trên ngữ cảnh: cung cấp cho mô hình thông tin liên quan đến công việc.

Khi thêm một tính năng, hãy xác định một thành phần hoặc hàm tương tự trong kho lưu trữ. Hướng dẫn Claude tuân theo các quy ước nào, chẳng hạn như client API, logic xác thực, xử lý lỗi hoặc cấu trúc kiểm thử.

“Theo dõi cách @src/widgets/Weather.tsx lấy và lưu trữ dữ liệu” cung cấp cho Claude một tham chiếu cụ thể. Đồng thời, hãy nêu rõ bất kỳ sự khác biệt nào mà tính năng mới yêu cầu để tránh sao chép các hành vi không còn phù hợp. Các quy ước này nên phản ánh quy trình phát triển phần mềm của nhóm bạn.

Đối với các thay đổi mã nguồn, hãy chỉ định lệnh kiểm thử, lệnh xây dựng hoặc lệnh lint liên quan cùng với hành vi cần kiểm tra. Đối với nghiên cứu, hãy yêu cầu tham chiếu tệp hoặc ID commit. Đối với công việc liên quan đến giao diện người dùng (UI), hãy cung cấp hình ảnh tham chiếu và cách thức đã được cấu hình để chụp lại bản triển khai trong cùng một khung nhìn.

Yêu cầu Claude báo cáo những gì nó đã thực sự kiểm tra, bao gồm cả các lỗi và các kiểm tra bị bỏ qua. Kiểm tra xem bằng chứng có đáp ứng yêu cầu hay không; việc bản dựng thành công không đồng nghĩa với việc mọi hành vi được yêu cầu đều hoạt động đúng.

Đối với các công việc dài hơn, Claude Code còn cung cấp điều kiện /goal và các hook dừng (Stop hooks). Bộ đánh giá mục tiêu (goal evaluator) sẽ đánh giá các bằng chứng xuất hiện trong cuộc hội thoại thay vì kiểm tra các tệp hoặc chạy các bài kiểm thử một cách độc lập. Một hook dừng đã được cấu hình có thể ngăn chặn việc hoàn thành công việc, nhưng nó có giới hạn về số lần chặn lặp lại. Cả hai đều không thể thay thế cho các bài kiểm thử thích hợp và việc đánh giá của con người.

Nếu việc sửa lỗi lặp đi lặp lại vẫn không giải quyết được vấn đề, hãy dừng lại và xác định xem yêu cầu ban đầu còn điểm nào chưa rõ ràng. Lưu lại các phát hiện hữu ích, trạng thái Git hiện tại và công việc còn lại trước khi xóa cuộc hội thoại.

Hướng dẫn thực hành tốt nhất của Anthropic khuyến nghị nên bắt đầu lại từ đầu sau hai lần sửa lỗi không thành công đối với cùng một vấn đề. Sử dụng lệnh /clear, sau đó cung cấp một lời nhắc đã được sửa đổi bao gồm những gì bạn đã học được. Việc xóa cuộc hội thoại sẽ không làm hủy bỏ các thay đổi trên tệp.

Nhấn phím Esc để ngắt một phản hồi đang chạy. Khi ô nhập lệnh trống, nhấn phím Esc hai lần để mở menu quay lại và chọn nội dung cần khôi phục. Chức năng quay lại không hủy bỏ mọi tác động bên ngoài, do đó hãy sử dụng các điểm kiểm tra Git và các quy trình khôi phục riêng biệt cho các thay đổi đối với cơ sở dữ liệu hoặc dịch vụ từ xa.

Lưu hướng dẫn chung cho toàn dự án trong tệp CLAUDE.md, các quy trình có thể lặp lại trong các kỹ năng (skills) và hướng dẫn cho các tệp cụ thể trong các quy tắc có phạm vi theo đường dẫn. Sử dụng các hook cho các hành động liên kết với các sự kiện cụ thể, chẳng hạn như chạy công cụ định dạng sau khi chỉnh sửa.

Chọn dựa trên thời điểm mà hướng dẫn đó nên được áp dụng:

Yêu cầu đối với một tính năng thường nên được đưa vào lời nhắc công việc hoặc thông số kỹ thuật của tính năng đó, thay vì trong tệp CLAUDE.md. Việc thêm các hướng dẫn tạm thời vào tệp áp dụng cho toàn dự án sẽ khiến chúng khó phân biệt hơn với các quy ước cần áp dụng trên toàn bộ kho lưu trữ.

Ví dụ: lưu lệnh kiểm thử của dự án trong tệp CLAUDE.md, đặt các quy ước cụ thể cho từng thành phần vào quy tắc có phạm vi đường dẫn và lưu quy trình đánh giá định kỳ dưới dạng kỹ năng. Hãy xem lại các tệp này khi lệnh hoặc quy ước thay đổi, giống như cách bạn làm với các tài liệu dự án khác.

Các lời nhắc, tệp CLAUDE.md và hướng dẫn kỹ năng định hướng hành vi của Claude; chúng không đảm bảo rằng một chỉ thị sẽ được tuân thủ. Các hook có thể thực hiện kiểm tra tại các sự kiện đã được cấu hình, nhưng độ tin cậy của chúng phụ thuộc vào loại hook và cách triển khai.

Một hook lệnh thực thi một skript. Một prompt hoặc hook đại lý dựa vào phán đoán của mô hình. Như hướng dẫn thực hành tốt nhất của Anthropic giải thích: “Một prompt hoặc hook đại lý yêu cầu một mô hình khác đưa ra quyết định, do đó nó cũng không mang tính xác định.” Đối với một quy tắc cần được áp dụng, hãy sử dụng các biện pháp kiểm soát quyền truy cập phù hợp và kiểm thử hook lệnh hoặc HTTP liên quan, bao gồm cả cách nó xử lý các trường hợp lỗi.

Các subagent tùy chỉnh là một cách khác để tổ chức công việc lặp lại. Hãy định nghĩa một chuyên gia trong thư mục `claude/agents/` khi cần một vai trò đánh giá riêng biệt hoặc phạm vi công cụ cụ thể, thay vì thêm từng hướng dẫn chuyên gia vào phiên làm việc chính. Các hướng dẫn về mô hình Claude tốt nhất cho công việc và các loại tác nhân AI này cung cấp thêm bối cảnh.

Nếu nhóm của bạn duy trì các lời nhắc trên nhiều sản phẩm AI khác nhau, hãy tham khảo các công cụ thiết kế lời nhắc này để quản lý thư viện ngoài Claude Code.

Khi một phiên làm việc cho ra kết quả chưa hoàn chỉnh hoặc không phù hợp, hãy kiểm tra xem yêu cầu có để lại những quyết định quan trọng chưa được giải quyết hay không. Năm sai lầm này có thể khiến việc chẩn đoán và đánh giá công việc trở nên khó khăn hơn.

“Khám phá kho lưu trữ” không cung cấp cho Claude nhiều hướng dẫn về những tệp nào quan trọng hoặc khi nào nên dừng lại. Bạn có thể nhận được một bản tóm tắt chung chung mà không có câu trả lời cho vấn đề đã dẫn đến yêu cầu đó.

Đặt tên cho hành vi hoặc quyết định mà bạn cần hiểu, xác định địa điểm bắt đầu và xác định kết quả đầu ra mong đợi. Ví dụ: “Theo dõi cách điểm cuối này kiểm tra quyền truy cập và trích dẫn các hàm liên quan.” Nếu bạn sử dụng các tác nhân phụ, hãy đưa ra cho mỗi tác nhân một câu hỏi có giới hạn thay vì giao cho chúng cùng một nhiệm vụ tìm kiếm không giới hạn.

Việc chuyển đổi giữa một tính năng, một lỗi không liên quan và một yêu cầu tài liệu khiến cuộc hội thoại mang theo bối cảnh có thể không áp dụng cho công việc hiện tại. Các tham chiếu như “tập tin đó” hoặc “cách tiếp cận trước đây” trở nên mơ hồ.

Sử dụng các phiên làm việc riêng biệt cho các công việc không liên quan. Nếu nhiều phiên làm việc sẽ chỉnh sửa kho lưu trữ, hãy sử dụng các Git worktrees riêng biệt để chúng không sửa đổi cùng một thư mục làm việc. Một câu hỏi phụ ngắn gọn: lệnh /btw của Claude Code giúp giữ cuộc trao đổi này tách biệt khỏi lịch sử cuộc hội thoại chính.

Một bản dựng có thể vượt qua kiểm tra trong khi một tính năng lại hoạt động không chính xác. Một bộ kiểm thử có thể vượt qua vì nó chưa bao giờ thử nghiệm với đầu vào gây lỗi. Yêu cầu Claude “chạy các bài kiểm thử” không xác định được yêu cầu nào mà các bài kiểm thử đó đang xác minh.

Liên kết các tiêu chí chấp nhận với các bước kiểm tra cụ thể. Đối với việc sửa lỗi, yêu cầu bằng chứng cho thấy bài kiểm tra tái hiện đã thất bại trước khi thực hiện thay đổi và thành công sau đó. Giữ các tiêu chí chưa được kiểm tra ở trạng thái hiển thị thay vì coi một lệnh thành công là bằng chứng xác minh cho toàn bộ thay đổi.

Một tệp CLAUDE.md đang được mở rộng có thể chứa các lệnh đã lỗi thời, các quy tắc trùng lặp và các hướng dẫn mâu thuẫn với các yêu cầu cụ thể của công việc. Việc thêm các từ ngữ mạnh mẽ hơn sẽ không giải quyết được những mâu thuẫn đó.

So sánh tệp với kho lưu trữ hiện tại. Loại bỏ các hướng dẫn đã lỗi thời, làm rõ các quy tắc mâu thuẫn và chuyển các hướng dẫn chỉ áp dụng trong phạm vi hẹp sang các quy tắc hoặc kỹ năng có phạm vi áp dụng theo đường dẫn. Nếu một yêu cầu cần được thực thi, hãy cấu hình và kiểm thử các biện pháp kiểm soát phù hợp thay vì dựa vào các lời nhắc nhở lặp đi lặp lại.

Một lần đánh giá có thể chỉ ra các lỗi thực sự, các vấn đề chưa rõ ràng và các đề xuất tái cấu trúc tùy chọn cùng một lúc. Việc áp dụng mọi đề xuất có thể làm mở rộng phạm vi thay đổi mà không cải thiện được hành vi mong muốn.

Yêu cầu bằng chứng và tác động đằng sau mỗi phát hiện. Ưu tiên các vấn đề về tính chính xác và các yêu cầu chưa được đáp ứng, điều tra các tuyên bố không rõ ràng và loại bỏ các cải tiến không liên quan khỏi bản diff hiện tại. Người đánh giá nên có thể báo cáo không có phát hiện nào cần xử lý khi bằng chứng hỗ trợ kết luận đó.