Prompt Engineering Với Claude Code Cho Developer

Sau đây là câu chuyện thường gặp khi áp dụng Prompt Engineering: Hai developer trong cùng dự án được giao một task giống nhau — viết API cho tính năng “Đăng ký sự kiện”. Vấn đề xảy ra khi cả hai đều dùng Claude Code.

• Người thứ nhất gõ một dòng, mất chưa đầy 10 giây, rồi bấm Enter.
• Người thứ hai dành thêm vài phút viết rõ vai trò, ngữ cảnh dự án và ràng buộc nghiệp vụ trước khi giao task.

Tuy nhiên, kết quả lại khác nhau hoàn toàn.

• Người thứ nhất nhận được code chạy được, nhưng sai convention, thiếu validate, thiếu test. Vì vậy phải sửa lại gần như từ đầu.
• Ngược lại, người thứ hai nhận được một pull request sạch: đúng cấu trúc, đúng convention, có test, có migration.

Ta dễ dàng thấy sự khác biệt không nằm ở việc “ai viết prompt hay hơn”, mà là sự khác nhau trong cách đưa ra yêu cầu ban đầu cho AI thực hiện. Người thứ hai đã chuẩn bị sẵn ngữ cảnh (context), ràng buộc (constraint) và quy trình làm việc rõ ràng cho AI, trong khi người thứ nhất chỉ gõ một câu lệnh rồi chờ kết quả.

Thực tế là phần lớn developer hiện nay mới chỉ dùng được một phần rất nhỏ và thường hay ngộ nhận việc viết prompt hay là có thể giải quyết được 90% yêu cầu, còn lại là tùy vào sự “thông minh” của AI. Đó là một hiểu lầm tai hại có thể khiến chúng ta tốn rất nhiều thời gian, công sức để chỉnh sửa, làm mới, cải tiến hệ thống để đáp ứng đúng yêu cầu ban đầu.

Vậy bản chất thật của Prompt Engineering là gì, chúng ta hãy cùng tìm hiểu tiếp.

1. Developer đang hiểu sai Prompt Engineering như thế nào?

Nhiều người nghĩ Prompt Engineering là kỹ năng viết câu lệnh sao cho “hay” để AI trả lời đúng ý. Từ đó có rất nhiều bài viết mang nội dung như “50 prompt thần thánh cho developer”.

Tuy nhiên, cách hiểu này chỉ đúng khi bạn hỏi một câu và nhận một câu trả lời — giống việc tìm kiếm trên Google. Cách làm như vậy không đủ khi AI tham gia vào cả một quy trình làm phần mềm: đọc yêu cầu, thiết kế database, viết code, viết testcase và review.

Ví dụ thực tế: Một bạn developer junior đưa cho AI prompt “Viết function xử lý thanh toán”. AI viết ra một function không sai cú pháp, nhưng sai nghiệp vụ: không xử lý được trường hợp bấm nút hai lần, không dùng transaction, không theo pattern repository mà dự án đang dùng.

Thực ra, bạn ấy không sai vì viết tiếng prompt “dở”. Bạn ấy sai vì coi AI như máy tra cứu, thay vì cung cấp bối cảnh cho AI hiểu dự án.

Vấn đề gốc: Developer đang cố tối ưu câu chữ trong prompt, trong khi thứ thật sự cần tối ưu là toàn bộ thông tin xung quanh câu chữ đó.

2. Prompt chỉ là 10% của bài toán

AI không “hiểu” dự án của bạn như một con người. Nó chỉ dựa vào những gì có trong ngữ cảnh (context) tại thời điểm đó, mà prompt chỉ là một phần nhỏ trong đó.

7 lớp thông tin trong một phiên làm việc với AI

Một phiên làm việc với AI thường có 7 lớp thông tin:

Prompt là dòng lệnh bạn gõ, nhưng AI luôn trả lời dựa trên cả 7 lớp trên dù bạn có để ý hay không. Nếu không chuẩn bị 6 lớp còn lại, AI sẽ tự đoán — và thường đoán theo hướng chung nhất, không đúng với dự án cụ thể của bạn.

Do đó, đây là lý do vì sao hai developer dùng cùng một AI, cùng một task, lại ra hai kết quả khác nhau như trong ví dụ mở đầu.

3. Context mới là “vũ khí mạnh nhất”

