企业官网建设流程全解析

简介：这是一份关于DeepSeek人工智能平台的实战操作手册，以15天从入门到精通为主线，适合办公人士、科研人员、自媒体创作者、学生及编程爱好者学习。内容涵盖账号注册与界面认识、高效提问方法、文档解析与代码生成，以及学术论文辅助、新媒体运营、自动化流程搭建、多语言翻译等场景化应用。资源共1个docx文档，压缩包约138KB，结构简洁，便于按章阅读和随学随用。已有281人学习下载。除基础命令与操作细节外，还提供避坑指南与实战演练，读者可掌握从对话技巧到复杂任务拆解的完整技能，并将其直接迁移到日常学习、工作与创作中。

1. 15天从入门到精通，先从「参数」而不是「界面」开始

很多人拿到DeepSeek人工智能平台，第一反应是把对话窗口当搜索框用，半个月过去还在原地打转。真正让DeepSeek从「聊天玩具」变成生产力工具的，是API调用、上下文管理、本地部署和工具链集成这四条路。这份15天计划按三段走：前5天把账号、密钥和OpenAI兼容接口跑通；第6~10天把它接进编辑器、企业微信和自动化脚本；第11~15天做本地部署、并发推理和避坑收尾。适合认真把DeepSeek当工具用的开发者、内容生产者，以及想给团队统一搭AI入口的技术负责人。

2. 前5天：把平台基础、模型选型和API准备做扎实

15天计划的头5天只有一个目标：让一个真实请求从你自己的代码里发出去，并且能看懂响应里的每个字段。很多教程上来就是「注册→复制密钥→调接口」，却跳过了关键的一步：理解DeepSeek平台的分层结构。这层理解决定了后面10天遇到问题，你去查模型文档、开放平台文档还是客户端配置。先花半天把这三层关系理清，后面每一步都快。

2.1 DeepSeek平台的三层结构：模型层、开放平台层与应用层

DeepSeek平台不是单一的聊天网站，而是由三层组成的AI服务体系。第一层是模型层：DeepSeek-V3负责通用对话、写作、代码生成，响应快；DeepSeek-R1是推理增强模型，在数学、逻辑和复杂代码任务上表现更强，但响应更慢、单位token消耗也更高。第二层是开放平台层：API密钥、用量统计、模型路由和计费都在这层完成，所有对外调用都走这里。第三层才是你日常看到的应用层：网页对话、第三方客户端、你自己写的脚本或机器人。

理解这三层之后，一个常见困惑就解开了：网页聊天和API调用是两个通道，网页会话不计入API用量，API调用也不出现在网页聊天记录里。如果你只是随便问问，用网页版没问题；如果要做自动化、要接机器人、要做产品，必须走API。很多人在第3天就卡在这里——分不清「平台」和「接口」的关系，配置时填错地址，白白耗掉一整天。

把模型选型也放在这一节，方便后续直接引用。实际使用中，我会默认「通用任务优先选DeepSeek-V3接口，只有数学、推理、复杂代码审查这类任务才选R1接口」。R1不是任何场景的默认选项，因为它的思维链过程更长，同样的字数要求会消耗更多token。下表是我常用的选型参考：

注意一个细节：API里的模型参数名并不是「deepseek-v3」「deepseek-r1」这样的大名，而是deepseek-chat和deepseek-reasoner这两个路由名。开放平台用路由名指向当前版本的模型，模型更新时路由名不变，你的代码不用跟着改。这类命名细节，不实跑一遍很难注意到。

2.2 注册、实名与API密钥：第一天就完成的三件事

第一天不要急着写代码，先把三件事办完：注册账号、完成实名认证、创建API密钥。密钥在创建页只完整显示一次，关掉页面就再也看不到了，只能重新生成。我吃过这个亏——第一次拿到密钥随手截了个图，后来想复制到服务器，发现截图模糊，只能重新生成一份，旧的作废。

创建好密钥后，立刻把它放进环境变量，不要写死在代码里。这是最便宜的一道安全防线：写死在脚本里，一旦代码被带到别处、提交到仓库，密钥就泄露了，账单上会出现你完全不认识的调用量。常见做法是在项目根目录放一个.env文件，.gitignore里把.env排除掉，程序启动时读取。Windows PowerShell和Linux/macOS的写法略有不同，你自己平时用哪个就直接复制哪条：

# Linux / macOS 临时写入当前终端会话 export DEEPSEEK_API_KEY="sk-你的密钥"

