拓冰网站定制 
这次我们不聊某个具体的模型而是聊一个经常被忽略、但直接影响产出质量的话题LLM Etiquette。直译过来是“大语言模型礼仪”但它并不是要求你对模型说“请”和“谢谢”而是指在使用大语言模型时从提示词书写、API 调用、资源占用、团队协作到合规边界的一整套行为约定。很多开发者在本地部署过开源模型也在公网 API 上调过 GPT 类接口但真正把“如何正确使用 LLM”这件事工程化的人并不多。结果就是同一个问题不同人问出来的回答质量差异巨大同一个 API有人频繁超时或被限流同一个提示词换个运行环境就完全不稳定。这些问题大多不是模型本身造成的而是缺少一套统一的 LLM 使用规范。LLM Etiquette 要解决的就是“怎么用 LLM 才稳定、可复现、可协作、可审计”的问题。它既包含提示词层面的输入规范也包含 API 调用层面的限流与重试策略还包含多人共用服务时的资源分配和成本管理。换句话说它更像一套面向 LLM 应用开发者和使用者的最佳实践集合。本文会从提示词礼仪讲起逐步展开 API 调用的工程规范、团队协作中的资源管理、合规与安全边界以及 LLM Agent 和 LLM 框架中如何落地这些约束。如果你是刚接触 LLM 的开发者或者正在把大模型接入自己的工具链这篇文章可以直接当清单用。1. LLM Etiquette 核心能力速览先说清楚LLM Etiquette 不是一个可下载的软件包也不是一个开源仓库而是一套可以落地的规范体系。为了让它的边界更清楚我用一张表把它拆开来看。规范维度覆盖内容落地方式是否依赖 GPU提示词礼仪角色设定、目标描述、约束条件、输出格式提示词模板、团队共享 Prompt 库否API 调用礼仪限流、超时、重试、错误处理、批量任务代码封装、网关配置否资源分配礼仪并发控制、配额管理、成本统计服务网关、队列、预算脚本否但受推理服务吞吐影响协作礼仪Prompt 版本管理、输出结果沉淀、知识库共享Git、LLM Wiki、团队文档否合规与安全边界敏感数据脱敏、版权授权、输出审查审批流程、审计日志否从这张表可以看到这套规范绝大多数内容不依赖 GPU 和具体模型品牌。无论你是本地用 llama.cpp 跑量化模型还是调用公网 API或者基于开源模型做 LoRA 微调LLM Etiquette 都可以套用。它的核心价值不是提升单次对话的“灵性”而是让整个使用过程变得可预期、可复现、可排查。实际落地时先解决提示词统一再解决 API 稳定性最后补团队协作和安全审计按这个顺序推进成本最低。2. 适用场景与使用边界LLM Etiquette 面向四类典型场景。第一类是个人开发者自己写脚本调用 LLM API 做文本总结、信息抽取或代码生成这时需要的是 API 调用规范避免被限流、避免超时导致任务中断。第二类是团队协作场景多个成员共用同一个模型服务如果没有配额和优先级约定很容易出现一个人跑批量任务占满所有并发其他人正常提问全部排队。第三类是产品集成场景把 LLM 接入业务系统比如客服助手、内容审核、文档解析这时必须输出可解析的结构化结果并设计失败降级路径。第四类是 LLM Agent 和自动化流程让模型自主调用工具、多轮规划这时需要在系统层面植入行为边界否则 Agent 可能反复尝试失败动作或循环消耗 token。使用边界同样要明确。LLM Etiquette 不适合用来解决模型能力本身的问题模型知识不够、推理能力弱、幻觉严重这些不是靠“礼貌”能救回来的。它也不适合替代模型微调。当业务对输出格式和专业领域准确性要求极高时正确做法是采集领域数据做 LLM 微调然后把规范作为微调数据整理的一部分。还有一个重要边界是合规涉及个人隐私、人脸、声音、未授权版权素材的内容任何礼仪规范都不能作为使用依据必须走授权流程。尤其是图像、语音、视频类生成任务必须在数据来源和输出用途上同时确认合法性。3. 提示词礼仪与大模型会话的第一步规范提示词是用户与 LLM 之间的输入接口。提示词写得混乱模型输出的随机性就会放大。所谓提示词礼仪本质上是通过固定的输入结构降低模型的理解成本从而让输出更稳定。3.1 角色、目标、约束、输出格式四位一体一个规范化的提示词建议包含四个部分角色、目标、约束、输出格式。角色让模型进入正确的知识范围目标告诉模型需要完成什么约束限制回答的方向和长度输出格式则保证结果可以被程序解析。很多开发者只写“帮我写一段 Python 代码”模型虽然能给出结果但代码风格、依赖版本、错误处理都不稳定。如果改成下面这种结构结果会明显可控。# 角色 你是一名资深后端工程师熟悉 Python 与分布式系统。 # 目标 帮我把下面的需求拆解成可执行的技术方案。 # 约束 - 方案需要可以直接落地不写空泛建议。 - 优先考虑开源组件。 - 输出长度控制在 300 字以内。 # 输入 需求...这个模板适用性很强。遇到复杂任务可以继续增加“背景信息”和“禁止事项”两个字段。背景信息用来补充模型不知道的上下文禁止事项用来提前规避已知的坑。比如调用公网 API 时加上“不要使用未经验证的第三方库”生成文案时加上“不要出现夸大承诺”。提示词结构一旦固定下来后续调参和排错都容易很多。3.2 信息密度与上下文管理第二个提示词礼仪是控制单次输入的信息密度。LLM 的上下文窗口是有限的虽然现在很多模型支持几十万 token 的长上下文但窗口越长检索准确率和响应速度都会下降。正确做法是只把当前任务必要的信息放进去无关历史一律截断。多轮对话时定期把前面对话压缩成摘要避免 token 无限膨胀。这里有一个建议给每个重要任务准备一份 system prompt把业务规则、回答风格、输出格式固定在里面用户输入只放每次变化的内容。上下文管理还有一层含义是避免“上下文污染”。如果模型需要在多份资料中找答案先把资料按相关性排序再拼接进提示词效果比一次性灌入全部资料好得多。对于长文档场景可以先做分段检索再基于检索结果生成回答。这其实就是 RAG 的基本思路也是 LLM Etiquette 在提示词层面的延伸。3.3 提示词模板的版本管理提示词写好之后不要只在聊天窗口里用应该沉淀成模板文件纳入版本管理。一个提示词就是一个可维护的代码资产。建议在一个目录下按任务类型组织模板例如prompts/qa/,prompts/summary/,prompts/code-review/。每个模板文件头部写明用途、适用模型、更新日期和已知注意事项。这样当模型版本升级导致输出风格变化时才能快速定位是提示词问题还是模型行为漂移。4. API 调用礼仪与工程规范提示词礼仪解决的是输入质量API 调用礼仪解决的是交互稳定性。不管调用开源模型本地部署的服务还是公网模型 API都必须处理限流、超时、重试、错误类型识别和批量任务这些问题。4.1 限流与超时策略公网模型 API 几乎都有速率限制单位时间内的请求数或 token 数超过阈值就会返回 429。本地部署的大模型服务同样有吞吐上限。合理的做法是在客户端做请求节流单次请求之间留出间隔并发数不超过服务端限制。超时设置也要分场景流式接口可以接受较长的总时长但连接超时和读取超时一般分别设置连接超时 10 到 30 秒读取超时根据任务复杂度和模型速度调整。4.2 重试与错误处理重试不是把请求无条件发第二次。需要根据状态码区分429 限流和 5xx 服务端错误可以重试4xx 参数错误重试没有意义。重试时要有退避策略指数退避是最常见的做法第一次等 1 秒第二次 2 秒第三次 4 秒防止雪崩。同时设置最大重试次数超过后进入失败队列而不是无限重试。下面是一个通用示例基于requests库封装了重试逻辑实际项目里可以直接按这个骨架改。import time import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry LLM_API_URL https://api.example.com/v1/chat/completions API_KEY your-api-key session requests.Session() retry Retry( total3, backoff_factor1.0, status_forcelist[429, 500, 502, 503, 504], ) adapter HTTPAdapter(max_retriesretry) session.mount(http://, adapter) session.mount(https://, adapter) def call_llm(prompt, max_tokens1024, temperature0.3): payload { model: your-model-name, messages: [ {role: system, content: 你是一个技术助手回答保持准确和简洁。}, {role: user, content: prompt} ], max_tokens: max_tokens, temperature: temperature, } response session.post( LLM_API_URL, headers{Authorization: fBearer {API_KEY}}, jsonpayload, timeout60, ) response.raise_for_status() return response.json() if __name__ __main__: result call_llm(用一句话解释什么是大模型幻觉) print(result[choices][0][message][content])请求返回后还要校验响应结构。很多模型在生成长文本时可能中途截断实际能用的内容不是完整结果。判断成功与否不能只看 HTTP 状态码还要检查响应体里是否包含预期字段、finish_reason是否为正常结束。如果finish_reason是length说明输出被 token 上限截断需要增大max_tokens或者让模型提前结束。4.3 批量任务的工程化设计批量任务是最容易把“LLM 使用不规范”暴露出来的场景。常见问题是大量请求同时发出、直接打到服务端导致限流任务没有持久化中途失败后全部重跑输出没有单独落盘程序一断结果就丢了。规范化的批量任务需要考虑四个点输入队列、并发控制、失败重试、结果落盘。建议用一个 JSON 配置文件管理批量任务参数把输入目录、输出目录、并发数、请求间隔、模型名都集中放在一起。{ batch: { input_dir: ./inputs, output_dir: ./outputs, max_concurrency: 2, request_interval_seconds: 1.0, max_retries: 3, model: your-model-name } }程序读取配置文件后按max_concurrency控制并发每完成一条任务立即写入输出文件。这样即使中途中断也可以根据已有输出跳过已完成的任务继续执行剩余部分。批量处理还需要日志每条任务的 prompt 版本、请求时间、响应状态、token 消耗都要记录下来方便事后分析失败原因和成本。5. 多人协作与团队场景的 LLM 礼仪当 LLM 从个人工具变成团队共享设施时问题就从“我怎么调用”变成了“我们怎么一起用”。多人协作场景下资源分配、知识沉淀和成本控制是最容易扯皮的三件事。5.1 共享服务的资源分配团队共用一个模型服务时要引入最基本的配额机制。可以按成员或按业务线分配每分钟最大请求数也可以通过服务网关限制单用户并发。否则就会出现某位同事在跑一个需要几个小时的数据清洗任务结果把服务并发全部占满其他成员的正常提问全部超时。解决思路是分优先级交互式请求优先批处理任务放低优先级队列。如果团队规模不大至少要在约定层面明确批量任务避开工作高峰时段执行。5.2 Prompt 与输出结果的版本沉淀团队里最常见的浪费是同一个提示词被每个人各写一遍。更好的做法是把已验证有效的提示词统一入库形成团队级 Prompt 仓库。这个仓库不需要复杂用 Git 管理即可目录结构按业务场景划分。结合热词里常被提到的 LLM Wiki 思路可以在团队知识库软件中建一个 LLM 使用专区把接口文档、提示词模板、常见问题、失败案例都放进去。这样一个成员调通一个复杂提示词后其他人不用重新踩坑。输出结果同样要管理。凡是用于训练、微调、评估的输出数据建议统一落库并记录对应的提示词版本和模型版本。这不仅是数据管理问题也是复现问题的前提。很多场景下你发现模型输出变差了但根本找不到当时用的是什么提示词和模型只能从头排查这就是规范缺失的代价。5.3 成本控制与用量统计大多数公网模型 API 按 token 计费本地部署则要考虑 GPU 算力成本。成本控制的第一步是计量。每个账号或每个业务申请一个独立 API Key通过后台日志统计每个 Key 的 token 消耗。有了计量数据再设置月度预算和告警阈值。更细一层是在提示词层面控制限定输出长度、减少多余的历史对话、对长文本先做检索再送模型都能直接减少 token 消耗。6. 合规、隐私与内容安全边界LLM Etiquette 里最不能妥协的一部分是合规与安全。规范可以优化效率和成本但不能作为踩红线的理由。6.1 数据分级与敏感信息处理先给输入数据分级。公开资料、内部非敏感文档、个人敏感信息、商业机密这四类的处理方式完全不同。凡是包含手机号、身份证号、住址、人脸、可识别个人身份的声音等敏感信息都不应该在未经脱敏和授权的情况下直接送入公网模型服务。如果业务确实需要优先选择本地部署模型或者先做字段级脱敏再调用。团队内部可以约定进入 LLM 服务的所有文本必须先经过一个脱敏中间层把已知敏感字段替换成占位符返回结果后再做还原。6.2 版权与肖像授权图像生成、视频生成、声音克隆类任务必须确认素材来源。没有取得授权的人脸图片、他人声音样本、商用版权图片和视频片段不能作为模型输入。即使模型输出的是全新内容只要训练或生成过程使用了未经授权的素材后续使用风险仍然存在。实际项目里建议建立素材审批表记录每个素材的来源、授权范围、使用期限和负责人。发布或商用前由人工对输出内容做最终复核。6.3 输出审查与审计LLM 的输出并不总是可信的。涉及医疗、法律、金融等高风险领域时模型输出只能作为辅助参考不能直接作为决策依据。团队应建立输出复核机制自动化规则过滤 人工抽查。自动规则主要过滤明显违规词汇和异常格式人工抽查则针对内容质量和事实准确性。对于需要审计的场景所有请求和响应都要留日志至少保留提示词版本、模型版本、参数配置和结果记录一旦出现问题可以回溯。7. 从 LLM 到 LLM Agent 与 LLM 框架规范如何在工程中落地LLM 本身只是一个生成接口但实际工程中它往往被嵌入到 LLM Agent 和 LLM 框架里。Agent 让模型自主规划并调用工具框架负责编排整个流程。这时候LLM Etiquette 就不只是提示词层面的约定而是要变成系统里的硬约束。7.1 Agent 场景的行为边界LLM Agent 的典型问题是“失控循环”模型反复调用同一个失败工具或者在一个任务上消耗大量 token 却不收敛。规范的方法是在 Agent 的外部接入控制层限制最大工具调用次数、设置单轮任务超时、对每个工具调用做入参校验。还要在提示词里明确告知 Agent什么可以做、什么不能做、拿不准时直接询问用户。这些约束不是靠技巧让模型“听话”而是通过系统代码做兜底。工具调用返回错误时Agent 应该判断是临时异常还是永久失败避免无意义重试。7.2 在 LLM 框架层面固化规范使用 LLM 框架时规范应该做到配置化。请求超时、重试次数、并发上限这些参数不要散落在业务代码里而是统一放在框架配置层。用 YAML 或 JSON 维护一份环境配置不同环境使用不同参数测试环境可以并发高一点生产环境则更保守。框架层面还可以统一封装日志埋点把 token 消耗、响应延迟、错误码自动上报到监控系统。这样做的好处是业务开发不需要关心底层规范细节只要按配置接入即可。7.3 微调与数据集的礼仪如果团队准备对开源模型做 LLM 微调数据集的规范同样重要。训练数据要标注来源、版权状态和筛选标准不能用未授权数据做训练。数据清洗时去掉重复、错误和低质量样本微调后要做对比评测确认原始能力没有被破坏。精度问题也值得注意FP16、BF16、FP32 的选择会直接影响显存占用和输出质量。多人共用训练资源时要约定统一精度和并发策略否则同一份微调代码在不同设备上的结果可能不一致。8. 常见问题与排查方法LLM 使用中的问题通常不是单一原因造成的下面把高频问题和排查思路整理成一张表。问题现象可能原因排查方式解决方案接口频繁返回 429请求频率超过服务端限制查看服务端返回的限流头信息和请求日志降低并发、增加请求间隔、启用指数退避请求超时模型推理耗时太长或网络波动分阶段记录连接耗时和读取耗时调大读取超时、改用流式接口、简化 prompt输出内容不稳定prompt 过于模糊或缺少约束固定提示词模板对比多次输出增加角色、目标和输出格式约束长文本被截断max_tokens设置过小检查响应里的finish_reason增大max_tokens或调整输出策略批量任务中途失败进程崩溃或单条请求错误检查日志和已有输出文件任务持久化支持断点续跑多人共用服务时相互挤占缺少并发控制和配额查看服务端并发连接数增加网关限流和优先级队列同一条 prompt 在本地和远程结果不一致模型版本、精度或采样参数不同对比模型版本和生成参数统一模型版本和推理精度Agent 陷入死循环缺少最大步数和超时控制查看 Agent 工具调用日志外部控制循环次数和单步超时排查时有一个通用原则把问题分到层。先确认是网络层问题、服务端问题还是模型输出问题。网络层看状态码和延迟服务端看日志和资源占用模型输出看提示词与生成参数。分层排查能避免在一个已经正常的环节浪费大量时间。9. 最佳实践与落地建议把 LLM Etiquette 落地到实际项目不需要一次做完建议按阶段推进。第一阶段先建立最小规范。固定一套提示词模板统一 API 调用的超时和重试配置做好请求日志记录。这个阶段的目标是让单个开发者能稳定使用 LLM。第二阶段补充批量任务和错误处理。把批量任务持久化支持断点续跑重试加上退避策略输出结果按任务维度落盘。这个阶段的目标是让批处理任务上线后不会因为偶发错误导致全量返工。第三阶段团队协作和安全审计。搭建 Prompt 共享仓库统一模型服务入口加上配额和监控。这个阶段的目标是让多人协作时互不干扰且使用行为可追溯。每个阶段的推进顺序不要跳。如果第一批任务还没有稳定的重试机制先上团队配额只会让问题更复杂。另外所有规范文档和配置要放在团队仓库里让后来者有迹可循而不是靠口头约定。10. 总结与下一步LLM Etiquette 的价值在于把大模型使用从“凭感觉”变成“按规范”。提示词模板解决输出稳定性的问题API 调用规范解决服务可用性的问题团队资源分配解决协作冲突的问题合规与安全边界解决使用底线的问题。这四层合在一起才是完整的 LLM 使用礼仪。如果你今天只做一件事先选一个自己最常用的场景写一份固定格式的提示词模板然后给 API 调用加上超时和重试。这两个改动不需要任何额外硬件成本最低但效果最明显。如果已经过了这个阶段下一步就是设计批量任务的持久化队列把易失败点全部暴露出来再逐个解决。从最小规范开始逐步扩展LLM 才能真正成为稳定可靠的生产工具。建议收藏备用实际搭建时可以对照着逐项落地。 LLM Etiquette：大模型使用的工程规范与最佳实践
这次我们不聊某个具体的模型而是聊一个经常被忽略、但直接影响产出质量的话题LLM Etiquette。直译过来是“大语言模型礼仪”但它并不是要求你对模型说“请”和“谢谢”而是指在使用大语言模型时从提示词书写、API 调用、资源占用、团队协作到合规边界的一整套行为约定。很多开发者在本地部署过开源模型也在公网 API 上调过 GPT 类接口但真正把“如何正确使用 LLM”这件事工程化的人并不多。结果就是同一个问题不同人问出来的回答质量差异巨大同一个 API有人频繁超时或被限流同一个提示词换个运行环境就完全不稳定。这些问题大多不是模型本身造成的而是缺少一套统一的 LLM 使用规范。LLM Etiquette 要解决的就是“怎么用 LLM 才稳定、可复现、可协作、可审计”的问题。它既包含提示词层面的输入规范也包含 API 调用层面的限流与重试策略还包含多人共用服务时的资源分配和成本管理。换句话说它更像一套面向 LLM 应用开发者和使用者的最佳实践集合。本文会从提示词礼仪讲起逐步展开 API 调用的工程规范、团队协作中的资源管理、合规与安全边界以及 LLM Agent 和 LLM 框架中如何落地这些约束。如果你是刚接触 LLM 的开发者或者正在把大模型接入自己的工具链这篇文章可以直接当清单用。1. LLM Etiquette 核心能力速览先说清楚LLM Etiquette 不是一个可下载的软件包也不是一个开源仓库而是一套可以落地的规范体系。为了让它的边界更清楚我用一张表把它拆开来看。规范维度覆盖内容落地方式是否依赖 GPU提示词礼仪角色设定、目标描述、约束条件、输出格式提示词模板、团队共享 Prompt 库否API 调用礼仪限流、超时、重试、错误处理、批量任务代码封装、网关配置否资源分配礼仪并发控制、配额管理、成本统计服务网关、队列、预算脚本否但受推理服务吞吐影响协作礼仪Prompt 版本管理、输出结果沉淀、知识库共享Git、LLM Wiki、团队文档否合规与安全边界敏感数据脱敏、版权授权、输出审查审批流程、审计日志否从这张表可以看到这套规范绝大多数内容不依赖 GPU 和具体模型品牌。无论你是本地用 llama.cpp 跑量化模型还是调用公网 API或者基于开源模型做 LoRA 微调LLM Etiquette 都可以套用。它的核心价值不是提升单次对话的“灵性”而是让整个使用过程变得可预期、可复现、可排查。实际落地时先解决提示词统一再解决 API 稳定性最后补团队协作和安全审计按这个顺序推进成本最低。2. 适用场景与使用边界LLM Etiquette 面向四类典型场景。第一类是个人开发者自己写脚本调用 LLM API 做文本总结、信息抽取或代码生成这时需要的是 API 调用规范避免被限流、避免超时导致任务中断。第二类是团队协作场景多个成员共用同一个模型服务如果没有配额和优先级约定很容易出现一个人跑批量任务占满所有并发其他人正常提问全部排队。第三类是产品集成场景把 LLM 接入业务系统比如客服助手、内容审核、文档解析这时必须输出可解析的结构化结果并设计失败降级路径。第四类是 LLM Agent 和自动化流程让模型自主调用工具、多轮规划这时需要在系统层面植入行为边界否则 Agent 可能反复尝试失败动作或循环消耗 token。使用边界同样要明确。LLM Etiquette 不适合用来解决模型能力本身的问题模型知识不够、推理能力弱、幻觉严重这些不是靠“礼貌”能救回来的。它也不适合替代模型微调。当业务对输出格式和专业领域准确性要求极高时正确做法是采集领域数据做 LLM 微调然后把规范作为微调数据整理的一部分。还有一个重要边界是合规涉及个人隐私、人脸、声音、未授权版权素材的内容任何礼仪规范都不能作为使用依据必须走授权流程。尤其是图像、语音、视频类生成任务必须在数据来源和输出用途上同时确认合法性。3. 提示词礼仪与大模型会话的第一步规范提示词是用户与 LLM 之间的输入接口。提示词写得混乱模型输出的随机性就会放大。所谓提示词礼仪本质上是通过固定的输入结构降低模型的理解成本从而让输出更稳定。3.1 角色、目标、约束、输出格式四位一体一个规范化的提示词建议包含四个部分角色、目标、约束、输出格式。角色让模型进入正确的知识范围目标告诉模型需要完成什么约束限制回答的方向和长度输出格式则保证结果可以被程序解析。很多开发者只写“帮我写一段 Python 代码”模型虽然能给出结果但代码风格、依赖版本、错误处理都不稳定。如果改成下面这种结构结果会明显可控。# 角色 你是一名资深后端工程师熟悉 Python 与分布式系统。 # 目标 帮我把下面的需求拆解成可执行的技术方案。 # 约束 - 方案需要可以直接落地不写空泛建议。 - 优先考虑开源组件。 - 输出长度控制在 300 字以内。 # 输入 需求...这个模板适用性很强。遇到复杂任务可以继续增加“背景信息”和“禁止事项”两个字段。背景信息用来补充模型不知道的上下文禁止事项用来提前规避已知的坑。比如调用公网 API 时加上“不要使用未经验证的第三方库”生成文案时加上“不要出现夸大承诺”。提示词结构一旦固定下来后续调参和排错都容易很多。3.2 信息密度与上下文管理第二个提示词礼仪是控制单次输入的信息密度。LLM 的上下文窗口是有限的虽然现在很多模型支持几十万 token 的长上下文但窗口越长检索准确率和响应速度都会下降。正确做法是只把当前任务必要的信息放进去无关历史一律截断。多轮对话时定期把前面对话压缩成摘要避免 token 无限膨胀。这里有一个建议给每个重要任务准备一份 system prompt把业务规则、回答风格、输出格式固定在里面用户输入只放每次变化的内容。上下文管理还有一层含义是避免“上下文污染”。如果模型需要在多份资料中找答案先把资料按相关性排序再拼接进提示词效果比一次性灌入全部资料好得多。对于长文档场景可以先做分段检索再基于检索结果生成回答。这其实就是 RAG 的基本思路也是 LLM Etiquette 在提示词层面的延伸。3.3 提示词模板的版本管理提示词写好之后不要只在聊天窗口里用应该沉淀成模板文件纳入版本管理。一个提示词就是一个可维护的代码资产。建议在一个目录下按任务类型组织模板例如prompts/qa/,prompts/summary/,prompts/code-review/。每个模板文件头部写明用途、适用模型、更新日期和已知注意事项。这样当模型版本升级导致输出风格变化时才能快速定位是提示词问题还是模型行为漂移。4. API 调用礼仪与工程规范提示词礼仪解决的是输入质量API 调用礼仪解决的是交互稳定性。不管调用开源模型本地部署的服务还是公网模型 API都必须处理限流、超时、重试、错误类型识别和批量任务这些问题。4.1 限流与超时策略公网模型 API 几乎都有速率限制单位时间内的请求数或 token 数超过阈值就会返回 429。本地部署的大模型服务同样有吞吐上限。合理的做法是在客户端做请求节流单次请求之间留出间隔并发数不超过服务端限制。超时设置也要分场景流式接口可以接受较长的总时长但连接超时和读取超时一般分别设置连接超时 10 到 30 秒读取超时根据任务复杂度和模型速度调整。4.2 重试与错误处理重试不是把请求无条件发第二次。需要根据状态码区分429 限流和 5xx 服务端错误可以重试4xx 参数错误重试没有意义。重试时要有退避策略指数退避是最常见的做法第一次等 1 秒第二次 2 秒第三次 4 秒防止雪崩。同时设置最大重试次数超过后进入失败队列而不是无限重试。下面是一个通用示例基于requests库封装了重试逻辑实际项目里可以直接按这个骨架改。import time import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry LLM_API_URL https://api.example.com/v1/chat/completions API_KEY your-api-key session requests.Session() retry Retry( total3, backoff_factor1.0, status_forcelist[429, 500, 502, 503, 504], ) adapter HTTPAdapter(max_retriesretry) session.mount(http://, adapter) session.mount(https://, adapter) def call_llm(prompt, max_tokens1024, temperature0.3): payload { model: your-model-name, messages: [ {role: system, content: 你是一个技术助手回答保持准确和简洁。}, {role: user, content: prompt} ], max_tokens: max_tokens, temperature: temperature, } response session.post( LLM_API_URL, headers{Authorization: fBearer {API_KEY}}, jsonpayload, timeout60, ) response.raise_for_status() return response.json() if __name__ __main__: result call_llm(用一句话解释什么是大模型幻觉) print(result[choices][0][message][content])请求返回后还要校验响应结构。很多模型在生成长文本时可能中途截断实际能用的内容不是完整结果。判断成功与否不能只看 HTTP 状态码还要检查响应体里是否包含预期字段、finish_reason是否为正常结束。如果finish_reason是length说明输出被 token 上限截断需要增大max_tokens或者让模型提前结束。4.3 批量任务的工程化设计批量任务是最容易把“LLM 使用不规范”暴露出来的场景。常见问题是大量请求同时发出、直接打到服务端导致限流任务没有持久化中途失败后全部重跑输出没有单独落盘程序一断结果就丢了。规范化的批量任务需要考虑四个点输入队列、并发控制、失败重试、结果落盘。建议用一个 JSON 配置文件管理批量任务参数把输入目录、输出目录、并发数、请求间隔、模型名都集中放在一起。{ batch: { input_dir: ./inputs, output_dir: ./outputs, max_concurrency: 2, request_interval_seconds: 1.0, max_retries: 3, model: your-model-name } }程序读取配置文件后按max_concurrency控制并发每完成一条任务立即写入输出文件。这样即使中途中断也可以根据已有输出跳过已完成的任务继续执行剩余部分。批量处理还需要日志每条任务的 prompt 版本、请求时间、响应状态、token 消耗都要记录下来方便事后分析失败原因和成本。5. 多人协作与团队场景的 LLM 礼仪当 LLM 从个人工具变成团队共享设施时问题就从“我怎么调用”变成了“我们怎么一起用”。多人协作场景下资源分配、知识沉淀和成本控制是最容易扯皮的三件事。5.1 共享服务的资源分配团队共用一个模型服务时要引入最基本的配额机制。可以按成员或按业务线分配每分钟最大请求数也可以通过服务网关限制单用户并发。否则就会出现某位同事在跑一个需要几个小时的数据清洗任务结果把服务并发全部占满其他成员的正常提问全部超时。解决思路是分优先级交互式请求优先批处理任务放低优先级队列。如果团队规模不大至少要在约定层面明确批量任务避开工作高峰时段执行。5.2 Prompt 与输出结果的版本沉淀团队里最常见的浪费是同一个提示词被每个人各写一遍。更好的做法是把已验证有效的提示词统一入库形成团队级 Prompt 仓库。这个仓库不需要复杂用 Git 管理即可目录结构按业务场景划分。结合热词里常被提到的 LLM Wiki 思路可以在团队知识库软件中建一个 LLM 使用专区把接口文档、提示词模板、常见问题、失败案例都放进去。这样一个成员调通一个复杂提示词后其他人不用重新踩坑。输出结果同样要管理。凡是用于训练、微调、评估的输出数据建议统一落库并记录对应的提示词版本和模型版本。这不仅是数据管理问题也是复现问题的前提。很多场景下你发现模型输出变差了但根本找不到当时用的是什么提示词和模型只能从头排查这就是规范缺失的代价。5.3 成本控制与用量统计大多数公网模型 API 按 token 计费本地部署则要考虑 GPU 算力成本。成本控制的第一步是计量。每个账号或每个业务申请一个独立 API Key通过后台日志统计每个 Key 的 token 消耗。有了计量数据再设置月度预算和告警阈值。更细一层是在提示词层面控制限定输出长度、减少多余的历史对话、对长文本先做检索再送模型都能直接减少 token 消耗。6. 合规、隐私与内容安全边界LLM Etiquette 里最不能妥协的一部分是合规与安全。规范可以优化效率和成本但不能作为踩红线的理由。6.1 数据分级与敏感信息处理先给输入数据分级。公开资料、内部非敏感文档、个人敏感信息、商业机密这四类的处理方式完全不同。凡是包含手机号、身份证号、住址、人脸、可识别个人身份的声音等敏感信息都不应该在未经脱敏和授权的情况下直接送入公网模型服务。如果业务确实需要优先选择本地部署模型或者先做字段级脱敏再调用。团队内部可以约定进入 LLM 服务的所有文本必须先经过一个脱敏中间层把已知敏感字段替换成占位符返回结果后再做还原。6.2 版权与肖像授权图像生成、视频生成、声音克隆类任务必须确认素材来源。没有取得授权的人脸图片、他人声音样本、商用版权图片和视频片段不能作为模型输入。即使模型输出的是全新内容只要训练或生成过程使用了未经授权的素材后续使用风险仍然存在。实际项目里建议建立素材审批表记录每个素材的来源、授权范围、使用期限和负责人。发布或商用前由人工对输出内容做最终复核。6.3 输出审查与审计LLM 的输出并不总是可信的。涉及医疗、法律、金融等高风险领域时模型输出只能作为辅助参考不能直接作为决策依据。团队应建立输出复核机制自动化规则过滤 人工抽查。自动规则主要过滤明显违规词汇和异常格式人工抽查则针对内容质量和事实准确性。对于需要审计的场景所有请求和响应都要留日志至少保留提示词版本、模型版本、参数配置和结果记录一旦出现问题可以回溯。7. 从 LLM 到 LLM Agent 与 LLM 框架规范如何在工程中落地LLM 本身只是一个生成接口但实际工程中它往往被嵌入到 LLM Agent 和 LLM 框架里。Agent 让模型自主规划并调用工具框架负责编排整个流程。这时候LLM Etiquette 就不只是提示词层面的约定而是要变成系统里的硬约束。7.1 Agent 场景的行为边界LLM Agent 的典型问题是“失控循环”模型反复调用同一个失败工具或者在一个任务上消耗大量 token 却不收敛。规范的方法是在 Agent 的外部接入控制层限制最大工具调用次数、设置单轮任务超时、对每个工具调用做入参校验。还要在提示词里明确告知 Agent什么可以做、什么不能做、拿不准时直接询问用户。这些约束不是靠技巧让模型“听话”而是通过系统代码做兜底。工具调用返回错误时Agent 应该判断是临时异常还是永久失败避免无意义重试。7.2 在 LLM 框架层面固化规范使用 LLM 框架时规范应该做到配置化。请求超时、重试次数、并发上限这些参数不要散落在业务代码里而是统一放在框架配置层。用 YAML 或 JSON 维护一份环境配置不同环境使用不同参数测试环境可以并发高一点生产环境则更保守。框架层面还可以统一封装日志埋点把 token 消耗、响应延迟、错误码自动上报到监控系统。这样做的好处是业务开发不需要关心底层规范细节只要按配置接入即可。7.3 微调与数据集的礼仪如果团队准备对开源模型做 LLM 微调数据集的规范同样重要。训练数据要标注来源、版权状态和筛选标准不能用未授权数据做训练。数据清洗时去掉重复、错误和低质量样本微调后要做对比评测确认原始能力没有被破坏。精度问题也值得注意FP16、BF16、FP32 的选择会直接影响显存占用和输出质量。多人共用训练资源时要约定统一精度和并发策略否则同一份微调代码在不同设备上的结果可能不一致。8. 常见问题与排查方法LLM 使用中的问题通常不是单一原因造成的下面把高频问题和排查思路整理成一张表。问题现象可能原因排查方式解决方案接口频繁返回 429请求频率超过服务端限制查看服务端返回的限流头信息和请求日志降低并发、增加请求间隔、启用指数退避请求超时模型推理耗时太长或网络波动分阶段记录连接耗时和读取耗时调大读取超时、改用流式接口、简化 prompt输出内容不稳定prompt 过于模糊或缺少约束固定提示词模板对比多次输出增加角色、目标和输出格式约束长文本被截断max_tokens设置过小检查响应里的finish_reason增大max_tokens或调整输出策略批量任务中途失败进程崩溃或单条请求错误检查日志和已有输出文件任务持久化支持断点续跑多人共用服务时相互挤占缺少并发控制和配额查看服务端并发连接数增加网关限流和优先级队列同一条 prompt 在本地和远程结果不一致模型版本、精度或采样参数不同对比模型版本和生成参数统一模型版本和推理精度Agent 陷入死循环缺少最大步数和超时控制查看 Agent 工具调用日志外部控制循环次数和单步超时排查时有一个通用原则把问题分到层。先确认是网络层问题、服务端问题还是模型输出问题。网络层看状态码和延迟服务端看日志和资源占用模型输出看提示词与生成参数。分层排查能避免在一个已经正常的环节浪费大量时间。9. 最佳实践与落地建议把 LLM Etiquette 落地到实际项目不需要一次做完建议按阶段推进。第一阶段先建立最小规范。固定一套提示词模板统一 API 调用的超时和重试配置做好请求日志记录。这个阶段的目标是让单个开发者能稳定使用 LLM。第二阶段补充批量任务和错误处理。把批量任务持久化支持断点续跑重试加上退避策略输出结果按任务维度落盘。这个阶段的目标是让批处理任务上线后不会因为偶发错误导致全量返工。第三阶段团队协作和安全审计。搭建 Prompt 共享仓库统一模型服务入口加上配额和监控。这个阶段的目标是让多人协作时互不干扰且使用行为可追溯。每个阶段的推进顺序不要跳。如果第一批任务还没有稳定的重试机制先上团队配额只会让问题更复杂。另外所有规范文档和配置要放在团队仓库里让后来者有迹可循而不是靠口头约定。10. 总结与下一步LLM Etiquette 的价值在于把大模型使用从“凭感觉”变成“按规范”。提示词模板解决输出稳定性的问题API 调用规范解决服务可用性的问题团队资源分配解决协作冲突的问题合规与安全边界解决使用底线的问题。这四层合在一起才是完整的 LLM 使用礼仪。如果你今天只做一件事先选一个自己最常用的场景写一份固定格式的提示词模板然后给 API 调用加上超时和重试。这两个改动不需要任何额外硬件成本最低但效果最明显。如果已经过了这个阶段下一步就是设计批量任务的持久化队列把易失败点全部暴露出来再逐个解决。从最小规范开始逐步扩展LLM 才能真正成为稳定可靠的生产工具。建议收藏备用实际搭建时可以对照着逐项落地。