5 Mindset & 2 Workflow mà người mới cần nắm để dùng Claude Code hiệu quả

Mình thấy một pattern lặp lại hoài trong community: mở Claude Code, gõ yêu cầu, chờ, không được thì sửa prompt, lại chờ. Tốn thời gian, tốn token, mà kết quả cứ “gần đúng”.

Vấn đề không nằm ở Claude. Vấn đề nằm ở cách mình tiếp cận.

Bài này mình chia sẻ 2 workflow cụ thể mà mình dùng hàng ngày, một cho build mới và một cho sửa lỗi, kèm starter prompts bạn có thể copy xài ngay. Không lý thuyết, không triết lý, chỉ có quy trình.

Nhưng trước khi vào workflow, có một thứ cần chỉnh trước.

Mindset: bạn đã có sẵn skill cần thiết, chỉ chưa biết áp dụng

Nếu bạn không phải dân kỹ thuật, có thể bạn đang nghĩ “mình không biết code thì Claude Code có giúp được gì đâu”. Hoặc ngược lại, “mình cứ bảo nó làm, nó sẽ hiểu”. Cả hai đều sai.

Thực tế thì bạn đã có hầu hết những gì cần thiết rồi. Mỗi ngày đi làm, bạn nhờ đồng nghiệp làm gì đó, bạn biết phải nói rõ. Bạn giao việc cho nhân viên, bạn biết phải mô tả kết quả mong muốn. Bạn review công việc người khác, bạn biết nói “đúng rồi” hay “chưa đúng, sửa chỗ này”.

Làm việc với Claude Code cũng y vậy. Bạn không cần học code. Bạn cần dùng đúng những skill bạn đã có, chỉ là áp dụng vào context mới.

Dưới đây là 5 mindset cụ thể, mỗi cái mình kèm ví dụ từ công việc hàng ngày để bạn thấy nó không xa lạ gì.

1. Mô tả rõ kết quả mong muốn, không mô tả cảm xúc

Ở công ty: Bạn không bảo designer “làm cho đẹp”. Bạn nói “banner này cần nổi bật nút đăng ký, dùng màu cam, kích thước 1200x628 cho Facebook.”

Với Claude Code: Không bảo “tạo cho mình app học tiếng Anh”. Mà nói “tạo web app, user nhập câu tiếng Việt, hệ thống dịch sang tiếng Anh, cho nghe phát âm, rồi chấm điểm phát âm của user.”

Cái khác biệt là input/output rõ ràng. Ai dùng, nhập gì vào, nhận gì ra. Bạn làm chuyện này mỗi ngày khi brief công việc cho team, chỉ là chưa quen làm với AI.

Bắt đầu bằng: Trước khi gõ bất cứ gì vào Claude Code, viết ra 3 dòng: (1) ai dùng, (2) họ làm gì, (3) họ nhận được gì. Chỉ 3 dòng thôi, nhưng nó thay đổi hoàn toàn kết quả.

2. Delegate rõ ràng, không dump rồi cầu nguyện

Ở công ty: Bạn không quăng một đống tài liệu cho nhân viên mới rồi nói “làm đi”. Bạn chia nhỏ, giao từng phần, kiểm tra từng bước.

Với Claude Code: Không paste cả ý tưởng 2000 chữ rồi bảo “build cho mình”. Mà chia thành: brainstorm trước, rồi lên plan, rồi chia task, rồi implement từng task một.

Mình thấy nhiều người giao cho Claude một prompt dài 3 đoạn rồi thất vọng khi kết quả sai. Nhưng nếu cùng một khối lượng công việc đó mà bạn giao cho nhân viên một lúc, kết quả cũng sẽ sai. Không phải vì người đó kém, mà vì khối lượng quá lớn để xử lý một lần.

Bắt đầu bằng: Mỗi lần tương tác với Claude, chỉ yêu cầu MỘT việc. Xong việc đó, review, rồi mới sang việc tiếp.

3. Review trước khi duyệt, không nhắm mắt accept

Ở công ty: Khi nhân viên gửi báo cáo, bạn đọc rồi mới ký. Bạn không ký mà không đọc (ờ, hy vọng vậy).

Với Claude Code: Khi Claude đề xuất PRD, plan, hay code, bạn đọc và hỏi lại nếu chưa hiểu. “Chỗ này tại sao chọn cách này mà không chọn cách khác?” “Phần này có cần thiết không?” Đừng accept mọi thứ Claude đưa ra chỉ vì nó “nghe có vẻ đúng”.

Đây là skill quan trọng nhất và cũng là chỗ nhiều người lười nhất. Claude đề xuất rất tự tin, nhưng tự tin không có nghĩa là đúng. Vai trò của bạn là người chốt quyết định, không phải người gật đầu.

