十分钟承诺，以及人们不愿说出口的事
关于“10 分钟内在你的应用中构建 AI 聊天”这件事，每个人都假装相信它——直到计时开始。然后，我们会遇到常见的一些问题：API 密钥、令牌限制、回调地狱、神秘的延迟、合规性检查清单，以及不可避免的“再添加一个库”。十分钟？你可以在十分钟内煮杯咖啡。但通常无法完成交付。
但这里有个转折：如果你停止围绕流行语进行仪式性的舞蹈，并专注于“AI 聊天”的实际含义——一个用户界面、一个状态机，加上一个你无法控制的远程大脑，那么你可以非常接近目标。这不是魔法；这只是带有更好自动完成功能的管道。
这是一份操作指南，带有一种怀疑的视角，旨在 10 分钟内在你的应用中构建 AI 聊天。不是“一个季度的企业转型”。不是“数字战略”。十分钟内实现一个可工作的、可交付的切片：一个文本框、一个记录、一个请求、一个响应，一点持久性，以及——如果你不想给过去的那些产品经理留下深刻印象——一两个智能的护栏。你想要速度和清晰度。其他一切都是可选的，而且通常是陷阱。
“AI 聊天”的真正含义（以及它不是什么）
当人们说“AI 聊天”时，他们会将三个层次混为一谈：
- 聊天 UI：文本框、发送按钮、输入指示器和一个回溯记录。
- 对话状态：谁说了什么，以什么顺序说的，以及足够的上下文，以避免每次回复都显得语无伦次。
- 模型 API：你向它提供消息，它会返回文本（可能是函数调用），你通过流式传输 tokens 来获得快速的体验。
其他一切都是品牌宣传：代理、副驾驶、助手——对于同一个循环来说，这些都是不错的词。这里的陷阱是，在你的应用需要工作层之前，就假装它需要营销层。你不需要。从循环开始。然后交付。
10 分钟构建：你实际上可以在一次完成的事情
“10 分钟内在你的应用中构建 AI 聊天”并不是承诺在站立会议期间解决 AI 对齐问题。这是一个承诺，让你的应用做一些用户立即理解的事情：提问、回答、重复。如果你集中精力，检查清单很短：
- UI：一个用于用户消息的文本区域、一个发送按钮、一个记录列表和一个输入指示器。添加乐观渲染以提高响应速度。
- API 调用：使用系统提示和滚动上下文窗口访问你选择的模型端点。随着 tokens 的到达，将响应流式传输到 UI。
- 存储：为对话保留一个简短的记忆。积极地进行修剪。如果你喜欢花哨的东西，可以缓存嵌入；如果不是，只需存储最近的十几个回合。
- 护栏：超时、重试和一个字符限制。就是这样。第一天不要使用鲁布·戈德堡机械。
- 可观测性：记录时间、令牌使用情况和失败次数。你调试的第一件事不是模型，而是你的管道。
这就是循环。循环就是应用。
选择模型，避免被炒作淹没
你不需要和一个模型结婚；你需要交付一个消息循环。选择一个具有合理的文档、流式传输支持和可预测延迟的 API。“最佳模型”是情境性的。对于客户支持摘要，更小、更快的模型可以胜过思考过度的聪明的大型模型。对于代码，质量很重要；对于 UI 的精妙之处，速度是关键。最重要的是：将模型置于你控制的界面之后，这样你就可以在世界发生变化时更换它——因为它会的。
你真正需要的最小代码
你可以在任何技术栈中连接它，但形式永远不会改变：
- 客户端：防抖输入，显示输入指示器，增量流式传输 tokens。
- 服务器：持有 API 密钥。构建一个简单的 POST 端点：消息输入，消息输出。添加一个 20-30 秒的超时。
- 存储：保留最近的回合。避免保存整部小说。你的用户不会在聊天框中写《无尽的玩笑》。
它是“生产环境”吗？如果你的错误处理不是耸肩表情，那就是。生产环境只是“不会在凌晨 3 点叫醒我”的另一种说法。
每个人都跳过的技巧：让它感觉很快
速度是一种感知。模型可能很快，但如果在流式传输开始之前 UI 卡住，它会感觉很慢。并非技巧的技巧：
- 一旦你获得第一个 token，就开始流式传输。显示光标。人类的阅读速度比模型的输入速度快——所以让他们看。
- 在流式传输时显示结构。如果模型返回项目符号，则增量渲染项目符号。空白是敌人。
- 保持往返行程短。 “让我调用五个工具才能回答”的代理演示在主题演讲中效果很好，但在现实世界中会失败。
如果你什么都不做，也要尽早并始终流式传输。
真正有帮助的护栏（并且不会将你的应用变成警察）
你需要一些规则，而不是道德哲学：
- 最大输入 tokens，最大输出 tokens。你的预算有限制，用户的耐心也是如此。
- 削减上下文。将其保持为最近的 N 次交流和一个简短的系统提示。如果你需要长期记忆，稍后再进行设计。
- 超时。如果模型停滞不前，你就不会。优雅地失败并保持 UI 响应。
礼貌的错误胜过永远不会到达的完美答案。
如何在 10 分钟内构建 AI 聊天：一个直白的配方
这是每个人都滚动到的部分。
- 使用 flex 列和粘性页脚输入。不要花哨。默认情况下使其适合移动设备。
- POST /chat: { messages: [...] }
- 在服务器上添加你的系统提示，而不是在客户端上。将块作为服务器发送事件或 WebSockets 流式传输。
- 将消息作为 role 传递：user/assistant/system。从小处开始。
- 保留最近的 8-12 条消息对。截断旧消息。不要想太多。
- 如果你必须添加上下文，将较早的回合总结为单个系统注释。
- 20 秒超时。512–1,024 token 输出上限。
完成。不是火箭飞船——只是一个你的用户立即理解的聊天循环。
“Lovable App”中的“Lovable”
“Lovable”是一个很高的标准。你无法从模型规格表中获得 Lovability；你只能从品味中获得。每天都会交付的精雕细琢的细节：
- 在重新加载时保持状态。如果用户刷新并且他们的对话消失了，你就教会了他们不要信任你。
- 合理的默认值。除非你的用户是研究人员，否则不要询问 temperature 或 top_p。大多数人只是想要一个好的答案。
- 人性化的语气。你的系统提示不应该读起来像人质便条。坦率地说。用户不需要在每次回复中看到你的品牌宣言。
- 尊重键盘。 Cmd/Ctrl+Enter 发送。 Escape 取消。箭头键表现正常。现在不是 2009 年。
使 UI 变得美观，用户会原谅平庸的答案。使其变得笨拙，即使模型是天才，他们也会跳出。
你希望早点完成的无聊部分
只有三件无聊的事情可以使 AI 聊天持久：
- 可观测性：跟踪延迟、错误代码、token 消耗和用户在流式传输中途的流失。如果你不衡量，你就是在猜测。
- 隐私：将 PII 保留在日志之外，并且不要将原始提示喷洒到第三方仪表板中。默认值应该是保守的。
- 速率限制：保护自己免受滥用和意外循环的影响。 10 分钟构建，如果你跳过它，则需要 10 个月来清理。
最好的应用程序使无聊的部分对用户不可见，但对开发人员来说却非常明显。
一个很大的误解：你在第一天就需要“代理”
你不需要。当存在确定性工具时，工具使用就很棒。获取日历事件？完美。总结 PDF？很好。但是，伪自治链会游荡 45 秒来做谁知道的事情？用户不会为之鼓掌。将工具置于明确的意图之后。如果模型需要调用函数，请调用它。如果不是，则回答并继续。 “Agentic”不是一种个性；它是一种控制流。
关于 RAG：检索可以提供帮助，而不是科学展览项目
RAG——检索增强生成——可以区分听起来很聪明的模型和真正聪明的模型。但这也是一个兔子洞。一个明智的第一步：
- 在保留结构的情况下对文档进行分块。段落、标题、标题很重要。
- 检索 5-10 个相关块。提供引文。不要让模型淹没在无关紧要的琐事中。
- 缓存你能缓存的内容。大多数用户都会问相同的五个问题。
如果你的“10 分钟”范围包括 RAG，那么你已经花费了 20 分钟。保持可选；稍后再进行连接。
安全性和合规性，而无需将应用程序翻过来
显而易见但经常被跳过：
- 不要将 API 密钥发送到客户端。永远不要。你的服务器调用模型。
- 静态加密任何你不好意思泄露的内容。假设日志会泄露。
- 为用户提供一个“忘记此对话”按钮。这既符合道德规范，又具有实际意义。
合规性不是一种氛围；它是一份检查清单。如果你要卖给有委员会的公司，请雇用一个喜欢检查清单的人。
工具实际上有帮助的部分
大多数“AI 平台”的宣传都归结为三个承诺：速度、护栏和分析。一半可以提供其中之一；很少有人能全部提供。 Sider.AI 实际上在痛点上有所帮助：启动感觉原生的 AI 聊天，流式传输速度快，并且不会让你的开发人员使用五个 SDK 玩 Twister。将其用于其擅长的方面——快速连接、可重用的提示、合理的默认值和你不必眯着眼睛看的日志——然后随着你的成长，换入你自己的具体内容。如果你需要一个快速启动，这是一个难得的工具，它不会要求进行一周的会议来做你可以在一个下午完成的事情。 诀窍不是外包你的产品品味；而是外包你原本会糟糕地重建的苦差事：token 计数、流式传输怪癖、无聊的重试以及你发誓要在“下一个 sprint”中完成的仪表板。
使十分钟花费十天的常见陷阱
一个经典的自摆乌龙的简短列表：
- 试图成为 ChatGPT。你正在构建一项功能，而不是一个平台。狭隘的用途胜过通用性。
- 阻止“完美”模型选择。在你服务器后面抽象提供程序，然后继续。
- 在第一天编写自定义 token 计费器。这是一个以后的问题。限制响应并交付。
如果你争论模型政治而不是用户流程，那么你就迷失了方向。
真实的十分钟配方，带有理智检查
- 第 1-2 分钟：搭建 UI。底部输入，上方记录，输入指示器占位符。
- 第 3-4 分钟：添加一个 /chat 服务器路由。持有 API 密钥。系统提示设置为描述助手的单个句子。
- 第 5-6 分钟：连接模型流式传输。 Token 块通过 SSE 输出；客户端附加到最后一个助手气泡。
- 第 7 分钟：在服务器端（或首先在本地，然后同步）存储最后 10 条消息。截断。
- 第 8 分钟：添加超时和一次重试。如果两者都失败，则显示一个友好的内联错误，并带有一个重试按钮。
- 第 9 分钟：记录延迟和 token 计数。今天的控制台日志，明天的真实日志。但要记录一些东西。
- 第 10 分钟：润色感觉——在发送后聚焦输入，自动滚动记录，立即显示输入气泡。
就这样。它 Lovable 吗？还不是。但它是可交付的，这是找到 Lovable 的唯一方法。
针对你的实际应用程序进行调整（因为“通用聊天”是一种欺骗）
- 文档应用程序？偏向于引用和内联摘要。用户想要收据。
- CRM？保持回复简短且可操作。不要写读起来像 AI 写的电子邮件。
- IDE？首选确定性。显式显示工具调用和结果；将模型置于控制之下。
- 移动设备？延迟是罪魁祸首。积极缓存。部分渲染每次都胜过 spinners。
重点：AI 聊天是一种功能，而不是目的地。让它很好地完成一项工作。
如何使其感觉像你的产品，而不是其他人模型的皮肤
- 声音：编写一个段落风格的系统提示，听起来像你。然后停止。
- 摩擦：不要要求用户选择模型。他们来使用你的应用程序；他们不是来成为你的 ML 运营团队的。
- 持久性：保留正确的记忆。存档其余部分。杂乱的历史是使你的应用程序感觉廉价的最快方式。
- 本地习惯：尊重平台约定。在 iOS 上，滑动姿势和安全区域。在 Web 上，键盘快捷键和选择行为。
品味是唯一持久的护城河。
何时不构建 AI 聊天（或：怀疑论者的插曲）
- 如果你的用户不提问。不要在按钮更好的地方添加聊天框。
- 如果你的产品的核心工作是确定性的。没有人想要一个概率计算器。
你可以支持 AI，但仍然对聊天说不。这不是勒德分子；这是产品意识。
安静的力量：约束
从最佳“AI”功能中获得的重要经验：他们经常说不。将模型约束到你的领域。保持提示简短。如果可能，在你的应用程序的本机 UI 中显示结果，而不是在记录中。你越缩小目标，模型就越能击中目标。它不是“通用智能”；它是具体的有用性。
重新审视交付
可交付胜过有抱负。一个整洁的 10 分钟构建证明了循环有效。然后在重要的地方进行迭代：速度、适合性和感觉。你可以稍后更改模型。你可以稍后添加工具。当你有值得保留的记忆时，你可以重构记忆模型。你无法修复的是因第一次体验感觉像是从主题演讲中逃脱的演示而导致的用户信任丢失。
所以，是的，你可以在 10 分钟内在你的 Lovable 应用程序中构建 AI 聊天。如果你指的是一个真实的、可工作的循环。如果你指的是品味胜过剧院。如果你指的是流式传输胜过悬念。其余的只是打磨。
如果你对样板文件过敏（合理），那么像 Sider.AI 这样的平台可以为你节省时间：快速连接、合理的流式传输默认值以及当你超出脚手架时的一个逃生舱口。像使用好的 UI 工具包一样使用它——保留优雅的部分，替换不优雅的部分。目标不是承诺效忠；而是以尽可能少的车轮再发明来实现“有效”，然后实现“感觉良好”。 或者你可以手动完成所有操作。这很好。只是不要忘记输入指示器。
一个不太完整的结论
承诺不是 AI 将你的产品变成科幻小说。承诺是你可以让你的应用程序像一个乐于助人的人一样回答问题——并且现在就做，而不是下个季度。十分钟可以让你获得循环，而循环可以让你获得反馈。之后，就是品味和迭代。
如果这听起来很无聊，那就对了。无聊是 Lovable 的所在地。
常见问题解答
Q1: 你真的可以在 10 分钟内将 AI 聊天构建到应用程序中吗？
是的——如果“构建 AI 聊天”是指一个工作循环：输入、上下文、模型调用、流式传输和一个记录。 sprint 关注的是速度和清晰度，而不是在回答之前查询 12 个工具的巴洛克代理。
Q2: 添加流式 AI 响应的最简单方法是什么？
使用服务器发送事件或 WebSockets 将 tokens 从模型流式传输到你的聊天 UI。在第一个块上开始渲染——感知速度比稍后挤出几毫秒更重要。
Q3: 我需要 RAG 或代理来获得基本的 AI 聊天功能吗？
不需要。检索和工具使用是升级，而不是先决条件。首先交付聊天循环；当你拥有真实内容和一个超出“在演示中听起来很酷”的原因时，添加检索。
Q4: 如何保持 AI 聊天快速且经济实惠？
限制上下文，积极修剪并流式传输响应。较小、更快的模型通常在常见任务中获胜，并且通过服务器抽象交换模型可以使你摆脱供应商锁定。
Q5: Sider.AI 在 10 分钟构建中扮演什么角色？
Sider.AI 可以帮助处理不吸引人的部分——流式传输、护栏、日志和快速连接——因此你的团队可以专注于 Lovable 应用程序的细节。像使用好的脚手架一样使用它：依靠它，然后在扩展时替换部件。 
