一次 EdgeOne Pages + AI 辅助开发的真实踩坑记录
最近刷短视频，偶然看到了腾讯云 EdgeOne Pages 的介绍，感觉挺有意思的，部署简单，全球加速。正好我一直想自己搭一个“一言”API，既能方便自己调用，也能练练手。于是，一个新计划就诞生了：全程用 AI 来开发，并把它部署到 EdgeOne Pages 上。
这个想法听起来很酷，但整个过程充满了意想不到的曲折，从最初的雄心壮志到部署时的抓狂，再到最后的柳暗花明，实在是一段值得记录的经历。
💡故事的开始：一个简单的目标
我的目标很明确：创建一个名为 One Sentence API 的服务。它不仅能随机返回一句鸡汤或诗词，还要支持增删改查（CRUD），并带有一个简单的密码认证后台管理页面。
我把这个需求一股脑地丢给了 AI：
"嘿！帮我用
Node.js创建一个一言 API，要支持完整的CURD，带密码保护，还要有个漂亮的现代化前端管理界面！"
这次 AI 给我生成的，是大家都很熟悉的 Express.js 框架。代码看起来很标准，结构也很清晰。
😵第一阶段：本地是龙，线上是虫
AI 生成的项目在本地环境中表现堪称完美。前端展示页赏心悦目，所有 API 接口——包括需要密码认证的后台增删接口——都能通过前端管理页面正常操作。我用浏览器把所有功能都测了一遍，一切顺利。
我心想：“这不就成了？” 然后，自信满满地部署到 EdgeOne Pages 。
然后，噩梦就开始了 😱
部署成功后，我打开线上地址，发现前端展示页和最基础的随机获取句子接口是好的。但是，那个用 Express.js 路由搭建的后台管理页面彻底失灵。页面上的所有 API 请求，比如添加、删除句子的操作，全部失败，鉴权逻辑也完全不起作用。
本地运行良好的全功能网站，一到线上后台部分就完全瘫痪。我陷入了深深的困惑，开始了漫长的调试过程。我反复检查 EdgeOne Pages 的日志，但信息有限。我猜想是 Express.js 的路由和中间件机制，和 EdgeOne Pages 底层的函数计算环境可能存在兼容性问题。这个问题，让我整整折腾了两天，几乎耗尽了所有耐心。
转折点：大佬一句话，醍醐灌顶🙏
就在我快要抓狂的时候，和一个大佬吐槽这事，他的一番话直接点醒了我。
“你不是用他的 demo 改的吗？”
这句话瞬间点醒了梦中人。是啊，我为什么在这里闭门造车，死磕一个可能与平台水土不服的传统框架，而不是直接从官方的最佳实践入手？
紧接着，他也对那个让我耗费心神的后台管理页面提出了质疑，认为对这样一个小项目来说完全是画蛇添足。
这番话让我彻底明白了自己犯的两个根本性错误：第一，技术选型上舍近求远，没有直接拥抱官方推荐的方案；第二，在项目范围上过度设计，为一个简单的 API 服务强加了一个非必要的复杂后台。
✨第二阶段：基于模板，发现新大陆（和新问题）
我立刻冲去官网找到了 EdgeOne Pages 的官方示例项目。选择的是 Hono 框架，一个专门为边缘计算等现代 JS 运行时设计的、轻量级的 Web 框架。
放弃 Express ，基于官方的 Hono 模板重构后，之前那个棘手的后台路由问题瞬间就解决了。但在这个正确的基础上继续开发，新的、更具体的挑战也浮现了出來：
新挑战一：KV 数据库的正确姿势
在实现数据存储时，我习惯性地想通过 context.env 来访问 KV 存储，结果发现行不通。经过一番研究才明白，在 EdgeOne 的环境中，绑定的 KV 应该作为全局变量直接访问。
// ❌ 错误的方式
const data = await c.env.MY_KV.get('key');
// ✅ 正确的全局访问方式
const data = await MY_KV.get('key', { type: 'json' });
新挑战二：更安全地处理跨域（CORS）
简单的 app.use('*', cors()) 虽然方便，但在生产环境中并不安全。我利用 Hono 强大的 cors 中间件和平台的环境变量配置功能，实现了一个更安全的动态 CORS 策略。
import { cors } from 'hono/cors';
// CORS中间件
app.use('*', cors({
origin: (origin, c) => {
const allowedOriginsStr = c.env.ALLOWED_ORIGINS || '';
if (!allowedOriginsStr) {
return null; // 如果未设置环境变量，则不进行CORS处理
}
const allowedOrigins = allowedOriginsStr.split(',').map(item => item.trim());
return allowedOrigins.includes(origin) ? origin : null;
},
allowMethods: ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
allowHeaders: ['Content-Type, Authorization'],
// credentials 和 maxAge 等其他高级选项也可以轻松添加
}));
这样一来，只有在 EdgeOne Pages 后台配置了 ALLOWED_ORIGINS 环境变量并匹配成功的域名，才能进行跨域访问，安全性和灵活性都大大提高了。
🧘第三阶段：回归现实，拥抱简洁
最终，我彻底采纳了大佬的建议：“阉割” 掉整个后台管理页面，只保留核心的后台 API 和鉴权逻辑。
项目变成了现在这个更轻盈、更专注的样子：
✅ 核心API：使用 Hono 重写，保留随机获取、精确获取、添加和删除句子的接口 （带密码认证） 。
✅ 实用前端：一个现代化的响应式界面，用于公开的 API 测试和文档展示。
✅ 开发工具：开发了一个 PowerShell 脚本，通过调用受保护的 API 来实现批量添加句子，完美替代了后台页面的功能。
至于那个被 “阉割” 掉的后台管理页面嘛……也许未来哪天，我会心血来潮搭一个聚合类的 API 站点，到时候再给它一个真正的家吧。不过说实话，谁知道呢，大概率是没那天了。😮💨
🧠这次折腾的关键学习
这次过山车般的开发经历，让我对 AI 辅助开发和新技术平台有了更深的理解。
- 选对框架是成功的一半：为特定平台（尤其是
Serverless或边缘计算）选择一个原生支持或官方推荐的框架至关重要。强行使用不适配的传统框架，只会事倍功半。 - 官方模板是“救命稻草”：接触一个新平台或新技术时，第一件事就应该是去找官方的
Quick Start或模板。这是避免踩坑、理解最佳实践的最高效方式。 - 听人劝，吃饱饭：有时候自己钻牛角尖，不如听听旁观者的建议。朋友的建议直接帮我跳出了“必须要有后台页面”和“必须用
Express”的思维定式。 - 适时调整范围：当发现最初的目标实现起来过于复杂或不符合平台特性时，果断调整项目范围是一种明智的选择。保留核心，砍掉枝叶，会让项目更健康。
总而言之，EdgeOne Pages 是一个非常出色的边缘计算平台。而 AI 则是这个时代最锋利的工具之一。将两者结合确实能爆发出惊人的开发效率，但前提是，作为开发者，必须是那个最终的决策者和领航员。这次的“翻车”经历，也算是一次宝贵的成长了。