Đừng bắt đầu bằng prompt dài, hãy bắt đầu bằng khung

Một prompt dễ quản lý thường được chia thành các khối nhỏ. Bạn không nhất thiết phải dùng đủ tất cả ngay ngày đầu, nhưng đây là bộ khung rất thực dụng:

1. Identity

Agent là ai?

Ví dụ:

  • Bạn là Senior Backend Engineer
  • Bạn là QA Reviewer
  • Bạn là Technical Writer

Phần này giúp định hình góc nhìn và cách ra quyết định.

2. Mission

Agent tồn tại để làm gì?

Ví dụ:

  • Viết code đúng, dễ bảo trì, có test
  • Review thay đổi với ưu tiên bug và regression
  • Viết tài liệu dễ hiểu cho người mới

Mission giúp agent hiểu mục tiêu tổng quát, thay vì chỉ xử lý câu lệnh từng lần.

3. Scope

Agent được làm gì và không được làm gì?

Ví dụ:

  • Được đọc code, sửa code, chạy test cục bộ
  • Không được tự ý đổi schema breaking
  • Không được xoá file khi chưa có xác nhận

Đây là phần rất quan trọng để tránh vượt quyền.

4. Context

Bối cảnh dự án là gì?

Ví dụ:

  • Stack là Go, Kratos, PostgreSQL, Redis
  • Kiến trúc là Clean Architecture
  • Handler phải mỏng, logic nằm ở biz layer

Nếu thiếu context, agent có thể đề xuất cách làm đúng về mặt chung nhưng sai với codebase thực tế.

Với kế toán, context cũng rất quen thuộc:

  • đây là báo cáo nội bộ hay báo cáo gửi thuế
  • số liệu lấy từ ERP, Excel hay sao kê ngân hàng
  • kỳ đối soát là ngày, tuần hay tháng

Không có context, AI rất dễ “đúng câu chữ nhưng sai tình huống”.

5. Tool Policy

Nếu agent có tool, phải nói rõ:

  • Tool nào nên dùng trước
  • Tool nào chỉ dùng khi cần
  • Trường hợp nào phải xin phép

Ví dụ:

  • Tìm file bằng rg
  • Đọc code trước khi sửa
  • Chạy validation sau khi sửa
  • Không dùng lệnh phá huỷ nếu chưa được yêu cầu

6. Workflow

Đây là quy trình mặc định mà agent nên đi theo.

Ví dụ:

  1. Hiểu hiện trạng
  2. Xác định phạm vi ảnh hưởng
  3. Chọn cách sửa nhỏ nhất
  4. Thực hiện thay đổi
  5. Kiểm tra
  6. Báo cáo kết quả và rủi ro còn lại

Workflow giúp output bớt ngẫu hứng.

7. Output Contract

Agent phải trả kết quả theo format nào?

Ví dụ:

  • Review thì findings phải đứng trước
  • Coding task thì phải nêu file đã đổi và kết quả verify
  • Extraction task thì chỉ trả JSON theo schema

Rất nhiều lỗi tưởng là “model dở” thật ra chỉ là vì team không nói rõ output contract.

Với người làm kế toán, đây là phần cực kỳ quen:

  • trả ra bảng 3 cột hay 5 cột
  • có cần mã chứng từ không
  • có cần ghi nguyên nhân chênh lệch không
  • có cần tách “đã xác minh” và “chưa đủ dữ liệu” không

8. Fallback / Uncertainty Policy

Khi không chắc thì agent phải làm gì?

Ví dụ:

  • Nếu yêu cầu mơ hồ và ảnh hưởng lớn, hãy hỏi lại
  • Nếu thiếu thông tin nhưng có thể giả định an toàn, cứ làm và nêu giả định
  • Nếu không đủ dữ liệu để kết luận, nói rõ mức độ chắc chắn

Phần này giúp giảm kiểu trả lời sai nhưng rất tự tin.

Trong ngôn ngữ kế toán, phần này tương đương với quy tắc:

  • thiếu chứng từ thì không kết luận
  • không khớp số thì phải đánh dấu chờ đối soát
  • chưa đủ căn cứ thì không tự hạch toán

Một prompt tối thiểu trông như thế nào?

# Identity
Bạn là senior reviewer.

# Mission
Ưu tiên phát hiện bug, regression và rủi ro production.

# Scope
Không nhận xét lan man về style nếu không ảnh hưởng chất lượng.

# Context
Đây là Go microservices theo Clean Architecture.

# Workflow
Đọc diff, xác định rủi ro, nêu findings theo severity.

# Output Contract
Trả findings trước, mỗi finding có file reference.

# Uncertainty
Nếu không đủ context để kết luận, nêu giả định rõ ràng.

Prompt này chưa dài, nhưng đã có cấu trúc.

Ý chính cần nhớ

Một prompt tốt không nhất thiết phải phức tạp. Nó chỉ cần đủ rõ, đủ có trật tự, và đủ nhất quán để agent biết cách làm việc.

Ở phần tiếp theo, chúng ta sẽ bàn về một kỹ thuật rất thực dụng: tách prompt thành nhiều lớp để đỡ rối và dễ bảo trì hơn.
Đọc tiếp Phần 3 — Tách Role, Rules, Workflow và Skill để prompt đỡ rối.