企业官网建设流程全解析

简介：这份PDF是清华大学新闻与传播学院新媒体研究中心推出的《DeepSeek：从入门到精通》完整讲义，面向希望系统掌握大模型应用与提示语设计的开发者、研究者及AI爱好者。内容从DeepSeek公司与开源推理模型DeepSeek-R1讲起，覆盖智能对话、文本生成、语义理解、计算推理、代码生成补全等场景，并深入辨析推理模型与通用模型的差异、CoT链式思维下的快思慢想机制，以及针对不同模型的任务选择与提示语策略。资源包为单一PDF文件，大小约5.36MB，结构清晰、图文并茂，便于通读与检索。目前已有14295人学习下载，适合作为入门到进阶的案头参考，帮助读者理解国产开源模型的能力边界，并掌握从下达指令到表达需求的提示语设计方法。

1. 一份 104 页的 DeepSeek 手册，为什么值得逐页拆开看

很多人第一次拿到《DeepSeek：从入门到精通》这类 104 页的 PDF，反应是“先存着，回头再看”，然后就没有回头了。我一开始也这样，直到某次要把一个内部知识库问答接进 DeepSeek，翻了三四个零散教程都对不上，才回头把这份手册从头到尾过了一遍。它真正有价值的地方，不是告诉你“DeepSeek 能干什么”，而是把提示词结构、参数含义、场景模板串成了一条能落地的线。适合谁？适合已经会用聊天框、但一到写代码、做表格、搭工作流就卡壳的从业者。这篇笔记就按“手册里讲了什么 → 怎么照着跑 → 哪些地方容易翻车”的顺序，把它拆成能直接抄的步骤。

2. 先搞懂 DeepSeek 的三种调用姿势：网页、API、本地部署

2.1 网页端适合验证提示词，不适合做批量任务

手册前三分之一基本都在讲网页端交互，这部分最容易被跳过，但它其实是后面所有工作的“试验田”。网页端的价值在于：你改一句提示词，立刻能看到输出差异，不用等接口返回、不用配环境。我一般会在这里把提示词的骨架定下来，比如角色设定、输出格式、约束条件这三段式，确认稳定之后再往 API 搬。

具体做法是：打开对话窗口，先写一句角色定义，再写任务，最后写格式要求。比如“你是一名数据清洗工程师，请把下面这段文本里的手机号替换成 [PHONE]，只输出替换后的文本，不要解释”。跑三五轮，看它会不会自作主张加解释、会不会漏替换。这一步定不下来，后面写代码也是白搭。

提示：网页端每次对话是独立的，别指望它记住上一轮的格式要求，重要约束每轮都要重复写。

2.2 API 调用：把提示词变成可复用的函数

手册里关于 API 的部分，核心就三件事：鉴权、消息结构、参数。很多人卡在第一步，是因为把 API Key 直接写死在代码里，然后传到公开仓库，第二天就被刷爆。正确做法是走环境变量。

import os from openai import OpenAI # 从环境变量读取，不要硬编码 client = OpenAI( api_key=os.environ.get("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com" # 常见做法是走兼容接口 ) def clean_text(raw: str) -> str: resp = client.chat.completions.create( model="deepseek-chat", # 通用对话模型 messages=[ {"role": "system", "content": "你是数据清洗助手，只输出结果，不解释。"}, {"role": "user", "content": f"替换手机号为[PHONE]：{raw}"} ], temperature=0.2, # 清洗任务要低温度 max_tokens=1024 ) return resp.choices[0].message.content if __name__ == "__main__": print(clean_text("联系我 13800000000 谢谢"))

逻辑说明：system消息负责定角色和硬约束，user消息放具体任务。temperature设 0.2 是为了让输出稳定，清洗类任务不需要创造力。max_tokens限制单次输出长度，防止模型啰嗦。参数怎么改？如果任务是创意文案，温度可以提到 0.8 到 1.0；如果是抽取结构化字段，温度压到 0 到 0.3。失败时先看返回的finish_reason，如果是length，说明max_tokens给小了。

2.3 本地部署：什么时候才值得折腾

手册里提到本地部署，但没展开。我的判断标准很简单：数据不能出内网、或者调用量极大想省成本，才考虑本地。否则 API 的稳定性和迭代速度更划算。本地部署常见做法是用推理框架加载量化后的模型权重，显存 16G 起步能跑 7B 级别的量化版本，32G 以上可以考虑更大参数。这一步坑最多，驱动版本、CUDA 版本、量化格式对不上，报错能看一整天。新手建议先用 API 把流程跑通，再考虑本地。

3. 把手册里的提示词模板改成能跑的工作流

3.1 提示词三段式：角色、任务、格式

手册里反复出现的一个结构是“角色 + 任务 + 格式”，但很多人只抄了角色，忘了格式。格式约束才是让输出能进下游程序的关键。比如你要批量处理 500 条评论，输出必须是 JSON，否则后面还得写正则去抠。

