Bỏ qua để đến nội dung

Tin tưởng nó: kiểm chứng các lần chạy không giám sát

Bài viết được dịch tự động từ bài viết gốc, chưa được kiểm tra lại bởi con người. Chỉ những bài viết có dấu tick xanh cạnh tiêu đề là đã được kiểm tra.

Bạn giao một tác vụ cho Claude và để nó chạy mà không theo dõi từng bước. Giờ nó báo đã xong. Trước khi ship kết quả đó, bạn cần một cách kiểm tra thứ mà bạn còn không giám sát. Bước kiểm tra đó chính là điều làm cho Claude Code “buông tay” trở nên an toàn để tin tưởng.

Ý tưởng ở đây rất đơn giản: kiểm chứng tương xứng với mức độ tự do bạn đã cho lần chạy đó. Nếu bạn theo dõi các tin nhắn lướt qua trong một phiên ngắn, một cái liếc nhanh là đủ. Nhưng một lần chạy không giám sát, hay một job kích hoạt trong continuous integration mà không có ai theo dõi, cần một sự kiểm tra thực sự. Không ai chứng kiến chuyện gì đã xảy ra, nên bạn phải tái dựng lại nó sau đó.

Hãy hình dung thế này: bạn càng ít theo dõi, bạn càng phải kiểm chứng nhiều.

Giữ các lần chạy không giám sát ở auto mode

Phần tiêu đề “Giữ các lần chạy không giám sát ở auto mode”

Khi một lần chạy diễn ra không giám sát trong công việc, hãy giữ nó ở auto mode thay vì bypass permissions. Ở auto mode, classifier vẫn review từng hành động để tìm nguy hiểm. Đó là một lưới an toàn đáng giữ lại.

Nhưng hãy hiểu rõ lưới đó làm được gì và không làm được gì. Classifier không bao giờ đánh giá liệu code có đúng hay không. Nó chỉ gắn cờ các hành động nguy hiểm. Vậy nên mức chuẩn kiểm chứng của bạn vẫn giữ nguyên như cũ. Đặt mức chuẩn đó dựa trên việc lần chạy đó không giám sát tới mức nào.

Bắt đầu từ diff, không phải bản tóm tắt

Phần tiêu đề “Bắt đầu từ diff, không phải bản tóm tắt”

Đừng bắt đầu từ bản tóm tắt của Claude về những gì nó đã làm. Hãy bắt đầu từ chính diff.

  1. Chạy /code-review để rà qua các thay đổi và gắn cờ vấn đề.
  2. Sau đó tự mình nhìn vào git diff.

Cái bẫy là một bản tóm tắt gọn gàng, đọc nghe rất xuôi tai, trong khi diff thực tế lại chạm vào một file mà bạn hoàn toàn không ngờ tới. Bản tóm tắt sẽ không nói cho bạn biết điều đó. Diff thì có.

Vậy nên hãy đọc những gì đã thay đổi. Đọc các file nằm trong kế hoạch trước, sau đó tìm bất cứ thứ gì nằm ngoài kế hoạch đó. Một bản tường trình gọn gàng không phải là bằng chứng cho một đoạn code sạch.

Biến test thành một cổng chặn, không phải một lời hứa

Phần tiêu đề “Biến test thành một cổng chặn, không phải một lời hứa”

Cổng chặn thực sự với một lần chạy không giám sát là liệu test có pass hay không, và liệu Claude có thực sự chạy chúng hay chỉ tuyên bố là đã chạy. Đừng để điều đó dựa vào lòng tin. Hãy gắn nó thành một hook để Claude không thể bỏ qua.

Có vài hook làm được việc này:

  • Một stop hook chạy test của bạn và từ chối kết thúc lượt (turn) nếu có lỗi.
  • Một post-tool-use hook lint và type-check sau mỗi lần chỉnh sửa.

Chi tiết quan trọng nhất là exit code. Một hook exit với exit 2 sẽ đưa lỗi thẳng trở lại cho Claude. Claude đọc lỗi đó và tự sửa mà không cần bạn yêu cầu. Điều tuyệt nhất: bước kiểm tra này kích hoạt ở mọi lần chạy, dù bạn có nhớ để yêu cầu nó hay không.

Cách review bằng sub-agent bạn từng chạy trước khi tạo pull request cũng áp dụng được ở đây. Hãy chỉ nó vào một lần chạy không giám sát.

Mở một phiên hoặc sub-agent mới và để nó review code đã thay đổi mà không có bất kỳ ký ức nào về cách code được viết ra. Vì nó không có “cổ phần” gì trong cách tiếp cận ban đầu, nó bắt được những thứ mà lần chạy gốc đã tự thuyết phục bản thân bỏ qua. Một reviewer thứ hai với cái nhìn hoàn toàn mới sẽ tìm ra những gì tác giả ban đầu đã hợp lý hoá để bỏ qua.

Hãy làm bước kiểm tra nghiêm túc tương xứng với mức độ không giám sát của lần chạy đó:

  • Tự mình đọc diff.
  • Biến test thành một hook chốt chặn lượt (turn).
  • Kiểm chứng các lần chạy headless qua kết quả JSON và exit code của chúng.
  • Lấy một ý kiến thứ hai “lạnh” cho bất cứ điều gì quan trọng.

Làm được vậy, câu “Claude đã làm trong lúc tôi không để ý” không còn cần tới niềm tin mù quáng nữa.

Xem thêm: Best practices § Cho Claude cách tự kiểm chứng công việc · Đánh giá & độ tin cậy