“LLM Etiquette”这个词第一眼看上去容易误解成“大模型聊天要有礼貌”但实际做项目的人知道它说的是另一件事你与 LLM 协作时那一整套约定和规范。包括怎么问问题、怎么组织上下文、怎么控制精度和采样参数、怎么设计 Agent 的工具调用以及把本地知识库接进来时应该先处理哪些材料。这套规范定义得越清楚模型的输出就越稳定项目从 Demo 走向批量和生产就越顺利。这篇文章适合正在调 API、做 Agent、接知识库、跑本地模型的开发者。也会聊到 FP16、BF16、微调、编排框架、AnythingLLM、Obsidian LLM Wiki 这些关键词但不会只堆概念。我会按实际落地的顺序把 LLM 使用中容易被忽略的边界和坑点拆开讲。1. 先把“LLM Etiquette”理解为模型协作协议而不是聊天礼仪聊天礼貌是人和人之间的事。LLM Etiquette 要做的是另一件事在“人—模型—代码—数据”这条链路上给每一步定清楚规则。很多项目跑不稳并不是模型本身不行而是使用模型的人没有约定好输入边界、输出格式、失败策略和上下文管理方式。1.1 最常见的一类问题什么都想问但什么都不约束我见过不少这样的调用场景把一大段资料直接塞进对话然后问“帮我总结一下”。模型确实会回答但结果可能重点偏掉也可能把原文里的错误信息一并保留。这不是模型能力问题而是交互方式太随意了。LLM 本质上是概率生成你不给它明确的约束它就会按自己统计到的“最常见回答方式”来生成。如果希望输出稳定就要在提示词里尽量说明你让模型扮演什么角色它要处理什么输入输出应该遵循什么格式哪些内容不能编造信息不足时应该怎么回答。这些要求不复杂但能明显提升首轮回包质量减少后续反复纠正的轮次。1.2 代码调用里的“礼仪”更严格对普通聊天来说回答偏一点还能接受。但如果你在用代码调用 LLM 接口纪律就要严格得多。比如系统提示词里允许什么、禁止什么用户输入要不要先做格式校验模型输出要不要做 JSON 或结构化校验超时、重试、失败降级怎么设计上下文会不会无限增长同一任务重试时模型是否可能产出不同结果。这些都属于 LLM Etiquette 的工程层面。很多人踩坑是因为只把它当聊天工具用没意识到你正在构建的是一个包含“人—模型—程序”的协作系统。1.3 项目越复杂越需要分层管理我一般会把 LLM 项目的礼仪分成三层排查时按层定位交互层的礼仪提示词结构、上下文管理、模型行为边界。工程层的礼仪精度选择、采样参数、输出校验、重试与日志。数据层的礼仪知识库整理、检索结果筛选、微调数据质量。如果你的项目只是个人问答第一层就够用了。如果做 Agent、批处理、知识库问答就必须把三层都梳理清楚。2. 提示词和上下文层面的礼仪先给边界再要结果提示词是 LLM Etiquette 里最基础也最容易被轻视的部分。很多人以为提示词越长越好其实关键是结构清晰让模型知道哪些能做、哪些不能做、输出长什么样。2.1 先把边界写清楚再让模型发挥我常用的提示词结构并不花哨一般包含四段角色定义你是一个负责代码审查的助手。任务描述请审查以下代码指出潜在问题。输出格式使用列表每条包含严重程度、位置、说明、修复建议。负面约束如果代码没有明显问题请直接说明“未发现明显问题”不要为了凑答案强行输出风险。负面约束特别有用。没有它模型很容易输出一堆“可能存在问题建议进一步检查”的废话。加了之后输出会收敛很多。2.2 上下文不是越长越好窗口不等于记忆上下文窗口是 LLM 项目里最常见的资源瓶颈之一。窗口越大能装的文字越多但不代表效果越好。很多新手以为“把整个文档都塞进上下文模型就能记住”实际结果通常是关键信息被长文本稀释模型抓不住重点调用成本变高单次请求耗时变长输出质量反而可能下降。更稳的做法是先做摘要或分段处理。比如一个几十页的说明文档可以先让模型按章节产出摘要再基于摘要回答问题而不是把全文原样放进上下文。2.3 给历史对话设“保鲜期”在会话类场景里高频问题往往和目标无关。比如“你叫什么名字”“你能做什么”这类问题对话轮次多了以后会慢慢把真正有用的信息挤出去。我一般会设置历史消息裁剪策略最近的 N 轮保留完整内容更早的对话先压缩成摘要超过摘要长度限制的直接丢弃。这样做既保留了关键背景又不会让 token 无限膨胀。注意上下文裁剪不是简单的“删掉旧消息”。如果你在做一个多轮任务模型需要依赖早前用户提供的信息盲目裁剪会直接导致后续任务失败。正确做法是先判断旧消息在未来是否还会被引用再决定保留还是摘要。2.4 给模型“允许说你不知道”的空间LLM 项目里最难容忍的不是回答错误而是编造答案。工程上要避免这个问题除了在提示词里加“如果不知道请明确说不知道”还要在程序侧做校验。比如做知识库问答时如果检索结果与问题相关性不高就不要硬拼答案。这时候更合理的处理是返回兜底文案暂未找到相关内容请换一种表达方式。这比强行让模型生成一段看似合理、实则无依据的内容靠谱得多。3. 工程调用层面的礼仪精度、采样参数和输出校验到了工程层“礼仪”就变成了具体配置。这里最让人困惑也最容易翻车的是精度问题。模型权重用什么精度加载不仅影响显存占用还会直接影响输出结果。FP16、FP32、BF16 三者的差异在实际项目中不是“哪个分数高用哪个”那么简单。3.1 FP16、FP32、BF16 的差异和选择逻辑先说结论FP32 精度高、显存占用大FP16 显存省一半但容易溢出BF16 在深度学习场景里通常比 FP16 更稳因为它的指数范围和 FP32 一致能表示更大动态范围的数据。给个对比表精度类型显存占用数值范围适用场景常见问题FP32高大训练、需要高精度的调试场景显存不足推理速度慢FP16中较小老显卡、显存紧张时的推理小数值容易溢出输出可能漂移BF16中与 FP32 接近高并发推理、大模型部署尾数精度低复杂计算可能有细微误差本地跑大模型时我一般先用 BF16 跑一遍业务数据观察输出是否满足需求如果显存吃紧再降级到 FP16 或 INT8 量化。判断标准不是理论上损失多少精度而是你的实际任务是否能接受输出差异。如果做对比测试一定要在相同精度和相同采样参数下跑。不同精度之间输出的微小差异很可能被误判成模型能力问题。3.2 采样参数不是越大越好temperature 和 top_p 这两个参数经常被当成“创意调节旋钮”。实际上它们控制的是输出概率分布的形状。temperature 偏好低一点0.1 到 0.3输出会更稳定、更可复现适合代码生成、数据抽取、结构化输出。temperature 偏高时回答更多样但也更容易跑偏适合创意写作。top_p 一般和 temperature 搭配使用不建议同时都拉到很高。做生产级任务时我通常固定一组低随机性参数比如 temperature 0.2、top_p 0.9这样同一输入的结果波动小后面调 bug 也容易复现。3.3 输出校验是必须的不是可选的把 LLM 的返回值直接放给下游这在我眼里是高风险行为。模型输出经常会有多余的换行、引号、解释性文字甚至 JSON 结构不完整。更隐蔽的问题是模型可能生成“看起来很对但字段体系完全不对”的内容。所以接口层一定要加校验如果是 JSON尝试解析失败则进入重试或降级流程如果是指定枚举值检查结果是否在合法范围内如果要求输出固定长度检查长度和边界。校验失败时不要反复调同一个请求而是先检查提示词的输出格式约束和采样参数是否合理。3.4 重试要保证幂等性LLM 接口调用天然有不确定性一次失败后盲目重试拿到的新结果可能和第一次完全不一样。在批量任务里这会导致同一个文档生成两次结果却不同。更稳妥的思路是为每个请求生成一个唯一的任务 ID并记录输入、参数、输出和版本号。重试时使用相同输入和相同参数输出差异控制在较低水平。如果业务对一致性要求高可以固定 seed在平台支持的前提下同时把 temperature 调低。4. Agent 和编排框架里的礼仪让模型学会“先看再动”Agent 是 LLM 应用里最容易失控的形态。模型一旦具备工具调用能力就会自行决定“接下来做什么”如果边界不清晰常常出现的事不是“AI 在干活”而是“AI 在反复折腾同一个动作”。4.1 Agent 最常见的故障模式我排查过的 Agent 问题里高频现象有三个工具调用循环模型反复调用同一个工具没有收敛判断。任务边界模糊明明只需要查天气模型却去读日志、翻文档。上下文污染把工具返回的原始结果全部塞进上下文导致后续决策混乱。这些问题的根源不是模型不够聪明而是你给模型的任务描述、工具描述和停止条件不够清楚。4.2 工具调用要先定“接口契约”每个工具都应该有清晰的三段式描述工具负责什么、输入需要什么、返回什么格式。模型在决定是否调用工具时依赖的就是这些描述。例如工具查询订单状态。输入订单号字符串。返回JSON 对象包含 status、remark、updatedAt 字段。这样设定之后模型就不会把一个不存在的字段当作查询条件。你还要在系统提示词里说明如果没有拿到有效订单号不执行查询直接请用户补充。4.3 编排框架真正解决的是“把任务拆成可管理的步骤”很多人问为什么 LLM 应用需要编排框架比如 LangChain、Dify、Coze 这类套件。直接原因是你不可能把所有判断都写进一个大提示词里。一个复杂任务通常需要拆成多个子步骤先判断用户的意图再按意图挑选处理节点每个节点内部执行独立的 LLM 调用或工具调用最后汇总输出。编排框架提供的是这类流程的承载能力比如节点连接、状态传递、缓存、失败重试、日志追踪。它本身不提升模型能力但能把项目从“一条提示词写完”升级成“一串节点协同完成”。4.4 必设停止条件Agent 比单次问答更需要“收手”机制。你需要提前定义好什么情况下任务算完成什么情况下必须停止继续调用工具。常见的停止条件包括已拿到完整答案且格式校验通过工具调用次数达到上限连续多次工具返回结果不变用户明确取消。没有这些条件Agent 在低成本场景下还能忍受在高并发或计费接口的场景里开销会被迅速放大。注意不要为了让 Agent 表现“聪明”而无限放宽最大迭代次数。更可靠的做法是减少每轮决策的复杂度让模型每一步只做一件简单事而不是指望它能自我纠偏十几次。5. 知识库和 Wiki 场景的礼仪先整理数据再让模型回答知识库问答是 LLM 应用非常流行的落地方式。像 AnythingLLM、Dify、Obsidian LLM Wiki 这类组合之所以受欢迎是因为它们把“文档管理、检索、问答”串成了一条链路。但这一步最容易被忽视的是数据进入知识库之前的清洗和整理。没有人喜欢把时间花在清洗文档上但知识库效果不好80% 的问题都出在数据进库前而不是模型不够好。5.1 知识库场景里的“Wiki 范式”到底是什么Andrej Karpathy 提过一种用 Wiki 方式组织知识供 LLM 使用的思路。核心思想不是把所有笔记堆进一个文件而是让知识以结构化、互相链接的方式存在。简单理解模型本身不是记忆库它只是根据你给的上下文生成回答。如果你希望它稳定引用你的项目资料你就得先让这些资料足够整洁、区分度足够高。Obsidian LLM Wiki 这类组合的实际价值在于笔记按主题拆分而不是一个大文档每个笔记有清晰标题和摘要通过关键词和链接关系提高检索命中率。这样接入向量库后检索到的片段会更精准回答也更有依据。5.2 数据入库前先做这四步我接知识库的时候会强制自己按下面顺序处理格式统一所有 PDF、Word、Markdown 先转成纯文本或 Markdown去掉页眉页脚。编码检查批量文档出现乱码时优先处理文件编码不要让模型去“猜”。分段合理按标题和段落切分而不是固定每 500 个字硬切。硬切会切断语义检索时容易遗漏关键信息。内容质量过滤广告、重复内容、过期信息直接清理掉。如果你用的是 AnythingLLM 这类工具可以借助它自带的向量化、聊天设置和文档管理功能但别指望工具替你完成清洗。5.3 检索增强型回答要明确“回答依据”知识库问答的礼仪核心是让回答说清依据并控制模型在多文档内容不一致时的处理方式。提示词里值得加入这样的约束回答必须基于给定的资料如果资料之间互相矛盾请指出矛盾点不要强行统一如果资料中没有相关内容请说明未找到不要编造。工程侧还要做引用来源展示。这不仅是体验问题也是排查工具。用户回答错误时能快速定位是检索到错误片段还是模型生成时跑偏。5.4 多人访问知识库时的权限判断“AnythingLLM 设置网页”“让其他人访问”这类需求很常见。本地工具默认跑在本地地址团队协作时通常要做网络访问配置。注意一个边界任何人能访问时凡是涉及用户数据、接口凭证、内部文档都要单独做权限判断。最稳妥的顺序是先在内网或本机部署确认功能正常再按官方文档配置访问地址为不同角色配置权限分组不直接开放全量管理权限查看会话记录和文件访问日志确认是否有人访问超范围内容。这里我强调一点如果你对网络配置不熟悉不要直接修改监听地址或将端口暴露到公网。本地工具升级成多人服务时涉及的不只是功能还有账号体系和权限边界这一步必须谨慎。5.5 微调不能替代知识库微调是一个单独话题。很多人想通过微调让模型“记住”某些私有知识但实际上微调擅长的是让模型掌握某种行为模式或表达风格而不是让你把文档内容背下来。一个比较实用的分工是提示词负责行为边界知识库负责提供事实资料微调负责让模型适配特定输出风格编排框架负责把多个步骤串联起来。如果业务数据的分布和形式比较稳定微调确实能改善效果但如果只是想增加新的知识点更高效的做法是直接更新知识库。6. 排查链路效果变差时不要先怪模型做 LLM 项目最难受的是“模型可能每次输出都不一样”问题定位很难。经验多了之后我养成了一个固定习惯先分清现象属于哪一层再动手调参。6.1 按四层顺序排查排查层先看什么常见表现输入层用户输入格式、文档编码、路径、上下文长度输出和预期不相关提示词层角色、任务、输出格式、负面约束回答泛泛而谈、格式不对参数层精度、temperature、top_p、seed输出时好时坏、结果漂移系统层依赖版本、显存、端口、权限、日志报错、卡住、返回为空很多“模型效果变差”的问题最后都能落到输入层和参数层。比如长文档没有分段、上下文被截断、知识库里的材料编码乱掉这些都会被误判成“模型变笨了”。6.2 先看日志再改参数不要一上来就调 temperature 或换模型。正确顺序应该是看请求和响应日志确认输入有没有问题看上下文长度确认有没有被截断看资源占用确认有没有显存不足导致加载异常看返回值确认是结构错误还是内容错误再决定是修改提示词、采样参数还是数据清洗逻辑。如果日志不完整直接调参数很难定位。理想的日志至少包含时间、请求 ID、模型版本、精度、采样参数、输入摘要、输出摘要、耗时和错误码。6.3 用固定样例做回归校验当系统配置多次变化后你需要一个回归集来确认“这次改进到底有没有用”。我维护过一个很小的测试集包含五六个典型输入一个长文本总结、一个 JSON 抽取、一个不确定问题、一个需多轮澄清的问题、一个批量文件任务。每次调整完先跑一遍这个回归集确认行为没有倒退。这个习惯能解决 LLM 项目里最麻烦的问题模型输出不稳定导致你分不清某个改动是真正有效还是运气好。6.4 什么情况下才考虑换模型如果把前面几层都排查完了输入干净、提示词清晰、参数合理、知识库正常但输出仍然不能接受这时再考虑换模型或换精度。优先比较同参数量、不同架构的模型没有结果再升级模型规模。模型规模变大不等于直接变好在低显存环境里升级模型还会引入加载慢、显存不足、批量任务变长等问题。收个尾LLM Etiquette 不是一套外在礼貌而是你在使用大模型时主动建立的秩序。提示词里写清楚边界上下文里控制好长度精度和采样参数按自己的任务去选择Agent 设计好工具契约和停止条件知识库入库前先清理数据排查问题时从日志和输入开始逐层定位。每一步都不难但缺任何一环项目都会在某个意想不到的方向上翻车。我更建议先把单任务跑稳再考虑批量、接口和多人协作。默认配置不是不能用但它只适合用来学习或快速验证不适合直接当成生产标准。真正的稳定来自规范和校验而不是换一个更聪明的大模型。