Context Engineering là gì? Cách giúp AI hiểu đúng dự án, lập trình hiệu quả và tiết kiệm token

Có một tình huống khá quen thuộc khi lập trình với AI.

Buổi sáng, chúng ta yêu cầu AI xây dựng chức năng đăng nhập. AI làm khá tốt. Đến chiều, tiếp tục yêu cầu bổ sung phân quyền. Mọi thứ vẫn ổn.

Ngày hôm sau, khi yêu cầu sửa một chức năng khác, AI lại đề xuất thay đổi cấu trúc database, tạo thêm bảng người dùng hoặc viết lại một phần authentication mà trước đó đã hoàn thành.

Ủa, hôm qua mình thống nhất rồi mà?

Chú Nha 27 tuổi nghĩ rằng nhiều người từng sử dụng AI để lập trình đã gặp tình huống tương tự.

Chúng ta có thể giải thích lại cho AI. Nhưng nếu mỗi lần làm việc đều phải kể lại toàn bộ lịch sử dự án, từ công nghệ đang sử dụng, quy tắc phân quyền, cấu trúc dữ liệu cho đến những quyết định đã thống nhất, thì thời gian tiết kiệm nhờ AI bắt đầu bị tiêu hao vào việc hướng dẫn lại chính AI.

Vấn đề không hẳn do prompt chưa đủ hay.

Có thể chúng ta chưa tổ chức context đúng cách.

Trong bài trước, tôi đã chia sẻ về Vibe Coding và phương pháp Human-Directed AI Coding, với tư duy con người quyết định WHY, WHAT, RULES và AI hỗ trợ thực hiện HOW.

Bài này đi sâu vào một phần rất quan trọng của quy trình ấy: Context Engineering.

Chúng ta sẽ tìm hiểu context thực sự gồm những gì, vì sao AI có thể hiểu sai dù đã được cung cấp tài liệu, cách tổ chức BRD/SRS thành Markdown, cấu hình project instructions, xây dựng task context, quản lý phiên làm việc dài và đo mức tiêu thụ token.

Tôi cũng sẽ đưa ra một cấu trúc repository mẫu cùng các prompt có thể áp dụng ngay.

1. Context Engineering là gì?

Context Engineering là quá trình thiết kế, lựa chọn, tổ chức, cung cấp và duy trì những thông tin mà AI cần để thực hiện một nhiệm vụ hiệu quả.

Nói ngắn gọn: Không chỉ hỏi AI điều gì, mà còn quyết định AI cần biết những gì trước khi trả lời hoặc hành động.

Theo tài liệu nghiên cứu về Context Engineering của Anthropic công bố ngày 29/09/2025, khái niệm này mở rộng từ Prompt Engineering sang việc quản lý toàn bộ trạng thái ngữ cảnh của mô hình, bao gồm chỉ dẫn, công cụ, dữ liệu bên ngoài và lịch sử tương tác.

Với lập trình, context có thể là:

• Mục tiêu và phạm vi dự án.
• BRD và SRS đã được phê duyệt.
• Business rules.
• Kiến trúc và quyết định kỹ thuật.
• Cấu trúc repository.
• Mã nguồn liên quan.
• Database schema và API contracts.
• Test cases và acceptance criteria.
• Lịch sử những thay đổi quan trọng.
• Chỉ dẫn hệ thống và project instructions.
• Kết quả từ công cụ tìm kiếm, terminal hoặc các công cụ tích hợp.

AI Coding Agent cần những thông tin này ở những thời điểm khác nhau.

Không phải tất cả cùng một lúc.

Đây là điểm mấu chốt.

2. Context Engineering khác Prompt Engineering như thế nào?

Hai khái niệm có liên quan nhưng không giống nhau.

Prompt Engineering

Prompt Engineering tập trung vào cách chúng ta đưa ra yêu cầu cho AI.

Ví dụ:

Hãy tạo API đăng nhập bằng ASP.NET Core.

Yêu cầu:
- Validate dữ liệu đầu vào
- Trả mã lỗi phù hợp
- Không tiết lộ mật khẩu
- Viết unit test

Đây là một prompt tương đối rõ ràng.

Nhưng AI vẫn chưa biết dự án đang sử dụng cơ chế xác thực nào, người dùng được lưu ở đâu, hệ thống phân quyền ra sao hoặc API phải tương thích với những dịch vụ nào.

Context Engineering

Với Context Engineering, chúng ta cung cấp thêm môi trường thông tin phù hợp:

Task: AUTH-001
- Implement Login API

Relevant documents: docs/auth/requirements.md docs/auth/business-rules.md docs/auth/api-contracts.md

