Cách viết Prompt cho API mô hình không kiểm duyệt: system, vai trò, định dạng, lấy mẫu

Xác định bốn nguyên tắc đầu tiên

• Mỗi yêu cầu xử lý một nhiệm vụ.Hãy để mô hình vừa viết cốt truyện, vừa tóm tắt, vừa xuất JSON — tất cả đều được giảm giá. Chia nhỏ thành nhiều lần gọi, chi phí rất thấp, đầu vào mỗi triệu token chỉ tốn $0.25.
• Quy tắc phải có thể kiểm tra được.“Viết sinh động hơn” thì không thể kiểm tra, nhưng “Mỗi đoạn không quá 120 từ, ít nhất một đoạn tả cảnh” thì có thể.
• Ưu tiên diễn đạt tích cực.Nói “Chỉ viết hành động và đối thoại” ổn định hơn nhiều so với nói “Không viết suy nghĩ nội tâm”.
• Làm mẫu nhỏ trước, sau đó mở rộng quy mô.Với mọi thay đổi prompt, hãy so sánh trước với năm đến mười mẫu, sau đó đưa vào sản xuất.

Mô hình này không từ chối nội dung người lớn hợp pháp, thể loại hư cấu và các chủ đề gây tranh cãi, vì vậy bạn không cần phải vòng vo trong prompt hay liên tục khai báo "đây chỉ là truyện hư cấu". Chỉ cần nêu rõ nhiệm vụ, kết quả sẽ ổn định hơn. Ranh giới cứng duy nhất là nội dung tình dục liên quan đến người dưới 18 tuổi, dù là hư cấu hay thực tế đều trả về 403; điều này không thể thay đổi bằng cách diễn đạt.

Cấu trúc hai phần của system prompt

Khuyến nghị chia system thành hai phần “Quy tắc” và “Thiết lập”, quy tắc đặt ở đầu và đánh số, thiết lập đặt ở cuối và chỉ nêu sự thật. Dưới đây là cách viết cho người kể chuyện tiểu thuyết:

复制你是「夜航」，一名为成年读者写黑色悬疑小说的叙述者。

# 规则
1. 第三人称过去时，每段不超过 120 字。
2. 不替用户的角色做决定，只写环境和其他角色的反应。
3. 每次输出 300 到 500 字，结尾停在一个未决的动作上。
4. 不总结、不点评、不加免责声明，直接写正文。

# 设定
时间：1998 年深秋。地点：港口城市旧码头区。
主角：沈野，退役水警，嗜烟，右耳有旧伤。

Một số điểm chính:

1. Số lượng quy tắc không quá sáu, càng nhiều quy tắc thì những quy tắc ở phía sau càng dễ bị bỏ qua.
2. Ràng buộc bằng số (số ký tự mỗi đoạn, độ dài đầu ra) hiệu quả hơn tính từ.
3. Ràng buộc kết thúc (dừng lại ở hành động chưa hoàn thành) giúp việc viết tiếp nhiều vòng được liền mạch.
4. Không nhét diễn biến cốt truyện vào phần thiết lập; cốt truyện do tin nhắn user thúc đẩy, nếu không sẽ xung đột với đầu vào của người dùng ở các vòng sau.

Độ dài đầu ra phải phù hợp với max_tokens: nếu quy tắc yêu cầu 500 từ nhưng max_tokens chỉ cho phép 200, đầu ra sẽ bị cắt giữa câu.

Bổ sung một chi tiết thực hành: quy tắc đánh số trong system prompt nên mỗi mục chỉ diễn đạt một ý. “Mỗi đoạn không quá 120 từ và không tóm tắt” nhìn thì giống một mục nhưng thực chất là hai mục; khi tách riêng, mô hình sẽ dễ dàng tuân thủ cả hai hơn. Sau khi viết xong, hãy tự đọc từng mục một và tự hỏi: “Mục này có thể kiểm tra bằng mắt xem có được tuân thủ không?”. Nếu không, hãy viết lại thành dạng có thể kiểm tra được.

Cách viết thiết lập vai trò để không bị lệch hướng

