【亲测有效】DeepSeek极简入门与应用_161.[第6章高级应用技巧] 框架选择决策树：不同任务该用哪种提示词框架

机器爱上学习

530人浏览 · 2026-05-18 18:39:31

机器爱上学习 · 2026-05-18 18:39:31 发布

在这里插入图片描述

还在用"万能提示词"硬怼所有任务？一张决策树让你秒变Prompt架构师，彻底告别"框架选择困难症"！本文将带你拆解6大主流提示词框架的适用边界，从结构化输出到复杂推理，从创意生成到代码调试，手把手教你建立"任务-框架"的精准映射关系，让DeepSeek的输出质量直接起飞。

目录速览

结构化输出场景：JSON/XML/Markdown表格的精准选择
复杂推理场景：CoT/ToT/ReAct的递进式应用
创意生成场景：Few-Shot/角色扮演/约束创作的三板斧
代码相关场景：伪代码/测试驱动/代码审查的实战组合
多轮对话场景：上下文管理、记忆注入与状态追踪
知识检索场景：RAG/知识图谱/多源验证的进阶玩法

嗨，大家好呀，我是你的老朋友精通代码大仙。接下来我们一起学习《DeepSeek极简入门与应用》，震撼你的学习轨迹！

“工具选不对，努力全白费。”

这句话放在Prompt工程上，简直不要太真实。我见过太多小伙伴，拿着一个"万能模板"去怼所有任务——写代码用它，写文案用它，做数据分析还用它。结果呢？DeepSeek给出的答案总是差那么点意思，不是格式混乱，就是逻辑跑偏，最后还得自己手动改半天。

更扎心的是，很多人根本不知道问题出在哪。他们以为是模型不够聪明，其实是自己没给对"脚手架"。

今天这篇，我就当一回"框架导航员"，带你建立一张清晰的决策地图。看完你会发现：原来选对框架，DeepSeek的表现能差出十条街！

一、结构化输出场景：机器可读才是第一要义

点题

当你需要DeepSeek的输出能被程序直接解析、入库、或者传给下一个API时，结构化输出框架就是你的必选项。核心就三种格式：JSON模式、XML模式、Markdown表格。选哪个？看下游系统的"饮食习惯"。

痛点分析

新手最常犯的错，就是嘴上说要JSON，提示词里却完全不提格式要求。看这段"灾难现场"：

帮我分析这段用户评论的情感倾向。

DeepSeek可能给你回一大段自然语言分析，情感是正面还是负面？得你自己从文字里抠。要是批量处理一万条评论，这不得疯？

还有一种情况，要求了JSON但schema模糊不清：

请用JSON格式返回分析结果，包含情感和关键词。

结果每次输出的字段名都不一样，今天叫"sentiment"，明天叫"emotion"，后天又变成"feeling"。你的解析代码得写多少个if-else来兼容？

解决方案/正确做法

JSON模式：给机器看的，schema必须焊死

请分析以下用户评论，严格按以下JSON Schema返回结果：

```json
{
  "schema": {
    "sentiment": {"type": "string", "enum": ["positive", "negative", "neutral"]},
    "confidence": {"type": "number", "minimum": 0, "maximum": 1},
    "keywords": {"type": "array", "items": {"type": "string"}},
    "aspects": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "aspect": {"type": "string"},
          "sentiment": {"type": "string", "enum": ["positive", "negative", "neutral"]}
        }
      }
    }
  }
}

评论内容：{{user_comment}}


看到了吗？enum限定取值范围，type限定数据类型，嵌套结构用对象和数组说清楚。这样输出的JSON，你的代码可以直接`JSON.parse()`然后点属性，稳得很。

**XML模式：Java老项目和配置系统的最爱**

```markdown
请将以下配置信息转换为XML格式，根节点为<app-config>，使用属性而非子元素存储简单值：

配置项：
- 数据库连接池大小：20
- 超时时间：3000ms
- 开启缓存：true

要求：包含XML声明，所有字符串值进行CDATA包裹。

XML在属性vs子元素的选择、命名空间处理上，提前在提示词里约定好，能避免很多解析噩梦。

Markdown表格：给人快速扫一眼的场景

