#1. 非推理模型

非推理模型指的是 DeepSeek-V4 在「快速模式」下的工作方式，对应 API 中的 deepseek-v4-pro 与 deepseek-v4-flash 非思考模式（Non-Thinking Mode）。在这种模式下，模型不会进行显式的链式推理，而是直接根据提示词生成最终答案，响应速度快、调用成本低，适合日常对话、内容创作、信息抽取、批量任务等场景。

正因为非推理模型不会"边想边写"，提示词的结构化程度就成了决定输出质量的关键变量。同样一个需求，写得越清晰、约束越明确，模型的输出就越稳定可用。业界目前形成了两套较为成熟的结构化提示词框架：CO-STAR 框架和 BROKE 框架。前者偏向内容创作与沟通表达，后者偏向工程化任务与可验证产出。

下面分别介绍两套框架的构成、写法要点与完整示例。

#CO-STAR 框架

CO-STAR 由新加坡政府科技局在 2023 年的一场提示工程竞赛中提出并推广，强调对沟通要素的精细刻画。它由六个要素组成：

使用技巧：

• 六个要素不必每条都写满，根据任务取舍，但 Context、Objective、Response 三项建议必填
• Style 和 Tone 容易混淆，可以先写 Style 锁定形式，再用 Tone 微调情绪
• Audience 一栏越具体越好，"中型企业 IT 负责人"比"企业用户"更有效
• Response 中的格式要求，建议直接给出小节标题或字段名，不要让模型猜

完整示例：撰写企业产品发布稿

提示词：

# Context（上下文）
我们是一家成立四年的企业级数据分析 SaaS 公司，主要客户为零售、制造业的中型
企业（年营收 5 亿至 50 亿元人民币）。本次发布的是 v3.0 版本，核心更新有三点：
（1）引入自然语言查询能力，业务人员可直接用中文提问获得数据可视化结果；
（2）查询响应时间相比 v2.0 降低 60%；
（3）新增与主流 ERP 系统的预置连接器（用友、金蝶、SAP B1）。
当前市场环境：同类产品普遍仍依赖拖拽式 BI 操作，自然语言查询是差异化卖点。

# Objective（目标）
撰写一篇用于公司官网与微信公众号同步发布的产品发布稿，介绍 v3.0 的三大更新，
并引导读者预约产品演示。

# Style（风格）
正式的科技产品发布稿风格，结构清晰，段落紧凑。可参考国内头部 SaaS 公司
（如飞书、钉钉）发布新版本时的官方推文写法，但避免过度使用感叹号与营销话术。

# Tone（语气）
专业、克制、自信。强调产品价值而非情绪渲染。涉及性能数据时使用客观陈述，
描述用户场景时可适度共情。

# Audience（受众）
主要读者为中型企业的 IT 负责人、数据分析团队负责人、CIO。他们关心的是
落地成本、与现有系统的兼容性、对业务的实际价值，而非底层技术细节。

# Response（响应格式）
- 总长度 800 至 1000 字
- 输出为 Markdown 格式
- 包含以下小节：
  1. 标题（一级标题，体现 v3.0 与"自然语言"两个关键词）
  2. 引言段（约 150 字，点出本次更新的整体意义）
  3. 三大更新（每项以二级标题呈现，下设场景描述与价值说明）
  4. 客户价值小结（约 150 字）
  5. 行动号召（一句话引导预约演示，附预约入口提示）
- 不要使用第一人称"我"，统一使用"我们"或公司视角
- 不要编造具体客户名称或客户引言

适用场景

CO-STAR 在以下场景中表现突出：

• 营销文案、新闻稿、品牌故事
• 客户邮件、商务信函、对外公告
• 公众号、小红书、知乎等平台的内容创作
• 面向特定受众的科普文章与知识分享
• 演讲稿、致辞、宣传片旁白

简而言之，凡是"写给人看的文字"，CO-STAR 都是首选。

#BROKE 框架

BROKE 框架源自工程实践社区，相比 CO-STAR 更强调任务的可执行性与产出的可验证性。它由五个要素组成：

使用技巧

• Role 与 Objectives 是 BROKE 的发力点，写得好就成功了一半
• Key Result 不要写"输出要好"这种空话，要写"哪些条件全部满足才算好"
• Evolve 部分可以让模型自己列出"分析的局限"或"需要补充的信息"，相当于免费做了一轮自我审稿
• 复杂任务可以把 Objectives 写成 5 至 10 步的清单，比期待模型自己拆解更可靠

