Đạt kết quả tốt với Claude Code

• Sau khi thử nghiệm nhiều tác nhân lập trình LLM khác nhau trong vài tháng gần đây, Claude Code là công cụ mang lại sự hài lòng nhất
• Nhờ Claude Code, tác giả đã viết khoảng 12 chương trình và dự án trong thời gian ngắn, kể cả những việc bình thường sẽ không bắt đầu vì thiếu thời gian
• Để sử dụng hiệu quả, điều cốt lõi là viết đặc tả rõ ràng, cung cấp tài liệu về cấu trúc dự án, cách chạy build và lint, yêu cầu AI tự review code của mình, và vận hành hướng dẫn tác nhân toàn cục được cá nhân hóa
• Vì code do AI viết thường có thể không chính xác hoặc kém hiệu quả, nên cần tự mình xem xét toàn bộ code và test case, đồng thời trực tiếp bổ sung test còn thiếu hoặc yêu cầu AI viết rồi kiểm tra lại
• Phần phụ lục công khai hướng dẫn tác nhân toàn cục bao gồm chỉ dẫn phát triển chi tiết như kế hoạch triển khai theo từng bước, phát triển hướng kiểm thử, triết lý ưu tiên tính đơn giản, rõ ràng và thực dụng, tiêu chuẩn chất lượng, cùng quy trình giải quyết vấn đề

---

Trải nghiệm và hiệu quả khi dùng Claude Code

• Trong vài tháng gần đây, tác giả đã thử nghiệm nhiều tác nhân lập trình LLM, và trải nghiệm với Claude Code là tốt nhất
• Dù không phải hoàn toàn không có vấn đề, tác giả vẫn có thể hoàn thành hơn 12 chương trình và dự án trong thời gian ngắn
• Nếu không có Claude Code, gần như không thể hoàn thành toàn bộ số công việc này trong cùng khoảng thời gian
• Nhiều việc trong số đó là những dự án mà tác giả thậm chí đã không thử làm vì tốn quá nhiều thời gian

Chiến lược sử dụng Claude Code

• Viết đặc tả rõ ràng
  • Trước khi bắt đầu dự án, tài liệu hóa rõ ràng yêu cầu và ngữ cảnh rồi cung cấp cho tác nhân
  • Qua đó làm rõ hướng viết code và phạm vi công việc
• Tài liệu hóa cấu trúc dự án
  • Chuẩn bị tài liệu bao gồm cách chạy build, lint và test
  • Giúp tác nhân khám phá codebase và làm việc hiệu quả hơn
• Yêu cầu tác nhân review code
  • Để Claude Code tự review code mà nó tạo ra nhằm phát hiện các điểm cần cải thiện hoặc lỗi ngoài dự kiến
• Sử dụng hướng dẫn toàn cục cá nhân
  • Duy trì quy trình phát triển nhất quán thông qua ~/.claude/CLAUDE.md, nơi chứa các quy tắc cá nhân như cách tiếp cận giải quyết vấn đề, áp dụng TDD, giữ tính đơn giản và rõ ràng, cũng như giới hạn số lần thử là 3

Kiểm chứng code do LLM viết

• Code do AI tạo ra thường có các vấn đề như lỗi logic, suy giảm hiệu năng, kiểm thử chưa đầy đủ
• Tác giả review thủ công toàn bộ code và xác nhận cách nó hoạt động
  • Tự bổ sung các test case bị thiếu
  • Hoặc yêu cầu AI viết rồi review lại code và test
• Tác giả nhấn mạnh rằng trong môi trường chuyên nghiệp, khi PR mang tên mình thì trách nhiệm cuối cùng về chất lượng vẫn thuộc về bản thân

Nội dung chính trong hướng dẫn tác nhân “toàn cục” cá nhân

Hướng dẫn này được quản lý trong file ~/.claude/CLAUDE.md

• Triết lý và nguyên tắc cốt lõi

  • Tiến từng bước: thay đổi theo đơn vị nhỏ, luôn đảm bảo biên dịch và test đều qua
  • Học từ code hiện có: phân tích pattern trong code và lập kế hoạch trước khi triển khai
  • Ưu tiên tính thực dụng: tiếp cận linh hoạt phù hợp với tình huống của dự án
  • Ưu tiên sự rõ ràng: code dễ đọc, ý đồ rõ ràng, tránh các mẹo không cần thiết

