如何为你的应用添加AI功能

要为你的应用添加AI功能，就从服务器调用大语言模型（LLM）API：把清晰的指令和相关数据一起发送过去，然后使用返回的结果。大多数有用的功能都属于四种模式之一：摘要、聊天、结构化数据提取和分类。每一种模式只需几十行代码，AI构建器通常都能替你写出来。真正决定功能好不好的，是调用周围的工作：把API密钥保留在服务器上、控制每位用户的成本，以及在信任输出之前先进行检查。

支撑大多数AI功能的四种模式

提取和分类往往最有价值，却也最不显眼。它们每处理一条记录都能悄悄节省别人几分钟，而且因为输出是固定格式，可以自动检查。聊天最显眼，却也最难做好，它有自己的专门指南：如何构建AI聊天机器人应用。

它如何融入你的应用

每种模式的结构都一样：

1. 用户采取行动：点击“总结”、上传文件、发送消息。
2. 前端调用你自己的服务器，而不是AI服务商。
3. 服务器构建请求：系统指令、用户输入，以及模型需要的、来自你数据库的数据，且只包含该用户有权查看的数据。
4. 服务器调用LLM API，密钥保存在环境变量中。
5. 服务器检查响应：是否为有效JSON、是否属于已知标签、长度是否合理，然后保存或返回。
6. 前端展示结果，较长的回答会随着返回逐步流式显示。

第4步中的密钥位于服务器上，永远不会到达浏览器。如果你对API这个概念还不熟悉，什么是API是一篇简短的入门介绍，而如何使用LLM API会更深入地讲解token、模型和密钥。

选择服务商和模型

OpenAI、Anthropic、Google等主要服务商都提供文本API，接口形式大致相似。选择时可以考虑以下问题：

• 在你的任务上的质量。 用你应用中的几个真实示例，在两三个模型上分别试一试。在你自己的数据上，模型之间的差异通常比通用基准测试更明显。
• 规模与成本。 服务商既提供能力更强的大模型，也提供更小、更便宜、更快的模型。分类和简单提取往往用小模型就能做好；长篇推理或细腻的写作可能需要大模型。
• 结构化输出。 对于提取和分类，优先使用服务商提供的、让模型按你给出的模式返回JSON的API功能，而不是解析自由文本。
• 数据处理。 阅读服务商条款，了解API输入是否会被存储或用于训练，以及这是否适合你的用户提供的数据。
• 限额。 新账户的速率限制通常较低，上线前请先确认。

模型名称和价格变化很频繁，因此代码应从配置中读取模型名称，而不是在多处硬编码。

分步添加一个功能

以一个示例说明：一个小型CRM，每个联系人都有很长的备注记录。

1. 保存密钥。 在服务商后台创建密钥，并把它保存为服务器端密钥，例如 OPENAI_API_KEY 或 ANTHROPIC_API_KEY。

2. 先要一个范围明确的功能：

在联系人页面添加一个“总结”按钮。在服务器上，用名为 [ENV_NAME] 的密钥把该联系人最近的20条备注发送给 [PROVIDER]，指令是写三个要点：当前状态、未解决的问题、下一步。只包含登录用户有权查看的备注。显示加载状态，保存带时间戳的摘要，并在调用失败时显示“暂时无法生成摘要”。绝不要把密钥发送到浏览器。

3. 在能省去打字的地方加入提取：

当用户把邮件签名粘贴到“快速添加”框中时，在服务器上调用 [PROVIDER]，使用服务商的结构化输出功能返回包含姓名、公司、职位、邮箱和电话的JSON。在服务器上校验JSON，用它预填新建联系人表单，并让用户在保存前进行编辑。无法确定的字段留空，不要猜测。

“让用户在保存前编辑”是关键：模型负责提出建议，最终由人决定。

4. 在后台分类：

有新的支持工单到达时，把它归入以下且仅一个类别：账单、缺陷、功能请求、账户访问、其他。使用小型、低成本的模型。如果返回的不是这些标签之一，就存为“其他”。把标签显示为可编辑的标签。