请对比三种前端框架的特点，用Markdown表格呈现，包含：框架、学习曲线、适用场景、社区活跃度四列。

表格的优势是一目了然，适合放在文档里或者聊天窗口快速浏览。但别指望程序能稳定解析Markdown表格，那正则写起来能要人命。

小结

结构化输出的核心原则是"下游优先"——你的数据给谁用，就用谁听得懂的格式。JSON给API，XML给Java老项目，Markdown表格给人类快速阅读。schema定义越严格，模型输出越稳定。

二、复杂推理场景：让DeepSeek"慢思考"

点题

遇到数学计算、逻辑推理、多步骤决策这类任务，你需要的是"思维框架"：CoT（Chain of Thought，思维链）、ToT（Tree of Thoughts，思维树）、ReAct（Reasoning + Acting，推理行动）。复杂度递进，适用场景各不相同。

痛点分析

很多人用DeepSeek做数学题，直接扔题干：

小明有15个苹果，给了小红3个，又买了8个，最后吃了2个，还剩几个？

模型可能直接蹦出个"18"，对了是运气，错了你也不知道它哪步算岔了。更隐蔽的问题是"幻觉推理"——模型为了凑答案，硬编中间步骤，看起来头头是道，实则漏洞百出。

还有小伙伴听说CoT好用，就无脑加"请一步一步思考"，结果发现简单问题反而变啰嗦，复杂问题还是搞不定。这不是框架的错，是用错了地方。

解决方案/正确做法

CoT思维链：单路径推理的标准解法

请解决以下问题，并在最终答案前，用【思考过程】标签展示完整的推理步骤：

问题：一个水池有两个进水管，A管单独注满需6小时，B管单独注满需4小时。同时打开两管，注满水池需要多少小时？

要求：
1. 先明确已知条件和所求
2. 列出工作效率的数学表达
3. 计算合作效率
4. 得出最终时间
5. 用【最终答案】标签输出结果

关键不是那句"一步一步思考"，而是显式指定推理步骤的结构。让模型把中间过程"说出来"，你既能验证逻辑，也方便调试。

ToT思维树：需要探索多种方案时

我需要为一个电商系统设计推荐算法，请用思维树方式分析：

【问题】如何平衡推荐系统的准确性和多样性？

请生成3个不同的解决思路（分支），对每个分支：
1. 描述核心策略
2. 分析预期效果
3. 列出主要风险
4. 给出可行性评分（1-10）

最后，基于评估选择最优分支，并说明理由。

ToT的精髓是"先发散，再收敛"。适合策略制定、方案选型这类没有标准答案的开放问题。DeepSeek会自己扮演"头脑风暴参与者+评委"的双重角色。

ReAct：需要与外部世界交互时

你是一个数据分析助手，可以使用以下工具：
- search(query): 搜索互联网获取实时信息
- calculate(expression): 执行数学计算
- python(code): 运行Python代码

请按以下格式解决问题：
思考：分析当前状态，决定下一步行动
行动：选择工具及参数，格式为【工具名:参数】
观察：记录工具返回结果
...（重复直到问题解决）

问题：2024年Python和JavaScript的GitHub star数量差距是多少？

ReAct把"推理"和"行动"解耦，模型自己决定什么时候查资料、什么时候计算、什么时候写代码。这是构建Agent的基础框架。

小结

推理框架的选择看"路径复杂度"：单一路径用CoT，多方案探索用ToT，需要外部工具用ReAct。记住，让模型"慢思考"不是让它啰嗦，而是让思考过程可见、可验证、可调试。

三、创意生成场景：给想象力装上方向盘

点题

写文案、起名字、编故事、设计营销方案——这些需要"脑洞"的任务，最怕的是"一片空白"和"天马行空收不住"。三大框架帮你拿捏分寸：Few-Shot示例定风格，角色扮演定视角，约束创作定边界。

痛点分析

“帮我写个产品文案”——这种提示词，等于把方向盘完全交给DeepSeek。它可能给你写个文艺散文，而你想要的是带货感；可能写得太正式，而你的用户是Z世代。

更常见的是"风格漂移"：同一个提示词多次运行，每次调性都不一样。今天像罗永浩，明天像李佳琦，后天又像央视主播。品牌一致性？不存在的。

