Khi tôi onboard một lập trình viên mới, tôi không chỉ trỏ họ vào codebase và nói “cứ làm đi”. Tôi sẽ dẫn họ đi qua các quy ước của đội. Tôi cho họ xem các ví dụ về đoạn code mà chúng tôi xem là tốt. Tôi giải thích vì sao chúng tôi đưa ra một số quyết định kiến trúc — ví dụ tại sao dùng Fastify thay vì Express, tại sao service viết theo hàm (functional) thay vì class, hay vì sao việc validation diễn ra ở tầng route.

Chỉ sau khi thiết lập bối cảnh như vậy, tôi mới kỳ vọng họ đóng góp code phù hợp với dự án.

AI coding assistant cũng cần quá trình onboarding giống như vậy.

Nhiều lập trình viên trải nghiệm thứ có thể gọi là “vòng lặp bực bội” khi làm việc với AI:

tạo code → nhận ra nó không phù hợp với codebase → yêu cầu AI tạo lại với chỉnh sửa → lặp lại cho đến khi bỏ cuộc hoặc chấp nhận một kết quả phải sửa rất nhiều.

Tôi dần tin rằng ma sát này không đến từ khả năng của AI, mà từ một bước bị thiếu — chúng ta yêu cầu AI viết code mà không cung cấp bối cảnh cần thiết trước đó.

Bài viết này nói về khái niệm tôi gọi là Knowledge Priming — thực hành chia sẻ bối cảnh dự án đã được chọn lọc cho AI trước khi yêu cầu nó tạo code.

Ý tưởng cốt lõi rất đơn giản:

AI giống như một cộng tác viên cực kỳ giỏi nhưng hoàn toàn không có bối cảnh.

Chúng có thể làm việc nhanh hơn bất kỳ con người nào, nhưng chúng không biết gì về quy ước, ràng buộc hay lịch sử của một dự án cụ thể. Khi thiếu bối cảnh, chúng sẽ mặc định dùng các mẫu chung trên Internet, có thể phù hợp hoặc không.

Vấn đề hành vi mặc định

Đây là điều thường xảy ra khi bạn yêu cầu AI viết code mà không có bước priming.

Ví dụ yêu cầu:

“Tạo một UserService xử lý authentication”

AI có thể sinh ra 200 dòng code sử dụng:

• Express.js (trong khi dự án dùng Fastify)
• JWT lưu trong localStorage (trong khi dự án dùng httpOnly cookie)
• helper utils/auth.js (trong khi quy ước đặt trong lib/services/)
• class-based syntax (trong khi codebase dùng functional)
• API bcrypt đã lỗi thời

Code đó vẫn chạy.

Nó đúng cú pháp.

Thậm chí có thể pass test cơ bản.

Nhưng nó hoàn toàn sai với codebase.

Tại sao?

Vì AI mặc định dựa vào training data của nó — sự kết hợp của hàng triệu repository, tutorial và câu trả lời trên Stack Overflow.

Nó tạo ra “giải pháp trung bình của Internet”, chứ không phải giải pháp đúng cho một đội cụ thể.

Điều này giống hệt việc yêu cầu một nhân viên mới viết code ngày đầu tiên mà không onboarding.

Họ sẽ dựa vào kinh nghiệm cũ của mình, mà điều đó có thể không phù hợp với quy ước của team.

Hệ phân cấp tri thức

Tôi thấy hữu ích khi nghĩ về tri thức của AI theo ba lớp, sắp theo mức độ ưu tiên:

Training Data (thấp nhất) Hàng triệu repository, tutorial và pattern chung — thường đã lỗi thời. Đây là “trung bình của Internet.”

Conversation Context (trung bình) Những gì được nói trong phiên chat hiện tại hoặc các file AI vừa xem. Nhưng ngữ cảnh này mờ dần khi cuộc trò chuyện kéo dài.

