DeepSeek 提示词工程实战指南

更新时间：2026-08-12。模型能力与入口以 DeepSeek 官网 及当前账号页面为准。

导读

DeepSeek 提示词、DeepSeek Prompt、DeepSeek 提示词工程的核心不是堆「专业、深入、一步一步」，而是把任务写成可验收的规格：目标、证据、约束、输出契约与质检标准。上下文清楚时，DeepSeek 更容易稳定产出可改稿；上下文模糊时，它也会自信地空泛或编造。本文给你一套可复用的六要素结构、四类场景模板，以及用样例集迭代提示版本的方法。

这篇解决什么问题？

• 用六要素把「随便问问」改成可执行的任务书
• 拿到写作、分析、代码、推理四类可直接粘贴的模板
• 用诊断表定位空泛、格式漂移、幻觉、过长等问题
• 用固定样例集评估提示版本，而不是凭一次「感觉不错」

六要素提示结构

把每次请求写成六段（可压缩成短提示，但逻辑顺序不要乱）：

1. 任务：用动词写清要交付什么（改写、抽取、诊断、对比……）
2. 背景：读者是谁、场景是什么、当前卡在哪
3. 资料：模型必须依据的原文、数据、报错、政策片段
4. 约束：长度、语气、禁止项、不得虚构、资料外标「未知」
5. 格式：标题字段、表格、JSON、清单或固定段落顺序
6. 验收：什么叫完成——必须保留的事实、必须通过的自检项

角色：[可选，一句话即可]
任务：[动词 + 交付物]
读者 / 场景：[谁用、做什么决策]
资料：仅使用下方内容；缺失处写「未知」，禁止猜测。
约束：[字数/语气/禁止项/保密]
格式：[字段或结构]
验收：[必须核对的事实、通过条件]
完成后按约束逐项自检，再输出。
资料：
"""
[粘贴]
"""

最短可用版（日常对话）：「目标 → 证据 → 约束 → 输出结构 → 未知时先问」。先跑短提示，再只补失败点，比一次写超长「万能提示」更稳。

四类高频场景与模板

1. 写作与改写

目标是保留事实、服务读者行动，而不是「更华丽」。

面向[读者]改写下列资料，使其完成[行动]。
保留全部日期、数字、产品名与链接；不得新增未出现的功能或承诺。
输出：
1) 正文（≤[N] 字，语气：[正式/口语]）
2) 相对原文的语义变化清单（无则写「无」）
3) 仍缺的信息（最多 3 条）
资料：
"""
[粘贴]
"""

2. 分析与比较

先定维度与权重，再填表；缺证据的格子写「未知」，不要强制决出赢家。

按下列加权维度比较[选项 A/B/C]，只依据所给资料。
维度（权重）：[成本 30%] [风险 30%] [落地速度 20%] [可维护性 20%]
输出表格：维度 | A | B | C | 证据段落编号 | 置信度
另附：结论（1 段）、关键未知项、建议的下一步验证。
禁止用常识补全资料中没有的数字。
资料：
"""
[编号段落]
"""

3. 代码与排错

提供环境、最小代码、完整堆栈与预期行为；要求先测试/验证命令，再给最小补丁。

环境：[语言/框架/版本]；禁止新增依赖。
任务：[实现函数 / 诊断报错]
预期 vs 实际：[…]
完整错误栈 / 相关最小代码：
"""
[粘贴]
"""
输出顺序：
1) 最可能根因（1 个）+ 证据行
2) 我可复制执行的验证命令
3) 最小补丁说明
4) 回归测试点
证据不足时先提 ≤3 个澄清问题，不要给大段猜测代码。

更完整的编程流程见：DeepSeek 编程实战。

4. 推理与多约束决策

编号列出已知与硬约束，要求返回结论、可检查依据、约束核对与独立验证方法。需要深度推演时可配合推理模式，见：R1 推理解析。