Relevant code: backend/Controllers/AuthController.cs backend/Services/AuthService.cs backend/Repositories/UserRepository.cs

Constraints:
- Reuse existing identity model
- Preserve current API contracts
- No database migration
- No hardcoded secrets

Acceptance: AC-AUTH-001 AC-AUTH-002 AC-AUTH-003

Prompt vẫn cần thiết. Nhưng bây giờ AI còn biết phải dựa vào tài liệu nào, sửa phần nào và không được thay đổi điều gì.

Có thể diễn đạt đơn giản:

• Prompt Engineering: Cách chúng ta giao việc.
• Context Engineering: Cách chúng ta chuẩn bị và quản lý những thông tin cần thiết để AI làm đúng việc.

Một prompt rất hay không thể tự bổ sung những thông tin nghiệp vụ mà chúng ta chưa cung cấp.

3. Context Window là gì? Vì sao context dài chưa chắc tốt?

Context Window là giới hạn lượng thông tin mà mô hình có thể xử lý trong một lần suy luận, thường được đo bằng token.

Token không hoàn toàn tương đương với từ hoặc ký tự. Mã nguồn, tiếng Việt, dấu câu và những định dạng dữ liệu khác nhau có thể được tách thành số token khác nhau.

Mỗi mô hình và nền tảng có giới hạn context riêng. Khả năng sử dụng context cũng phụ thuộc vào cấu hình, công cụ và cơ chế quản lý phiên làm việc.

Giới hạn lớn không có nghĩa rằng chúng ta nên đưa vào càng nhiều tài liệu càng tốt.

Hãy hình dung một nhân viên mới nhận nhiệm vụ sửa lỗi thanh toán.

Chúng ta đưa cho người ấy toàn bộ tài liệu nhân sự, marketing, quản lý kho, bán hàng, CRM và lịch sử họp của công ty trong ba năm.

Nghe có vẻ đầy đủ. Nhưng tìm đúng quy tắc thanh toán giữa hàng nghìn trang tài liệu chưa chắc dễ hơn việc được cung cấp một bộ tài liệu ngắn, chính xác và có liên kết đến phần cần đọc thêm.

AI cũng có thể gặp những vấn đề tương tự.

Context quá dài hoặc chứa nhiều thông tin không liên quan có thể làm tăng chi phí, gây nhiễu và khiến việc xác định chỉ dẫn nào quan trọng trở nên khó khăn.

Vì vậy, Context Engineering cần cân bằng giữa ba yếu tố:

• Đủ: Không thiếu thông tin cần thiết để thực hiện nhiệm vụ.
• Đúng: Thông tin có nguồn, còn hiệu lực và phù hợp với yêu cầu.
• Gọn: Hạn chế lặp lại và tránh đưa vào những nội dung không liên quan.

Gọn không có nghĩa là cắt bỏ những ngoại lệ nghiệp vụ quan trọng chỉ để tiết kiệm token.

4. Năm lớp context cần có trong một dự án lập trình

Tôi đề xuất tổ chức context thành năm lớp để dễ quản lý.

Lớp 1 - Project Context

Đây là những thông tin nền tảng của dự án:

• Dự án giải quyết vấn đề gì?
• Ai là người sử dụng?
• Phạm vi sản phẩm?
• Những module chính?
• Kiến trúc công nghệ?
• Những hệ thống liên quan?

Thông tin này thường ít thay đổi và có thể được lưu tại README.md, project-overview.md và architecture.md.

Lớp 2 - Business Context

Đây là phần quyết định sản phẩm có làm đúng nghiệp vụ hay không.

Bao gồm BRD, SRS, business rules, phân quyền, trạng thái dữ liệu, trường hợp ngoại lệ và acceptance criteria.

Ví dụ, phần mềm quản lý bán hàng cần biết đơn hàng đã thanh toán có được sửa hay không, hoàn tiền cần quyền gì và cách tính giảm giá như thế nào.

Nếu thiếu lớp này, AI có thể viết code đúng cú pháp nhưng xử lý sai nghiệp vụ.

Lớp 3 - Technical Context

Bao gồm:

• Ngôn ngữ lập trình và framework.
• Phiên bản runtime.
• Database schema.
• API contracts.
• Coding conventions.
• Testing conventions.
• Cấu trúc thư mục.
• Những quyết định kiến trúc đã phê duyệt.

Đây là cơ sở để AI triển khai phù hợp với hệ thống thay vì tự tạo một cách làm mới không cần thiết.

Lớp 4 - Task Context

Đây là những thông tin phục vụ nhiệm vụ hiện tại.

