简介这份PDF资料源自清华大学新媒沈阳团队面向希望借助大语言模型提升办公效率的职场人士与AI应用开发者系统讲解DeepSeek在真实工作场景中的落地方法。内容涵盖团队在人机协同、人机共生方向的研究背景DeepSeek在英伟达NIM、微软Azure、亚马逊AWS等平台的部署信息以及基础模型V3、深度思考模型R1与联网搜索模型RAG在规范性、路径灵活性和风险特征上的差异对比。资料还给出RTGO与CO-STAR两套提示语框架并延伸到可视化图表、海报设计、视频分镜、新媒体文案批量生成、市场调查与AI应用开发等场景兼顾操作规范与人机协作意识。资源包为1个PDF文件大小约10.02MB结构清晰便于通读与检索。目前已有599人学习适合想系统掌握DeepSeek提示词技巧与多场景应用思路的读者参考。1. 从一份清华 PDF 说起DeepSeek 进职场到底改变了什么2025 年开年到现在我身边做运营、做数据分析、做行政的朋友问得最多的一句话就是DeepSeek 到底能不能真用在职场里还是又一个看着热闹、落地翻车的玩具。清华那份《DeepSeek 如何赋能职场应用》的 PDF 之所以被反复转发恰恰是因为它戳中了一个真实痛点——大部分人不是不会用大语言模型而是不知道怎么把提示词、API 调用、本地部署这几件事串成一条能交付的工作流。我自己在过去几个月里把 DeepSeek 接进了周报生成、竞品调研、SQL 辅助、会议纪要整理四条链路踩过的坑比想象中多。这篇笔记不讲概念只讲我实际怎么搭、参数怎么调、哪里最容易翻车适合已经用过 ChatGPT 类工具、想把 DeepSeek 真正嵌进日常工作的从业者也适合刚接触提示词工程、想找一个能复现起点的新手。2. DeepSeek 职场落地的三条技术路线API、本地部署、客户端接入2.1 先想清楚你的场景该走哪条路很多人一上来就问DeepSeek 怎么本地部署但其实不是所有职场场景都需要本地跑。我一般按三个维度做选型数据敏感度、调用频率、硬件预算。如果只是写周报、润色邮件、生成会议提纲走官方 API 最省事按 token 计费几分钟就能跑通如果涉及公司内部合同、客户名单、未公开财务数据那就必须考虑本地部署把数据留在自己机器上如果是团队协作、需要多人共用一套提示词模板那客户端接入加统一提示词库更合适。路线适合场景硬件门槛数据是否出本地上手时间官方 API通用文案、调研、代码辅助无是10 分钟本地部署敏感数据、离线环境16G 显存起步否半天到一天客户端接入团队共用、模板管理无视配置而定1 小时这张表不是绝对的我自己就遇到过先用 API 跑通流程、再迁到本地的混合方案。关键是想清楚你处理的数据能不能出内网这决定了后面所有技术选择。2.2 API 调用最小可跑通的 Python 脚本先给一个我实际在用的最小调用脚本跑通它你就能理解 DeepSeek API 的基本结构。# deepseek_min_call.py # 最小可跑通的 DeepSeek API 调用示例 import os from openai import OpenAI # 从环境变量读取 key不要硬编码在代码里 client OpenAI( api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com # DeepSeek 兼容 OpenAI SDK 格式 ) response client.chat.completions.create( modeldeepseek-chat, # 通用对话模型 messages[ {role: system, content: 你是一名严谨的职场助理输出简洁、分点。}, {role: user, content: 把下面这段会议记录整理成三条待办……} ], temperature0.3, # 职场场景建议 0.2~0.5降低发散 max_tokens800 # 控制输出长度避免废话 ) print(response.choices[0].message.content)这段代码有三个关键点。第一base_url指向 DeepSeek 的兼容端点SDK 用法和 OpenAI 几乎一致所以如果你之前写过 OpenAI 的调用迁移成本极低。第二temperature在职场场景我一般压到 0.3 左右写文案可以放到 0.7但整理纪要、生成待办这种任务温度高了会开始编。第三max_tokens一定要设不设的话模型容易输出一大段客套话反而增加你后期筛选的成本。提示API key 永远走环境变量或密钥管理服务不要写进代码提交到仓库这是血泪经验。2.3 本地部署显存不够时的降级策略本地部署这块很多人卡在硬件上。我实测下来14B 级别的模型在 16G 显存的消费级卡上能跑但上下文一长就爆显存。如果你的机器只有 8G 显存别硬上大模型直接选 7B 量化版本牺牲一点推理质量换稳定性。部署工具常见做法是用 Ollama 或类似的一键拉取方案命令层面大致是这样# 拉取并运行一个 7B 量化模型示意具体模型名以你本地仓库为准 ollama pull deepseek-r1:7b ollama run deepseek-r1:7b # 查看当前运行的模型和显存占用 ollama ps跑起来之后真正的坑不在启动而在上下文长度和并发。本地部署默认上下文窗口往往比你想象的小处理长文档时会截断表现就是模型忘了前面说过什么。我的做法是把长文档先切块每块控制在 2000 字以内再用一个汇总提示词把分块结果拼起来。并发方面本地单卡基本只能扛一两个并发请求团队共用的话要么排队要么上多卡这一点在选型阶段就要想清楚别等上线了才发现同事一多就卡死。2.4 客户端接入与提示词模板管理如果你不想写代码客户端接入是最快让团队用起来的方式。核心不是装哪个客户端而是把提示词模板沉淀下来。我一般会建一个团队共享的提示词库按场景分类周报类、调研类、代码类、会议类。每个模板固定三件事——角色设定、输出格式、禁止事项。比如周报模板里我会明确写不要写在领导的关怀下这类套话直接列本周完成、下周计划、风险项。这一步看起来简单但它是团队能不能规模化用起来的分水岭。没有模板每个人问法不一样输出质量就完全靠运气。3. 提示词工程在职场场景的四个可复用套路3.1 结构化输出让模型直接产出能用的表格职场里最没用的输出就是一大段看起来很有道理的话。我要求模型输出必须结构化最常用的就是让它直接吐 Markdown 表格或 JSON。这里有个技巧不要只说用表格输出要把表头写死。prompt 你是竞品分析助理。请针对以下三家产品输出一张 Markdown 表格。 表头固定为产品名 | 核心功能 | 定价 | 目标用户 | 明显短板 不要添加表头以外的列不要写总结段落。 产品信息…… 把表头写死的好处是输出可以直接粘进飞书或 Notion不用再手动调整。参数上这种任务temperature设 0.2 就够越低越稳定。如果模型偶尔多输出一列那说明你的不要添加表头以外的列这句话权重不够可以把它放到 system 角色里约束力更强。3.2 分步推理复杂任务的拆解提示词遇到帮我分析这份数据并给出建议这种模糊需求直接问一定翻车。我的做法是强制模型分步先复述任务、再列分析维度、再逐维度给结论、最后给建议。这个套路在处理大语言模型擅长的长文本任务时特别有效因为它把一次性生成变成了分阶段收敛。prompt 请按以下四步处理每步用标题分隔 第一步用一句话复述你理解的任务目标。 第二步列出你打算分析的 3 到 5 个维度。 第三步逐维度给出结论每个结论必须引用原文中的具体信息。 第四步基于结论给出不超过 3 条可执行建议。 如果原文信息不足以支撑某个维度直接写信息不足不要编造。 最后那句不要编造是我踩坑之后加的。早期我没写这句模型会在数据缺失时自己脑补一个合理数字看起来特别真但一核对就露馅。职场场景里编造比不输出更危险。3.3 角色与约束把不要做什么写清楚提示词工程里大家习惯写你要做什么但真正拉开差距的是你不要做什么。我一般会在 system 里固定几条禁止项不要用感叹号、不要写总之、不要输出超过 500 字、不要用我们这种模糊主语。这些约束看起来琐碎但能大幅降低后期编辑成本。尤其是不要输出超过 X 字能逼模型把话说清楚而不是靠堆字数显得专业。3.4 上下文工程长文档怎么喂才不丢信息DeepSeek 这类模型上下文窗口虽然不小但能塞进去和能记住是两回事。我的经验是长文档不要整篇丢先做一次摘要再把摘要和关键原文片段一起喂。具体做法是第一轮让模型对每个章节生成 100 字摘要第二轮把摘要拼起来做全局分析第三轮针对具体问题回查原文。这个三轮法比一次性塞 5 万字稳定得多代价是多花一点 token但换来的是结果可追溯。4. 避坑与排查DeepSeek 职场落地最常见的五个翻车点4.1 现象API 返回正常但内容明显是编的原因temperature设太高或者提示词里没有信息不足时明确说明的约束。模型在低置信度时会倾向于补全而不是承认不知道。解决把temperature降到 0.2~0.3并在提示词里加一句如果原文没有相关信息直接回答原文未提及。我还会在关键任务上加一步人工抽检随机核对两三条输出。4.2 现象本地部署跑着跑着就卡死或返回空原因显存被上下文吃满或者并发请求超过了单卡承载能力。表现是进程还在但响应越来越慢直到超时。解决先看ollama ps或对应的显存监控确认占用。然后限制单次输入的上下文长度长文档切块处理。团队共用的话加一个简单的请求队列别让所有人同时打。4.3 现象同一个提示词今天好用明天就不好用原因模型版本更新、服务端参数调整或者你的输入数据分布变了。大语言模型不是确定性程序同样的输入不保证同样的输出。解决把提示词和关键参数版本化管理每次输出异常时先对比是不是模型侧变了。重要任务不要依赖单次输出跑两到三次取交集或人工判断。4.4 现象输出格式总是差一点表格缺列或多列原因格式约束写得太软或者放在了 user 角色里权重不够。解决把格式要求写进 system 角色并且给出一个正确示例。模型对示例的遵循度远高于对描述的遵循度。如果还不行就在输出后加一步程序化校验用正则或 JSON schema 检查不合格就重试。4.5 现象敏感数据不小心走了 API原因团队里有人图方便直接把内部文档粘进了在线客户端。解决这条只能靠流程不能靠技术。我的做法是把敏感场景的入口收窄只保留本地部署通道同时在团队里明确哪些数据绝对不能出内网。技术上可以做一层输入检测命中关键词就拦截但根本还是人的意识。5. 进阶技巧把 DeepSeek 接进你的自动化工作流5.1 用脚本把重复任务串起来单次对话解决不了每天自动生成日报这种需求。我的做法是写一个定时脚本把数据源、提示词、API 调用、结果落盘串成一条流水线。核心结构大概是这样# daily_report.py # 每天定时拉取数据 - 调用 DeepSeek - 生成日报 - 写入文件 import json from datetime import datetime from openai import OpenAI client OpenAI(api_keyos.getenv(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com) def build_prompt(raw_data: str) - str: return f 你是数据分析助理。基于以下原始数据生成一份日报。 格式要求 1. 今日关键指标不超过 5 条 2. 异常波动及可能原因没有就写无 3. 明日建议关注项不超过 3 条 不要写客套话不要编造数据中没有的数字。 原始数据 {raw_data} def generate_report(raw_data: str) - str: resp client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: build_prompt(raw_data)}], temperature0.2, max_tokens1000 ) return resp.choices[0].message.content if __name__ __main__: raw open(today_data.txt, encodingutf-8).read() report generate_report(raw) filename freport_{datetime.now().strftime(%Y%m%d)}.md with open(filename, w, encodingutf-8) as f: f.write(report) print(f已生成 {filename})这个脚本的价值在于把提示词变成了可版本化的代码。你可以把它挂到 cron 或任务计划里每天早上自动跑。参数上日报类任务temperature固定 0.2max_tokens控制在 1000 以内避免模型自由发挥。5.2 验证输出质量的三个土办法自动化跑起来之后最大的问题是你怎么知道它今天没胡说。我一般用三个土办法做抽检第一随机抽一天人工核对日报里的数字和原始数据是否一致第二在提示词里要求模型对每个结论标注来源没有来源的结论直接标红第三每周跑一次对抗测试故意喂一份缺数据的输入看模型会不会编。这三个办法不优雅但能兜住大部分风险。5.3 我自己的习惯我现在做任何 DeepSeek 落地第一步都不是写提示词而是先想清楚这个任务的失败长什么样。是编数据、是格式乱、还是漏信息想清楚失败模式提示词和校验才有方向。另外我坚持把每次调好的提示词存进一个共享文档标注适用场景和已知问题因为提示词这东西过两周你自己都忘了当时为什么那么写。希望帮到你。本文还有配套的精品资源点击获取
