Xây dựng vòng lặp xác thực (verification loop) trong Claude Code bằng Skills

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.

Claude Code22/07/2026

Phần lớn các phiên làm việc agentic trong Claude Code đều đi theo một vòng lặp quen thuộc: bạn yêu cầu một thay đổi, Claude thu thập ngữ cảnh, hành động, xác thực kết quả, rồi nếu cần sẽ quay lại thu thập thêm ngữ cảnh. Xác thực là cách agent tự kiểm tra công việc trước khi báo lại cho bạn. Claude vốn đã suy ra được một phần việc này từ các tín hiệu tất định có sẵn trong codebase - type checker, linter, test, lỗi runtime. Phần còn lại, những gì Claude không thể tự suy ra, chính là các bước bạn vẫn phải tự tay kiểm tra một tính năng.

Vấn đề là: những bước kiểm tra thủ công đó hoàn toàn có thể chuyển thành verification loop (vòng lặp xác thực) - một chu trình lặp, trong đó Claude tự kiểm tra và tự sửa công việc của chính nó trước khi báo cáo xong.

Verification loop là gì?

Đó là một chu trình lặp lại: agent chạy test, linter, hoặc các kiểm tra tuỳ chỉnh, rồi sửa những gì thất bại trước khi tiếp tục. Trong Claude Code, verification loop có thể được đóng gói thành skill, để mọi phiên làm việc đều tự áp dụng cùng một bộ kiểm tra, thay vì trông chờ con người nhớ để làm điều đó mỗi lần.

Các cơ chế xác thực có sẵn

Trước khi tự thiết kế verification loop riêng, đáng để biết Claude Code đã hỗ trợ sẵn những gì:

Skill /verify - build, chạy và quan sát thay đổi ngay trong ứng dụng của bạn.
Tích hợp toolchain - Claude cố gắng bắt và xử lý mã lỗi, cảnh báo từ bất kỳ công cụ nào bạn cung cấp, như linter. Nên liệt kê chính xác lệnh build và test trong CLAUDE.md để Claude không phải tự đoán.
Code Review (research preview) - một dịch vụ multi-agent được quản lý, chạy một lượt review tự động trên PR ở các repo bạn bật tính năng này. Bạn có thể tự sửa lỗi được tìm thấy rồi push, hoặc đóng vòng lặp bằng cách comment @claude ngay dưới finding đó.
GitHub Actions - định nghĩa một job gọi Claude kèm một verification skill, để cùng bộ kiểm tra bạn chạy cục bộ cũng tự động chạy trên mỗi lần push hoặc mở PR.
Spec validation - một skill giúp đối chiếu từng thay đổi với một file spec Markdown trong repo, và tìm cách sửa nếu có vi phạm.
Rubric trong Claude Managed Agents (beta) - một dịch vụ agent được quản lý, cho phép xác thực kết quả đầu ra dựa trên rubric bằng một grader agent riêng biệt; nếu không đạt, công việc tự động quay lại để làm tiếp.

Viết verification loop của riêng bạn

Nếu bạn đang làm việc trên một dự án sẵn có và nhận ra mình cứ phải sửa đi sửa lại cùng một lỗi mỗi khi Claude thêm một tính năng mới, đó là lúc nên biến các bước sửa đó thành một verification loop riêng. Bước đầu tiên: ghi lại tất cả những gì bạn thường làm mỗi lần rà soát.

Với dự án mới cũng vậy - hãy viết ra phiên bản “cách làm chuẩn” bằng ngôn ngữ tự nhiên, như thể bạn đang hướng dẫn cho một đồng nghiệp mới vào ngày đầu tiên. Nếu chưa biết diễn đạt bài kiểm tra thế nào, có thể nhờ Claude gợi ý best practice trước rồi chỉnh sửa lại - phần khác biệt giữa gợi ý đó và cách bạn thực sự muốn chính là thứ đáng để ghi lại thành quy tắc riêng.

