企业官网建设流程全解析

简介：《DeepSeek从入门到精通》面向AI初学者、内容创作者与开发者，聚焦国产大模型DeepSeek的能力边界与实操方法，帮助读者从“会用”走向“用好”。压缩包内仅含1个PDF文件，约5.36MB，体量轻便，适合碎片化阅读。内容由清华大学新媒体研究团队整理，围绕DeepSeek是什么、能做什么、如何使用展开，辨析推理大模型与非推理大模型的差异，讲解推理模型与通用模型在提示语策略、任务匹配上的关键原则。读者可掌握文本创作、摘要改写、多语言翻译、代码生成与调试、语义分析与知识推理等场景的提问思路，理解指令驱动、需求导向、混合模式、启发式提问等策略的适用边界，避免对推理模型过度拆解、对通用模型过度信任。目前已有1011人学习，适合希望建立大模型应用框架、提升提示词设计能力的读者参考。

1. 先搞懂一件事：DeepSeek 是什么，零基础该怎么理解它

第一次听到 DeepSeek 的人，十有八九会先问一句：它到底是个 App、一个网站，还是又一个大模型？我刚开始也卡在这儿。用大白话说，它是一个能听懂人话、也能把话写出来的国产大模型，你打开网页把要求打进去，它给结果。所以 DeepSeek 入门这件事，难的从来不是操作——打开页面、打字、回车，三十秒就会；难的是把“我到底想要什么”说清楚。这份材料里反复出现的那句话挺戳人：当人人都会用 AI 时，你如何用得更好更出彩。它适合谁？写文案的、做表格的、写代码的、天天写汇报的，以及所有想让重复劳动少一点的人。

2. 它能替你干什么：先把四类活分清楚

新手最容易犯的错，是一上来就研究“怎么问才高级”，结果连它能干什么都没数。更稳的顺序是反过来的：先在自己的工作里找出三件烦人的事，再去看它能不能接。这一章不讲原理，只把它的能力范围摊开给你看，看完你心里应该有一张清单，知道哪些活可以试着丢给它。

2.1 文本类：写、改、缩、译，占日常使用的八成

这四类任务是新手最快见效的地方，也是最不容易翻车的地方，因为结果好不好你一眼就能看出来。

“写”包括文章、故事、诗歌这类创作，也包括营销文案、广告语、社交媒体推文和帖子，还有剧本和对话设计。我一般不推荐新手一上来就让它写长文，容易得到一堆正确但没味道的话；反而是短文案更好用，比如让它给同一个产品写五条不同风格的推荐语，你从里面挑一条改，效率比对着空白页面发呆高得多。

“改”和“缩”是另外两个高频动作。长文本摘要可以对付论文、报告、会议记录，文本简化则是把一段绕口的专业表述降到你需要的阅读难度。这两件事的关键在于你要说清楚“缩到什么程度”和“给谁看”——是给领导看的 200 字摘要，还是给自己看的要点清单，结果完全是两个样子。

“译”除了常规的多语言翻译，还有本地化这一层：同一句话翻成另一种语言，语气、称呼、单位都可能要跟着换。新手可以把原文和译文都贴回去，让它对照着指出哪里不自然，这一招我用得很多。

最后是结构化生成，比如把一段乱糟糟的需求整理成表格、列表、日程安排，或者把菜谱整理成步骤清单。这类任务对新手特别友好，因为格式是否合格你一眼就能判断，不用纠结文采。

2.2 代码类：不会写代码的人也能用上

很多人以为代码相关的能力只对程序员有用，其实不是。只要你需要处理数据、批量改文件、跑一个小脚本，这类能力就派得上用场。

它能做的事情大致有：根据需求生成代码片段，Python 和 JavaScript 这类常用语言都没问题；对报错信息做分析并给出修复建议；对已有代码做性能优化提示；生成 API 文档、解释整个代码库的结构、给出使用示例；以及自动补全和写注释。这里有个对新手很实用的点：你不一定要会写，但你要会看结果对不对。所以入门阶段最值得练的动作，是“让它写，然后让它解释自己写了什么”。

