9 mẹo thực chiến về Claude Code của Boris: Hóa ra cấu hình của cao thủ lại "đơn giản" đến vậy Boris Cherny có một biệt danh trong nội bộ Anthropic: Cha đẻ của Claude Code. Gần đây, anh ấy rất hoạt động trên X, vì vậy nhiều người đã hỏi Boris: Bạn thực sự sử dụng Claude Code như thế nào? Anh ấy vừa chia sẻ 9 mẹo thực chiến trên X. Không có nhiều mẹo như bạn tưởng, mỗi mẹo đều rất giản dị. 【1】Triết lý cốt lõi: Không có câu trả lời chuẩn cho các thực hành tốt nhất của Claude Code Boris mở đầu bằng cách nói: > Cấu hình của tôi có thể sẽ khiến bạn ngạc nhiên vì nó rất "nguyên bản"! Claude Code hoạt động tuyệt vời ngay từ đầu, vì vậy tôi cá nhân không tùy chỉnh nhiều. > Cấu hình của tôi có thể khiến bạn ngạc nhiên vì nó rất "nguyên bản". Claude Code hoạt động tốt ngay khi mở hộp, tôi cá nhân không thực hiện nhiều tùy chỉnh. Cũng có thể hiểu, những thực hành tốt nhất, như Skills, Plugins, với tư cách là nhà phát triển Claude Code, họ đã tích hợp những thực hành tốt nhất này vào chức năng từ lâu. Không có cách duy nhất đúng để sử dụng Claude Code. Nhóm đã cố tình thiết kế nó để có thể tùy chỉnh thoải mái, bạn muốn sử dụng, thay đổi, hoặc tùy chỉnh thế nào cũng được. Cách sử dụng của mỗi người trong đội ngũ Claude Code hoàn toàn khác nhau. Vì vậy, không cần phải tốn công tìm kiếm "thực hành tốt nhất", điều quan trọng nhất là phù hợp với nhịp độ của bản thân. 【2】Nhiệm vụ đa Agent song song: Mở cùng lúc hàng chục Claude Ngày thường của Boris như sau: mở 5 phiên bản Claude Code trong terminal, các tab được đánh số từ 1 đến 5, bật thông báo hệ thống, cái nào cần nhập thì chuyển qua xử lý. Cùng lúc, anh ấy cũng chạy từ 5 đến 10 nhiệm vụ trên phiên bản web. Terminal và web có thể "chuyển giao" cho nhau: sử dụng ký hiệu & để chuyển phiên làm việc địa phương sang web, hoặc sử dụng --teleport để chuyển đổi giữa hai bên. Mỗi sáng và ban ngày, anh ấy sẽ khởi động một vài nhiệm vụ từ ứng dụng Claude trên điện thoại, sau đó quay lại xem kết quả sau. Cách làm việc "đa luồng" này có logic cốt lõi là: Claude Code giỏi trong việc tự thực hiện, nhiều nhiệm vụ không cần bạn theo dõi. Bạn khởi động nhiệm vụ, đưa ra một hướng đi, để nó tự chạy, trong khi bạn bận rộn với việc khác. Khi nó cần bạn xác nhận, bạn quay lại. Điều này hoàn toàn khác với nhịp độ truyền thống "người gõ một dòng mã, AI bổ sung vài dòng". Nhưng điều này cũng đòi hỏi người sử dụng có yêu cầu cao hơn, bạn cần giỏi trong việc phân bổ nhiệm vụ cho Agent và có thể chuyển đổi giữa nhiều nhiệm vụ bất cứ lúc nào. Đối với những người đã quen với việc phát triển một cách truyền thống, chỉ có một nhiệm vụ diễn ra, đây là một thách thức lớn. Thật xấu hổ, mặc dù tôi cũng thường xuyên sử dụng Coding Agent, nhưng vẫn chưa quen với việc chạy nhiều nhiệm vụ cùng lúc, năm nay tôi sẽ tăng cường luyện tập trong lĩnh vực này. 【3】Lựa chọn mô hình: Tại sao sử dụng Opus thay vì Sonnet nhanh hơn Boris nói rằng tất cả nhiệm vụ của anh ấy đều sử dụng Opus 4.5 kết hợp với chế độ thinking. Đây là mô hình lập trình tốt nhất mà anh ấy đã sử dụng. Có người sẽ hỏi: Opus không phải lớn hơn và chậm hơn Sonnet sao? Câu trả lời của Boris là: mặc dù phản hồi một lần chậm hơn một chút, nhưng bạn cần sửa chữa nó ít hơn nhiều, việc gọi công cụ cũng chính xác hơn, cuối cùng tính ra lại nhanh hơn. Điều này thực sự tôi luôn đồng ý, viết mã không thể chỉ cầu nhanh, mà phải đảm bảo chất lượng cao, nếu một mô hình nhanh cần bạn sửa đi sửa lại ba lần, thì thà dùng một mô hình chậm mà hoàn thành một lần. Thời gian không chỉ là thời gian phản hồi của mô hình, mà còn là chi phí chú ý và năng lượng của bạn. Vấn đề duy nhất là Opus có chi phí cao hơn. 【4】 là một tệp cấu hình đặc biệt của Claude Code, nằm trong thư mục gốc của dự án. Mỗi lần khởi động Claude Code, nó sẽ tự động đọc tệp này và coi nội dung bên trong như "kiến thức nền tảng". Bạn có thể hiểu rằng: đây là tài liệu mô tả dự án mà bạn viết cho AI, cho nó biết cấu trúc, quy chuẩn và lưu ý của dự án này. Cách làm của đội ngũ Boris là: toàn bộ kho Claude Code chia sẻ một Git, tất cả mọi người cùng duy trì. Mỗi tuần đều có người thêm vào. Quy tắc rất đơn giản: mỗi lần thấy Claude làm sai điều gì, thì viết vào "đừng làm như vậy", lần sau nó sẽ biết. Thú vị hơn là, họ cũng sử dụng cơ chế này trong việc xem xét mã. Boris sẽ @.claude trong PR của đồng nghiệp, để Claude thêm một quy tắc mới vào . Điều này được thực hiện thông qua hành động GitHub của Claude Code. Dan Shipper gọi cách làm này là "kỹ thuật lãi suất kép": mỗi lần sửa lỗi đều trở thành tài sản của đội ngũ, giúp AI ngày càng hiểu dự án của bạn. Nếu bạn chưa sử dụng lệnh , Claude sẽ tự động phân tích cấu trúc dự án và tạo ra một phiên bản ban đầu. Sau đó bạn có thể sử dụng và bổ sung, thấy chỗ nào không đúng thì thêm vào. 【5】Chế độ Plan: Nghĩ rõ ràng trước khi bắt tay vào làm Boris nói rằng hầu hết các cuộc hội thoại của anh ấy bắt đầu từ chế độ Plan. Trong Claude Code, chỉ cần nhấn hai lần Shift+Tab là có thể chuyển đổi. Trong chế độ Plan, Claude sẽ không trực tiếp sửa mã, mà sẽ đưa cho bạn một kế hoạch thực hiện trước. Bạn có thể thảo luận, sửa đổi kế hoạch cho đến khi hài lòng. Sau đó chuyển sang chế độ tự động chấp nhận, Claude thường có thể hoàn thành một lần. "Kế hoạch tốt thực sự rất quan trọng", thói quen này thực ra là chuyển giao trí tuệ cổ điển của phát triển phần mềm vào hợp tác AI: thiết kế trước rồi mới mã hóa. Nhiều người gặp vấn đề khi sử dụng AI để viết mã là bắt đầu ngay lập tức, kết quả là sai hướng, chi phí làm lại rất cao. Dành vài phút để đồng bộ kế hoạch có thể tiết kiệm vài giờ làm lại. 【6】Tự động hóa công việc lặp lại: lệnh gạch chéo và Agent con Boris có một vài thao tác mà anh ấy phải sử dụng hàng chục lần mỗi ngày, anh ấy đã biến chúng thành lệnh gạch chéo. Ví dụ như "/commit-push-pr", hoàn thành việc gửi, đẩy, tạo PR chỉ bằng một nút bấm. Lệnh gạch chéo về cơ bản là tệp Markdown, nằm trong thư mục .claude/commands/. Bạn có thể viết lệnh bằng ngôn ngữ tự nhiên, và còn có thể nhúng các tập lệnh bash để lấy một số thông tin trước, giảm số lần gọi mô hình. Những lệnh này có thể được gửi lên Git, toàn bộ đội ngũ cùng chia sẻ. Ngoài lệnh gạch chéo, anh ấy còn sử dụng Agent con (Agent là các phiên bản Claude độc lập, chuyên làm một loại công việc nào đó. Ví dụ, anh ấy có một Agent con code-simplifier, tự động đơn giản hóa mã sau khi Claude hoàn thành công việc; còn có một Agent con verify-app, chuyên trách kiểm tra end-to-end). Điểm chung của hai chức năng này là: biến những việc bạn làm lặp đi lặp lại thành cố định, để Claude tự gọi. Bạn không cần phải giải thích lại mỗi lần, cũng không cần nhớ các chi tiết lệnh khác nhau. Sử dụng PostToolUse Hook để định dạng mã do Claude tạo ra. Claude thường có thể tự động tạo ra mã có định dạng tốt, và Hook này sẽ xử lý 10% mã cuối cùng, để tránh lỗi định dạng trong quá trình tích hợp liên tục (CI). 【7】An toàn và tích hợp: cấu hình quyền và công cụ bên ngoài Boris không sử dụng tùy chọn "nguy hiểm" --dangerously-skip-permissions. Ngược lại, anh ấy sử dụng lệnh /permissions để phê duyệt trước một số lệnh an toàn thường dùng, tránh việc mỗi lần đều hiện hộp xác nhận. Những cấu hình này được lưu trong .claude/settings.json, chia sẻ trong đội ngũ. Mạnh mẽ hơn là tích hợp máy chủ MCP. MCP là viết tắt của Model Context Protocol, là giao thức tiêu chuẩn do Anthropic phát triển để kết nối AI với các công cụ bên ngoài. Thông qua MCP, Claude Code có thể trực tiếp: - Tìm kiếm và gửi tin nhắn Slack - Chạy truy vấn BigQuery để trả lời các câu hỏi dữ liệu - Kéo nhật ký lỗi từ Sentry Đội ngũ Boris cũng đã gửi cấu hình MCP của Slack vào kho, tất cả mọi người đều có thể sử dụng ngay. Điều này có nghĩa là Claude Code không chỉ là một công cụ lập trình, mà còn là "trợ lý toàn năng" có thể gọi toàn bộ chuỗi công cụ của bạn. 【8】Xử lý nhiệm vụ dài: để Claude tự xác minh Đối với những nhiệm vụ chạy lâu, Boris có một vài chiến lược: Một là để Claude hoàn thành và tự động xác minh kết quả bằng Agent nền. Bạn có thể yêu cầu trong lời nhắc, hoặc sử dụng Stop Hook để kích hoạt một cách chắc chắn hơn. > Chú thích: Hooks là cơ chế "móc" của Claude Code, cho phép bạn chèn logic tùy chỉnh vào những thời điểm cụ thể khi Claude thực hiện thao tác. Bạn có thể hiểu nó như là "triggers": khi một sự kiện xảy ra, tự động thực hiện lệnh hoặc tập lệnh mà bạn đã thiết lập trước. > Stop Hook là khi Claude hoàn thành phản hồi và chuẩn bị trả lại quyền kiểm soát. > Tài liệu liên quan: Hai là sử dụng plugin ralph-wiggum, về cơ bản là một vòng lặp Bash: tưởng tượng một vòng lặp đơn giản (while true), nó liên tục cung cấp cùng một tài liệu nhiệm vụ (tệp nhắc) cho AI, để nó cải tiến công việc một lần nữa cho đến khi hoàn thành hoàn toàn. Ba là trong môi trường sandbox sử dụng --permission-mode=dontAsk hoặc --dangerously-skip-permissions, để Claude không bị gián đoạn bởi xác nhận quyền, tự chạy đến cùng. Logic cốt lõi là: nếu đã là nhiệm vụ dài, thì đừng để nó chờ bạn. Đưa cho nó đủ quyền tự chủ và khả năng tự sửa lỗi. 【9】Điều quan trọng nhất: cho Claude khả năng xác minh Boris đặt điều này ở cuối, nói rằng đây có thể là yếu tố quan trọng nhất để có được kết quả tốt. Nếu Claude có thể xác minh công việc của mình, chất lượng sản phẩm cuối cùng có thể tăng lên 2 đến 3 lần. Anh ấy đưa ra một ví dụ: mỗi thay đổi mà họ gửi đến đều được Claude tự kiểm tra bằng tiện ích mở rộng Chrome: mở trình duyệt, kiểm tra UI, phát hiện vấn đề thì lặp lại, cho đến khi chức năng hoạt động bình thường và trải nghiệm hợp lý. Cách xác minh tùy thuộc vào bối cảnh. Có thể là chạy một lệnh bash, có thể là chạy bộ kiểm tra, có thể là kiểm tra ứng dụng trong trình duyệt hoặc mô phỏng trên điện thoại. Hình thức không quan trọng, điều quan trọng là: để AI có phản hồi. Điều này thực sự rất đơn giản. Kỹ sư con người cũng dựa vào vòng lặp "viết mã - kiểm tra - xem kết quả - sửa đổi" để đảm bảo chất lượng. AI cũng vậy. Nếu nó chỉ có thể viết mà không thể kiểm tra, thì giống như làm việc với đôi mắt nhắm lại, chất lượng hoàn toàn phụ thuộc vào may mắn. Lời khuyên của Boris là: đầu tư công sức để xây dựng cơ chế xác minh vững chắc. Đây là khoản đầu tư có tỷ suất lợi nhuận cao nhất. 【10】Cao thủ dùng kiếm không có chiêu thức thắng có chiêu thức Trong tiểu thuyết võ hiệp, cao thủ dùng kiếm không có nhiều chiêu thức hoa mỹ, không có chiêu thức thắng có chiêu thức. Boris không khoe khoang cấu hình phức tạp, không có mẹo bí mật nào, chỉ sử dụng các chức năng chính thức. Sự khác biệt là: anh ấy thực sự hiểu logic đằng sau những chức năng này, sau đó kết hợp chúng thành quy trình làm việc hiệu quả. Làm việc song song là vì Claude có thể tự thực hiện; sử dụng Opus là vì hiệu suất tổng hợp cao hơn; là biến việc sửa lỗi thành tài sản; chế độ Plan là nghĩ rõ ràng trước khi bắt tay vào làm; lệnh gạch chéo và Agent con là tự động hóa công việc lặp lại; cơ chế xác minh là để AI có phản hồi. Nếu bạn mới bắt đầu sử dụng Claude Code, không cần phải vội vàng nghiên cứu các cấu hình cao cấp. Hãy bắt đầu với những điều cơ bản: học cách làm việc song song, học cách lập kế hoạch, học cách tích lũy các phương pháp xác minh AI. Khi bạn thực sự gặp phải bế tắc, thì hãy đi tìm những điều phức tạp sau.

