Prompt Engineering
用语言精确地驱动模型
System Prompt 定身份和规则，User Prompt 提具体诉求。
在 Prompt 里给几个示例（few-shot）比纯指令（zero-shot）效果通常更好。
让模型"想清楚再答"——把推理过程写出来，准确率显著提升。
CoT 的多分支版本：探索多种思路再回头评估。
同一问题让模型答 N 次，取出现最多的答案。
让模型先答，再以"挑刺者"身份审一遍自己的回答。
强制模型输出 JSON 或指定 Schema 的结果，便于程序解析。
用户在输入里塞入指令，试图劫持你的 System Prompt。
稳定输出 JSON 的关键是把格式约束说清楚,并让模型只输出 JSON,不要夹解释文本。更可靠的做法是使用模型的结构化输出能力或工具调用 schema,再在服务端做 JSON parse 和 schema 校验。
- +Prompt 里要给字段名、类型、可选值和示例,不要只说"返回 JSON"
- +服务端必须处理解析失败、缺字段和多余字段,必要时重试或降级
- +高可靠场景优先用 schema/JSON mode/工具调用,纯 prompt 只是最低成本方案
CoT 让模型把复杂问题拆成中间步骤,降低一步到位答错的概率。它适合数学、规划、复杂判断,但对简单分类、事实问答和低延迟接口可能拖累速度、增加成本,甚至暴露不该展示的推理过程。
- +生产中常让模型内部推理,最终只输出简洁结论和必要依据
- +CoT 不是万能,错误的中间步骤会把模型带偏
- +对用户可见的答案要控制长度和安全性,不要直接泄露冗长推理草稿
核心是把用户输入当作数据,不是指令。系统规则要放在更高优先级位置,用户内容要加边界标记和任务说明,并明确模型不能执行用户文本里的越权指令。
- +检索文档、网页内容、工具返回值也可能带恶意指令,同样只能当数据
- +对高风险操作加权限校验和人工确认,不能只靠 prompt 防护
- +可以用输入分类、规则过滤和输出校验形成多层防线
Zero-shot 适合模型本来就会、要求简单明确的任务;Few-shot 适合格式特殊、标准细腻或希望模型模仿风格的任务。Few-shot 的价值是用例子对齐边界,但会占用上下文并可能让模型过拟合样例。
- +样例要覆盖正例、反例和边界情况,不要只给最理想输入
- +输出格式类任务通常很吃示例质量,坏示例会稳定地产生坏结果
- +样例顺序和相似度会影响结果,上线前需要在评估集上验证
Tree-of-Thought 适合需要探索多个候选路径的问题,比如复杂规划、搜索、推理题和策略选择。它不是线性一步步想,而是生成多个分支、评估分支、保留更有希望的路径继续展开。
- +ToT 通常比 CoT 更耗 token 和时间,不适合普通问答
- +分支评估可以由模型打分,也可以接规则、测试或外部环境反馈
- +关键价值在探索和回溯,不是把答案写得更长
Self-Consistency 是让模型用多次采样生成多个推理路径,再通过投票或聚合选出更一致的答案。它利用的是复杂问题上"多数独立路径指向同一结论"的信号,能降低单次采样偶然出错的概率。
- +它会显著增加调用成本,更适合高价值、低频、可投票的问题
- +投票适合选择题和短答案,开放生成任务要设计聚合规则
- +如果 prompt 或知识源本身错了,多采样也可能稳定地产生错误答案
Self-Critique 适合先生成草稿,再检查是否遗漏约束、格式、事实或边界条件。它在写作、代码、长答案和复杂任务中有用,但对事实正确性不能只靠模型自查,仍要结合检索、测试或规则校验。
- +批评标准要具体,例如检查 JSON schema、引用来源、是否回答问题
- +自我修正常见问题是越改越长,需要限制轮数和输出长度
- +对代码任务,真实测试比模型自评更可信