← Chương trước: Phần 2 — 8 khối chuẩn của một prompt cho agent (2026) | Mục lục Series | Chương tiếp theo: Từ prompt cảm tính sang prompt có thể test và version (2026) →

Answer-first: Tách biệt Role, Rules, Workflow và Skill theo mô hình phân lớp giúp prompt ngắn gọn, dễ bảo trì và tái sử dụng. Khi có thay đổi chính sách, team chỉ cần cập nhật lớp Rules dùng chung mà không phải sửa lại toàn bộ prompt nghiệp vụ.

Vì sao một prompt duy nhất thường trở nên quá tải?

Lúc mới bắt đầu, nhiều team hay gom mọi thứ vào một file:

  • agent là ai
  • phải cư xử thế nào
  • quy định an toàn
  • quy trình làm việc
  • hướng dẫn cho từng loại task

Ban đầu có vẻ tiện. Nhưng càng dùng lâu, prompt càng có 3 vấn đề:

  • dài
  • khó sửa
  • sửa chỗ này dễ ảnh hưởng chỗ khác

Giải pháp tốt hơn là tách lớp.

Mô hình 4 lớp rất dễ áp dụng

1. Role

Role trả lời câu hỏi: agent đang đóng vai gì?

Ví dụ:

  • Backend Developer
  • Reviewer
  • DevOps
  • Technical Architect

Role nên chứa:

  • identity
  • trách nhiệm
  • quyền quyết định
  • phong cách giao tiếp

2. Rules

Rules là các điều bất biến.

Ví dụ:

  • không sửa file generated bằng tay
  • không dùng lệnh phá huỷ
  • không bịa test result
  • không lộ secrets

Rules nên ngắn, rõ, và ít thay đổi.

3. Workflow

Workflow là trình tự xử lý một loại công việc.

Ví dụ:

  • debug issue
  • architecture planning
  • deep review
  • quick docs

Workflow giúp agent không bỏ sót bước.

4. Skill

Skill là hướng dẫn chuyên sâu cho một loại task hoặc domain cụ thể.

Ví dụ:

  • add-api-endpoint
  • add-event-handler
  • write-tests
  • review-service

Skill chỉ nên được gọi khi task thật sự phù hợp.

Nếu nhìn từ góc độ kế toán:

  • role giống vai trò “kế toán thanh toán” hay “kế toán tổng hợp”
  • rules giống nguyên tắc không được bỏ qua chứng từ
  • workflow giống quy trình chốt công nợ hay đối soát cuối tháng
  • skill giống hướng dẫn riêng cho nghiệp vụ hoàn tiền, đối soát ví điện tử, hay kiểm tra VAT

Lợi ích của cách tách lớp này

Dễ tái sử dụng

Một reviewer role có thể dùng chung cho nhiều repo.

Dễ sửa

Nếu chỉ muốn thay quy trình review, bạn sửa workflow, không cần chỉnh sửa toàn bộ prompt.

Dễ đào tạo team

Người mới có thể hiểu hệ thống prompt theo từng lớp, thay vì đọc một file rất dài.

Dễ kiểm soát drift

Khi output bắt đầu lệch, team dễ lần ra nguyên nhân hơn:

  • do role mơ hồ?
  • do rule thiếu?
  • do workflow chưa đủ?
  • do skill viết quá chung?

Một ví dụ gần gũi

Thay vì có một prompt khổng lồ như:

Bạn là senior backend developer, hãy lịch sự, đọc code trước khi sửa,
ưu tiên clean architecture, viết test, không sửa generated files,
nếu debug thì làm A B C, nếu review thì làm X Y Z, nếu viết docs thì...

hãy chia thành:

role/developer.md
rules/coding-safety.md
workflows/debug-issue.md
skills/add-api-endpoint/SKILL.md
skills/write-tests/SKILL.md

Đây là cách biến prompt từ “đoạn chat tạm thời” thành “hệ thống vận hành”.

Ý chính cần nhớ

Nếu team muốn dùng AI agent nghiêm túc, prompt nên được tổ chức như code:

  • có module
  • có trách nhiệm rõ ràng
  • có thể thay thế từng phần

Ở phần tiếp theo, chúng ta sẽ đi từ kiến trúc prompt sang vận hành thật: cách version prompt và test prompt để biết bản nào thực sự tốt hơn.

🔗 Đọc thêm các chuyên đề liên quan:

← Chương trước: Phần 2 — 8 khối chuẩn của một prompt cho agent (2026) | Mục lục Series | Chương tiếp theo: Từ prompt cảm tính sang prompt có thể test và version (2026) →

❓ Câu Hỏi Thường Gặp (FAQ)

Q1: Tách Role, Rules, Workflow và Skill trong Thiết Kế Prompt Lớp (2026) giải quyết vấn đề cốt lõi nào trong kiến trúc hệ thống?

Cách chia prompt thành nhiều lớp nhỏ để dễ bảo trì, tái sử dụng và phù hợp cho đội ngũ phát triển (Cập nhật 2026).

Q2: Những lưu ý quan trọng nhất khi triển khai thực tế là gì?

Cần chú trọng phân tầng ranh giới trách nhiệm (bounded context), thiết lập cơ chế fallback dự phòng, và giám sát chặt chẽ qua metrics OpenTelemetry để phát hiện sớm các điểm nghẽn.

Q3: Làm sao để kiểm thử và đánh giá hiệu quả sau khi áp dụng?

Áp dụng kiểm thử tải (load test), benchmark độ trễ P95/P99 trước và sau triển khai, kết hợp tracing phân tán để xác minh tính ổn định dưới tải cao.