直接拼字符串会出错，因模型对空格、换行、分隔符极度敏感，易混淆指令边界、破坏JSON结构、无法适配不同模型的token要求。
为什么 prompt 直接拼字符串会出错？
Python 里把 prompt 当普通字符串拼接，看似省事，实则埋雷。模型对空格、换行、分隔符极度敏感，"用户说：" + user_input + "请回答：" 这种写法会让模型混淆指令边界，尤其在多轮或含 JSON 的场景下，容易漏掉关键结构。
- 模型不是人，不会“理解上下文”，它只认 token 序列；少一个
\n 或多一个空格，可能让 system 角色失效
- 不同模型对分隔符要求不同：
llama-3 偏好 <|start_header_id|>user<|end_header_id|>，而 qwen 用 <|im_start|>user，硬拼字符串根本没法适配
- 拼接时容易忽略转义——比如
user_input 含 "\n" 或双引号，不处理就破坏 JSON 格式
\n 或多一个空格，可能让 system 角色失效 llama-3 偏好 <|start_header_id|>user<|end_header_id|>，而 qwen 用 <|im_start|>user，硬拼字符串根本没法适配 user_input 含 "\n" 或双引号，不处理就破坏 JSON 格式 用 string.Template 或 f-string 配合预清洗更稳：
from string import Template<br>template = Template("你是一个助手。\n用户输入：$input\n请用中文回答。")<br>prompt = template.substitute(input=user_input.strip().replace("\n", " "))
怎么让 system 指令真正生效？
很多同学加了 system 字段但模型还是乱答，问题不在模型，而在模板没对齐它的 tokenizer 行为。
-
system 内容必须出现在 prompt 最开头，且不能被后续的 user 分隔符覆盖（比如误写成 "[INST] <<sys>>...<</sys>）
- OpenAI API 要求
messages 列表中第一个是 {"role": "system", "content": ...}；但本地 transformers 加载的 llama 模型根本不认这个字段，得靠 tokenizer 自带的 apply_chat_template
- 有些模型（如
phi-3）会忽略过长的 system 提示，超过 64 token 就开始降权，建议控制在 30 字以内
system 内容必须出现在 prompt 最开头，且不能被后续的 user 分隔符覆盖（比如误写成 "[INST] <<sys>>...<</sys>） messages 列表中第一个是 {"role": "system", "content": ...}；但本地 transformers 加载的 llama 模型根本不认这个字段，得靠 tokenizer 自带的 apply_chat_template phi-3）会忽略过长的 system 提示，超过 64 token 就开始降权，建议控制在 30 字以内 检查方式很简单：打印 tokenizer.encode(prompt)，确认 system 对应的 token 是否真实出现在输出数组最前端。
apply_chat_template 为什么返回空或报错？
这是 Hugging Face 生态里最常卡住的点——调用 tokenizer.apply_chat_template 却返回空字符串或抛 KeyError: 'messages'。
- 必须传入标准格式的
messages 列表，不是单个字符串：[{"role": "system", "content": "..."}, {"role": "user", "content": "..."}]
- 模型没有内置 chat template 时，该方法会静默失败（返回空），可用
tokenizer.chat_template 查看是否为 None
- 使用
add_generation_prompt=True 才会补上模型期待的起始 token（比如 <|eot_id|><|start_header_id|>assistant<|end_header_id|>），漏掉它，模型就不知道该生成什么
messages 列表，不是单个字符串：[{"role": "system", "content": "..."}, {"role": "user", "content": "..."}] tokenizer.chat_template 查看是否为 None add_generation_prompt=True 才会补上模型期待的起始 token（比如 <|eot_id|><|start_header_id|>assistant<|end_header_id|>），漏掉它，模型就不知道该生成什么 常见修复：
if tokenizer.chat_template is None:<br> tokenizer.chat_template = "{% for message in messages %}{{ message['role'] }}: {{ message['content'] }}{% endfor %}"
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
JSON 输出不稳定？别硬 parse，用 response_format 参数
想让模型返回合法 JSON，很多人写 prompt 里强调“只返回 JSON，不要解释”，结果还是混入 Markdown 或自然语言。这不是模型不听话，是没用对机制。
- OpenAI API 的
response_format={"type": "json_object"} 会强制模型走 JSON 模式，底层启用 grammar-guided decoding，比任何 prompt 描述都管用
-
transformers 生态暂不原生支持，但可通过 llama.cpp 的 -ngl 或 litgpt 的 json_schema 实现类似效果
- 硬 parse 返回文本风险极高：
json.loads(response) 遇到单引号、尾逗号、注释就崩，而模型真会这么干
response_format={"type": "json_object"} 会强制模型走 JSON 模式，底层启用 grammar-guided decoding，比任何 prompt 描述都管用 transformers 生态暂不原生支持，但可通过 llama.cpp 的 -ngl 或 litgpt 的 json_schema 实现类似效果 json.loads(response) 遇到单引号、尾逗号、注释就崩，而模型真会这么干 如果必须手动解析，至少先用正则提取 json 块：
import re<br>match = re.search(r"<code>json\n(.*?)\n</code>", response, re.DOTALL)<br>data = json.loads(match.group(1)) if match else {}
立即学习“Python免费学习笔记（深入）”；
事情说清了就结束。真正麻烦的从来不是写模板，而是每次换模型都要重新校验 token 边界和分隔符行为——这点没人替你记，只能自己存一份 model_name → chat_template → sample_input → encoded_ids 对照表。