还有一种痛苦叫"收不住"：让写200字，回你800字；让口语化，结果网络梗满天飞，老板看了直摇头。

解决方案/正确做法

Few-Shot示例：用例子教风格

请为新款降噪耳机写3条朋友圈文案，参考以下风格示例：

示例1（科技简约风）：
"48dB深度降噪，一戴即静。世界很吵，但你不必听见。"

示例2（场景代入风）：
"地铁轰鸣？飞机引擎？戴上它，只剩你和音乐的双向奔赴。"

示例3（数据说话风）：
"3麦AI通话降噪，100小时续航。参数党看了都沉默。"

现在，为产品"睡眠耳塞"写3条同风格文案，每条控制在30字以内。

Few-Shot的魔力在于"示范优于描述"。你说"要文艺"，每个人理解不同；但你给几个例子，模型瞬间get到那个味儿。

角色扮演：锁定视角和身份

角色设定：
你是一位有10年经验的母婴博主"暖暖妈"，说话亲切、爱用emoji、经常分享真实踩坑经历。粉丝主要是25-35岁的新手妈妈。

任务：推荐一款婴儿湿巾，要求：
- 用第一人称"我"
- 提到一个具体的使用场景
- 包含一个"差点选错"的小故事
- 结尾引导评论区互动

角色扮演不是换个称呼那么简单，它是一整套语境的植入——知识背景、语言习惯、价值观、甚至口头禅。DeepSeek会基于这个"人设"自动生成一致的内容。

约束创作：用规则画边界

请为咖啡店写一周朋友圈文案，严格遵循以下约束：

【硬性约束】
- 每天一条，共7条
- 每条必须包含：产品名+价格+一个情绪关键词
- 字数：25-35字（含标点）
- 禁止用词：便宜、优惠、折扣、快来

【软性约束】
- 周一到周五偏理性（提神、效率）
- 周末偏感性（放松、治愈）
- 周三埋个小彩蛋（谐音梗或冷知识）

约束创作是给创造力"打框架"。硬性约束用数字和禁止清单，软性约束用场景和氛围描述。DeepSeek会在框内跳舞，而不是到处乱撞。

小结

创意不是完全自由，而是"有纪律的发挥"。Few-Shot定调性，角色扮演定身份，约束创作定边界。三者可以叠加使用——给例子、设角色、加约束，让DeepSeek的脑洞精准命中你的靶心。

四、代码相关场景：从描述到交付的全链路

点题

写代码、改bug、做重构、写测试——程序员和DeepSeek打交道最多的场景。三种框架覆盖全流程：伪代码描述搭骨架，测试用例驱动定契约，代码审查模式保质量。

痛点分析

“帮我写个排序算法”——这种需求，DeepSeek可能给你个冒泡排序，而你要的是处理千万级数据的工业级实现。信息不对等，输出必然错位。

更坑的是"看似能跑，实则埋雷"：生成的代码语法没错，但边界条件没处理、异常没捕获、性能没考虑。直接复制粘贴到生产环境？明天P0事故就是你。

还有一种痛苦：代码能跑，但风格混乱、命名随意、注释缺失。接手的同事骂骂咧咧，而你也不好意思说是AI写的。

解决方案/正确做法

伪代码描述：先对齐思路，再生成代码

请用Python实现一个LRU缓存，先阅读以下伪代码逻辑，再生成完整实现：

CLASS LRUCache:
INIT(capacity):
self.capacity = capacity
self.cache = 有序字典 // 保持插入顺序

GET(key):
    IF key 不在 cache: RETURN -1
    将key移到字典末尾  // 标记为最近使用
    RETURN cache[key]

PUT(key, value):
    IF key 已在 cache:
        更新value
        将key移到末尾
        RETURN
    IF len(cache) >= capacity:
        删除字典第一个元素  // 最久未使用
    添加key-value到字典末尾


要求：
- 使用collections.OrderedDict或类似机制
- 时间复杂度O(1)
- 包含类型注解
- 添加3个典型用例的doctest

伪代码是"需求翻译层"。把你脑子里的逻辑用结构化方式表达，DeepSeek就能少猜一点、少错一点。

测试用例驱动：用契约约束实现

