Prompt Engineering 解决什么

Prompt Engineering 最该解决的问题很朴素：把任务说清楚。

大模型不是读心术。你不给输入边界、不说输出格式、不定义好坏标准，它就会按训练中最常见的写法补全。很多“模型不行”的问题，其实是任务单写得太糊。

它适合解决的 5 类问题

1. 任务目标不清

比如你只说“帮我分析这个产品”，模型会不知道你要用户分析、商业模式、竞品、技术可行性，还是文案建议。

更好的写法是：

请从目标用户、使用场景、付费动力、传播机制四个角度分析这个产品。每个角度只写判断和理由，不写泛泛建议。

2. 输入材料边界不清

模型需要知道哪些是事实、哪些是背景、哪些不能信。

比如：

• “以下是用户访谈原文，不要补充原文没有的信息。”
• “下面是旧版本 PRD，只能作为背景，新需求以后面的列表为准。”
• “如果资料不足，请直接标注缺口，不要猜。”

3. 输出格式不稳

如果结果要进入表格、数据库、工单或前端页面，格式必须提前约束。

不要只说“结构化输出”。直接给字段：

{
  "problem": "",
  "evidence": [],
  "risk_level": "low | medium | high",
  "next_action": ""
}

4. 口径和风格不一致

客服、销售、运营、教育内容都需要口径。提示词可以定义语气、禁用词、回答长度、是否允许反问。

但如果你需要长期稳定的品牌口吻，只靠提示词会吃力。那时要考虑示例库、评估集，甚至微调。

5. 需要模型按步骤思考

有些任务不是一句话能完成的。提示词可以要求模型先分类、再提取证据、再给结论。但如果任务涉及真实计算、联网检索、权限查询，就应该接工具，而不是让模型假装会做。

它不适合解决什么

Prompt Engineering 不能解决这些问题：

• 缺最新资料：要 RAG 或联网检索；
• 缺私有知识：要知识库和权限管理；
• 模型能力不足：要换模型、拆任务或加工具；
• 大规模稳定风格：可能要微调或模板系统；
• 事实可靠性：要引用、校验和评估，不是写一句“请不要胡说”。

一个好提示词的骨架

任务：你要完成什么。
输入：下面材料分别是什么，可信程度如何。
输出：字段、格式、长度、语言。
判断标准：什么算好，什么算错。
限制：不能编、不能越界、信息不足时怎么说。
示例：给一个正例，必要时给一个反例。

真正有用的提示词不是花哨咒语，而是把任务边界写到模型无法轻易误解。

下一步读：RAG 解决什么，看什么时候该补资料而不是继续调提示词。