deepseek提示词技巧教程

很多人用 DeepSeek 的卡点不在模型本身：问一句答一段，看着热闹，改起来比重写还费劲。问题多半出在提示词没交代任务、没给参照、没说清交付形态。这篇不讲玄学，把「怎么问—怎么改—怎么验收」拆成可照做的步骤，每个技巧配一个能套用的示例，也写清哪些场景下这套写法不适用。

很多人用 DeepSeek 的卡点不在模型本身：问一句答一段，看着热闹，改起来比重写还费劲。问题多半出在提示词没交代任务、没给参照、没说清交付形态。这篇不讲玄学，把「怎么问—怎么改—怎么验收」拆成可照做的步骤，每个技巧配一个能套用的示例，也写清哪些场景下这套写法不适用。

另外提醒一句：模型版本、上下文长度、各家接口的实际表现会随时间变，本文只讲写法。想核对 DeepSeek 当前有哪些模型、上下文多长、价格怎么算，去站内模型库和价格页看当时的数字，别拿别人截图里的旧信息当准。写法是通用的，参数是流动的。

先说清：为什么你的 DeepSeek 回答总是「没毛病但没用」

先给判断标准：拿到一段回答，先问自己「这段能直接交出去吗」。答案是不能，就先别急着追问，回看提示词缺了哪一项。多数时候不是模型笨，是你把关键约束留在了脑子里没写出来。

模型会主动补齐你没说的信息，但补的内容不一定是你想要的。你不说受众，它默认写给「一般读者」；你不说形态，它默认给一大段散文；你不说范围，它自选重点。所以关键约束要显式写出来，而不是指望它猜。

• 先分清是「信息不够」还是「约束不够」：信息不够就补背景，约束不够就补格式；
• 同一句话换个问法仍不对，多半是任务本身没说清，不是措辞问题；
• 把每次踩的坑记一行，积累成自己的约束清单，比反复试错快。

四格结构：一个能直接套用的提问骨架

四格结构就是四句话：角色与场景、任务与产出物、约束条件、验收标准。每格一句就够，不用写小作文。写多了反而容易互相打架，尤其约束一多，模型会顾此失彼。

角色与场景

你在什么身份、什么场景下用这份输出，比如给团队做一次内部分享

任务与产出物

要做出什么东西，具体到份数、页数、类型

约束条件

字数或条数、语言风格、必须包含与必须避免的内容

验收标准

你怎么判断它合格，比如「能直接贴进周报不用改」

• 约束里最好用的三类：字数或条数、语言风格、必须包含和必须避免的内容；
• 四格别写满，留一两处给模型自己发挥，否则输出会变得很僵；
• 先写骨架再发问，比来回追问三四轮省时间。

不适用的情况也要说清：纯头脑风暴、你自己也还没想清楚要什么的时候，先发散再收紧，别一上来就卡死格式。思路没打开就被格式框住，往往出来的东西既没新意也不实用。

给一个例子，胜过写十句形容词

形容词是最低效的约束。「专业一点」「生动一点」「接地气一点」，每个人理解都不一样。换成给一个样例，让模型照着这个长度、语气、结构来，效果通常立刻不一样。

1. 先写样例自己动手写一小段你满意的输出，长度不用长，够体现结构就行，然后说「照这个来」。
2. 没样例就给反例贴一段你不想要的片段，指出具体哪里不对，比如「太绕，主语和动作分不清」，比抽象要求准得多。
3. 多个样例要排序按「好—更好」排出顺序，并说明排序理由，别只丢一堆文本让它自己猜哪个是目标。

注意一个坑：样例和任务不匹配时，模型会硬套样例格式。比如你给的是产品说明，却要它写内部通知，它会连说明的语气一起搬过去。这种时候宁可少给，或者明确说「只参考结构，不参考语气」。

把大任务拆成步骤，再用反向提问补漏

长任务分两轮做：第一轮让模型复述任务并列出提纲，你确认方向没错，再让它展开。这一步看着多余，实际上能拦掉大半「写完才发现跑偏」的情况。

反向提问是另一个好用的动作：让它先说出这个任务最容易翻车的三个点，你据此补约束。它列出的风险点不一定都对，但能帮你想起来自己漏说了什么。

• 对事实类问题，要求它标注没有把握的部分，而不是硬编一个肯定答案；
• 涉及要核对数字的地方，直接说「不确定就留空，我来填」，比事后逐条查更快；
• 拆步骤会拉长对话，简单任务别硬拆，拆过头反而慢。

追问与改写：不满意时怎么改第二轮

追问别只说「不行，重写」。按「指出问题—给出方向—限定范围」的顺序说：先说哪一段不对、哪里不对，再说希望往哪个方向改，最后限定只改这一部分、其余保持原样。这样能避免整段漂移，越改越远。

有个经验判断：同一段反复改到第三轮还没到位，通常说明原始提示词就有问题。这时候回去改骨架，比继续磨省时间。继续磨往往只是把错误往不同方向挪。

1. 圈定范围明确说「只改第二段，其余不动」，避免它顺手把好的部分也改掉。
2. 给方向不给重写说清往哪改，比如「把结论提到最前面」，而不是让它自由发挥。
3. 沉淀模板改好的版本存成自己的模板，下次换主体不换结构，能省下大量重复描述。

控长度、控格式：让输出直接能贴进文档

字数要求给区间而不是单点，并说明超出或不足时优先保哪部分。只说「写短点」，模型不知道是该砍例子还是砍结论，结果常把关键信息砍掉。

形态先说清楚：分点、表格、段落三种各有适用场景，先说要哪种，再要求别混着来。想要清单就限定条数并说明每条大概多长，否则容易变成一句话拆成五行的废话。

• 术语和专有名词要求统一写法，避免同一份文档里出现三种叫法；
• 要求它保留原文里的数字和名称，不要自行改写；
• 涉及需要核对的参数，让它在句末标注「待核对」，你再去站内页面确认。

几个实战示例：写作、整理、提问式学习

下面三个场景覆盖了日常大多数用法。每个示例都附一句「哪里可以替换」，方便你换成自己的内容，不用照抄。

1. 写作场景第一轮只要提纲和大纲层级，确认结构后再要正文，正文阶段再补语气和长度约束。好处是方向错了只损失一份提纲。
2. 资料整理场景把素材贴进去，要求按主题归类，并单独列出重复出现的说法和互相矛盾的地方。矛盾项让它标出来但别急着下结论，你自己判断。
3. 学习场景让它先出题再讲解，用问答检验你有没有真懂。答错的题让它换个角度再讲一遍，比直接看讲解记得住。

替换点说明：写作场景里，把主题换成你的题目即可；整理场景里，把素材换成你的会议记录或调研笔记；学习场景里，把学科换成你正在学的内容。结构不用动。

发出去之前的自检清单

最后给一份可以照着打勾的清单。不用每次都全写满，但缺了哪一项，就要预期输出会往哪偏。

• 任务、受众、产出形态、长度、必须包含项，这五个有没有缺；
• 有没有至少一个例子或参照，没有的话模型只能靠猜；
• 有没有说清「什么算合格」，也就是你打算怎么验收；
• 回答拿到后，先核对有没有编造的事实和数字，再决定用不用；
• 涉及模型参数、价格、上下文长度这类会变的数字，一律去站内页面核对当时的值。

这套写法也不是万能的。要创意、要发散、要它提出你自己没想到的角度时，四格结构反而会限制发挥。判断依据是：你需要的是「按要求交付」还是「帮你想」，前者用骨架，后者先放开再收。