这次我们来看一个不太像“软件”的项目LLM Etiquette。它不是一个开箱即用的推理引擎也不是带界面的 AI 工具而是一套“和大模型协作时的行为规范”。简单说就是在本地部署、接口调用、知识库搭建、批量任务这些场景里怎么设计提示词、怎么管理上下文、怎么约束输出、怎么评估效果、怎么控制成本。核心一句话把大模型当成一个需要明确指令、需要反馈、需要预算管理的协作者而不是一个能猜中你心思的搜索引擎。这个主题最值得关注的内容有三块第一上下文预算管理也就是一套提示词结构怎么给模型留足发挥空间又不会被历史内容淹没第二输出纪律包括固定格式、JSON 输出、角色约束和失败重试第三工程化配套比如本地模型服务怎么启动、API 怎么调、批量任务怎么排队。文章里我会用一套可复制的模板和验证流程带你跑通“单轮问答—多轮对话—长文本处理—批量任务—接口调用”这条完整链路。如果你现在正在折腾本地大模型或者想把 LLM 能力接进自己的脚本、知识库、内容生产流程里这篇文章可以直接收藏。下面从核心能力开始拆。1. LLM Etiquette 核心能力速览能力项说明项目类型方法论 / 协作规范 / 工程实践指南核心内容上下文预算、提示词结构、角色约束、输出格式约束、评估闭环、成本控制配合工具Ollama、LM Studio、AnythingLLM、Obsidian LLM Wiki、Python 脚本等主要功能单轮问答、多轮对话、批量文本处理、知识库内容生成、结构化输出解析推荐硬件与本机推理服务一致显存占用需按实际模型版本测试支持平台通用本机部署以 Linux/Windows/macOS 均可移动端依赖第三方客户端启动方式由底层推理服务决定Ollama / LM Studio / API 网关等形式是否支持 API支持以本地推理服务或云 API 为入口是否支持批量任务支持通过脚本循环或任务队列实现需自行设计重试与日志适合场景本地部署测试、知识库问答、内容批量生成、Agent 工具调用、团队协作规范这里先说明一个前提LLM Etiquette 本身不需要安装它是一套给人用的规范。但这套规范必须落到实际工具上才有效果。所以本文的实操部分会围绕“Ollama 本地服务 Python 调用接口 模板化提示词 批量任务脚本”这套组合展开。如果你用的是其他推理引擎核心逻辑一样只需要替换启动命令和接口地址。2. 适用场景与使用边界从实际使用来看LLM Etiquette 适合这几类人本地部署玩家已经有本地模型但每次对话效果不稳定提示词改来改去没有方向需要一套系统的调试方法。想把 LLM 接进业务系统的人比如写邮件分类、Bug 报告摘要、文档打标、简历初筛都需要结构化输出。规范文本输入输出是保证系统稳定的前提。知识库搭建者比如 Obsidian LLM Wiki 的组合需要模型稳定地从个人笔记里抽取信息、生成摘要、维护双向链接。Agent 开发者模型需要按固定 JSON 格式输出工具调用参数一旦格式漂移整个 Agent 链路就会断。它不适合什么场景这里要泼一盆冷水如果你只是每天打开网页版聊天工具随便问几个问题LLM Etiquette 对你来说帮助不大。它不是“让回答更聪明的魔法”而是“让回答更可控的工程手段”。模型的能力上限由底座决定Etiquette 能保证的是同样的模型在同样的任务上输出更稳定、更符合预期、更容易被下游程序消费。另外要强调安全性。大模型可能生成有偏见或不合规的内容尤其在开放域对话里。任何接入了 LLM 的正式系统都应该在输入侧做内容过滤在输出侧做人工复核。涉及真实人物的声音、肖像、个人信息必须先获取授权。涉及版权材料不要直接拿来做批量改编和商用。本地模型也不是“法外之地”数据合规和隐私保护是使用边界的第一条。3. 本地部署环境准备与前置条件LLM Etiquette 落到实操层面你至少需要三样东西一个能跑模型的推理服务、一个能发起请求的客户端、一套存放提示词和评估结果的目录结构。3.1 硬件与系统大模型推理对硬件的要求取决于模型大小。7B/8B 级别模型可以在 8GB 显存的显卡上运行量化之后也有纯 CPU 推理的可行性但速度会明显下降。13B/14B 模型建议 12GB 以上显存更大的 30B 以上模型需要 24GB 显存或以上。这些都不是 LLM Etiquette 本身的要求而是你选择的底座模型的要求。更稳妥的判断是先用小模型跑通流程再根据显存占用和速度决定是否换大模型。系统方面没有硬性限制Windows、Linux、macOS 都能跑。区别主要在启动命令和驱动环境。Linux 下 CUDA 环境相对干净Windows 下需要注意显卡驱动和 Visual C 运行库。macOS 用户可以用 Metal 加速显存和内存共享实际占用需要以本机观察为准。3.2 软件与依赖清单组件作用说明Ollama 或 LM Studio本地模型推理服务两者二选一建议先试 OllamaPython 3.10调用接口、写批量脚本需要 requests、openai 等库Obsidian可选维护 LLM Wiki 知识库用来沉淀提示词模板和测试结果Postman 或 curl快速调试接口验证服务是否正常AnythingLLM可选可视化知识库问答前端如果不想纯命令行操作安装依赖时最容易踩的坑是版本冲突。建议用虚拟环境隔离# 创建虚拟环境 python -m venv llm-env # 激活环境Windows llm-env\Scripts\activate # 激活环境Linux/macOS source llm-env/bin/activate # 安装依赖 pip install requests openai3.3 目录结构长期使用规范建议一开始就分好目录llm-workspace/ ├── prompts/ # 提示词模板 ├── inputs/ # 输入文本、待处理文档 ├── outputs/ # 模型输出、批量结果 ├── logs/ # 请求日志、错误日志 └── evaluation/ # 评估记录、bad case 收集4. 提示词规范LLM Etiquette 的核心提示词不是写给模型看的“咒语”而是你和模型之间的接口约定。一套可复用的提示词至少要包含六个部分任务目标、输入数据、输出格式、约束条件、示例、判断标准。4.1 一个可复用的提示词模板[角色] 你是一个专业的文本处理助手擅长从用户提供的材料中提取信息并进行结构化整理。 [任务] 从下面的输入文本中提取客户反馈并输出 JSON 格式的摘要。 [输入文本] {{INPUT_TEXT}} [输出格式] { summary: 一句话摘要, issues: [问题1, 问题2], sentiment: positive|neutral|negative } [约束条件] 1. 只根据输入文本提取信息不要补充外部知识。 2. issues 最多列出 5 条。 3. 如果输入文本很短summary 也要保持完整语义。 [示例] 输入你们的产品安装太麻烦了界面也不直观。 输出{summary: 用户反馈安装繁琐且界面不直观, issues: [安装麻烦, 界面不直观], sentiment: negative} [判断标准] 输出必须是可以被 json.loads 直接解析的合法 JSON。这段模板的价值在于你把“该做什么、输入是什么、输出长什么样、不允许做什么、给个例子、怎么算成功”全部写清楚了。模型的自由发挥空间被压缩到可控范围。4.2 上下文预算管理LLM 的输入窗口是有限资源。7B 模型常见上下文是 4K/8K/32K大模型有 128K 甚至 200K但窗口越大推理成本越高历史内容对后续生成的影响也会越复杂。所以 Etiquette 的第一条纪律是不要把整个对话历史每次都塞进请求里。多轮对话场景下建议做三层管理系统提示词固定不变描述角色和全局规则。会话窗口只保留最近 N 轮对话更早的内容做摘要压缩。外部记忆超出窗口的长期事实通过检索或者摘要的方式按需注入。4.3 输出格式约束结构化输出是接业务系统的前提。除了在提示词里写清格式还需要在代码里做双重校验。模型偶尔会输出 json 标记或者多一个逗号所以解析时要做好异常处理。4.4 用 LLM Wiki 沉淀规范Andrej Karpathy 提过 “LLM Wiki” 的范式把与大模型协作的经验逐渐改写成一套可查询、可更新的知识库。你可以用 Obsidian 维护一个专门的笔记库里面放三类内容提示词模板、bad case 复盘、评估小记。每次提示词失效或效果波动都记录一页笔记。时间长了这套 Wiki 就是你个人的 LLM Etiquette 手册而不是散落在聊天记录里的临时经验。5. 本地模型服务启动与访问5.1 用 Ollama 启动服务以 Ollama 为例下载安装后先拉取模型# 拉取一个 7B 级别模型 ollama pull qwen2.5:7b # 启动服务会常驻后台默认端口 11434 ollama serve如果之前已经装过直接启动即可。启动后可以用 curl 验证服务是否可用curl http://127.0.0.1:11434/api/generate \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, prompt: 你好用一句话说明什么是 LLM Etiquette。, stream: false }能返回正常 JSON 就说明服务已经就绪。如果你用的是 LM Studio操作路径是加载模型 - 启动本地服务器 - 记录服务地址和端口。过程可以但端**口和模型名要按你自己的配置填。5.2 端口冲突与自适应默认端口可能被占用。如果你已经有程序占了 11434可以换端口启动OLLAMA_HOST127.0.0.1:11435 ollama serve客户端请求地址也要同步改成http://127.0.0.1:11435。更省事的办法是用环境变量统一配置。5.3 配合 AnythingLLM 做知识库前端如果你不想纯命令行操作可以本地部署一个 AnythingLLM 作为前端。它在设置里填 Ollama 的服务地址和模型名之后就能建立基于本地文档的工作区。本质上AnythingLLM 做的就是“把文档切块 - 向量化 - 检索后拼进提示词”这件事。而提示词模板的写法仍然是 LLM Etiquette 的范畴。6. 功能测试与效果验证部署成功后建议按下面的顺序跑一些受控测试而不是一上来就丢长文档。6.1 单轮问答测试测试目的确认服务连通、模型回复正常、输出速度可接受。输入你是一名测试助手。请只回答“OK”或“ERROR”不要输出其他内容。 现在请回答服务是否正常预期结果返回OK且延迟几秒内可见。判断标准回答不是“ERROR”说明基础链路通了。6.2 多轮对话与上下文窗口测试测试目的观察模型是否能记住前几轮的约束条件。输入序列第1轮请你记住一个密码 abc123后续我会让你输出这个密码。 第2轮请完整输出你刚才被要求记住的密码。 第3轮如果不记得请输出 NOT_FOUND。预期结果第 2 轮输出abc123第 3 轮视上下文保留情况而定。注意本地模型上下文窗口有限如果第 3 轮报错或遗忘不一定是模型笨可能是上下文窗口被截断了。排查时把对话历史打印出来看实际送入的 tokens 数。6.3 JSON 输出稳定性测试测试目的验证模型是否严格遵循输出格式。输入请将下面的句子分类为正面或负面情绪并输出 JSON {text: 这个功能非常好用} 输出格式{sentiment: positive 或 negative}预期结果返回合法 JSON。失败排查如果模型在前面加了“好的”或json标记不要慌张。在代码里做一次剥离处理再 json.loads。真正要评估的是连续 20 次请求里有多少次能一次解析成功。这个比率建议记录到评估表里。6.4 长文本处理测试测试目的评估模型在长输入上的表现和延迟。操作准备一段 2000 字左右的文档让模型做摘要。观察点是否截断。关键信息是否丢失。显存和内存占用变化。生成延迟是否明显上升。建议如果长文本效果差不要把文本一次性塞进提示词。先做分块摘要再做摘要合并。6.5 批量任务测试测试目的验证批量处理的稳定性和错误处理。示例脚本# 遍历 inputs 目录下的 txt 文件 for f in inputs/*.txt; do echo Processing $f python process_one.py --input $f if [ $? -ne 0 ]; then echo ERROR: $f fi done批量任务的核心不是“快”而是可断点续跑。输出文件名加上输入文件名作为前缀每处理完一个就写日志。7. 接口 API 调用与批量任务设计7.1 OpenAI 兼容接口调用Ollama 提供了 OpenAI 兼容接口。可以用标准openaiPython 库访问这是最方便的方式。from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, api_keyollama, # 本地服务通常不校验密钥但也别暴露到公网 ) response client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 你是一个严格的摘要助手。}, {role: user, content: 请用三句话总结这段话...} ], temperature0.3, ) print(response.choices[0].message.content)注意api_key填什么都行但本地服务不要随意暴露到公网。如果要远程访问至少加一层网关鉴权。7.2 批量任务队列设计批量任务最简单的结构是三层层级职责实现方式任务清单记录哪些文件/文本需要处理遍历目录或读取 csv处理循环逐个调用模型接口for 循环 / 队列结果汇总写输出文件与失败日志JSONL 逐行写入推荐把每次请求的记录写进 JSONL一行一次请求{file: input_001.txt, prompt_id: summary_v2, output: ..., error: null} {file: input_002.txt, prompt_id: summary_v2, output: ..., error: timeout}这样即使中途崩溃也能从日志里恢复。7.3 失败重试建议接口调用常见的失败包括连接超时、模型加载中、偶发解析错误。建议采用指数退避策略import time max_retries 3 retry_delay 2 for attempt in range(max_retries): try: result client.chat.completions.create(...) break except Exception as e: if attempt max_retries - 1: raise time.sleep(retry_delay * (2 ** attempt))8. 资源占用与性能观察这是本地部署最容易忽略的部分。大模型推理的服务端和 Web 应用不一样它的资源占用是动态的模型加载进显存时占用峰值很高生成过程中显存和计算资源都会被持续使用生成结束后显存可能会继续被模型占用只有卸载模型才会释放。所以观察显存要看两个时间点模型加载后、生成过程中。如果你想观察资源占用Linux 下用nvidia-smi -l 1每秒刷新一次Windows 下用任务管理器或者nvidia-smi都能看。重点看显存使用量是否在生成过程中持续增长。是否出现内存交换导致生成速度骤降。如果多个人同时请求显存占用会翻倍还是排队等待。降低显存占用的方法有几种换更小的量化版本模型、减小上下文长度、限制num_ctx、在 Ollama 中设置OLLAMA_NUM_PARALLEL1避免并发请求同时载入多个模型实例。生成速度慢的时候先看是不是stream参数导致的逐 token 返回再看是不是 CPU 推理。长文本和短文本的资源差异非常明显。同样一个 7B 模型短文本生成速度可能很快但长输入一进来prefill 阶段的计算量会显著上升首 token 延迟变高。所以批量任务里一定要按输入长度做预估不要盲目调高并发。9. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后页面或接口打不开端口被占用或服务未启动检查日志、curl 访问端口换端口或重启服务依赖安装失败Python 版本冲突或网络问题查看 pip 错误信息用虚拟环境重装或指定镜像源模型文件缺失拉取中断或路径不对查看服务端日志重新执行 pull 命令CUDA/显卡驱动问题驱动版本过旧或 PyTorch 版本不匹配运行python -c import torch; print(torch.cuda.is_available())更新驱动或安装匹配版本显存不足模型过大或并发过高观察 nvidia-smi换小模型、量化、降低并发API 调用失败地址/模型名写错打印请求 URL 和返回体核对服务端模型列表批量任务卡住单次请求超时或进程假死添加请求超时时间与重试机制设置 timeout 并加入失败重试输出质量不稳定提示词模糊或温度参数偏高固定测试集对比降低 temperature完善提示词模板长文本被截断上下文窗口不足查看 tokens 统计分块处理或扩展上下文窗口排查的第一原则是看日志。本地推理服务的日志会告诉你模型是否加载成功、是否收到请求、是否在处理中。不要凭感觉猜先看日志再定位。10. 最佳实践与使用建议最后给一套可以直接上手的最佳实践。第一次尝试时先用小参数、小模型、小样本跑通全流程保留一套最小可运行配置方便以后快速复现模型文件、输入素材、输出结果分目录管理避免把一组实验的文件混在一起。批量任务务必加日志和失败重试接口服务务必限制访问范围。第二点是提示词管理。所有提示词都要版本化改提示词就等于改代码要用 Git 管理。每个提示词版本和当时的测试结果对应保存这样模型升级后效果变差也能定位是哪次改动造成的。第三点是评估闭环。不要凭感觉判断“这次好多了”要固定一组测试样本每次改动后跑同一组样本比较结构化输出的解析成功率、关键信息覆盖率、失败类型分布。评估样本数量不需要特别大20 到 30 条就足够发现明显问题。第四点是合规和授权。如果你处理的是真实用户数据、个人隐私或者受版权保护的材料先确认你的法律边界。模型生成的结果不等于“无主内容”发布或商用之前要做效果复核尤其涉及肖像、声音、品牌信息时必须确认授权链完整。LLM Etiquette 说到底不是某个模型的能力而是你愿不愿意花时间去定义“什么是好的协作方式”。最值得尝试的习惯是从今天开始每次写提示词都加上角色、任务、输入、输出格式、约束、示例和判断标准这七个部分同时把失败的案例记进你的 LLM Wiki。先跑通本地服务再完善模板最后接上批量任务和 API。这套规范一旦建立换模型、换框架都不需要推倒重来。 LLM Etiquette：大模型协作规范与本地部署实践指南
这次我们来看一个不太像“软件”的项目LLM Etiquette。它不是一个开箱即用的推理引擎也不是带界面的 AI 工具而是一套“和大模型协作时的行为规范”。简单说就是在本地部署、接口调用、知识库搭建、批量任务这些场景里怎么设计提示词、怎么管理上下文、怎么约束输出、怎么评估效果、怎么控制成本。核心一句话把大模型当成一个需要明确指令、需要反馈、需要预算管理的协作者而不是一个能猜中你心思的搜索引擎。这个主题最值得关注的内容有三块第一上下文预算管理也就是一套提示词结构怎么给模型留足发挥空间又不会被历史内容淹没第二输出纪律包括固定格式、JSON 输出、角色约束和失败重试第三工程化配套比如本地模型服务怎么启动、API 怎么调、批量任务怎么排队。文章里我会用一套可复制的模板和验证流程带你跑通“单轮问答—多轮对话—长文本处理—批量任务—接口调用”这条完整链路。如果你现在正在折腾本地大模型或者想把 LLM 能力接进自己的脚本、知识库、内容生产流程里这篇文章可以直接收藏。下面从核心能力开始拆。1. LLM Etiquette 核心能力速览能力项说明项目类型方法论 / 协作规范 / 工程实践指南核心内容上下文预算、提示词结构、角色约束、输出格式约束、评估闭环、成本控制配合工具Ollama、LM Studio、AnythingLLM、Obsidian LLM Wiki、Python 脚本等主要功能单轮问答、多轮对话、批量文本处理、知识库内容生成、结构化输出解析推荐硬件与本机推理服务一致显存占用需按实际模型版本测试支持平台通用本机部署以 Linux/Windows/macOS 均可移动端依赖第三方客户端启动方式由底层推理服务决定Ollama / LM Studio / API 网关等形式是否支持 API支持以本地推理服务或云 API 为入口是否支持批量任务支持通过脚本循环或任务队列实现需自行设计重试与日志适合场景本地部署测试、知识库问答、内容批量生成、Agent 工具调用、团队协作规范这里先说明一个前提LLM Etiquette 本身不需要安装它是一套给人用的规范。但这套规范必须落到实际工具上才有效果。所以本文的实操部分会围绕“Ollama 本地服务 Python 调用接口 模板化提示词 批量任务脚本”这套组合展开。如果你用的是其他推理引擎核心逻辑一样只需要替换启动命令和接口地址。2. 适用场景与使用边界从实际使用来看LLM Etiquette 适合这几类人本地部署玩家已经有本地模型但每次对话效果不稳定提示词改来改去没有方向需要一套系统的调试方法。想把 LLM 接进业务系统的人比如写邮件分类、Bug 报告摘要、文档打标、简历初筛都需要结构化输出。规范文本输入输出是保证系统稳定的前提。知识库搭建者比如 Obsidian LLM Wiki 的组合需要模型稳定地从个人笔记里抽取信息、生成摘要、维护双向链接。Agent 开发者模型需要按固定 JSON 格式输出工具调用参数一旦格式漂移整个 Agent 链路就会断。它不适合什么场景这里要泼一盆冷水如果你只是每天打开网页版聊天工具随便问几个问题LLM Etiquette 对你来说帮助不大。它不是“让回答更聪明的魔法”而是“让回答更可控的工程手段”。模型的能力上限由底座决定Etiquette 能保证的是同样的模型在同样的任务上输出更稳定、更符合预期、更容易被下游程序消费。另外要强调安全性。大模型可能生成有偏见或不合规的内容尤其在开放域对话里。任何接入了 LLM 的正式系统都应该在输入侧做内容过滤在输出侧做人工复核。涉及真实人物的声音、肖像、个人信息必须先获取授权。涉及版权材料不要直接拿来做批量改编和商用。本地模型也不是“法外之地”数据合规和隐私保护是使用边界的第一条。3. 本地部署环境准备与前置条件LLM Etiquette 落到实操层面你至少需要三样东西一个能跑模型的推理服务、一个能发起请求的客户端、一套存放提示词和评估结果的目录结构。3.1 硬件与系统大模型推理对硬件的要求取决于模型大小。7B/8B 级别模型可以在 8GB 显存的显卡上运行量化之后也有纯 CPU 推理的可行性但速度会明显下降。13B/14B 模型建议 12GB 以上显存更大的 30B 以上模型需要 24GB 显存或以上。这些都不是 LLM Etiquette 本身的要求而是你选择的底座模型的要求。更稳妥的判断是先用小模型跑通流程再根据显存占用和速度决定是否换大模型。系统方面没有硬性限制Windows、Linux、macOS 都能跑。区别主要在启动命令和驱动环境。Linux 下 CUDA 环境相对干净Windows 下需要注意显卡驱动和 Visual C 运行库。macOS 用户可以用 Metal 加速显存和内存共享实际占用需要以本机观察为准。3.2 软件与依赖清单组件作用说明Ollama 或 LM Studio本地模型推理服务两者二选一建议先试 OllamaPython 3.10调用接口、写批量脚本需要 requests、openai 等库Obsidian可选维护 LLM Wiki 知识库用来沉淀提示词模板和测试结果Postman 或 curl快速调试接口验证服务是否正常AnythingLLM可选可视化知识库问答前端如果不想纯命令行操作安装依赖时最容易踩的坑是版本冲突。建议用虚拟环境隔离# 创建虚拟环境 python -m venv llm-env # 激活环境Windows llm-env\Scripts\activate # 激活环境Linux/macOS source llm-env/bin/activate # 安装依赖 pip install requests openai3.3 目录结构长期使用规范建议一开始就分好目录llm-workspace/ ├── prompts/ # 提示词模板 ├── inputs/ # 输入文本、待处理文档 ├── outputs/ # 模型输出、批量结果 ├── logs/ # 请求日志、错误日志 └── evaluation/ # 评估记录、bad case 收集4. 提示词规范LLM Etiquette 的核心提示词不是写给模型看的“咒语”而是你和模型之间的接口约定。一套可复用的提示词至少要包含六个部分任务目标、输入数据、输出格式、约束条件、示例、判断标准。4.1 一个可复用的提示词模板[角色] 你是一个专业的文本处理助手擅长从用户提供的材料中提取信息并进行结构化整理。 [任务] 从下面的输入文本中提取客户反馈并输出 JSON 格式的摘要。 [输入文本] {{INPUT_TEXT}} [输出格式] { summary: 一句话摘要, issues: [问题1, 问题2], sentiment: positive|neutral|negative } [约束条件] 1. 只根据输入文本提取信息不要补充外部知识。 2. issues 最多列出 5 条。 3. 如果输入文本很短summary 也要保持完整语义。 [示例] 输入你们的产品安装太麻烦了界面也不直观。 输出{summary: 用户反馈安装繁琐且界面不直观, issues: [安装麻烦, 界面不直观], sentiment: negative} [判断标准] 输出必须是可以被 json.loads 直接解析的合法 JSON。这段模板的价值在于你把“该做什么、输入是什么、输出长什么样、不允许做什么、给个例子、怎么算成功”全部写清楚了。模型的自由发挥空间被压缩到可控范围。4.2 上下文预算管理LLM 的输入窗口是有限资源。7B 模型常见上下文是 4K/8K/32K大模型有 128K 甚至 200K但窗口越大推理成本越高历史内容对后续生成的影响也会越复杂。所以 Etiquette 的第一条纪律是不要把整个对话历史每次都塞进请求里。多轮对话场景下建议做三层管理系统提示词固定不变描述角色和全局规则。会话窗口只保留最近 N 轮对话更早的内容做摘要压缩。外部记忆超出窗口的长期事实通过检索或者摘要的方式按需注入。4.3 输出格式约束结构化输出是接业务系统的前提。除了在提示词里写清格式还需要在代码里做双重校验。模型偶尔会输出 json 标记或者多一个逗号所以解析时要做好异常处理。4.4 用 LLM Wiki 沉淀规范Andrej Karpathy 提过 “LLM Wiki” 的范式把与大模型协作的经验逐渐改写成一套可查询、可更新的知识库。你可以用 Obsidian 维护一个专门的笔记库里面放三类内容提示词模板、bad case 复盘、评估小记。每次提示词失效或效果波动都记录一页笔记。时间长了这套 Wiki 就是你个人的 LLM Etiquette 手册而不是散落在聊天记录里的临时经验。5. 本地模型服务启动与访问5.1 用 Ollama 启动服务以 Ollama 为例下载安装后先拉取模型# 拉取一个 7B 级别模型 ollama pull qwen2.5:7b # 启动服务会常驻后台默认端口 11434 ollama serve如果之前已经装过直接启动即可。启动后可以用 curl 验证服务是否可用curl http://127.0.0.1:11434/api/generate \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, prompt: 你好用一句话说明什么是 LLM Etiquette。, stream: false }能返回正常 JSON 就说明服务已经就绪。如果你用的是 LM Studio操作路径是加载模型 - 启动本地服务器 - 记录服务地址和端口。过程可以但端**口和模型名要按你自己的配置填。5.2 端口冲突与自适应默认端口可能被占用。如果你已经有程序占了 11434可以换端口启动OLLAMA_HOST127.0.0.1:11435 ollama serve客户端请求地址也要同步改成http://127.0.0.1:11435。更省事的办法是用环境变量统一配置。5.3 配合 AnythingLLM 做知识库前端如果你不想纯命令行操作可以本地部署一个 AnythingLLM 作为前端。它在设置里填 Ollama 的服务地址和模型名之后就能建立基于本地文档的工作区。本质上AnythingLLM 做的就是“把文档切块 - 向量化 - 检索后拼进提示词”这件事。而提示词模板的写法仍然是 LLM Etiquette 的范畴。6. 功能测试与效果验证部署成功后建议按下面的顺序跑一些受控测试而不是一上来就丢长文档。6.1 单轮问答测试测试目的确认服务连通、模型回复正常、输出速度可接受。输入你是一名测试助手。请只回答“OK”或“ERROR”不要输出其他内容。 现在请回答服务是否正常预期结果返回OK且延迟几秒内可见。判断标准回答不是“ERROR”说明基础链路通了。6.2 多轮对话与上下文窗口测试测试目的观察模型是否能记住前几轮的约束条件。输入序列第1轮请你记住一个密码 abc123后续我会让你输出这个密码。 第2轮请完整输出你刚才被要求记住的密码。 第3轮如果不记得请输出 NOT_FOUND。预期结果第 2 轮输出abc123第 3 轮视上下文保留情况而定。注意本地模型上下文窗口有限如果第 3 轮报错或遗忘不一定是模型笨可能是上下文窗口被截断了。排查时把对话历史打印出来看实际送入的 tokens 数。6.3 JSON 输出稳定性测试测试目的验证模型是否严格遵循输出格式。输入请将下面的句子分类为正面或负面情绪并输出 JSON {text: 这个功能非常好用} 输出格式{sentiment: positive 或 negative}预期结果返回合法 JSON。失败排查如果模型在前面加了“好的”或json标记不要慌张。在代码里做一次剥离处理再 json.loads。真正要评估的是连续 20 次请求里有多少次能一次解析成功。这个比率建议记录到评估表里。6.4 长文本处理测试测试目的评估模型在长输入上的表现和延迟。操作准备一段 2000 字左右的文档让模型做摘要。观察点是否截断。关键信息是否丢失。显存和内存占用变化。生成延迟是否明显上升。建议如果长文本效果差不要把文本一次性塞进提示词。先做分块摘要再做摘要合并。6.5 批量任务测试测试目的验证批量处理的稳定性和错误处理。示例脚本# 遍历 inputs 目录下的 txt 文件 for f in inputs/*.txt; do echo Processing $f python process_one.py --input $f if [ $? -ne 0 ]; then echo ERROR: $f fi done批量任务的核心不是“快”而是可断点续跑。输出文件名加上输入文件名作为前缀每处理完一个就写日志。7. 接口 API 调用与批量任务设计7.1 OpenAI 兼容接口调用Ollama 提供了 OpenAI 兼容接口。可以用标准openaiPython 库访问这是最方便的方式。from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:11434/v1, api_keyollama, # 本地服务通常不校验密钥但也别暴露到公网 ) response client.chat.completions.create( modelqwen2.5:7b, messages[ {role: system, content: 你是一个严格的摘要助手。}, {role: user, content: 请用三句话总结这段话...} ], temperature0.3, ) print(response.choices[0].message.content)注意api_key填什么都行但本地服务不要随意暴露到公网。如果要远程访问至少加一层网关鉴权。7.2 批量任务队列设计批量任务最简单的结构是三层层级职责实现方式任务清单记录哪些文件/文本需要处理遍历目录或读取 csv处理循环逐个调用模型接口for 循环 / 队列结果汇总写输出文件与失败日志JSONL 逐行写入推荐把每次请求的记录写进 JSONL一行一次请求{file: input_001.txt, prompt_id: summary_v2, output: ..., error: null} {file: input_002.txt, prompt_id: summary_v2, output: ..., error: timeout}这样即使中途崩溃也能从日志里恢复。7.3 失败重试建议接口调用常见的失败包括连接超时、模型加载中、偶发解析错误。建议采用指数退避策略import time max_retries 3 retry_delay 2 for attempt in range(max_retries): try: result client.chat.completions.create(...) break except Exception as e: if attempt max_retries - 1: raise time.sleep(retry_delay * (2 ** attempt))8. 资源占用与性能观察这是本地部署最容易忽略的部分。大模型推理的服务端和 Web 应用不一样它的资源占用是动态的模型加载进显存时占用峰值很高生成过程中显存和计算资源都会被持续使用生成结束后显存可能会继续被模型占用只有卸载模型才会释放。所以观察显存要看两个时间点模型加载后、生成过程中。如果你想观察资源占用Linux 下用nvidia-smi -l 1每秒刷新一次Windows 下用任务管理器或者nvidia-smi都能看。重点看显存使用量是否在生成过程中持续增长。是否出现内存交换导致生成速度骤降。如果多个人同时请求显存占用会翻倍还是排队等待。降低显存占用的方法有几种换更小的量化版本模型、减小上下文长度、限制num_ctx、在 Ollama 中设置OLLAMA_NUM_PARALLEL1避免并发请求同时载入多个模型实例。生成速度慢的时候先看是不是stream参数导致的逐 token 返回再看是不是 CPU 推理。长文本和短文本的资源差异非常明显。同样一个 7B 模型短文本生成速度可能很快但长输入一进来prefill 阶段的计算量会显著上升首 token 延迟变高。所以批量任务里一定要按输入长度做预估不要盲目调高并发。9. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后页面或接口打不开端口被占用或服务未启动检查日志、curl 访问端口换端口或重启服务依赖安装失败Python 版本冲突或网络问题查看 pip 错误信息用虚拟环境重装或指定镜像源模型文件缺失拉取中断或路径不对查看服务端日志重新执行 pull 命令CUDA/显卡驱动问题驱动版本过旧或 PyTorch 版本不匹配运行python -c import torch; print(torch.cuda.is_available())更新驱动或安装匹配版本显存不足模型过大或并发过高观察 nvidia-smi换小模型、量化、降低并发API 调用失败地址/模型名写错打印请求 URL 和返回体核对服务端模型列表批量任务卡住单次请求超时或进程假死添加请求超时时间与重试机制设置 timeout 并加入失败重试输出质量不稳定提示词模糊或温度参数偏高固定测试集对比降低 temperature完善提示词模板长文本被截断上下文窗口不足查看 tokens 统计分块处理或扩展上下文窗口排查的第一原则是看日志。本地推理服务的日志会告诉你模型是否加载成功、是否收到请求、是否在处理中。不要凭感觉猜先看日志再定位。10. 最佳实践与使用建议最后给一套可以直接上手的最佳实践。第一次尝试时先用小参数、小模型、小样本跑通全流程保留一套最小可运行配置方便以后快速复现模型文件、输入素材、输出结果分目录管理避免把一组实验的文件混在一起。批量任务务必加日志和失败重试接口服务务必限制访问范围。第二点是提示词管理。所有提示词都要版本化改提示词就等于改代码要用 Git 管理。每个提示词版本和当时的测试结果对应保存这样模型升级后效果变差也能定位是哪次改动造成的。第三点是评估闭环。不要凭感觉判断“这次好多了”要固定一组测试样本每次改动后跑同一组样本比较结构化输出的解析成功率、关键信息覆盖率、失败类型分布。评估样本数量不需要特别大20 到 30 条就足够发现明显问题。第四点是合规和授权。如果你处理的是真实用户数据、个人隐私或者受版权保护的材料先确认你的法律边界。模型生成的结果不等于“无主内容”发布或商用之前要做效果复核尤其涉及肖像、声音、品牌信息时必须确认授权链完整。LLM Etiquette 说到底不是某个模型的能力而是你愿不愿意花时间去定义“什么是好的协作方式”。最值得尝试的习惯是从今天开始每次写提示词都加上角色、任务、输入、输出格式、约束、示例和判断标准这七个部分同时把失败的案例记进你的 LLM Wiki。先跑通本地服务再完善模板最后接上批量任务和 API。这套规范一旦建立换模型、换框架都不需要推倒重来。