简介这份《DeepSeek 15天精通指南》面向初次接触AI工具的新手以及希望借助AI助手提升办公与科研效率的专业人士帮助读者在两周多时间内完成从基础交互到专业场景应用的系统进阶。压缩包内仅含1个PDF文件大小约1.31MB内容按准备篇、基础对话、效率提升、场景实战等模块层层递进便于按章节顺序学习或按需查阅。目前已有221人学习下载。指南围绕有效提问的黄金法则、文档分析与代码编写、学术论文全流程辅助、自媒体内容生产等真实任务展开并配有避坑指南与进阶玩法如多语言切换、白板面试模拟等读者可据此掌握人机协作的提问思路与自动化任务搭建方法逐步培养用DeepSeek处理文献查阅、文案撰写、程序编制及科研辅助等工作的能力。1. 从“会聊天”到“能干活”15 天到底该练什么很多人用 DeepSeek 的方式其实停留在“高级搜索框”阶段问一句、答一句答得不好就换个问法再不行就骂模型不行。我见过一个做运营的同行每天用 DeepSeek 写文案用了三个月产出效率只比手写快了不到两成。问题不在模型在于他把一个能跑多轮推理、能挂外部工具、能约束输出格式的系统当成了单轮问答机。“15 天精通”这个说法听起来像营销话术但如果把“精通”拆成可验证的能力项——第 1 到 3 天把基础交互的边界摸清第 4 到 8 天掌握结构化提示与多轮上下文管理第 9 到 12 天跑通代码、文档、数据分析三类专业场景第 13 到 15 天做工作流封装和效果回归——15 天是够的。前提是每天练的不是“多问几个问题”而是针对一个具体交付物做迭代。这篇笔记面向两类人一类是刚接触 DeepSeek、想知道从哪下手的新手另一类是已经在用、但输出质量不稳定、想把它嵌进真实工作流的熟手。下面按“基础交互 → 结构化控制 → 专业场景落地 → 避坑 → 进阶技巧”的顺序推演每一步都落到可复现的操作上。2. 基础交互的四个控制维度别再把模型当搜索框2.1 角色、任务、约束、格式一条提示的四段结构新手最容易犯的错是把所有信息揉成一句话丢过去。比如“帮我写个周报”模型只能猜你的岗位、汇报对象、数据范围、篇幅要求。我一般会把提示拆成四段角色设定、任务描述、约束条件、输出格式。这四段不一定要写全但缺哪段输出就在哪个维度上失控。# DeepSeek 基础交互的四段式提示模板 prompt # 角色 你是一名有 5 年经验的电商运营擅长把流水账数据整理成有结论的周报。 # 任务 根据以下原始数据生成一份给部门负责人的周报。 # 约束 - 只使用我提供的数据不要编造任何数字 - 结论部分必须指出环比变化最大的两个指标 - 全文不超过 400 字 # 输出格式 ## 本周核心结论 两句话 ## 关键指标 | 指标 | 本周 | 上周 | 环比 | ## 下周动作 三条每条不超过 20 字 # 原始数据 此处粘贴数据 这段模板的关键不在“写得多”而在每一段都在消除一种歧义。角色段决定用词风格任务段决定输出目标约束段是防止模型自由发挥的护栏格式段让结果可以直接粘贴进文档。参数上如果你用的是 APItemperature在写周报这类需要稳定的任务上建议设 0.3 以下如果是创意文案可以放到 0.8 到 1.0。max_tokens要留出余量400 字中文大约对应 600 到 800 token设 1000 比较稳。2.2 多轮对话里的上下文污染什么时候该开新会话多轮对话有个隐蔽的坑前面几轮的错误信息会被后续轮次继承。比如你第一轮让模型“假设用户量是 10 万”后面忘了纠正模型会一直基于这个假设往下算。我自己的习惯是当一个任务的目标发生切换时直接开新会话而不是在旧会话里“顺便再问一个”。判断是否该开新会话看三个信号任务目标变了、关键前提被推翻、输出格式要求完全不同。如果只是同一任务下的追问比如“把第二段改短一点”那继续在原会话里说就行。DeepSeek 的上下文窗口足够长但长不等于该塞满塞得越杂后面越容易跑偏。2.3 用“先问后答”逼出模型的推理路径直接要答案模型可能给你一个看起来对、但经不起推敲的结果。一个实用技巧是让它先复述问题、再列步骤、最后给结论。这在数据分析和逻辑推理场景里尤其明显。# 强制模型展示推理路径的提示写法 prompt 在回答之前请先完成以下三步 1. 用一句话复述你理解的问题 2. 列出解决这个问题需要的步骤标注每步依赖什么信息 3. 如果某步信息不足明确指出缺什么不要假设 完成后再给出最终答案。 这个写法的价值在于你能在“复述”那一步就发现模型有没有理解偏。如果它复述错了后面不用看了直接改提示。参数上不需要特殊设置但建议把top_p保持在 0.9 左右太低会让推理路径变得死板。2.4 基础交互的验收标准三个可量化的指标练完前三天怎么判断自己过关了我一般用三个指标一次通过率、格式合规率、事实错误率。一次通过率指不改提示、只跑一次就能用的比例格式合规率指输出结构完全符合要求的比例事实错误率指输出里出现编造数据的比例。前两个指标靠提示结构优化第三个靠约束条件和“不要编造”类指令压制。这三个指标在后续所有场景里都适用只是阈值不同。3. 结构化提示与上下文管理让输出稳定可复现3.1 把提示当代码管变量、模板、版本当你要反复用同一类提示时把它硬编码在脚本里是灾难。我一般会把提示拆成模板加变量模板存文件变量运行时注入。这样改一处所有调用点都生效。# prompt_template.py # 提示模板与变量分离便于版本管理和批量调用 REPORT_TEMPLATE # 角色 你是一名{role}擅长{skill}。 # 任务 {task} # 约束 {constraints} # 输出格式 {output_format} # 输入数据 {data} def build_prompt(role, skill, task, constraints, output_format, data): return REPORT_TEMPLATE.format( rolerole, skillskill, tasktask, constraintsconstraints, output_formatoutput_format, datadata )这样做的直接好处是当你要对比两种约束写法哪个效果好时只需要改constraints变量不用动整个脚本。参数上constraints建议用列表拼接而不是长字符串方便逐条增删。我一般会把常用约束存成一个列表比如“不要编造数据”“不要使用第一人称”“数字保留两位小数”按场景勾选。3.2 上下文压缩长文档场景下的取舍策略处理长文档时把全文塞进上下文是最省事但最不稳定的做法。模型在长上下文里对中间部分的注意力会下降这是公开研究中反复出现的现象。我的做法是分层压缩先让模型对每个章节做摘要再把摘要拼起来做全局分析。# 长文档分层摘要的伪代码流程 # 第一步按章节切分逐段摘要 section_summaries [] for section in split_by_heading(document): summary call_deepseek( promptf用三句话总结以下内容保留所有数字和结论\n{section} ) section_summaries.append(summary) # 第二步基于摘要做全局分析 final call_deepseek( promptf以下是各章节摘要请找出三个相互矛盾的结论\n{section_summaries} )这个流程的关键参数是切分粒度。切得太碎摘要之间丢失关联切得太粗单次摘要质量下降。我的经验是每段控制在 800 到 1500 字对应大约 1200 到 2000 token。如果文档本身结构清晰按标题切分是最省事的。3.3 输出格式的硬约束JSON、表格、固定字段需要程序消费的输出必须用硬约束。最可靠的方式是给一个示例结构然后要求“只输出 JSON不要任何解释文字”。如果模型偶尔还是会加一句“好的以下是结果”可以在后处理里做截断。# 要求严格 JSON 输出的提示片段 prompt 请从以下文本中抽取信息严格按此 JSON 结构输出不要添加任何其他文字 { company: 公司名称, amount: 金额数字类型, date: 日期格式 YYYY-MM-DD } 文本 {text} 参数上这类任务建议temperature0top_p1尽量消除随机性。如果输出仍然不稳定可以在提示末尾加一句“如果你不确定某个字段填 null不要猜测”。这个约束能显著降低编造率。3.4 多轮任务的状态管理用外部文件记住进度当一个任务需要跨多次会话完成时靠模型自己记住进度是不靠谱的。我一般会在本地维护一个状态文件每次会话开始时把状态注入提示结束时把新状态写回。# 状态文件示例task_state.json { task_id: report_2024_w12, completed_sections: [summary, metrics], pending_sections: [actions], last_updated: 2024-03-20T10:30:00 }每次调用前读取这个文件把pending_sections告诉模型让它只处理未完成部分。这样即使中间换了会话进度也不会丢。这个做法在批量处理几十份文档时特别有用相当于给模型外挂了一个“后悔药”。4. 三类专业场景落地代码、文档、数据分析4.1 代码场景从补全到审查的提示差异用 DeepSeek 写代码提示方式直接决定输出质量。补全场景下给上下文和函数签名就够了审查场景下需要明确告诉它关注什么维度。# 代码审查场景的提示模板 prompt 请审查以下代码重点关注三个维度 1. 边界条件空输入、超长输入、类型异常时是否会崩溃 2. 资源泄漏文件、连接、内存是否有未释放路径 3. 并发安全共享状态是否有竞态风险 对每个问题给出问题位置、触发条件、修复建议。 如果某个维度没有问题明确说“无”。 代码 {code} 补全场景的提示则相反要少给约束多给上下文。我一般会把相关模块的接口定义、调用示例、命名风格一起贴进去让模型模仿现有风格。参数上代码补全建议temperature0.2审查建议temperature0因为审查需要稳定复现。4.2 文档场景从会议记录到结构化纪要会议记录转纪要难点不在总结在于区分“讨论过程”和“决议结果”。我的提示里会强制模型分两栏输出并且要求每条决议必须标注责任人。# 会议纪要结构化提示 prompt 将以下会议记录整理成纪要分两部分 ## 决议事项 每条格式事项 | 责任人 | 截止时间 只写有明确结论的内容讨论过程中的假设不要写进来。 ## 待定事项 每条格式事项 | 卡点 | 下一步 没有结论但需要跟进的内容放这里。 会议记录 {transcript} 这个提示的关键是“只写有明确结论的内容”这句约束。不加这句模型会把“某人提出可以考虑……”也当成决议。参数上temperature0.3比较合适太低会让语言过于生硬太高会引入原文没有的推断。4.3 数据分析场景让模型做计算而不是猜结论数据分析是模型最容易翻车的场景因为它倾向于“看起来合理”而不是“算得对”。我的做法是把计算和解释拆成两步先让模型写计算代码执行后再让它解释结果。# 两步式数据分析提示 # 第一步生成计算代码 step1 根据以下数据结构写一段 Python 代码计算 1. 每个月的环比增长率 2. 增长率最高的三个月 3. 是否存在连续两个月负增长 只输出代码不要解释。使用 pandas。 数据结构 {data_schema} # 第二步基于真实计算结果做解释 step2 以下是计算结果 {computed_result} 请用三句话总结指出最值得关注的一个信号并说明理由。 不要重新计算只解释已有结果。 这个流程把“算”和“说”分开算的部分交给代码说的部分交给模型。参数上第一步temperature0第二步可以放到 0.5让解释更自然。如果数据量大第一步生成的代码要先在小样本上验证再跑全量。4.4 场景落地的验收用回归集代替感觉每个场景跑通后我建议留一组固定输入作为回归集。每次改提示或换模型版本跑一遍回归集对比输出差异。回归集不需要大每个场景 5 到 10 条就够但要覆盖正常输入、边界输入、异常输入三类。这个习惯能帮你区分“这次输出好是因为提示改对了”还是“只是因为随机性”。5. 避坑与排查五条血泪经验5.1 现象模型编造了不存在的数字原因约束不够具体解决加“只使用提供数据”并做后验这是最高频的翻车。提示里只写“不要编造”往往不够因为模型对“编造”的定义和你不一致。有效的做法是明确写“只使用我提供的数据如果某个字段在数据中不存在填‘未提供’”。同时在程序侧做一次校验比如检查输出里的数字是否都能在输入中找到。5.2 现象多轮对话越聊越偏原因上下文污染累积解决任务切换时开新会话前面提过但值得再强调。判断标准很简单如果你需要往上翻好几轮才能说清当前任务的前提那就该开新会话了。把必要前提重新写进新会话的第一条提示比在旧会话里“纠正”更省时间。5.3 现象JSON 输出偶尔多出解释文字原因格式约束不够硬解决加“只输出 JSON”并在后处理截断即使提示里写了“只输出 JSON”模型仍可能加一句“以下是结果”。稳妥做法是在程序里找第一个{和最后一个}截取中间部分再解析。如果解析失败把原始输出和错误一起记日志用于后续优化提示。5.4 现象长文档分析漏掉中间章节原因长上下文注意力衰减解决分层摘要不要指望模型在几万字里均匀分配注意力。分层摘要虽然多一步但结果稳定得多。切分粒度按标题走每段控制在 1500 字以内摘要时要求“保留所有数字和结论”这样后续全局分析才有依据。5.5 现象同一提示两次输出差异大原因温度设置过高或任务本身歧义解决降温度并消除歧义如果任务需要稳定复现temperature设 0 到 0.3。如果降了温度还是不稳定说明提示本身有歧义比如“写一段吸引人的文案”里的“吸引人”没有定义。把主观词换成可操作的标准比如“包含一个具体数字和一个行动号召”。6. 进阶把 DeepSeek 嵌进工作流的三个具体技巧第一个技巧是提示版本化。我习惯把每个场景的提示存成独立文件文件名带日期和版本号比如report_prompt_v3_20240320.txt。每次修改前先复制一份改完跑回归集对比通过率。这样即使改坏了也能快速回滚。参数上回归集的通过率下降超过 10% 就回滚不要犹豫。第二个技巧是输出后验。对任何涉及数字或事实的输出写一个简单的校验函数。比如检查金额是否在合理区间、日期是否可解析、引用的数据是否在输入中出现。校验不通过的输出不要直接给人看先让模型基于校验反馈重试一次。# 输出后验的简化示例 def validate_output(output, source_data): errors [] # 检查数字是否都能在源数据中找到 for num in extract_numbers(output): if num not in source_data: errors.append(f数字 {num} 不在源数据中) # 检查日期格式 for date in extract_dates(output): if not is_valid_date(date): errors.append(f日期格式异常{date}) return errors # 如果有错误带着反馈重试 errors validate_output(result, source) if errors: result call_deepseek( promptf上次输出有以下问题{errors}。请修正后重新输出。 )第三个技巧是建立自己的场景库。不要每次遇到新任务都从零写提示。把跑通的提示按场景分类存好新任务先找最接近的场景改几个变量就能用。我自己的场景库分了六类信息抽取、文本改写、代码生成、代码审查、数据分析、决策建议。每类下面有三到五个模板覆盖不同粒度。最后一个习惯每次模型输出让你觉得“这不对”的时候不要只改这一条提示而是问自己“这类任务的通用约束是什么”把它加到模板里。15 天下来你的模板会越来越厚但需要临时想的越来越少。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/15 6:34:46 · 阅读 1.2k 15天精通DeepSeek：从基础交互到工作流实战指南
简介这份《DeepSeek 15天精通指南》面向初次接触AI工具的新手以及希望借助AI助手提升办公与科研效率的专业人士帮助读者在两周多时间内完成从基础交互到专业场景应用的系统进阶。压缩包内仅含1个PDF文件大小约1.31MB内容按准备篇、基础对话、效率提升、场景实战等模块层层递进便于按章节顺序学习或按需查阅。目前已有221人学习下载。指南围绕有效提问的黄金法则、文档分析与代码编写、学术论文全流程辅助、自媒体内容生产等真实任务展开并配有避坑指南与进阶玩法如多语言切换、白板面试模拟等读者可据此掌握人机协作的提问思路与自动化任务搭建方法逐步培养用DeepSeek处理文献查阅、文案撰写、程序编制及科研辅助等工作的能力。1. 从“会聊天”到“能干活”15 天到底该练什么很多人用 DeepSeek 的方式其实停留在“高级搜索框”阶段问一句、答一句答得不好就换个问法再不行就骂模型不行。我见过一个做运营的同行每天用 DeepSeek 写文案用了三个月产出效率只比手写快了不到两成。问题不在模型在于他把一个能跑多轮推理、能挂外部工具、能约束输出格式的系统当成了单轮问答机。“15 天精通”这个说法听起来像营销话术但如果把“精通”拆成可验证的能力项——第 1 到 3 天把基础交互的边界摸清第 4 到 8 天掌握结构化提示与多轮上下文管理第 9 到 12 天跑通代码、文档、数据分析三类专业场景第 13 到 15 天做工作流封装和效果回归——15 天是够的。前提是每天练的不是“多问几个问题”而是针对一个具体交付物做迭代。这篇笔记面向两类人一类是刚接触 DeepSeek、想知道从哪下手的新手另一类是已经在用、但输出质量不稳定、想把它嵌进真实工作流的熟手。下面按“基础交互 → 结构化控制 → 专业场景落地 → 避坑 → 进阶技巧”的顺序推演每一步都落到可复现的操作上。2. 基础交互的四个控制维度别再把模型当搜索框2.1 角色、任务、约束、格式一条提示的四段结构新手最容易犯的错是把所有信息揉成一句话丢过去。比如“帮我写个周报”模型只能猜你的岗位、汇报对象、数据范围、篇幅要求。我一般会把提示拆成四段角色设定、任务描述、约束条件、输出格式。这四段不一定要写全但缺哪段输出就在哪个维度上失控。# DeepSeek 基础交互的四段式提示模板 prompt # 角色 你是一名有 5 年经验的电商运营擅长把流水账数据整理成有结论的周报。 # 任务 根据以下原始数据生成一份给部门负责人的周报。 # 约束 - 只使用我提供的数据不要编造任何数字 - 结论部分必须指出环比变化最大的两个指标 - 全文不超过 400 字 # 输出格式 ## 本周核心结论 两句话 ## 关键指标 | 指标 | 本周 | 上周 | 环比 | ## 下周动作 三条每条不超过 20 字 # 原始数据 此处粘贴数据 这段模板的关键不在“写得多”而在每一段都在消除一种歧义。角色段决定用词风格任务段决定输出目标约束段是防止模型自由发挥的护栏格式段让结果可以直接粘贴进文档。参数上如果你用的是 APItemperature在写周报这类需要稳定的任务上建议设 0.3 以下如果是创意文案可以放到 0.8 到 1.0。max_tokens要留出余量400 字中文大约对应 600 到 800 token设 1000 比较稳。2.2 多轮对话里的上下文污染什么时候该开新会话多轮对话有个隐蔽的坑前面几轮的错误信息会被后续轮次继承。比如你第一轮让模型“假设用户量是 10 万”后面忘了纠正模型会一直基于这个假设往下算。我自己的习惯是当一个任务的目标发生切换时直接开新会话而不是在旧会话里“顺便再问一个”。判断是否该开新会话看三个信号任务目标变了、关键前提被推翻、输出格式要求完全不同。如果只是同一任务下的追问比如“把第二段改短一点”那继续在原会话里说就行。DeepSeek 的上下文窗口足够长但长不等于该塞满塞得越杂后面越容易跑偏。2.3 用“先问后答”逼出模型的推理路径直接要答案模型可能给你一个看起来对、但经不起推敲的结果。一个实用技巧是让它先复述问题、再列步骤、最后给结论。这在数据分析和逻辑推理场景里尤其明显。# 强制模型展示推理路径的提示写法 prompt 在回答之前请先完成以下三步 1. 用一句话复述你理解的问题 2. 列出解决这个问题需要的步骤标注每步依赖什么信息 3. 如果某步信息不足明确指出缺什么不要假设 完成后再给出最终答案。 这个写法的价值在于你能在“复述”那一步就发现模型有没有理解偏。如果它复述错了后面不用看了直接改提示。参数上不需要特殊设置但建议把top_p保持在 0.9 左右太低会让推理路径变得死板。2.4 基础交互的验收标准三个可量化的指标练完前三天怎么判断自己过关了我一般用三个指标一次通过率、格式合规率、事实错误率。一次通过率指不改提示、只跑一次就能用的比例格式合规率指输出结构完全符合要求的比例事实错误率指输出里出现编造数据的比例。前两个指标靠提示结构优化第三个靠约束条件和“不要编造”类指令压制。这三个指标在后续所有场景里都适用只是阈值不同。3. 结构化提示与上下文管理让输出稳定可复现3.1 把提示当代码管变量、模板、版本当你要反复用同一类提示时把它硬编码在脚本里是灾难。我一般会把提示拆成模板加变量模板存文件变量运行时注入。这样改一处所有调用点都生效。# prompt_template.py # 提示模板与变量分离便于版本管理和批量调用 REPORT_TEMPLATE # 角色 你是一名{role}擅长{skill}。 # 任务 {task} # 约束 {constraints} # 输出格式 {output_format} # 输入数据 {data} def build_prompt(role, skill, task, constraints, output_format, data): return REPORT_TEMPLATE.format( rolerole, skillskill, tasktask, constraintsconstraints, output_formatoutput_format, datadata )这样做的直接好处是当你要对比两种约束写法哪个效果好时只需要改constraints变量不用动整个脚本。参数上constraints建议用列表拼接而不是长字符串方便逐条增删。我一般会把常用约束存成一个列表比如“不要编造数据”“不要使用第一人称”“数字保留两位小数”按场景勾选。3.2 上下文压缩长文档场景下的取舍策略处理长文档时把全文塞进上下文是最省事但最不稳定的做法。模型在长上下文里对中间部分的注意力会下降这是公开研究中反复出现的现象。我的做法是分层压缩先让模型对每个章节做摘要再把摘要拼起来做全局分析。# 长文档分层摘要的伪代码流程 # 第一步按章节切分逐段摘要 section_summaries [] for section in split_by_heading(document): summary call_deepseek( promptf用三句话总结以下内容保留所有数字和结论\n{section} ) section_summaries.append(summary) # 第二步基于摘要做全局分析 final call_deepseek( promptf以下是各章节摘要请找出三个相互矛盾的结论\n{section_summaries} )这个流程的关键参数是切分粒度。切得太碎摘要之间丢失关联切得太粗单次摘要质量下降。我的经验是每段控制在 800 到 1500 字对应大约 1200 到 2000 token。如果文档本身结构清晰按标题切分是最省事的。3.3 输出格式的硬约束JSON、表格、固定字段需要程序消费的输出必须用硬约束。最可靠的方式是给一个示例结构然后要求“只输出 JSON不要任何解释文字”。如果模型偶尔还是会加一句“好的以下是结果”可以在后处理里做截断。# 要求严格 JSON 输出的提示片段 prompt 请从以下文本中抽取信息严格按此 JSON 结构输出不要添加任何其他文字 { company: 公司名称, amount: 金额数字类型, date: 日期格式 YYYY-MM-DD } 文本 {text} 参数上这类任务建议temperature0top_p1尽量消除随机性。如果输出仍然不稳定可以在提示末尾加一句“如果你不确定某个字段填 null不要猜测”。这个约束能显著降低编造率。3.4 多轮任务的状态管理用外部文件记住进度当一个任务需要跨多次会话完成时靠模型自己记住进度是不靠谱的。我一般会在本地维护一个状态文件每次会话开始时把状态注入提示结束时把新状态写回。# 状态文件示例task_state.json { task_id: report_2024_w12, completed_sections: [summary, metrics], pending_sections: [actions], last_updated: 2024-03-20T10:30:00 }每次调用前读取这个文件把pending_sections告诉模型让它只处理未完成部分。这样即使中间换了会话进度也不会丢。这个做法在批量处理几十份文档时特别有用相当于给模型外挂了一个“后悔药”。4. 三类专业场景落地代码、文档、数据分析4.1 代码场景从补全到审查的提示差异用 DeepSeek 写代码提示方式直接决定输出质量。补全场景下给上下文和函数签名就够了审查场景下需要明确告诉它关注什么维度。# 代码审查场景的提示模板 prompt 请审查以下代码重点关注三个维度 1. 边界条件空输入、超长输入、类型异常时是否会崩溃 2. 资源泄漏文件、连接、内存是否有未释放路径 3. 并发安全共享状态是否有竞态风险 对每个问题给出问题位置、触发条件、修复建议。 如果某个维度没有问题明确说“无”。 代码 {code} 补全场景的提示则相反要少给约束多给上下文。我一般会把相关模块的接口定义、调用示例、命名风格一起贴进去让模型模仿现有风格。参数上代码补全建议temperature0.2审查建议temperature0因为审查需要稳定复现。4.2 文档场景从会议记录到结构化纪要会议记录转纪要难点不在总结在于区分“讨论过程”和“决议结果”。我的提示里会强制模型分两栏输出并且要求每条决议必须标注责任人。# 会议纪要结构化提示 prompt 将以下会议记录整理成纪要分两部分 ## 决议事项 每条格式事项 | 责任人 | 截止时间 只写有明确结论的内容讨论过程中的假设不要写进来。 ## 待定事项 每条格式事项 | 卡点 | 下一步 没有结论但需要跟进的内容放这里。 会议记录 {transcript} 这个提示的关键是“只写有明确结论的内容”这句约束。不加这句模型会把“某人提出可以考虑……”也当成决议。参数上temperature0.3比较合适太低会让语言过于生硬太高会引入原文没有的推断。4.3 数据分析场景让模型做计算而不是猜结论数据分析是模型最容易翻车的场景因为它倾向于“看起来合理”而不是“算得对”。我的做法是把计算和解释拆成两步先让模型写计算代码执行后再让它解释结果。# 两步式数据分析提示 # 第一步生成计算代码 step1 根据以下数据结构写一段 Python 代码计算 1. 每个月的环比增长率 2. 增长率最高的三个月 3. 是否存在连续两个月负增长 只输出代码不要解释。使用 pandas。 数据结构 {data_schema} # 第二步基于真实计算结果做解释 step2 以下是计算结果 {computed_result} 请用三句话总结指出最值得关注的一个信号并说明理由。 不要重新计算只解释已有结果。 这个流程把“算”和“说”分开算的部分交给代码说的部分交给模型。参数上第一步temperature0第二步可以放到 0.5让解释更自然。如果数据量大第一步生成的代码要先在小样本上验证再跑全量。4.4 场景落地的验收用回归集代替感觉每个场景跑通后我建议留一组固定输入作为回归集。每次改提示或换模型版本跑一遍回归集对比输出差异。回归集不需要大每个场景 5 到 10 条就够但要覆盖正常输入、边界输入、异常输入三类。这个习惯能帮你区分“这次输出好是因为提示改对了”还是“只是因为随机性”。5. 避坑与排查五条血泪经验5.1 现象模型编造了不存在的数字原因约束不够具体解决加“只使用提供数据”并做后验这是最高频的翻车。提示里只写“不要编造”往往不够因为模型对“编造”的定义和你不一致。有效的做法是明确写“只使用我提供的数据如果某个字段在数据中不存在填‘未提供’”。同时在程序侧做一次校验比如检查输出里的数字是否都能在输入中找到。5.2 现象多轮对话越聊越偏原因上下文污染累积解决任务切换时开新会话前面提过但值得再强调。判断标准很简单如果你需要往上翻好几轮才能说清当前任务的前提那就该开新会话了。把必要前提重新写进新会话的第一条提示比在旧会话里“纠正”更省时间。5.3 现象JSON 输出偶尔多出解释文字原因格式约束不够硬解决加“只输出 JSON”并在后处理截断即使提示里写了“只输出 JSON”模型仍可能加一句“以下是结果”。稳妥做法是在程序里找第一个{和最后一个}截取中间部分再解析。如果解析失败把原始输出和错误一起记日志用于后续优化提示。5.4 现象长文档分析漏掉中间章节原因长上下文注意力衰减解决分层摘要不要指望模型在几万字里均匀分配注意力。分层摘要虽然多一步但结果稳定得多。切分粒度按标题走每段控制在 1500 字以内摘要时要求“保留所有数字和结论”这样后续全局分析才有依据。5.5 现象同一提示两次输出差异大原因温度设置过高或任务本身歧义解决降温度并消除歧义如果任务需要稳定复现temperature设 0 到 0.3。如果降了温度还是不稳定说明提示本身有歧义比如“写一段吸引人的文案”里的“吸引人”没有定义。把主观词换成可操作的标准比如“包含一个具体数字和一个行动号召”。6. 进阶把 DeepSeek 嵌进工作流的三个具体技巧第一个技巧是提示版本化。我习惯把每个场景的提示存成独立文件文件名带日期和版本号比如report_prompt_v3_20240320.txt。每次修改前先复制一份改完跑回归集对比通过率。这样即使改坏了也能快速回滚。参数上回归集的通过率下降超过 10% 就回滚不要犹豫。第二个技巧是输出后验。对任何涉及数字或事实的输出写一个简单的校验函数。比如检查金额是否在合理区间、日期是否可解析、引用的数据是否在输入中出现。校验不通过的输出不要直接给人看先让模型基于校验反馈重试一次。# 输出后验的简化示例 def validate_output(output, source_data): errors [] # 检查数字是否都能在源数据中找到 for num in extract_numbers(output): if num not in source_data: errors.append(f数字 {num} 不在源数据中) # 检查日期格式 for date in extract_dates(output): if not is_valid_date(date): errors.append(f日期格式异常{date}) return errors # 如果有错误带着反馈重试 errors validate_output(result, source) if errors: result call_deepseek( promptf上次输出有以下问题{errors}。请修正后重新输出。 )第三个技巧是建立自己的场景库。不要每次遇到新任务都从零写提示。把跑通的提示按场景分类存好新任务先找最接近的场景改几个变量就能用。我自己的场景库分了六类信息抽取、文本改写、代码生成、代码审查、数据分析、决策建议。每类下面有三到五个模板覆盖不同粒度。最后一个习惯每次模型输出让你觉得“这不对”的时候不要只改这一条提示而是问自己“这类任务的通用约束是什么”把它加到模板里。15 天下来你的模板会越来越厚但需要临时想的越来越少。希望帮到你。本文还有配套的精品资源点击获取