Bắt đầu bằng: Mỗi lần Claude đề xuất gì, hỏi ít nhất 1 câu “tại sao” trước khi đồng ý. Chỉ 1 câu thôi, nhưng nó buộc bạn phải thật sự đọc và hiểu.

4. Mô tả vấn đề bằng triệu chứng, không tự chẩn đoán

Ở công ty: Khi máy tính hỏng, bạn gọi IT và nói “mình bật máy lên thì màn hình đen, có tiếng bíp 3 lần.” Bạn không nói “mainboard chắc cháy rồi” vì bạn không biết, và nếu đoán sai thì IT sẽ đi sai hướng.

Với Claude Code: Khi gặp bug, không bảo “sửa function X”. Mà mô tả “khi mình bấm nút submit, mình expect trang chuyển sang trang kết quả, nhưng nó reload lại trang cũ, console hiện lỗi này [paste error].”

Mô tả triệu chứng thay vì tự chẩn đoán vì có thể bạn đoán sai nguyên nhân. Để Claude điều tra sẽ chính xác hơn, giống như để IT kiểm tra thay vì bạn tự tháo máy.

Bắt đầu bằng: Khi gặp lỗi, viết theo format: “khi [hành động], mình expect [A] nhưng thực tế [B].” Cứ theo format này, Claude sẽ chẩn đoán tốt hơn nhiều.

5. Học dần trong quá trình làm, không chờ “sẵn sàng”

Ở công ty: Bạn không đợi học hết Excel rồi mới bắt đầu làm report. Bạn làm report, gặp chỗ không biết thì tra Google hoặc hỏi đồng nghiệp, rồi biết thêm một chút.

Với Claude Code: Flowchart, schema database, API, deployment, bạn không cần hiểu hết từ đầu. Bắt đầu làm, gặp khái niệm lạ thì hỏi Claude giải thích. Nó giải thích rất tốt nếu bạn hỏi cụ thể.

Nhưng “học dần” không có nghĩa là “không cần effort”. Bạn vẫn cần đọc, cần hiểu, cần hỏi lại khi chưa rõ. Claude không phải nút magic, nó là một cộng sự giỏi. Và để làm việc hiệu quả với cộng sự giỏi, bạn cũng cần bỏ công sức ra.

Bắt đầu bằng: Mỗi khi Claude dùng một khái niệm bạn không hiểu, hỏi ngay: “giải thích [khái niệm] cho mình bằng ngôn ngữ đơn giản, kèm ví dụ.” Sau vài tuần bạn sẽ ngạc nhiên mình biết nhiều thứ hơn mình tưởng.

5 mindset này không mới. Bạn đã dùng nó hàng ngày ở công ty. Khác biệt duy nhất là bây giờ “đồng nghiệp” của bạn là AI, và nó làm việc nhanh hơn người thật rất nhiều, nhưng cũng cần được brief rõ ràng y như người thật.

OK, vào workflow.

Workflow 1: build something new

Đây là quy trình mình dùng mỗi khi bắt đầu một project hoặc feature mới. 4 bước, theo thứ tự.

Bước 1: brainstorm với Claude

Mở Claude Code, chưa vội code gì hết. Mô tả ý tưởng bằng ngôn ngữ bình thường, như đang kể cho bạn bè nghe.

Starter prompt:

Mình muốn làm [mô tả ý tưởng]. Trước khi bắt đầu, hãy hỏi mình 10 câu hỏi để hiểu rõ yêu cầu. Hỏi từng câu một, đợi mình trả lời xong rồi hỏi tiếp.

Cái này hiệu quả vì Claude sẽ hỏi những thứ bạn chưa nghĩ tới. Ai dùng? Dùng ở đâu? Data lưu ở đâu? Edge cases nào? Bạn chỉ cần trả lời, Claude sẽ giúp bạn tự làm rõ ý tưởng.

Dùng Opus ở bước này. Đây là bước khám phá, cần reasoning sâu để hỏi đúng câu hỏi.

Bước 2: vào Plan Mode, để Claude tạo PRD

Sau khi brainstorm xong, chuyển sang Plan Mode.

Starter prompt:

Dựa trên cuộc brainstorm vừa rồi, hãy tạo một PRD (Product Requirements Document) bao gồm: mục tiêu sản phẩm, user stories chính, phạm vi (làm gì và KHÔNG làm gì), data model cơ bản, tech stack đề xuất, và các ràng buộc kỹ thuật.

Claude sẽ viết PRD cho bạn. Bạn đọc, chỉnh, bổ sung. Đây là lúc quan trọng nhất, vì mọi quyết định ở đây sẽ ảnh hưởng tới toàn bộ project sau này.

Mấy thứ cần chú ý khi review PRD:

Phần “KHÔNG làm gì” quan trọng ngang phần “làm gì”. Nếu không chốt scope rõ, Claude sẽ tự thêm feature và bạn sẽ bị scope creep mà không biết.