# Windows PowerShell 临时写入当前会话 $env:DEEPSEEK_API_KEY = "sk-你的密钥"

两条命令都只对当前终端会话生效，关掉终端就没了，不影响系统的全局环境。如果你希望永久生效，Linux/macOS把export那行追加到~/.bashrc或~/.zshrc，Windows在「系统属性→环境变量」里新建用户变量。注意：密钥用双引号包起来，防止复制时在开头或结尾带入空格——这个空格是后面401报错的经典来源，第5章会专门讲。

提示：API密钥只显示一次，丢失只能重新生成。生成后立刻放进环境变量或本机密钥管理器，不要截图、不要发到聊天工具里。

如果对token消耗有管理需求，还可以在开放平台后台设置用量上限或充值预警，防止某次失控调用烧光额度。团队场景建议做企业认证，额度、发票和成员管理都会方便很多。这一步虽然枯燥，但15天计划里最不能跳过的就是它。

2.3 用Python跑通第一次DeepSeek API调用：最小可运行代码

环境准备好之后，第一次API调用不要写复杂逻辑，就跑通一个最小请求：把一句话发给模型，把回复打印出来。DeepSeek开放平台提供OpenAI兼容接口，所以直接用openai这个Python库就行，不需要额外装DeepSeek专用SDK。安装库用一行命令：

pip install openai

安装完成后新建一个chat.py，写下面这几行：

import os from openai import OpenAI # 从环境变量读取密钥，避免硬编码 client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com" ) resp = client.chat.completions.create( model="deepseek-chat", # 路由名，指向DeepSeek-V3 messages=[ {"role": "system", "content": "你是一个资深的Python工程师。"}, {"role": "user", "content": "请用一句话解释什么是RAG。"} ], temperature=0.4, # 偏低，让回答更稳定 max_tokens=256 # 限制回复长度，防止超出预期 ) print(resp.choices[0].message.content)

这段代码的逻辑是：先创建一个OpenAI客户端，指定DeepSeek的base_url，这样SDK就知道所有请求都发往DeepSeek而不是OpenAI；然后调用chat.completions.create发起一次对话补全请求；最后从resp.choices里取出模型生成的文本。messages数组里可以同时放system和user消息，system用来设定角色和约束，这是后面所有高级用法的基础。

几个参数值得记住。model填deepseek-chat，对应V3模型；如果做复杂推理，换成deepseek-reasoner，对应R1模型，但响应会慢一些。temperature控制随机性，0到2之间取值，写作、头脑风暴可以调到0.8以上，代码生成、数据提取建议0.3以下。max_tokens是单次回复的最大输出长度，不设的话可能生成一篇长文，对预算敏感的接口调用建议显式设置。

跑起来之后，还可以把stream改为True体验流式输出：模型逐字返回内容，体验接近网页版，但代码处理方式不同——需要遍历resp而不是直接取message.content。这一步先不展开，等你把简单调用跑通再玩流式。

3. 第6~10天：把DeepSeek接进编辑器、企业微信与自动化脚本

前5天你已经让代码能调用DeepSeek了，但「能调用」距离「好用」还远。中间这5天只有一个指标：DeepSeek出现在多少个你每天必用的工具里。我会按「客户端验证→编辑器集成→消息机器人」三步走，每一站都是真实场景，让你在工作流里感受到API接入带来的变化。

3.1 先别写代码：用客户端把API变成团队工作台

进入第6天，第一件事不是敲代码，而是把API密钥填进一个AI客户端里。市面上Chatbox、Cherry Studio这类桌面客户端都支持自定义OpenAI兼容接口，填入base_url和密钥就可以直接对话。这一步的产出不是技术，而是让你先习惯「用API」而不是「用网页」的体验差异。

为什么不直接用网页版？两个原因。第一，网页版和API是两套独立通道，网页会话不计入API用量，API调用也不出现在网页聊天记录里，团队想统一统计消耗就无从下手。第二，网页版的会话管理是黑匣子，你没法控制上下文保留多久、什么时候被截断；客户端通常把会话数据存在本地，你可以随时审查、导出、删除，这对内容敏感的场景很重要。

团队场景下，我更推荐由一个人统一申请API密钥，配置到每个成员的客户端里。好处是计费集中、权限可控，成员离职了直接吊销这个密钥，不会出现「人走了还拿公司的key在外面跑」的情况。同一个密钥在多台设备同时用是允许的，只要开放平台没有并发限制——设置界面里通常会标明，按提示操作即可。