请实现一个函数`parse_log_line(line: str) -> dict`，必须满足以下测试用例：

```python
# 测试用例1：标准格式
parse_log_line("2024-01-15 10:30:45 [INFO] User login: alice")
# 预期: {"timestamp": "2024-01-15 10:30:45", "level": "INFO", "message": "User login: alice"}

# 测试用例2：缺少级别
parse_log_line("2024-01-15 10:30:45 User logout: bob")
# 预期: {"timestamp": "2024-01-15 10:30:45", "level": None, "message": "User logout: bob"}

# 测试用例3：异常格式（应抛出ValueError）
parse_log_line("not a log line")  # 抛出 ValueError

先输出你的实现，然后说明如何处理测试用例3的边界情况。


测试用例是"可执行的需求文档"。DeepSeek会围绕这些用例生成代码，天然具备可验证性。你甚至可以让它先写测试，再写实现——TDD的AI版本。

**代码审查模式：质量把关**

```markdown
请对以下代码进行审查，按以下维度输出报告：

【代码】
```python
def fetch_data(url):
    r = requests.get(url)
    return r.json()

【审查维度】

异常处理：是否捕获了可能的异常？
安全性：是否存在注入或泄露风险？
性能：是否有明显的性能问题？
可读性：命名和结构是否清晰？
Pythonic：是否符合Python最佳实践？

【输出格式】

每个维度：问题描述（如有）+ 严重级别（高/中/低）+ 修改建议
最后给出重构后的完整代码


代码审查模式让DeepSeek扮演"资深同事"的角色。它的视角比你更客观，能发现你习以为常的坏味道。

### 小结

代码场景的核心是"先共识，后实现"。伪代码对齐思路，测试用例定义契约，代码审查保障质量。记住：AI写的代码，责任在你。审查环节不能省。

---

## 五、多轮对话场景：上下文是稀缺资源

### 点题

复杂任务往往需要多轮交互，但DeepSeek的上下文窗口有限，且模型会"遗忘"早期内容。三大技术帮你管理：上下文窗口管理做取舍，记忆注入技术做补偿，对话状态追踪做同步。

```mermaid
%%{init: {'theme': 'base', 'themeVariables': { 'fontFamily': 'Microsoft YaHei', 'fontSize': '13px'}}}%%
flowchart TD
    A["多轮对话优化"] --> B["上下文窗口管理"]
    A --> C["记忆注入技术"]
    A --> D["对话状态追踪"]
    
    B --> B1["滑动窗口保留最近N轮"]
    B --> B2["摘要压缩历史信息"]
    B --> B3["主动遗忘无关内容"]
    
    C --> C1["关键信息显式提取"]
    C --> C2["结构化记忆存储"]
    C --> C3["定期重新注入"]
    
    D --> D1["状态变量显式定义"]
    D --> D2["每轮确认当前状态"]
    D --> D3["异常状态自动恢复"]
    
    style A fill:#ff6b6b,stroke:#1a1a2e,color:#fff
    style B fill:#ff9ff3,stroke:#1a1a2e,color:#1a1a2e
    style C fill:#feca57,stroke:#1a1a2e,color:#1a1a2e
    style D fill:#54a0ff,stroke:#1a1a2e,color:#1a1a2e

痛点分析

最经典的翻车现场：和DeepSeek聊了20轮，终于把需求说明白了，结果它突然"失忆"，把第一轮确认过的关键约束给忘了。你气得想砸键盘，但其实是自己没管好上下文。

还有一种情况：对话越来越长，模型的回复质量明显下降。早期的细节被挤出了窗口，或者淹没在噪声里。你感觉它在"敷衍"，其实是它真的"记不住了"。

更隐蔽的问题是"状态混乱"：多轮对话中，需求改了、方案换了、约束加了，但模型还在用旧状态推理。最后输出的东西，和当前讨论完全对不上。

解决方案/正确做法

上下文窗口管理：主动做减法

【对话策略：滑动窗口 + 关键摘要】

每5轮对话后，我将提供以下结构化摘要，请基于摘要继续：