Để thấy rõ, hãy so sánh hai cách yêu cầu cùng một việc.

Developer A — chỉ có prompt:

Viết API đăng ký sự kiện

Developer B — prompt kèm context:

Role: Bạn là Senior Backend Developer, đang làm Event Platform bằng Laravel 10 + MySQL.

Context:
- Đã có model Event, User, EventRegistration
- Team dùng pattern: Controller -> Service -> Repository
- Validate bằng Form Request, không validate trong Controller
- Response trả về qua API Resource

Task:
Viết API POST /api/events/{id}/register để user đăng ký sự kiện.

Constraints:
- Không cho đăng ký nếu đã đủ số lượng (event.max_attendees)
- Không cho đăng ký trùng (user_id + event_id là duy nhất)
- Lỗi trả về theo format: {"error": {"code", "message"}}

Output: Controller, Service, Form Request, migration nếu cần và 3 test case: đăng ký thành công, hết chỗ, đăng ký trùng.

So sánh kết quả hai cách viết prompt

Hai prompt này cho ra kết quả rất khác nhau:

Thực chất, AI vẫn là cùng một model. Thứ thay đổi là lượng thông tin thật mà AI có để làm việc. Đó chính là Context Engineering — sẽ nói chi tiết hơn ở phần 5.

4. Prompt Engineering gồm những gì?

Một prompt tốt thường có 7 phần. Không phải yêu cầu nào cũng cần đủ cả 7, nhưng biết rõ từng phần giúp bạn chủ động chọn cái gì cần dùng.

• Role: AI đóng vai gì — Senior Backend Developer, Code Reviewer, hay System Architect. Vai trò khác nhau, AI ưu tiên khác nhau.
• Goal: mục tiêu cuối cùng, không chỉ là hành động. Ví dụ “đảm bảo không bị trừ tiền hai lần” rõ hơn nhiều so với “viết function thanh toán”.
• Constraints: giới hạn kỹ thuật hoặc nghiệp vụ — version, pattern bắt buộc, chỗ không được sửa.
• Input: dữ liệu, schema, đoạn code có sẵn AI cần đọc trước.
• Output: định dạng kết quả — chỉ code hay có giải thích, có test hay không.
• Examples: ví dụ mẫu, rất hữu ích khi convention của team khác với chuẩn phổ biến trên mạng.
• Evaluation: tiêu chí để biết kết quả đạt hay chưa — coverage test tối thiểu, thời gian phản hồi API.

5. Context Engineering — phần quan trọng nhất

Nếu prompt là câu bạn nói trong một cuộc trò chuyện, thì Context Engineering là việc chuẩn bị sẵn “hồ sơ nền” để AI hiểu bối cảnh dự án mà không cần giải thích lại mỗi lần. Đây là trụ cột quan trọng nhất trong Prompt Engineering mà nhiều developer bỏ qua. Tài liệu chính thức của Claude Code gọi đây là “Memory” — cơ chế giúp Claude giữ ngữ cảnh xuyên suốt qua nhiều phiên làm việc.

Các cơ chế lưu context của Claude Code

Claude Code có nhiều cơ chế để lưu và nạp context cho từng repo:

Ví dụ thực tế: file CLAUDE.md

Cho một file CLAUDE.md của dự án Laravel + Vue:

# CLAUDE.md

## Kiến trúc
- Backend: Laravel 10, pattern Controller -> Service -> Repository
- Frontend: Vue 3 + Pinia
- Database: MySQL, migration bắt buộc có rollback

## Quy tắc bắt buộc
- Không viết logic nghiệp vụ trong Controller
- Mọi API phải có Form Request để validate
- Response luôn qua API Resource, không trả raw Model
- Service class mới bắt buộc có test

## Lệnh thường dùng
- Test: `php artisan test`
- Lint: `./vendor/bin/pint`

## Không được làm
- Không sửa trực tiếp migration đã chạy trên production
- Không thêm package mới khi chưa được duyệt

Khi có file này, mọi prompt sau đó sẽ ngắn gọn hơn nhiều, vì Claude Code đã đọc sẵn phần context nền khi bắt đầu phiên làm việc. Nếu CLAUDE.md gốc bắt đầu dài và khó quản lý, có thể tách phần chi tiết theo module sang các file trong .claude/rules/, giữ CLAUDE.md gốc chỉ như một bản mục lục ngắn gọn.