注意：客户端里如果同时配置了多个模型服务，别把上下文窗口、计费规则混在一起。不同服务的context长度和计费方式不同，同样一段长对话，在A服务可能已经超限，在B服务还能继续。第5章会专门讲上下文超限的坑，这里先记住一句：对话历史越长的会话，越要在配置里确认模型服务给出的上下文上限。

3.2 在VSCode里接入DeepSeek：Continue、Roo Code与Codex的通用配置

从第7天开始，让DeepSeek进入你写代码的地方。VSCode生态里的Continue、Roo Code、Cline这类AI编程插件，多数已经把DeepSeek作为预设Provider——装好插件、在设置里选DeepSeek、填API密钥就能用，不用写代码。以Continue为例，它的配置在~/.continue/config.json里，核心是这样一段：

{ "models": [ { "provider": "deepseek", "model": "deepseek-chat", "apiKey": "sk-你的密钥" } ] }

逻辑上，Continue发起的每个补全请求都会走DeepSeek的OpenAI兼容接口，密钥只存在于本机配置里。model字段同样填路由名deepseek-chat，日常代码补全用V3足够，如果让插件帮你做跨文件重构、复杂逻辑审查，可以临时切到deepseek-reasoner。各插件对reasoner模型的流式输出支持程度不同，切过去实测一下，响应不稳定就换回来。

如果你用的是Codex、Claude Code这类Agent型编码工具，接入方式稍有不同：它们本身支持自定义模型endpoint，把base_url指向DeepSeek即可。这种做法的本质是让工具把DeepSeek当作一个OpenAI兼容服务来调用，所以配置项不是「DeepSeek预设」，而是「自定义OpenAI兼容endpoint」。常见配置是把环境变量里的OPENAI_BASE_URL改成https://api.deepseek.com，模型名改成deepseek-chat，密钥换成DeepSeek的。

关键提醒：所有写在配置文件里的密钥都要小心。Continue的config.json经常被提交进Git仓库，一旦仓库是公开的，密钥和你的调用额度就一起暴露了。我一般建议在config.json里用${DEEPSEEK_API_KEY}引用环境变量而不是写死原文，插件运行时自动读取。另外，插件自动补全的代码质量取决于模型对仓库上下文的理解，在项目里放一个清晰的README和规范的目录结构，比任何提示词都管用。

3.3 用FastAPI写一个企业微信/公众号机器人：最小可跑版本

第8~9天做一个最贴近真实需求的事情：把DeepSeek接进企业微信或公众号，让同事在聊天框里直接问AI。这类机器人本质上是一个webhook服务——微信后台收到消息后，把内容POST到你的服务地址，你转发给DeepSeek，再把回复POST回微信。先上一个最小可跑版本，用FastAPI实现：

import os from fastapi import FastAPI, Request from openai import OpenAI app = FastAPI() client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com" ) @app.post("/webhook") async def webhook(request: Request): # 简化版：生产环境必须校验签名、处理消息去重 data = await request.json() user_message = data.get("content", "") if not user_message: return {"reply": "消息为空"} resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是企业内部的AI助手，回答简洁准确。"}, {"role": "user", "content": user_message} ], temperature=0.3, max_tokens=512 ) reply = resp.choices[0].message.content return {"reply": reply}

这段代码的逻辑链路：微信后台把用户消息以JSON POST到/webhook，FastAPI解析出content字段，拼进messages数组发给DeepSeek，拿到回复后原路返回。微信收到返回的reply字段，就把它作为机器人的回复推给用户。对于公众号开发模式，消息格式略有不同，但主干逻辑完全一样——接收、转发、回写。

几个参数按消息场景做了特殊调整。temperature设为0.3，避免AI回复过于随机，企业内部问答要的是稳定不是惊喜。max_tokens设为512，防止AI在聊天框里输出一篇长文，把同事的对话体验搞崩。system提示词里加了一句「回答简洁准确」，这句话在消息机器人场景比任何参数都管用。

这个demo能跑通，但距离生产还有四件事必须补：签名校验（微信后台会带加密签名，不能裸奔）、消息去重（用户连点两次会重复投递，AI会回复两次）、超时处理（DeepSeek响应超过微信接口超时时间，要用被动回复加主动推送的方式）、内容安全过滤（企业内部需要考虑的消息边界）。这些不是DeepSeek的问题，是微信接入机制本身的约束。第一次做的人往往会卡在「demo能跑但微信收不到回复」，原因多半就是签名校验没过，请求被微信后台丢弃了。排查时先看服务日志有没有收到来自微信的调用，再往上一层看。