```yaml
项目背景: [一句话概括]
当前目标: [本轮要解决的具体问题]
已确认决策: [列表，如：技术选型React、数据库用PostgreSQL]
待解决疑问: [列表，如：认证方案待定、部署流程不明确]
约束条件: [列表，如：预算10万、2个月上线、团队3人]

请确认理解以上状态，然后继续讨论[当前目标]。


这不是让DeepSeek自己记，而是**你把记忆"外化"出来**，定期重新注入。相当于给对话做"存档点"，随时可以读档。

**记忆注入技术：关键信息反复提醒**

```markdown
【系统提示词 - 长期有效】

你正在协助我设计一个微服务架构。以下关键约束必须始终遵守，即使后续对话中未提及：

1. 必须支持水平扩展，无状态设计
2. 数据库选型已确定为MySQL 8.0，不可更改
3. 所有服务间通信必须使用gRPC，REST仅用于外部网关
4. 认证统一使用JWT，禁止在服务层自行实现鉴权

每轮回复前，请快速自检：以上约束是否被违反？

关键约束要"置顶"，而不是指望模型记住。你可以把它放在system message里，或者每轮手动粘贴。成本是多一点token，收益是少很多返工。

对话状态追踪：显式同步

【状态追踪模板】

当前轮次：第7轮
对话阶段：方案细化 → 进入技术选型
用户意图：确认消息队列方案
已排除选项：RabbitMQ（运维复杂度）、自研（时间成本）
候选方案：Kafka vs RocketMQ
待决策点：吞吐量需求评估、团队技术栈匹配度

请基于以上状态，给出对比分析，并在回复末尾更新状态追踪。

状态追踪是"元对话"——关于对话的对话。它强迫双方对齐认知，减少"我以为你知道"的误会。

小结

多轮对话的本质是"在有限记忆中维持一致性"。窗口管理做取舍，记忆注入做补偿，状态追踪做同步。别让模型"猜"状态，要显式地"说"状态。

六、知识检索场景：当DeepSeek需要"查资料"

点题

模型知识有截止日期，且可能产生幻觉。需要事实性、时效性、专业性内容时，三大框架帮你 grounding：RAG检索增强给模型"开卷考"，知识图谱提示建立关联推理，多源验证框架交叉确认可靠性。

痛点分析

“2024年最新的人工智能发展趋势”——这种涉及时效性的问题，DeepSeek可能给你编一套听起来像那么回事，但细节全错的答案。因为它的知识截止了，又不好意思说"我不知道"。

更危险的是专业领域：医学、法律、金融，一个幻觉可能带来严重后果。你问"这个药和那个药能一起吃吗"，它可能给出看似合理实则危险的建议。

还有一种情况：问题需要跨文档关联，比如"对比A公司和B公司2023年的财报策略"。模型没有同时看过两份财报，很难做有效对比。

解决方案/正确做法

RAG检索增强：给模型配"参考资料"

【检索增强模式】

以下是从知识库中检索到的相关文档片段，请基于这些资料回答问题。如果资料不足以回答，请明确说明"信息不足"。

【检索结果】
[文档1] 来源：公司2023年报.pdf 第15页
"本年度研发投入占比提升至18.5%，重点布局AIGC和自动驾驶领域..."

[文档2] 来源：行业分析报告.pdf 第8页
"对比头部企业，该公司研发强度处于行业前20%水平..."

[文档3] 来源：技术白皮书.pdf
"AIGC业务线已组建200人团队，预计2024年Q3推出首款产品..."

【问题】
该公司2023年的研发策略是什么？与行业平均水平相比如何？

RAG的核心是"先检索，后生成"。模型被限制在提供的资料范围内回答，大幅降低幻觉风险。你需要做的是：把资料切分好、检索准、排序对。

知识图谱提示：关联推理的利器

【知识图谱推理模式】

已知以下实体关系网络，请回答关于影响力路径的问题：

实体：张三（CEO）、李四（CTO）、王五（投资人）
公司A（AI初创）、公司B（云计算大厂）、公司C（芯片公司）

关系：

张三 founder_of 公司A
李四 employee_of 公司A, previous_employee_of 公司B
王五 investor_in 公司A, board_member_of 公司C
公司A strategic_partner_of 公司C
公司B competitor_of 公司C


问题：如果公司C决定终止与公司A的合作，哪些实体会受到直接影响？请用关系路径说明。

