我刚开始接触大模型的时候，以为它是个万能问答机器。问它什么都能答，写代码、写文案、翻译、做表格，样样都行。用了几个月发现，它的能力边界挺清晰。它擅长语言理解和生成，适合处理有文本规律的任务。实时信息、精确计算、专业决策，这些它容易翻车。我把它当成一个反应快、知识面广的实习生，而不是权威专家。这个定位帮我省了很多纠结。
1.1 大模型使用入门：能力边界、适用场景与工具选择
我写这篇大模型使用教程，想先从基础认知讲起。我平时用得最多的场景是写作辅助和资料整理。写公众号草稿、改邮件、总结会议纪要，大模型能省一半时间。做竞品分析时，我把十几页报告丢给它，让它提取关键观点。它做得不错，偶尔会漏掉细节。我朋友做电商客服，用大模型生成回复话术，再人工润色。他告诉我，回复速度上去了，客户满意度没降。适用场景可以按“文本密度高、容错率中等、不需要实时数据”来判断。
工具选择要看具体需求。日常聊天和写作，网页端够用。需要处理超长文档，选支持长上下文的模型。写代码多，可以试试代码专用模型。我手机里装了三个客户端，分别对应不同账号和模型。有人问我哪个最好，我通常反问：你主要拿它干什么。没有全能冠军，只有适合当前任务的工具。
1.2 第一次使用大模型：网页端、API 与客户端调用流程
网页端是最容易上手的入口。打开官网，注册账号，找到输入框，打字就行。我第一次用的时候，连提示词都不懂，直接问“帮我写个年终总结”。它给了一篇很套路的模板。后来我学会补充信息，比如岗位、业绩、语气，结果就好很多。网页端适合试水，也适合日常轻量使用。
API 调用听起来技术门槛高，其实流程不复杂。去平台申请密钥，选一个模型名称，用官方提供的示例代码发请求。我踩过的坑有两个：接口地址填错，模型名写成了网页端显示的名字。调试半小时才发现问题。API 适合批量处理、接入自己的工具。费用按量计算，用之前最好设个预算提醒。
客户端调用是折中方案。像 Chatbox、NextChat、Cherry Studio 这类工具，填入 API 地址和密钥就能用。界面比网页端灵活，可以切换多个模型。我给非技术朋友推荐这种方式，他们不用写代码，也能享受 API 的稳定性。第一次配置时，注意区分“模型名称”和“显示名称”，这两个地方容易填混。
1.3 大模型提示词使用教程：角色、任务、上下文与输出格式
提示词不是玄学，我把它拆成四块：角色、任务、上下文、输出格式。角色告诉模型“你是谁”，任务说清“做什么”，上下文补充“背景信息”，输出格式规定“怎么交作业”。我写周报时，会这样开头：你是一位资深运营经理，帮我写一份周报。本周完成了三场活动，数据分别是……输出用表格，分目标、结果、问题三列。模型给出的内容直接能贴进文档。
很多人只写任务，比如“写一份产品介绍”。模型不知道产品是什么、卖给谁、语气要正式还是活泼。我通常会加一句：面向25到35岁的职场女性，语气轻松，避免专业术语。这样出来的文案更贴近需求。输出格式也很关键。要表格就明确说“用Markdown表格”，要JSON就写“返回JSON，字段包括title、summary、tags”。模型对格式指令的服从度挺高。
上下文给多少合适？我的经验是，关键信息不能少，无关信息不要塞。做合同摘要时，我会把合同全文放进去，再要求“只提取付款条款和违约责任”。做创意写作时，上下文可以少一些，给个方向就行。提示词写得好，模型就像听懂话的助手。写得模糊，它只能靠猜。猜对了是运气，猜错了是常态。
1.4 提示词进阶技巧：少样本示例、分步推理、结构化输出与迭代优化
少样本示例是我最常用的技巧。想让模型模仿某种风格，直接给两三个例子。我让模型写小红书标题时，会先贴三条爆款标题，再让它按同样句式生成五条。它出来的结果明显更对味。示例不需要多，两三条就能让模型抓住规律。例子质量差，输出也会跑偏。
分步推理适合复杂任务。我处理数据清洗时，会要求模型“先列出字段含义，再检查缺失值，收尾给出清洗建议”。它按步骤输出，我更容易发现逻辑漏洞。结构化输出能直接对接程序。我让模型把会议纪要转成JSON，包含参会人、议题、结论、待办。解析起来很方便。迭代优化是常态。第一版不满意，我会指出具体问题，比如“第三点太笼统，补充数据支撑”。改两三轮，结果就能用。
有人担心分步推理会让模型啰嗦。我的做法是限定步骤数量，比如“用三步分析，每步不超过两句话”。结构化输出也要给 schema，不然字段名可能每次都不一样。迭代时别只说“不好”，要告诉它哪里不好、希望改成什么样。模型没有读心术，但很会跟着反馈调整。
1.5 常见问题处理：幻觉、上下文超限、隐私安全与结果校验
幻觉是大模型最让人头疼的问题。它会把不存在的事实说得像真的一样。我让它推荐论文，它编过作者和期刊名。后来我养成习惯：涉及事实的内容，要求它提供来源链接。它给不出链接，我就自己搜。不确定的地方，我会追问“你确定吗？不确定就说不知道”。这样能减少一部分胡编。
上下文超限发生在文档太长的时候。模型会忘记前面的内容，或者直接截断。我的处理方式是分段处理，每段总结成要点，再把要点合并。做长报告时，我先让模型逐章摘要，再让它基于摘要写总览。这样比硬塞全文更靠谱。隐私安全方面，我会把客户姓名、电话、地址脱敏后再输入。敏感项目用本地部署模型，数据不出内网。
结果校验不能省。我从来不直接把模型输出发给客户。数字、日期、人名、法律条款，这些必须人工核对。我同事做过实验，让模型计算发票金额，十次里错两次。它的数学能力不稳定。校验花的时间，比返工少得多。把大模型当副驾驶，方向盘还是握在自己手里。
上一章聊了网页端、API 和提示词。这一章我讲本地部署。我动了本地部署的念头，来自处理客户合同的需求。数据不能出内网，云端模型再好用也得放弃。本地部署听起来门槛高，实际跑通一个 7B 模型，一个下午就够。
2.1 本地部署大模型教程：硬件评估、模型选择、量化与运行环境准备
我评估硬件先看显存。N 卡 8G 能跑 7B 量化模型，12G 跑 14B，24G 跑 32B。Mac 的统一内存也香，M2 16G 能跑 7B Q4。内存至少 16G，推荐 32G。硬盘留 100G 放模型。我朋友用旧游戏本，GTX 1060 6G，跑 3B 模型都喘。显存带宽比核心数量更影响速度。
模型选择看任务和语言。中文场景 Qwen、DeepSeek、GLM 都不错。英文 Llama、Mistral。代码用 DeepSeek Coder、CodeLlama。量化是省显存的关键。GGUF 适合 CPU 加 GPU 混合，Q4_K_M 平衡好。GPTQ、AWQ 适合 N 卡，速度快。我试过 Q8 和 Q4，Q4 在写作任务上差别不大，数学题差一些。
运行环境准备。Windows 装 CUDA 驱动，Python 3.10，创建虚拟环境。Linux 更顺，Docker 拉镜像。我踩过驱动版本不匹配的坑，折腾一晚上。现在习惯用 conda 管理环境，模型文件放单独盘。准备一个干净的目录，后面切换模型方便。
2.2 主流本地部署方案：Ollama、LM Studio、llama.cpp 与 vLLM 实践
Ollama 是我最推荐的入门工具。命令行一句 ollama run qwen2.5 就能跑。它自动下载量化模型，管理模型列表。我把它装在家里的迷你主机上，当内网 API 用。API 地址是 localhost:11434，兼容 OpenAI 格式。朋友不会命令行，我让他用 Ollama 加 Open WebUI，界面和 ChatGPT 差不多。
LM Studio 适合喜欢图形界面的人。下载模型、调参数、开服务，点鼠标就行。我拿它给同事演示本地模型，他们十分钟上手。llama.cpp 更底层，适合折腾量化、编译。我编译过一次，开启 CUDA 加速，速度比 CPU 快三倍。vLLM 适合服务器并发，PagedAttention 省显存。我帮一个小团队部署 vLLM，同时服务 20 个请求，延迟稳定。
四个方案各有位置。个人玩 Ollama 加 LM Studio。要嵌入自己程序，llama.cpp 的 Python 绑定好用。企业级 API，vLLM 是首选。我现在的组合：Ollama 做日常，vLLM 做批量任务。别纠结哪个最好，先跑起来一个，后面按需求换。
2.3 本地模型与提示词工程：RAG、函数调用、智能体与工作流编排
本地模型加 RAG，能把私有资料变成问答库。我用 LangChain 加 Chroma 做向量库，把产品手册切块、嵌入、存储。提问时先检索相关段落，再拼进提示词。模型回答有依据，幻觉少很多。嵌入模型用 bge-m3，中文效果好。切块大小 500 字，重叠 50 字，这个参数我调了三次。
函数调用让模型能操作外部工具。我定义天气查询、数据库查询、发邮件三个函数。模型根据用户问题选择调用哪个。本地模型对函数调用支持参差不齐，Qwen 和 Mistral 较好。智能体是函数调用的进阶，给模型一个目标，它自己规划步骤。我做过一个自动整理文件的智能体，它先扫描目录，再按类型分类，写日志。偶尔会乱建文件夹，我加了人工确认。
工作流编排把多个步骤串起来。我用 Dify 和 n8n 搭过写作工作流：输入主题，模型生成大纲，再逐段扩写，自动配图，发到草稿箱。本地模型跑在 Ollama 上，Dify 负责调度。整个流程跑通花了周末两天。编排的核心是错误处理，某一步失败要有回退。我设置了重试和通知，省心不少。
2.4 性能与成本优化：推理速度、显存占用、并发、上下文长度与缓存
推理速度取决于模型大小、量化等级、硬件。7B Q4 在 RTX 3060 上大概 40 token/s。14B Q4 降到 20 token/s。我追求速度时用 Q4_K_S，追求质量用 Q5_K_M。显存占用公式：参数量 × 量化位数 / 8 + 上下文缓存。8B Q4 约 5GB，加上 4K 上下文，再多 1GB。显存不够会溢出到内存，速度断崖下跌。
并发是多人使用的门槛。Ollama 默认单并发，vLLM 能批处理。我测试 vLLM 在 24G 卡上跑 7B，并发 10 个请求，总吞吐是单请求的六倍。上下文长度越长，KV 缓存越大。我把默认上下文从 8K 调到 4K，显存省了 2GB。缓存方面，Ollama 有提示词缓存，重复前缀能加速。vLLM 有前缀缓存，多轮对话更明显。
成本不只是电费。时间成本、维护成本都要算。我在家用旧显卡跑，电费一个月多几十块。公司用云 GPU 按小时计费，跑批量任务更划算。优化顺序：先量化，再调上下文，再上并发框架。别一上来就买顶配显卡，先用手头设备跑通流程。我见过有人为了跑 70B 模型花两万，结果需求只是写周报。
2.5 综合实战项目：私有知识库问答、写作助手与自动化任务助手
私有知识库问答是我最满意的项目。我把公司内部文档、会议纪要、产品规格放进 RAG 系统。同事问“退款流程是什么”，它先检索制度文档，再生成回答，附上来源。准确率比通用模型高很多。部署在办公室一台旧工作站上，数据不出内网。维护也简单，新文档丢进文件夹，跑一次嵌入脚本就行。
写作助手结合本地模型和提示词模板。我预设了公众号、小红书、邮件三种模板。输入关键词，选择模板，模型生成初稿。我再用另一个模型做润色和事实检查。整个流程在本地跑，速度够用。我朋友做外贸，用它写英文开发信，改改就能发。写作助手的核心是模板质量，我迭代了十几版提示词。
自动化任务助手帮我处理重复工作。每天早上下载报表、提取数据、生成摘要、发到钉钉。我用 Python 脚本加本地模型，模型负责理解非结构化内容。遇到异常发邮件通知我。这套东西跑了半年，每周省出三四个小时。自动化任务助手的边界要清晰，涉及付款、删除、对外发送的操作，必须人工确认。本地部署给了数据安全感，也给了我折腾的乐趣。