Priming Documents (cao nhất) Bối cảnh dự án được cung cấp rõ ràng — quyết định kiến trúc, quy ước đặt tên, version cụ thể và pattern code. Khi có, chúng ghi đè mặc định chung.

Thứ bậc này rất quan trọng.

Khi có priming document, thông điệp gửi tới AI thực chất là:

“Bỏ qua pattern chung trên Internet. Đây là cách dự án này hoạt động.”

Và theo trải nghiệm của tôi, AI thực sự làm theo điều đó.

Về mặt kỹ thuật: đây là RAG thủ công

Về mặt kỹ thuật, điều này giống manual RAG (Retrieval-Augmented Generation).

Bạn đang lấp đầy context window của AI bằng token có giá trị cao, đặc thù cho dự án, từ đó ghi đè training data chung.

Giống như khi nhân viên mới hiểu quy ước của team, họ sẽ bỏ các thói quen cũ.

AI cũng vậy — khi có priming rõ ràng, training-data default sẽ nhường chỗ cho context cụ thể.

Cơ chế phía sau cũng có lý do kỹ thuật.

Mô hình transformer xử lý ngữ cảnh thông qua attention mechanism — về bản chất là một ngân sách hữu hạn.

Mỗi token trong context window cạnh tranh để ảnh hưởng đến output.

Nếu cửa sổ ngữ cảnh chứa toàn pattern chung từ training data → model tạo ra giải pháp trung bình.

Nếu cửa sổ chứa bối cảnh dự án cụ thể → những token này sẽ nhận attention cao hơn và điều hướng output theo pattern đúng.

Đó là lý do:

Chọn lọc quan trọng hơn số lượng.

Một priming document tập trung không chỉ thêm ngữ cảnh, mà còn thay đổi thứ mà model chú ý.

Knowledge Priming trông như thế nào

Knowledge Priming là việc chia sẻ tài liệu đã chọn lọc, pattern kiến trúc và thông tin version cho AI trước khi yêu cầu nó viết code.

Hãy nghĩ nó giống như bộ tài liệu onboarding cho nhân viên mới.

Ví dụ:

• Đây là tech stack và version
• Đây là cách code được tổ chức
• Đây là quy ước đặt tên
• Đây là ví dụ code tốt trong dự án

So sánh trước và sau priming

Không có priming:

Yêu cầu tạo UserService có thể sinh ra:

• Express
• class-based code
• sai cấu trúc file
• API cũ

→ tốn 45 phút sửa hoặc viết lại

Có priming:

AI có thể sinh ra:

• Fastify
• functional pattern
• đúng file path
• API mới

→ chỉ cần 5 phút review và chỉnh sửa nhỏ

Tôi không thể khẳng định đây là kết quả đã được nghiên cứu chính thức, nhưng lý luận rất hợp lý: context cụ thể sẽ ghi đè default chung.

Các thử nghiệm cá nhân của tôi cũng rất khả quan.

Cấu trúc của một priming document

Một priming document tốt không phải là dump toàn bộ kiến thức.

Nó phải là hướng dẫn có cấu trúc và được chọn lọc, cung cấp đúng thông tin AI cần.

Tôi đề xuất 7 phần — giống với những gì tôi nói khi onboarding một lập trình viên.

1. Tổng quan kiến trúc

Điều tôi nói với nhân viên mới:

“Hãy hiểu bức tranh lớn trước.”

Loại ứng dụng gì?

Các thành phần chính?

Chúng tương tác thế nào?

Ví dụ:

Microservices e-commerce:

• API Gateway
• User Service
• Order Service
• Notification Service

Giao tiếp qua RabbitMQ.

Mỗi service có database riêng (PostgreSQL).

2. Tech stack và version

Điều tôi nói:

“Đây là stack của chúng ta — và chú ý API phụ thuộc version.”

Version rất quan trọng vì API thay đổi theo version.

Ví dụ:

