Claude Code không nên được xem là một công cụ sinh mã đơn lẻ. Khi được đặt trong một quy trình có ngữ cảnh rõ, kế hoạch rõ và cơ chế kiểm chứng rõ, Claude Code có thể hỗ trợ lập trình, kiểm thử, phân tích log, đọc tài liệu dự án và xử lý các thay đổi lặp lại trong repository.
Các kinh nghiệm được trình bày trong bài viết này dựa trên cách nhóm phát triển Claude Code sử dụng chính công cụ của họ trong công việc hằng ngày. Điểm đáng chú ý không nằm ở việc Claude Code có thể tạo mã nhanh. Điểm quan trọng hơn là cách tổ chức môi trường để agent có thể làm việc ổn định, tự kiểm chứng kết quả và giảm lỗi lặp lại qua thời gian.
Trong nội bộ Anthropic, tỷ lệ kỹ sư kỹ thuật sử dụng Claude Code hằng ngày được mô tả ở mức hơn 70 phần trăm. Kênh phản hồi nội bộ có thể nhận phản hồi mới sau khoảng vài phút. Các con số này không nên được hiểu như thông tin quảng bá. Chúng cho thấy một thực tế vận hành: một AI coding agent muốn trưởng thành nhanh thì phải được sử dụng trong chính môi trường kỹ thuật mà nó cần phục vụ. Khi phản hồi đến từ công việc thật, nhóm phát triển có thể phát hiện sớm lỗi workflow, lỗi trải nghiệm và các mẫu sử dụng chưa ổn định.
Antfooding tạo ra phản hồi gần với môi trường sản xuất
Tự sử dụng sản phẩm (dogfooding) là thực hành trong đó nhóm phát triển dùng chính sản phẩm của mình trước khi phát hành rộng rãi. Anthropic gọi biến thể nội bộ của thực hành này là Antfooding. Với Claude Code, Antfooding có giá trị đặc biệt vì công cụ được dùng để phát triển chính Claude Code.
Điều này tạo ra một vòng phản hồi ngắn. Khi Claude Code xử lý một tác vụ trong codebase thật, nhóm phát triển có thể quan sát nó đọc ngữ cảnh như thế nào, lập kế hoạch ra sao, sửa mã ở đâu, bỏ sót ràng buộc nào và cần thêm cơ chế kiểm chứng gì. Vì vậy, các thực hành như Plan Mode, CLAUDE.md, Stop Hook, PostToolUse Hook, Git worktree song song và subagent review không phải là mẹo rời rạc. Chúng là kết quả của việc quan sát agent trong môi trường kỹ thuật có áp lực thật.
Giá trị của Antfooding nằm ở việc công cụ được kiểm tra bằng chính loại công việc mà nó cần hỗ trợ. Một lỗi nhỏ trong workflow có thể được phát hiện sớm. Một mẫu sử dụng tốt có thể được chuẩn hóa thành quy trình. Một sai lệch lặp lại có thể được ghi lại thành quy tắc để agent tránh mắc lại.
Verification loop là điều kiện để kết quả đáng tin cậy hơn
Vòng lặp kiểm chứng (verification loop) là nguyên tắc quan trọng nhất khi dùng Claude Code. Người dùng không nên chỉ yêu cầu Claude sửa mã rồi chờ kết quả cuối cùng. Người dùng cần cung cấp cho Claude một cách để tự chạy, tự kiểm tra, tự đọc lỗi và tự sửa trong phạm vi đã được giao.
Verification loop không thay thế review của con người. Nó giúp loại bỏ các lỗi có thể phát hiện tự động trước khi kết quả được chuyển lại cho người dùng. Nếu không có verification loop, Claude chủ yếu dựa vào suy luận từ mã nguồn. Khi có verification loop, Claude có thêm bằng chứng từ hệ thống thật như kết quả test, log runtime, trình duyệt, output từ CLI hoặc kết quả truy vấn dữ liệu.
Với backend và API, bằng chứng phù hợp thường là test suite. Claude cần được phép chạy các lệnh như mvn test, bun run test hoặc các lệnh kiểm thử tương đương của dự án. Khi test thất bại, Claude đọc lỗi và sửa lại. Với frontend và UI, bằng chứng phù hợp hơn là giao diện thật trong trình duyệt, vì thay đổi trực quan không thể đánh giá đầy đủ bằng cách đọc mã. Với script và CLI, Claude cần chạy lệnh, đọc output và xác định lỗi từ thông tin thực tế. Với hệ thống phân tán, log từ container và service runtime thường quan trọng hơn phân tích tĩnh. Với dữ liệu và analytics, Claude cần chạy truy vấn và đối chiếu kết quả.
Điểm chung của các trường hợp trên là Claude phải nhìn thấy hậu quả của hành động. Khi agent chỉ đọc mã, nó dễ dự đoán sai trạng thái thực tế. Khi agent được phép chạy test, mở browser, đọc log hoặc truy vấn dữ liệu, quá trình sửa lỗi có cơ sở hơn.
Stop Hook có thể được dùng để làm cho verification loop tự động hơn. Khi Claude chuẩn bị dừng, hệ thống chạy một lệnh kiểm thử. Nếu kiểm thử thất bại, trạng thái thất bại không được xem là kết quả cuối cùng. Nó trở thành tín hiệu để Claude tiếp tục sửa. Nhờ vậy, người dùng không phải nhắc lại nhiều lần rằng cần chạy test sau khi sửa mã.
Mã minh họa cho verification loop
Đoạn cấu hình dưới đây minh họa cách yêu cầu Claude chạy kiểm thử trước khi kết thúc phiên làm việc. Ý chính không nằm ở tên lệnh cụ thể. Ý chính nằm ở việc biến kết quả kiểm thử thành phản hồi bắt buộc. Nếu test thất bại, Claude phải đọc lỗi và tiếp tục sửa thay vì trả về một kết quả chưa được kiểm chứng.
{
"hooks": {
"Stop": [
{
"matcher": "*",
"hooks": [
{
"type": "command",
"command": "bun run test || echo TEST_FAILED_CONTINUE"
}
]
}
]
}
}Với dự án Java, phần command có thể đổi thành mvn test. Với dự án .NET, có thể đổi thành dotnet test. Cách viết cụ thể cần khớp với cấu trúc repository, nhưng nguyên tắc vẫn giữ nguyên. Agent chỉ được xem là hoàn tất khi đã có bằng chứng kiểm thử.
Plan Mode giúp giảm sai lệch trước khi triển khai
Chế độ lập kế hoạch (Plan Mode) giúp Claude đọc ngữ cảnh, xác định phạm vi thay đổi, chỉ ra rủi ro và đề xuất hướng triển khai trước khi sửa mã. Đây là bước quan trọng với các tác vụ có nhiều phụ thuộc hoặc ảnh hưởng đến kiến trúc.
Khi bỏ qua Plan Mode, Claude có thể sửa đúng một phần nhưng bỏ sót ràng buộc hệ thống. Khi bắt đầu bằng Plan Mode, người dùng có thể kiểm tra hướng tiếp cận trước khi repository bị thay đổi. Cách làm này không làm chậm quy trình nếu xét toàn bộ vòng đời của task. Nó làm giảm khả năng phải sửa lại nhiều lần ở cuối.
Một quy trình hợp lý là để Claude đọc các file liên quan, đọc cấu trúc thư mục, đọc test hiện có và đọc CLAUDE.md trước. Sau đó Claude nêu kế hoạch gồm các bước thay đổi, file liên quan, điểm rủi ro và cách kiểm chứng. Người dùng duyệt kế hoạch, chỉnh phạm vi nếu cần, rồi mới yêu cầu Claude triển khai. Sau khi triển khai, Claude chạy lại verification loop để chứng minh thay đổi đạt yêu cầu.
Với các thay đổi lớn, có thể dùng một Claude để viết kế hoạch và một Claude khác để review kế hoạch như một kỹ sư cấp cao. Cách này giúp phát hiện sớm các giả định sai trước khi mã được sửa. Khi kế hoạch tốt hơn, khả năng triển khai đúng ngay từ lần đầu cũng cao hơn.
Ví dụ brief cho Plan Mode
Brief dưới đây cho thấy cách giao việc ở mức mục tiêu và ràng buộc, không điều khiển Claude từng dòng. Người dùng yêu cầu Claude đọc mã, lập kế hoạch, nêu rủi ro và đề xuất cách kiểm chứng trước khi sửa file.
Hãy bật Plan Mode và chưa sửa mã ở bước này.
Mục tiêu: bổ sung kiểm tra quyền truy cập trước khi người dùng tải báo cáo.
Phạm vi cần đọc:
src/controllers/reportController.ts
src/services/reportService.ts
tests/reportAccess.test.ts
CLAUDE.md
Ràng buộc:
Không thay đổi schema database.
Không đổi response format hiện tại.
Không sửa các module ngoài phạm vi report.
Yêu cầu đầu ra:
Nêu kế hoạch sửa mã.
Nêu rủi ro có thể phát sinh.
Nêu lệnh kiểm thử cần chạy sau khi triển khai.
Đây là dạng brief phù hợp vì nó đặt Claude vào vai trò phân tích trước khi triển khai. Agent có đủ thông tin để đọc đúng vùng mã, nhưng vẫn chưa được phép thay đổi repository cho đến khi kế hoạch được xem xét.CLAUDE.md là tài liệu vận hành của agent
Tệp CLAUDE.md nên được xem là tài liệu vận hành của agent trong repository. Tệp này ghi lại quy tắc phát triển, lệnh kiểm thử, chuẩn mã nguồn, lỗi Claude thường mắc và các quyết định kỹ thuật mà nhóm muốn Claude tuân thủ.
CLAUDE.md nên được đưa vào Git để toàn bộ nhóm cùng cập nhật và cùng hưởng lợi. Khi Claude mắc lỗi, việc chỉ sửa lỗi hiện tại là chưa đủ. Nếu lỗi có khả năng lặp lại, nhóm cần chuyển lỗi đó thành một quy tắc rõ ràng trong CLAUDE.md. Theo thời gian, tệp này giúp giảm tỷ lệ lỗi lặp lại và làm hành vi của Claude phù hợp hơn với repository.
Nội dung trong CLAUDE.md không nên quá dài hoặc quá chung chung. Một quy tắc tốt cần ngắn, có thể hành động ngay và gắn với tình huống thật. Ví dụ, dự án có thể quy định luôn dùng bun thay vì npm, luôn chạy typecheck trước test, không dùng TypeScript enum, ưu tiên string literal union, hoặc không tạo pull request khi test chưa chạy.
Giá trị của CLAUDE.md nằm ở tính tích lũy. Một nhận xét trong pull request có thể trở thành quy tắc dùng chung cho toàn nhóm. Một lỗi do một người phát hiện có thể giúp agent tránh lỗi đó trong các task sau. Đây là cách biến kinh nghiệm vận hành thành tri thức kỹ thuật có thể tái sử dụng.
Ví dụ CLAUDE.md
Đoạn dưới đây minh họa một CLAUDE.md ngắn. Nội dung không cố mô tả toàn bộ dự án. Nó tập trung vào các lệnh và quy tắc mà Claude cần dùng thường xuyên trong quá trình sửa mã.
# Development Workflow
Always use bun. Do not use npm.
Run commands in this order after changing code:
bun run typecheck
bun run test
bun run lint
Before creating a pull request, run:
bun run lint:claude
bun run test
Coding rules:
Never use TypeScript enum.
Use string literal unions instead.
Prefer type over interface.
Never create a pull request before tests pass.Cách viết này giúp Claude biết phải chạy lệnh nào và tránh pattern nào. Nếu dự án có thêm lỗi lặp lại, lỗi đó nên được chuyển thành một quy tắc mới trong CLAUDE.md, thay vì chỉ được nhắc lại trong từng phiên làm việc riêng lẻ.
Compounding Engineering biến lỗi thành Improving dài hạn
Tích lũy kỹ thuật (Compounding Engineering) có thể hiểu là việc biến mỗi lần sửa lỗi thành một cải tiến lâu dài trong quy trình. Khi Claude dùng sai pattern hoặc bỏ sót một quy tắc của repository, người dùng không chỉ yêu cầu sửa đoạn mã hiện tại. Người dùng cần yêu cầu cập nhật CLAUDE.md hoặc cập nhật workflow để lỗi đó ít có khả năng quay lại.
Cách làm này đặc biệt có ích trong nhóm nhiều người. Nếu chỉ sửa lỗi tại chỗ, tri thức vẫn nằm trong trí nhớ của một reviewer. Nếu chuyển lỗi thành quy tắc trong CLAUDE.md, tri thức đó trở thành một phần của môi trường làm việc. Agent và các thành viên khác đều có thể sử dụng lại.
Một repository dùng Claude Code hiệu quả thường không bắt đầu với CLAUDE.md hoàn hảo. Tệp này được hình thành dần từ những tình huống thật. Càng nhiều lỗi được chuyển thành quy tắc rõ, hành vi của Claude càng ổn định hơn trong các lần làm việc sau.
Ví dụ chuyển nhận xét review thành quy tắc
Ví dụ dưới đây mô tả một nhận xét trong pull request được chuyển thành quy tắc vận hành. Đây là phần nên đưa vào CLAUDE.md nếu lỗi có khả năng lặp lại.
Reviewer note:
Claude used TypeScript enum in a module where the repository prefers string literal unions.
Rule to add to CLAUDE.md:
Never use TypeScript enum in this repository.
Use string literal unions for closed value sets.
Example:
type ReportStatus = 'draft' | 'approved' | 'rejected';Sau khi quy tắc này được đưa vào CLAUDE.md, nó trở thành tri thức chung của repository. Lần sau Claude có thể đọc lại quy tắc trước khi sửa mã và giảm nguy cơ lặp lại cùng một lỗi.
Git worktree giúp tách các phiên làm việc song song
Phiên làm việc song song (parallel session) phù hợp khi dự án có nhiều tác vụ độc lập. Git worktree cho phép tạo nhiều không gian làm việc từ cùng một repository. Mỗi Claude session có thể làm việc trong một worktree riêng, tránh ghi đè thay đổi của session khác.
Có thể tách worktree theo mục đích. Một worktree dành cho thay đổi chức năng. Một worktree dành cho sửa lỗi cụ thể. Một worktree khác chỉ dùng để phân tích log, chạy truy vấn hoặc đọc dữ liệu. Cách tách này giúp người dùng biết rõ mỗi session đang làm gì và tránh trộn lẫn thay đổi thử nghiệm với thay đổi sẽ đưa vào pull request.
Trong thực tế, các nhãn như feature worktree, bugfix worktree và analysis worktree không phải là thứ tự bắt buộc. Chúng là cách phân loại phạm vi. Một dự án có thể mở nhiều feature worktree hoặc nhiều bugfix worktree cùng lúc. Nguyên tắc chính là mỗi phiên Claude phải có phạm vi rõ, nhánh làm việc rõ và tiêu chí hoàn thành riêng.
Analysis worktree nên được xem là vùng đọc và thử nghiệm. Nếu agent vừa phân tích log vừa sửa mã trong cùng một không gian, người dùng khó phân biệt thay đổi nào là kết quả chính thức và thay đổi nào là thử nghiệm tạm. Tách worktree giúp việc review sạch hơn và giảm rủi ro nhập nhầm thay đổi.
Ví dụ tạo worktree cho nhiều phiên Claude
Đoạn lệnh dưới đây tạo ba vùng làm việc độc lập. Hai vùng đầu dùng cho thay đổi mã. Vùng cuối chỉ dùng để phân tích, đọc log hoặc chạy truy vấn. Tên nhánh và thư mục cần được điều chỉnh theo quy ước của từng dự án.
git worktree add .claude/worktrees/featureA origin/main
git worktree add .claude/worktrees/bugfixB origin/main
git worktree add .claude/worktrees/analysis origin/main
alias ca='cd .claude/worktrees/featureA && claude'
alias cb='cd .claude/worktrees/bugfixB && claude'
alias cc='cd .claude/worktrees/analysis && claude'Cách tổ chức này giúp người dùng mở nhiều phiên Claude mà không làm lẫn thay đổi. Sau khi từng phiên hoàn tất, mỗi worktree có thể được review riêng như một pull request độc lập.
Migration là nhóm tác vụ phù hợp với agent
Các tác vụ migration thường có tính lặp lại, phạm vi lớn và tiêu chí kiểm chứng rõ. Vì vậy, chúng phù hợp để giao cho Claude Code xử lý theo mô hình nhiều worktree hoặc nhiều subagent. Ví dụ gồm đổi API cũ sang API mới, cập nhật pattern truy cập dữ liệu, thay đổi framework test hoặc chuẩn hóa cấu trúc file.
Quy trình migration nên bắt đầu bằng việc main agent xác định toàn bộ file cần thay đổi và chia thành các nhóm độc lập. Sau đó, các subagent xử lý từng nhóm thay đổi. Cuối cùng, test suite cũ được chạy lại để xác nhận hành vi hệ thống vẫn đúng sau migration.
Điểm quan trọng là agent không nên tự ý mở rộng phạm vi migration. Khi danh sách file, quy tắc chuyển đổi và tiêu chí kiểm chứng đã rõ, Claude có thể làm việc rất hiệu quả. Khi phạm vi mơ hồ, migration dễ biến thành nhiều thay đổi phụ khó review và khó truy vết.
Ví dụ task list cho migration
Task list dưới đây minh họa cách chia migration thành các phần kiểm soát được. Mỗi nhóm file có điều kiện hoàn thành riêng và đều quay lại verification loop ở cuối.
Migration goal:
Replace legacy report permission checks with centralized access policy.
Scope:
src/controllers/reportController.ts
src/services/reportService.ts
src/policies/reportPolicy.ts
tests/reportAccess.test.ts
Do not change:
Database schema
Public API response format
Authentication middleware
Steps:
Read existing tests.
Create reportPolicy if it does not exist.
Move access decision into reportPolicy.
Update service calls to use reportPolicy.
Add tests for owner, reviewer and unauthorized user.
Run full report test suite.
Completion criteria:
All existing report tests pass.
New access control tests pass.
No unrelated file is modified.Một task list như vậy giúp Claude hiểu rõ phạm vi. Nó cũng giúp reviewer kiểm tra xem agent có vượt quá phạm vi hay không.
Subagent cần có vai trò rõ ràng
Tác nhân phụ (subagent) không chỉ dùng để chia nhỏ khối lượng công việc. Subagent còn có thể tạo ra nhiều góc nhìn kiểm tra khác nhau. Trong review mã, một subagent có thể kiểm tra style, một subagent kiểm tra lịch sử dự án, một subagent tìm lỗi logic và một subagent kiểm tra rủi ro bảo mật.
Cách phân vai này làm giảm nguy cơ một agent trộn lẫn nhiều mục tiêu rồi bỏ sót chi tiết. Style reviewer chỉ tập trung vào quy tắc trình bày và quy ước repository. History reviewer so sánh với lịch sử mã để phát hiện trùng lặp hoặc lệch pattern. Bug and security reviewer tập trung vào logic, edge case, authorization, input validation, secret handling và dependency có rủi ro.
Mẫu này có giá trị vì nó buộc Claude phân biệt loại nhận xét. Một lỗi bảo mật không bị đặt ngang hàng với lỗi style nhỏ. Ngược lại, một vi phạm style cũng không bị bỏ qua nếu repository đã xem nó là quy tắc vận hành chính thức trong CLAUDE.md. Kết quả cuối cùng nên được tổng hợp sau khi các subagent đưa ra nhận xét độc lập.
Ví dụ slash command cho subagent review
Đoạn dưới đây có thể đặt trong một command nội bộ. Mục tiêu là ép các subagent review theo vai trò, sau đó tổng hợp nhận xét thay vì tạo pull request quá sớm.
# Code review command
Spawn three subagents simultaneously.
Agent 1: Style reviewer
Read CLAUDE.md.
Review the diff against repository style rules.
Report only style violations.
Agent 2: History reviewer
Search git history for similar implementations.
Report duplicated logic or inconsistent patterns.
Agent 3: Bug and security reviewer
Review logic errors, edge cases, authorization, input validation, secret handling and dependency risk.
Report only functional or security issues.
Final step:
Synthesize findings.
Separate style issues from functional issues.
Separate functional issues from security issues.
Do not create a pull request until all critical issues are resolved.Cách viết này phù hợp với secure code review vì nó yêu cầu agent tách rõ lỗi trình bày, lỗi chức năng và lỗi bảo mật. Reviewer con người cũng dễ kiểm tra lại kết quả hơn.
PostToolUse Hook duy trì chuẩn kỹ thuật sau mỗi lần sửa file
Móc xử lý sau khi dùng công cụ (PostToolUse Hook) giúp tự động chạy các tác vụ lặp lại sau khi Claude ghi hoặc sửa file. Trường hợp phổ biến nhất là format code. Dù Claude có thể format đúng trong nhiều trường hợp, vẫn cần cơ chế tự động để tránh lỗi nhỏ làm hỏng CI.
Hook chỉ nên xử lý các thao tác cơ học và ít gây rủi ro, chẳng hạn format, checkstyle hoặc lint ở phạm vi hẹp. Các thao tác có khả năng thay đổi hành vi hệ thống vẫn cần đi qua verification loop và review. Nói cách khác, hook giúp giữ vệ sinh kỹ thuật, nhưng không thay thế test suite.
Cách dùng hợp lý là sau mỗi lần Claude ghi hoặc sửa file, hệ thống tự chạy formatter tương ứng với công nghệ của dự án. Nếu formatter thất bại, lỗi đó cần được xử lý trước khi pull request hoàn tất. Tuy nhiên, việc formatter thất bại không nên luôn chặn toàn bộ phiên làm việc, vì Claude có thể cần tiếp tục đọc lỗi và sửa lại.
Ví dụ PostToolUse Hook
Đoạn cấu hình dưới đây minh họa việc chạy formatter sau khi Claude ghi hoặc sửa file. Lệnh cụ thể có thể thay đổi theo stack công nghệ của dự án.
{
"hooks": {
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "command",
"command": "bun run format || true"
}
]
}
]
}
}Với dự án Java, command có thể là mvn checkstyle:check. Với dự án .NET, command có thể là dotnet format. Dù dùng lệnh nào, hook chỉ nên hỗ trợ chuẩn hóa cơ học. Việc xác nhận hành vi vẫn phải dựa trên test và review.
Giao việc rõ ràng thay vì điều khiển từng dòng
Một nguyên tắc quan trọng khi dùng Claude Code là xem agent như một kỹ sư được giao nhiệm vụ, không phải một công cụ cần hướng dẫn từng dòng. Điều này không đồng nghĩa với giao việc mơ hồ. Ngược lại, brief ban đầu cần đầy đủ ngữ cảnh, phạm vi, ràng buộc và tiêu chí kiểm chứng.
Một brief tốt cần nói rõ mục tiêu cần đạt, các file hoặc module liên quan, điều không được thay đổi, chuẩn mã nguồn cần tuân thủ và cách chứng minh kết quả. Nếu Claude phải hỏi lại nhiều câu cơ bản, đó thường là dấu hiệu brief chưa đủ thông tin.
Sau khi brief rõ, người dùng nên để Claude đọc mã, lập kế hoạch, triển khai và tự kiểm chứng. Việc can thiệp quá thường xuyên có thể làm agent mất mạch xử lý. Vai trò của con người vẫn rất quan trọng, nhưng nên tập trung vào mục tiêu, ràng buộc, kế hoạch và tiêu chí chấp nhận thay vì điều khiển từng dòng sửa.
Ví dụ prompt giao việc theo mục tiêu
Prompt dưới đây không yêu cầu Claude sửa từng dòng. Nó mô tả kết quả mong muốn, phạm vi và tiêu chí kiểm chứng. Đây là cách phù hợp hơn khi muốn agent làm việc tự chủ nhưng vẫn có kiểm soát.
Hãy xử lý lỗi người dùng không có quyền vẫn tải được báo cáo nội bộ.
Trước khi sửa mã, hãy đọc controller, service, policy và test liên quan.
Yêu cầu:
Xác định nguyên nhân gốc.
Đề xuất kế hoạch sửa.
Chỉ sửa trong module report.
Không thay đổi response format.
Bổ sung test cho trường hợp người dùng không có quyền.
Chạy test liên quan sau khi sửa.
Tóm tắt bằng chứng kiểm chứng sau khi hoàn tất.Prompt này tạo ra một ranh giới rõ. Claude có quyền phân tích và triển khai, nhưng không được mở rộng phạm vi hoặc bỏ qua bằng chứng kiểm chứng.
Không chấp nhận bản sửa tạm
Một lỗi phổ biến khi dùng AI coding agent là chấp nhận bản sửa chạy được nhưng thiết kế kém. Với Claude Code, người dùng nên yêu cầu giải pháp đúng về kiến trúc, đúng về hành vi và có bằng chứng kiểm chứng, không chỉ yêu cầu lỗi biến mất tạm thời.
Khi bản sửa hiện tại chỉ giải quyết triệu chứng, người dùng nên yêu cầu Claude đánh giá lại toàn bộ cách tiếp cận và đề xuất giải pháp đúng kiến trúc hơn. Khi cần review nghiêm khắc, người dùng có thể yêu cầu Claude phản biện thay đổi trước khi tạo pull request. Khi cần chứng minh hành vi đã thay đổi, Claude phải dùng test, log hoặc so sánh behavior giữa branch hiện tại và main branch.
Với lỗi CI, Claude cần đọc thông tin lỗi thật và sửa nguyên nhân gốc. Với lỗi đến từ báo cáo bên ngoài, Claude cần truy vết từ báo cáo, log hoặc thread liên quan đến phần mã gây lỗi. Tinh thần chung là yêu cầu agent xử lý vấn đề kỹ thuật hoàn chỉnh, không chỉ tạo patch nhỏ để vượt qua một kiểm tra trước mắt.
Ví dụ yêu cầu chứng minh bản sửa
Khi nghi ngờ Claude chỉ sửa triệu chứng, có thể yêu cầu agent chứng minh thay đổi bằng test và so sánh hành vi. Phần dưới là một mẫu prompt ngắn.
Hãy chứng minh bản sửa này thực sự thay đổi hành vi lỗi.
Yêu cầu:
Mô tả behavior trên main branch.
Mô tả behavior trên branch hiện tại.
Chạy test thể hiện lỗi cũ thất bại trên main branch.
Chạy test thể hiện lỗi đã được sửa trên branch hiện tại.
Nếu không thể chạy được test, hãy nêu lý do và đưa ra bằng chứng thay thế từ log hoặc code path.Mẫu này buộc Claude nối kết bản sửa với bằng chứng. Nó cũng giúp reviewer phân biệt giữa patch chỉ làm hết lỗi trước mắt và thay đổi thật sự sửa đúng nguyên nhân.
Permission cần giới hạn theo lệnh an toàn
Quyền thực thi lệnh (permission) không nên bị tắt hoàn toàn. Cách tốt hơn là cho phép trước các lệnh an toàn và thường dùng, trong khi các lệnh có rủi ro cao vẫn cần phê duyệt.
Các lệnh build, test, typecheck, tìm kiếm file và truy vấn chỉ đọc thường cần được chạy nhiều lần trong verification loop. Nếu lệnh nào cũng cần xác nhận thủ công, agent bị ngắt mạch và hiệu quả tự kiểm chứng giảm mạnh. Ngược lại, các lệnh xóa dữ liệu, force push, thay đổi secret hoặc thay đổi quyền truy cập vẫn phải yêu cầu sự đồng ý của người dùng.
Nguyên tắc là quyền tự động phải đi kèm giới hạn rõ. Claude nên được tự chạy các lệnh giúp kiểm chứng kết quả, nhưng không nên được tự thực hiện các thao tác làm thay đổi trạng thái khó khôi phục nếu chưa có phê duyệt.
Ví dụ danh sách lệnh được cho phép
Danh sách dưới đây minh họa các lệnh có thể được cho phép trước trong một repository JavaScript hoặc TypeScript. Danh sách này chỉ là ví dụ. Dự án thật cần điều chỉnh theo công nghệ, mức rủi ro và quy định nội bộ.
Allow: Bash(bun run build:*)
Allow: Bash(bun run test:*)
Allow: Bash(bun run typecheck:*)
Allow: Bash(find:*)
Allow: Bash(grep:*)
Allow: Bash(bq query:*)
Require approval:
rm
rm -rf
git push --force
changing secrets
changing production configurationCách phân quyền này giúp Claude có đủ khả năng tự kiểm chứng nhưng không có quyền thực hiện các thao tác nguy hiểm mà không có kiểm soát của con người.
Kết luận
Các thực hành với Claude Code không chỉ là kinh nghiệm thao tác. Chúng phản ánh một cách tổ chức công việc với AI coding agent. Người dùng hiệu quả không chỉ yêu cầu agent viết mã. Họ cung cấp ngữ cảnh, bắt đầu bằng kế hoạch, thiết lập verification loop, tích lũy quy tắc trong CLAUDE.md, chia nhỏ phiên làm việc bằng Git worktree và giới hạn quyền thực thi theo mức rủi ro.
Ba nguyên tắc cần giữ ổn định là Verify, Delegate và Compound. Verify bảo đảm Claude có bằng chứng để kiểm chứng kết quả. Delegate giúp Claude làm việc như một kỹ sư được giao nhiệm vụ rõ ràng. Compound giúp tri thức vận hành được tích lũy qua từng lần sửa lỗi.
Khi ba điều kiện này được duy trì cùng lúc, Claude Code trở thành một phần của quy trình kỹ thuật có kiểm soát. Agent có không gian để tự làm việc, nhưng vẫn bị ràng buộc bởi kế hoạch, bằng chứng kiểm chứng, quy tắc repository và quyền phê duyệt của con người.