Biến nó thành một skill

Cách nhanh nhất để tạo skill là cài plugin skill-creator và để Claude phỏng vấn ngược lại bạn về quy trình làm việc:

/skill-creator Create a skill for verifying frontend changes end-to-end. Interview me about my workflow.

Bạn cũng có thể tự viết tay bằng cách thả một file Markdown vào .claude/skills/. Một skill xác thực tối giản chỉ cần vài dòng frontmatter cộng với phần nội dung:

---
name: verify-log-hygiene
description: Check that error logs include the request ID and never
  include the request body. Use when the diff touches error handling
  or logging.
allowed-tools: [Read, Edit, Grep]
---
Read the error-handling paths in the current diff.

For each log call on an error path, confirm it includes the request ID
and does not pass the request body, headers, or any user-supplied payload.

Report each violation with file:line, then fix it: add the request ID
where it's missing and strip the payload from the log call.

Chọn cách kích hoạt phù hợp

Bước tiếp theo là quyết định verification loop sẽ khởi chạy theo cách nào: standalone, embedded, chained, hay gắn vào mọi PR.

Standalone

Bạn tự gọi skill khi cần, sau khi sản phẩm đã tồn tại. Cách này phù hợp cho các kiểm tra xuyên suốt, không phải lúc nào cũng cần chạy - như quét bảo mật trước khi commit, kiểm tra khả năng tiếp cận (accessibility) trước khi mở PR, hay rà soát license header trên toàn repo. Bất cứ thứ gì bạn muốn dùng được ở nhiều quy trình khác nhau nhưng không muốn tự động chạy trên mọi thay đổi.

Cái giá phải trả là mỗi lần gọi vẫn tốn một lượt bạn phải nhớ để thực hiện. Dấu hiệu cho thấy bạn đã “vượt qua” giai đoạn standalone là khi bạn chạy nó sau mọi thay đổi - lúc đó, quy trình xứng đáng có một chỗ cố định hơn: embed hoặc chain nó lại.

Embedded

Skill tự động chạy như một phần của skill tạo ra sản phẩm đó. Kiểm tra này chỉ thuộc về một quy trình cụ thể, và giờ quy trình đó tự chạy kiểm tra mà không cần bạn yêu cầu. Cách đơn giản nhất là thêm một dòng vào cuối phần nội dung của skill gốc:

---
name: scaffold-component
description: Scaffold a new React component under src/components/, including the component file, its co-located test, and an index export. Use when the user asks to create a new component.
allowed-tools: [Read, Write, Edit, Bash, Glob]
---

# Scaffold a new React component

Given a component name (PascalCase), create the following under `src/components/<Name>/`:

1. `<Name>.tsx`: function component with a typed props interface and a default export.
2. `<Name>.test.tsx`: React Testing Library test that renders the component and asserts it mounts without throwing.
3. `index.ts`: re-export the default and any named exports.

Follow the patterns in `src/components/Button/` as the reference. Match the import alias style (`@/components/...`) used throughout the codebase.

# ...phần còn lại của skill...

After creating the component file, run eslint on it and
address any errors before reporting completion.

Kiểm chứng việc embed có hoạt động bằng cách gọi skill trên một tác vụ mới và xác nhận bước kiểm tra mới có chạy trong output. Nếu không, khả năng cao là phần mô tả (description) của skill hoặc các chỉ dẫn phía trước chưa “kéo” được bước kiểm tra thêm vào.

Cách này chỉ áp dụng được với skill bạn có quyền chỉnh sửa - skill tự viết, hoặc skill cài ở cấp dự án mà bạn kiểm soát file SKILL.md. Với skill dựng sẵn hay skill do plugin quản lý (loại bị ghi đè mỗi lần cập nhật), embed không dùng được - với những trường hợp đó, hãy dùng chained thay thế. Cũng nên bỏ qua embed nếu kiểm tra cần dùng chung cho nhiều quy trình khác nhau - trường hợp đó hợp với standalone hơn.