Boris có một điều chưa đề cập đến là quy trình CI/kiểm tra mã cơ bản, những điều này có thể là bình thường đối với họ, những người đã quen với các công ty lớn, và nên được mặc định có. Chẳng hạn, khi anh ấy hoàn thành một nhiệm vụ bằng Claude Code, anh ấy sẽ không trực tiếp hợp nhất vào nhánh chính mà sẽ gửi một PR. Sau khi gửi PR, tất cả các lint và kiểm tra tự động sẽ tự động chạy trên máy chủ CI, nếu kiểm tra thất bại thì PR sẽ không thể được hợp nhất. Một PR đã vượt qua tất cả các kiểm tra tự động, vẫn cần có người thực hiện kiểm tra mã (tất nhiên có thể hỗ trợ bởi AI, nhưng vẫn cần có người xác nhận), nếu kiểm tra mã phát hiện vấn đề, cần phải tiếp tục sửa đổi. Đối với nhiều nhà phát triển cá nhân, họ không có thói quen thiết lập một quy trình CI/kiểm tra mã, thậm chí còn không thực hiện quản lý mã Git, nếu có vấn đề thì không thể quay lại.

【10】 Những điều bạn không thấy Boris có một điều chưa đề cập đó là quản lý mã nguồn cơ bản / CI (tích hợp liên tục) / quy trình xem xét mã, những điều này có thể là bình thường đối với họ, những người đã quen với các công ty lớn, và được coi là điều hiển nhiên. Chẳng hạn, khi anh ấy hoàn thành một nhiệm vụ bằng Claude Code, anh ấy sẽ không trực tiếp hợp nhất vào nhánh chính mà sẽ gửi một PR. Sau khi gửi PR, trên máy chủ CI sẽ tự động chạy tất cả các lint và kiểm tra tự động, nếu kiểm tra thất bại thì PR không thể được hợp nhất. Một PR đã vượt qua tất cả các kiểm tra tự động vẫn cần có người thực hiện việc xem xét mã (tất nhiên có thể có sự hỗ trợ của AI, nhưng vẫn cần có người xác nhận), nếu việc xem xét mã phát hiện ra vấn đề, cần phải tiếp tục sửa đổi. Đây cũng là nền tảng cho việc họ có thể thực hiện nhiều nhiệm vụ song song, nếu không thực hiện tốt những quy trình cơ bản này, sẽ không thể thực hiện nhiều nhiệm vụ song song. Đối với nhiều nhà phát triển cá nhân, họ không có thói quen thiết lập một quy trình CI/xem xét mã, thậm chí còn không thực hiện quản lý mã Git, nếu có vấn đề cũng không thể quay lại.