电子产品世界

用大型语言模型构建让我明白了一个明确的道理：最好的AI功能往往是隐形的。

当它成功时，用户不会停下来想“那是人工智能”。他们只需点击一个按钮，快速得到回复，然后继续他们的任务。

当它不奏效时，你会立刻注意到：转盘花的时间太长，或者答案听起来自信但其实不是真的。我多次遇到这两堵墙。每次修复都不是关于“更智能的AI”，而是关于谨慎的工程选择。只使用你需要的上下文。要求有结构化的产出。当准确性重要时，保持低随机性。让系统说“我不知道”。

本指南不涉及大型研究理念。它讲述的是任何工程师都可以遵循的实际步骤，将开源的大型语言模型引入真实产品。可以把它当作一本实地指南。可以把它看作是一个现场指南，拥有简单的模式、可复制的代码和习惯，让AI功能感觉可靠、平静且快速。

工作原理——四步循环

每一个可靠的AI功能都遵循同一个循环。保持一致。无聊是好事。

1）阅读

只收集用户输入和你需要的最小应用上下文片段。更多的背景意味着成本更高，响应更慢，模型更容易偏离。

例子：

• 客服——“我的订单在哪里？”→传递用户ID和最后订单摘要，而不是完整的订单历史。

• 提取——“从此邮件线程中提取姓名和日期”→仅传递线程文本，不传递无关附件。

• 搜索——“查找退款政策”→传递文件中的前三段内容，而不是全部知识库。

2）约束

设定规则，确保模型保持在你期望的约束范围内。

• 系统提示符作为合同

• 说明助理是什么，什么不是

• 要求有效的 JSON 与模式相匹配

• 如果缺少信息，请请求用户简短的后续询问或回答“我不知道”。

• 保持隐私规则明确（不记录敏感数据）

• 修改提示并进行测试

• 温度与任务匹配（没有一个设置适合所有任务）

• 低（≈0.0–0.2）：提取、分类、验证、RAG回答并附引用、可靠的工具选择

• 中等：模板草稿与轻音色变化

• 高：头脑风暴和创意文案，多样性很重要

无论如何都要保持上下文紧密。如果你的栈支持，测试中使用种子以提高重复性。

3）行为

目标是产出可以作为下一阶段工作流程输入的LLM输出，无需进一步处理。

何时使用：

• 当下一步是程序化步骤时，结构化输出，例如用于更新界面、存储字段和运行验证。

• 为什么：这些输出作为工作流程或应用下一步的输入，无需进一步人工处理，是结构化、可解析的数据。

• 例：从发票中提取{姓名、日期、金额}。

• 当模型需要实时数据或触发代码控制的动作（如搜索、取物、计算、通知或连接外部系统）时，函数调用（工具）。

• 为什么：工具让模型能够使用新鲜信息，而不仅仅是依赖训练中学到的内容。这意味着它可以查询数据库、调用API，或查找最新记录而无需发明答案。模型提出动作，你的代码决定是否运行，你保持清晰的审计轨迹。

• 例：模型调用 search_docs（） 来查找相关文本，然后调用 render_chart（） 来创建可视化，最后向用户解释结果。

• 当结果仅为叙述性时，如摘要或简短回答，则使用纯文本。

• 为什么：当没有其他需要消耗输出时，最简单的路径。

• 提取时，显示匹配文本的简短预览。

• 在工具流中，显示哪些工具运行了什么顺序，然后把日志保留在服务器端。

4）解释

向用户展示步骤、工具和引用，让他们对应用生成的AI输出更有信心。

例子

• 附上简短的“我用了什么”注释，并注明来源标题或编号。以下复合模型展示了其答案，并附上了来源以保证清晰和信任。试试看这里。

• 提取时，显示匹配文本的简短预览。

• 在工具流中，显示哪些工具运行了什么顺序，然后把日志保留在服务器端。

你会重复使用的核心模式

领域特定语言（DSL）：一种为特定领域设计的小型语言。在应用中，这通常意味着搜索筛选、沙盒SQL查询、图表规范或电子邮件模板。

安全运输：测试、监控与后备方案

发布前：

• 写提示词单元测试，检查你预期的输出格式。对于 JSON，断言 required fields。对于纯文本，请检查关键词、结构、风格或拒绝短语。

• 从真实问题中建立一个小型评估集。包括预期结果和允许的拒绝情况。

• 在阴影模式或功能标志后运行，记录所有内容。

制作中需要跟踪的事项：

• 延迟p50和p95

• 代币的进出

• 模型和提示词版本

• 工具调用的成功与失败

• 无效的JSON速率

• 拒绝率

• 用户编辑率（比较模型输出与最终用户文本）

• 引用正确性（核对引用来源）

你可以在 Groq 控制台仪表盘中监控这些信号，该仪表盘会提供日志、指标、使用情况和批处理分析，帮助你了解 AI 功能在真实工作负载中的表现。

有效的后备方案

• 如果任务无法回答，则用下一步回答“我不知道”。

• 如果结果看起来很长或很慢，就先流式播放部分结果，并保持界面响应式。

• 在关键时刻使用小模型再大模型路由，大多数请求从更小、更快、更便宜的模型开始。如果输出不完整、不确定或被标记为过于复杂，则将同一请求升级到更大的模型。这样可以节省日常任务的成本和延迟，同时仍能以更强大的性能处理复杂的边缘情况。

常见陷阱与快速解决方法

• 太多上下文→只取你需要的东西然后重新排名。

• 让模型直接接触生产数据→始终使用工具和安全层。

• 所有事情都用聊天→很多工作更适合做简单的提取器或路由器。

• 冗长的回答会降低成本→偏好简洁的格式和结构化字段。

• 没有版本控制→每个日志行中都存储提示ID和模型版本。

一份你今天就可以使用的简短清单

• [ ] 写一个清晰的系统提示和严格的JSON模式。

• [ ] 为任务选择温度，并保持上下文紧密。

• [ ] 在UI或数据库更新前强制JSON验证。

• [ ] 添加一个工具，记录每次通话，并每周检查失败情况。

• [ ] 跟踪延迟、令牌、提示符和模型版本、拒绝以及无效 JSON。

• [ ] 用功能旗帜和简单的备选方案启动。

别忘了

无聊的AI功能是可靠的AI功能，用户感觉它们是隐形的——它们只是能正常工作。只读你需要的内容。用明确的规则来约束。用结构化输出和安全的工具行动。解释一下发生了什么。从最小的实用功能开始。使用适合你使用场景的图案。监控一切。改进基于真实用户行为，而非理论性能指标。目标不是打造令人印象深刻的AI演示。它是为了发布用户每天都依赖的功能。

关键词： AI LLM