4. 第11~13天：本地部署DeepSeek与vLLM并发推理

第11天开始进入本地部署环节。为什么要本地部署？三个理由：数据不出内网、没有按token计费压力、以及模型完全由你自己控制。但本地部署不是白嫖——显存、内存、并发调优都要付出真金白银的硬件成本。这一章按「选型→Ollama快速验证→vLLM服务化」的顺序讲，先用手头上的机器跑通，再谈生产级并发。

4.1 先选型：本地部署该用DeepSeek哪个模型、什么量化、多少显存

本地部署DeepSeek，指的是部署DeepSeek开源的模型权重。DeepSeek-V3这样的完整模型参数量很大，普通机器根本跑不动，实际落地通常选DeepSeek-R1的蒸馏版本（Distill），它们把R1的推理能力压缩到了小模型里，配合量化可以塞进个人电脑或单卡服务器。选型时第一个要认清的概念是量化：把模型权重从高精度浮点数压缩到低精度，例如Q4_K_M表示4比特量化，体积约为原模型的四分之一，推理时显存占用大幅下降，代价是极小的精度损失。

我一般按目标硬件的显存大小倒推模型选择，下面是常见经验值，基于8~14GB消费级显卡和24GB专业卡的典型场景：

表格里「约」字很关键：实际占用还受上下文长度和显存预留策略影响，同一模型上下文从4K拉到32K，显存占用可能翻倍。选型时先按表格估算下限，再把上下文长度对应的余量加进去。内存同样重要，模型权重加载时会占一块RAM，建议物理内存不小于目标显存的1.5倍，否则可能出现内存换页导致的卡顿。

另一个要提前想清楚的问题是：本地部署选Ollama还是vLLM。我的判断标准很简单——个人电脑、想跑通验证、要的是零配置体验，选Ollama；服务器场景、有并发请求、要接入统一API网关，选vLLM。Ollama的模型管理、命令交互做得顺手，但高并发吞吐不是它的强项；vLLM用PagedAttention做显存管理，能把并发推理吞吐顶上去，代价是安装配置复杂、对CUDA环境要求高。先Ollama后vLLM的顺序，能避免一上来就被vLLM的依赖问题劝退。

4.2 用Ollama两条命令跑起DeepSeek-R1：最小可行部署

第12天做一次完整的本地部署，目标是在自己的机器上把模型跑起来并能对话。Ollama把这步压缩到了两条命令：拉取模型和启动交互。以7B蒸馏版为例：

ollama pull deepseek-r1:7b ollama run deepseek-r1:7b

pull负责从模型仓库下载权重到本地，run负责加载并进入交互对话模式。命令里的deepseek-r1:7b对应DeepSeek-R1-Distill-7B的一个已量化版本，Ollama会自动选择适合你硬件的默认量化精度，不需要手动指定Q4或Q8。如果你是NVIDIA显卡，Ollama会自动走CUDA加速；没有独立显卡的机器，CPU也能跑，只是速度慢很多——7B模型在纯CPU环境下大约每秒几个token，够对话但不够干活。

run起来之后，Ollama会在本地启动一个API服务，默认监听11434端口。这个服务同样兼容OpenAI接口，于是你之前写的那段Python调用代码几乎不用改，只要把base_url从https://api.deepseek.com换成http://localhost:11434/v1，就能把请求发往本地模型。这一步是我最喜欢的地方：从云端API切换到本地部署，业务代码改动量只有一行。

如果7B模型在你这台机器上太慢，先别急着换更大的模型，检查两个地方。第一，看Ollama日志确认是否真的用了GPU，跑一次对话后看输出有没有CUDA相关日志。第二，会话里长上下文会显著拖慢推理速度，Ollama默认会记住整个会话历史，如果只是测速度，每次起新会话会更接近真实推理速率。

提示：模型下载中断也不要慌，重新执行pull会自动从断点继续，这是Ollama比较省心的地方。

验证部署是否成功，除了交互对话，还可以用curl直接探一下API：

curl http://localhost:11434/api/generate \ -H "Content-Type: application/json" \ -d '{"model": "deepseek-r1:7b", "prompt": "1+1=", "stream": false}'

这个请求会返回一个JSON，里面包含模型生成的回复和耗时统计。看到正常输出说明本地推理链路是通的，接下来就可以决定要不要上vLLM做并发服务了。

4.3 上vLLM：把单机推理变成并发服务

