原文：https://dev.to/hizba_cloud/mistakes-i-made-building-my-first-full-stack-ai-app-4o3j (作者 @hizba_cloud)
最近，我构建并部署了我的第一个端到端 AI 应用，过程远不如想象中顺利，充满了恐慌、终端错误刷屏和深夜调试。
以下是我犯下的 5 个主要错误，我的应用为何崩溃，以及我是如何恢复的。
1. 无限 Webhook / 异步循环
发生了什么：
为了让 UI 更具响应感，我启用了模型的流式响应。然而，我在前端组件内写了递归的状态更新，而后台 Webhook 也在无限触发。
测试运行 3 分钟后，我的本地开发服务器挂了，浏览器标签页内存溢出，电脑风扇像喷气式引擎起飞前一样嘶吼。
如何修复：
- AbortController 魔法：我实现了原生的 JavaScript Abort Controller，以便任何用户发起的发送或状态变更都能取消正在进行的 fetch 流。
- 状态锁定：停止在每个时刻将原始流内容直接存入应用状态。改为在本地缓冲数据，然后批量更新 DOM。
专业提示：即使 API 支持快速流式传输，也不意味着你的 React 状态需要为每个字符都更新一次！
2. 忽视速率限制和 Token 经济（50 美元的心脏病）
发生了什么：
在构建应用的自动化管道提示词和多智能体协调逻辑时，我完全忽视了速率限制和 Token 成本。测试时，我运行了一个测试脚本，忘记模拟 API 响应，开始每分钟向昂贵的重型模型发送数百个请求。第二天早上，我收到仪表盘的邮件，差点心脏病发作。
如何修复：
- 严格的缓存层：添加了严格的层缓存，使用简单的字典逻辑（在适用的情况下）以及 Redis 来处理更繁重的任务，确保相同类型的查询不会发送到付费 API 超过一次。
- 指数退避：在请求周期中添加了健壮的指数退避/重试逻辑和
sleep()延迟，以更优雅地处理429错误。 - 用量上限：在仪表盘上添加了用量上限和本地速率限制警告。
3. 盲目信任大语言模型（提示词注入、幻觉）
发生了什么：
我添加了一个辅助系统，AI 会解析用户输入的文本，并根据看到的内容执行系统级命令。当然，自测开始后的前 10 分钟内，一个奇怪的字符串输入就成功覆盖了我的系统提示词。AI 开始输出 Markdown 乱码，而不是按预期行事。
如何修复：
- 严格的护栏：我停止将原始用户文本放入提示词块，转而使用严格的定界符标签。我在系统命令边界上强制使用定界符，这样任何尝试修改它们的行为都会被捕获。
- Schema 验证：使用 schema 验证（JSON 模式）来确保如果模型尝试输出意外格式，在到达前端渲染引擎之前就会失败。
4. 部署时的 CORS 与环境变量噩梦
发生了什么：
在本地构建应用时，我们从不考虑 localhost 对请求是完全宽容的。当我将前端和后端（在不同平台上托管无服务器函数）部署上线时，噩梦开始了。控制台显示了关于 fetch 请求被 CORS 策略阻止的红色文本。更糟的是，由于环境配置不正确，我不慎在打包文件中暴露了 API 密钥。
如何修复：
- 后端代理：我将所有外部 AI API 调用都通过自己安全的后端端点进行路由，消除了前端任何 CORS 顾虑，并将 API 密钥隐藏在服务器端。
- 环境整洁：切换到
.env.local文件，并仔细检查了我的.gitignore和密钥管理器配置。
5. 在核心逻辑工作前过度设计 UI
发生了什么：
作为设计师和前端爱好者，我陷入了诱惑，花了整整 3 天来完善玻璃态 UI 效果、Framer Motion 页面过渡动画和深色模式切换动画，而这时我的后端甚至还没能返回一个 JSON 对象。当后端失败时，我不得不对美学组件进行大量重构，以修复底层数据结构。永远不要在无聊的功能代码完成前构建花哨的界面！
如何修复：
“先丑陋”原则：先构建丑陋的原型。确保 API 调用稳定、错误状态得到处理后，再引入任何美学设计。
最终思考：值得吗？
构建你的第一个端到端 AI 应用是一次令人谦卑的体验。你会搞砸事情，浪费 Token，并在凌晨 2 点盯着错误信息看。然而，这是无与伦比的学习经历，你应该拥抱它。
除非你快速连续发送了大量 API 请求，否则你不会真正理解速率限制。除非你因猛发 Webhook 请求而导致前端卡死，否则你不会学到状态管理。所以，如果你正在构建自己的 AI 应用，请拥抱这些 bug！它们是你正在做复杂且有价值之事的标志。
原文：https://dev.to/hizba_cloud/mistakes-i-made-building-my-first-full-stack-ai-app-4o3j (作者 @hizba_cloud)