Tech stack cũng nên chốt ở đây. Claude mạnh nhất với TypeScript/JavaScript (Next.js, React), Python (FastAPI, Flask), và Go vì training data phong phú và documentation tốt. Nếu bạn không có lý do đặc biệt, chọn stack phổ biến sẽ giúp Claude giúp bạn tốt hơn.

Vẫn dùng Opus ở bước này. PRD cần reasoning sâu để chốt đúng scope và tech decisions.

Bước 3: plan cho plan, chia PRD thành task

Vẫn trong Plan Mode, yêu cầu Claude chia nhỏ PRD thành implementation plan.

Starter prompt:

Dựa trên PRD trên, hãy chia thành các task cụ thể theo thứ tự implement. Mỗi task cần có: mô tả ngắn, input/output rõ ràng, dependencies (task nào cần xong trước), và estimate mức độ phức tạp (đơn giản / trung bình / phức tạp).

Review lại task list. Kiểm tra thứ tự có hợp lý không, có task nào quá lớn cần chia nhỏ thêm không. Mỗi task nên đủ nhỏ để hoàn thành trong một conversation.

Đến đây bạn có bản kế hoạch hoàn chỉnh mà bạn không tự viết dòng nào, nhưng đã review và chốt mọi quyết định. Đó là cái hay của Plan Mode.

Bước 4: execute từng task

Thoát Plan Mode. Bắt đầu implement.

Starter prompt cho mỗi task:

Đây là PRD của project: [paste hoặc trỏ tới file PRD] Đây là task list: [paste hoặc trỏ tới file task list] Hãy implement task [số]: [mô tả task]

Mỗi task nên là một conversation riêng. Xong task thì commit, mở conversation mới cho task tiếp theo. Cách này giữ context sạch, Claude không bị quên giữa chừng.

Chuyển sang Sonnet ở bước này. Bạn đã có spec rõ ràng từ bước trước, Sonnet execute nhanh và tiết kiệm token hơn khi implement theo plan có sẵn.

Mẹo quan trọng: tạo CLAUDE.md ngay từ đầu

Trước khi bắt đầu bước 4, tạo file CLAUDE.md ở root project. Claude Code tự động đọc file này đầu tiên mỗi session. Ghi vào đó:

Project này là [mô tả ngắn]. Tech stack: [stack]. Cấu trúc thư mục: [mô tả]. Quy tắc code: [conventions]. Decisions đã chốt: [liệt kê].

File này là bộ nhớ dài hạn của Claude. Mỗi conversation mới, Claude đều đọc lại CLAUDE.md nên nó không mất context giữa các session. Cập nhật file này mỗi khi có decision mới.

Workflow 2: fix something broken

Khác với build mới, sửa lỗi cần kỷ luật hơn. Sai lầm phổ biến nhất là bảo Claude “sửa cái bug này” rồi nó refactor cả file, phá thêm 3 chỗ khác. Mình từng mất cả buổi vì chuyện này (yeah).

Bước 1: mô tả triệu chứng, không mô tả giải pháp

Đừng bảo “sửa function X”. Hãy mô tả cái bạn thấy.

Starter prompt:

Mình gặp vấn đề: khi [hành động cụ thể], mình expect [kết quả mong muốn] nhưng thực tế [kết quả thực tế]. Error message (nếu có): [paste error]. File liên quan: [tên file].

Mô tả triệu chứng thay vì giải pháp vì có thể bạn đoán sai nguyên nhân. Để Claude tự điều tra sẽ chính xác hơn.

Dùng Opus ở bước này. Chẩn đoán cần reasoning sâu để tìm đúng nguyên nhân.

Bước 2: yêu cầu Claude chẩn đoán trước khi sửa

Đừng để Claude nhảy vào sửa ngay. Bắt nó phân tích trước.

Starter prompt:

Trước khi sửa, hãy phân tích nguyên nhân gốc của vấn đề này. Liệt kê các khả năng, đánh giá khả năng nào cao nhất, và giải thích tại sao. Chưa sửa code gì hết.

Bước này cực kỳ quan trọng. Nhiều bug nhìn giống nhau nhưng nguyên nhân khác nhau. Nếu Claude sửa sai nguyên nhân, bạn lại rơi vào vòng lặp bug-debug-bug.

Bước 3: giới hạn phạm vi sửa

Khi đã xác định nguyên nhân, giới hạn rõ Claude được sửa gì.

Starter prompt:

OK, mình đồng ý nguyên nhân [X]. Hãy sửa chỉ vấn đề này, không refactor hay thay đổi gì khác ngoài phạm vi fix. Liệt kê chính xác những file và function sẽ thay đổi trước khi sửa.

Cái “liệt kê trước khi sửa” là chìa khóa. Bạn review scope trước, đồng ý rồi Claude mới sửa. Tránh được chuyện Claude tự ý refactor cả codebase.