举个最典型的场景：你手上有一段别的语言写的老代码，想换成 Python。这时候与其自己硬啃，不如把代码贴给它，同时把要求说死——保持原有逻辑、别改输入输出、每一行加注释。它给出的东西未必能直接上生产，但作为“看得懂的初稿”非常好用。

2.3 理解类：从一堆文字里抽结论

这一类是新手最容易忽略、但价值最高的一类。它的能力包括语义分析、情感分析（评论和反馈）、意图识别（客服对话、用户查询）、实体提取（人名、地点、事件）、文本分类和主题标签生成、垃圾内容检测，以及因果分析和逻辑问题解答。

说得具体一点：你手上有几百条用户反馈，想知道大家到底在抱怨什么。硬看要看一整天，交给它的话，先让它按“功能问题、体验问题、价格问题、其他”分类，再让它从每类里挑出三条最有代表性的原话。注意最后这半句很重要——要求它引用原话，你就有了核对的办法，能立刻发现它是不是在瞎编。

这一类任务对提示语的要求比文本类高一些，因为“分类标准”必须你自己给，不能指望它猜。你给的标准越明确，结果越能用。

2.4 先把预期调整到合理水平：它做不好什么

入门阶段最影响体验的不是技巧，是预期。有四件事新手一定要提前知道。

第一，它对实时信息的掌握有限，涉及“今天”“最新”“刚发布”这类问题时，一定要看联网搜索有没有打开，或者干脆自己把资料贴进去让它读。第二，它会生成看起来很像真的、但其实不存在的内容，尤其是数字、人名、文献引用，凡是需要签字负责的结论，必须回到原始材料核对。第三，文件上传虽然能扫描读取文字，但图片和扫描件识别偶尔会出错，重要文件先让它复述关键段落再动手分析。第四，它给的是初稿不是终稿，你省下的是从 0 到 1 的时间，从 1 到 10 还得自己来。

提示：把“它能帮我省哪一步”想清楚，比“它能不能全替我做完”有用得多。

3. 第一个例子怎么跑：从一句话需求到能用的结果

理论说再多，不如亲手跑一遍。这一章带你走完一个最小闭环：写一句需求、发出去、拿到结果、改三遍。整个过程不涉及任何安装配置，打开官方网页版就能做。第一次跑通之后，你对它的感觉会从“玄学”变成“工具”。

3.1 第一步：先想清楚成品长什么样

新手最常见的动作是打开对话框就敲“帮我写个方案”，然后对着结果摇头。问题不在模型，在于你没定义成品。发出去之前，先回答三个问题：这东西给谁看？大概多长？要什么格式和语气？

“给谁看”决定了用词和详略，给同事看可以带术语，给客户看要说人话。“多长”决定了它是要点清单还是一篇完整文章，不给长度它往往写得比你要的长。“格式和语气”决定了它是一段话、一个表格，还是分点罗列。

这三个问题花不了两分钟，但能把结果质量拉开一大截。我第一次带新人时，让他们分别用“一句话需求”和“回答完三个问题的需求”各跑一次，对比完基本就没人再偷懒了。

3.2 第二步：照着这个结构把需求写下来

不用背什么复杂框架，记住三块就够：你要它干什么、它需要知道什么、你要什么形式的结果。下面这个模板可以直接抄去改。

# 任务：帮我把下面这段会议记录整理成一份给部门负责人看的工作简报 # 背景：会议讨论的是下季度的活动排期，参会的有市场、运营、设计三个组 # 材料：（把你的记录粘贴在这里） # 要求： # 1. 只保留结论和待办事项，过程讨论不要写 # 2. 待办事项要标出负责组和截止时间，没提到的写“待定” # 3. 总长度控制在 300 字以内 # 输出格式：先一段 100 字以内的概述，再用列表列待办