PROMPT_TEMPLATE = """你是一名电商评论分析员。 任务：判断下面评论的情感倾向。 格式：只输出 JSON，字段为 sentiment（positive/negative/neutral）和 reason（不超过20字）。 评论：{comment} """ def analyze(comment: str) -> dict: resp = client.chat.completions.create( model="deepseek-chat", messages=[{"role": "user", "content": PROMPT_TEMPLATE.format(comment=comment)}], temperature=0.1, response_format={"type": "json_object"} # 强制 JSON 输出 ) return resp.choices[0].message.content

逻辑说明：response_format设成json_object能大幅降低解析失败率，但前提是提示词里必须出现“JSON”这个词，否则部分接口会报错。temperature压到 0.1，保证同一评论多次跑结果一致。参数上，如果评论很长，注意max_tokens要留够，否则 JSON 会被截断成半截，解析直接抛异常。

3.2 批量任务：并发、重试、限流三件套

单条跑通之后，下一步就是批量。手册里没细讲并发，但这是从“能用”到“好用”的分水岭。我一般用线程池控制并发数，配合指数退避重试。

import time from concurrent.futures import ThreadPoolExecutor def safe_analyze(comment: str, retries: int = 3) -> dict: for i in range(retries): try: return analyze(comment) except Exception as e: if i == retries - 1: return {"sentiment": "error", "reason": str(e)} time.sleep(2 ** i) # 指数退避：1s, 2s, 4s def batch_run(comments: list, workers: int = 5): with ThreadPoolExecutor(max_workers=workers) as pool: return list(pool.map(safe_analyze, comments))

逻辑说明：workers不要一上来就设 50，接口通常有并发限制，设 5 到 10 比较稳。指数退避是为了应对偶发的超时或限流，直接死循环重试会把额度耗光。失败时看异常类型，如果是 401，检查 Key；如果是 429，降低并发；如果是超时，加大退避基数。

3.3 结果落库：别把 JSON 存成字符串

跑完批量任务，很多人直接把 JSON 字符串塞进数据库一个字段，后面想按情感筛选就得全表扫。正确做法是解析后存结构化字段。

import json import sqlite3 def save_results(conn, comment_id: int, raw: str): try: data = json.loads(raw) except json.JSONDecodeError: data = {"sentiment": "parse_error", "reason": raw[:50]} conn.execute( "INSERT INTO results (comment_id, sentiment, reason) VALUES (?, ?, ?)", (comment_id, data.get("sentiment"), data.get("reason")) ) conn.commit()

逻辑说明：解析失败要有兜底，把原始输出截断存下来，方便事后排查是模型问题还是提示词问题。sentiment和reason拆成独立列，后面做统计直接GROUP BY sentiment就行，不用再跑一遍模型。

4. 避坑：这五类问题我几乎每次都会遇到

4.1 输出带 markdown 代码块，解析直接崩

现象：明明要求只输出 JSON，结果返回json ...，json.loads报错。原因：模型在训练时见过大量带代码块的 JSON 示例，习惯性加围栏。解决：提示词里明确写“不要用 markdown 代码块包裹”，同时在解析前做一次清洗，用正则去掉首尾的 ``` 和 json 标记。

4.2 长文本被截断，后半段凭空消失

现象：输入 3000 字，输出只分析了前 500 字。原因：max_tokens限制的是输出长度，但输入过长时模型可能自行截断上下文。解决：先确认模型的上下文窗口大小，超长文本做分段处理，每段单独调用，最后合并结果。分段时按段落切，不要按固定字数切，否则会把一句话劈开。

4.3 温度设太高，同一输入两次结果不一样

现象：批量跑 100 条，重跑一遍发现 10 条结果变了。原因：temperature大于 0 时输出有随机性。解决：分类、抽取、清洗类任务一律设 0 到 0.2；只有创意生成才调高。如果业务要求完全可复现，温度设 0，并且固定seed参数（如果接口支持）。

4.4 并发太高触发限流，一半请求失败

现象：workers=20时大量 429 错误。原因：接口有 QPS 限制，超过就拒绝。解决：把并发降到 5 左右，配合重试。如果业务量大，考虑错峰跑，或者申请更高的配额。别用“加机器”的思路硬扛，限流是服务端的硬约束。

4.5 提示词里写“尽量”“最好”，模型就放飞

现象：要求“尽量简短”，结果输出三行；要求“最好用中文”，结果夹英文。原因：模糊约束等于没约束。解决：把“尽量”“最好”换成硬性数字或枚举，比如“不超过 20 个字”“只允许 positive/negative/neutral 三个值之一”。约束越具体，输出越稳定。

5. 进阶：用 few-shot 和自检把准确率再提一截

手册后半部分提到 few-shot，但例子偏简单。我在实际项目里发现，光给例子还不够，得让模型自己检查一遍。具体做法是两段式调用：第一段让模型输出结果，第二段把结果和原始输入一起丢回去，让它判断“这个结果是否满足格式和逻辑要求”，不满足就重跑。

def analyze_with_check(comment: str) -> dict: first = analyze(comment) check_prompt = f"""原始评论：{comment} 模型输出：{first} 请判断输出是否为合法 JSON 且 sentiment 值在允许范围内。 如果是，原样返回；如果不是，重新输出正确结果。 只输出 JSON。""" resp = client.chat.completions.create( model="deepseek-chat", messages=[{"role": "user", "content": check_prompt}], temperature=0 ) return resp.choices[0].message.content

逻辑说明：第二段调用相当于一个轻量校验器，成本是翻倍，但准确率能明显提升。适合对准确率敏感、对成本不敏感的场景。如果量很大，可以只对第一段输出解析失败的样本做二次校验，省一半开销。

另一个技巧是给例子时覆盖边界情况。比如情感分类，除了正面和负面，一定要给一条中性评论的例子，否则模型遇到“还行吧”这种模糊表达会乱猜。例子数量 3 到 5 条足够，太多会挤占上下文，反而让模型抓不住重点。

参数上，few-shot 场景下temperature依然要压低，因为例子已经提供了足够的模式信息，不需要模型发挥。如果发现模型开始模仿例子的具体内容而不是格式，说明例子太具体了，把例子里的实体词换成占位符，比如“某产品”“某用户”。

最后说个我自己的习惯：每次改完提示词，先拿 20 条历史数据跑一遍回归，对比改动前后的输出差异。别凭感觉觉得“这次应该更好了”，数据不会骗人。这套流程跑顺之后，104 页手册里剩下的场景模板，基本都能套进这个框架里。希望帮到你。

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