Skill-Based AI Execution: Khi prompt không còn đủ nữa

Khi prompt không còn đủ nữa

Có một thời điểm trong quá trình làm việc với AI mà mọi senior dev đều gặp phải — không phải lúc AI bắt đầu sai, mà là lúc bạn nhận ra mình không thể dự đoán khi nào nó sẽ sai.

Đó là lúc prompt-based execution chạm trần.

Tại sao prompt-based thất bại ở scale

Vấn đề không phải model kém. Vấn đề là kiến trúc.

Prompt-based execution về bản chất là stateless: mỗi lần chạy là một lần suy luận từ đầu, không có memory, không có constraint, không có guardrail. Ở task đơn giản, điều này không thành vấn đề. Ở task phức tạp với nhiều bước phụ thuộc nhau, đây là công thức cho drift tích lũy.

❌ Prompt-based (stateless reasoning)

User prompt
    │
    ▼
┌─────────────────────────────┐
│  Model tự suy luận toàn bộ  │
│  - Hiểu yêu cầu             │
│  - Chọn approach            │
│  - Viết code                │
│  - Quyết định edge cases    │
└─────────────────────────────┘
    │
    ▼
Output (unpredictable)

Mỗi "hộp" ở trên là một điểm có thể drift. Và drift tích lũy qua nhiều bước.

Skill-Based Execution: Kiến trúc thay vì prompt

Skill-based execution giải quyết vấn đề ở tầng kiến trúc, không phải tầng prompt. Thay vì cố gắng viết prompt đủ tốt, bạn xây một hệ thống để AI không thể reasoning sai ở những điểm quan trọng.

✅ Skill-based (constrained execution)

User Input
    │
    ▼
┌──────────────┐
│   Workflow   │  ← điều phối luồng, không cho phép skip bước
└──────┬───────┘
       │
   ┌───┴────────────────────┐
   ▼                        ▼
┌────────┐            ┌──────────┐
│ Agents │            │  Skills  │  ← source of truth, override reasoning
│ roles  │            │  rules   │
└───┬────┘            └──────────┘
    │
    ▼
┌─────────────────────────────────────┐
│  Parse → Research → Plan → Confirm  │
│       → Execute → Check → Verify    │
└─────────────────────────────────────┘
    │
    ▼
Output (predictable)

Ba thành phần cốt lõi:

Workflow — pipeline cố định, không thể bị bỏ qua. Mọi task đều đi qua cùng một sequence.

Agent — phân vai rõ ràng. Planner không execute. Checker không plan. Mỗi agent chỉ làm đúng một việc trong pipeline.

Skill — tập hợp rule và heuristic được viết ra trước. Đây là nơi kiến thức về project được encode, không phải trong prompt.

Gray Area Detection: Bước hay bị bỏ qua nhất

Phần lớn hallucination không đến từ model tệ — đến từ câu hỏi chưa được hỏi.

Trước khi plan, workflow bắt buộc phải identify các decision point chưa được xác định rõ:

Decision tree — Gray Area Check
────────────────────────────────

Nhận task
    │
    ▼
Có điểm nào chưa rõ?
    │
  ┌─┴─────────────┐
  │               │
 Có              Không
  │               │
  ▼               ▼
List ra        Tiến hành plan
2-4 questions
  │
  ▼
Hỏi user → Nhận confirm
  │
  ▼
Tiến hành plan

Ví dụ câu hỏi cần explicit hóa trước khi plan:

□ Loading state: skeleton hay spinner?
□ Error handling: retry tự động hay fail-fast?
□ API schema: strict validation hay flexible?
□ Empty state: show placeholder hay hide component?

Mỗi câu hỏi không được hỏi = một assumption tự điền vào = một potential rework.

Plan Loop: Đừng tin plan đầu tiên

✅ Plan Loop với giới hạn

Planner tạo plan (v1)
        │
        ▼
Plan-checker review
        │
   ┌────┴────┐
   │         │
 Pass       Fail
   │         │
   ▼         ▼
 Confirm   Update plan (v2)
 with user      │
                ▼
          Plan-checker review
                │
           ┌────┴────┐
           │         │
         Pass       Fail
           │         │
           ▼         ▼
         Confirm  Update plan (v3)
         with user      │
                        ▼
                  ❗ STOP — escalate to user
                  (loop limit reached)

Giới hạn 2–3 iteration không phải tùy tiện. Nếu sau 3 lần plan vẫn không pass checker, đó là tín hiệu gray area chưa được xử lý đủ — không phải vấn đề cần loop thêm.

Kết quả thực tế sau khi migrate

Bắt đầu từ đâu nếu bạn muốn thử

Tuần 1: Viết skill file đầu tiên
  └─ .cursor/skills/project-rules.md
     (naming convention, tech stack, những gì không được tự chọn)

Tuần 2: Thêm gray area rule
  └─ "Trước khi plan, list 2-4 điểm chưa rõ và hỏi"

Tuần 3: Thêm plan-checker
  └─ Một prompt đơn giản review lại plan trước khi execute

Tuần 4: Thêm human-in-the-loop checkpoint
  └─ AI không execute nếu chưa có confirm từ user

Sau mỗi lần AI làm sai, không chỉ sửa output — encode lại rule vào skill file. Đó là cách hệ thống tự cải thiện theo thời gian.

Kết luận

Prompt tốt là điều kiện cần — không phải điều kiện đủ.

Ở một mức độ phức tạp nhất định, vấn đề không còn là "viết prompt thế nào" mà là "thiết kế hệ thống thế nào để AI luôn làm đúng." Skill-based execution là câu trả lời cho câu hỏi đó.

Đừng optimize prompt. Hãy design hệ thống.