第13天解决最后一个硬需求：多人同时用。Ollama在多用户并发时容易排队堆积，vLLM通过PagedAttention技术和连续批处理把GPU显存利用率提上来，延迟和吞吐明显改善。vLLM的部署以模型仓库为入口，一条命令拉起一个兼容OpenAI的服务：

pip install vllm vllm serve deepseek-ai/DeepSeek-R1-Distill-7B \ --served-model-name deepseek-r1-7b \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9

先解释复用逻辑：vllm serve命令会去拉取模型权重，启动后默认监听8000端口，提供的接口路径是/v1/chat/completions，和OpenAI格式完全一致。也就是说，你第2章写的调用代码，只要把base_url改成http://服务器IP:8000/v1，模型名改成deepseek-r1-7b，就能直接连上这个本地服务。

四个参数务必理解后再调。--served-model-name是服务对外暴露的模型名，客户端调用时传这个名字，我习惯把它和模型实际名称区分开，方便后续模型无感升级。--tensor-parallel-size是并行推理的GPU卡数，单卡填1，多卡环境可以填2或4，但前提是卡间带宽足够，否则通信开销会抵消收益。--max-model-len是单次请求的最大上下文长度，8192表示上下文窗口8K，这个值调大一块，KV Cache显存占用就涨一块，要和显存一起规划。--gpu-memory-utilization是显存利用率上限，0.9意味着给CUDA图的创建和其他进程留出10%余量，别贪心想填0.99，CUDA OOM往往就是这么填出来的。

服务起来后，用curl做一次健康验证：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-r1-7b", "messages": [{"role": "user", "content": "写一个快速排序"}], "max_tokens": 512 }'

返回里会包含模型生成的正文、token消耗和用时统计。重点关注三个数字：生成耗时长不长、输出token数和预期是否一致、有没有出现截断。如果返回的content为空但finish_reason是length，说明max_tokens设小了，调大即可。

vLLM部署常见的拦路虎是环境依赖：CUDA版本、PyTorch版本、vLLM版本三者必须匹配。安装时别用最新版PyTorch硬配旧版CUDA，直接看vLLM官方对CUDA版本的要求装对应环境。这个坑几乎每个第一次用vLLM的人都踩过。

5. 第14~15天：避坑——DeepSeek使用中的5个经典翻车现场

14天跑下来，你手上应该同时有API调用、工具集成和本地部署三条链路。最后两天不学新东西，专门做一件事：把最常见的翻车点逐条排一遍。下面5个问题是我在实际使用中或者帮别人排查时反复遇到的，每一条按「现象→原因→解决」写，你可以直接照着查。

5.1 现象：API报401但密钥明明是对的

现象：调用API时返回401 authentication error，反复核对密钥没抄错，网页版对话正常，就是API不让进。

原因：最常见的是密钥被复制进了不可见字符，比如开头或结尾的空格；其次是.env文件读取时机不对，程序启动时环境变量还没加载；再有一种情况是把网页版的登录凭证当成了API密钥，这是两个东西。

解决：重新生成一个密钥，粘贴进环境变量时确认首尾没有空格；在代码里打印len(api_key)看看长度是否和后台显示一致；确认.env是被程序显式读取的，而不是仅仅放在项目目录里就指望生效。

5.2 现象：长对话到上限后，新对话完全不记得上一轮说了什么

现象：会话聊到一定长度后，你问「刚才那个问题结论是什么」，模型一脸茫然，甚至开始胡说。

原因：上下文长度有上限，超过上限后最早的内容被截断或压缩，模型只看得见最近一段对话。DeepSeek的API支持把对话历史放在messages里，但messages的总token数不能超过模型的上下文窗口。

解决：要么把历史对话压缩成摘要再塞回messages，要么只保留最近几轮。我一般会在本地维护一个「记忆池」，当对话变长时，先请模型对前面的内容做一次摘要，把摘要和最近几轮消息一起提交，效果比简单截断好很多。摘要模板可以是这样：

请把以下对话压缩成300字以内的摘要，保留关键决定、数字、结论和待办事项： [这里粘贴前面的对话原文]

这段提示词的本质是让模型把长上下文「蒸馏」成短记忆，然后你用这个摘要替代原文，从而绕开上下文窗口限制。

提示：摘要是会失真的，涉及精确数字和承诺时，把原文的关键段落单独保留，不要全指望摘要。

5.3 现象：局域网里部署带skill的工具链，读文件报SetNamedSecurityInfoW failed (win32)