• Định nghĩa về tính đơn giản

  • Hàm và lớp chỉ có một trách nhiệm
  • Tránh trừu tượng hóa quá sớm
  • Giảm độ phức tạp và hướng tới code không cần giải thích thêm

• Quy trình làm việc

  • 1. Lập kế hoạch và chia giai đoạn:
    • Với công việc phức tạp, chia thành 3~5 giai đoạn và ghi vào IMPLEMENTATION_PLAN.md
    • Nêu rõ mục tiêu, tiêu chí thành công, test case và trạng thái tiến độ của từng giai đoạn
  • 2. Luồng triển khai:
    • Hiểu vấn đề → viết test (đỏ) → triển khai tối thiểu (xanh) → refactor → commit
  • 3. Đánh giá lại sau giới hạn 3 lần thử:
    • Khi thất bại, ghi lại nội dung thử nghiệm, lỗi và nguyên nhân
    • Tìm kiếm phương án thay thế (2~3 cách tiếp cận)
    • Xem xét lại việc phân rã bài toán hoặc thiết kế ở mức gốc rễ
    • Thử pattern hoặc tính năng khác

• Tiêu chuẩn kỹ thuật

  • Ưu tiên composition, tận dụng dependency injection
  • Sử dụng interface để đảm bảo dễ kiểm thử
  • Luồng dữ liệu tường minh
  • Khuyến nghị TDD, không được vô hiệu hóa test

• Quy tắc chất lượng code

  • Mọi commit phải biên dịch thành công, test vượt qua, có test cho tính năng mới và tuân thủ style code
  • Trước khi commit cần chạy formatter và linter, tự review thay đổi, và viết commit message giải thích “vì sao”

• Xử lý lỗi

  • Fail fast và thông điệp cụ thể
  • Cung cấp ngữ cảnh cần thiết cho việc debug
  • Xử lý ngoại lệ ở mức phù hợp, không che giấu ngoại lệ

• Tiêu chí ra quyết định

  • 1. Dễ kiểm thử
  • 2. Tính dễ đọc, dễ hiểu ngay cả sau 6 tháng
  • 3. Tính nhất quán với pattern của dự án
  • 4. Sự đơn giản
  • 5. Khả năng thay đổi dễ dàng

• Tích hợp vào dự án

  • Phân tích ít nhất 3 chức năng tương tự
  • Tái sử dụng pattern và thư viện hiện có
  • Dùng cùng utility test hiện có
  • Cần có lý do thật thuyết phục khi đưa vào công cụ mới

• Cổng chất lượng

  • Tất cả test đều phải qua
  • Tuân thủ quy tắc của dự án
  • Không có cảnh báo từ linter
  • Commit message rõ ràng
  • Phần triển khai khớp với kế hoạch
  • TODO phải kèm số issue

• Hướng dẫn kiểm thử

  • Test tập trung vào hành vi thay vì cách triển khai
  • Nếu có thể, mỗi test chỉ nên có một assertion
  • Tên rõ ràng mô tả kịch bản
  • Tái sử dụng utility test hiện có
  • Test phải có tính quyết định

• Tuyệt đối không làm

  • Bỏ qua hook bằng --no-verify
  • Vô hiệu hóa test
  • Commit code không biên dịch được
  • Đoán mò mà không kiểm chứng

• Bắt buộc phải làm

  • Commit theo từng bước nhỏ
  • Cập nhật tài liệu liên tục
  • Học từ phần triển khai hiện có
  • Đánh giá lại cách tiếp cận sau 3 lần thất bại

Các dự án mã nguồn mở được tạo bằng Claude Code