• Node.js 20
• Fastify 4 (không phải Express)
• PostgreSQL 15 + Prisma 5
• JWT với httpOnly cookies
• Vitest
• Zod validation

3. Nguồn tri thức được chọn lọc

Điều tôi nói:

“Trước khi tìm trên Internet, hãy đọc những nguồn này.”

Mỗi team đều có:

• tài liệu chính thức
• blog quan trọng
• bài viết ảnh hưởng tới kiến trúc

Những nguồn này tạo nên mô hình tư duy chung của team.

4. Cấu trúc dự án

Điều tôi nói:

“File đặt ở đâu rất quan trọng.”

Ví dụ:

src/
lib/
services/
repositories/
schemas/
utils/
routes/
middleware/
types/
config/

5. Quy ước đặt tên

Consistency quan trọng hơn sở thích cá nhân.

Ví dụ:

• file: kebab-case
• function: camelCase
• type: PascalCase
• constant: SCREAMING_SNAKE_CASE
• boolean: is/has/can

6. Ví dụ code tốt

Không chỉ nói — hãy cho ví dụ.

2–3 snippet từ codebase.

7. Anti-pattern cần tránh

Nói rõ AI không được làm gì.

Ví dụ:

• không dùng class-based services
• không dùng Express
• không lưu JWT trong localStorage
• không dùng raw SQL
• không viết business logic trong route

Priming nên là hạ tầng, không phải thói quen

Cách mạnh nhất là xem priming như hạ tầng, không phải thói quen.

Thay vì copy-paste mỗi lần chat, hãy lưu priming doc trong repo.

Ví dụ:

Cursor

.cursor/rules
.cursor/commands/priming.md

GitHub Copilot

.github/copilot-instructions.md

Claude Projects

upload vào Project Knowledge

Vì sao hạ tầng tốt hơn copy-paste

• có version control
• tự động áp dụng
• toàn team dùng chung context
• thay đổi qua pull request

Điều này biến priming từ mẹo cá nhân thành hạ tầng của team.

Những sai lầm phổ biến

Một số failure mode tôi gặp:

Quá nhiều thông tin → giữ 1–3 trang

Quá mơ hồ → dùng version cụ thể

Không có ví dụ code

Nội dung lỗi thời

Không liệt kê anti-pattern

Bẫy “quá nhiều thông tin”

Priming doc không phải documentation đầy đủ.

Nó là cheat sheet cho AI.

Nếu dài hơn 3 trang, hãy tự hỏi:

AI có cần tất cả thông tin này không?

Cách giữ priming doc luôn cập nhật

Xử lý nó như code, không phải tài liệu.

• lưu trong repo
• thay đổi qua PR
• tech lead review định kỳ

Ví dụ thực tế

Một priming doc thực tế có thể chỉ 50 dòng.

Đó là mục tiêu:

ngắn gọn cụ thể hành động được

Đánh đổi và hạn chế

Cách này có chi phí:

• cần thời gian viết priming doc
• không cần thiết cho task rất nhỏ
• doc lỗi thời có thể gây hại
• AI vẫn có thể sai

Nhưng lợi ích lớn nhất là với công việc phức tạp hoặc kéo dài nhiều session.

Kết luận

Knowledge Priming về bản chất là manual RAG.

Bạn lấp đầy context window của AI bằng tri thức dự án cụ thể, từ đó ghi đè default chung của Internet.

Sự thay đổi quan trọng là:

xem context như hạ tầng (file trong repo) chứ không phải thói quen copy-paste mỗi session.

Hạ tầng thì tồn tại lâu dài.

Thói quen thì dễ biến mất.

Và đây chính là nền tảng cho mọi thứ khác.

Khi AI đã hiểu kiến trúc:

• thảo luận thiết kế hiệu quả hơn
• custom command hoạt động tốt hơn
• năng suất tăng theo cấp số nhân

Đầu tư vào priming sẽ tích lũy giá trị theo thời gian.