先把话说在前面如果你最近正在频繁使用 ChatGPT、Claude、通义千问、Kimi 这类大语言模型或者正在团队里做 LLM 应用开发那么“LLM Etiquette”这个话题值得认真看一遍。LLM Etiquette 直译过来是“大模型使用礼仪”但它讲的不只是“怎么有礼貌地问问题”。它更像一套与大模型高效协作的规范和习惯怎么把问题说清楚、怎么管理上下文、怎么判断输出靠不靠谱、怎么在项目里科学使用模型能力以及怎么避免把 API 调用做成一场灾难。我在团队里观察到一个很普遍的现象不同的人用同一个模型产出质量能差出好几倍。有人能用一个 Prompt 精准拿到结构化结果有人来回对话 20 轮还在绕圈子有人把 FP16、BF16 这些精度概念用得明明白白有人只会在界面上复制粘贴。这中间的差距很大程度上不是模型本身决定的而是使用者有没有一套“得体”的协作方式。这篇文章我会从概念、输入输出规范、资源管理、工程落地几个角度把 LLM Etiquette 拆成一套可执行的方法论。无论你是普通用户、算法工程师还是正在搭建 LLM 应用的开发者这篇文章都能给你一些可以直接落地的建议。1. 到底什么是 LLM Etiquette1.1 它不是“礼貌”而是“协作效率”很多人第一次看到“LLM Etiquette”这个词会误以为是要教你怎么用“请”“谢谢”来和大模型对话。确实礼貌用语有时会影响生成结果的语气倾向但这不是核心。LLM Etiquette 的本质是用户与大模型之间的交互规范。想象一下你带过的一个新人同事。如果他上来就问“这个怎么弄”你会一头雾水但如果他说“我在处理某个订单列表数据在 PostgreSQL 里现在需要统计最近 7 天每个品类的销量我贴一下表结构帮我写一个 SQL”你会非常顺畅地给出答案。大模型也是这样。它没有读心术只能通过你提供的 Prompt、上下文和参数设置来推断意图。输入信息越规范、约束越明确输出质量就越高。LLM Etiquette 就是把这套“和 AI 协作的沟通规范”系统化。1.2 为什么现在这个话题特别重要2025 年之后大模型已经渗透到非常多的实际业务场景中智能客服、代码助手、知识库问答、报表生成、文档总结、Agent 自动化流程……这些场景有一个共同点模型的输出质量直接决定业务效果。也就是说LLM 不再只是“聊着玩”的工具而是生产环境里的核心组件。此时如果没有一套使用规范就会出现业务人员不会写 Prompt每次都要靠技术人员帮忙调。开发者在代码里硬编码系统提示词换一个模型就要重写。API 调用完全不控制 Token 消耗月底账单高得离谱。对模型输出不做校验幻觉内容直接进入业务数据。这些都是典型的“LLM 失礼”行为。而 LLM Etiquette就是用来解决这些问题的。1.3 本文的核心范围下面我分几个层面展开输入侧如何把问题说清楚。输出侧如何验证和信任模型结果。资源侧精度、量化、成本与模型选择。工程侧知识库、Agent、编排框架的落地方式。组织侧合规、安全与团队协作规范。每一部分都会给出可操作的清单和示例。2. 输入侧礼仪让模型听懂你在问什么2.1 先说清楚背景、任务、要求大模型对话和人类对话有一个重要区别人类可以通过表情、语气、眼神补足信息大模型只能靠文字推测。所以高效提问的第一原则是给足上下文。一个“得体”的 Prompt 通常包含以下要素角色或背景设定你希望模型以什么视角回应。任务描述要做什么输出什么。输入数据需要模型处理的具体内容。输出格式要求JSON、Markdown 表格、纯文本等。约束条件字数、语气、禁止项等。这里给一个对比示例。低效提问帮我写个Python脚本高效提问你是资深Python开发工程师。我需要一个脚本功能是读取当前目录下的sales.csv文件 统计每个产品类别的总销售额并将结果输出为一个新的CSV文件包含category、total_sales两列。 编码格式为UTF-8。请输出完整可运行的Python代码并简要说明关键步骤。第二种提问方式具备所有关键要素模型不需要反复追问一次性产出的代码可用率会高很多。记住一个原则你给模型的信息量决定了模型给你的信息质量。2.2 复杂任务要拆解如果任务本身比较复杂比如“分析这 30 页文档并生成一份商业计划书”一次性丢给模型输出往往比较泛。正确的做法是拆成多步让模型先总结文档核心内容。提取关键数据。按照商业计划书的结构逐段输出。最后整合。这其实就是 Prompt 工程里的“Chain of Thought思维链”思路。实际使用中你可以把它拆成多轮对话也可以在一个 Prompt 里用序号步骤明确规定。示例请按以下步骤处理给定的文档内容 第一步列出文档中提到的3个核心问题。 第二步针对每个问题提取文档中对应的解决方案。 第三步将问题与方案整理成表格列为“问题|方案|涉及部门”。 最后用100字以内总结文档的核心观点。对大模型来说任务拆得越细每一步的“思考负担”越小最终输出的条理性和准确性就会越高。2.3 提示词模板要沉淀很多人和大模型对话是“开盲盒”式的——每次重新打一遍措辞不同输出就不稳定。这在学习阶段没什么问题但一旦要用在业务场景、团队协作中效率就太低。推荐的思路是把高频 Prompt 沉淀成模板。你可以使用一个简单的配置管理方式比如存成 Markdown 文件或 JSON 文件{ templates: { sql_optimizer: { name: SQL优化助手, system: 你是一名资深的数据库性能优化专家擅长MySQL和PostgreSQL。, user_prompt: 下面是我的一段SQL请帮我分析慢查询原因并给出优化建议。\nSQL:\n{sql_text}\n请从索引、表结构、执行计划三个角度分析。 }, 代码审查: { name: 代码审查助手, system: 你是高级软件工程师负责代码评审。请从代码规范、安全漏洞、性能问题三个维度给出建议。, user_prompt: 请审查以下代码\n{code}\n输出格式问题列表 修复建议。 } } }对于开发者来说这类模板就是Prompt 即代码。把提示词纳入版本管理跟随项目一起迭代是团队推动 LLM 落地的关键一步。很多 LLM 编排框架比如 LangChain、LlamaIndex也支持从配置文件中加载提示词模板这比直接硬编码在代码里要规范得多。3. 输出侧礼仪学会质疑模型的每一句话3.1 幻觉问题始终要留一颗“怀疑的心”大语言模型的本质是“下一个词预测器”。它生成的内容是概率分布下的连续输出而不是从数据库里查询出来的事实。因此模型输出的信息看起来可能非常可信但本质上没有任何事实保障。这就是常说的“幻觉Hallucination”模型用流畅、自信的语言编造出不存在的法律条款、新闻事件、API 函数、论文引用。2025 年之后的大模型在事实性上已经有了很大进步内容正确率提升了不少但这不代表你可以放弃对输出的审查。在依赖大模型输出结果的场景里至少要做三层检查事实类内容人名、数字、日期、文献标题必须人工核对原始来源。代码类内容不能直接复制到生产环境。先 review再跑测试。逻辑类内容检查结论和论据之间是否有因果断层。3.2 用提示词降低幻觉概率虽然无法彻底消灭幻觉但可以通过 Prompt 设计大幅降低它出现的频率。核心手段是让模型承认“我不知道”。示例你是一位严谨的技术顾问。对于不确定的事实信息请明确回答“我不确定”或“我无法确认”。 如果某个数据在给出的上下文中不存在请直接说明而不要猜测。这种“允许承认无知”的设定非常有效因为它打破了模型“必须给出完整回答”的隐性倾向。对于应用开发团队更推荐另一种做法给模型接上“检索增强生成Retrieval-Augmented GenerationRAG”能力。简单说就是先从一个可控的知识库比如内部文档库、FAQ、产品手册中检索相关内容再把检索结果作为上下文注入给模型要求它只能依据这些内容回答。这样一来模型猜答案的空间会被大幅缩小。3.3 建立结构化输出协议“得体”的 LLM 使用方式应该是面向机器时输出结构化数据面向人时输出自然语言。在开发 LLM 应用时尽量不要让模型输出大段口语化文本然后靠正则去解析。更好的做法是要求模型返回 JSON。一般会配合response_format参数来使用这是各大模型服务商常见的接口能力{ role: system, content: 你是一个信息提取器。用户会给一段文本你需要提取其中的人名、日期、事件以JSON格式输出。 }然后设定模型输出{ entities: { person: [张三, 李四], date: [2025-06-01], event: [项目启动会] } }这样可以跳过正则解析直接处理结构化结果。如果你用的是 OpenAI 兼容接口通常会有 JSON mode 或response_format{type: json_object}之类的能力国内很多模型服务商的 SDK 也支持类似参数。具体配置需要以你的模型服务商文档为准。输出侧礼仪的核心可以概括为一句话把模型当成一个能力很强、但偶尔会撒谎的实习生——要用但要校验。4. 资源侧礼仪精度、成本与模型选择的学问4.1 为什么精度会直接影响生成质量很多开发者对大模型的精度概念很陌生但在实际部署和 API 调用场景里FP16、BF16、FP32这些词经常出现而且直接影响生成效果。为什么这要从大模型的存储和计算方式说起。大模型的权重通常是浮点数。参数越多需要的内存越大。训练和推理时如果所有参数都使用 FP32单精度浮点数每个数占 4 字节内存开销会非常大计算速度也会受到限制。所以业界普遍采用半精度方案FP1616位浮点数和 BF16bfloat16脑浮点16。这两种方案都将每个数压缩到 2 字节显著减少显存占用提升推理速度。但精度降低会带来一个问题数值表示范围的缩小和精度的损失可能导致模型推理结果异常。尤其是在一些对数值敏感的任务中FP16 可能产生精度丢失而 BF16 保留了和 FP32 一样的指数范围只减少了尾数位在实际训练中更稳定。这也是为什么很多开源模型在发布时会给出不同精度检查点FP32、FP16、BF16甚至 INT8、INT4 量化版。你选择的精度版本直接决定了显存占用、推理速度、输出质量三者之间的平衡。4.2 实际选择建议如果你调用的是商业 APIOpenAI、国内大模型厂商等精度问题通常由服务商管理你不需要关心。但如果你在本地部署开源模型无论是用 Ollama、vLLM、llama.cpp 还是 Hugging Face Transformers精度选择就是一个绕不开的决策点。简单给出几条建议本地有充足 GPU 显存优先选择 BF16 或 FP16。BF16 在 Linux 环境、较新 GPU 上兼容性更好在训练和推理中数值稳定性优于 FP16。显存紧张可以考虑 INT8 或 INT4 量化模型。量化会带来一定质量损失但在很多场景下性价比极高。开发调试阶段可以用较低精度模型快速验证流程最后再切换到高精度模型做正式推理。再补充一个显存估算的简单公式方便你做选型模型显存占用 ≈ 参数量 × 每个参数占用的字节数以 7B 参数模型为例精度每参数字节数约需显存FP32428 GBFP16 / BF16214 GBINT817 GBINT40.53.5 GB注意这只是权重的基础占用量实际推理还需要额外的 KV Cache 和激活内存。所以上面数值是“下限”实际部署时建议留出 20% 到 30% 余量。4.3 Token 预算是资源礼仪的硬指标“Token”是大模型处理文本的基本单位。一次 API 调用你发送的 Prompt 和模型生成的回答都会消耗 Token而 Token 就是你的真金白银。所谓 Token 预算就是在一次对话或一个应用流程中对 Token 的消耗量做明确的规划和控制。开发者在设计 LLM 应用时至少要从这几个维度控制控制上下文长度不要把整个知识库塞进 Prompt。只注入当前任务相关的内容。限制最大回复长度设置max_tokens防止模型生成冗余内容。设置上下文窗口上限在多轮对话中超出窗口后的历史消息会被截断或压缩需要设计上下文管理策略。日志与监控记录每次请求的 Token 用量方便分析成本。一个基本的上下文管理策略示例class ContextManager: def __init__(self, max_tokens4000): self.max_tokens max_tokens def build_messages(self, system_prompt, history, new_user_input): # 估算每条消息的 token 数这里简化处理 def estimate_tokens(text): # 中文场景下一个汉字大约 1-2 个 token这里用简单比例估算 return len(text) * 2 messages [] messages.append({role: system, content: system_prompt}) # 从后往前遍历历史消息知道超过预算则停止 remaining self.max_tokens - estimate_tokens(system_prompt) - estimate_tokens(new_user_input) history_messages [] for msg in reversed(history): msg_size estimate_tokens(msg[content]) if remaining - msg_size 0: break history_messages.append(msg) remaining - msg_size messages.extend(reversed(history_messages)) messages.append({role: user, content: new_user_input}) return messages这个代码只是一个简化的思路实际项目中建议用tiktoken这类分词库来准确计算 Token 数。但它体现了一个核心原则LLM 的上下文窗口是稀缺资源要像管理数据库连接池一样去管理它。5. 工程侧礼仪知识库、Agent 与编排框架5.1 从“聊天窗口”走向“知识库应用”到目前为止最成功的大模型落地形态之一是“企业知识库问答”。这个方向之所以受欢迎是因为它解决了一个核心矛盾通用大模型不了解企业内部数据但企业内部知识又是最值钱的资产。围绕知识库业界已经形成了相当成熟的架构模式也就是前面提到的 RAG。一个典型流程是将文档切分成 chunks文本块。为每个 chunk 生成向量存入向量数据库。用户提问时将问题转为向量检索最相似的若干 chunks。将 chunks 作为上下文和问题一起交给 LLM。LLM 基于提供的上下文生成答案并标注来源。这套架构现在有很多工具链支撑比如 LlamaIndex、LangChain、向量数据库 Milvus / Qdrant / Chroma以及各种商业化平台。如果你是初学者想低成本体验知识库的构建流程可以参考一个经典的学习路径使用 Obsidian 管理 Markdown 笔记通过这些笔记构建私人的 LLM 知识库。社区里把这种模式称为“LLM Wiki”。核心思路是用 Markdown 维护结构化笔记用脚本把笔记导入向量库再通过对话式界面实现个人知识问答。这里有一个核心启示LLM 不擅长记忆事实但擅长理解和生成。把记忆工作交给向量数据库把生成工作交给大模型各司其职才是礼仪。5.2 Agent把大模型从“聊天对象”变成“执行者”如果说 RAG 解决的是“让模型知道更多”那么 Agent智能体解决的是“让模型做更多”。一个 LLM Agent 通常具备以下能力任务规划将复杂任务拆解为多个子步骤。工具调用可以调用代码解释器、搜索引擎、API、数据库等外部工具。记忆管理记录中间结果供后续步骤使用。自主决策根据执行结果决定下一步动作。Python 生态里最简单直接的 Agent demo 可以基于 LangChain 或国内厂商的 Agent 框架实现。下面是一个简化的“工具调用 Agent”的代码示例from langchain_community.chat_models import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.tools import tool from langchain_core.prompts import ChatPromptTemplate # 定义一个工具计算日期 tool def get_weekday(date_str: str) - str: 根据 YYYY-MM-DD 格式的日期计算是星期几 from datetime import datetime dt datetime.strptime(date_str, %Y-%m-%d) return f{dt.strftime(%A)} # 工具列表 tools [get_weekday] # 提示词 prompt ChatPromptTemplate.from_messages([ (system, 你是一个智能助手可以调用工具回答问题。), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 初始化模型与 Agent llm ChatOpenAI(modelgpt-4o-mini, temperature0) agent create_tool_calling_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue) # 执行 result executor.invoke({input: 2025-06-01 是星期几请用工具计算。}) print(result)注意这段代码依赖特定版本的 langchain如果你本地版本不同接口可能有差异。但它展示了 Agent 的核心模式——给模型注册一批工具模型自主判断何时调用哪个工具并根据工具返回结果继续推理。LLM Agent 的礼仪要点是什么给 Agent 的工具必须定义清晰、描述准确否则模型不会调用或者调用错。每个工具都应该有输入校验和异常处理不能容忍 Agent 传入非法参数时系统崩溃。Agent 权限必须做最小化控制。你给 Agent 接数据库时如果只读用途就用只读账号需要写入时先在测试环境验证。5.3 为什么需要编排框架随着应用场景复杂化单次 Prompt 调用已经远远不够需要在多个模型调用之间做流程编排。比如一个“会议纪要 待办提取 日程生成”的流程可能需要三次不同的模型调用还要拼接中间结果。这时候就需要一个编排框架。编排框架的核心价值有三点流程复用把固定流程封装成模板避免每次重新写代码。状态管理流程中多个步骤之间需要传递数据编排框架帮你管理中间状态。异常处理某个步骤失败时支持重试、降级、回滚策略。选型时不用盲目追新。对于简单项目直接用 Python 写流程控制就够了项目规模变大后再引入 LangGraph、Dify 之类的框架会事半功倍。6. 团队协作中的 LLM 礼仪6.1 明确人与模型的分工在团队协作中引入 LLM最容易犯的错误是职责错位。有人把所有任务都丢给模型有人完全禁止模型参与。这两种极端都不可取。更稳健的分工原则是模型负责“生成初稿”代码雏形、文档框架、方案草稿、数据整理。人类负责“决策与定稿”需求方向、技术选型、内容审核、质量验收。这正是 LLM Etiquette 在组织层面的体现大模型是“提效杠杆”不是“责任人”。任何进入业务系统的内容都必须有人类责任人对最终质量负责。6.2 数据安全与合规底线这是团队使用大模型时最不能越过的红线。内部资料是否允许发送到外部模型服务这个问题需要法务和信息安全部门来评估。但有几个可以提前执行的默认准则敏感数据脱敏在输入提示词前移除身份证号、手机号、客户名称、密钥等敏感信息。最小权限数据交付只给模型完成任务所必需的数据不给全部数据。内部私有化部署如果业务数据足够敏感优先考虑使用私有化部署的开源模型。记录与审计LLM 调用链路应该纳入日志系统便于追踪数据流向和可能的安全事件。6.3 建立团队的 Prompt 评审机制Prompt 不是“随便写的一句话”它实际上是系统的业务逻辑。团队应该有评审机制。在团队协作里最不“体面”的事情是核心 Prompt 只存在于某个人的聊天记录里人一走业务就停了。应该把提示词纳入代码仓库管理。当业务需求变化时提示词变更要走评审流程和代码变更一样。团队内部可以约定提示词必须存入 Git 仓库作为项目资产。提示词变更要有变更说明。所有模型调用代码必须通过代码评审。模型版本升级时要有回归测试来验证输出质量。7. 常见的“LLM 失礼”行为与排查思路在实际使用中有一些高频问题值得单独列出来。下面整理了一份对照检查表你在自查时可以逐条对照。问题现象常见原因解决思路模型答非所问用户 Prompt 缺少具体约束和背景补充角色、任务、输出格式、约束条件回答不稳定每次结果差异大模型 temperature 参数设置不当Prompt 太泛将 temperature 降低到 0~0.3模板化 Prompt代码无法直接运行模型生成了“看起来对”的代码本地先跑测试确认依赖版本不要盲信API 成本失控Token 消耗无预算、上下文越长越大上下文裁剪、限制 max_tokens、启用日志监控本地推理显存不足模型精度选择不匹配硬件改用精度更低的检查点或量化模型知识库回答穿越向量检索未命中相关 chunk调整 chunk 大小、改进分段策略、增加 top_kAgent 调用工具报错工具描述不清晰模型传参错误完善工具描述为工具添加输入校验数据泄露风险未脱敏数据直接发送到外部 API建立脱敏流程敏感数据走私有化部署排查问题时建议按这个顺序来先确认输入是否清晰再检查参数配置然后看模型版本和精度最后检查下游处理逻辑。多数问题都出在前两环。8. 最佳实践清单最后把全文的要点收敛成一份可以在实际工作中直接对着做的清单。8.1 个人使用层面提问前先交代背景、任务、输出格式。复杂任务拆成多步不一次硬塞。对事实类输出保持怀疑特别是法律、医疗、金融领域。对代码输出先跑通再使用而不是直接部署。保存常用的高质量 Prompt形成自己的模板库。8.2 应用开发层面用 JSON 约束模型输出方便程序解析。用 RAG 降低幻觉不依赖模型记忆事实。给模型接入工具时工具描述要精确权限要最小化。对每次 API 调用做 Token 用量和耗时监控。Prompt 纳入版本管理与代码同步迭代。8.3 团队管理层面建立模型输出的人工审核机制。制定敏感数据使用大模型的合规边界。统一团队用的模型、参数和提示词规范。本地部署时选择合适精度平衡成本和质量。这份清单不是一步到位的终稿。LLM 技术和工具链演进非常快今天的最佳实践未来可能很快过时。但底层的方法论是稳定的清晰输入、审慎输出、控制成本、保障安全。最后想分享一个个人经验。刚开始接触大模型时我也觉得“会聊天就行”但随着项目深入发现真正拉开差距的不是谁更会用某个模型的某个功能而是谁更早建立起一套稳定、可复用、可管理的协作规范。LLM Etiquette 听起来是个很虚的概念但落到每天写 Prompt、调 API、评估结果的动作上它就是实打实的生产力。如果你也准备把大模型引入自己的工作流或业务系统不妨先把这篇文章里的清单逐条过一遍。把该省的 Token 省下来把该校验的结果校验好把该规范的流程规范化再大胆去用模型的能力。 LLM Etiquette：大模型高效协作的规范与工程实践指南
先把话说在前面如果你最近正在频繁使用 ChatGPT、Claude、通义千问、Kimi 这类大语言模型或者正在团队里做 LLM 应用开发那么“LLM Etiquette”这个话题值得认真看一遍。LLM Etiquette 直译过来是“大模型使用礼仪”但它讲的不只是“怎么有礼貌地问问题”。它更像一套与大模型高效协作的规范和习惯怎么把问题说清楚、怎么管理上下文、怎么判断输出靠不靠谱、怎么在项目里科学使用模型能力以及怎么避免把 API 调用做成一场灾难。我在团队里观察到一个很普遍的现象不同的人用同一个模型产出质量能差出好几倍。有人能用一个 Prompt 精准拿到结构化结果有人来回对话 20 轮还在绕圈子有人把 FP16、BF16 这些精度概念用得明明白白有人只会在界面上复制粘贴。这中间的差距很大程度上不是模型本身决定的而是使用者有没有一套“得体”的协作方式。这篇文章我会从概念、输入输出规范、资源管理、工程落地几个角度把 LLM Etiquette 拆成一套可执行的方法论。无论你是普通用户、算法工程师还是正在搭建 LLM 应用的开发者这篇文章都能给你一些可以直接落地的建议。1. 到底什么是 LLM Etiquette1.1 它不是“礼貌”而是“协作效率”很多人第一次看到“LLM Etiquette”这个词会误以为是要教你怎么用“请”“谢谢”来和大模型对话。确实礼貌用语有时会影响生成结果的语气倾向但这不是核心。LLM Etiquette 的本质是用户与大模型之间的交互规范。想象一下你带过的一个新人同事。如果他上来就问“这个怎么弄”你会一头雾水但如果他说“我在处理某个订单列表数据在 PostgreSQL 里现在需要统计最近 7 天每个品类的销量我贴一下表结构帮我写一个 SQL”你会非常顺畅地给出答案。大模型也是这样。它没有读心术只能通过你提供的 Prompt、上下文和参数设置来推断意图。输入信息越规范、约束越明确输出质量就越高。LLM Etiquette 就是把这套“和 AI 协作的沟通规范”系统化。1.2 为什么现在这个话题特别重要2025 年之后大模型已经渗透到非常多的实际业务场景中智能客服、代码助手、知识库问答、报表生成、文档总结、Agent 自动化流程……这些场景有一个共同点模型的输出质量直接决定业务效果。也就是说LLM 不再只是“聊着玩”的工具而是生产环境里的核心组件。此时如果没有一套使用规范就会出现业务人员不会写 Prompt每次都要靠技术人员帮忙调。开发者在代码里硬编码系统提示词换一个模型就要重写。API 调用完全不控制 Token 消耗月底账单高得离谱。对模型输出不做校验幻觉内容直接进入业务数据。这些都是典型的“LLM 失礼”行为。而 LLM Etiquette就是用来解决这些问题的。1.3 本文的核心范围下面我分几个层面展开输入侧如何把问题说清楚。输出侧如何验证和信任模型结果。资源侧精度、量化、成本与模型选择。工程侧知识库、Agent、编排框架的落地方式。组织侧合规、安全与团队协作规范。每一部分都会给出可操作的清单和示例。2. 输入侧礼仪让模型听懂你在问什么2.1 先说清楚背景、任务、要求大模型对话和人类对话有一个重要区别人类可以通过表情、语气、眼神补足信息大模型只能靠文字推测。所以高效提问的第一原则是给足上下文。一个“得体”的 Prompt 通常包含以下要素角色或背景设定你希望模型以什么视角回应。任务描述要做什么输出什么。输入数据需要模型处理的具体内容。输出格式要求JSON、Markdown 表格、纯文本等。约束条件字数、语气、禁止项等。这里给一个对比示例。低效提问帮我写个Python脚本高效提问你是资深Python开发工程师。我需要一个脚本功能是读取当前目录下的sales.csv文件 统计每个产品类别的总销售额并将结果输出为一个新的CSV文件包含category、total_sales两列。 编码格式为UTF-8。请输出完整可运行的Python代码并简要说明关键步骤。第二种提问方式具备所有关键要素模型不需要反复追问一次性产出的代码可用率会高很多。记住一个原则你给模型的信息量决定了模型给你的信息质量。2.2 复杂任务要拆解如果任务本身比较复杂比如“分析这 30 页文档并生成一份商业计划书”一次性丢给模型输出往往比较泛。正确的做法是拆成多步让模型先总结文档核心内容。提取关键数据。按照商业计划书的结构逐段输出。最后整合。这其实就是 Prompt 工程里的“Chain of Thought思维链”思路。实际使用中你可以把它拆成多轮对话也可以在一个 Prompt 里用序号步骤明确规定。示例请按以下步骤处理给定的文档内容 第一步列出文档中提到的3个核心问题。 第二步针对每个问题提取文档中对应的解决方案。 第三步将问题与方案整理成表格列为“问题|方案|涉及部门”。 最后用100字以内总结文档的核心观点。对大模型来说任务拆得越细每一步的“思考负担”越小最终输出的条理性和准确性就会越高。2.3 提示词模板要沉淀很多人和大模型对话是“开盲盒”式的——每次重新打一遍措辞不同输出就不稳定。这在学习阶段没什么问题但一旦要用在业务场景、团队协作中效率就太低。推荐的思路是把高频 Prompt 沉淀成模板。你可以使用一个简单的配置管理方式比如存成 Markdown 文件或 JSON 文件{ templates: { sql_optimizer: { name: SQL优化助手, system: 你是一名资深的数据库性能优化专家擅长MySQL和PostgreSQL。, user_prompt: 下面是我的一段SQL请帮我分析慢查询原因并给出优化建议。\nSQL:\n{sql_text}\n请从索引、表结构、执行计划三个角度分析。 }, 代码审查: { name: 代码审查助手, system: 你是高级软件工程师负责代码评审。请从代码规范、安全漏洞、性能问题三个维度给出建议。, user_prompt: 请审查以下代码\n{code}\n输出格式问题列表 修复建议。 } } }对于开发者来说这类模板就是Prompt 即代码。把提示词纳入版本管理跟随项目一起迭代是团队推动 LLM 落地的关键一步。很多 LLM 编排框架比如 LangChain、LlamaIndex也支持从配置文件中加载提示词模板这比直接硬编码在代码里要规范得多。3. 输出侧礼仪学会质疑模型的每一句话3.1 幻觉问题始终要留一颗“怀疑的心”大语言模型的本质是“下一个词预测器”。它生成的内容是概率分布下的连续输出而不是从数据库里查询出来的事实。因此模型输出的信息看起来可能非常可信但本质上没有任何事实保障。这就是常说的“幻觉Hallucination”模型用流畅、自信的语言编造出不存在的法律条款、新闻事件、API 函数、论文引用。2025 年之后的大模型在事实性上已经有了很大进步内容正确率提升了不少但这不代表你可以放弃对输出的审查。在依赖大模型输出结果的场景里至少要做三层检查事实类内容人名、数字、日期、文献标题必须人工核对原始来源。代码类内容不能直接复制到生产环境。先 review再跑测试。逻辑类内容检查结论和论据之间是否有因果断层。3.2 用提示词降低幻觉概率虽然无法彻底消灭幻觉但可以通过 Prompt 设计大幅降低它出现的频率。核心手段是让模型承认“我不知道”。示例你是一位严谨的技术顾问。对于不确定的事实信息请明确回答“我不确定”或“我无法确认”。 如果某个数据在给出的上下文中不存在请直接说明而不要猜测。这种“允许承认无知”的设定非常有效因为它打破了模型“必须给出完整回答”的隐性倾向。对于应用开发团队更推荐另一种做法给模型接上“检索增强生成Retrieval-Augmented GenerationRAG”能力。简单说就是先从一个可控的知识库比如内部文档库、FAQ、产品手册中检索相关内容再把检索结果作为上下文注入给模型要求它只能依据这些内容回答。这样一来模型猜答案的空间会被大幅缩小。3.3 建立结构化输出协议“得体”的 LLM 使用方式应该是面向机器时输出结构化数据面向人时输出自然语言。在开发 LLM 应用时尽量不要让模型输出大段口语化文本然后靠正则去解析。更好的做法是要求模型返回 JSON。一般会配合response_format参数来使用这是各大模型服务商常见的接口能力{ role: system, content: 你是一个信息提取器。用户会给一段文本你需要提取其中的人名、日期、事件以JSON格式输出。 }然后设定模型输出{ entities: { person: [张三, 李四], date: [2025-06-01], event: [项目启动会] } }这样可以跳过正则解析直接处理结构化结果。如果你用的是 OpenAI 兼容接口通常会有 JSON mode 或response_format{type: json_object}之类的能力国内很多模型服务商的 SDK 也支持类似参数。具体配置需要以你的模型服务商文档为准。输出侧礼仪的核心可以概括为一句话把模型当成一个能力很强、但偶尔会撒谎的实习生——要用但要校验。4. 资源侧礼仪精度、成本与模型选择的学问4.1 为什么精度会直接影响生成质量很多开发者对大模型的精度概念很陌生但在实际部署和 API 调用场景里FP16、BF16、FP32这些词经常出现而且直接影响生成效果。为什么这要从大模型的存储和计算方式说起。大模型的权重通常是浮点数。参数越多需要的内存越大。训练和推理时如果所有参数都使用 FP32单精度浮点数每个数占 4 字节内存开销会非常大计算速度也会受到限制。所以业界普遍采用半精度方案FP1616位浮点数和 BF16bfloat16脑浮点16。这两种方案都将每个数压缩到 2 字节显著减少显存占用提升推理速度。但精度降低会带来一个问题数值表示范围的缩小和精度的损失可能导致模型推理结果异常。尤其是在一些对数值敏感的任务中FP16 可能产生精度丢失而 BF16 保留了和 FP32 一样的指数范围只减少了尾数位在实际训练中更稳定。这也是为什么很多开源模型在发布时会给出不同精度检查点FP32、FP16、BF16甚至 INT8、INT4 量化版。你选择的精度版本直接决定了显存占用、推理速度、输出质量三者之间的平衡。4.2 实际选择建议如果你调用的是商业 APIOpenAI、国内大模型厂商等精度问题通常由服务商管理你不需要关心。但如果你在本地部署开源模型无论是用 Ollama、vLLM、llama.cpp 还是 Hugging Face Transformers精度选择就是一个绕不开的决策点。简单给出几条建议本地有充足 GPU 显存优先选择 BF16 或 FP16。BF16 在 Linux 环境、较新 GPU 上兼容性更好在训练和推理中数值稳定性优于 FP16。显存紧张可以考虑 INT8 或 INT4 量化模型。量化会带来一定质量损失但在很多场景下性价比极高。开发调试阶段可以用较低精度模型快速验证流程最后再切换到高精度模型做正式推理。再补充一个显存估算的简单公式方便你做选型模型显存占用 ≈ 参数量 × 每个参数占用的字节数以 7B 参数模型为例精度每参数字节数约需显存FP32428 GBFP16 / BF16214 GBINT817 GBINT40.53.5 GB注意这只是权重的基础占用量实际推理还需要额外的 KV Cache 和激活内存。所以上面数值是“下限”实际部署时建议留出 20% 到 30% 余量。4.3 Token 预算是资源礼仪的硬指标“Token”是大模型处理文本的基本单位。一次 API 调用你发送的 Prompt 和模型生成的回答都会消耗 Token而 Token 就是你的真金白银。所谓 Token 预算就是在一次对话或一个应用流程中对 Token 的消耗量做明确的规划和控制。开发者在设计 LLM 应用时至少要从这几个维度控制控制上下文长度不要把整个知识库塞进 Prompt。只注入当前任务相关的内容。限制最大回复长度设置max_tokens防止模型生成冗余内容。设置上下文窗口上限在多轮对话中超出窗口后的历史消息会被截断或压缩需要设计上下文管理策略。日志与监控记录每次请求的 Token 用量方便分析成本。一个基本的上下文管理策略示例class ContextManager: def __init__(self, max_tokens4000): self.max_tokens max_tokens def build_messages(self, system_prompt, history, new_user_input): # 估算每条消息的 token 数这里简化处理 def estimate_tokens(text): # 中文场景下一个汉字大约 1-2 个 token这里用简单比例估算 return len(text) * 2 messages [] messages.append({role: system, content: system_prompt}) # 从后往前遍历历史消息知道超过预算则停止 remaining self.max_tokens - estimate_tokens(system_prompt) - estimate_tokens(new_user_input) history_messages [] for msg in reversed(history): msg_size estimate_tokens(msg[content]) if remaining - msg_size 0: break history_messages.append(msg) remaining - msg_size messages.extend(reversed(history_messages)) messages.append({role: user, content: new_user_input}) return messages这个代码只是一个简化的思路实际项目中建议用tiktoken这类分词库来准确计算 Token 数。但它体现了一个核心原则LLM 的上下文窗口是稀缺资源要像管理数据库连接池一样去管理它。5. 工程侧礼仪知识库、Agent 与编排框架5.1 从“聊天窗口”走向“知识库应用”到目前为止最成功的大模型落地形态之一是“企业知识库问答”。这个方向之所以受欢迎是因为它解决了一个核心矛盾通用大模型不了解企业内部数据但企业内部知识又是最值钱的资产。围绕知识库业界已经形成了相当成熟的架构模式也就是前面提到的 RAG。一个典型流程是将文档切分成 chunks文本块。为每个 chunk 生成向量存入向量数据库。用户提问时将问题转为向量检索最相似的若干 chunks。将 chunks 作为上下文和问题一起交给 LLM。LLM 基于提供的上下文生成答案并标注来源。这套架构现在有很多工具链支撑比如 LlamaIndex、LangChain、向量数据库 Milvus / Qdrant / Chroma以及各种商业化平台。如果你是初学者想低成本体验知识库的构建流程可以参考一个经典的学习路径使用 Obsidian 管理 Markdown 笔记通过这些笔记构建私人的 LLM 知识库。社区里把这种模式称为“LLM Wiki”。核心思路是用 Markdown 维护结构化笔记用脚本把笔记导入向量库再通过对话式界面实现个人知识问答。这里有一个核心启示LLM 不擅长记忆事实但擅长理解和生成。把记忆工作交给向量数据库把生成工作交给大模型各司其职才是礼仪。5.2 Agent把大模型从“聊天对象”变成“执行者”如果说 RAG 解决的是“让模型知道更多”那么 Agent智能体解决的是“让模型做更多”。一个 LLM Agent 通常具备以下能力任务规划将复杂任务拆解为多个子步骤。工具调用可以调用代码解释器、搜索引擎、API、数据库等外部工具。记忆管理记录中间结果供后续步骤使用。自主决策根据执行结果决定下一步动作。Python 生态里最简单直接的 Agent demo 可以基于 LangChain 或国内厂商的 Agent 框架实现。下面是一个简化的“工具调用 Agent”的代码示例from langchain_community.chat_models import ChatOpenAI from langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_core.tools import tool from langchain_core.prompts import ChatPromptTemplate # 定义一个工具计算日期 tool def get_weekday(date_str: str) - str: 根据 YYYY-MM-DD 格式的日期计算是星期几 from datetime import datetime dt datetime.strptime(date_str, %Y-%m-%d) return f{dt.strftime(%A)} # 工具列表 tools [get_weekday] # 提示词 prompt ChatPromptTemplate.from_messages([ (system, 你是一个智能助手可以调用工具回答问题。), (human, {input}), (placeholder, {agent_scratchpad}), ]) # 初始化模型与 Agent llm ChatOpenAI(modelgpt-4o-mini, temperature0) agent create_tool_calling_agent(llm, tools, prompt) executor AgentExecutor(agentagent, toolstools, verboseTrue) # 执行 result executor.invoke({input: 2025-06-01 是星期几请用工具计算。}) print(result)注意这段代码依赖特定版本的 langchain如果你本地版本不同接口可能有差异。但它展示了 Agent 的核心模式——给模型注册一批工具模型自主判断何时调用哪个工具并根据工具返回结果继续推理。LLM Agent 的礼仪要点是什么给 Agent 的工具必须定义清晰、描述准确否则模型不会调用或者调用错。每个工具都应该有输入校验和异常处理不能容忍 Agent 传入非法参数时系统崩溃。Agent 权限必须做最小化控制。你给 Agent 接数据库时如果只读用途就用只读账号需要写入时先在测试环境验证。5.3 为什么需要编排框架随着应用场景复杂化单次 Prompt 调用已经远远不够需要在多个模型调用之间做流程编排。比如一个“会议纪要 待办提取 日程生成”的流程可能需要三次不同的模型调用还要拼接中间结果。这时候就需要一个编排框架。编排框架的核心价值有三点流程复用把固定流程封装成模板避免每次重新写代码。状态管理流程中多个步骤之间需要传递数据编排框架帮你管理中间状态。异常处理某个步骤失败时支持重试、降级、回滚策略。选型时不用盲目追新。对于简单项目直接用 Python 写流程控制就够了项目规模变大后再引入 LangGraph、Dify 之类的框架会事半功倍。6. 团队协作中的 LLM 礼仪6.1 明确人与模型的分工在团队协作中引入 LLM最容易犯的错误是职责错位。有人把所有任务都丢给模型有人完全禁止模型参与。这两种极端都不可取。更稳健的分工原则是模型负责“生成初稿”代码雏形、文档框架、方案草稿、数据整理。人类负责“决策与定稿”需求方向、技术选型、内容审核、质量验收。这正是 LLM Etiquette 在组织层面的体现大模型是“提效杠杆”不是“责任人”。任何进入业务系统的内容都必须有人类责任人对最终质量负责。6.2 数据安全与合规底线这是团队使用大模型时最不能越过的红线。内部资料是否允许发送到外部模型服务这个问题需要法务和信息安全部门来评估。但有几个可以提前执行的默认准则敏感数据脱敏在输入提示词前移除身份证号、手机号、客户名称、密钥等敏感信息。最小权限数据交付只给模型完成任务所必需的数据不给全部数据。内部私有化部署如果业务数据足够敏感优先考虑使用私有化部署的开源模型。记录与审计LLM 调用链路应该纳入日志系统便于追踪数据流向和可能的安全事件。6.3 建立团队的 Prompt 评审机制Prompt 不是“随便写的一句话”它实际上是系统的业务逻辑。团队应该有评审机制。在团队协作里最不“体面”的事情是核心 Prompt 只存在于某个人的聊天记录里人一走业务就停了。应该把提示词纳入代码仓库管理。当业务需求变化时提示词变更要走评审流程和代码变更一样。团队内部可以约定提示词必须存入 Git 仓库作为项目资产。提示词变更要有变更说明。所有模型调用代码必须通过代码评审。模型版本升级时要有回归测试来验证输出质量。7. 常见的“LLM 失礼”行为与排查思路在实际使用中有一些高频问题值得单独列出来。下面整理了一份对照检查表你在自查时可以逐条对照。问题现象常见原因解决思路模型答非所问用户 Prompt 缺少具体约束和背景补充角色、任务、输出格式、约束条件回答不稳定每次结果差异大模型 temperature 参数设置不当Prompt 太泛将 temperature 降低到 0~0.3模板化 Prompt代码无法直接运行模型生成了“看起来对”的代码本地先跑测试确认依赖版本不要盲信API 成本失控Token 消耗无预算、上下文越长越大上下文裁剪、限制 max_tokens、启用日志监控本地推理显存不足模型精度选择不匹配硬件改用精度更低的检查点或量化模型知识库回答穿越向量检索未命中相关 chunk调整 chunk 大小、改进分段策略、增加 top_kAgent 调用工具报错工具描述不清晰模型传参错误完善工具描述为工具添加输入校验数据泄露风险未脱敏数据直接发送到外部 API建立脱敏流程敏感数据走私有化部署排查问题时建议按这个顺序来先确认输入是否清晰再检查参数配置然后看模型版本和精度最后检查下游处理逻辑。多数问题都出在前两环。8. 最佳实践清单最后把全文的要点收敛成一份可以在实际工作中直接对着做的清单。8.1 个人使用层面提问前先交代背景、任务、输出格式。复杂任务拆成多步不一次硬塞。对事实类输出保持怀疑特别是法律、医疗、金融领域。对代码输出先跑通再使用而不是直接部署。保存常用的高质量 Prompt形成自己的模板库。8.2 应用开发层面用 JSON 约束模型输出方便程序解析。用 RAG 降低幻觉不依赖模型记忆事实。给模型接入工具时工具描述要精确权限要最小化。对每次 API 调用做 Token 用量和耗时监控。Prompt 纳入版本管理与代码同步迭代。8.3 团队管理层面建立模型输出的人工审核机制。制定敏感数据使用大模型的合规边界。统一团队用的模型、参数和提示词规范。本地部署时选择合适精度平衡成本和质量。这份清单不是一步到位的终稿。LLM 技术和工具链演进非常快今天的最佳实践未来可能很快过时。但底层的方法论是稳定的清晰输入、审慎输出、控制成本、保障安全。最后想分享一个个人经验。刚开始接触大模型时我也觉得“会聊天就行”但随着项目深入发现真正拉开差距的不是谁更会用某个模型的某个功能而是谁更早建立起一套稳定、可复用、可管理的协作规范。LLM Etiquette 听起来是个很虚的概念但落到每天写 Prompt、调 API、评估结果的动作上它就是实打实的生产力。如果你也准备把大模型引入自己的工作流或业务系统不妨先把这篇文章里的清单逐条过一遍。把该省的 Token 省下来把该校验的结果校验好把该规范的流程规范化再大胆去用模型的能力。