前不久，我在X（原 Twitter）的时间线上刷到一个非常有趣的项目，它完全由 Google Gemini 3 Pro 在 Google AiStudio 中生成。
这个项目是一个中国传统风格的“在线求签”应用。用户点击页面上的“摇签”按钮，页面中间的“签筒”动画开始快速摇动；十几秒后，掉出一支签，随后生成签文，以及对签文的解读。
出于好奇，我下载了开源的项目代码，发现整个项目由 React 实现，编译后支持部署到Cloudflare Pages上 （演示地址： https://kaucim.obodo.fun/ ）。在本地浏览器测试时，动画流畅，功能完美。
然而，当我把链接地址分享给朋友后，很快收到了反馈，点击“摇签”按钮后，屏幕上的“签筒”会一只摇动，始终没有停止。
没想到，这个意外的 Bug，开启了我对完全由 AI 生成代码的一次深度审查和重构之旅。
⚠️ 危机浮现：AI 代码的两个致命缺陷
接到反馈后，我立刻打开浏览器开发者工具（DevTools），检查 Network 请求和 Console 日志，很快发现了问题所在。
网络连通性问题
这个纯前端项目，在点击“摇签”按钮后，是 从浏览器端直接请求 Google Api 。
众所周知，Google 的 Api 服务在有些区域是无法直接访问，除非用者的网络具备科学上网的能力，否则请求等待较长时间，直到超时，这就导致在整个等待过程中，前端逻辑卡死在“摇动中”状态。
致命的安全漏洞：API Key 裸奔
在检查 NetWork 请求载荷时，我发现了一个致命的安全漏洞。 ** 请求 Google API 所使用的 API Key，竟然明文包含在前端发送的请求中。**
这意味着，任何访问我网站的人，都可以轻易获取我的Key。如果有心人利用这个 Key 去做其他API请求，我可能就会在月底收到一张金额数目不小的账单，甚至面临配额被滥用的风险。
🛠️ 架构重构：从 Golang 到 Serverless
显然，AI 生成的代码虽然“能跑”，但在可用性和安全性方面是不合格的。解决这两个问题的核心思路是：将纯前端架构改为“前端+后端”分离架构。
- 隐藏 Key: 后端服务持有 API Key, 前端只负责展示，不接触敏感信息。
- 网络中转： 由后端服务发起对 Google API 的请求，并将返回的数据返回给前端。
原始方案：传统 VPS + Golang
在我过往自己开发的项目中，如果是需要做前后端分离项目，都会选择前端使用Vue3，后端使用Golang。所以当时第一反应，写一个 Golang 服务，部署到闲置的VPS上，对外提供 RESTful API 接口。
但是这个项目，前端使用的是 React。对 React 完全不熟悉的我，只好在 Google Antigravity 中，把重构方案提交给 AI，希望它帮我完成前端代码的改造工作。
结果 Gemini 3 pro 思考之后，给了我更好的方案。
重构方案：Cloudflare Pages Functions
Google Antigravity 帮我重构的方案，是使用 Cloudflare Pages Functions 替代 Golang 服务，重构前端代码，再部署到 Cloudflare Pages 上。
Cloudflare Pages Functions 运行在 Cloudflare 的全球边缘网络（Edge Network）上，实际上是 Cloudflare Workers 技术的应用，代码会在离用户最近的节点执行，提供低延迟的无服务器计算。
它们是为 Pages 体验定制的 Workers，处理动态功能、与存储集成和后端逻辑，无需管理服务器。
当部署在Cloudflare Pages上的静态网站，需要调用服务实现动态功能时，会调用 Cloudflare Pages Functions。这样既省去了运维服务器的麻烦，又能享受全球CDN的低延迟优势，而且对于个人项目来说，免费额度通常绰绰有余。
💻 重构过程：AI 结对编程
确定方案后，我开始在 Google Antigravity 中进行“结对编程”。
- 后端实现：我要求 AI 编写一个 Functions 脚本，用于转发请求到 Google Gemini API。
- 前端改造：让 AI 修改 React 代码，将原本指向 Google 的请求，改为指向
/api/ask（即我的 Pages Functions 地址）。 - 环境配置：Gemini 指导我创建目录结构，并配置 Wrangler 环境变量，确保 API Key 安全地存储在 Cloudflare 后台，而非代码中。
在这个过程中，尽管我不熟悉 React，也没通读过 Pages Functions 的文档，但在 AI 的辅助下，我仅用极短的时间就完成了从“纯前端”到“前后端分离”的架构升级。
🛡️ 加固防线：引入 Cloudflare Turnstile
重构完成后，虽然 Gemini API Key 不再直接暴露在浏览器中，但接口本身还是公开的。并且这个项目是免费，且不需要用户注册登录就可以使用的。如果被恶意爬虫或脚本等无限制的访问，不仅消耗我的 Gemini API 额度，还可能耗尽 Cloudflare 的免费请求数。
我再次询问 Gemini：“如何以最低成本防止接口被滥用？” 它给出了最佳实践：Cloudflare Turnstile。
什么是 Cloudflare Turnstile?
Cloudflare Turnstile 是一个智能验证服务，旨在取代传统的 CAPTCHA 验证码。它通过在后台进行一系列非交互式测试（浏览器行为、设备指纹等）来区分人类和机器人，提供“无感”的验证体验。
集成过程异常丝滑：
- 前端：Gemini 帮我在 React 组件中引入了 Turnstile Widget。用户在点击“摇签”前，Turnstile 会自动完成验证并生成一个临时 Token。
- 后端：在 Pages Functions 中增加一段中间件代码，校验请求头中携带的 Token。如果 Token 无效或过期，直接拒绝请求，不再调用昂贵的 AI API。
🎉 最终效果与复盘
经过一番折腾，KauCim 项目终于完成了蜕变：
- ✅ 可用性提升：无论用户身处何地，都能流畅使用摇签功能（由 Cloudflare 边缘节点代为请求）。
- ✅ 安全性闭环：API Key 存储在服务器端环境变量中，彻底杜绝泄露风险。
- ✅ 防滥用机制：Cloudflare Turnstile 成功拦截了自动化脚本，保护了我的钱包。
写在最后
这次经历让我对“AI 编程”有了更深的理解。
AI 是很好的助手，也是漏洞的制造者
AI 生成的代码非常高效，但它往往是“功能导向”而非“工程导向”的。 AI 能够快速实现“从 0 到 1”，但在安全性、架构合理性以及边界情况处理上，依然需要人类开发者的经验去把关。
如果你也正在使用 AI 生成代码，请务必多留一个心眼：检查你的 API Key，别让它在互联网上“裸奔”。
AI 是很好的助手，也是很好的老师
以往与 AI 协作开发，都是在我已经熟悉的技术栈上进行的，基本架构都遵循了我之前的逻辑。
但是这次因为前端代码使用 Reaxt 实现，我让 AI 拥有了更多的主导权。它教会了我在使用Cloudflare Pages时，如果需要一些简单的后端逻辑，只要用Cloudflare Pages Functions即可，不需要再去服务器上部署后端服务。这样的方式，在以后的项目中，我会多多尝试。