大模型网摘DeepSeek 网页对话与 API 提示词写法差异
同一个 DeepSeek，网页上聊得好好的提示词，搬到 API 调用里效果就垮了——这事不少人踩过坑。原因不复杂：网页端帮你把模型选择、思考开关、上下文拼接这些都默认处理好了，而 API 是裸的，你的提示词要独自承担全部「工程责任」。这篇把两边差异讲清楚，并给出可直接粘贴的模板。
先分清你用的是哪个模型
DeepSeek 目前两条产品线：V 系列走通用对话路线，响应快、适合日常问答和写作；R 系列带深度思考能力，会先推理再给答案，适合数学、代码调试、多步逻辑这类复杂任务。网页端通常允许你开关「深度思考」模式，具体入口以官方页面为准；API 则要在请求参数里直接指定模型 ID。
常见错误是：网页上开了思考模式调出一个满意结果，API 里却默认用了通用模型——同一个提示词，效果自然对不上。反过来也一样，简单任务挂着思考模式跑，不仅慢，还费 token。
网页对话：可以「省话」，API：必须「说全」
网页聊天是多轮的，模型记着上文，你可以说「再改短一点」「按刚才的思路来」。API 调用默认无状态，每次请求都要把必要上下文完整带上：任务描述、约束条件、输出格式、示例，一个都不能少。
对 R 系列深度思考模型，还有一个反直觉的要点：它不吃「角色扮演花活」。你写「你是一位有 20 年经验的大厂资深架构师」，对它几乎没有增益，反而可能引入噪音。它真正吃的是清晰的约束和结构化需求——把输入、要求、输出格式写明白，比堆人设有效得多。V 系列通用模型对角色设定的响应相对更敏感一些。
API 提示词模板一：结构化分析任务（推荐配深度思考模型）
text
【任务】分析以下用户反馈，判断属于哪类问题。
【输入】
用户反馈：{feedback_text}
【分类标准】
- 功能异常：产品功能无法正常使用
- 体验问题：能用但不好用
- 需求建议：希望新增或改进功能
- 其他：不属于以上任何类别
【要求】
1. 先分析反馈内容，再给出结论
2. 若一句话可能属于多类，选最主要的一类并说明理由
3. 严格按以下 JSON 格式输出，不要输出其他内容：
{"category": "分类名", "reason": "一句话理由"}
这类模板的关键：分类标准穷举、输出格式锁死 JSON。深度思考模型会自己完成推理链，你不需要教它「怎么想」，只需要约束它「输出什么」。
API 提示词模板二：日常对话类任务（通用模型即可）
text
你是一名中文内容编辑。请根据以下要求改写一段文字。
原文：{source_text}
改写要求：
1. 保留全部事实信息，不得添加原文没有的内容
2. 语气从口语改为书面，适合发布在公司官网
3. 长度控制在原文的 80%~100%
4. 直接输出改写结果，不要任何解释或前言
这种任务不需要深度思考，用 V 系列通用模型，响应快、成本低。DeepSeek API 定价本身偏低，但简单任务不触发思考模式，依然是省钱的直接手段。
网页端验证，API 端固化
一个实用工作流：先用网页对话快速试错——多轮调整措辞、开关思考模式对比效果，成本几乎为零；等提示词稳定后，把它改写成上面那种自包含的 API 模板：补全上下文、锁死输出格式、去掉「刚才」「上面」这类依赖对话历史的指代。两边角色定位不同：网页端是实验室，API 端是生产线。
最后提醒一句：无论哪端，涉及模型版本、参数名、计费方式的信息，都以 DeepSeek 官方页面为准，本站为非官方资讯站，仅作使用经验分享。把「网页试出来的提示词」原样搬进 API，是效果翻车的头号原因；补全上下文、按模型特性写提示词，才是稳定输出的前提。