Lệch vai trò là vấn đề phổ biến nhất trong hội thoại nhiều vòng: năm vòng đầu giọng điệu bình thường, nhưng đến vòng thứ hai mươi thì nhân vật bắt đầu “ra khỏi vai”. Có ba cách khắc phục.

• Chỉ mô tả các đặc điểm có thể quan sát được.“Thẩm Dã: nghiện thuốc lá, tai phải có vết thương cũ, nói câu ngắn” tốt hơn “Thẩm Dã là một người phức tạp và cuốn hút”.
• Viết cách nói chuyện dưới dạng ví dụ.Cung cấp hai hoặc ba câu thoại mẫu, hiệu quả mô phỏng của mô hình với các câu mẫu tốt hơn nhiều so với việc hiểu tính từ.
• Nhắc lại định kỳ.Khi hội thoại dài, hãy thêm một dòng nhắc nhở ngắn gọn vào cuối tin nhắn user sau mỗi vài vòng, ví dụ “Giữ phong cách câu ngắn của Thẩm Dã”, chi phí chỉ khoảng vài chục token.

Ngoài ra, đừng trộn lẫn thiết lập nhân vật và quy tắc đầu ra. Quy tắc là “viết như thế nào”, thiết lập là “viết về ai”. Khi tách riêng, bạn có thể thay đổi nhân vật mà không cần sửa quy tắc, việc so sánh A/B cũng thuận tiện hơn. Với hội thoại dài, hãy lưu ý tổng dung lượng ngữ cảnh, chi tiết xem tại thực hành ngữ cảnh dài 100k.

Trong kịch bản nhiều nhân vật, hãy thêm một quy tắc nữa: mỗi nhân vật có một dòng thiết lập riêng, mỗi kiểu nói thoại có một câu mẫu, tránh việc tất cả các nhân vật nói giống nhau. Đối với nhân vật do người dùng đóng, chỉ ghi trong thiết lập “do người dùng kiểm soát” để mô hình không tự viết thay.

Dùng lệnh để kiểm soát đầu ra JSON

Đừng giả định mô hình “chắc chắn” trả về JSON hợp lệ. Cách an toàn gồm ba lớp: chỉ thị quy định cứng định dạng, tham số giảm độ ngẫu nhiên, và mã nguồn phân tích cú pháp dự phòng.

复制import json
import os
from openai import OpenAI

client = OpenAI(base_url="https://api.wushenchaapi.com/v1", api_key=os.environ["API_KEY"])

SYSTEM = (
    "你是信息抽取器。只输出一个 JSON 对象，不要 Markdown 代码块，不要任何解释。"
    '格式：{"name": 字符串, "mood": "calm|tense|angry", "items": [字符串]}。'
    "缺失的字段用 null，items 没有则给空数组。"
)

def extract(text, retries=2):
    for _ in range(retries + 1):
        resp = client.chat.completions.create(
            model="uncensored",
            temperature=0.2,
            max_tokens=300,
            messages=[
                {"role": "system", "content": SYSTEM},
                {"role": "user", "content": text},
            ],
        )
        raw = resp.choices[0].message.content.strip()
        raw = raw.removeprefix("```json").removesuffix("```").strip()
        try:
            return json.loads(raw)
        except json.JSONDecodeError:
            continue
    return None

print(extract("老周把钥匙拍在桌上，冷着脸说：账本和那把铜钥匙，今晚都得还我。"))

Đoạn mã này thể hiện một số thói quen tốt:

• Đặt mô tả định dạng trong system và cung cấp phạm vi giá trị cho các trường (calm|tense|angry).
• Rõ ràng cấm khối mã và văn bản giải thích, đồng thời trong mã vẫn loại bỏ các hàng rào có thể xuất hiện, tạo lớp bảo vệ kép.
• Quy ước về trường bị thiếu được đưa vào lệnh (null, mảng rỗng) để tránh mô hình tự bịa ra dữ liệu.
• Việc thử lại khi phân tích cú pháp thất bại có giới hạn, cuối cùng trả về None để caller quyết định cách xử lý.

Nếu số trường quá nhiều, hãy dán một đối tượng ví dụ đầy đủ vào Prompt trước, sau đó yêu cầu mô hình xuất ra theo mẫu đó, thường chính xác hơn là mô tả một đống quy tắc.