5. 用杂乱的真实数据测试：很长的备注、空备注、其他语言、没有电话号码的签名，上线前把20条输出并排查看。

写出有效的指令

每次请求都附带的指令（通常称为系统提示词）决定了质量的高低。

• 说明它是为谁服务的，以及什么样才算好。 “摘要会在打电话前由销售人员用10秒钟阅读”能给模型一个明确目标。
• 固定格式。 确定的项目符号数量、长度上限、字段和标签。
• 说明不确定时该怎么做。 “如果备注中没有提到下一步，就写‘未记录下一步’。”这能减少模型编造答案。
• 为提取和分类提供两三个示例，展示好的输入和输出。
• 把指令与用户内容分开，并清楚地标明用户内容，让模型能区分两者。

把提示词保存在代码库的文件中，这样它们就和其他代码一样有版本记录、便于审查。

控制成本

LLM API按token收费，即发送内容和返回内容两部分的小段文本。成本随每次请求的上下文量增长，并乘以运行频率。实用的控制方法包括：

• 只发送必要的内容。 发送最近20条备注，而不是整个历史。长文档要裁剪或拆分。
• 使用能完成任务的最小模型。 在默认使用最大模型之前先测试。
• 用API的最大token设置限制输出长度。
• 缓存结果。 保存摘要，只在源内容变化时重新生成，而不是每次打开页面都生成。
• 为每位用户设限。 按账户或套餐设置每日上限，防止单个重度用户或某个脚本耗光账单。
• 对该接口做速率限制，就像对其他开销大的路由一样。
• 在服务商后台设置预算或提醒，并在上线后每周检查用量。
• 按功能记录token用量，这样你就知道每个功能各自花多少钱。

如果AI功能是你产品的核心，请把它们的运行成本计入定价，而不是自己默默承担。

安全与信任

AI的输出具有概率性。它可能出错，却听起来很自信，而且可能被它所读取的文本引导。因此要针对这些情况进行设计：

• 把输出当作不可信的输入。 校验结构，在渲染为HTML之前进行转义，绝不把它当作代码或数据库查询来执行。
• 对于有后果的操作，保留人工参与。 例如发送邮件、修改记录、退款。模型起草，由人来确认。
• 防范提示词注入。 文档或消息中可能包含“忽略你的指令”之类的文字。把模型能看到的内容限制在当前用户可以看到的范围内，并且不要给它可以执行敏感操作的工具，除非你的代码先检查过权限。
• 标注AI生成的内容，让用户知道摘要或建议是生成的，并可以进行核对。
• 妥善处理失败。 服务商会出现故障或达到速率限制。应设置超时，显示清晰的提示，并让应用的其他部分继续正常工作。
• 留意用户发送的内容。 对于开放式文本输入，可以考虑加入内容审核步骤，并在隐私政策中说明内容由第三方AI服务商处理。

更完整的检查清单见AI构建应用安全检查清单。

常见错误

• 一开始就做通用聊天机器人，而一个“摘要”或“分类”按钮能让更多人受益。
• 把密钥放在前端代码中，或放进公开的代码仓库。
• 把整个数据库当作上下文发送，这既慢又贵，还可能暴露其他用户的数据。
• 信任自由文本输出，而本可以用模式或固定标签让结果变得可检查。
• 没有按用户设限，直到第一张账单到来时才发现问题。

在Mythex中添加AI功能

在Mythex中，你可以在聊天里要求在应用中添加AI，并使用你自己的服务商密钥。把密钥保存为项目密钥：当代理需要时，Mythex会在聊天中显示密钥卡片，这样你就不必把密钥粘贴到对话中。随后代理会编写服务器路由、提示词和界面。你的应用的AI用量由你的服务商计费，与你构建时花费的Mythex积分分开。文档中有一个起始提示词，见使用你自己的API密钥添加AI功能。

常见问题