Prompt Engineering 实用技巧，我总结了这些

#

用大模型一年多了，写了不少 Prompt。从最开始"帮我写个 xxx"的大白话，到现在能让模型按我要的格式和风格精确输出，走了不少弯路。把真正实用的技巧整理一下。

零样本和少样本提示

#

零样本（Zero-shot）：直接给指令，不带示例。

请将以下英文翻译成中文：Hello, how are you?

简单任务零样本就够了。但稍微复杂点，模型可能理解不了你想要什么格式。

少样本（Few-shot）：给几个示例让模型"学"你要的格式和风格。

请对以下评论进行情感分类。

评论：这家店太好吃了，下次还来！
分类：正面

评论：等了一个小时才上菜，再也不来了
分类：负面

评论：东西还行，但价格偏贵
分类：

有了示例，输出格式一下就稳定了。我的经验：能给示例就给示例，虽然多费点 Token，但输出质量提升明显。特别是需要特定格式的时候，少样本几乎是必须的。

角色设定

#

在 System Prompt 里给模型一个角色身份：

你是一个有10年经验的 Java 后端工程师，擅长 Spring Boot 和微服务架构。
回答简洁专业，附带代码示例。

设了角色之后回答会更有深度、更有针对性。我审查代码的时候喜欢用"你是一个严格的代码审查专家"，效果比随口说"看看这代码有没有问题"好太多。

角色设定还有个好处：限定回答范围。设定"你是 Java 专家"，它就不太会扯到 Python 方案去。

思维链（Chain of Thought）

#

这是个很强的技巧。让模型一步步推理，而不是直接给最终答案。

最简单的方式——加一句"请一步步思考"：

一个水池有两个进水管和一个出水管。
A管每小时进3吨，B管每小时进5吨。
出水管每小时出2吨。水池容量20吨，多久能装满？

请一步步思考。

模型会把推理过程展开写出来，准确率高很多。不加这句的话，复杂推理容易直接算错。

更高级的是 Few-shot CoT——在示例里就展示推理过程：

问题：小明有5个苹果，吃了2个，又买了3个，现在几个？
思考：开始5个，吃了2个剩3个，买了3个，3+3=6。
答案：6个

问题：（你的实际问题）

我写算法题的时候经常让模型先分析思路再写代码。比直接让它生成代码靠谱很多，debug 了几次才总结出来的经验。

结构化输出

#

如果需要程序解析模型的输出，结构化格式很关键：

请分析以下文本的情感，以 JSON 格式返回：
{
  "sentiment": "正面/负面/中性",
  "confidence": 0.0-1.0,
  "keywords": ["关键词1", "关键词2"]
}

文本：今天天气真好，心情也不错，就是午饭有点难吃。

模型通常能很好地遵循 JSON 格式。OpenAI 还支持 JSON Mode，强制输出合法 JSON。

在 LangChain4j 里可以直接映射成 Java 对象：

record SentimentResult(String sentiment, double confidence, List<String> keywords) {}

interface Analyzer {
    @UserMessage("分析以下文本的情感：{{text}}")
    SentimentResult analyze(@V("text") String text);
}

框架会自动处理 JSON 解析和对象映射，写起来很舒服。

日常使用的实战技巧

#

分享几个我用下来觉得真好用的：

给明确的限制条件。“用 Java 17 语法”、“不要用第三方库”、“代码控制在 50 行以内”。限制越具体，输出越符合预期。

让模型先问你问题。需求不太明确的时候说"在开始之前，请先问我几个问题来确认需求"。模型会主动澄清不确定的点，最终输出质量更高。

复杂任务分步走。别把一大段需求一股脑丢给它。先设计方案，确认后再实现，最后再审查。每一步质量都会更好。

肯定句比否定句好使。“不要用递归"不如"请用迭代方式实现”。模型对肯定指令的遵循度更高。

重要约束多强调。关键要求可以在 Prompt 开头和结尾各出现一次。模型对首尾的内容会更重视（跟注意力机制有关）。

其实吧，Prompt Engineering 说到底就是跟模型沟通的技巧。我之前老觉得模型"不听话"，后来反思发现多半是我自己表达不够清楚。你的 Prompt 越精确，模型给的结果就越好。多试多调，慢慢就找到感觉了。