这几行分别对应了三个东西：任务那一行是“指令”，告诉它做什么；背景和材料是“上下文”，让它有依据；要求加输出格式是“期望”，框住结果的样子。新手写不好提示语，九成是缺了中间那块上下文，导致它只能靠猜。

粘贴材料的时候有个小技巧：材料里的无关内容可以删，但别删得太狠，把关键数字和时间删了，它就只能编。宁可多贴两段，也不要让它靠常识补。

3.3 第三步：发出去，然后按方向改三遍

第一遍的结果大概率是“能用但不够好”，这很正常。改的时候别只说“再改改”，要说清楚改哪个方向。常用的三个方向是：加约束、给示例、换说法。

加约束就是补条件，比如“每条待办不超过 20 字”“不要用‘进一步’‘持续’这类词”。给示例是最有效的一招，你可以把它上一版里写得好的那一条贴回去，说“后面几条照这个长度和语气来”。换说法适用于结果完全跑偏的情况，与其在原句上修修补补，不如重新描述一遍需求。

改三遍是个经验值。第一遍看方向对不对，第二遍调节奏和篇幅，第三遍抠细节和用词。超过三遍还在原地打转，通常不是提示语的问题，是需求本身没想清楚，这时候该停下来自己先写两行提纲。

3.4 第二个例子：让它写一段能跑的代码

文本类跑通之后，可以试试代码。下面这段是我常用来给新人演示的需求，你可以原样发过去看看它给什么。

# 需求：写一个函数，统计一段文字里每个英文单词出现的次数 # 要求： # 1. 忽略大小写，"Apple" 和 "apple" 算同一个词 # 2. 去掉标点符号，但保留单词中间的连字符，比如 well-known 算一个词 # 3. 返回一个字典，按出现次数从高到低排序 # 4. 每一行加中文注释，说明这行在干什么

它给出的代码细节每次可能不太一样，这不要紧。你要看的是三件事：它有没有处理大小写、有没有处理标点、排序有没有真的做。这三点就是检验它是否认真读了你的要求。

拿到代码之后，别急着复制走。先自己造一条测试数据跑一遍，比如"Apple apple, well-known well-known banana."，看结果是不是apple出现两次、well-known出现两次、banana出现一次。跑不通就把报错原样贴回去，让它自己修——这比自己盯着看快得多。

参数上也需要留意：输入的text应该是字符串，返回值是字典，键是单词、值是次数。如果它返回的是列表而不是字典，说明排序那一步它用了别的写法，你要么接受，要么明确要求“返回字典而不是列表”。对新手来说，能看懂返回值的结构，就已经跨过最难那道坎了。

3.5 还有一条路：把文件直接丢给它读

除了打字提问，它还支持上传文件，能扫描读取各类文件及图片中的文字内容。这条路对新手特别友好，因为你不用把长材料复制粘贴，直接上传就行。

步骤上建议这么做：先把文件传上去，然后问一句“这份文件一共几页、主要讲了几件事”，确认它读全了；接着再提具体问题，比如“把第三章提到的三个风险点列出来”；最后要求它引用原文，方便你核对。

如果上传的是图片或扫描件，一定加上那句“请先复述图片里的关键文字，再回答我的问题”。这一步看起来多余，实际上能帮你筛掉大部分识别错误。我吃过亏，一份拍歪了的表格它读错了两列数字，我当时没核对就用了，后面返工了半小时。

4. 入门绕不开的一个概念：推理模型和通用模型差在哪

用了一段时间你会发现，同样是提问，有些问题它答得又快又顺，有些问题怎么问都不到位。这背后有个很关键的分野：模型分两类，一类靠“快速反应”，一类靠“慢速思考”。搞懂这件事，你的提示语水平会往上跳一档，因为你会发现很多时候不是你不会问，是你问错了对象。

4.1 一个比喻先说明白：快思和慢想

有些模型的工作方式像直觉反应：基于大量数据训练，快速预测接下来最可能出现的内容，响应快、算力成本低，适合处理即时任务。另一类模型则在生成答案前先做链式推理，把问题拆成若干步，一步步往前推，速度慢、成本高，但复杂问题上更稳。