Ví dụ:

• Task ID.
• Mục tiêu.
• Yêu cầu liên quan.
• Business rules.
• Các file mã nguồn cần xem.
• Phạm vi được phép thay đổi.
• Tiêu chí nghiệm thu.
• Test cần thực hiện.

Task Context thường thay đổi liên tục theo công việc.

Lớp 5 - Runtime Context

Đây là những thông tin phát sinh trong lúc AI đang làm việc:

• Kết quả tìm kiếm mã nguồn.
• Log từ terminal.
• Kết quả build và test.
• Lỗi xuất hiện trong quá trình chạy.
• Diff của những file vừa chỉnh sửa.
• Những quyết định mới được con người phê duyệt.

Lớp này thường dễ phát sinh nhiều token vì một lệnh chạy test có thể trả về hàng nghìn dòng log.

Do đó, không nên giữ mọi kết quả trung gian mãi trong context. Cần bảo toàn lỗi quan trọng, bằng chứng kiểm thử và trạng thái công việc, đồng thời loại bỏ những phần log không còn giá trị.

5. Tổ chức repository để AI tìm đúng tài liệu

Để thực hành, chúng ta sử dụng ví dụ một ứng dụng quản lý công việc có frontend Next.js, backend ASP.NET Core và database SQL Server.

Cấu trúc tham khảo:

task-management/
|
+-- README.md
+-- AGENTS.md
+-- .env.example
+-- .gitignore
|
+-- docs/
|
+-- INDEX.md
|
+-- project/ |
|
+-- vision.md |
|
+-- brd.md |
|
+-- architecture.md |   |
|
+-- modules/ |
|
+-- auth/ |   |
|
+-- srs.md |   |
|
+-- rules.md |   |
|
+-- api.md |   |   | |
|
+-- tasks/ |
|
+-- srs.md |
|
+-- rules.md |
|
+-- data-model.md |
|
+-- api.md |   |
|
+-- decisions/ |
|
+-- ADR-001.md |   |
|
+-- security/
|
+-- authorization.md
|
+-- tasks/
|
+-- AUTH-001.md
|
+-- TASK-001.md
|
+-- frontend/
+-- backend/
+-- tests/

Đây là cấu trúc gợi ý, không phải tiêu chuẩn bắt buộc.

Điều cần chú ý là tài liệu được chia theo phạm vi. Khi làm authentication, AI có thể bắt đầu với docs/modules/auth. Khi làm quản lý công việc, AI ưu tiên docs/modules/tasks.

Nếu hai module có phụ thuộc vào nhau, task phải tham chiếu cả tài liệu liên quan thay vì cố tình giới hạn context đến mức thiếu thông tin.

6. Tạo docs/INDEX.md để AI biết nên đọc gì

Một ý tưởng đơn giản nhưng hữu ích là tạo file INDEX.md trong thư mục docs.

File này không chứa toàn bộ yêu cầu. Nó đóng vai trò bản đồ tài liệu.

# Documentation Index

## Project
- project/vision.md

Purpose and business objectives
- project/brd.md

Approved business requirements
- project/architecture.md

System architecture and constraints

## Authentication
- modules/auth/srs.md

Authentication requirements
- modules/auth/rules.md

Authentication business rules
- modules/auth/api.md

API contracts

## Task
Management
- modules/tasks/srs.md

Task management requirements
- modules/tasks/rules.md

Task management rules
- modules/tasks/data-model.md

Database entities and constraints
- modules/tasks/api.md

API contracts

## Security
- security/authorization.md

Authorization policies

## Architecture
Decisions
- decisions/

Approved architecture decisions

## Reading
Rules
1. Read the current task.
2. Identify required documents.
3. Read only relevant sections initially.
4. Expand context when dependencies require it.
5. Report missing or conflicting information.

Như vậy, AI có thể tìm tài liệu theo nhiệm vụ thay vì nạp toàn bộ thư mục docs.

Tuy nhiên, file INDEX.md phải được cập nhật khi cấu trúc dự án thay đổi. Một bản đồ chỉ sai đường còn gây phiền hơn việc không có bản đồ.

7. Chuẩn hóa BRD và SRS để AI sử dụng hiệu quả

Trong bài Vibe Coding trước, chúng ta đã thống nhất rằng AI có thể hỗ trợ con người nghiên cứu WHAT, WHY và RULES, sau đó xuất tài liệu Markdown.

Ở bước này, cần làm thêm một việc: biến tài liệu thành những yêu cầu có thể tham chiếu và kiểm chứng.

Ví dụ, một mục trong SRS:

# TASK-FR-001: Create Task

