前阵子帮团队搭一个批量文档处理工具用 LLM 提炼结构化信息。刚开始那几天特别顺把提示词往 API 里一丢输出质量超出预期。但用了一周后问题来了同一段提示词换了个模型版本输出格式全乱了批量跑到第 47 条时突然返回空内容日志也没报错让模型根据上下文追问时它居然把上一条文档里的数据当成了当前文档的输入。排查到最后问题不在模型能力而在我们根本没给 LLM 建立一套使用规范。后来我在自己的项目里反复试、反复踩坑才慢慢意识到一个被低估的概念LLM Etiquette。它不是“和 AI 说话要有礼貌”这种表面文章而是一整套输入、运行、输出、协作规则。真正能稳定用好 LLM 的团队和个人不是提示词写得多么华丽而是把与模型打交道的整个过程收敛成了可以重复、可以验证、可以排查的流程。这篇文章想把这件事说透。我会结合模型精度选择、本地知识库、上下文管理、Agent 编排、批量任务落地等常见场景拆解什么是 LLM Etiquette、为什么单次跑通不等于能用好、以及普通开发者和内容生产者应该从哪里开始。1. 先给 LLM Etiquette 一个定义这不是客套是稳定输出1.1 为什么“随便聊聊”和“项目使用”要求完全不一样很多人在第一次接触 LLM 时习惯把它当成一个更聪明的搜索引擎或聊天对象。你问一句它答一句答得不好就换个说法再问。这种模式下双方之间的“礼仪”几乎不存在你可以随时打断、随意换话题、接受模糊回答因为聊天本身没有明确交付物。但一旦把 LLM 放进项目流程事情就变了。它要处理的是固定格式的输入输出要能被程序解析错误要能被定位结果要能被验证。此时同一句话在不同模型、不同温度参数、不同上下文长度下可能产生完全不同的结果。你面对的已经不是“能不能对话”而是“能不能稳定复现”。这时候真正需要的不是更好的模型而是一套协作规范。LLM Etiquette 就是这套规范的名字。1.2 主判断LLM Etiquette 是把“偶发可用”变成“稳定可复现”的交互规范我在实际项目中得到的核心判断是LLM Etiquette 的本质是承认模型是概率系统然后通过输入规范、输出规范和边界约束把概率波动控制在对业务可接受的范围内。换句话说你不可能让模型每次输出都一样但你可以让“绝大多数输出都满足契约”。这个契约包括输入侧给模型的任务描述足够清晰信息来源可追溯。运行侧模型、精度、路径、参数是确定的不是随便选的。输出侧输出格式可解析缺失或错误时能被发现并重试。协作侧当多个模型或工具协作时每一步的职责和权限是定死的。如果不建立这套规范就会出现我在开头描述的场景Demo 阶段很爽项目阶段四处救火。你以为是模型太笨其实是你在用聊天的方式做工程。注意这里说的“规范”不是要求模型固化成死板模板而是把人的随意性降到最低。LLM 的创造力该用在内容生成上不该用在格式解析上。2. 输入侧礼仪从“丢一段话”到“交付一个上下文”2.1 提示词不是口播稿要写清楚角色、任务、输入、输出很多人写提示词等于把需求用大白话描述一遍。比如“请总结这段客户反馈”然后就把一段很长很长的文本贴在后面。这在一次性使用中常常能work但到了批量场景里你会发现模型每次“理解”的重点都不一样。我建议把提示词当成一份任务书来写四要素缺一不可角色模型以什么身份处理这个任务比如“你是一名内容运营”。任务具体要做什么比如“从以下客户反馈中提取三个产品痛点”。输入任务处理的原始材料用明确的标记分隔不要混在指令中间。输出输出格式、字数限制、是否要 JSON、字段名是什么。一个更结构化的示意角色你是一名数据分析助手。 任务从给定的客户反馈中提取“产品问题”和“用户情绪”。 输入 feedback 这里放客户反馈原文 /feedback 输出要求 - 输出 JSON 对象 - 字段problemstringsentimentpositive/neutral/negative - 不要输出多余解释这样写模型的“自由发挥空间”被收敛在合理范围里。输出的格式也更稳定。2.2 上下文管理才是真正的隐形瓶颈一旦任务变复杂上下文就成了比提示词更稀缺的资源。很多人以为“把材料都塞给模型它就能记住”实际上模型的处理窗口是有限的而且它对上下文不同位置的敏感度并不相同。从工程经验看有几个地方最容易踩坑长文本中埋在中间的信息容易被模型忽略。关键内容尽量前置或者在后半部分再强调一次。上下文超长时系统可能会截断或丢失开头内容。要提前确认模型的最大上下文长度并给输入设置冗余上限。多轮对话中历史错误信息会污染后续判断。出现一次错误输出后最好重新构建本次任务上下文而不是带着旧对话继续“纠正”。一个合适的类比是先给目录再按需展开章节。不要试图让模型一次读完一整本书然后把所有内容都记住。更可靠的做法是先把文档切块检索出相关片段再把片段喂给模型。2.3 知识库接入不是塞资料而是先把语料整理成人能读、模型才能读的格式很多人看到 LLM 就想往里面塞公司文档、个人笔记、几百页白皮书。这里最容易犯的错误是“把知识库接入等同于向量化后扔给模型”。但实际操作中知识库能不能发挥作用取决于你的语料是否适合被模型消费。以 Obsidian LLM wiki 搭建个人知识库为例。这里的核心不是把笔记全部变成向量而是先让笔记有清晰的结构、标题、标签和链接。模型读取到的不是“一段乱糟糟的文字”而是“一个语义单元”。如果原始笔记本身没有边界即使切块也会切出很多语义破碎的片段。AnythingLLM 这类工具也在解决同一个问题把文档、网页、数据库整理成可检索的上下文再通过对话窗口对外提供答案。用它的“对外访问”功能让团队成员使用时真正要操心的不是能不能打开网页而是知识库里放了什么、哪些内容可以被检索、哪些内容不应该被暴露。我个人的经验是知识库的质量决定了模型回答的天花板。模型再强也补不了“输入本身混乱”的坑。这不是模型能力问题是输入侧礼仪缺失。3. 运行侧礼仪精度、路径、引擎是让模型“跑得稳”的前提3.1 模型精度不是越高越好FP16、FP32、BF16 各管什么很多初学者第一次接触本地 LLM 时会看到一堆术语FP16、FP32、BF16、量化、int8、int4。如果不理解这些选择的含义就会盲目采用社区里流传的“默认配置”导致显存爆了、推理很慢、结果不稳定。从原理上讲这些精度描述的是模型权重在计算时用多少位来表示一个数字。精度越高数值越接近原始训练结果但内存开销也越大。下面是常见选择的一个通用参考精度内存占用稳定性常见应用场景FP32最高最稳定基线测试、特定数值敏感性任务FP16中等一般推理加速但小数值场景可能有溢出风险BF16中等偏小较好训练和推理常用指数范围接近 FP32INT8/INT4低有损追求速度和内存适合对精度不敏感任务注意不同的推理引擎、不同的显卡架构对精度的支持不一样。如果输入材料没有明确给出推荐精度落地前最好先用小样本对比一下输出质量。这里的“质量”不是看一两句话是否通顺而是看关键信息是否丢失、格式是否稳定、数值是否准确。实操建议第一次部署本地模型不要一上来就追求低精度量化。先把模型用默认精度跑通再尝试精度压缩每一步都保留输出样例做对比。这样你能知道是哪一步的压缩引入了质量损失。3.2 模型权重、基础模型、微调模型先把路径关系理清楚本地跑模型时路径配置看起来是一件小事但实际翻车的概率非常高。很多工具都提供了一个外部配置文件用来告诉程序去哪里找模型。一个常见的问题是模型下载了但程序找不到或者加载了错误版本。以 ComfyUI 的extra_model_paths.yaml为例它允许用户把模型路径指向自定义目录。这个例子同样适用于很多 LLM 本地推理工具。配置的关键不是“把路径填上就行”而是理解模型目录的组织逻辑基础模型放哪里、LoRA 放哪里、CLIP 放哪里、嵌入模型放哪里各有约定。下面是一个示例结构具体字段以你的工具为准# 示例结构不要直接照抄 my_models: base_path: /data/models lora: /data/models/lora llm: /data/models/llm clip: /data/models/clip一个容易踩坑的点是多个项目共用同一套模型目录时版本冲突会出现。比较稳妥的做法是给每个模型目录加版本标识或把模型文件按日期组织避免“模型更新后旧接口突然不可用”这种问题。项目代码里尽量不写死绝对路径通过配置文件或环境变量注入这样换机器、换团队时成本更低。3.3 本地私有部署时“给别人访问”之前要做什么现在很多团队会用 AnythingLLM 这类工具搭一个内部问答服务然后通过网页让其他人访问。这个场景看起来简单真正落地时要补的细节不少访问控制是不是任何人都能打开这个页面要不要登录权限如何分配资源预算几个人同时使用时显存、CPU、内存够不够并发一高会不会卡死数据边界知识库里是否包含敏感内容外部访问者能不能看到不合适的文档日志记录谁在什么时间问了什么问题模型返回了什么出现事故时能不能追溯这些不是 LLM 特有的问题但 LLM 服务会放大这些问题。因为它让人与数据的交互变得更自然、更直接用户可能无意间检索到不该看的内容。部署内部服务之前先把这些问题想清楚比加一个漂亮的前端界面重要得多。4. 输出侧礼仪拿到结果不等于任务结束4.1 先定义“什么算好结果”再决定怎么调输入或参数很多团队在模型效果不好时第一反应是换模型、调温度参数、改提示词。但如果你没有定义“什么算好结果”所有调整都只是碰运气。我建议在项目开始前准备一个小小的评估集。这个评估集不需要很大二三十条真实任务即可。每一批调参之后都拿这个评估集跑一遍对比输出质量。评估标准可以包括输出格式是否合规。必要字段是否完整。事实性内容是否有明显错误。风格是否满足业务需求。这不是学术评测不需要复杂指标。它起的作用是“防止你被一两次成功输出误导”。单次成功只能证明流程能通不能证明流程稳定。4.2 给 LLM 设计输出协议结构化、可解析、可校验越是工程化的场景越应该约束输出格式。你当然可以让模型生成一段自然语言然后靠人去读但如果你希望后续程序能自动处理结果就必须给模型一套输出协议。比如让模型返回 JSON{ summary: 一句话摘要, points: [要点1, 要点2], risk_level: high }以下是一些实用的约束策略明确要求输出 JSON 或其他结构并给出字段定义。要求模型不要输出解释性文字只输出数据。在程序中增加解析和校验环节解析失败时自动重试。重试仍失败时把原始输入和输出写入日志方便人工检查。这个环节不仅能提高自动化率还能帮助你定位问题。如果某类输入总是解析失败你就能快速判断是模型输出协议问题还是输入数据格式问题。4.3 批量任务真正要防的不是慢而是失败之后没有日志处理批量任务时大家通常先担心速度。实际上批量任务最大的风险是“失败没有痕迹”跑到第 50 条挂掉了日志里只有一行超时你根本不知道挂在哪一步、为什么挂。我的一般排查顺序是看现象卡住、超时、空输出、格式错乱、结果不稳定。看输入原始文本格式、编码、长度、字段是否完整。看环境模型版本、依赖版本、显存占用、网络连接。看参数并发数、批次大小、超时设置、温度参数、max_tokens。看模型边界输入是否超长、是否触发内容过滤、是否达到速率限制。在批量任务中最容易被低估的是“批次和断点”。建议让每个任务都可以单独重跑并保留中间产物。这样即使某个批次失败你只需要修复问题后重跑失败条目不需要把整批任务重新执行一遍。这看起来像工程常识但在 LLM 项目中特别容易忽略因为模型调用看起来太简单了简单到让你以为不需要这些机制。实用建议给每个任务加上唯一的任务 ID输出结果和原始输入放在同一个目录结构里。这样你随时能追溯“这个结果是怎么来的”而不是看到一个孤零零的输出文本。5. 协作侧礼仪从单次对话到 Agent 与编排5.1 为什么单次调用够用但复杂任务需要编排框架如果你只是做“输入一段文本、输出一段摘要”单次调用就够了。但真实项目往往不是这样需要先检索资料再判断该调用哪个工具然后执行操作最后汇总结果。这种多步骤流程如果全写在提示词里让模型自由发挥结果会非常不可控。这也是为什么“LLM 应用需要编排框架”会成为热门话题。编排框架的价值不是替模型思考而是把复杂任务拆成一个有边界的流程每一步的输入是什么、调用什么工具、输出到哪里、失败怎么办。模型在其中承担的是“决策和生成”的职责而不是整个流程的调度者。以 LLM Agent 为例它看起来很灵活好像能自主规划。但如果 Agent 没有任何边界它就可能反复试错、调用错误的工具、在一个死循环里绕圈。编排框架要做的事恰恰是给这些“自主行为”加上规则和限制。5.2 让 Agent 干活前先给它划清边界Agent 是一个非常有吸引力的概念你告诉它一个目标它自己拆解任务、调用工具、返回结果。但一旦进入生产环境无约束的 Agent 是灾难性的它可能会重复消费 API 额度、读取错误文件、修改不该改的数据、在工具调用失败后不返回错误信息。我通常会建议按下面的方式约束一个 Agent工具清单Agent 只能调用预先注册的工具不能无限扩展。权限控制工具能访问哪类数据、能执行哪些操作必须明确。人工确认节点涉及写操作、删除操作、对外发消息时设置人工确认。超时和重试单次任务允许运行多久、失败后重试几次、重试仍失败怎么办。这里的核心判断是Agent 的灵活程度要与风险等级成正比。做文本分类时可以让 Agent 自由一点做数据删除或资金操作时任何自动执行都要有强约束。5.3 从 LLM wiki 到知识库工作流把模型放进你的持续学习系统热搜词里反复出现的 LLM wiki以及“Obsidian LLM wiki 搭建个人知识库”本质上代表的是一种工作流转变LLM 不再只是一个聊天窗口而是嵌入到你的知识管理系统中。LLM wiki 这个思路用我自己的话理解是把大模型当成个人知识库的“解释器”。你不再需要把每篇笔记都整理成标准答案而是把原始材料、链接、标签、摘要存成结构化的 wiki然后让 LLM 按需检索、汇总、对比。它的价值不是让你少写笔记而是让你在知识越来越多时仍然能找到你需要的内容。这种工作流对内容创作者、研究者和技术文档维护者尤其有价值。以前写笔记是“记录”现在写笔记是“喂给未来的你”。但这也意味着你的笔记结构越清晰模型能发挥的作用越大。这又回到了输入侧礼仪乱糟糟的个人笔记库即使接入了再强的模型也只会给出乱糟糟的答案。6. 一张落地清单学完可以直接对照检查6.1 LLM Etiquette 六步检查清单我把前面的内容压缩成一张检查清单适合在搭 LLM 项目时逐项对照环节检查项输入提示词是否包含角色、任务、输入、输出四要素上下文关键信息是否前置是否设置了长度上限知识库语料是否有结构是否经过清洗和切块运行精度、路径、引擎版本是否确定并记录输出是否定义了结构化输出是否有解析和校验批量是否有任务 ID、日志、断点重跑机制协作Agent 工具权限是否受限是否有确认节点这张清单不是金科玉律但它值得在项目启动时贴在你的文档里。6.2 哪些场景不适合套这套规范不是所有使用 LLM 的场景都需要严格礼仪。如果你只是和朋友讨论一个概念快速起草一段文案临时让模型翻译一段文字纯好奇心探索某个模型能力那完全可以放松约束。LLM Etiquette 的核心价值在于“可复现、可维护、可验证”而这些只有在长期使用、多人协作、批量处理或生产环境里才真正重要。如果你处在一个快速验证阶段比如一个周末 hackathon 的原型那么先跑通、再优化就够了。不要在一开始就把流程设计得过于复杂。6.3 最后回到我的核心判断回到最开始那个问题为什么很多 LLM 项目在演示时惊艳投入真实场景后却一地鸡毛不是因为模型变笨了而是因为使用方式变了。演示阶段你宽容模型的每一次输出生产环境你要求模型稳定输出。LLM Etiquette 不是教你说“请”和“谢谢”而是帮你在模型不完美的情况下设计一套足够可靠的协作方式。它包含对输入的组织、对运行环境的控制、对输出格式的校验、对失败路径的预案以及对边界和权限的清醒认知。如果你现在正在为一个 LLM 项目的稳定性头疼我的建议是先别急着换模型或调参数。回头沿着输入、上下文、环境、输出、日志这个链路检查一遍看哪一条礼仪没有被遵守。问题往往不在大模型而在你和它之间的那套协作协议。