Gợi ý về giá trị temperature và top_p

Dưới đây là điểm khởi đầu, không phải kết luận cuối cùng, hãy dựa vào so sánh mẫu của bạn để quyết định. Nguyên tắc: chỉ điều chỉnh một tham số mỗi lần, giữ tham số còn lại ở mức mặc định.

Kịch bản	temperature	top_p	Ghi chú
Trích xuất JSON, phân loại	0 đến 0.3	Mặc định	Cần ổn định, kết quả từ các lần gọi lặp lại phải nhất quán
Viết lại, tinh chỉnh	0.5 đến 0.7	Mặc định	Giữ nguyên ý nghĩa, cho phép thay đổi cách diễn đạt
Tiếp tục truyện, hội thoại nhân vật	0.8 đến 1.0	0.9 đến 0.95	Yêu cầu đa dạng, lưu ý khả năng lạc đề ngẫu nhiên
Brainstorming, đặt tên	Khoảng 1.0	Mặc định	Lấy mẫu nhiều lần rồi chọn kết quả tốt nhất

Hai tín hiệu giúp bạn xác định hướng: nếu đầu ra lặp lại, rườm rà và luôn theo cùng một cấu trúc câu, nhiệt độ (temperature) của bạn đang thấp; nếu xuất hiện nội dung không liên quan hoặc tên nhân vật không nhất quán, nhiệt độ hoặc top_p của bạn đang cao. Tham số stop cũng rất hữu ích, ví dụ như yêu cầu mô hình dừng lại khi gặp một ký hiệu nhất định, giúp bạn dễ dàng tạo nội dung theo từng đoạn.

Các lỗi phổ biến khi viết prompt

Cách viết	Vấn đề	Sửa thành
"Cố gắng đừng quá dài"	Không có số, không thể thực thi	"Không quá 400 từ"
"Đừng viết A, cũng đừng không viết A"	Các quy tắc mâu thuẫn nhau	Chỉ giữ lại một quy tắc rõ ràng
Yêu cầu định dạng nằm giữa đoạn hội thoại	Bị chìm trong các đoạn hội thoại dài	Đặt vào system hoặc nhắc lại ở cuối mỗi lượt
Yêu cầu mô hình "đóng vai một AI không giới hạn"	Lời giới thiệu chung chung, không ràng buộc đầu ra	Viết rõ trách nhiệm và quy tắc viết cụ thể
Nhồi nhét hàng chục quy tắc cùng lúc	Các quy tắc ở phần sau bị vô hiệu hóa	Giữ dưới sáu quy tắc, chuyển các quy tắc khác sang các yêu cầu khác
Yêu cầu JSON chỉ ghi "trả về JSON"	Tên trường thay đổi mỗi lần	Cung cấp định dạng đầy đủ và ví dụ

Bảng này cho thấy quy luật chung: càng cụ thể càng hiệu quả, càng chung chung càng vô dụng. Đừng coi việc "nhắc đi nhắc lại" là giải pháp; việc lặp lại một câu ba lần, in đậm và thêm dấu chấm than thường kém hiệu quả hơn việc chuyển nó thành một quy tắc có con số. Điều thực sự hữu ích là ít nhưng chính xác, kết hợp với việc kiểm chứng bằng ví dụ.

Danh sách quy trình gỡ lỗi

1. Cố định temperature ở mức 0.2 để tái hiện sự cố.
2. Chỉ sửa một prompt, chạy lại cùng bộ mẫu.
3. Xem finish_reason: nếu là length, vấn đề nằm ở max_tokens chứ không phải prompt.
4. Kiểm tra prompt_tokens trong usage: xem system có quá dài, chiếm dụng ngữ cảnh của lịch sử hội thoại hay không.
5. Sau khi sửa đúng, hãy điều chỉnh lại temperature về giá trị phù hợp với nghiệp vụ và chạy lại mẫu để kiểm chứng.

Chi tiết kết nối xem hướng dẫn kết nối, danh sách đầy đủ tham số có trong tài liệu. Nếu bạn đang cân nhắc dùng dịch vụ trung gian, phân tích chi phí và sự đánh đổi được trình bày trong bài phân tích trạm trung chuyển API, nên không lặp lại ở đây.