已知事实（编号）：
1. …
2. …
硬约束（不可违反）：…
目标决策：[…]
请输出：
- 结论（一句话）
- 推理步骤（对应事实编号）
- 约束核对表（每条：满足/违反/未知）
- 独立验证方法（我可不依赖模型再查一次）
- 若事实冲突：列出冲突点，不要强行统一
禁止引入未编号的「常识事实」。

迭代诊断表：先定位失败，再改提示

不要只说「再详细一点」。一次只改一个变量，并保留同一测试输入。

症状	常见原因	改法
内容空泛	缺受众、缺资料、目标含糊	补场景 + 粘贴证据 + 明确交付物
格式漂移	只口头描述结构	给固定字段名或一行示例
编造事实 / 幻觉	强迫必须作答	允许「未知」；限定只用所给资料
过长灌水	未设范围与优先级	指定字数、段落数、先写结论
漏关键约束	约束埋在长文中间	把硬约束单独成段并放验收里
改了一处坏了另一处	一次改太多指令	发「补丁指令」：保留第 X 节，只重写第 Y 节
代码不可运行	缺版本与边界	写死环境；先要测试表再要实现

补丁指令示例：

保留第 1、3 节不变。
只用附件政策重写第 2 节；每条主张标注资料段落编号。
遇到冲突只标记，不自行仲裁。输出后按验收清单自检。

用样例集评测提示版本

「感觉更好」不可复现。团队或个人应维护一套小样例集：

1. 准备 12–20 个代表性输入（写作 / 抽取 / 推理 / 代码各若干）
2. 为每个样例写期望：必含事实、禁止项、格式是否有效、允许的未知处
3. 每次改提示后，用同一模型入口与参数重跑全套
4. 评分维度建议：准确、完整、格式通过、无依据主张数、人工修改分钟数
5. 记录：提示版本号、日期、入口（网页 / API）、模型名（以页面为准）

通过测试的短提示，优于听起来专业却未测过的长提示。API 侧版本管理可结合：DeepSeek API 入门。

日常检查清单

• 任务用动词写清交付物
• 有资料时已粘贴，并声明「资料外写未知」
• 硬约束独立成段（长度、禁止虚构、保密）
• 输出格式可机器/人工直接验收
• 失败时用诊断表定位，一次只改一处
• 重要流程有固定样例集与版本记录
• 敏感内容已脱敏后再上传

访问与入口

• 国内对话：DeepSeek V4
• 镜像工作台：AI Chat Studio
• 官方聊天：chat.deepseek.com
• API 文档：api-docs.deepseek.com

同一提示在不同入口的结果可能不同；重要流程应固定入口、模型与提示版本后再评测。

常见问题

要不要写「请一步一步思考」？

通常不必。清晰约束与可验证输出，比笼统要求「慢慢想」更有效。需要深度推演时，优先选推理能力并核对依据，而不是只加口头咒语。

提示越长越好吗？

不是。只保留完成任务必要的信息，删除冲突与重复。先短跑、再按失败点补丁，通常比一次塞满「角色设定小说」更稳。

如何减少幻觉？

限定资料范围、允许回答未知、要求可定位依据，并对日期、数字、链接做人工核验。关键决策不要把模型输出当唯一真相。

可以复用网上的万能提示吗？

可作为起点，必须用自己的样例集重测；换模型、换入口后旧提示可能失效。

角色扮演有用吗？

可选，一句话足够。真正拉开差距的是证据、约束与验收，而不是更长的人设。

网页对话和 API 提示写法要分开吗？

原则相同；API 更强调稳定格式（JSON/schema）、温度等参数与版本记录，详见 API 指南。

官方资源

• DeepSeek 官网
• 官方聊天
• API 文档

下一步阅读

• DeepSeek 编程实战
• DeepSeek R1 推理解析
• DeepSeek V4 完整指南
• DeepSeek API 申请与开发入门

小结

提示词工程本质是需求工程：任务、资料、约束、格式、验收写清楚，再用固定样例迭代版本。把 DeepSeek 当可验收的执行器，而不是「说得越多越好」的聊天对象，输出质量与人工修改成本都会更可控。