Claude Certification Guide

Prompt Engineering cho Claude: System Prompt, Few-Shot, và Xác thực Output

18 tháng 3, 2026 · 10 phút đọc

Không có cú pháp bí mật nào khiến Claude tự động ngoan ngoãn. Prompt engineering là việc cung cấp cho mô hình các tiêu chí rõ ràng, ràng buộc cứng, và ví dụ cụ thể để nó làm đúng những gì bạn thực sự cần, mỗi lần đều vậy. Hướng dẫn này bao gồm các mẫu hình hoạt động tốt trong sản xuất và những mẫu hình mà bài thi Claude Certified Architect sẽ kiểm tra bạn.

System prompt: tiêu chí rõ ràng thắng chỉ thị mơ hồ

Sai lầm lớn nhất mà mọi người mắc phải với prompt trong sản xuất là gì? Chỉ thị system mơ hồ. Bảo Claude "hãy thận trọng" hoặc "chỉ báo cáo các phát hiện có độ tin cậy cao" không cho nó ranh giới quyết định thực sự nào cả. Nó sẽ diễn giải những cụm từ đó khác nhau mỗi lần.

So sánh hai cách tiếp cận sau cho một system prompt review code:

Mơ hồ (không đáng tin cậy):

You are a code reviewer. Be conservative and only flag important issues. Report findings with high confidence.

Tiêu chí rõ ràng (đáng tin cậy):

You are a code reviewer. Report findings in these categories only: BUGS: Flag when code will produce incorrect results at runtime. - Report: null dereference, off-by-one errors, unchecked return values - Skip: style preferences, naming conventions, missing comments SECURITY: Flag when code introduces an exploitable vulnerability. - Report: SQL injection, XSS, hardcoded credentials, path traversal - Skip: theoretical attacks requiring physical access Do not report findings outside these categories.

Phiên bản thứ hai cho Claude biết chính xác cái gì tính và cái gì không. Không có chỗ để xoay xở. Đó là điều khiến nó đáng tin cậy qua hàng nghìn lần gọi, và đó là mẫu hình bài thi kiểm tra trong Task 4.1 — System Prompt.

Hiệu chỉnh mức độ nghiêm trọng bằng ví dụ code

Bạn có thể mô tả các mức độ nghiêm trọng bằng văn xuôi ("nghiêm trọng nghĩa là ứng dụng sẽ crash"), nhưng cách này kém đáng tin cậy hơn so với việc chỉ ra code thực tế:

Severity levels: CRITICAL — Application crashes or data loss: Example: `db.execute(f"DELETE FROM users WHERE id = \{user_input\}")` → SQL injection allowing arbitrary data deletion MINOR — Suboptimal but functional: Example: `items = [x for x in big_list if x > 0]; items = list(filter(...))` → Redundant list creation, minor memory overhead

Tại sao cách này hiệu quả hơn? Claude có thể pattern-match với code thực tế. Nó không phải đoán bạn muốn nói gì bằng "nghiêm trọng" — nó có thể thấy nghiêm trọng trông như thế nào.

Ví dụ few-shot: khi nào chúng giúp ích và khi nào chúng lãng phí token

Ví dụ few-shot rất hiệu quả để khóa chặt định dạng output và bao quát các trường hợp biên. Chúng không phải là cách khắc phục cho một thiết kế prompt bị hỏng từ gốc.

Khi nào few-shot hiệu quả

Điểm phù hợp nhất là định dạng output nhất quán. Cho Claude thấy kết quả nên trông như thế nào:

pythonCopy

import anthropic
 
client = anthropic.Anthropic()
 
message = client.messages.create(
    model="claude-sonnet-4-6-20250514",
    max_tokens=1024,
    system="""Extract structured data from customer messages.
Return JSON with these fields: intent, product, urgency (low/medium/high).
 
Example input: "My laptop screen cracked yesterday, I need this fixed ASAP"
Example output: {"intent": "repair", "product": "laptop", "urgency": "high"}
 
Example input: "Just wondering what colour options the new headphones come in"
Example output: {"intent": "inquiry", "product": "headphones", "urgency": "low"}""",
    messages=[
        {"role": "user", "content": "The printer I bought last week keeps jamming and I have a deadline tomorrow"}
    ]
)

Hai ví dụ đó làm được rất nhiều việc. Chúng khóa chặt cấu trúc JSON và chỉ cho Claude cách ánh xạ các tín hiệu ngôn ngữ sang mức độ khẩn cấp ("ASAP" → cao, "chỉ đang tự hỏi" → thấp). Được đề cập sâu trong Task 4.4 — Few-Shot & Ví dụ.

Khi nào few-shot là cách khắc phục sai

Nếu Claude cứ liên tục gọi get_customer trong khi lẽ ra phải gọi lookup_order, ném thêm ví dụ few-shot vào vấn đề sẽ không giúp ích gì. Nguyên nhân gốc rễ là mô tả tool bị chồng lấn. Hãy sửa mô tả, không phải sửa prompt.

Đây là chỗ khiến nhiều người mắc bẫy trong bài thi. Bài thi luôn ưu tiên cách khắc phục ít công sức, hiệu quả cao. Dọn dẹp mô tả tool luôn thắng việc thêm ví dụ few-shot cho các vấn đề định tuyến. Không có ngoại lệ.

Structured output với xác thực

Nếu code ứng dụng của bạn không thể parse output của Claude, thì câu trả lời có tốt đến đâu cũng không quan trọng. Hệ thống sản xuất cần structured output, và Claude hỗ trợ điều này thông qua chế độ JSON và sinh nội dung bị ràng buộc bởi schema.

Mẫu hình output JSON

pythonCopy

import anthropic
import json
 
client = anthropic.Anthropic()
 