现象：在内网服务器上用harness类工具跑带skill的工作流，加载后读取文件时报错SetNamedSecurityInfoW failed (win32)，文件明明存在，权限看起来也对。

原因：这个报错是Windows系统在设置文件安全属性时失败，常出现在以服务账户或系统账户运行的进程试图修改文件ACL的场景，或者目录被同步工具、杀毒软件占用。报错名看起来像系统故障，其实是进程没有权限对目标文件做安全设置。

解决：把运行用户改成有明确目录写权限的普通用户，而不是Administrator或SYSTEM；尝试把工作目录移到非系统盘；关闭该目录上实时扫描或同步工具后重试。Linux环境下同类问题多半是目录属主或SELinux上下文不对，用ls -Z看上下文，restorecon或chown修正即可。如果只是临时复现，以普通方式直接启动进程，别用服务方式，通常马上就能定位是不是权限问题。

5.4 现象：显存明明够用，vLLM/Ollama加载时却CUDA OOM

现象：按模型量化表估算显存足够，启动时却报CUDA out of memory，模型根本加载不上。

原因：估算时只算了权重，忘了KV Cache和CUDA context。上下文长度越长，KV Cache占显存越大；--gpu-memory-utilization设成0.99后，系统连绘图和其他进程的空间都没留，一个偶发占用的进程就能挤爆显存。

解决：用nvidia-smi先看当前显存占用，确认没有其他进程抢卡；把gpu-memory-utilization降到0.85左右重试；还是不行就把--max-model-len从8192降到4096。顺序是先降上下文、再降显存利用率，最后才考虑换小模型。

5.5 现象：生成内容AI味重，反复要求「去AI化」没用，甚至更差

现象：让DeepSeek写文案，输出一看就是AI写的，你反复加「不要像AI」「去AI化」，结果文字越来越僵硬。

原因：模型很难理解抽象否定指令。「不要AI味」没有给出可执行的风格目标，模型只能在原有输出风格里打转；而且重复强调「AI味」反而让模型对AI腔调的注意力变强，等于反向强化。

解决：把否定改成肯定描述，直接给样例、目标和边界。我常用这个模板：

请按下面的要求改写这段文字： 1. 用第一人称，语气像一位有10年经验的工程师在讲真实经历； 2. 每句话不超过30个字，删除所有「综上所述」「值得注意的是」这类过渡词； 3. 只保留一个具体案例，不要提出建议清单。 原文：[粘贴原文]

注意到区别没有：每一条都是可执行的肯定指令，模型知道每一步该做什么。要让DeepSeek产出不像AI的文字，核心不是「去AI化」，而是「给一个明确的作者人设和禁止词汇表」，让它往具体方向改写。这是我的血泪经验——提示词里的每条要求都要能让模型落地，否则就是玄学碰运气。

6. 第15天之后：把DeepSeek用出「精通感」的4个小技巧

第一个技巧是给系统提示词建立「可复用模板库」。零零散散写提示词是新手习惯，精通的操作者会把system prompt沉淀成文件，按任务类型分成写作、代码、问答、润色几类，用时直接加载。模板库的价值在于：稳定复现一种风格，而不是每次靠临场发挥。

第二个技巧是temperature与top_p的配合使用。我常用的组合是：事实提取类任务temperature设0.2、top_p设0.3，结果稳定；文案创作类temperature设0.9、top_p设0.7，输出更有变化。两个参数一起调的原因是temperature影响整体随机性，top_p影响候选词的收窄范围，单独调一个会出现「部分时刻稳定、部分时刻发散」的情况。

第三个技巧是长文档的投喂策略。把一份几十页资料一次性丢给模型效果很差，我一般先让模型列出全文提纲，再按章节分段投喂，每段提取要点后汇总。这个过程看起来多花了调用次数，实际总token消耗更低，输出质量也更高。

第四个技巧是做一个最简Agent闭环：让模型输出结构化JSON，你写脚本执行，把执行结果再喂回模型。比如让模型生成一组Shell命令，脚本执行后把输出返回，模型根据新输出决定下一步动作。两层循环做下来，DeepSeek就从「问答工具」变成了「能操作的执行器」。

我记得自己第一次把DeepSeek接进生产环境时，犯的就是最基础的错误——密钥写死在代码里，长对话不加摘要，最后被401和上下文超限折腾了两天。后来养成一个习惯：每次接入新场景之前，先把第5章那五类问题过一遍，再动手写代码。这条习惯帮我少走了很多弯路。希望帮到你。

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