从拼凑原型到架构重构：Syntax AI 的演进

每个开发者的成长历程中都会有这样一个时刻：你看着一个月前自己写的代码，心想： “谁让我碰键盘的？”

查看 Syntax AI v13 时，我就有这种感觉。

Syntax 是嵌入我个人作品网站的定制 AI 助手。v13 表面上已经能用：可以回答问题，有深色模式，也完成了基本任务。但内部实现相当杂乱。我直接从 Cloudflare Worker API 返回数千行 HTML 与 CSS；为了避免数据库承压，使用 setTimeout 人为延迟请求；还有一些臃肿的“记忆”类，只增加了 CPU 开销。

它是一个能工作的实验原型，但我希望进一步把它整理为职责清晰、能够应对故障的微服务。

以下记录了我如何在资源限制下，将它重构为 Syntax v15.6，并继续向 v16 演进：引入故障恢复、负载分配与边缘计算，同时将当时的运行费用维持在 0.00 美元。

前后端解耦：Next.js 15 前端

v13 版本的第一个致命缺陷就是单体架构。我的 Cloudflare Worker 试图同时扮演数据库、AI 编排器和前端 Web 服务器的角色。

在 v15／v16 重构中，我把前端从 Worker 中独立出来，迁移到 Next.js 15 App Router 应用。React 前端结合服务器端渲染（SSR）与 JSON-LD 结构化数据，改善技术 SEO 与搜索引擎对内容的理解。我也重构了主题切换逻辑，处理无样式内容闪烁（FOUC）与水合过程中的布局偏移。

前端专注于界面和交互，通过 JSON 与后端通信；后端则专注于 AI 请求与数据处理。

后端重构：Cloudflare Workers 与 Llama 3.3

Worker 不再承担界面服务后，我开始整理 AI 后端。项目当时需要适应 Cloudflare 免费套餐的限制，包括 10 毫秒 CPU 时间与每次调用 50 个子请求，因此必须控制每次请求的工作量。

1. 带熔断机制的负载分配：在 v13 中，一旦 Groq API 触发速率限制，机器人就可能超时。到了 v16，我加入了带熔断机制的轮询调度：维护多个 API 密钥，并在每次请求前打乱顺序，以分散请求。当某个密钥返回 429 Rate Limit 时，Worker 会用 Map() 将其标记为冷却 60 秒；后续请求直接跳过冷却中的密钥，减少反复请求同一受限密钥带来的等待。

2. 混合内存引擎（克服 3043 错误）此前，我尝试把较长的博文拆成语义向量片段。输入体积过大时，Cloudflare 嵌入模型会返回 3043: Internal server errors；而单篇文章拆成 10 个片段，再加上其余处理请求，也很容易耗尽 50 个子请求的额度。

为了适应 Cloudflare 的资源边界，我设计了一个混合记忆系统：

• 向量检索层：每篇文章只为经过清理、限制在 500 个字符的摘要生成一个嵌入向量。这部分需要 1 个子请求，并能降低长文本输入导致模型报错的风险。
• KV 全文存储层：为了保留文章深处的分析或技术栈等细节，我将整篇约 8,000 个英文单词的原始文本存入 Cloudflare KV。

3. 交叉注意力重排序我构建了结合两种检索方式的 RAG（检索增强生成）引擎。面对复杂问题，系统先结合对话上下文改写查询，补全代词所指向的对象，再并行执行面向概念的语义向量检索和面向具体细节的 KV 关键词检索，融合得分后，将相关上下文交给 Llama 3.3。

4. “智能同步”前端编排器另一个瓶颈是单次执行的资源限制。一次同步 50 个作品集项目，会使脚本超出限制。

我把编排循环移到 Next.js 管理界面：先向 Strapi CMS 查询“一共有多少个项目？”，再按每批 5 个项目逐次发送给 Cloudflare Worker。Worker 处理完一批便结束该次连接，随后接收下一批。这样，每批请求都拥有独立的子请求额度，可以逐步扩大索引，而不必在一次调用中处理全部数据。

要点总结

重构后的 Syntax v16.0 职责更清晰，也补上了 CORS 来源校验、基于 IP 的异步速率限制与 URL 解析等机制，并清理了不再使用的代码。

通过接受免费版无服务器架构的极端限制，我被迫学习大型平台如何处理负载均衡、并发和数据编排。有时候，没有预算反而是架构设计方面最大的优势。

想体验一下？点击右下角的聊天气泡，贴入我的一个项目链接，让 Syntax 帮你分析。