• Reverse proxy nhận biết HTML/XML (cdzombak/xrp)
• Giao diện Solarized cho VS Code (sáng/tối) (cdzombak/dzsolarized-vscode)
• Trình tạo RSS cho photostream Flickr (cdzombak/flickr-rss)
• Công cụ metadata cho thư viện ảnh Lychee (cdzombak/lychee-meta-tool)
• Báo cáo trạng thái khóa màn hình macOS qua MQTT (cdzombak/macos-screenlock-mqtt)
• Tự động đặt tiêu đề ảnh Bird Buddy trong Lychee (cdzombak/lychee-birb-title)
• Tự động phân loại ảnh dựa trên LLM cục bộ (cdzombak/lychee-ai-organizer)
• Tự động hóa cài đặt hàng loạt phần mềm cho macOS (cdzombak/mac-install)
• Dự án dịch vụ RSS (cdzombak/rss.church)
• Xuất toàn bộ/chọn lọc ảnh Flickr và bảo toàn metadata (cdzombak/flickr-exporter)
• Trình tạo gallery HTML tĩnh (cdzombak/gallerygen)

[wedding]

Việc cho ra kết quả tốt có nghĩa là đã tham chiếu tốt đoạn mã mà ai đó đã tạo sẵn rồi phải không.

[aeolian21]

Những gì tác giả làm thì mọi người đều đã làm từ lâu rồi, nên đừng khoe mấy thứ vô bổ như vậy.
Khi so sánh giữa các LLM, sẽ ý nghĩa hơn nhiều nếu viết rõ căn cứ vì sao bạn cho rằng Claude là tốt nhất.
Ví dụ như so sánh mã được tạo ra thực tế, tần suất lỗi biên dịch, độ ổn định trong việc nắm bắt ngữ cảnh, v.v.
Thực tế, khả năng nắm bắt ngữ cảnh tốt nhất là Gemini (1 triệu token).

[zxcv123]

Toàn làm ra những thứ vô dụng rồi chỉ viết dài dòng lê thê.

[knunu]

Có thể sẽ hữu ích với ai đó đấy haha

[GN⁺]

Ý kiến trên Hacker News

• Hôm nay lần đầu tiên tôi thật sự có được một trải nghiệm thành công đúng nghĩa với Claude và coding agent. Trước đây tôi đã thử Cursor, nhưng giờ đang dùng Claude và thử thêm vài thứ khác. Đúng như bài viết nói, điểm mấu chốt là phải viết đặc tả rõ ràng. Tôi đã tự viết một tài liệu 12 bước trong 2 tiếng để sắp xếp cách triển khai và đưa cả thông tin nền vào đó. Claude chỉ việc làm theo quy trình đó và tạo mã theo từng bước. Theo tôi, như vậy chắc đã tiết kiệm được khoảng 6–10 tiếng. Giờ tôi sẽ rà soát, kiểm thử, điều chỉnh dần và thêm tính năng. Nền tảng của thành công này là vì chính tôi đã viết rõ tất cả các bước Claude cần làm; tức là tôi thiết kế toàn bộ luồng, còn Claude chỉ làm theo chỉ dẫn. Qua quá trình này, tôi càng tin rằng các lập trình viên từ mức trung cấp trở lên sẽ chưa bị AI thay thế trong tương lai gần. Nhưng nhìn cảnh Claude đọc đặc tả từ đầu đến cuối rồi xuất ra mã được tổ chức và tài liệu hóa tốt thực sự là một trải nghiệm rất kỳ lạ. Việc tôi không cần tự tay code vẫn thật ấn tượng.

  • Tôi vẫn có kết quả tốt với Claude mà không cần chuẩn bị kỹ đến vậy. Tôi gần như yêu cầu Claude từng bước một, giống hệt cách tôi sẽ tự viết code. Mỗi lần như vậy tôi áp dụng ngay phần thay đổi, commit rồi xem lại diff. Nếu Claude tạo ra thứ gì kỳ quặc thì tôi yêu cầu sửa ngay. Ngoài ra tôi cũng chỉ rõ các đoạn code hoặc hàm có sẵn mà tôi muốn nó tham chiếu. Với cách này, tôi có thể đạt kết quả rất tốt với ít thao tác gõ và ít thời gian hơn nhiều.

  • Tôi khuyên nên đọc “Programming as Theory Building” của Naur. Từ đó tôi học được cách phải tự mình hiểu vấn đề về mặt lý thuyết và tự mô hình hóa nó. Nếu không, LLM có thể tự dựng nên một lý thuyết riêng của nó — và có thể là sai.
    Đọc “Programming as Theory Building” - Naur

  • Đúng như trong bài, đặc tả rõ ràng thực sự rất quan trọng. Tôi đang dùng Claude để tạo một ngôn ngữ lập trình và cảm nhận điều này rất rõ. Lập trình là cả một chuỗi dài những lựa chọn nhỏ nhặt. Nếu không hướng dẫn rõ ràng, LLM sẽ xử lý phần lớn bằng cách đoán, mà nhiều khi lại đoán sai. Những sai sót nhỏ này có thể cộng dồn và dẫn đến kết quả sai lệch.

  • Nếu có thể chia sẻ trực tiếp một ví dụ về loại tài liệu đặc tả này thì sẽ thật tuyệt. Với người đang tự học phát triển phần mềm và thử nghiệm Claude Code như tôi, điều đó sẽ giúp ích rất nhiều để hiểu loại thông tin nào và mức độ chi tiết nào là hữu ích trong thực tế.

  • Thực ra cũng có khá nhiều lập trình viên trung cấp và senior không viết được tài liệu đặc tả cho ra hồn. Nhưng tôi hiểu ý bạn muốn nói.

