Cách tôi sử dụng Claude Code

Nghe bài viết:

Tôi đã sử dụng Claude Code làm công cụ phát triển chính trong khoảng 9 tháng, và quy trình làm việc mà tôi xây dựng khác biệt hoàn toàn so với cách phần lớn mọi người sử dụng các công cụ AI hỗ trợ lập trình.

Phần lớn lập trình viên chỉ nhập một prompt, đôi khi dùng plan mode, sửa lỗi rồi lặp lại. Những người “terminally online” hơn thì ghép nối đủ thứ vòng lặp và công cụ tự động hóa phức tạp. Kết quả trong cả hai trường hợp thường là một mớ hỗn độn, và sẽ sụp đổ ngay khi xử lý bất kỳ vấn đề nào không tầm thường.

Quy trình tôi sắp mô tả có một nguyên tắc cốt lõi: không bao giờ để Claude viết code cho đến khi bạn đã xem xét và phê duyệt một bản kế hoạch bằng văn bản. Sự tách biệt giữa lập kế hoạch và thực thi là điều quan trọng nhất trong toàn bộ quy trình của tôi. Nó giúp tránh lãng phí công sức, giữ tôi kiểm soát các quyết định kiến trúc, và tạo ra kết quả tốt hơn đáng kể với mức tiêu thụ token thấp hơn nhiều so với việc nhảy thẳng vào code.

screenshot 2026-02-28 at 21.05.21-260228210733

Giai đoạn 1: Nghiên cứu

Tôi đã sử dụng Claude Code làm công cụ phát triển chính trong khoảng 9 tháng. Quy trình tôi xây dựng khác hoàn toàn so với cách phần lớn lập trình viên dùng AI hỗ trợ lập trình.

Nhiều người nhập một prompt, dùng plan mode, sửa lỗi rồi lặp lại. Một số người khác tạo các vòng lặp phức tạp với nhiều công cụ tích hợp. Kết quả thường là hệ thống rối rắm và dễ sụp đổ khi gặp vấn đề phức tạp.

Quy trình của tôi dựa trên một nguyên tắc cốt lõi: không bao giờ để Claude viết code cho đến khi tôi đã xem xét và phê duyệt một bản kế hoạch bằng văn bản.

Tách biệt giữa suy nghĩ (planning) và thực thi (implementation) là yếu tố quan trọng nhất. Điều này giúp tránh sai lầm kiến trúc, giảm lãng phí token và nâng cao chất lượng code.

Mọi nhiệm vụ quan trọng đều bắt đầu bằng việc đọc sâu hệ thống.

Hãy đọc thư mục này thật kỹ, hiểu cách nó hoạt động, chức năng của nó và toàn bộ các chi tiết liên quan. Sau đó viết một tài liệu research.md mô tả đầy đủ những gì bạn đã học được.

Nghiên cứu chi tiết hệ thống thông báo, hiểu các cơ chế nội bộ và viết một tài liệu research.md giải thích toàn bộ cách hoạt động.

Phân tích luồng lập lịch tác vụ, tìm tất cả lỗi tiềm ẩn. Tiếp tục nghiên cứu cho đến khi tìm ra toàn bộ lỗi, sau đó ghi lại chi tiết trong research.md.

Các từ như “thật kỹ”, “chi tiết”, “mọi khía cạnh” rất quan trọng. Nếu không, Claude sẽ đọc lướt.

Tài liệu research.md là điểm kiểm soát chất lượng đầu tiên. Tôi đọc lại, xác minh hiểu biết trước khi chuyển sang lập kế hoạch.

Giai đoạn 2: Lập kế hoạch

Sau khi nghiên cứu xong, tôi yêu cầu viết một tài liệu plan.md chi tiết.

Tôi muốn xây dựng tính năng <mô tả> để đạt được <kết quả kinh doanh>. Hãy viết một tài liệu plan.md chi tiết, bao gồm các đoạn mã minh họa.

Endpoint danh sách cần chuyển sang cursor-based pagination thay vì offset. Hãy đọc code hiện tại và viết kế hoạch chi tiết dựa trên hệ thống thực tế.

Kế hoạch phải bao gồm:

  • Mô tả cách tiếp cận
  • Đường dẫn file cần sửa
  • Snippet minh họa
  • Phân tích trade-off

Tôi luôn dùng file markdown riêng thay vì plan mode mặc định để có thể chỉnh sửa trực tiếp.

Chu trình ghi chú (Annotation Cycle)

Sau khi có plan, tôi chỉnh sửa trực tiếp trong tài liệu:

  • Sử dụng công cụ migration chuẩn thay vì SQL thô
  • Không dùng PUT, hãy dùng PATCH
  • Xóa phần caching không cần thiết
  • Logic retry đã có sẵn

