大模型网摘DeepSeek 提示词入门：用 few-shot 示例驱动输出
让模型按你想要的格式输出，讲十句道理不如给它一两个例子。这就是 few-shot（少样本）提示的核心：在提示词里塞进几组「输入 → 输出」示例，模型会模仿示例的风格、结构和细节程度来回答。对 DeepSeek 来说这招特别好用——V 系列通用对话模型执行力强，配合结构清晰的示例，输出稳定度会明显提升。这篇给你能直接粘贴的模板和几个避坑要点。
为什么示例比形容词管用
很多人写提示词喜欢堆形容词：「输出要简洁专业」「语言要生动」。这些描述对模型来说太模糊了。你说「简洁」，到底是一句话还是三行？你说「专业」，是学术论文腔还是技术文档腔？
一个示例胜过十个形容词。你给一条完整示例，模型立刻知道：长度多少、用什么标点、要不要编号、术语怎么处理。示例是把你的隐含期望「显性化」的过程，这比任何描述都精确。
DeepSeek 的中文语感好，示例里的中文表达习惯会被很好地继承，所以示例本身就用你目标场景的真实中文来写，不要用翻译腔。
什么时候用 few-shot
不是所有任务都需要示例。判断标准很简单：
- 需要用：输出格式有明确要求（JSON、表格、固定字段）、文风要模仿（改写、摘要成特定口吻）、任务边界模糊（什么算「重要信息」需要示例来定义）。
- 不用：事实问答、代码生成、数学计算这类任务，说清楚需求就行。数学和代码本来就是 DeepSeek 的强项，示例反而可能把它的注意力带偏。
- 深度思考模式下慎用：R 系列开思考模式时，模型会自己推理步骤。此时给示例主要是约束「最终答案的格式」，别给中间推理过程的示例，那会干扰它自己的推演。简单任务直接用 V 系列，不必触发深度思考。
模板一：结构化提取
适合从文本中提取固定字段，输出 JSON：
你是一个信息提取助手。从用户提供的商品评价中提取以下字段，以 JSON 输出：
product（商品名）、sentiment（好评/差评/中性）、issue（提到的问题，没有则为 null）。
示例1：
输入：买了这个保温杯，续航不行，半天就凉了，做工倒是不错。
输出：{"product": "保温杯", "sentiment": "差评", "issue": "保温效果差"}
示例2：
输入：物流很快，包装完好，杯子颜值在线，家人都说好看。
输出：{"product": "杯子", "sentiment": "好评", "issue": null}
现在处理以下评价，只输出 JSON，不要任何解释：
输入：{在这里粘贴评价文本}
要点：示例覆盖了不同情况（含问题、无问题），模型遇到边界情况才知道怎么处理。null 的用法也靠示例来定义，比写十行规则有效。
模板二：文风模仿与改写
适合把内容改写成特定口吻：
把下面的产品描述改写成小红书笔记风格。
示例1：
原文：本款乳液含有烟酰胺成分，可改善肤色暗沉，质地清爽不粘腻。
改写：熬夜脸有救了！！这瓶乳液我真的回购三次🙌 烟酰胺提亮是真有点东西，上脸秒吸收，完全不闷痘，黄黑皮姐妹冲！
示例2：
原文：此键盘采用热插拔轴体设计，支持全键无冲，适合程序员日常使用。
改写：程序员打工人快看这台键盘⌨️ 轴体能自己换，坏一颗不用换整把！打字手感一绝，写代码一整天手也不累，办公室摸鱼都更快乐了哈哈哈哈
现在改写以下原文，保持同样的风格、emoji 密度和段落长度：
原文：{在这里粘贴原文}
文风这种东西没法用规则描述清楚，但两个示例一摆，模型抓风格抓得又快又准。示例里故意保留了口语化的粗糙感，模型也会跟着学。
几个常见的坑
1. 示例别太多：两个到四个通常够用。示例过多会拉长提示词、增加成本，边际收益也递减。DeepSeek API 定价低，但任务复杂时上下文长度本身也会影响质量。 2. 示例要覆盖边界情况：如果你只给好评示例，模型遇到差评可能不知所措。最重要的那条示例，往往是你最不希望出现的极端情况。 3. 示例和指令别冲突：指令说「不要解释」，示例里却有解释文字，模型会摇摆。两者保持一致。 4. 格式靠示例锁定，不用求它：与其反复强调「请务必输出 JSON」，不如让每个示例都以合法 JSON 结尾，模型模仿得比你想象的忠实。
开放权重玩家的额外玩法
DeepSeek 开放权重、可本地部署，few-shot 在本地场景还有个好处：示例直接烧进系统提示词里，等于把你的格式要求固化成服务的一部分，团队里任何人调用都拿到一致输出，不用每次对话重新交代规则。
把这套方法用到你手头最烦的重复性任务上：找两条你亲手改到满意的输出，倒推成示例放进提示词，剩下的交给模型。示例给得准，一次就到位。