Đây là điểm khác biệt lớn nhất: Context Engineering làm một lần, dùng lại nhiều lần, còn Prompt Engineering phải lặp lại ở từng task.

6. Workflow Engineering trong Prompt Engineering

Một task phần mềm thật sự không dừng ở một câu hỏi — nó đi qua nhiều bước, và AI có thể tham gia ở từng bước.

• Requirement: AI giúp hỏi lại cho rõ yêu cầu, tìm case chưa được nhắc tới.
• Planning: Ở bước này, AI đề xuất chia nhỏ task và chỉ ra phần rủi ro cao.
• Architecture: AI đưa ra vài phương án kèm ưu nhược điểm.
• Coding: Đây là bước AI viết code theo đúng context và constraint đã thiết lập.
• Testing: AI sinh test theo business rule, không chỉ test cú pháp.
• Review: Ở vai trò reviewer, AI đối chiếu convention và tìm lỗi logic.
• Refactor: AI đề xuất cải thiện hiệu năng, giảm độ phức tạp.
• Deploy: Đến bước deploy, AI hỗ trợ viết CI/CD script và checklist trước khi release.
• Document: AI sinh tài liệu, changelog từ code đã viết.

Tuy nhiên, nếu bạn chỉ dùng AI ở bước Coding, bạn đang bỏ lỡ phần lớn giá trị mà AI có thể mang lại cho cả quy trình.

7. Case study minh hoạ: Laravel + Nuxt

Ví dụ dưới đây mô tả một pattern thường gặp khi team áp dụng Context Engineering, mang tính minh hoạ để dễ hình dung — không phải số liệu công bố từ một dự án hay khách hàng cụ thể.

Một team xây Community Platform bằng Laravel (backend) và Nuxt (frontend). Đây là kết quả trước và sau khi áp dụng Prompt Engineering có hệ thống.

Trước: mỗi developer viết prompt theo phong cách riêng, không có context chuẩn.

• Có Controller theo pattern Repository, có Controller viết logic thẳng trong action.
• Response API không đồng nhất giữa các endpoint.
• Naming lẫn lộn camelCase và snake_case trong cùng codebase.
• Reviewer mất nhiều thời gian sửa lỗi convention hơn là review logic.

Sau: team viết một CLAUDE.md chung, định nghĩa rõ pattern, response format, naming convention. Đồng thời chuẩn hoá prompt template cho việc sinh API mới.

• API do AI sinh ra tuân theo đúng pattern Controller → Service → Repository.
• Response format đồng nhất 100%.
• Thời gian review giảm rõ rệt.
• Developer mới có thể dùng AI để sinh code đúng chuẩn ngay từ ngày đầu.

Khác biệt không đến từ việc đổi model AI mạnh hơn. Mà nó đến từ việc team đầu tư thời gian cho Context và Workflow.

8. Sai lầm phổ biến khi làm Prompt Engineering

Dưới đây là những sai lầm thường gặp nhất khi áp dụng Prompt Engineering vào công việc hàng ngày:

• Prompt dài nhưng thiếu cấu trúc: nhồi hết thông tin vào một đoạn văn, không tách Role, Goal, Constraint, Output rõ ràng.
• Không có context: không có CLAUDE.md, Claude Code phải đoán convention mỗi lần, dẫn tới code không nhất quán.
• Thiếu examples: sẽ gây nguy hiểm khi convention của team khác với chuẩn phổ biến trên mạng.
• Không review lại output: coi AI như hộp đen đáng tin tuyệt đối.
• Dùng một prompt cho mọi project: copy prompt giữa các dự án có stack và convention khác nhau.

9. Best Practices Cho Prompt Engineering

Checklist trước khi giao task cho AI — áp dụng đúng các nguyên tắc Prompt Engineering đã nêu ở các mục trên:

• Đã có CLAUDE.md (và .claude/rules/ nếu cần chi tiết theo module) cho repo chưa?
• Prompt có nêu rõ Role và Goal, không chỉ là hành động đơn lẻ?
• Constraint kỹ thuật và nghiệp vụ đã liệt kê cụ thể chưa?
• Có ví dụ mẫu (code tham chiếu, input/output) đính kèm không?
• Đã nêu rõ định dạng Output mong muốn chưa?
• Có tiêu chí Evaluation để biết kết quả đạt yêu cầu?
• Task này ở bước nào trong Workflow?
• Sau khi nhận kết quả, có review lại như review code người viết không?