Tôi đã thêm ghi chú vào tài liệu. Hãy cập nhật kế hoạch dựa trên tất cả ghi chú. Chưa triển khai code.

Chu trình này có thể lặp lại 1–6 lần.

Cụm “chưa triển khai” cực kỳ quan trọng. Nếu không, Claude sẽ bắt đầu viết code ngay.

screenshot 2026-02-28 at 20.56.43-260228210843

Vì sao cách này hiệu quả?

File markdown đóng vai trò là trạng thái chia sẻ giữa tôi và Claude. Tôi chỉnh sửa trực tiếp vào nơi có vấn đề thay vì giải thích dài dòng trong chat.

Claude không có judgement sản phẩm. Annotation giúp tôi đưa quyết định chiến lược vào kế hoạch.

Danh sách công việc (Todo)

Hãy thêm danh sách công việc chi tiết theo từng giai đoạn vào kế hoạch. Chưa triển khai code.

Checklist này giúp theo dõi tiến độ và đảm bảo không bỏ sót bước nào.

Giai đoạn 3: Triển khai

Triển khai toàn bộ kế hoạch. Khi hoàn thành từng mục, đánh dấu vào tài liệu. Không dừng giữa chừng. Không thêm comment dư thừa. Luôn chạy typecheck.

Ở bước này, mọi quyết định đã được xác nhận. Việc triển khai trở nên cơ học, không còn sáng tạo.

  • Triển khai đầy đủ
  • Tuân thủ kế hoạch
  • Không dừng giữa chừng
  • Type an toàn
  • Kiểm tra lỗi liên tục

Phản hồi trong quá trình triển khai

Tôi chuyển sang vai trò giám sát:

  • Bạn chưa triển khai hàm X
  • Di chuyển logic sang module admin

Với frontend, phản hồi thường rất ngắn:

  • Rộng hơn
  • Vẫn bị cắt
  • Còn lệch 2px

Nếu đi sai hướng, tôi revert và thu hẹp phạm vi thay vì vá lỗi dần dần.

screenshot 2026-02-28 at 20.57.16-260228210954

Luôn giữ quyền kiểm soát

Tôi không bao giờ trao toàn quyền cho Claude.

  • Tôi chọn giải pháp
  • Tôi quyết định trade-off
  • Tôi bảo vệ kiến trúc hệ thống

Claude xử lý phần cơ học. Tôi chịu trách nhiệm về judgement.

screenshot 2026-02-28 at 20.57.31-260228211122

Phiên làm việc dài duy nhất

Tôi thực hiện nghiên cứu, lập kế hoạch và triển khai trong một phiên làm việc dài duy nhất, thay vì chia chúng thành nhiều session riêng biệt. Một session có thể bắt đầu bằng việc đọc sâu một thư mục, sau đó trải qua ba vòng chỉnh sửa kế hoạch, rồi triển khai toàn bộ tính năng — tất cả trong một cuộc hội thoại liên tục.

Tôi không gặp tình trạng suy giảm hiệu năng mà nhiều người nói đến khi vượt quá 50% context window. Trên thực tế, đến thời điểm tôi nói “triển khai toàn bộ”, Claude đã dành cả session để xây dựng sự hiểu biết: đọc file trong giai đoạn nghiên cứu, tinh chỉnh mô hình tư duy của nó qua các vòng annotation, và hấp thụ các điều chỉnh kiến thức domain từ tôi.

Khi context window đầy, cơ chế tự nén (auto-compaction) của Claude vẫn giữ lại đủ ngữ cảnh để tiếp tục làm việc. Và tài liệu kế hoạch — artifact bền vững của tôi — vẫn được giữ nguyên vẹn sau khi nén. Tôi có thể yêu cầu Claude tham chiếu lại tài liệu đó bất cứ lúc nào.


Quy trình trong một câu

Đọc sâu, viết kế hoạch, chỉnh sửa kế hoạch cho đến khi đúng, rồi để Claude triển khai toàn bộ mà không gián đoạn, đồng thời kiểm tra type trong suốt quá trình.

Chỉ vậy thôi. Không có prompt thần kỳ, không có system instruction phức tạp, không có mẹo vặt cao siêu. Chỉ là một pipeline kỷ luật tách biệt giữa suy nghĩ và thao tác gõ code.

Giai đoạn nghiên cứu ngăn Claude thực hiện những thay đổi thiếu hiểu biết.
Bản kế hoạch ngăn nó thực hiện những thay đổi sai lầm.
Chu trình annotation đưa judgement của tôi vào hệ thống.
Và lệnh triển khai cho phép nó chạy liên tục khi mọi quyết định đã được đưa ra.

Hãy thử quy trình này. Bạn sẽ tự hỏi làm sao trước đây mình có thể phát hành sản phẩm với coding agents mà không có một tài liệu kế hoạch được annotate kỹ lưỡng nằm giữa bạn và code.