知识图谱把隐式的关联显式化，适合做影响分析、风险传导、机会发现这类需要"连点成线"的推理。

多源验证框架：事实核查机制

【多源验证模式】

请对以下陈述进行事实核查，按步骤执行：

陈述："Python 3.12引入了真正的多线程并行，不再受GIL限制。"

步骤1：检索验证 - 搜索Python 3.12官方发布说明，确认GIL相关变更
步骤2：交叉验证 - 查找3个以上技术社区（Reddit/HN/StackOverflow）的讨论
步骤3：专家验证 - 查找Python核心开发者的博客或演讲
步骤4：一致性评估 - 各来源是否一致？如有分歧，分歧点在哪？
步骤5：置信度评分 - 高/中/低，并说明理由

最终输出：核查结论 + 关键证据摘要 + 建议的谨慎表述方式

多源验证是"怀疑一切"的工程化。让DeepSeek扮演调查记者，自己给自己找茬，最后给出经过交叉检验的结论。

小结

知识检索场景的核心是"grounding"——让模型的回答有迹可循。RAG给资料，知识图谱给关联，多源验证给可信度。记住：涉及事实，宁可让模型说"不知道"，也不要让它"编一个"。

写在最后

看完这六大场景、十几种框架，你是不是有点信息过载？别急，我给你画张" cheat sheet "：

你的任务	首选框架	关键记忆点
要机器解析的输出	JSON/XML/Markdown	schema焊死，下游优先
数学/逻辑/决策	CoT/ToT/ReAct	让思考过程可见
写文案/起名字/编故事	Few-Shot+角色+约束	例子定调，约束画框
写代码/改bug/做重构	伪代码+测试驱动+审查	先共识，后实现
多轮复杂对话	窗口管理+记忆注入+状态追踪	显式同步，定期存档
查资料/验事实	RAG+知识图谱+多源验证	给资料，限范围，交叉验

框架选择的本质，是给DeepSeek一个合适的"工作说明书"。没有万能模板，只有场景适配。就像你不会用螺丝刀去切菜，也别用一个提示词框架硬怼所有任务。

编程之路不易，但每一步成长都算数。今天的框架选择能力，明天就会转化为十倍的生产力。保持好奇，持续实验，你也能成为Prompt工程的高手。

最后送大家一句话：好的提示词工程师，不是会写多复杂的提示词，而是懂得在什么时候用什么样的框架。

咱们下篇见！

关注私信备注：“资料代找获取”，全网计算机学习资料代找：例如:
《课程：2026 年多模态大模型实战训练营》
《课程：AI 大模型工程师系统课程 (22 章完整版持续更新)》
《课程：AI 大模型系统实战课第四期 (2026 年开课持续更新)》
《课程：2026 年 AGI 大模型系统课 23 期》
《课程：2026 年 AGI 大模型系统课 21 期》
《课程：AI 大模型实战课 8 期 (2026 年 2 月最新完结版)》
《课程：AI 大模型系统实战课三期》
《课程：AI 大模型系统课程 (2026 年 2 月开课持续更新)》
《课程：AI 大模型全阶课程 (2025 年 12 月开课 2026 年 6 月结课)》
《课程：AI 大模型工程师全阶课程 (2025 年 10 月开课 2026 年 4 月结课)》
《课程：2026 年最新大模型 Agent 开发系统课 (持续更新)》
《课程：LLM 多模态视觉大模型系统课》
《课程：大模型 AI 应用开发企业级项目实战课 (2026 年 1 月开课)》
《课程：大模型智能体线上速成班 V2.0》
《课程：Java+AI 大模型智能应用开发全阶课》
《课程：Python+AI 大模型实战视频教程》
《书籍：软件工程 3.0: 大模型驱动的研发新范式.pdf》
《课程：人工智能大模型系统课 (2026 年 1 月底完结版)》
《课程：AI 大模型零基础到商业实战全栈课第五期》
《课程：Vue3.5+Electron + 大模型跨平台 AI 桌面聊天应用实战 (2025)》
《课程：AI 大模型实战训练营从入门到实战轻松上手》
《课程：2026 年 AI 大模型 RAG 与 Agent 智能体项目实战开发课》
《课程：大模型训练营配套补充资料》