Status: Approved Version: 1.0 Module: Task Management

## Requirement
Authorized users can create tasks.

## Inputs
- Title
- Description
- Assignee
- Due Date
- Priority

## Business
Rules
- BR-TASK-001
- BR-TASK-002
- BR-AUTH-003

## Acceptance
Criteria

AC-TASK-001: Valid input creates a task.

AC-TASK-002: Empty title is rejected.

AC-TASK-003: Unauthorized requests are rejected.

AC-TASK-004: Failed transactions do not leave partially committed task data.

AC-TASK-005: Task creation is recorded in the audit history.

## Dependencies
- Authentication module
- Authorization policy

## Open
Questions None

Mã định danh giúp liên kết yêu cầu với business rules, nhiệm vụ triển khai và test cases.

Thay vì nói "Hãy làm đúng phần quản lý công việc", chúng ta có thể yêu cầu "Triển khai TASK-FR-001 và bảo đảm AC-TASK-001 đến AC-TASK-005".

Cách làm này giúp giảm sự mơ hồ, nhưng cũng cần chú ý không tạo quá nhiều mã định danh nếu dự án chỉ có vài chức năng đơn giản.

8. AGENTS.md, CLAUDE.md và Copilot Instructions khác nhau thế nào?

Không phải công cụ AI Coding nào cũng sử dụng cùng một cơ chế đọc chỉ dẫn.

Một số định dạng thông dụng:

• AGENTS.md: File hướng dẫn dành cho coding agents được nhiều công cụ hỗ trợ, trong đó có các cơ chế của OpenAI Codex.
• CLAUDE.md: File hướng dẫn dự án được Claude Code sử dụng.
• .github/copilot-instructions.md: Chỉ dẫn chung của repository dành cho những tính năng GitHub Copilot hỗ trợ.
• .github/instructions/*.instructions.md: Chỉ dẫn áp dụng theo đường dẫn hoặc nhóm file trong các môi trường Copilot tương thích.

Phạm vi và cách nạp tài liệu còn phụ thuộc vào từng phiên bản, môi trường chạy và tính năng đang sử dụng.

Vì vậy, đừng mặc định rằng tạo AGENTS.md thì mọi công cụ đều tự đọc hoặc tự động áp dụng đúng.

Nên tổ chức như thế nào khi sử dụng nhiều công cụ?

Tôi đề xuất một nguyên tắc: Giữ tài liệu nghiệp vụ và kiến trúc tại một nơi thống nhất, sau đó tạo chỉ dẫn ngắn phù hợp cho từng công cụ.

Ví dụ:

repository/
|
+-- AGENTS.md
+-- CLAUDE.md
|
+-- .github/
|
+-- copilot-instructions.md
|
+-- docs/
|
+-- INDEX.md
|
+-- project/
|
+-- modules/
|
+-- security/

Các file hướng dẫn nên trỏ đến cùng một nguồn tài liệu đã được phê duyệt thay vì sao chép toàn bộ business rules vào nhiều nơi.

Lưu ý rằng một đường dẫn được ghi trong Markdown không bảo đảm công cụ sẽ tự động mở file đó. Cần xác nhận cơ chế tham chiếu và nạp file thực tế của công cụ.

Mẫu AGENTS.md ngắn gọn

# Agent Instructions

## Mission
Implement approved requirements safely.

## Source of
Truth
- docs/INDEX.md
- Approved module requirements
- Approved business rules
- Current repository code

## Working
Process
1. Read task specification.
2. Identify relevant documentation.
3. Inspect related source files.
4. Identify assumptions and conflicts.
5. Propose implementation plan.
6. Implement within approved scope.
7. Run relevant tests.
8. Report evidence and limitations.

## Rules
- Never invent business rules.
- Never bypass authorization.
- Never hardcode secrets.
- Never change production directly.
- Never run destructive operations

without explicit approval.
- Never expand scope silently.
- Preserve existing API contracts

unless a change is approved.

## Verification
- Check acceptance criteria.
- Run applicable tests.
- Review code changes.
- Report unexecuted tests.

## Output
- Summary
- Changed files
- Test evidence
- Risks
- Open questions

Không nên biến AGENTS.md thành một tài liệu dài chứa toàn bộ SRS.

Hãy giữ những quy tắc ổn định, áp dụng thường xuyên ở đây. Phần kiến thức chuyên sâu theo module nên nằm trong docs.

9. Task Context: Mỗi lần giao việc, AI cần biết những gì?

Nếu có một thói quen đáng duy trì khi sử dụng AI Coding, tôi chọn việc tạo task rõ ràng trước khi yêu cầu sửa code.

Một file task có thể như sau:

# TASK-001: Create Task API

## Status
Ready for Implementation

## Objective
Implement task creation endpoint.

## Requirements
- TASK-FR-001

## Business
Rules
- BR-TASK-001
- BR-TASK-002
- BR-AUTH-003

## Relevant
Documents
- docs/modules/tasks/srs.md
- docs/modules/tasks/rules.md
- docs/modules/tasks/api.md
- docs/security/authorization.md

## Scope
- API endpoint
- Application service
- Repository changes if required
- Automated tests

## Out of
Scope
- Reporting
- Notifications
- UI redesign

## Acceptance
Criteria
- AC-TASK-001
- AC-TASK-002
- AC-TASK-003
- AC-TASK-004
- AC-TASK-005

## Constraints
- Do not change existing API contracts

without approval.
- Do not access production.
- Do not add dependencies unnecessarily.

## Definition of
Done
- Acceptance criteria verified.
- Tests executed and reported.
- Security reviewed.
- Documentation updated if needed.

Nhìn vào file này, AI biết mình được giao gì, phải tuân thủ những gì và khi nào được xem là hoàn thành.

Đặc biệt, mục Out of Scope rất hữu ích. Nó giúp làm rõ những việc không nên thực hiện trong task hiện tại.

10. Prompt thực hành: Cho AI đọc đúng context trước khi lập trình

Sau khi đã có tài liệu và task, chúng ta không cần một prompt quá dài.

Bạn là AI Coding Agent của dự án.

Task hiện tại: tasks/TASK-001.md

Hãy thực hiện giai đoạn phân tích.
1. Đọc project instructions.
2. Đọc task specification.
3. Đọc docs/INDEX.md.
4. Chỉ đọc các tài liệu cần thiết

cho task và dependency của task.
5. Kiểm tra mã nguồn hiện tại.
6. Xác định những điểm chưa rõ.
7. Đối chiếu acceptance criteria.

Chưa chỉnh sửa code.

Hãy trả về:
- Requirement summary
- Relevant documents
- Relevant source files
- Implementation plan
- Risks and assumptions
- Questions requiring approval
- Proposed tests

Không tự quyết định các business rules chưa được phê duyệt.

Sau khi kiểm tra kế hoạch, chúng ta mới cho phép AI triển khai.

Implementation plan đã được duyệt cho TASK-001.

Hãy triển khai đúng phạm vi.

Yêu cầu:
- Tuân thủ business rules.
- Không chỉnh sửa module không liên quan.
- Không thay đổi API contract.
- Viết test cho hành vi thay đổi.
- Chạy các bước kiểm tra phù hợp.
- Báo cáo kết quả thực tế.

Nếu phát hiện yêu cầu mâu thuẫn, dừng phần bị ảnh hưởng và báo lại.

Không tự sửa yêu cầu nghiệp vụ để làm cho code chạy được.

Cách làm này không bảo đảm AI sẽ không mắc lỗi. Nhưng nó tạo ra những điểm kiểm soát rõ ràng để phát hiện sai lệch sớm hơn.

11. Quản lý context khi dự án kéo dài nhiều phiên làm việc

Một dự án thực tế có thể kéo dài nhiều tuần hoặc nhiều tháng. Không thể kỳ vọng mọi thông tin quan trọng chỉ tồn tại trong một cuộc trò chuyện.

Thậm chí, trong một phiên dài, công cụ có thể phải rút gọn lịch sử để tiếp tục hoạt động.

Vì vậy, cần phân biệt hai loại thông tin.

Thông tin cần lưu lâu dài

• Yêu cầu được phê duyệt.
• Business rules.
• Quyết định kiến trúc.
• API contracts.
• Trạng thái các task.
• Những lỗi và rủi ro chưa xử lý.
• Quy tắc kỹ thuật được áp dụng lâu dài.

Những thông tin này nên nằm trong repository hoặc hệ thống quản lý công việc đáng tin cậy.

Thông tin chỉ phục vụ phiên hiện tại

• Những lần thử code chưa thành công.
• Log tạm thời.
• Kết quả tìm kiếm trung gian.
• Những phương án đã bị loại bỏ.
• Chi tiết trao đổi không ảnh hưởng đến quyết định cuối cùng.

Không cần lưu lại toàn bộ dưới dạng tài liệu dự án.

Tạo file handoff khi kết thúc phiên

Với những task dài, có thể duy trì một file handoff để phiên tiếp theo tiếp tục làm việc.

# Session Handoff

Task: TASK-001 Date: YYYY-MM-DD

## Approved
Scope Implement Create Task API.

## Completed
- Request validation
- Service implementation
- Basic unit tests

## Files
Changed
- backend/...
- tests/...

## Verification
- Build: Passed
- Unit tests: 12 passed
- Integration tests: Not run

## Pending
- Authorization integration test
- Review transaction handling

## Known
Risks
- Concurrent updates not reviewed

## Next
Action Complete integration tests and review.

## Important
Do not change approved business rules.

Những kết quả trong ví dụ trên chỉ là dữ liệu minh họa. Khi sử dụng thực tế, phải ghi theo log và kết quả thật.

File handoff nên ngắn, có cấu trúc và được cập nhật sau mỗi giai đoạn quan trọng.

Không nên để nhiều file handoff cũ cùng tuyên bố những trạng thái khác nhau. Cần có một nguồn trạng thái hiện hành rõ ràng.

12. Khi nào nên dùng RAG, tìm kiếm ngữ nghĩa hoặc Vector Database?

Đây là một câu hỏi mà nhiều người làm hệ thống AI thường gặp.

Nếu dự án có hàng nghìn tài liệu, có nên đưa tất cả vào Vector Database rồi cho Coding Agent tìm kiếm không?

Câu trả lời là tùy nhu cầu.

Với repository nhỏ hoặc vừa, hệ thống file, Git, tìm kiếm theo tên file, tìm kiếm toàn văn và các công cụ phân tích mã nguồn có thể đã đủ hiệu quả.

Không nhất thiết phải triển khai RAG chỉ để đọc vài chục file Markdown.

RAG (Retrieval-Augmented Generation) hữu ích khi cần truy xuất thông tin liên quan từ một kho dữ liệu lớn trước khi cung cấp cho mô hình.

Một số tình huống đáng xem xét:

• Kho tài liệu quá lớn để tìm thủ công.
• Có nhiều tài liệu không có cấu trúc thống nhất.
• Cần tìm thông tin theo ý nghĩa, không chỉ từ khóa.
• Thông tin nằm ở nhiều hệ thống khác nhau.
• Cần truy xuất nguồn và phiên bản tài liệu.

Tuy nhiên, tìm kiếm ngữ nghĩa có thể trả về những đoạn nội dung gần giống về ý nghĩa nhưng không phải quy tắc đang có hiệu lực.

Ví dụ, một chính sách giảm giá cũ có thể rất giống chính sách mới. Nếu AI lấy nhầm phiên bản, kết quả có thể sai.

Vì vậy, hệ thống truy xuất cần quản lý phiên bản, trạng thái phê duyệt, phạm vi quyền truy cập và nguồn của tài liệu.

Với dữ liệu mã nguồn, nên cân nhắc kết hợp tìm kiếm theo tên symbol, đường dẫn, từ khóa chính xác và quan hệ phụ thuộc, thay vì chỉ dựa vào vector similarity.

Tóm lại, hãy bắt đầu từ giải pháp đơn giản nhất đáp ứng nhu cầu. Khi khối lượng tài liệu và yêu cầu truy xuất tăng lên, lúc đó mới đánh giá việc bổ sung RAG.

13. Tối ưu token: Những việc nên làm trước tiên

Tiết kiệm token là một mục tiêu hợp lý, nhất là khi nhóm phát triển sử dụng AI Coding thường xuyên.

Nhưng cần tối ưu đúng chỗ.

Thứ nhất: Không đưa toàn bộ lịch sử chat vào mỗi task

Hãy chuyển các quyết định đã được duyệt vào tài liệu chính thức.

Những đoạn tranh luận, phương án cũ và các quyết định đã bị thay thế không nên được coi là yêu cầu đang có hiệu lực.

Thứ hai: Chia tài liệu theo module

Không bắt mọi task đọc toàn bộ BRD/SRS nếu chỉ một phần liên quan.

Nhưng khi nhiệm vụ có phụ thuộc xuyên module, cần bổ sung đúng những tài liệu liên quan.

Thứ ba: Giữ project instructions ngắn và ổn định

AGENTS.md hoặc CLAUDE.md nên tập trung vào nguyên tắc áp dụng nhiều lần.

Không lặp lại toàn bộ yêu cầu chi tiết của từng module trong file hướng dẫn gốc.

Thứ tư: Giảm log không cần thiết

Khi chạy test hoặc build, hãy yêu cầu agent giữ lại thông tin lỗi, kết quả kiểm tra và bằng chứng có giá trị.

Không cần đưa hàng nghìn dòng log thành công vào mọi lượt suy luận tiếp theo.

Tuy nhiên, bản log đầy đủ vẫn có thể được lưu riêng để phục vụ kiểm tra và truy vết.

Thứ năm: Sử dụng đúng khả năng của công cụ

Một số nền tảng hỗ trợ prompt caching, compaction, file references hoặc các cơ chế quản lý context khác nhau.

Hãy kiểm tra tài liệu và cấu hình của công cụ đang sử dụng. Không nên mặc định mọi mô hình đều có cùng cơ chế hoặc cách tính chi phí.

Thứ sáu: Tạo bộ test để giảm vòng lặp sửa sai

Một task ít token nhưng liên tục tạo lỗi sẽ không thật sự tiết kiệm.

Test tốt giúp agent phát hiện sai lệch và có bằng chứng rõ ràng để sửa đúng vấn đề.

14. Đo hiệu quả Context Engineering bằng một thử nghiệm nhỏ

Thay vì chỉ cảm nhận AI hoạt động tốt hơn, chúng ta có thể thử nghiệm.

Chọn một nhóm task có độ khó tương đương, chẳng hạn các chức năng CRUD, phân quyền hoặc báo cáo đơn giản.

Chia thành hai nhóm:

• Nhóm A: AI nhận prompt thông thường và tự tìm hiểu dự án.
• Nhóm B: AI nhận task có cấu trúc, tài liệu theo module, business rules và acceptance criteria rõ ràng.

Nên sử dụng cùng mô hình, cấu hình, công cụ và điều kiện kiểm thử. Nếu có thể, hoán đổi thứ tự thực hiện và lặp lại trên nhiều task để giảm ảnh hưởng của độ khó hoặc biến động kết quả.

Theo dõi những chỉ số sau:

• Tổng input tokens.
• Tổng output tokens.
• Cached tokens, nếu có.
• Chi phí thực tế.
• Thời gian hoàn thành.
• Số vòng sửa lỗi.
• Tỷ lệ acceptance criteria đạt.
• Số lỗi phát hiện trong review.
• Số thay đổi ngoài phạm vi.

Ví dụ bảng ghi nhận:

Task ID: Method: A or B Model: Model Version: Agent Tool: Input Tokens: Output Tokens: Cached Tokens: Total Cost: Duration: Correction Rounds: Acceptance Passed: Review Findings: Out-of-Scope Changes: Notes:

Không nên chỉ cộng input và output tokens rồi xem đó là chi phí cuối cùng. Giá sử dụng có thể khác nhau theo mô hình, loại token, cache và công cụ.

Cũng cần nhớ rằng kết quả một vài task chưa đủ để kết luận phương pháp nào luôn tốt hơn.

Mục tiêu của thử nghiệm không phải chứng minh Context Engineering có thể giảm một tỷ lệ token cố định, mà là tìm cách tổ chức thông tin phù hợp nhất với dự án và công cụ chúng ta đang sử dụng.

15. Những sai lầm thường gặp khi tổ chức context

Viết một file AGENTS.md thật dài rồi nghĩ rằng đã xong

Một file dài không thay thế được BRD, SRS, business rules và task specification.

Project instructions nên chỉ dẫn cách làm việc, không trở thành nơi chứa mọi kiến thức của dự án.

Nhân bản business rules vào nhiều file

Nếu cùng một quy tắc được sao chép vào năm file, đến khi thay đổi chúng ta rất dễ chỉ sửa bốn file.

Hãy chọn nguồn tài liệu chính thức và tham chiếu bằng mã định danh.

Để AI tự tạo tài liệu rồi tự phê duyệt

AI có thể chuẩn hóa yêu cầu rất tốt, nhưng vẫn có thể hiểu sai nghiệp vụ.

Quyết định quan trọng cần có con người kiểm tra và phê duyệt.

Tài liệu đã lỗi thời

Một file SRS rất đầy đủ nhưng mô tả phiên bản cũ có thể khiến AI triển khai sai.

Cần quản lý trạng thái và phiên bản tài liệu, nhất là những nội dung liên quan đến dữ liệu và phân quyền.

Chỉ đưa tài liệu mà không kiểm tra mã nguồn hiện tại

Tài liệu mô tả hành vi mong muốn, nhưng mã nguồn cho biết hệ thống đang hoạt động như thế nào.

Với dự án đang vận hành, AI phải đối chiếu cả hai. Khi phát hiện mâu thuẫn, cần báo lại thay vì tự chọn một bên.

Quá phụ thuộc vào tóm tắt của AI

Một bản tóm tắt có thể bỏ sót điều kiện ngoại lệ hoặc chi tiết quan trọng.

Với các quy tắc liên quan đến tài chính, phân quyền, dữ liệu cá nhân hoặc thay đổi không thể khôi phục dễ dàng, nên đọc lại nguồn chính thức.

Nhầm tài liệu tham khảo với chỉ dẫn có thẩm quyền

Một file README từ thư viện bên ngoài hoặc kết quả tìm kiếm không được phép tự thay đổi quy tắc của dự án.

Agent cần phân biệt nguồn thông tin, mức độ tin cậy và quyền hạn của từng loại chỉ dẫn để giảm nguy cơ prompt injection.

16. Checklist Context Engineering cho mỗi dự án

Trước khi giao việc cho AI Coding Agent, hãy kiểm tra:

• Đã có project overview chưa?
• Đã xác định tài liệu nào là nguồn chính thức chưa?
• BRD/SRS có trạng thái phê duyệt rõ ràng không?
• Business rules có mã định danh không?
• Task có acceptance criteria cụ thể không?
• Có danh sách tài liệu liên quan đến task không?
• AI đã kiểm tra mã nguồn hiện tại chưa?
• Project instructions có ngắn gọn và chính xác không?
• Những thông tin nhạy cảm đã được bảo vệ chưa?
• Quyền của agent đã được giới hạn phù hợp chưa?
• Có cơ chế kiểm thử và review không?
• Có nơi lưu quyết định và trạng thái công việc để sử dụng ở phiên sau không?

Sau khi task hoàn thành, nên kiểm tra thêm:

• Những quyết định mới đã được cập nhật vào tài liệu chưa?
• Có thay đổi nào làm tài liệu cũ mất hiệu lực không?
• Test và acceptance criteria có được cập nhật không?
• Có lỗi nào cần bổ sung thành quy tắc chung không?
• Task đã có báo cáo kết quả và phần việc còn lại chưa?

17. Kết luận: Đừng bắt AI nhớ mọi thứ, hãy tổ chức để AI tìm đúng thứ cần biết

Ngày trước, khi một lập trình viên mới tham gia dự án, chúng ta thường phải hướng dẫn cấu trúc hệ thống, giải thích nghiệp vụ và chỉ ra những phần mã nguồn quan trọng.

AI Coding Agent cũng cần một quá trình tiếp nhận thông tin tương tự, dù cách đọc và xử lý thông tin có khác con người.

Với chú Nha 27 tuổi, Context Engineering không phải một kỹ thuật cao siêu đòi hỏi phải xây dựng ngay một hệ thống RAG hay Vector Database phức tạp.

Chúng ta có thể bắt đầu bằng những việc rất đơn giản: viết rõ yêu cầu, quản lý tài liệu Markdown, tạo bản đồ tài liệu, sử dụng mã định danh cho business rules và chuẩn bị task trước khi giao cho AI.

Sau đó mới bổ sung những công cụ cần thiết khi dự án lớn lên.

Context Engineering cũng không thay thế tư duy của người phát triển phần mềm. Nó giúp các quyết định đã được suy nghĩ kỹ có thể được truyền đạt nhất quán hơn đến AI.

Con người vẫn quyết định WHY, WHAT và RULES. AI có thể giúp nghiên cứu, viết tài liệu và thực hiện HOW. Nhưng giữa hai phần ấy cần có một chiếc cầu: thông tin được tổ chức đúng, có nguồn, có phiên bản và có thể kiểm chứng.

Một dự án được chuẩn bị tốt không cần giải thích lại mọi chuyện từ đầu mỗi khi mở một cuộc trò chuyện mới.

Đó là điều tôi thấy đáng đầu tư.

Tiết kiệm token là một lợi ích có thể đo lường. Tiết kiệm thời gian sửa sai còn đáng giá hơn. Và quan trọng nhất, người phát triển phần mềm có thể dành nhiều thời gian hơn để suy nghĩ về sản phẩm và những vấn đề thật sự cần giải quyết.

Ở bài tiếp theo, chúng ta sẽ thực hành sâu hơn với AGENTS.md: cách thiết kế bộ quy tắc cho AI Coding Agent, cấu hình theo từng công cụ và tổ chức những quy tắc đủ chặt chẽ mà không biến file hướng dẫn thành một cuốn sách quá dài.

Nguồn tham khảo

• Anthropic - Effective Context Engineering for AI Agents
• Anthropic - Give Claude Context: CLAUDE.md and Better Prompts
• Anthropic - Steering Claude Code
• GitHub - Custom Instructions for GitHub Copilot
• Visual Studio Code - Custom Instructions Reference
• AGENTS.md - Instructions for Coding Agents
• CommonMark - Markdown Specification