这个区别可以类比成人做数学题。简单口算你可以脱口而出，但一道需要多步推导的证明题，你必须拿草稿纸一步步写。前一种模式适合聊天、改写、头脑风暴这类不需要严密链条的事，后一种适合数学推导、逻辑分析、代码生成、复杂问题拆解。

有个反直觉的点新手容易忽视：这两类不是“谁更强”的关系，而是“谁更适合”。推理模型在它训练目标覆盖的领域显著更好，但在发散性任务上反而不如通用模型，比如让它写诗，它可能给你一首结构工整但毫无灵气的作品。

4.2 怎么判断手上的活该交给哪一类

判断标准其实很简单，看这个任务需不需要“一步一步推”。

需要严谨链条的，交给推理型：数学证明、逻辑推理、代码生成与调试、需要拆解的复杂问题、需要验证结论是否成立的场景。这类任务的共同点是，中间错一步后面就全错，所以要的是稳不是快。

需要发散和表达的，交给通用型：创意写作、文案、多轮对话、开放性问答、把一段话换个说法。这类任务没有唯一正确答案，要的是灵活和语感。

现实里很多任务是混合的。比如“分析一份数据并给出三条建议”，分析部分需要推理，建议部分需要表达。这时候可以拆成两轮：先让它做分析、把推导过程写出来，你确认没问题，再让它基于这个分析写建议。一次干两件事，往往两件都干得一般。

还有一类容易被误判：看起来是“写”，实际是“推”。比如写一份带预算的方案，里面涉及成本测算，那就不是纯创意任务了，该按推理的路子来。

4.3 同一件事，两种问法，结果差很远

这里的差别主要在提示语策略上。对推理型模型，提示语应该更简洁，只需明确任务目标和需求，因为它已经把推理逻辑内化了；你强行拆解步骤，反而可能限制它的能力。对通用型模型，则需要显式引导推理步骤，或者提供示例，否则它可能跳过关键逻辑。

下面这张表是新手最该记住的一张，做任务前扫一眼就行。

看这张表你会发现一个规律：越是需要严密推导的，越要少管；越是需要风格和表达的，越要多给方向。

4.4 两个必须记住的误区

第一个误区是对推理型模型用“启发式”提示，比如给它安排一个角色、让它分步骤想。这类做法在通用模型上很有效，但对推理模型可能干扰它的逻辑主线，结果是它一边演角色一边推理，两头都没做好。要什么直接说，是这类模型最舒服的用法。

第二个误区是反过来——对通用模型过度信任。你直接问它一道复杂推理题，它可能给你一个听起来很顺、但过程有漏洞的答案。这时候的正确做法是把问题拆开，一步步追问，每步都验证。

判断自己有没有踩坑，有个简单的自查：如果你发现“怎么改提示语都没用”，先别改措辞，换一类模型试试。很多时候问题不在你怎么问，在你问错了对象。

5. 新手最容易踩的 5 个坑：都是我没核对吃的亏

这一章会比较扎心，因为每一条都是真实发生过的。新手阶段最大的成本不是不会用，是用错了还不知道，把错误结果当成正确答案用出去。下面五条按“现象、原因、解决”写，遇到对应情况直接对号入座。

5.1 坑一：把它当搜索引擎用

现象：问“最近有什么新政策”“某个产品现在多少钱”，它给了一个很像样但经不起核对的答案，你一查发现根本不存在。

原因：它的知识有截止时间，对实时信息的掌握有限，遇到不确定的地方不会说“我不知道”，而是会生成一个看起来合理的内容补上。这不是它故意骗你，是这类模型的工作方式决定的。

解决：涉及实时信息的任务，先看联网搜索有没有打开；如果没有，就把资料自己找好贴进去，明确说“只根据我提供的材料回答，材料里没有的写‘未提及’”。后面这半句是关键，它能把编造的空间压到最小。

5.2 坑二：一句话扔过去，然后嫌它写得空