Chuyển sang Sonnet ở bước này để execute fix. Bạn đã có chẩn đoán rõ ràng, Sonnet sửa nhanh và chính xác theo scope đã chốt.

Bước 4: verify rồi commit

Sau khi Claude sửa xong, verify.

Starter prompt:

Hãy giải thích chính xác những gì đã thay đổi và tại sao. Sau đó chạy test liên quan để confirm fix hoạt động.

Nếu OK thì commit ngay. Đừng để fix này trộn lẫn với thay đổi khác. Một fix, một commit, message rõ ràng.

Nếu fix không hoạt động, quay lại bước 2 thay vì bảo Claude “sửa lại đi”. Cứ lặp bước 2 → 3 → 4 cho đến khi xong, mỗi vòng lặp đều có chẩn đoán rõ ràng thay vì trial and error.

Tiết kiệm token: những nguyên tắc xuyên suốt

Xuyên suốt cả 2 workflow, có mấy nguyên tắc giúp bạn không cháy token:

Opus để nghĩ, Sonnet để làm. Brainstorm, chẩn đoán, planning thì dùng Opus — cần reasoning sâu. Execute code theo plan có sẵn thì dùng Sonnet — nhanh và tiết kiệm. Đừng dùng Sonnet khi bạn còn đang tìm hiểu vấn đề, giống bạn không giao thiết kế nhà cho thợ xây vậy. Nếu bạn dùng Max plan, cứ Opus cho tất cả — không cần chuyển qua lại.

Mỗi task một conversation. Context window có giới hạn. Conversation dài quá thì Claude bắt đầu quên, hallucinate, bịa function. Xong task thì commit, conversation mới. CLAUDE.md sẽ giữ context xuyên suốt.

CLAUDE.md là bộ nhớ, không phải trang trí. Cập nhật nó liên tục. Mỗi decision mới, mỗi convention mới, ghi vào đó. Claude đọc file này đầu tiên mỗi session, nên bạn không tốn token nhắc lại những gì đã chốt.

Đừng hỏi lại cùng một câu. Nếu Claude đã trả lời rồi mà bạn quên, đọc lại conversation cũ thay vì hỏi lại. Mỗi lần hỏi lại là tốn token.

Dùng Claude.ai Projects cho brainstorm dài. Nếu bạn cần brainstorm phức tạp, nhiều tài liệu tham khảo, dùng Claude.ai Projects thay vì Claude Code. Projects giữ context tốt hơn cho loại công việc này. Claude Code mạnh nhất khi execute code, đừng ép nó làm tất cả.

Starter prompts tổng hợp

Copy và xài ngay, thay [phần trong ngoặc] bằng nội dung của bạn.

Khi bắt đầu project mới:

Mình muốn làm [mô tả ý tưởng]. Trước khi bắt đầu, hãy hỏi mình 10 câu hỏi để hiểu rõ yêu cầu. Hỏi từng câu một, đợi mình trả lời xong rồi hỏi tiếp.

Khi cần PRD:

Dựa trên cuộc brainstorm vừa rồi, hãy tạo PRD bao gồm: mục tiêu sản phẩm, user stories chính, phạm vi (làm gì và KHÔNG làm gì), data model cơ bản, tech stack đề xuất, và các ràng buộc kỹ thuật.

Khi cần chia task:

Dựa trên PRD trên, hãy chia thành các task cụ thể theo thứ tự implement. Mỗi task cần có: mô tả ngắn, input/output rõ ràng, dependencies, và estimate mức độ phức tạp.

Khi implement task:

Đây là PRD: [trỏ tới file]. Task list: [trỏ tới file]. Hãy implement task [số]: [mô tả].

Khi gặp bug:

Mình gặp vấn đề: khi [hành động], mình expect [kết quả mong muốn] nhưng thực tế [kết quả thực tế]. Error: [paste]. File liên quan: [tên file]. Phân tích nguyên nhân gốc trước, chưa sửa gì.

Khi cho phép sửa bug:

Đồng ý nguyên nhân [X]. Sửa chỉ vấn đề này, không refactor gì khác. Liệt kê file và function sẽ thay đổi trước khi sửa.

Khi setup CLAUDE.md:

Tạo file CLAUDE.md cho project này với nội dung: project description, tech stack, folder structure, coding conventions, và key decisions đã chốt từ PRD.

Cả 2 workflow trên đều xoay quanh một ý: nghĩ trước, gõ sau. Bạn dành 30 phút plan thì tiết kiệm được 3 tiếng debug. Bạn mô tả triệu chứng rõ thì Claude chẩn đoán đúng từ lần đầu. Bạn giới hạn scope thì không bị refactor phá code.

Không có gì phức tạp, chỉ cần kỷ luật.