• Tạo ~/.claude/CLAUDE.md rồi nhét quy tắc vào đó có lẽ thực tế không hiệu quả đến vậy. Claude không phải con người và cũng không suy luận cẩn thận trên từng dòng code. Những chỉ dẫn mang tính chủ quan và mơ hồ sẽ không thực sự khiến nó thay đổi code. Còn có cả vấn đề gọi là 'context rot' nữa.
  (Giải thích về context rot: hiện tượng LLM bị mất hoặc bóp méo ngữ cảnh trong các cuộc hội thoại hay công việc dài; link tham khảo: https://news.ycombinator.com/item?id=44564248)
  Trên thực tế, việc nhét đủ thứ quy tắc vào một file duy nhất rồi mong AI tự tuân thủ là bất khả thi. Muốn làm thế thì phải tạo sub-agent cho từng quy tắc và tách chúng thành pipeline thông thường thay vì giao cho AI. Nhưng làm vậy thì chi phí sẽ tăng theo cấp số nhân.

  • Nếu là vấn đề chi phí thì sau khi workflow ổn định, bạn có thể dùng các LLM rẻ hơn (dù chi phí vận hành vẫn cao). Fine-tuning, tối ưu prompt, các kỹ thuật distillation chuyên biệt... đều có thể giúp giảm chi phí. Lĩnh vực này đã có rất nhiều nghiên cứu.

  • Tôi tò mò không biết nên đưa những gì vào CLAUDE.md.

• Nhìn các dự án mẫu ở cuối trang thì phần lớn đều là phần mềm được tối ưu cho một mục đích rất cụ thể. Sau này có lẽ các dự án mã nguồn mở cũng sẽ tiến hóa theo hướng rất chuyên biệt để phục vụ nhu cầu của một người theo kiểu như vậy. Tôi nghĩ loại phần mềm này (utility) sẽ dần trở thành thứ mã dùng một lần do LLM sinh ra trong một lượt.

• Cách tiếp cận của tôi với Claude Code vẫn đang thay đổi liên tục. Tôi vẫn chưa thành công trong việc dùng Claude Code để đóng góp ngay các tính năng thật sự có ý nghĩa vào ứng dụng web lớn của công ty. Đặc tả có giúp phần nào, nhưng rốt cuộc nó vẫn hay chệch sang hướng kỳ quặc và rơi vào vòng lặp lặp đi lặp lại những lựa chọn sai. Có thể đó là giới hạn của Claude, hoặc cũng có thể là do tài liệu đặc tả của tôi vẫn chưa đủ chính xác. Tôi đã thử nghiệm rất nhiều, nhưng với những việc “mang tính thử thách hoặc đòi hỏi nhiều kiến thức chuyên môn miền” thì tỷ lệ thất bại cao đến mức tôi không còn cố nữa. Thay vào đó, theo gợi ý của một người bạn, tôi bắt đầu dùng Claude cho các backlog task gần như không gây gánh nặng tinh thần. Ví dụ, tôi giao cho Claude tạo các bài test Playwright trong một workspace mới cho thứ mà tôi không quá gắn bó. Kết quả rất thành công. Tôi mô tả trải nghiệm người dùng cho Claude như thể đang giải thích cho con người, rồi chỉ định đường dẫn dev server. Tôi bảo nó dùng Playwright MCP để tìm ra cần dùng feature nào như thế nào, ghi lại quy trình chạy, viết test và debug lỗi. Tôi cũng cho nó luôn việc lục UI code trong dự án để thêm selector data-testid. Tôi gom toàn bộ quy trình vào một master task.md, và còn yêu cầu nó tạo các file task markdown riêng cho từng feature. Cách này cực kỳ hiệu quả. Tôi còn áp dụng nó cho những feature phức tạp nơi 2 người dùng trên trình duyệt tương tác với nhau theo cách không trực quan; dù không chính xác 100%, càng phức tạp thì chỉ cần chỉnh thêm ngữ cảnh và sửa code đôi chút, nhưng nhìn chung nó giải quyết được ngay những việc phiền phức vốn sẽ mất nhiều ngày.

• Với CLAUDE.md, cách tốt nhất với tôi là giữ nó tối giản, dưới 100 dòng,

  • tóm tắt bản chất và mục tiêu của dự án
  • mô tả tối thiểu về cấu trúc dự án để biết type, interface và helper nằm ở đâu
  • chỉ đưa các lệnh chính để không phải parse package.json lặp đi lặp lại Trong luồng triển khai/kiểm thử, theo kinh nghiệm của tôi Claude hay cố viết trước toàn bộ test trong một lượt hoặc chỉ triển khai toàn bộ khi import thất bại (không đúng kiểu TDD), nên tôi đã tạo một hook tên là TDD-Guard để buộc nó chỉ cho qua từng test một, test phải fail vì đúng lý do, và chỉ viết lượng code tối thiểu để pass test. Chất lượng code thì tôi tự động hóa bằng husky, lint-staged, commitlint... và có kết quả rất tốt. Làm vậy sẽ dành được context cho những thông tin quan trọng hơn. Tôi cũng đồng ý rằng khi Claude Code bị kẹt thì cuối cùng cách tốt nhất vẫn là lập trình viên tự vào can thiệp. Chỉ là nếu dừng ở các hướng dẫn quá chung chung thì hơi đáng tiếc.
  • Nếu bạn quan tâm đến cách tiếp cận tự động hóa:
    • tdd-guard và ví dụ cấu hình
    • husky
    • commitlint
    • lint-staged

• Tôi đã làm việc với Claude Code mỗi ngày hơn một tháng nay. Tôi cũng đã dùng Cursor, Q, v.v. nhưng Claude Code tốt hơn hẳn. Những mẹo trong bài trùng khá nhiều với những gì tôi đã tự rút ra.
  Chia sẻ thêm vài suy nghĩ:

  • Tôi bắt đầu bằng một buổi brainstorm ý tưởng với Claude trên web console. Tôi giải thích mục tiêu của dự án, cùng phác thảo mô hình miền và các mốc lớn. Nếu là dự án nhỏ thì chỉ vài tiếng trao đổi qua lại là xong. Bản đầu tiên của CLAUDE.md cũng ra từ đây.

  • Khi bắt đầu dự án thật, Claude sẽ đọc cả CLAUDE.md toàn cục lẫn CLAUDE.md của dự án rồi mới bắt đầu. Mỗi session đều như vậy.

  • Trong quá trình làm, tôi cũng bảo Claude Code tiếp tục cập nhật CLAUDE.md của dự án: đánh dấu tiến độ theo kế hoạch, rồi đến cuối session thì ghi thêm tóm tắt dự án, cách vận hành, cách điều hướng code, v.v. Nó giống như một dạng trí nhớ dài hạn, và khá hiệu quả.

  • Dù guideline có tốt đến đâu thì Claude vẫn có xu hướng tự vượt lên trước. Vì vậy, với những việc tôi trực tiếp tham gia, tôi luôn buộc nó tập trung theo từng bước nhỏ. Còn với những thứ một lần hoặc nguyên mẫu thì tôi cứ để nó tự triển khai thoải mái.

    • Tôi muốn biết gói đăng ký $20 có đáng tiền hơn Cursor không, và liệu phải dùng hằng ngày thì mới xứng đáng hay không.

• Với CLAUDE.md ở cấp dự án, tốt nhất là giữ ngắn gọn, súc tích, rồi chuyển các nội dung chi tiết hơn xuống các thư mục con. Ở cấp cao nhất, hãy dùng nó như một bản đồ. Mỗi khi lên kế hoạch cho một feature, Claude sẽ tự xem các thư mục phù hợp, tham chiếu ngữ cảnh cần thiết và lập kế hoạch triển khai theo từng bước. Cuối mỗi bước, tôi lại yêu cầu Claude cập nhật kế hoạch triển khai bằng ngữ cảnh mới. Cách này giúp context được chuyển tự nhiên sang bước tiếp theo, đồng thời có thể reset cửa sổ để bước vào giai đoạn sau với trạng thái mới mẻ hơn.

• Tôi đang làm một game ASCII kiểu factorio bằng Claude Code. Ban đầu tôi gần như để nó viết code mà không giám sát mấy, và nó triển khai được hầu hết các tính năng chính (lưu/tải, tùy chọn, debug, tạo bản đồ, xây dựng, băng chuyền, chế tạo, QoL...) chỉ trong một mạch. Nhưng khi bắt đầu sửa chi tiết thì cứ hễ thay đổi di chuyển là băng chuyền lại hỏng, kiểu như thế, tức là cứ sửa cái này thì lại vỡ cái khác. Thế là tôi cho nó thêm tự động hóa Playwright, nhưng chất lượng test kém và đầy các lệnh gọi sleep. Xem kỹ code thì hóa ra cấu trúc lại là frontend React với useEffect, chứ không phải kiến trúc của một game engine đúng nghĩa. Nó cũng không tuân thủ tốt quy tắc hook và hiểu biết về timing còn yếu. Vì vậy lần này tôi đưa vào game engine dựa trên tick và bắt đầu làm lại từ đầu, đồng thời thêm cả code review. Tốc độ chậm hơn, nhưng việc phát triển chắc chắn hơn nhiều. Nếu hoàn thành được một bản demo tốt, tôi định sẽ đăng Show HN.

  • Cho đến khi có được bộ khung nền tảng ban đầu, sự đóng góp trực tiếp của con người thực sự rất quý. Sau khi qua một vòng refactor, từ đó trở đi có thể yên tâm hơn đôi chút.

• Nếu có ai như tôi vừa dùng gói công việc vừa dùng gói cá nhân của Claude, thì có thể chuyển tài khoản đơn giản bằng cách như alias claude-personal="CLAUDE_CONFIG_DIR=~/.claude-personal claude"
  Blog về cách dùng hiệu quả nhiều tài khoản Claude

• Mọi người đều nói “mấu chốt là phải viết đặc tả rõ ràng từ trước để đưa context vào”, nhưng theo kinh nghiệm của tôi thì điều đó không phải lúc nào cũng hiệu quả. Tôi thực sự đã ngồi cùng một chuyên gia và làm các session CC với Opus 4 & Sonnet 4; người đó chuẩn bị spec rất rõ ràng, nhưng kết quả lại không tốt hơn cách của tôi mấy — tức là cứ nảy ra tính năng nào thì yêu cầu ngay theo context của nó, không cần CLAUDE.md. Workflow dựa trên đặc tả thường xuyên quên các điểm quan trọng, hoặc tự bịa ra những thứ không có trong tài liệu ngữ cảnh (thậm chí cả những thứ đã bị cấm). Còn tôi thì những chỉ thị kiểu như “hãy thêm trang CRUD cho invoice, trước tiên thử phân tích codebase đi” lại cho kết quả tốt hơn. Đây chỉ là kinh nghiệm cá nhân của tôi, nhưng sau hơn 100 dự án làm cùng Claude, ngoài các hook riêng để ngăn nó vượt quá phạm vi, tôi không thể khẳng định có cách cụ thể nào tốt hơn hẳn. Dù nhiều người nói “cách dựa trên spec tốt hơn”, nhưng khi yêu cầu họ cho xem thực tế thì thường lại thấy họ tốn quá nhiều thời gian để liên tục sửa những chỗ sai một cách rất rõ ràng. Thậm chí dù có ghi trong CLAUDE.md rằng “tuyệt đối đừng làm những việc này”, nó vẫn có xu hướng tiếp tục làm như vậy.