现象：输入“帮我写个活动方案”，得到一份放在任何公司都能用的模板，全是“提升品牌影响力”“增强用户粘性”这类话，一句能用的都没有。

原因：它没有你的上下文。你的活动是什么性质、预算多少、面向谁、场地在哪、上一次同类活动出过什么问题，这些它一概不知道，只能往最通用的方向写。

解决：至少补齐三样——给谁看、要多长、有什么硬约束。再加一样最好用的：给它一个你自己写过的例子，说“照这个风格来”。有示例和没示例，结果差得很明显。

5.3 坑三：对推理型模型手把手教，越教越差

现象：你怕它想不周全，把步骤拆得特别细，还给它安排了角色，结果它给出的答案反而绕，逻辑链断在半路。

原因：这类模型本身已经内化了推理逻辑，会自动生成结构化的推导过程。你强行拆解，等于给它加了一堆额外约束，它得一边完成推理一边满足你的格式要求，注意力被分散了。

解决：把任务目标和需求说清楚就行，剩下的交给它。如果你确实想控制过程，可以等它给出结果后，再让它“把第三步的推导展开讲讲”，而不是一开始就把路堵死。

5.4 坑四：拿到结果直接用，数字和人名一个都不核对

现象：一份带数据的报告里，有两个百分比明显不对劲；或者引用了一本书，书名对但作者错了。这类问题往往在交出去之后才被发现。

原因：模型生成的是“最像正确答案的内容”，不是“查证过的内容”。数字、人名、文献引用、法规条款，这几类是最容易出问题的地方。

解决：给自己定一条硬规矩——凡是需要签字、需要对外发布、需要担责的内容，里面的每一个数字和专有名词都要回到原始来源核对。改这一遍大概多花十分钟，但省下的是返工和解释的成本。

5.5 坑五：一次问十件事，每件都得到一句废话

现象：一条消息里塞了“帮我分析数据、写个总结、再想三个方案、顺便起个标题”，结果每一项都答得很浅，你还得重新问一遍。

原因：一次任务里目标太多，它的注意力被摊薄，每个方向都只能给出通用回答。这跟人一样，你让同事一次干四件事，他也只能每件都做得马马虎虎。

解决：拆成多轮，一轮一个目标。先做分析，确认没问题，再基于分析写总结，最后单独起标题。多花几轮对话，但每一轮的产出都能直接用。

注意：这五条里，第四条最容易造成实际损失，也最容易被忽略，因为错误看起来太像正确的了。

6. 下一步学什么：把“下指令”换成“说需求”

跑通第一个例子之后，很多人会开始背各种提示语模板，我不太建议这么做。模板会过时，需求表达不会。真正值得练的能力，是把“下指令”换成“说需求”——不是命令它做什么，而是把它需要知道的信息给全。

具体来说，一条好用的需求通常包含三块：指令，明确告诉它要完成什么任务；上下文，提供背景信息帮它准确理解；期望，说明你要什么形式、多长、给谁看的结果。这三块你可以当成检查清单，每次发出去之前扫一眼，缺哪块补哪块。

不同类型的需求，表达方式也有差别。做决策时，给出目标、选项和评估标准；做分析时，给出问题、数据和你想用的分析方法；要创意时，给主题、风格和约束；要验证时，给结论、验证方法和风险点；要执行时，给任务、步骤约束和输出格式。这些不是死规则，是提醒你别漏信息。

如果你只打算练一个动作，我建议练“给示例”。从你已有的材料里挑一段写得好的，贴进去说“照这个来”，效果比加十条形容词都明显。我第一次带新人时不信这个，觉得太土，后来发现他们用示例的那几次，产出质量稳定得离谱。

最后说个我自己的习惯。从那以后，我每次把结果发给别人之前，都强制走一遍“数字核对 + 让它复述结论”这两步，不管多赶。这两步加起来不到五分钟，但帮我挡掉过好几次尴尬。入门阶段最重要的不是学多少技巧，是养成一个能长期用的习惯。希望帮到你。

本文还有配套的精品资源，点击获取