10. Tương lai: từ Code Writer đến System Designer

Đây chính là tương lai của Prompt Engineering.

Giá trị của developer đang dịch chuyển: từ “viết được code” sang “thiết kế được hệ thống mà AI có thể vận hành đúng trong đó”. Người giỏi Prompt Engineering theo nghĩa đầy đủ — Prompt + Context + Workflow — sẽ là người tạo ra đòn bẩy lớn nhất cho team.

Đây không phải là thay developer bằng AI. Đây là thay đổi thứ mà một developer giỏi cần thành thạo: không chỉ ngôn ngữ lập trình, mà còn cách thiết kế môi trường làm việc cho AI.

Biểu đồ: Context Engineering Trong Prompt Engineering Ảnh Hưởng Đến Chất Lượng Output Như Thế Nào

Ví dụ Prompt Engineering thực tế với Claude Code

1. CLAUDE.md đọc tự động, prompt trong phiên chỉ cần nêu task:

# CLAUDE.md ở root repo đã đọc tự động khi khởi động phiên làm việc
claude "Thêm endpoint DELETE /api/events/{id}/register để user
huỷ đăng ký, dùng lại EventRegistrationService đang có"

2. Tách rule chi tiết theo module vào .claude/rules/, giữ CLAUDE.md gốc gọn:

# .claude/rules/backend.md
Khi sửa file trong app/Http/Controllers:
- Giữ Controller mỏng, chuyển toàn bộ logic vào Service tương ứng
- Mọi input phải qua Form Request, không validate trong Controller
- Response luôn trả qua API Resource

3. Đóng gói quy trình lặp lại thành custom slash command:

# .claude/commands/review-pr.md
Review PR hiện tại theo checklist:
1. Có tuân theo pattern Controller -> Service -> Repository không?
2. Có test cho Service class mới không?
3. Response format có đúng chuẩn API Resource không?
4. Liệt kê rủi ro bảo mật nếu có.

# Gọi lại quy trình review chuẩn hoá này bất cứ lúc nào
claude
> /review-pr

4. Auto memory ghi lại điều đã thống nhất, không cần lặp lại trong prompt:

Khi bạn sửa Claude giữa phiên làm việc — ví dụ “từ giờ dùng Str::uuid() thay vì Str::random() cho mọi primary key” — Claude Code có thể tự ghi lại thành một note trong bộ nhớ, và áp dụng lại ở các phiên sau mà không cần bạn nhắc lại trong CLAUDE.md.

Auto memory cần Claude Code bản mới và có thể bật/tắt qua /memory trong phiên làm việc — kiểm tra version hiện tại bằng claude –version nếu tính năng chưa xuất hiện.

Sơ Đồ: Các Lớp Thông Tin Trong Một Phiên Prompt Engineering Với Claude Code

11. Kết luận

Prompt Engineering không phải là kỹ năng “gõ câu lệnh hay”. Đó là kỹ năng chuẩn bị đủ thông tin để AI đưa ra quyết định đúng — gồm context dự án, ràng buộc kỹ thuật, ví dụ mẫu, và vị trí của task trong cả quy trình.

Developer chỉ tối ưu câu chữ trong prompt sẽ luôn nhận kết quả “đúng cú pháp, sai ngữ cảnh”. Developer đầu tư vào Context Engineering và Workflow Engineering sẽ biến AI thành cộng sự thật sự hiểu dự án.

Nếu repo của bạn chưa có CLAUDE.md hay file tương đương, đó là việc đáng làm nhất — không phải để viết prompt hay hơn, mà để không phải giải thích lại context ở mỗi lần trao đổi với AI.

Cuối cùng: chọn một repo đang làm, viết thử file context theo mẫu ở mục 5, rồi so sánh chất lượng output trước và sau. Khác biệt sẽ thấy rõ được sau một đến hai task.

Tổng kết lại, các bạn có thể xem hình ảnh tóm tắt dưới đây để dễ nhớ cách tận dụng AI giúp hỗ trợ cho công việc lập trình hiện tại.

Ngoài ra, các bạn có thể xem thêm các bài viết kỹ thuật khác tại chuyên mục Tin kỹ thuật của Rivercrane.

Lê Văn Hiểu PHP Developer