Chained

Một skill gọi skill khác ở bước cuối, tạo thành một chuỗi xác thực chạy liền mạch từ đầu đến cuối. Đội Claude Code của Anthropic dùng mẫu này trong công việc hằng ngày: /code-review tìm bug, /simplify dọn lại diff, một skill /verify xác nhận hành vi từ đầu đến cuối, và một skill /design tuỳ chỉnh đối chiếu với quy chuẩn trong file DESIGN.md nếu thay đổi có đụng đến giao diện.

Chaining cũng là cách để thêm xác thực vào một skill bạn không thể sửa trực tiếp: xây một skill “bọc” (wrapper) gọi skill gốc, rồi gọi tiếp skill xác thực của bạn:

Run /simplify on the current diff first.
When /simplify finishes, invoke /verify-no-public-api-changes.

Một thói quen (“mình luôn chạy /verify sau /simplify”) giờ trở thành một quy ước cố định (“/simplify luôn tự chạy /verify khi xong”). Cả chuỗi tự chạy hết chu trình phát triển; bạn chỉ can thiệp khi có gì đó cần leo thang lên tới bạn.

Có thể bỏ qua chaining nếu các bước đủ độc lập để đôi khi bạn muốn chạy riêng từng bước - chaining đánh đổi sự linh hoạt để lấy tự động hoá. Verification loop dạng chained có thể làm tăng lượng token tiêu tốn, nên hãy thử nghiệm kỹ trước khi triển khai rộng.

Gắn vào mọi PR

Khi chuỗi đã ổn định cho các thay đổi của riêng bạn, cùng quy trình đó có thể chạy trên mọi PR. Thay đổi của đồng nghiệp sẽ phải qua đúng những cổng kiểm tra mà thay đổi của bạn từng qua, bất kể họ có nhớ gọi chuỗi đó hay không. Đây là lúc xác thực không còn là “hạ tầng cá nhân” nữa mà trở thành “hạ tầng của cả đội” - bài kiểm tra bạn viết ra để tiết kiệm cho mình vài phút mỗi tuần, giờ tiết kiệm thời gian đó cho mọi người, trên mọi thay đổi. Nên tạm hoãn việc gắn gate cho toàn bộ PR trong lúc chuỗi vẫn còn đang thay đổi liên tục, vì mỗi lần chỉnh sửa lúc đó sẽ trở thành một sự kiện cả đội đều thấy.

Quy trình tổng quát

Khi đã quen, việc tạo verification loop luôn theo một quy trình nhất quán, bất kể bạn đang tự động hoá điều gì hay ở môi trường nào:

Chọn ra việc thủ công bạn phải làm lại nhiều nhất trong tuần.
Thử skill /verify có sẵn trước, xem có đáp ứng được quy trình của bạn không.
Viết quy trình đó bằng ngôn ngữ tự nhiên, như đang hướng dẫn một đồng nghiệp mới.
Đưa cho skill-creator, hoặc tự thả file Markdown vào .claude/skills/.
Gọi skill trên một tác vụ mới, xác nhận bước kiểm tra chạy đúng trong output, rồi lặp lại nếu cần chỉnh.
Thử nghiệm việc nối chuỗi skill để tạo thành một luồng xác thực trọn vẹn từ đầu đến cuối.

Càng mã hoá được nhiều quy trình cho Claude tuân theo, câu trả lời của Claude càng có xu hướng đúng ngay từ lần thử đầu tiên. Những lần sửa tay bạn không còn phải làm nữa sẽ giải phóng sự chú ý của bạn cho phần việc mà không skill nào viết thay được.

Bài viết gốc do Delba de Oliveira, thành viên đội Claude Code, chấp bút.

← Xem tất cả bài viết

Phuc Tran

Software Engineer | Learning Claude