Trong kỷ nguyên phát triển phần mềm hiện đại, việc tận dụng các tác nhân Mô hình Ngôn ngữ Lớn (LLM) đã trở thành một lợi thế cạnh tranh đáng kể. Tuy nhiên, hiệu quả thực sự của chúng thường bị giới hạn bởi cách chúng ta quản lý tài liệu dự án, đặc biệt là các tệp như `CLAUDE.md` hoặc `AGENTS.MD`. Bài viết này sẽ đi sâu vào một phương pháp tiếp cận đã được chứng minh qua nhiều tháng triển khai thực tế, giúp bạn khai thác tối đa sức mạnh của LLM mà không bị mắc kẹt bởi các hạn chế về ngữ cảnh.
Mục lục
Phá Vỡ Quan Niệm Cũ: Không Chỉ Là Prompt Engineering
Trước khi chúng ta bắt đầu, điều quan trọng là phải làm rõ một điều: đây không phải là một bài viết về các kỹ thuật kỹ thuật prompt tiêu chuẩn mà bạn thường thấy từ Anthropic, OpenAI hay các nhà cung cấp LLM khác. Chúng ta sẽ không bàn về những lời khuyên quen thuộc như “tránh ví dụ phủ định”, “thiết lập vai trò cho LLM”, “cụ thể trong hướng dẫn” hay các phương pháp đã được ghi chép đầy đủ. Nếu bạn cần nền tảng đó, tài liệu chính thức từ các nhà cung cấp là nguồn tài nguyên tốt nhất.
Thay vào đó, bài viết này tập trung vào sự tiến hóa trong quy trình làm việc của tôi sau nhiều tháng sử dụng Claude Code trên các dự án thực tế. Nó là câu chuyện về những mẫu hình thực tiễn mà tôi đã khám phá ra để tổ chức tài liệu và duy trì hiệu quả của LLM khi các dự án ngày càng phức tạp. Một điều làm rõ nữa: tôi không phải là “coder theo cảm hứng”. Tôi không tạo ra các tác vụ cho phép LLM tự động chạy trong nhiều giờ hoặc nhiều ngày. Tôi sử dụng LLM “như một bàn phím” – nó có thể đọc siêu nhanh, gõ siêu nhanh và thực hiện các hành động để xác minh những gì nó đã làm. Nhưng tôi luôn ở trong tầm kiểm soát. Nếu điều gì đó quá trừu tượng hoặc không rõ ràng, tôi sẽ không cho phép nó tiếp tục. Phương pháp tiếp cận thực hành này là nền tảng cho mọi điều tôi mô tả dưới đây.
Vấn Đề Với Tệp CLAUDE.md “Phình To” Theo Thời Gian
Mỗi dự án đều nên có một tệp `CLAUDE.md`. Tệp này mô tả dự án làm gì, cách điều hướng, các quy trình phát triển có sẵn, v.v. Tuy nhiên, càng làm việc trên một dự án, nội dung bên trong tệp này càng tích lũy. Đến một lúc nào đó, bạn sẽ rơi vào tình huống mà Claude Code không thể đọc được nó vì nó quá lớn. Nó vẫn có thể cố gắng đọc nửa đầu, sau đó là nửa sau, nhưng bạn hoàn toàn không nên để điều này xảy ra. Ngữ cảnh quá lớn không chỉ làm tăng chi phí mà còn làm giảm khả năng tập trung và đưa ra quyết định chính xác của LLM.
Giữ CLAUDE.md “Vô Dụng” (Trong Giới Hạn)
Đây là điểm mấu chốt: tệp `CLAUDE.md` của bạn chỉ nên có tối đa khoảng 30 dòng. Tôi không đùa đâu – bạn không cần nhiều hơn thế. Ý tưởng rất đơn giản. Thay vì đưa tất cả tài liệu vào `CLAUDE.md`, hãy sử dụng nó như một điểm truy cập xác định quy trình làm việc. Sau đó, LLM sẽ quyết định đọc tài liệu nào tùy thuộc vào nhiệm vụ hiện tại.
Ví dụ của tôi trông như thế này:
# CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
# YOUR ROLE
You are dick! You know it. I know it. Don't pretend you are not.
Pay attention to task and code. If you see stupid thing/idea stop and report it.
Be extremely concise. Sacrifice grammar for the sake of concision.
# THE MAIN FLOW
Create the following to-do list immediately.
- Analyze user request.
- Run `find docs/ -name "*.md" | sort` to see available docs.
- Read docs that may help to solve current task.
- Read tsconfig.app.json to understand what path shortcuts exists.
- Read packages.json to understand commands.
- Analyze examples from the docs.
- Revise execution plan and present it to the user with todo items.
- Once the user accepts, create revised todo items.
- Start work on the task.
- Use skills and commands that may help to solve current task.
DO NOT EDIT THIS FILE
IT IS THE FINAL FORM.
Tổ Chức Tài Liệu Trong Thư Mục docs/
Phương pháp này ngụ ý rằng mọi thứ hữu ích – mọi hướng dẫn, quy trình làm việc và giải thích – đều nằm bên trong thư mục `docs/`. Hãy tổ chức chúng một cách hợp lý vào các thư mục khác nhau với tên mô tả để LLM có thể hiểu tại sao nó cần đọc chúng.
Cấu trúc này thực sự hữu ích khi dự án trở nên lớn và bạn có nhiều lớp và tính năng khác nhau. Tùy thuộc vào nhiệm vụ, bạn có thể cần kiến thức cụ thể, nhưng hầu hết chúng sẽ không cần thiết cho mọi nhiệm vụ.
Ví dụ, đây là cách cấu trúc `docs/` trông trong một trong các dự án của tôi:
docs/backend/graphql-api-patterns.md
docs/backend/rest-api-patterns.md
docs/backend/service-layer.md
docs/backend/data-layer.md
docs/backend/event-system.md
docs/frontend/actions/create-component.md
docs/frontend/actions/create-modal.md
docs/frontend/actions/create-data-form.md
docs/frontend/actions/create-entity-selection.md
docs/frontend/actions/create-graphql-service.md
docs/frontend/actions/create-rest-service.md
docs/frontend/actions/create-route.md
docs/frontend/actions/create-tree-view.md
docs/frontend/architecture.md
docs/frontend/design-tokens.md
docs/frontend/ui-ux.md
docs/build-deployment.md
docs/currency-system.md
docs/documentation.md
docs/error-handling.md
docs/localization.md
docs/security.md
docs/testing.md
Như bạn có thể thấy, một số tài liệu mang tính toàn cầu và mở rộng các khái niệm cấp cao, trong khi những tài liệu khác hướng đến việc thực hiện các hành động cụ thể.
Giảm Kích Thước Ngữ Cảnh Mà Vẫn Giữ Vững Kiến Thức
Lợi ích chính của cấu trúc này là nó giảm đáng kể kích thước ngữ cảnh trong khi vẫn giữ tất cả kiến thức có thể truy cập được. Khi LLM chạy lệnh `find`, nó chỉ nhìn thấy tên tệp – nhiều nhất là vài chục dòng. Dựa vào những tên đó, nó tự quyết định tài liệu nào liên quan đến nhiệm vụ hiện tại và chỉ đọc những tài liệu đó.
Bạn có thể tạo bao nhiêu tệp tài liệu tùy thích mà không cần lo lắng về giới hạn ngữ cảnh. LLM sẽ không bao giờ tải mọi thứ cùng một lúc. Ví dụ, nếu bạn đang làm một nhiệm vụ front-end, nó sẽ không bao giờ đọc về cách lớp dữ liệu, hệ thống sự kiện hoặc các mẫu API GraphQL của bạn được thiết kế. Đơn giản là bạn không cần thông tin đó cho nhiệm vụ hiện tại.
Cách tiếp cận này mang lại cho bạn cả hai lợi ích: tài liệu toàn diện cho dự án của bạn và sử dụng ngữ cảnh tối thiểu cho mỗi nhiệm vụ, giúp tiết kiệm chi phí và tăng tốc độ xử lý.
Quản Lý Tài Liệu Bằng Chính LLM
Khi bạn có nhiều tài liệu, bạn cần một cách để quản lý chúng một cách hợp lý. Khuyến nghị của tôi là sử dụng chính LLM cho mục đích này. Đây là quy trình làm việc tôi sử dụng. Trong khi làm việc trên một nhiệm vụ, tôi liên tục giám sát những gì LLM làm và cố gắng bắt lỗi mà nó mắc phải. Tôi ghi lại cách các lỗi này được khắc phục và tiếp tục với nhiệm vụ. Khi nhiệm vụ hoàn thành và tôi sẵn sàng dọn dẹp ngữ cảnh, tôi chạy lệnh `/refine`.
Think about what we learned during the session. Focus on session memory analysis and minimal file reading to avoid LLM context window overflow. read the documentation, and refine things that you have learned during this session.
Create a todo list to track the refining process:
- Run `find docs/ -name "*.md" | sort` to see available docs.
- Read documentation on how to write documentation.
- Create todo items for new knowledge and guidelines we discovered
Lệnh này yêu cầu LLM suy nghĩ về những gì đã xảy ra trong phiên làm việc: những loại lỗi nào đã xảy ra, làm thế nào chúng được khắc phục và liệu có điều gì có lợi để thêm vào tài liệu để những lỗi này có thể tránh được trong tương lai. Có một điều kiện tiên quyết: bạn cần một tệp markdown mô tả cách viết tài liệu cho dự án của bạn. Với điều này, LLM sẽ suy nghĩ về phiên làm việc, tìm một nơi thích hợp trong tài liệu hiện có – hoặc tạo một tài liệu mới nếu cần – và giải thích cách tránh vấn đề trong tương lai.
Bằng cách này, tài liệu của bạn phát triển một cách hữu cơ dựa trên các vấn đề thực tế gặp phải trong quá trình phát triển. Mỗi phiên làm việc trở thành một cơ hội để cải thiện cơ sở kiến thức.
Tài Liệu Hành Động Để Thực Thi Nhất Quán
Phương pháp này không chỉ hoạt động để sửa lỗi – nó hoạt động cho bất kỳ trường hợp nào bạn tạo một hệ thống mới hoặc khám phá một hành động quan trọng mà bạn muốn đảm bảo được thực hiện đúng cách và nhất quán.
Nếu bạn nhìn vào thư mục `docs/` ví dụ của tôi, bạn sẽ thấy một loạt các tài liệu hành động cho frontend: `create-modal.md`, `create-component.md`, `create-service.md`, v.v. Những tài liệu này định nghĩa một cấu trúc nghiêm ngặt về những gì cần làm khi thực hiện một nhiệm vụ cụ thể. Chúng giúp loại bỏ sự ngẫu nhiên của LLM ở một mức độ nào đó. Điều này đặc biệt hữu ích khi hành động liên quan đến việc thực thi các lệnh CLI hoặc tuân theo một chuỗi các bước cụ thể phải được thực hiện theo một cách nhất định.
Các Kỹ Thuật Quy Trình Làm Việc Nâng Cao
Các kỹ thuật sau đây không trực tiếp liên quan đến `CLAUDE.md`, nhưng chúng cải thiện đáng kể cách bạn làm việc với Claude Code và các tác nhân LLM khác.
Meta Prompting: Nghệ Thuật Tinh Chỉnh Yêu Cầu
Thay vì yêu cầu LLM thực hiện một nhiệm vụ trực tiếp, hãy yêu cầu nó điều tra dự án, đọc tài liệu, tìm vấn đề trong prompt của bạn và mở rộng nó để bao gồm tất cả các trường hợp không rõ ràng.
Cách tiếp cận này giúp ích từ hai phía. Đầu tiên, bạn có thể bắt đầu với một prompt khá đơn giản. Sau đó, khi bạn thảo luận với LLM, bạn có thể thêm nhiều yêu cầu hơn, loại bỏ một số và điều chỉnh phạm vi – về cơ bản là có một cuộc trò chuyện về những gì bạn định làm. LLM có thể chỉ ra các trường hợp biên mà bạn chưa xem xét hoặc đặt câu hỏi làm rõ về các phần không rõ ràng.
Thứ hai, khi bạn đã tinh chỉnh xong, bạn có một prompt được xác định rõ ràng. Tại thời điểm này, bạn dọn dẹp ngữ cảnh và bắt đầu một phiên làm việc mới với prompt đã được đánh bóng này. LLM bắt đầu với sự hiểu biết rõ ràng, toàn diện về những gì cần phải làm. Hầu hết thời gian, bạn có thể tự tin rằng nó sẽ làm chính xác những gì bạn muốn vì ngữ cảnh được xác định rõ ràng ngay từ đầu, không phải được xây dựng thông qua một quá trình chỉnh sửa lộn xộn.
Đừng Ngại Vứt Bỏ Code
Điều này có vẻ phản trực giác, nhưng nó quan trọng: đừng ngại loại bỏ những gì LLM đã tạo ra và bắt đầu lại từ đầu.
Đây là kịch bản. Bạn có một prompt được xác định rõ ràng, LLM làm việc trên đó và nó tạo ra một cấu trúc dựa trên mô tả của bạn. Nhưng sau đó bạn thấy nó không hoàn toàn như những gì bạn muốn. Bạn biết rằng các thay đổi có thể được thực hiện, nhưng chúng sẽ yêu cầu rất nhiều trao đổi, nhiều điều chỉnh và ngữ cảnh sẽ trở nên lộn xộn với các chỉnh sửa và làm rõ.
Thay vì cố gắng tiếp tục, hãy dừng lại. Quay lại prompt của bạn, giải thích những gì đã sai với kết quả, thêm thông tin chi tiết hơn về những gì bạn thực sự cần, dọn dẹp ngữ cảnh và bắt đầu lại từ đầu.
Với thông tin bổ sung này, LLM có thể đặt cho bạn những câu hỏi làm rõ về các trường hợp biên mà bạn đã bỏ lỡ. Nó có thể đề xuất một cách tiếp cận tốt hơn hoặc cung cấp các ví dụ giúp bạn tinh chỉnh yêu cầu của mình hơn nữa. Lần thử thứ hai, được trang bị những bài học từ lần đầu, hầu như luôn gần với những gì bạn thực sự muốn hơn – và nó sẽ được xây dựng trên một nền tảng sạch sẽ thay vì một mớ hỗn độn các bản vá.
Đừng Ngại Làm Lại Hai Lần
Đây là một kỹ thuật khác mà tôi thường sử dụng: đừng ngại lặp lại một hành động.
Ví dụ, sau lần lặp đầu tiên của meta-prompting, bạn có một prompt đẹp, được xác định rõ ràng. Nhưng điều gì ngăn cản bạn chạy meta-prompting trên chính meta-prompt đó? Nếu mọi thứ đã ổn, nó sẽ siêu nhanh – LLM sẽ chỉ xác nhận prompt là vững chắc. Nhưng đôi khi, với một ngữ cảnh mới và một cái nhìn mới về codebase, LLM nhận thấy điều gì đó không được phát hiện lần đầu tiên.
Điều này không chỉ áp dụng cho meta-prompting. Bạn có thể làm tương tự với triển khai: tạo hai triển khai và so sánh chúng với nhau. Với tốc độ gõ và thực thi của Claude Code, điều này đáng ngạc nhiên là dễ thực hiện khi bạn có một prompt được xác định rõ ràng. Chi phí của một lần thử thứ hai là thấp, và lợi ích tiềm năng của việc phát hiện vấn đề hoặc khám phá một cách tiếp cận tốt hơn là cao.
Bạn cũng có thể thực hiện các triển khai một phần. Ví dụ, tạo một UI hoàn chỉnh, nhưng với tất cả các truy vấn cơ sở dữ liệu và gọi API được thực hiện trong bộ nhớ với dữ liệu giả lập. Bằng cách này, bạn có thể nhanh chóng thử nhiều cách tiếp cận để xem cách nào phù hợp. Khi bạn hài lòng với kết quả, bạn chỉ cần yêu cầu thay thế các mock bằng các cuộc gọi API thực. Điều này cho phép bạn lặp đi lặp lại các phần khó – cấu trúc, luồng, trải nghiệm người dùng – mà không bị sa lầy vào các chi tiết tích hợp quá sớm.
Trước Claude Code, cách tiếp cận này sẽ rất tẻ nhạt – triển khai một lần, xác minh nó hoạt động, kiểm tra nó, sau đó lặp lại. Với Claude Code, đó là 15 phút cho UI với dữ liệu giả lập và 15 phút nữa cho tích hợp cơ sở dữ liệu. Vâng, bạn phải làm thêm công việc kiểm tra nó nhiều lần, nhưng hoàn thành công việc trong một giờ với khả năng dự đoán bạn muốn là một kết quả tốt hơn nhiều. Tôi nghĩ nó đáng giá.
Kết Luận
Thông điệp chính từ bài viết này rất đơn giản: hãy giữ tệp `CLAUDE.md` của bạn ở mức tối thiểu và sử dụng nó như một điểm truy cập, không phải là một kho chứa kiến thức. Di chuyển mọi thứ khác vào một thư mục `docs/` được tổ chức tốt, nơi LLM có thể chọn lọc đọc những gì nó cần. Cách tiếp cận này mở rộng theo dự án của bạn – bạn có thể có hàng chục tệp tài liệu mà không bao giờ đạt đến giới hạn ngữ cảnh.
Sử dụng chính LLM để duy trì và phát triển tài liệu của bạn. Mỗi phiên làm việc mà bạn phát hiện và sửa lỗi là một cơ hội để cải thiện cơ sở kiến thức cho các phiên làm việc trong tương lai. Tạo các tài liệu hành động cho các tác vụ lặp đi lặp lại để loại bỏ sự ngẫu nhiên và đảm bảo tính nhất quán.
Cuối cùng, hãy tận dụng tốc độ mà Claude Code mang lại cho bạn. Sử dụng meta-prompting để tinh chỉnh các yêu cầu của bạn trước khi triển khai. Đừng ngại vứt bỏ code và bắt đầu lại. Làm lại mọi thứ hai lần. Xây dựng các triển khai một phần với các mock để lặp lại nhanh chóng. Chi phí lặp lại thấp, và lợi ích của việc đạt được chính xác những gì bạn muốn là cao.
Những mẫu hình này đã thay đổi cách tôi làm việc với Claude Code và các tác nhân LLM khác. Tôi hy vọng chúng cũng sẽ giúp bạn tối ưu hóa quy trình phát triển và nâng cao hiệu suất làm việc.