完整示例：客户反馈数据分析

提示词：

# Background（背景）
我们是一款面向中小企业的财税 SaaS 产品，最近一个月内通过客服渠道、应用商店
评论、用户调研三种来源收集到约 240 条用户反馈。这批反馈已经整理为统一的
CSV 格式，字段包括：feedback_id、source、submitted_at、user_segment、
raw_text、initial_label。其中 initial_label 是客服初步打的标签，但准确率
仅约 70%，不可完全依赖。本次分析的产物将用于下周的产品月会决策。

# Role（角色）
你是一位拥有八年经验的 B 端 SaaS 产品分析师，擅长从非结构化用户反馈中
提炼可执行的产品洞察，熟悉 Jobs-to-be-Done 与 Kano 模型。

# Objectives（目标）
基于我接下来粘贴的反馈文本，完成以下任务：
1. 将所有反馈归并为不超过 8 个主题类别，每个类别给出明确定义。
2. 统计每个类别的反馈数量，并按数量降序排列。
3. 对排名前 3 的类别，分别给出代表性反馈摘录（每个类别 2 至 3 条原文片段）。
4. 针对前 3 个类别，输出对应的产品改进建议，每条建议需说明：
   - 建议要解决的具体问题
   - 建议的方向（不要求技术细节）
   - 预期的用户价值
5. 标注哪些反馈属于"信号噪音"（如纯抱怨、与产品无关、明显误用），并简述判断依据。

# Key Result（关键结果）
合格的输出应同时满足以下条件：
- 输出格式为 Markdown，包含上述 5 个小节，分别使用二级标题。
- 类别定义需互斥，避免同一条反馈可同时归入多个类别。
- 所有数量统计必须与"分类汇总表"一致，不能出现总数不符。
- 改进建议必须聚焦产品层面，不涉及销售、价格、服务态度等非产品维度。
- 全文不引入 CSV 中未出现的虚构信息。

# Evolve（迭代）
在正文之后追加一节"分析的局限与建议"，指出：
- 本次分析中你识别出的、需要更多数据才能下结论的灰色地带；
- 如果允许下一轮提问，你建议我补充哪些信息以提升洞察质量；
- 哪些类别的样本量偏少（少于 5 条），其结论需谨慎对待。

请确认你已理解上述要求，然后等待我粘贴反馈数据。

适用场景

BROKE 在以下场景中表现突出：

• 数据分析与洞察提炼
• 代码生成、代码审查与重构建议
• 技术方案撰写、架构评审
• 结构化信息抽取（如从合同、简历、报告中提取字段）
• 流程自动化任务（如批量分类、批量打标）
• 需要多轮迭代、产物会被复用的复杂任务

简而言之，凡是"输出需要被验证、被使用、被迭代"的产物，BROKE 都更合适。

#CO-STAR 与 BROKE 的选择

两个框架并非互斥，而是各有侧重：

实际工作中也存在融合写法。例如撰写一份"面向投资人的技术尽调报告"，既需要 CO-STAR 中对受众与风格的精细控制，也需要 BROKE 中对结论可验证性的严格要求。这种情况下，可在 BROKE 的 Background 之外补充 Audience 与 Tone 字段，组成自定义混合框架。

#面向非推理模型的优化建议

在两套通用框架之外，结合 DeepSeek-V4 非推理模式的特点，还有几条特定优化建议：

善用上下文：V4 系列支持百万 token 上下文，可以一次性放入完整资料。但在非推理模式下，过长的无关信息会稀释关键指令的权重。建议把核心任务说明放在提示词的开头与结尾两个位置，中间放参考资料。

输出样例：非推理模型不擅长从抽象描述推断格式细节。需要 JSON 输出时，直接在提示词里给出一个填好示例值的 JSON 模板；需要表格时，直接给出表头。

约束优先："不要使用感叹号""不要编造数据""不要超过 500 字"这类否定式约束，比"请保持克制""请尊重事实""请简洁"等正向鼓励更有效。

显式编号：多步骤任务不要假设模型会自动规划。BROKE 框架的 Objectives 部分采用编号列表正是这个原因。

先简后繁：非推理模式调用成本低、响应快，适合"快速迭代提示词"的工作方式：先用一小段样本测试提示词效果，确认后再批量处理。