简介：一套聚焦大模型辅助工作场景的演示文稿，共五十七页，面向职场办公人群、高校师生及对AI提效感兴趣的入门学习者。内容围绕大模型辅助检索、辅助办公、辅助创作三大主线展开，并结合联网搜索功能，对比传统检索在大纲生成、多轮连续查询、实时信息获取等方面的优势。资源为一个演示文稿文件，压缩包约二十一点七四MB，页面结构清晰，适合用于培训分享或个人自学。目前已有128人学习浏览。课件还重点演示了秘塔写作猫、ChatPDF、文心一言、通义千问、Deepseek、Kimi等主流平台的实际操作，涵盖论文信息补全、Word全文写作、PDF问答等具体案例，能帮助读者快速理解并上手大模型辅助工作的方法，是一份兼具概念解析与操作示例的入门资料。
1. 大模型辅助工作：检索、办公与创作三条操作线的实际边界
把同样一个问题分别丢给搜索引擎和 AI 大模型，你得到的不是两种答案，而是两种完全不同的信息处理机制：一个返回链接让你自己判断，另一个直接把结论摆在你面前。很多人误以为「大模型辅助工作」就是把问题打进对话框这么简单，实际上它分成检索、办公、创作三条完全不同的操作线，每条线的工具选型、交互方式和验证标准都不一样。这套 57 页的 PPT 内容没有停留在概念层面，而是把每条操作线的具体平台、开关位置、生成流程都拆开了。对 IT 从业者来说，真正有价值的地方在于：你能据此判断哪些任务可以放心交给模型，哪些环节必须保留人工控制，以及当模型输出可疑时该去哪里排查。
2. 联网搜索与大模型辅助检索：从关键词匹配到意图理解
2.1 联网搜索是大模型的额外集成工具，不是自带能力
先说一个容易混淆的前提：大模型本身不具备实时访问互联网的能力。无论是 Kimi、DeepSeek 还是 ChatGPT，模型承载的是训练阶段从海量语料中习得的静态知识，通常只覆盖到某个截止时间点。联网搜索功能是通过接口与搜索引擎或其他在线资源集成实现的，属于嵌入模型的一项额外工具。因此你会观察到同一个模型在开启与关闭联网开关时表现差异明显：关掉后它依赖记忆回答，遇到「今天发布的显卡参数」这类问题就会给出过时信息甚至编造数据；开启后它先检索再组织答案，并在回答中整合浏览过的页面内容。
这套分工机制决定了使用方式：需要常识性和方法论类问题时不必开联网，模型内部知识足够应对且响应更快；涉及新闻事件、产品参数、论文状态、天气市场等时效性信息时则必须开启。PPT 中强调大模型能将被浏览过的网页信息进行整合并直观返回结果，这个「整合」过程在工程上等同于一次检索增强生成（RAG）流程。自建本地知识库时，检索增强的效果取决于文档切分粒度、向量化模型和 Top-K 召回参数，与模型本身的能力同样关键。
2.2 主流平台的联网搜索开关差异
PPT 明确将检索平台划分为两种类型：默认开启联网搜索，以及提供手动开关按钮。这个差异不是产品设计上的随意选择，而是与各平台的定位和知识更新策略相关。
| 平台 | 联网搜索方式 | 注意点 |
|---|---|---|
| 文心一言、通义千问、腾讯元宝、Grok | 默认开启 | 对话输入框即时检索，适合实时信息类问题 |
| DeepSeek、Kimi、ChatGPT、Gemini | 手动开关 | 输入框下方「地球」按钮，按需开启 |
| 自建模型服务（Ollama、vLLM 部署） | 需自行集成 | 无内置检索，通过 API 挂接搜索服务 |
手动开关的平台需要操作者形成习惯：开错状态容易把时间浪费在等待上。用 DeepSeek 查询本地文件路径时不应开启联网，ChatGPT 问训练数据截止日期后的技术版本时则必须打开。默认开启的平台省去这一步，但代价是每次对话都产生检索延迟，涉及纯知识问答时反而拖慢节奏。
2.3 三种典型检索场景的操作路径
PPT 列举的三种检索场景，本质上对应了大模型辅助检索的三个核心能力维度，即多轮连续性、信息整合性和实时性。
论文信息补全。传统方式是你搜索标题、记下出处、逐篇打开 PDF 再手动提取作者、期刊和发表日期。大模型的方式是在对话框里粘贴论文标题，让它一次性返回完整的元数据库。注意这里有一个细节：最好在提问中明确「请给出该论文的准确出处和引用格式」，否则模型可能只返回标题层面的信息，遗漏卷号、页码等关键字段。补全结果需要通过交叉核对确认，后文 2.4 节会给出具体验证脚本。
多轮对话的连续检索。传统搜索每一轮的查询彼此独立，第一次搜「Transformer 架构」，第二次搜「注意力机制」，搜索引擎不会自动把两次的结果关联起来。大模型则保持对话上下文：你先问「vLLM 部署大模型的显存占用如何估算」，再追问「如果换成 FP16 量化呢」，模型能理解第二问的主语仍是 vLLM 部署场景，并针对性地给出调整后的数值范围。连续性在检索中的真实价值是逐层收敛：第一轮圈定范围，第二轮缩小候选，第三轮定位答案，每轮比上一轮更具体。
实时信息查询。这项优势在涉及 2024 年之后发布的技术栈时体现得最为明显。传统搜索只返回参考网页，你需要逐一打开判断是否可行；大模型直接给出概括性答案，并提供来源列表。但要留意一个坑：整合多个来源时模型可能把不同来源之间互相矛盾的信息做「平滑处理」，掩盖了冲突。做法是看到汇总结果后追问一句「这些信息是否有不一致的地方」，让模型展示证据链。
2.4 检索结果质量的验证
联网搜索看起来省事，但返回结果不可信时反而更费事。常见错误是只用一个平台检索，直接把生成的答案写进报告。更稳的做法是对关键事实做交叉验证。如果接入的是 OpenAI 兼容接口，可以用脚本批量比对多个模型的输出：
import requests def query_llm(messages, model_name, api_base, api_key): """通用对话接口脚本，兼容 DeepSeek/ChatGPT/本地部署服务""" resp = requests.post( f"{api_base}/v1/chat/completions", headers={"Authorization": f"Bearer {api_key}"}, json={ "model": model_name, "messages": messages, "temperature": 0.2, "max_tokens": 512 }, timeout=60 ) return resp.json()["choices"][0]["message"]["content"] # 同一问题发给两个不同来源，用于交叉核对事实类信息 question = "2025年发布的消费级显卡中，显存容量最大的是哪一款？" answer_1 = query_llm( [{"role": "user", "content": question}], "deepseek-chat", "https://api.deepseek.com", "你的key" ) answer_2 = query_llm( [{"role": "user", "content": question}], "gpt-4o-mini", "https://api.openai.com", "你的key" ) print("答案1:", answer_1) print("答案2:", answer_2)脚本里temperature设为 0.2 是为了压制随机性，让事实类回答尽可能稳定；max_tokens限制截断成本。当两个模型的答案在关键数字和结论上不一致时，需要把问题拆成更小的子问题逐一排查。自建 RAG 服务的场景下，同样用这种脚本验证不同召回参数的效果：同一问题跑三组 Top-K 值，对比答案与文档片段是否对应得上。
3. 大模型辅助办公：Word、PDF、Excel 场景下的工具与自动化路径
3.1 Word 场景：秘塔写作猫的结构化生成流程
文档撰写是大模型办公中最成熟的场景。PPT 以秘塔写作猫为例演示了完整链路：填入文章标题后选择篇幅、是否自动配图和摘要条数，AI 先生成摘要，再生成大纲，最后按照大纲逐条生成正文。这个流程的核心价值在于把一个大的写作任务切成「摘要—大纲—正文」三段，每一段都由人工确认，而不是一次性让模型输出整篇内容。
实际操作时，点进「全文写作」功能，填入标题，把文章长度选在中等档位，打开自动配图，AI 会先给出摘要。确认摘要后进入大纲编辑页。大纲阶段可以直接拖拽调整章节顺序，或删除不需要的条目，比如「市场需求分析」这节对内部周报没意义，可以当场删掉再点下一步。如果不想要大纲，界面里也有选项可以直接跳过，但建议非初稿场景保留大纲，因为后续修改正文时，大纲作为目录能让你快速定位到需要重写的章节。
结构化生成流程的工程含义在于：摘要步骤控制了全文基调，大纲步骤控制了章节边界，正文生成是在有限长度内填充内容，模型跑偏的概率显著低于一次性长文生成。这和代码生成是一致的——先定义接口签名再填充实现，比让模型一口气写完整模块更可控。
3.2 PDF 场景：ChatPDF 的交互式精读
ChatPDF 这类工具解决的是长文档精读效率问题。上传 PDF 后，它不是把全文塞进上下文窗口，而是对文档做切块和索引，之后每次提问都只检索相关片段拼接给模型。上传一篇十几页的英文论文，在对话框提问「这项研究的主要发现是什么」，工具会跨章节提取结论再生成汇总回答。更实用的用法是连续追问：先问「研究背景」，再问「核心方法」，最后问「局限性在哪」，一步步把文档内容挖干净。
用 ChatPDF 批量读论文时的提问顺序（每轮基于前一轮继续）： 1. 这篇文章想要解决什么问题？ 2. 它提出了什么方法，和现有的方法有什么本质区别？ 3. 实验使用了什么数据集和评估指标？ 4. 最大的局限是什么？有没有你无法从原文验证的表述？这组问题的逻辑是从「问题—方法—验证—局限」四个维度逐层收紧，每轮回答都可以追溯到原文位置。如果工具返回的答案无法定位到具体页码，说明切片检索召回失败，需要换一种表述方式重新提问。ChatPDF 这类工具的初期切块粒度一般是固定的几百个 token，文档里表格和公式密集的部分容易在切块时被截断，导致召回不全。
3.3 Excel 与 PPT 场景：从对话到批量处理
PPT 概述部分提到 Office 四大场景，但 Word 和 PDF 之外的具体操作讲得不多。实际工作里，Excel 表格的清洗、公式生成和数据解释，以及 PPT 的大纲生成与排版，同样是高频需求。Excel 场景常见的做法是让大模型生成公式或 Python 处理脚本，而不是直接让它读文件——因为你手里的表结构千差万别，模型无法预知列名和数据类型。
import pandas as pd # 用 pandas 读取待清洗的表格 df = pd.read_excel("销售数据.xlsx") print(df.head(), df.dtypes) # 让大模型根据列名生成清洗逻辑 prompt = f""" 表格列名: {list(df.columns)}, 数据类型: {dict(df.dtypes.astype(str))} 任务: 1. 识别包含缺失值的列并给出填充策略 2. 检测数值列中的异常值（超出3倍标准差） 3. 生成汇总统计表：按月统计销售额总和与订单量 请直接输出可运行的 pandas 代码，不要解释。 """ # 将模型生成的代码保存为 .py 后执行，输出结果写回 Excel注意这个流程里的关键点：模型输出的是代码而不是直接结果，人工审核后执行。列名和数据类型作为输入传入，模型才能生成匹配你表结构的代码。生成脚本执行出错时，把报错信息粘贴给大模型，让它修正，通常一两个来回就能跑通。这种方式同样适用于 PPT 场景——先让模型生成一套包含标题页、目录页、章节页的完整大纲，然后对照大纲在模板里逐页填充。
3.4 办公场景下的选型考量
| 办公场景 | 推荐工具 | 适用场景 | 局限性 |
|---|---|---|---|
| Word 长文 | 秘塔写作猫、Kimi | 报告、方案、制度文档 | 章节约稿后内容深度可能不够 |
| PDF 精读 | ChatPDF、通义文档 | 论文、合同、行业报告 | 扫描版 PDF 需先行 OCR |
| Excel 处理 | 通用对话模型 | 数据清洗、公式生成 | 复杂透视表仍需手动检查 |
| PPT 制作 | Gamma、Kimi PPT | 演示文稿大纲生成 | 设计细节需人工调整 |
选型时还要考虑数据敏感度。涉及内部财务数据、客户清单的文档处理，不建议直接发送到第三方平台。数据敏感的办公场景可以选择本地化部署方案，用 Ollama 部署私有模型跑 Word 和 Excel 任务。Ollama 部署私有模型的优势是数据不出内网，但需要注意显存大小决定能加载的模型参数量，7B 级别的模型跑文档摘要问题不大，处理复杂图表时能力会明显弱于云端商用模型。如果团队对吞吐量有要求，服务端可以用 vLLM 做推理框架，吞吐优势明显，但首次部署需要处理模型格式转换和显存分配。
4. 大模型辅助创作：结构化生成与多轮迭代的工作方法
4.1 创作任务拆解：从一句话到一个完整作品
大模型辅助创作不是「帮我写一篇文章」这样的单次对话，而是一个需要拆解、分步验证的工程过程。PPT 显示创作模块是独立成章的，但它内部的逻辑与 Word 场景一脉相承：先定结构，再填内容，最后打磨细节。
把创作任务拆成四个阶段：阶段一是定题，明确文体、读者和字数；阶段二是大纲，确定章节与要点；阶段三是逐节生成，每次只生成一个章节的内容；阶段四是合并润色，统一术语、调整语气和检查逻辑缺口。前两个阶段必须有人工参与，因为大纲决定了整篇内容的骨架。如果你自己都不知道本文要讲什么，模型生成的大纲大概率是套话的排列组合。
4.2 场景化的创作提示词模板
不同创作任务需要不同的提示词结构。PPT 里没有给出可直接复制的模板，但按照实践推导，一个合格的创作提示词应同时包含角色设定、任务描述、约束条件和输出格式。以下模板可作为基准：
# 角色 你是一名从事数据平台建设五年以上的资深技术专家，文风务实，避免空话。 # 任务 撰写一篇题为《数据仓库从 Lambda 架构到 Lakehouse 的迁移实践》的技术博客。 # 内容要求 1. 开篇用真实场景说明迁移动机，不要以"随着企业发展"开头 2. 包含至少一组架构对比表格，对比迁移前后差异 3. 给出核心建表语句和数据管道配置的关键参数 4. 每章结尾留一个具体的踩坑记录 # 约束条件 - 全文2000字左右 - 面向有三年以上数据开发经验的读者 - 不出现"赋能""抓手""闭环"等空泛词汇 # 输出格式 输出完整 Markdown 文档，含二级标题和三级标题，表格使用 Markdown 语法。模板里角色设定决定了文风，任务描述决定了内容范围，约束条件控制行文质量，输出格式保证结果可直接落地。生成之后先不要通篇采用——大模型在开篇部分容易写出发散性文字，需要单独检查。还有，每章结尾的踩坑记录是防止模型写得过于理想化，用真实案例约束生成倾向。
4.3 多轮迭代与内容质量控制
一次生成的草稿通常只能当毛坯。合格的创作流程至少要经历两轮迭代：第一轮检查结构，第二轮修改表达。结构检查关注各章篇幅是否均衡，逻辑是否连贯，有没有章节之间内容重叠；表达修改关注术语一致性、句式重复和长难句拆分。
迭代时每次只改一个变量。比如告诉模型「把第 2 章和第 3 章的案例统一用金融行业」，改完输出后进行比对；再告诉模型「压缩全文字数到 80%」，删减冗余段落。一次性把多个需求叠在一起提给模型，输出会顾此失彼。多轮对话的上下文窗口会累积前面的修改要求，这一点比每次重新开新对话更可靠，因为模型能感知之前的结构调整，避免改完第 3 章又把第 2 章改回原样。
PPT 中「讨论」这一节虽然没有展开，但核心议题应该是创作的边界。事实性材料、数字引用、法律合同条款等，必须由你亲自核实来源，模型生成的推荐语可以借鉴表达方式，但不能直接作为定稿。同样，图片素材生成涉及版权问题，商业用途需确认模型服务商对生成内容的使用授权范围。创作辅助提升的是生成速度而不是正确性，最终把关的责任在操作者。
5. Prompt 设计的四要素结构与大模型输出的复现验证
5.1 角色、任务、约束、格式四要素
把前几章用到的提示词归纳一下，会发现它们共享同一套框架：角色、任务、约束、格式。角色解决语言风格问题，任务解决内容边界问题，约束解决质量下限问题，格式解决可用性问题。缺任何一个要素，输出质量都会明显下降。缺少角色时模型默认使用百科式语气；缺少约束时回答冗长且充满正确的废话；缺少格式时你会得到一段没有标题的连续正文，还得自己重新整理。
import openai client = openai.OpenAI( base_url="http://localhost:8000/v1", # 本地部署服务地址 api_key="local-model-key" ) resp = client.chat.completions.create( model="qwen2.5-7b-instruct", messages=[ {"role": "system", "content": "你是一名系统架构师，回答要求精确、简洁、给出可执行命令。"}, {"role": "user", "content": "对比 Nginx 与 Envoy 在微服务网关场景下的性能差异，输出要点列表。"} ], temperature=0.3, # 低温度适合事实/工程类问答 max_tokens=1024, top_p=0.9 ) print(resp.choices[0].message.content)这里temperature参数对不同任务需要区分处理：写代码、查参数、生成配置等事实型任务建议 0.2 到 0.4，太高容易产生幻觉；头脑风暴、文案扩展等发散任务可以提到 0.8 以上。top_p与temperature不需要同时大幅调整，改一个即可。本地部署场景还要关注max_tokens，7B 或 13B 参数模型在生成超长内容时容易出现重复输出，限制长度比调提示词更直接。
5.2 输出可复现的验证方法
工作流真正跑通的标准不是「结果看起来对了」，而是「同样的输入，能稳定得到可接受的结果」。验证一批 Prompt 的质量，可以对同一任务连续执行三次，观察输出差异。对文档摘要任务，如果三次生成的要点走向完全不同，说明提示词约束不够，需要增加「只提取原文中出现过的数据和结论」这类限定。事实类任务改用更低的 temperature 再跑一轮，对比关键数字是否一致。
保存调试记录也是一个建议。每次对话的输入输出单独存档为一个 Markdown 文件，修改提示词后比较新旧版本。长期积累下来，你会逐步形成一个适合自己业务场景的提示词库——这比每次从头摸索效率高得多。遇到输出质量暴跌也不要着急换模型，先检查模型版本是否被更新，再用历史对话复现一次，定位是提示词变化还是模型行为漂移。把温度调到 0.3 以下再跑一遍，对比两次输出的差异出现在哪一步，问题出在检索召回、提示词约束，还是模型本身的生成策略，就一目了然了。
本文还有配套的精品资源，点击获取
