Tôi đã thử nghiệm hàng tá cấu hình Claude Code.
Thứ duy nhất thực sự thay đổi đầu ra của tôi: một file 60 dòng tên là CLAUDE.md.
Hãy đánh dấu trang này lại nhé 🔖
Đây là cách nó hoạt động, lý do hầu hết mọi người bỏ lỡ hoàn toàn, và template đầy đủ bạn có thể copy ngay hôm nay:
Điều không ai nói với bạn về Claude Code
Trước prompt đầu tiên của bạn. Trước một dòng code nào. Trước bất cứ điều gì xảy ra trong phiên làm việc của bạn.
Claude đọc một file. Chỉ một.
CLAUDE.md.
Và nó coi đó là chân lý tuyệt đối cho toàn bộ phiên làm việc. Không phải gợi ý. Không phải ngữ cảnh giữa nhiều thứ khác. Mà là bản tóm tắt quyết định mọi quyết định mà nó sẽ đưa ra.
Đó là lý do tại sao file này là biến số bị đánh giá thấp nhất trong toàn bộ stack Claude Code.
Hầu hết mọi người không có nó. Và những người có thì lại mắc một trong hai sai lầm: hoặc file trống rỗng nội dung, hoặc nó dài 300 dòng kiểu "hãy là một kỹ sư cấp cao giàu kinh nghiệm, người suy nghĩ từng bước một."
Cả hai đều vô dụng. Vì những lý do khác nhau.
Tại sao hầu hết các file CLAUDE.md không hoạt động: 3 lý do thực sự
Lý do 1: Quá dài
Claude có thể tuân theo một cách đáng tin cậy khoảng 150 đến 200 chỉ thị mỗi phiên. Đây là một ràng buộc về cấu trúc, không phải vấn đề thiện chí.
Vấn đề: System prompt nội bộ của Claude Code đã chứa khoảng 50 chỉ thị. Điều đó có nghĩa là CLAUDE.md của bạn thực sự chỉ có 100 đến 150 slot chỉ thị trước khi Claude bắt đầu bỏ qua chúng.
Nếu file của bạn dài 200 dòng, Claude không cố tình phớt lờ quy tắc của bạn. Nó quên chúng một cách máy móc. Bạn không có vấn đề về tuân thủ. Bạn có vấn đề về ngân sách tập trung.
Lý do 2: Nội dung tệ
Phần lớn các file CLAUDE.md chứa đầy những thứ Claude có thể tự suy luận hoặc những thứ không thay đổi hành vi của nó một cách có thể đo lường được.
"Hãy hành động như một kỹ sư cấp cao." → Claude đã biết điều đó có nghĩa là gì và nó không neo giữ bất kỳ hành vi cụ thể nào. "Suy nghĩ từng bước một." → Cái đó đã có trong quá trình huấn luyện của nó. Bạn đang lãng phí một dòng. "Viết code sạch và dễ bảo trì." → Không có tiêu chí cụ thể. Claude không biết "sạch" nghĩa là gì trong ngữ cảnh cụ thể của bạn.
Mỗi dòng không ngăn được một lỗi cụ thể, rõ ràng là một dòng bị đánh cắp khỏi những chỉ thị thực sự quan trọng. Bài kiểm tra rất đơn giản: nếu bạn xóa dòng này, Claude có mắc một lỗi cụ thể nào không? Nếu câu trả lời là không, dòng đó không nên ở đó.
Lý do 3: Không có thứ bậc
Hầu hết mọi người bỏ qua rằng có ba cấp độ chỉ thị trong Claude Code, và họ nhồi nhét mọi thứ vào cùng một chỗ.
~/.claude/CLAUDE.md→ Global (áp dụng cho tất cả các dự án của bạn).claude/CLAUDE.md→ Project (chia sẻ với nhóm, nằm trong git)./CLAUDE.local.md→ Local (ghi đè cá nhân, được gitignore)
Cấp độ global dành cho các quy tắc bạn sẽ lặp lại trong mọi dự án. Cấp độ project dành cho ngữ cảnh cụ thể về stack và nhóm của bạn. Cấp độ local dành cho sở thích cá nhân của bạn không cần chia sẻ.
Sử dụng đúng ba cấp độ là điều giữ cho mỗi file ngắn gọn, tập trung và thực sự hiệu quả. Đặt mọi thứ vào một file giống như xây một cái phễu để nhấn chìm các quy tắc quan trọng của bạn dưới đống tạp âm.
5 phần tạo nên một CLAUDE.md hiệu quả
Sau khi lùng sục hàng tá file CLAUDE.md trong thực tế—các dự án mã nguồn mở, tài liệu chính thức của Anthropic, kho best practice cộng đồng—đây là 5 phần mà tất cả các file hiệu quả đều có điểm chung:
Phần 1: Các lệnh quan trọng
Claude bắt đầu mỗi phiên mà không biết cách build dự án của bạn, chạy test, hay sửa lỗi lint. Nó sẽ đoán. Và những phán đoán của nó sẽ khiến bạn mất lượt.
Hãy cho nó biết chính xác phải gõ gì:
Commands
- Build:
npm run build - Dev:
npm run dev - Test single file:
npm test -- path/to/file - Full test:
npm test - Lint + fix:
npm run lint:fix - Type check:
npx tsc --noEmit
Ngắn gọn. Chính xác. Có thể dùng trực tiếp.
Nếu không có phần này, Claude sẽ thử npm test trong khi dự án của bạn chạy trên pnpm vitest. Nó sẽ mất ba lượt debug một vấn đề về lệnh vốn không bao giờ có tác dụng. Ba lượt mà bạn có thể dùng cho công việc thực sự.
Phần 2: Bản đồ kiến trúc
Claude bắt đầu mỗi phiên với kiến thức bằng không về codebase của bạn. Bằng không. Nó không biết business logic của bạn sống ở đâu. Nó không biết component của bạn có được thiết kế là stateless hay không. Nó không biết rằng API routes của bạn không nên chứa business logic.
Hãy cho nó một bản đồ:
Architecture
- src/lib/services/ → tất cả business logic
- src/components/ → chỉ UI component stateless
- src/lib/store/ → global state (Zustand)
- src/app/api/ → API routes, không có business logic ở đây
- Truy cập DB chỉ qua Server Actions hoặc API routes
Không phải danh sách đầy đủ cấu trúc cây thư mục của bạn. Chỉ đủ để Claude biết mọi thứ nằm ở đâu và quan trọng hơn, chúng KHÔNG nên đi đâu.
Sự phân biệt này... chỗ nào nên để vs. chỗ nào không nên... là điều ngăn chặn các lỗi kiến trúc thường gặp nhất.
Phần 3: Quy tắc cứng
Đây là phần quan trọng nhất của toàn bộ file. Không có ngoại lệ.
Mọi quy tắc ở đây phải trả lời một câu hỏi duy nhất: "Nếu tôi xóa dòng này, Claude có mắc một lỗi cụ thể không?"
Nếu có → quy tắc ở lại. Nếu không → nó không có lý do gì để ở đó.
Ví dụ về các quy tắc giá trị cao:
Rules
- NEVER commit .env files or secrets
- All async calls must be wrapped in a try/catch
- Functional components only, zero class components
- Mandatory commit prefixes: feat:, fix:, docs:, refactor:
- Every PR must pass
npm run verifybefore merge - Static export only, no SSR (deployed on S3)
- IMPORTANT: run type check after every code modification
Hai điều cần lưu ý về danh sách này.
Thứ nhất, quy tắc phủ định cũng quan trọng như quy tắc khẳng định. "Never commit .env files" là một quy tắc chỉ hiển nhiên cho đến ngày Claude làm điều đó. Hãy đưa nó vào.
Thứ hai, các dấu nhấn mạnh như IMPORTANT hoặc YOU MUST thực sự có tác dụng.
Đây không phải chuyện kể lể. Anthropic xác nhận điều này trong tài liệu của chính họ: thêm IMPORTANT hoặc YOU MUST trước một quy tắc giúp cải thiện đáng kể sự tuân thủ quy tắc đó của Claude.
Hãy sử dụng chúng một cách tiết kiệm: dành riêng cho những quy tắc có hậu quả nghiêm trọng nhất nếu bị bỏ qua.
Hãy giữ dưới 15 quy tắc trong phần này. Vượt quá giới hạn đó, bạn làm loãng sự tập trung vào những quy tắc quan trọng.
Phần 4: Sở thích về quy trình làm việc
Bạn đã từng trải qua điều này. Bạn yêu cầu Claude sửa một dòng. Nó viết lại ba file, đổi tên các function của bạn, và refactor một class không liên quan gì đến yêu cầu của bạn.
Phần này ngăn chặn điều đó:
Workflow
- Ask clarifying questions before starting complex tasks
- Make minimal changes, do not refactor unrelated code
- Run tests after every change, fix failures before continuing
- Create separate commits per logical change, not one giant commit
- In case of uncertainty between two approaches, explain both and let me choose
Mỗi dòng ở đây trả lời một vấn đề đau đầu cụ thể. Commit khổng lồ 47 file. Viết lại hoàn toàn không được yêu cầu. Quyết định kiến trúc Claude tự đưa ra khi đáng lẽ nó phải hỏi bạn.
Phần 5: Những gì KHÔNG nên đưa vào CLAUDE.md của bạn
Phần này cũng quan trọng như những phần khác. Thậm chí có thể hơn.
Do NOT include:
- Personality instructions ("be a senior engineer")
- Formatting rules that your linter already handles
- @ imports that pull entire docs into every session
- Duplicate rules (nếu global đã nói "run tests", thì project không lặp lại)
- Anything Claude learns on its own via auto-memory
Điểm cuối cùng này thường bị đánh giá thấp.
Claude duy trì ghi chú riêng của nó trong ~/.claude/projects/<project>/memory/. Chạy /memory trong phiên làm việc của bạn để xem nó đã học được gì về dự án của bạn. Sau vài phiên, bạn thường sẽ nhận ra Claude đã ghi lại thông tin mà bạn định viết tay vào CLAUDE.md của mình.
Đừng lãng phí các chỉ thị có hạn của bạn vào những thứ Claude đã tự ghi nhớ.
Template hoàn chỉnh dưới 60 dòng, sẵn sàng để sử dụng
Xóa các phần không áp dụng cho dự án của bạn. Mục tiêu không phải là điền đầy mọi thứ. Mục tiêu là chỉ giữ lại những gì thay đổi hành vi của Claude một cách có thể đo lường được.
Những dòng có tác động lớn nhất đến đầu ra của tôi: kết quả cụ thể
Sau khi thử nghiệm hàng tá cấu hình, đây là năm dòng tạo ra sự khác biệt rõ rệt nhất:
IMPORTANT: run type check after every code modification→ Ngăn Claude giao code bị hỏng kiểu dữ liệu mà nó không phát hiện được nếu không được nhắc kiểm tra rõ ràng.Make minimal changes, do not refactor unrelated code→ Ngăn việc viết lại hoàn toàn và không được yêu cầu toàn bộ file.Create separate commits per logical change, not one giant commit→ Ngăn commit quái vật 47 file hỗn độn không đọc nổi.In case of uncertainty between two approaches, explain both and let me choose→ Ngăn Claude tự đưa ra quyết định kiến trúc một mình khi đáng lẽ nó phải thuộc về bạn.Static export only, no SSR→ Ngăn Claude thêm server code vào một dự án được deploy tĩnh trên S3.
Điểm chung của năm dòng này: mỗi dòng ngăn chặn một lỗi cụ thể, thường xuyên và tốn kém thời gian debug.
Đây là bài kiểm tra tối thượng cho mọi dòng trong CLAUDE.md của bạn.
Sai lầm cơ bản và tại sao nó lại phổ biến đến vậy
Mọi người đối xử với CLAUDE.md của họ như một danh sách mong muốn hoặc một prompt tính cách.
"Hãy là cấp cao." "Hãy kỹ lưỡng." "Hãy suy nghĩ như một chuyên gia."
Đây không phải một bản tóm tắt. Đây là suy nghĩ mơ hồ.
CLAUDE.md của bạn nên là một tài liệu kỹ thuật, không phải một bài phát biểu tạo động lực. Stack, lệnh, kiến trúc, quy tắc cụ thể, quy trình làm việc. Mọi thứ khác là tạp âm cạnh tranh với những chỉ thị thực sự quan trọng.
Giữ file dưới 80 dòng. Xem xét lại mỗi khi Claude mắc lỗi mà bạn đáng lẽ có thể ngăn chặn.
Và trên hết: hãy hiểu file này trở thành gì theo thời gian.
Một CLAUDE.md tốt trong tháng đầu tiên giúp bạn tiết kiệm thời gian trong mỗi phiên. Đến tháng thứ ba, nó đã nắm bắt các quy ước và stack của bạn đủ chính xác để Claude hoạt động gần như một thành viên trong nhóm.
Đến tháng thứ sáu, nó chứa mọi lỗi Claude từng mắc phải trong dự án này và tự động ngăn chặn tất cả.
File này tích lũy giá trị. Nó cải thiện sau mỗi lần sửa chữa. Nó dần trở thành bản tóm tắt onboarding tốt nhất mà bạn từng viết.
Không phải cho Claude. Mà cho bạn.