message = client.messages.create(
    model="claude-sonnet-4-6-20250514",
    max_tokens=1024,
    system="""Analyse the given text and return a JSON object with this exact structure:
{
  "sentiment": "positive" | "negative" | "neutral",
  "confidence": 0.0-1.0,
  "key_topics": ["string"],
  "summary": "string (one sentence)"
}
 
Return ONLY the JSON object. No explanation, no markdown formatting.""",
    messages=[
        {"role": "user", "content": "The new API is significantly faster but the documentation is still incomplete."}
    ]
)
 
result = json.loads(message.content[0].text)

Pipeline xác thực output

Đừng bao giờ tin tưởng output của mô hình mà không xác thực. Nó sẽ đúng 95% thời gian, và 5% còn lại sẽ làm hỏng pipeline hạ nguồn của bạn vào lúc 2 giờ sáng thứ Bảy. Hãy xác thực trước khi truyền dữ liệu đi bất cứ đâu:

pythonCopy

from pydantic import BaseModel, field_validator
from typing import Literal
 
class SentimentAnalysis(BaseModel):
    sentiment: Literal["positive", "negative", "neutral"]
    confidence: float
    key_topics: list[str]
    summary: str
 
    @field_validator("confidence")
    @classmethod
    def confidence_in_range(cls, v: float) -> float:
        if not 0.0 <= v <= 1.0:
            raise ValueError("Confidence must be between 0 and 1")
        return v
 
    @field_validator("key_topics")
    @classmethod
    def topics_not_empty(cls, v: list[str]) -> list[str]:
        if len(v) == 0:
            raise ValueError("At least one topic required")
        return v
 
# Validate the model output
try:
    analysis = SentimentAnalysis.model_validate_json(message.content[0].text)
except Exception as e:
    # Handle validation failure — retry, fall back, or escalate
    print(f"Validation failed: {e}")

Sinh, xác thực, xử lý thất bại. Đó là vòng lặp, và đó là những gì bài thi kiểm tra trong Task 4.6 — Xác thực Output. Nguyên tắc rất đơn giản: xác thực ngay tại ranh giới giữa mô hình và code ứng dụng của bạn. Đừng để JSON chưa được xác thực lan truyền tiếp.

Chuỗi prompt (prompt chaining) cho các tác vụ phức tạp

Khi một prompt duy nhất không thể đảm nhận đáng tin cậy toàn bộ công việc, hãy chia nó thành các bước mà output của bước này nuôi cho bước tiếp theo:

  1. Extract (Trích xuất) — Lấy dữ liệu có cấu trúc từ input phi cấu trúc
  2. Transform (Biến đổi) — Áp dụng logic nghiệp vụ hoặc phân loại
  3. Validate (Xác thực) — Kiểm tra output theo các ràng buộc
  4. Format (Định dạng) — Tạo ra output cuối cùng

Mỗi bước có phạm vi hẹp hơn, vì vậy bạn có thể viết tiêu chí chặt chẽ hơn và bắt được lỗi sớm hơn. Một chuỗi 4 bước, mỗi bước đơn giản và được xác thực, sẽ vượt trội hơn một prompt độc khối duy nhất cố gắng làm mọi thứ cùng lúc. Không hề so kè.

Bài thi kiểm tra nội dung này trong Task 4.2 — Structured Output.

Vấn đề dương tính giả

Đây là một tình huống bài thi rất thích. Một pipeline CI/CD báo quá nhiều dương tính giả. Lập trình viên bắt đầu phớt lờ tất cả các phát hiện, không chỉ những cái sai. Sự tin tưởng xói mòn ở mọi hạng mục.

Đáp án hấp dẫn là "thêm ngưỡng độ tin cậy." Đừng chọn nó. Điểm tin cậy do mô hình tự báo cáo được hiệu chỉnh kém. Đây mới là cách thực sự hiệu quả:

  1. Xác định hạng mục nào có tỷ lệ dương tính giả cao
  2. Tạm thời vô hiệu hóa các hạng mục đó để khôi phục lòng tin vào những hạng mục còn hoạt động tốt
  3. Viết lại prompt cho các hạng mục bị vô hiệu hóa với tiêu chí rõ ràng và ví dụ code
  4. Kích hoạt lại từng hạng mục một, đo tỷ lệ dương tính giả trong suốt quá trình

Đó là cách tiếp cận có hệ thống mà bài thi kỳ vọng. Chỉ thị mơ hồ, lọc theo độ tin cậy, điều chỉnh temperature? Tất cả đều là phương án gây nhiễu.

Những điểm chính cần nhớ cho bài thi

  • Tiêu chí phân loại rõ ràng luôn thắng chỉ thị mơ hồ. Luôn luôn.
  • Few-shot khắc phục vấn đề định dạng, không phải định tuyến. Nếu tool bị định tuyến sai, hãy sửa mô tả tool trước.
  • Pydantic (hoặc xác thực schema tương tự) bắt được các phản hồi sai định dạng trước khi chúng đến tay người dùng của bạn. Hãy dùng nó.
  • Khi một câu hỏi thi yêu cầu cách khắc phục tốt nhất, hãy tìm lựa chọn ít công sức, hiệu quả cao. Đó gần như luôn là đáp án.
  • Hiệu chỉnh mức độ nghiêm trọng bằng ví dụ code vượt trội hơn mô tả bằng văn xuôi vì mô hình có thể pattern-match với code thực tế.
  • Đừng tin tưởng điểm tin cậy do mô hình tự báo cáo. Hãy xác thực output ngay tại ranh giới.

Bắt đầu với bài học Domain 4 để có chương trình học đầy đủ, hoặc chuyển thẳng đến câu hỏi luyện tập để tự kiểm tra bản thân.