上周帮一个团队评审大模型接入方案时我看到了一个非常典型的现象同一个 API、同一个模型、同样的预算不同开发者做出来的效果差距非常大。有人能用几段稳定 Prompt 跑出一条可复用的任务流有人花了三天还在跟模型的“一本正经胡说八道”搏斗。问题通常不在模型而在于我们是否理解它的工作方式是否建立了正确的协作边界。大语言模型不是一个“问一句就能拿答案”的搜索框它更像一个能力很强、但需要你交代清楚背景、边界和输出格式的协作者。这套协作规则我称之为LLM Etiquette——使用大语言模型时的礼仪与规范。这篇文章不打算讲某个具体框架的完整教程而是想系统梳理一套能迁移到日常开发中的 LLM 使用规范。无论你是在调 Prompt、做 Agent、搭知识库问答还是在做模型微调与推理部署这套规范都能帮你减少返工、提高输出稳定性。文章会穿插代码示例、参数对比和排查清单你可以直接把它当作一份团队内部的 LLM 协作手册来用。1. 为什么需要 LLM Etiquette从“协作失序”说起先看三个真实场景。场景一同一个 Prompt不同人用效果不一样。A 工程师写的是“帮我总结这段日志”B 工程师写的是“你现在是一名 SRE 工程师请分析下面这段来自生产环境的异常日志按时间顺序列出根因假设给出每个假设的证据链最后输出排查建议。如果证据不足请直接说证据不足不要猜测”。结果是 B 工程师拿到了一份可以直接贴进故障报告的分析而 A 工程师得到的是一段含糊的概述。两个人用的模型完全一样差距在于输入信息的组织方式。场景二上下文越长效果反而越差。产品经理说“模型不是支持 128K 上下文吗那把产品文档全部塞进去不就行了”。结果模型开始遗漏关键细节甚至被文档里的过期信息带偏。大上下文窗口只是能力上限不等于你把全部信息倒给它就能得到更好的结果。信息一多噪声跟着多模型没法判断你真正在乎什么。场景三Agent 跑着跑着就失控了。一个自动化工单 Agent 在调用搜索工具时由于返回结果不理想它在一个错误分支上反复重试最终把 API 调用额度耗掉了一大半而且每次重试都在用一个相似的错误前提推理。原因是这个 Agent 只被赋予了“完成任务”的目标却没有被告知“什么时候应该停下来”。这三个场景指向同一个结论LLM 输出质量 输入信息秩序 × 模型能力。模型能力是基础我们短期内改变不了但输入信息秩序是我们可以控制的。LLM Etiquette 的本质就是建立一套输入信息秩序让模型在明确的边界内发挥能力而不是在混沌中碰运气。它真正降低的是调试验证成本。没有规范时一次 Prompt 改动可能引发连锁反应有了规范你能清楚地知道问题是出在指令、上下文、工具权限还是模型本身。这篇文章适合正在做 Prompt 工程、Agent 开发、RAG 应用、模型微调或 API 集成的开发者也适合需要在团队里统一 LLM 使用方式的负责人。2. 核心概念理解 LLM 的输入输出规则在谈礼仪之前先理解模型的基本工作方式。下面几个概念是所有使用规范的基础。Token 与上下文窗口。Token 是模型处理文本的最小单位。中文场景下1 个汉字大约是 1 到 2 个 Token1 个英文单词约 1 到 2 个 Token。上下文窗口是模型一次能接收的最大 Token 数。窗口越大模型能看到的材料越多但不意味着它能把所有信息用得更好。temperature 与采样参数。temperature 控制输出的随机性。值越低输出越确定适合代码生成、数据抽取值越高输出越多样适合创意写作。与之配套的还有 top_p、top_k它们影响模型从候选词中选择下一个词的方式。对于大多数工程场景建议把 temperature 调低比如 0 到 0.3 之间优先保证稳定性。system prompt 与 user prompt。系统提示词负责设定角色的长期行为和固定规则用户提示词负责描述当次任务。两者分离的目的是让稳定规则和动态需求互不干扰。下面是这些概念对使用规范的实际影响概念通俗理解对使用规范的影响Token模型计费与输入长度的最小单位需要管理输入长度避免无效内容占用窗口上下文窗口模型一次能“看到”的内容范围不是越长越好要分主次放置信息temperature输出随机性控制旋钮工程场景建议调低保证输出稳定system prompt给模型设定的长期身份与规则适合放不经常变化的约束条件user prompt用户当次提交的任务描述适合放动态需求、输入数据和输出要求理解了这些概念后你会发现 LLM Etiquette 的很多规则其实是在跟模型的机制对齐。模型没有人类的“常识判断能力”它只会按照你给出的信息权重来作答。你把什么放进上下文、放在哪个位置、用怎样的结构呈现都会直接影响结果。3. Prompt Etiquette把需求说清楚Prompt 是与 LLM 交互最基础的方式也是大多数团队最早遭遇挫败的地方。很多人的第一反应是“模型效果差”但拆开看往往是 Prompt 本身写得含糊。3.1 一个好的 Prompt 有三个特征第一是具体。不要问“帮我看看这段代码”而要问“请检查这段代码中的 SQL 注入风险并给出修复建议”。具体意味着模型不需要替你猜测意图。第二是结构化。用分段、编号、列表把任务目标、输入数据、输出格式分开。模型在处理结构清晰的输入时更容易遵循指定的输出格式。第三是可验证。你要在 Prompt 里定义什么叫做“完成”。例如“输出必须是一个 JSON 对象”“如果信息不足回复‘信息不足’”。这样你可以在程序里做结果校验而不是靠肉眼判断。3.2 一个可复制的 Prompt 模板下面是一个可以复用的代码评审 Prompt 构建示例。它把角色、任务、输入、输出格式、约束拆分清楚。# 文件路径prompt_builder.py def build_review_prompt(code_snippet: str) - str: system_prompt 你是一名资深后端工程师负责代码评审。 你擅长发现安全风险、性能问题和可维护性隐患。 回答时要保持客观不夸奖代码只输出问题和建议。 user_prompt f 请评审以下代码片段 {code_snippet} 请按以下格式输出 【问题级别】阻断 / 建议 / 可选 【问题描述】不超过 50 字 【修改建议】给出关键修改方向或示意代码 如果代码没有明显问题仅输出通过。 return system_prompt \n\n user_prompt在这个示例中system prompt 负责设定评审者身份和回答风格user prompt 负责描述本次任务、给出输入、约束输出格式。这样做的好处是系统提示词可以沉淀为团队公共资源用户提示词只承载变化的部分两者便于分别维护和测试。3.3 需要避免的 Prompt 反模式常见反模式包括一次问多个不相关的问题导致模型只回答最后一个没有指定输出格式导致每次返回结构都不一样在 Prompt 中表达情绪或施压例如“你最好给我正确答案”这不会提高正确率没有给“不知道”的出口导致模型被迫编造。更稳妥的做法是如果你需要模型在信息不足时承认不确定就在 Prompt 里明确写“如果信息不足请回答不知道不要猜测”。这相当于主动为模型设置了一个安全的默认行为能显著减少幻觉。4. 上下文管理 EtiquetteToken 是稀缺资源大模型的上下文窗口是尺寸优先的资源。表面上 128K 很充裕但大量实践表明上下文越长模型越容易忽略关键信息。这不是玄学而是注意力机制的自然结果——当重要信息被淹没在大量无关文本中时模型很难抓住重点。4.1 上下文不是越长越好上下文过长会带来三个问题。第一是噪声干扰无关信息越多模型越容易被带偏第二是位置偏差模型对上下文开头和结尾的内容通常更敏感夹在中间的内容容易被忽略第三是成本输入 Token 是要付费的无效内容越多账单越高。4.2 信息分层策略可以把上下文按稳定程度分成三层系统层放置长期有效的规则、身份设定、禁止事项。这一层不随任务变化。任务层描述当次要做什么包括任务目标和输出格式。参考层只放与当次任务相关的资料片段并做数量和质量控制。这种分层方式能让模型更容易找到关键信息。比如在 RAG 应用中不要把整篇文档塞进去而是先做检索、截断、排序只保留最相关的片段。4.3 代码示例动态截断与排序下面这段代码演示了如何从检索结果中构建带预算上限的上下文。它按可用 Token 预算动态截断而不是把所有结果都拼接进去。# 文件路径context_builder.py def build_context(retrieved_chunks, max_tokens1500, separator\n\n): 将检索到的文本片段拼接为上下文。 这里用字符数粗估 Token 数实际项目应使用模型的分词器精确计算。 # 粗略估算中文场景下 1 个 Token 约等于 1.5 到 2 个字符 char_budget max_tokens * 3 selected [] used 0 for chunk in retrieved_chunks: size len(chunk) if used size char_budget: break selected.append(chunk) used size return separator.join(selected)关键的逻辑是设置预算、按序挑选、超出即停。如果检索结果有 20 个片段但预算只够放 6 个那就只放 6 个。这样既避免了上下文过载又保证了模型能集中处理最重要的信息。在实际项目中还可以在拼接时对片段按相关度排序把最相关的内容放在上下文开头和结尾——因为那是模型注意力更强的位置。5. Agent 场景 Etiquette边界比自由更重要Agent 是 LLM 应用里最让人兴奋、也最容易失控的方向。一个 Agent 拥有工具调用、多步推理、记忆管理能力但能力越多越需要规范约束。LLM Etiquette 在 Agent 场景中的核心原则只有一条边界比自由更重要。5.1 Agent 为什么会失控失控通常有几个原因没有限制工具调用的次数和范围Agent 可以在错误分支上反复重试没有设定终止条件Agent 会一直推理到超出预期没有人工确认机制Agent 执行了不可逆操作后才被发现。本质上模型是按概率生成下一步动作的它没有“及时止损”的本能。这个止损机制需要由开发者在系统设计层面加上。5.2 边界设置工具白名单、迭代上限、终止条件这里给出一个 Agent 配置的示例。重点不是某个框架的具体 API而是一组可迁移的约束项# 文件路径agent_config.py agent_config { # 工具白名单只允许使用这几个工具其余一律拒绝 tools: [search, calculator], # 允许访问的域名白名单避免 Agent 越权抓取 allowed_domains: [docs.example.com], # 最大迭代轮数超过后强制终止防止死循环 max_iterations: 3, # 终止条件一旦 Agent 输出答案标记立即停止 stop_after: [answer], # 高风险操作需要人工确认 require_human_confirm: [delete, send_email, transfer_money] }这些配置项的意图很清楚工具白名单缩小了 Agent 的行动面迭代上限锁死了推理轮数终止条件告诉它“什么时候算完成”人工确认给了不可逆操作一个安全阀。加上这些约束后Agent 的行为会明显更可控出 bug 时也更容易复现。5.3 失败回退机制另一个容易被忽略的细节是失败回退。当 Agent 调用工具失败时不应该静默重试而应该明确返回失败原因让上层逻辑决定是换方式重试、降级到人工处理还是直接终止。实践中可以在系统提示词里加上一条规则如果工具调用连续两次失败停止当前方案输出失败原因并请求用户决策。Agent 场景下的 LLM Etiquette本质上就是为模型设计一套“护栏”。模型在护栏内探索没问题但超出护栏时必须停下来。6. 精度选择 Etiquette用合适的精度跑合适的任务如果你的工作步骤涉及本地部署模型、微调或推理加速那一定会遇到精度选择问题。相关热词里反复出现的 fp16、fp32、bf16 问题其实就是 LLM 使用规范中硬件资源层面的“礼仪”问题——不要浪费算力也不要因为精度设置不当而损坏输出质量。6.1 fp16、fp32、bf16 到底有什么区别fp3232 位浮点数精度高、表示范围大但显存占用大、计算速度相对慢。fp1616 位半精度显存占用减半、速度更快但可表示的数值范围比 fp32 小大数容易溢出、小数容易下溢。bf1616 位“脑浮点”指数范围与 fp32 相同但尾数位数更少。这意味着它不容易溢出但精度比 fp16 略低。对于深度神经网络训练和推理来说bf16 往往是更稳妥的选择。精度显存占用数值范围精度适用场景fp32高大高训练基准、调试、精度敏感场景fp16中小中显存受限、支持良好的推理场景bf16中大中偏低大模型推理与训练首选6.2 不同场景怎么选如果你在跑大模型的推理服务且硬件支持 bf16通常优先使用 bf16因为它兼顾了显存节省和数值稳定性。如果你的硬件对 fp16 的优化更好可以实测对比。如果任务对数值精度非常敏感比如某些科学计算场景就不要为了省显存盲目降精度。6.3 代码示例按硬件能力动态选择精度下面示例展示加载模型时如何根据硬件能力选择精度类型。注意版本和 API 以实际环境为准这里演示的是通用思路。# 文件路径load_model.py import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_path your-llm-model tokenizer AutoTokenizer.from_pretrained(model_path) # 优先使用 bf16其次使用 fp16最后使用 fp32 if torch.cuda.is_available() and torch.cuda.is_bf16_supported(): torch_dtype torch.bfloat16 elif torch.cuda.is_available(): torch_dtype torch.float16 else: torch_dtype torch.float32 model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch_dtype, device_mapauto )在推理场景中切换精度后一定要做一轮回归测试比较同一组 Prompt 的输出质量。不要只看“能不能跑起来”还要留意极端输入下有没有出现 NaN 或剧烈质量下降。7. 知识库与 LLM 协作的 Etiquette知识库问答是当前 LLM 落地最广泛的方向之一。社区里也流行用 LLM 配合个人知识库工具搭建第二大脑比如结合笔记软件与 LLM 插件实现问答式检索。典型的实现路径是将文档切片对切片做向量化用户提问时做相似度检索再把检索结果交给 LLM 生成答案。这个流程本质上就是 RAG。RAG 场景下的 LLM Etiquette重点是原材料的质量和检索的纪律。LLM 只是一个阅读者你喂给它什么材料它就基于什么材料回答。如果准备阶段不认真后面再怎么调 Prompt 也救不回来。7.1 文档切分尊重语义边界不少人直接把整份 PDF 按固定字符数硬切成片段结果把一句话拆成了两半。更合理的做法是尽量按标题、段落、句子等语义边界切分让每个片段保持相对完整的意思。切分粒度也要和后续检索方式匹配太粗会混入无关内容太细会丢失上下文。7.2 检索结果不是越全越好检索返回的 Top K 结果里往往只有前几个是真正相关的后面的会逐渐偏离。盲目把所有结果都交给模型等于故意往上下文里塞噪声。更好的方式是设置一个相似度阈值低于阈值的片段直接丢弃。7.3 代码示例带阈值过滤的知识库查询下面是一个简化的知识库查询函数关键点是过滤低分结果并在没有合格材料时如实返回“未找到”而不是让模型强行作答。# 文件路径rag_query.py def query_knowledge_base(question, embedder, vector_index, top_k5, min_score0.6): query_vec embedder.embed_query(question) results vector_index.similarity_search_with_score(query_vec, ktop_k) # 过滤相似度过低的片段避免模型基于不相关内容作答 relevant [(doc, score) for doc, score in results if score min_score] if not relevant: return 知识库中未找到相关材料请补充资料后重试。 # 按相关度排序分数接近的按原顺序拼接 relevant.sort(keylambda x: x[1], reverseTrue) return \n\n.join(doc.page_content for doc, _ in relevant)7.4 给答案加引用源在生产环境里知识库问答必须要求模型标注答案来源。你可以在系统提示词里写“每条结论后标注参考文档编号如果没有对应文档支撑回答‘知识库未覆盖’”。这样既方便用户核验也方便你追踪模型是否答非所问。知识库协作的礼仪本质上是诚实原则材料里有的准确回答材料里没有的明确告知不确定的不强行猜测。这是降低 LLM 幻觉最有效的手段之一。8. 常见问题与排查方法实践过程中会遇到各种问题。下面整理了一份高频问题排查表覆盖 Prompt、上下文、Agent、精度和知识库场景。问题现象可能原因排查方式解决方案模型输出“一本正经胡说八道”提示词没有给“不知道”的出口或上下文中没有足够依据检查提示词是否允许拒绝回答检查知识库检索结果是否为空增加“信息不足时回答不知道”规则过滤低相关检索结果输出格式不稳定提示词没有严格指定输出格式或温度参数太高查看每次输出的原始内容对比格式差异将格式说明移到提示词末尾并配示例把 temperature 调到 0 附近上下文变长后效果明显下降关键信息被大量无关内容淹没统计单次请求的 Token 构成看参考层占比设置上下文预算动态截断并优先保留最相关片段Agent 反复调用工具不停止缺少迭代上限和终止条件查看 Agent 日志中的工具调用序列设置 max_iterations定义“完成”信号超出后强制终止切换 fp16/bf16 后输出质量下降精度设置未与任务匹配或该硬件下特定精度不稳定用同一组测试集分别跑 fp32 和切换后精度对比结果优先用 bf16回归测试不达标时回退 fp32知识库问答答非所问文档切分破坏语义或检索阈值过低打印命中的片段和相似度分数按标题/段落边界重新切分提高相似度阈值排错的基本原则是先看输入再看模型最后才怀疑代码。绝大多数 LLM 应用问题都可以追溯到输入信息组织不当。调试时建议先把完整的请求日志打印出来包括系统提示词、用户提示词、检索片段、模型原始输出这样你才能准确判断问题发生在哪一层。另外强调一点涉及生产环境变更时一定要在测试环境验证并保留回滚方案。比如调整精度、更新系统提示词、修改 Agent 工具权限都应该走正常的发布流程不要直接在线上改。9. 团队落地与最佳实践如果想把 LLM Etiquette 从个人习惯升级为团队规范下面几点值得优先落地。9.1 Prompt 版本管理与评审把 Prompt 当作代码来管理。建议放在 Git 仓库中每次改动都记录版本标注改动理由和预期影响。评审时重点看三个问题输出格式是否明确、是否包含“信息不足时怎么办”的兜底规则、是否存在安全隐患。Prompt 改动的回归测试可以固化为一组样例每次变更后自动跑一遍。9.2 日志与链路追踪在生产环境里至少记录每次请求的完整输入 Token 数、模型参数、响应耗时、输出摘要。如果是 Agent 场景还要记录工具调用序列。没有日志你根本无法定位一个偶发问题。建议在日志里生成 request_id把一次完整交互从入口到出口串起来。9.3 安全与合规底线使用 LLM 时必须遵守几个基本底线不把敏感个人数据、密钥、内部未公开资料直接发送给外部模型服务对 Agent 可访问的系统和数据范围做最小权限配置模型输出涉及删除、转账、发送消息等高风险操作时必须有人工确认环节。不要相信模型会自己判断“什么话不能说”边界要在系统层面强行控制。9.4 一套小型团队规范模板下面是一个可以直接复制修改的规范模板# LLM 使用规范团队内部 ## Prompt 编写 - 必须区分 system prompt 与 user prompt - 必须指定输出格式并给出一个示例 - 必须提供“信息不足”时的兜底规则 - 禁止在 Prompt 中包含未脱敏的敏感信息 ## 上下文管理 - 单次请求需设置 Token 预算上限 - 参考资料按相关度排序超过预算的直接截断 - 不把整篇文档塞入上下文 ## Agent 开发 - 必须配置工具白名单和迭代上限 - 高风险操作必须要求人工确认 - Agent 连续失败两次后必须停止并转人工 ## 模型部署 - 优先使用 bf16切换精度后必须回归测试 - 生产环境变更必须走测试与回滚流程 - 所有请求保留日志包含 request_id这套模板的价值在于把本文讲的各类规范浓缩成了可执行的检查项。你可以根据团队情况增删但关键是不让它成为一纸空文——最好把它接进代码评审清单和发布流程里。建立 LLM Etiquette 的过程本质上是在把不可控的概率输出逐步改造成一套可测试、可回滚、可审计的工程系统。模型能力每天都在进步但输入信息秩序的价值不会消失。你越早建立这套规范后续在 Agent、知识库、微调这些方向上的探索就会越省力。下一步建议你从一个小任务开始选一个团队里最高频的 LLM 调用场景按本文的规范重构 Prompt 和上下文逻辑加上日志和版本管理跑一轮回归对比。你会发现很多之前“时好时坏”的问题其实是规范和系统设计的问题。 LLM Etiquette：大模型协作规范与工程实战指南
上周帮一个团队评审大模型接入方案时我看到了一个非常典型的现象同一个 API、同一个模型、同样的预算不同开发者做出来的效果差距非常大。有人能用几段稳定 Prompt 跑出一条可复用的任务流有人花了三天还在跟模型的“一本正经胡说八道”搏斗。问题通常不在模型而在于我们是否理解它的工作方式是否建立了正确的协作边界。大语言模型不是一个“问一句就能拿答案”的搜索框它更像一个能力很强、但需要你交代清楚背景、边界和输出格式的协作者。这套协作规则我称之为LLM Etiquette——使用大语言模型时的礼仪与规范。这篇文章不打算讲某个具体框架的完整教程而是想系统梳理一套能迁移到日常开发中的 LLM 使用规范。无论你是在调 Prompt、做 Agent、搭知识库问答还是在做模型微调与推理部署这套规范都能帮你减少返工、提高输出稳定性。文章会穿插代码示例、参数对比和排查清单你可以直接把它当作一份团队内部的 LLM 协作手册来用。1. 为什么需要 LLM Etiquette从“协作失序”说起先看三个真实场景。场景一同一个 Prompt不同人用效果不一样。A 工程师写的是“帮我总结这段日志”B 工程师写的是“你现在是一名 SRE 工程师请分析下面这段来自生产环境的异常日志按时间顺序列出根因假设给出每个假设的证据链最后输出排查建议。如果证据不足请直接说证据不足不要猜测”。结果是 B 工程师拿到了一份可以直接贴进故障报告的分析而 A 工程师得到的是一段含糊的概述。两个人用的模型完全一样差距在于输入信息的组织方式。场景二上下文越长效果反而越差。产品经理说“模型不是支持 128K 上下文吗那把产品文档全部塞进去不就行了”。结果模型开始遗漏关键细节甚至被文档里的过期信息带偏。大上下文窗口只是能力上限不等于你把全部信息倒给它就能得到更好的结果。信息一多噪声跟着多模型没法判断你真正在乎什么。场景三Agent 跑着跑着就失控了。一个自动化工单 Agent 在调用搜索工具时由于返回结果不理想它在一个错误分支上反复重试最终把 API 调用额度耗掉了一大半而且每次重试都在用一个相似的错误前提推理。原因是这个 Agent 只被赋予了“完成任务”的目标却没有被告知“什么时候应该停下来”。这三个场景指向同一个结论LLM 输出质量 输入信息秩序 × 模型能力。模型能力是基础我们短期内改变不了但输入信息秩序是我们可以控制的。LLM Etiquette 的本质就是建立一套输入信息秩序让模型在明确的边界内发挥能力而不是在混沌中碰运气。它真正降低的是调试验证成本。没有规范时一次 Prompt 改动可能引发连锁反应有了规范你能清楚地知道问题是出在指令、上下文、工具权限还是模型本身。这篇文章适合正在做 Prompt 工程、Agent 开发、RAG 应用、模型微调或 API 集成的开发者也适合需要在团队里统一 LLM 使用方式的负责人。2. 核心概念理解 LLM 的输入输出规则在谈礼仪之前先理解模型的基本工作方式。下面几个概念是所有使用规范的基础。Token 与上下文窗口。Token 是模型处理文本的最小单位。中文场景下1 个汉字大约是 1 到 2 个 Token1 个英文单词约 1 到 2 个 Token。上下文窗口是模型一次能接收的最大 Token 数。窗口越大模型能看到的材料越多但不意味着它能把所有信息用得更好。temperature 与采样参数。temperature 控制输出的随机性。值越低输出越确定适合代码生成、数据抽取值越高输出越多样适合创意写作。与之配套的还有 top_p、top_k它们影响模型从候选词中选择下一个词的方式。对于大多数工程场景建议把 temperature 调低比如 0 到 0.3 之间优先保证稳定性。system prompt 与 user prompt。系统提示词负责设定角色的长期行为和固定规则用户提示词负责描述当次任务。两者分离的目的是让稳定规则和动态需求互不干扰。下面是这些概念对使用规范的实际影响概念通俗理解对使用规范的影响Token模型计费与输入长度的最小单位需要管理输入长度避免无效内容占用窗口上下文窗口模型一次能“看到”的内容范围不是越长越好要分主次放置信息temperature输出随机性控制旋钮工程场景建议调低保证输出稳定system prompt给模型设定的长期身份与规则适合放不经常变化的约束条件user prompt用户当次提交的任务描述适合放动态需求、输入数据和输出要求理解了这些概念后你会发现 LLM Etiquette 的很多规则其实是在跟模型的机制对齐。模型没有人类的“常识判断能力”它只会按照你给出的信息权重来作答。你把什么放进上下文、放在哪个位置、用怎样的结构呈现都会直接影响结果。3. Prompt Etiquette把需求说清楚Prompt 是与 LLM 交互最基础的方式也是大多数团队最早遭遇挫败的地方。很多人的第一反应是“模型效果差”但拆开看往往是 Prompt 本身写得含糊。3.1 一个好的 Prompt 有三个特征第一是具体。不要问“帮我看看这段代码”而要问“请检查这段代码中的 SQL 注入风险并给出修复建议”。具体意味着模型不需要替你猜测意图。第二是结构化。用分段、编号、列表把任务目标、输入数据、输出格式分开。模型在处理结构清晰的输入时更容易遵循指定的输出格式。第三是可验证。你要在 Prompt 里定义什么叫做“完成”。例如“输出必须是一个 JSON 对象”“如果信息不足回复‘信息不足’”。这样你可以在程序里做结果校验而不是靠肉眼判断。3.2 一个可复制的 Prompt 模板下面是一个可以复用的代码评审 Prompt 构建示例。它把角色、任务、输入、输出格式、约束拆分清楚。# 文件路径prompt_builder.py def build_review_prompt(code_snippet: str) - str: system_prompt 你是一名资深后端工程师负责代码评审。 你擅长发现安全风险、性能问题和可维护性隐患。 回答时要保持客观不夸奖代码只输出问题和建议。 user_prompt f 请评审以下代码片段 {code_snippet} 请按以下格式输出 【问题级别】阻断 / 建议 / 可选 【问题描述】不超过 50 字 【修改建议】给出关键修改方向或示意代码 如果代码没有明显问题仅输出通过。 return system_prompt \n\n user_prompt在这个示例中system prompt 负责设定评审者身份和回答风格user prompt 负责描述本次任务、给出输入、约束输出格式。这样做的好处是系统提示词可以沉淀为团队公共资源用户提示词只承载变化的部分两者便于分别维护和测试。3.3 需要避免的 Prompt 反模式常见反模式包括一次问多个不相关的问题导致模型只回答最后一个没有指定输出格式导致每次返回结构都不一样在 Prompt 中表达情绪或施压例如“你最好给我正确答案”这不会提高正确率没有给“不知道”的出口导致模型被迫编造。更稳妥的做法是如果你需要模型在信息不足时承认不确定就在 Prompt 里明确写“如果信息不足请回答不知道不要猜测”。这相当于主动为模型设置了一个安全的默认行为能显著减少幻觉。4. 上下文管理 EtiquetteToken 是稀缺资源大模型的上下文窗口是尺寸优先的资源。表面上 128K 很充裕但大量实践表明上下文越长模型越容易忽略关键信息。这不是玄学而是注意力机制的自然结果——当重要信息被淹没在大量无关文本中时模型很难抓住重点。4.1 上下文不是越长越好上下文过长会带来三个问题。第一是噪声干扰无关信息越多模型越容易被带偏第二是位置偏差模型对上下文开头和结尾的内容通常更敏感夹在中间的内容容易被忽略第三是成本输入 Token 是要付费的无效内容越多账单越高。4.2 信息分层策略可以把上下文按稳定程度分成三层系统层放置长期有效的规则、身份设定、禁止事项。这一层不随任务变化。任务层描述当次要做什么包括任务目标和输出格式。参考层只放与当次任务相关的资料片段并做数量和质量控制。这种分层方式能让模型更容易找到关键信息。比如在 RAG 应用中不要把整篇文档塞进去而是先做检索、截断、排序只保留最相关的片段。4.3 代码示例动态截断与排序下面这段代码演示了如何从检索结果中构建带预算上限的上下文。它按可用 Token 预算动态截断而不是把所有结果都拼接进去。# 文件路径context_builder.py def build_context(retrieved_chunks, max_tokens1500, separator\n\n): 将检索到的文本片段拼接为上下文。 这里用字符数粗估 Token 数实际项目应使用模型的分词器精确计算。 # 粗略估算中文场景下 1 个 Token 约等于 1.5 到 2 个字符 char_budget max_tokens * 3 selected [] used 0 for chunk in retrieved_chunks: size len(chunk) if used size char_budget: break selected.append(chunk) used size return separator.join(selected)关键的逻辑是设置预算、按序挑选、超出即停。如果检索结果有 20 个片段但预算只够放 6 个那就只放 6 个。这样既避免了上下文过载又保证了模型能集中处理最重要的信息。在实际项目中还可以在拼接时对片段按相关度排序把最相关的内容放在上下文开头和结尾——因为那是模型注意力更强的位置。5. Agent 场景 Etiquette边界比自由更重要Agent 是 LLM 应用里最让人兴奋、也最容易失控的方向。一个 Agent 拥有工具调用、多步推理、记忆管理能力但能力越多越需要规范约束。LLM Etiquette 在 Agent 场景中的核心原则只有一条边界比自由更重要。5.1 Agent 为什么会失控失控通常有几个原因没有限制工具调用的次数和范围Agent 可以在错误分支上反复重试没有设定终止条件Agent 会一直推理到超出预期没有人工确认机制Agent 执行了不可逆操作后才被发现。本质上模型是按概率生成下一步动作的它没有“及时止损”的本能。这个止损机制需要由开发者在系统设计层面加上。5.2 边界设置工具白名单、迭代上限、终止条件这里给出一个 Agent 配置的示例。重点不是某个框架的具体 API而是一组可迁移的约束项# 文件路径agent_config.py agent_config { # 工具白名单只允许使用这几个工具其余一律拒绝 tools: [search, calculator], # 允许访问的域名白名单避免 Agent 越权抓取 allowed_domains: [docs.example.com], # 最大迭代轮数超过后强制终止防止死循环 max_iterations: 3, # 终止条件一旦 Agent 输出答案标记立即停止 stop_after: [answer], # 高风险操作需要人工确认 require_human_confirm: [delete, send_email, transfer_money] }这些配置项的意图很清楚工具白名单缩小了 Agent 的行动面迭代上限锁死了推理轮数终止条件告诉它“什么时候算完成”人工确认给了不可逆操作一个安全阀。加上这些约束后Agent 的行为会明显更可控出 bug 时也更容易复现。5.3 失败回退机制另一个容易被忽略的细节是失败回退。当 Agent 调用工具失败时不应该静默重试而应该明确返回失败原因让上层逻辑决定是换方式重试、降级到人工处理还是直接终止。实践中可以在系统提示词里加上一条规则如果工具调用连续两次失败停止当前方案输出失败原因并请求用户决策。Agent 场景下的 LLM Etiquette本质上就是为模型设计一套“护栏”。模型在护栏内探索没问题但超出护栏时必须停下来。6. 精度选择 Etiquette用合适的精度跑合适的任务如果你的工作步骤涉及本地部署模型、微调或推理加速那一定会遇到精度选择问题。相关热词里反复出现的 fp16、fp32、bf16 问题其实就是 LLM 使用规范中硬件资源层面的“礼仪”问题——不要浪费算力也不要因为精度设置不当而损坏输出质量。6.1 fp16、fp32、bf16 到底有什么区别fp3232 位浮点数精度高、表示范围大但显存占用大、计算速度相对慢。fp1616 位半精度显存占用减半、速度更快但可表示的数值范围比 fp32 小大数容易溢出、小数容易下溢。bf1616 位“脑浮点”指数范围与 fp32 相同但尾数位数更少。这意味着它不容易溢出但精度比 fp16 略低。对于深度神经网络训练和推理来说bf16 往往是更稳妥的选择。精度显存占用数值范围精度适用场景fp32高大高训练基准、调试、精度敏感场景fp16中小中显存受限、支持良好的推理场景bf16中大中偏低大模型推理与训练首选6.2 不同场景怎么选如果你在跑大模型的推理服务且硬件支持 bf16通常优先使用 bf16因为它兼顾了显存节省和数值稳定性。如果你的硬件对 fp16 的优化更好可以实测对比。如果任务对数值精度非常敏感比如某些科学计算场景就不要为了省显存盲目降精度。6.3 代码示例按硬件能力动态选择精度下面示例展示加载模型时如何根据硬件能力选择精度类型。注意版本和 API 以实际环境为准这里演示的是通用思路。# 文件路径load_model.py import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_path your-llm-model tokenizer AutoTokenizer.from_pretrained(model_path) # 优先使用 bf16其次使用 fp16最后使用 fp32 if torch.cuda.is_available() and torch.cuda.is_bf16_supported(): torch_dtype torch.bfloat16 elif torch.cuda.is_available(): torch_dtype torch.float16 else: torch_dtype torch.float32 model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch_dtype, device_mapauto )在推理场景中切换精度后一定要做一轮回归测试比较同一组 Prompt 的输出质量。不要只看“能不能跑起来”还要留意极端输入下有没有出现 NaN 或剧烈质量下降。7. 知识库与 LLM 协作的 Etiquette知识库问答是当前 LLM 落地最广泛的方向之一。社区里也流行用 LLM 配合个人知识库工具搭建第二大脑比如结合笔记软件与 LLM 插件实现问答式检索。典型的实现路径是将文档切片对切片做向量化用户提问时做相似度检索再把检索结果交给 LLM 生成答案。这个流程本质上就是 RAG。RAG 场景下的 LLM Etiquette重点是原材料的质量和检索的纪律。LLM 只是一个阅读者你喂给它什么材料它就基于什么材料回答。如果准备阶段不认真后面再怎么调 Prompt 也救不回来。7.1 文档切分尊重语义边界不少人直接把整份 PDF 按固定字符数硬切成片段结果把一句话拆成了两半。更合理的做法是尽量按标题、段落、句子等语义边界切分让每个片段保持相对完整的意思。切分粒度也要和后续检索方式匹配太粗会混入无关内容太细会丢失上下文。7.2 检索结果不是越全越好检索返回的 Top K 结果里往往只有前几个是真正相关的后面的会逐渐偏离。盲目把所有结果都交给模型等于故意往上下文里塞噪声。更好的方式是设置一个相似度阈值低于阈值的片段直接丢弃。7.3 代码示例带阈值过滤的知识库查询下面是一个简化的知识库查询函数关键点是过滤低分结果并在没有合格材料时如实返回“未找到”而不是让模型强行作答。# 文件路径rag_query.py def query_knowledge_base(question, embedder, vector_index, top_k5, min_score0.6): query_vec embedder.embed_query(question) results vector_index.similarity_search_with_score(query_vec, ktop_k) # 过滤相似度过低的片段避免模型基于不相关内容作答 relevant [(doc, score) for doc, score in results if score min_score] if not relevant: return 知识库中未找到相关材料请补充资料后重试。 # 按相关度排序分数接近的按原顺序拼接 relevant.sort(keylambda x: x[1], reverseTrue) return \n\n.join(doc.page_content for doc, _ in relevant)7.4 给答案加引用源在生产环境里知识库问答必须要求模型标注答案来源。你可以在系统提示词里写“每条结论后标注参考文档编号如果没有对应文档支撑回答‘知识库未覆盖’”。这样既方便用户核验也方便你追踪模型是否答非所问。知识库协作的礼仪本质上是诚实原则材料里有的准确回答材料里没有的明确告知不确定的不强行猜测。这是降低 LLM 幻觉最有效的手段之一。8. 常见问题与排查方法实践过程中会遇到各种问题。下面整理了一份高频问题排查表覆盖 Prompt、上下文、Agent、精度和知识库场景。问题现象可能原因排查方式解决方案模型输出“一本正经胡说八道”提示词没有给“不知道”的出口或上下文中没有足够依据检查提示词是否允许拒绝回答检查知识库检索结果是否为空增加“信息不足时回答不知道”规则过滤低相关检索结果输出格式不稳定提示词没有严格指定输出格式或温度参数太高查看每次输出的原始内容对比格式差异将格式说明移到提示词末尾并配示例把 temperature 调到 0 附近上下文变长后效果明显下降关键信息被大量无关内容淹没统计单次请求的 Token 构成看参考层占比设置上下文预算动态截断并优先保留最相关片段Agent 反复调用工具不停止缺少迭代上限和终止条件查看 Agent 日志中的工具调用序列设置 max_iterations定义“完成”信号超出后强制终止切换 fp16/bf16 后输出质量下降精度设置未与任务匹配或该硬件下特定精度不稳定用同一组测试集分别跑 fp32 和切换后精度对比结果优先用 bf16回归测试不达标时回退 fp32知识库问答答非所问文档切分破坏语义或检索阈值过低打印命中的片段和相似度分数按标题/段落边界重新切分提高相似度阈值排错的基本原则是先看输入再看模型最后才怀疑代码。绝大多数 LLM 应用问题都可以追溯到输入信息组织不当。调试时建议先把完整的请求日志打印出来包括系统提示词、用户提示词、检索片段、模型原始输出这样你才能准确判断问题发生在哪一层。另外强调一点涉及生产环境变更时一定要在测试环境验证并保留回滚方案。比如调整精度、更新系统提示词、修改 Agent 工具权限都应该走正常的发布流程不要直接在线上改。9. 团队落地与最佳实践如果想把 LLM Etiquette 从个人习惯升级为团队规范下面几点值得优先落地。9.1 Prompt 版本管理与评审把 Prompt 当作代码来管理。建议放在 Git 仓库中每次改动都记录版本标注改动理由和预期影响。评审时重点看三个问题输出格式是否明确、是否包含“信息不足时怎么办”的兜底规则、是否存在安全隐患。Prompt 改动的回归测试可以固化为一组样例每次变更后自动跑一遍。9.2 日志与链路追踪在生产环境里至少记录每次请求的完整输入 Token 数、模型参数、响应耗时、输出摘要。如果是 Agent 场景还要记录工具调用序列。没有日志你根本无法定位一个偶发问题。建议在日志里生成 request_id把一次完整交互从入口到出口串起来。9.3 安全与合规底线使用 LLM 时必须遵守几个基本底线不把敏感个人数据、密钥、内部未公开资料直接发送给外部模型服务对 Agent 可访问的系统和数据范围做最小权限配置模型输出涉及删除、转账、发送消息等高风险操作时必须有人工确认环节。不要相信模型会自己判断“什么话不能说”边界要在系统层面强行控制。9.4 一套小型团队规范模板下面是一个可以直接复制修改的规范模板# LLM 使用规范团队内部 ## Prompt 编写 - 必须区分 system prompt 与 user prompt - 必须指定输出格式并给出一个示例 - 必须提供“信息不足”时的兜底规则 - 禁止在 Prompt 中包含未脱敏的敏感信息 ## 上下文管理 - 单次请求需设置 Token 预算上限 - 参考资料按相关度排序超过预算的直接截断 - 不把整篇文档塞入上下文 ## Agent 开发 - 必须配置工具白名单和迭代上限 - 高风险操作必须要求人工确认 - Agent 连续失败两次后必须停止并转人工 ## 模型部署 - 优先使用 bf16切换精度后必须回归测试 - 生产环境变更必须走测试与回滚流程 - 所有请求保留日志包含 request_id这套模板的价值在于把本文讲的各类规范浓缩成了可执行的检查项。你可以根据团队情况增删但关键是不让它成为一纸空文——最好把它接进代码评审清单和发布流程里。建立 LLM Etiquette 的过程本质上是在把不可控的概率输出逐步改造成一套可测试、可回滚、可审计的工程系统。模型能力每天都在进步但输入信息秩序的价值不会消失。你越早建立这套规范后续在 Agent、知识库、微调这些方向上的探索就会越省力。下一步建议你从一个小任务开始选一个团队里最高频的 LLM 调用场景按本文的规范重构 Prompt 和上下文逻辑加上日志和版本管理跑一轮回归对比。你会发现很多之前“时好时坏”的问题其实是规范和系统设计的问题。