从 Express 到 Encore：我如何借助 AI 能力在大半个月时间内，快速实现老项目中 86% 的前端功能以及 40% 的后端服务到新项目中

从过时SSR到现代全栈：AI助力下的快速技术栈迁移

引言： 在软件开发领域，技术栈的更替往往令人望而生畏。然而，近期我完成了一项大胆的尝试：在极短时间内将一个使用 Express、EJS、jQuery、Bootstrap 等老旧技术栈构建的服务端渲染（SSR）项目，迁移到一个以 Remix、TypeScript、Tailwind、Encore、Drizzle 等现代技术栈为基础的新项目。这一过程并非易事，但借助 AI 工具（如 ChatGPT 和 Claude）作为“编程拍档”，迁移进展异常顺利。本文将以半技术、半经验分享的口吻，介绍旧项目概况及痛点、新技术栈的选择理由，以及我是如何运用 AI 提升开发效率、克服迁移挑战的真实经历。

老项目回顾：过时技术栈的结构与痛点

在开始新的征程之前，有必要了解我们手头“遗留系统”的情况。旧项目技术栈主要包括：

• 后端： Node.js + Express 框架，用 EJS 模板引擎进行服务器端渲染。
• 前端： 基于 jQuery 的浏览器脚本，使用 Bootstrap 3 做响应式布局和样式。
• 数据库： 传统关系型数据库（如 MySQL），通过 Express 中的查询直接操作。

项目结构方面，Express 按照传统 MVC 划分：路由层负责 URL 定义，每个路由回调里从数据库取数据后调用 res.render() 渲染 EJS 模板。例如，典型的页面路由可能这样写成：

// Express 路由示例：获取帖子并渲染页面
app.get('/posts/:id', (req, res) => {
  const postId = req.params.id;
  // 查询数据库获取帖子
  db.query('SELECT * FROM posts WHERE id = ?', [postId], (err, result) => {
    if (err) return res.status(500).send("Database error");
    // 渲染 EJS 模板，将数据嵌入服务端生成的 HTML 中
    res.render('post.ejs', { post: result[0] });
  });
});

对应的前端 EJS 模板 (post.ejs) 里混合了 HTML 和服务端插值的模板语法。而交互逻辑则散落在脚本标签或独立的 JS 文件中，使用 jQuery 查找 DOM 元素并绑定事件。例如，一个简单的评论表单提交可能在页面里通过如下脚本处理：

<form id="commentForm">
  <textarea name="comment"></textarea>
  <button type="submit">提交评论</button>
</form>
<script>
  $('#commentForm').on('submit', function(e) {
    e.preventDefault();
    const comment = $('textarea[name="comment"]').val();
    if (!comment || comment.length < 3) {
      alert("评论内容至少3个字符");
      return;
    }
    $.post('/posts/<%= post.id %>/comment', { comment }, function(response) {
      if (response.success) {
        location.reload(); // 简单地刷新页面以显示新评论
      }
    });
  });
</script>

可以看出，旧技术栈的痛点主要体现在以下方面：

• 可扩展性差： 前后端耦合严重，模板、脚本、数据库查询逻辑混杂在一起。添加新功能往往需要同步修改多处代码，牵一发动全身，扩展困难。
• 代码维护困难： 由于缺乏类型约束和模块化机制，大型项目中难免出现隐蔽的bug。例如，某次我们因数据库字段名拼写错误导致页面崩溃，却只能在运行时才能发现——如果有类型检查本可避免。
• 开发效率低下： jQuery 手动操作 DOM、操作旧式构建工具，无形中增加了样板代码。每次改动都需要手动刷新页面验证，缺乏现代框架的热加载等提高效率的特性。
• 用户体验过时： 虽然 SSR 保证了初始渲染，但页面交互主要靠 jQuery 操作DOM，缺少更顺滑的组件化体验。一些复杂交互实现起来繁琐，移动端体验也不够理想。
• 技术债高企： Bootstrap 3 的样式已显陈旧，前端UI难以满足现代审美和定制需求；同时团队中新人往往不熟悉 jQuery/EJS 这种老旧模式，学习成本高。

简而言之，这个老系统像一栋年久失修的老房子——勉强能住人，但结构陈旧、漏洞百出，已经不堪重负。为了提高扩展性和开发效率，我们决心对其进行重构升级。

新技术栈选择：现代全栈的组合拳

在明确了迁移的必要性后，下一个问题是：选择什么样的新技术栈来重构这套系统？在评估了当前流行的技术后，我们为前端和后端分别选定了一套现代工具：

• 前端栈： React + Remix v2 框架、TypeScript、Tailwind CSS、Zod（用于表单/数据校验）。
• 后端栈： Encore.ts 平台（TypeScript 后端框架）、Drizzle ORM（现代轻量ORM）、仍然使用关系型数据库（Postgres）。

为什么选这些？我们逐项来解释。

前端：React、Remix、TypeScript 与 Tailwind 的组合

React 与 SSR 框架 Remix： React 不必多言，它是当今最主流的前端库之一，组件化开发提高了复用性和维护性。而我们选择 Remix v2 作为全栈框架，是因为它结合了 SSR 和前后端一体化开发的优点。Remix 被描述为“边缘原生（edge-native）的全栈框架”，可以用于构建现代、快速且健壮的用户体验，它将客户端和服务端通过 Web 标准进行了统一，使开发者能更专注于产品本身。简单来说，Remix 提供了约定优于配置的文件式路由、服务器端数据加载和表单处理机制，以及React Router v7带来的最新改进，让我们可以用 React 写出具有 SSR 能力的应用，同时享受服务端渲染带来的 SEO 和性能优势。

TypeScript： 旧项目饱受动态类型之苦，新项目坚决全面使用 TypeScript 来增强可靠性。TypeScript 的静态类型检查可以在编译期捕获许多错误，提高重构时的安全感。此外，Remix 对 TypeScript 有一流支持，我们可以在 loader 和 React 组件中定义类型，让前后端数据交换透明且自文档化。

Tailwind CSS： 作为现代 CSS 工具，Tailwind 提供原子化的实用类，使我们能够快速构建定制的界面风格，而不必局限于 Bootstrap 的预设样式或编写大量自定义 CSS。过去在旧项目中，如果需要修改一个组件的样式，常常要费力覆盖 Bootstrap 的层叠规则；现在只需在JSX中组合Tailwind类即可。比如，要给一个卡片增加圆角和阴影，只要加上className="rounded-lg shadow-lg p-4"即可，无需写额外的 CSS 文件。Tailwind 的设计让样式与组件紧密结合，提高开发速度的同时也避免了全局样式冲突。

Zod 校验库： Zod 是一个“TypeScript 优先”的运行时校验库，它允许我们定义模式(schema)来验证数据，并能推导出相应的 TypeScript 类型。这刚好满足了我们对表单验证和数据完整性的需求。在 Remix 中处理表单时，我们可以用 Zod 定义表单数据结构，并在服务端 loader/action 中验证输入是否符合预期。例如，我们为评论表单定义一个 Zod 模式，要求 comment 字段为至少3字符的字符串：

// 定义 Zod 模式
const CommentSchema = z.object({
  comment: z.string().min(3, "评论内容至少3个字符")
});

// 在 Remix 的 action 方法中使用模式验证表单输入
export async function action({ request }) {
  const formData = await request.formData();
  const input = Object.fromEntries(formData); // 将表单数据转成 JS 对象
  const result = CommentSchema.safeParse(input);
  if (!result.success) {
    // 验证不通过，返回错误信息
    return json({ errors: result.error.flatten().fieldErrors }, { status: 400 });
  }
  // 验证通过，执行业务逻辑
  const { comment } = result.data;
  await addCommentToPost(comment);
  return json({ success: true });
}

通过 Zod，我们在服务端保证了输入数据的合法性，并且 TS 类型让前端拿到 actionData 时可以明确其结构，不再需要手动检查。相比旧项目里依靠前端 jQuery 验证和后端重复验证，这种方式更严谨且不易出错。

后端：Encore.ts 与 Drizzle 打造新一代服务

Encore.ts 平台：后端我们选择 Encore.ts，这是一个现代的 TypeScript 后端开发框架（或称平台）。Encore 的特别之处在于，它内置了大量基础设施和开发工具：例如自动生成 API 文档、分布式跟踪、内置数据库迁移支持等，旨在减少后端样板代码和配置。更令人激动的是，Encore 官方号称其架构“AI Ready. Developer Obsessed”，能充分发挥 AI 在编码中的作用。据官方介绍，Encore 的声明式框架让 AI 工具不仅能生成代码片段，甚至可以生成完整的集成系统——包括服务、API 以及云基础设施配置。这意味着在AI的帮助下，我们可以快速构建出一套云端后端，而 Encore 会确保这些 AI 生成的代码模块契合框架要求并通过校验。这些特性与我们的目标不谋而合：我们正希望借力 AI 来加速开发，而 Encore 提供了友好的土壤。

除了AI方面，Encore.ts 相比传统 Express 还有显著性能优势。官方Benchmark显示，用 Encore.ts 替换 Express.js 可使 API 性能提高约9倍！这是因为 Encore 底层用 Rust 实现了多线程请求处理和验证，在保持 Node.js 生态兼容性的同时，大幅提高了性能和类型安全。对我们来说，这意味着新系统能更从容地应对高并发和复杂计算。

Drizzle ORM： 数据库访问层我们选型了 Drizzle ORM。Drizzle 是一个新兴的 TypeScript ORM，以轻量、高性能著称，并强调开发者体验和完全的类型推导。与老项目直接写 SQL 或使用重量级的 Sequelize 不同，Drizzle 的风格更贴近 SQL 同时提供了类型安全。我们可以用 TypeScript 定义数据库 schema，再通过 Drizzle 生成的类型安全查询方法操作数据库。例如，在 Drizzle 中定义一个posts表模型后，可以这样查询数据：

// 使用 Drizzle 定义表（简化示意）
const posts = pgTable("posts", {
  id: serial("id").primaryKey(),
  title: text("title"),
  content: text("content"),
});

// 类型安全的查询
const postId = 42;
const post = await db.select().from(posts).where(eq(posts.id, postId));

上例中，post 将会是一个类型化的对象，其属性来源于定义的表结构。如果字段名或类型不匹配，TypeScript 会在编译期报错。相比旧代码中那样手写 SQL 字符串，这种方式有效避免了常见的SQL拼写错误、类型错误，并简化了维护。在实际迁移中，我们借助 Drizzle 提供的迁移工具，将旧数据库结构导出为 Drizzle schema 定义，再生成迁移脚本，一举完成数据库的升级改造。

综上，新技术栈的选择充分考虑了开发效率和系统品质：前端采用 Remix+React 提升了用户体验和开发体验，后端借助 Encore+Drizzle 提供了强大的性能、类型安全和自动化能力。而贯穿前后的 TypeScript 则是架起了数据与接口的一道“强类型防线”。

AI赋能开发：利用 ChatGPT 加速迁移

在确定新旧技术选型之后，我们面临的就是如何高效地将庞大的旧系统迁移到新框架下。这是一项繁重的工程：包括重写大量页面、重构业务逻辑、适配新架构等等。幸运的是，我将 ChatGPT 和 Anthropic Claude 这样的AI 工具引入了我们的开发流程，充当智能助手，大大提高了迁移速度和质量。

代码生成与重构

AI 作为“代码生成器”：面对重复性高或模式固定的代码，ChatGPT 展现出了强大的生成能力。比如，在把若干个 EJS 页面转换为 React 组件时，我并未从零开始手敲 JSX，而是将原始的 HTML 模板提供给 ChatGPT，请它转换为 React 组件代码。举个例子，我把一个用户资料页面的 EJS 模板（包含若干<div>和 <% %>模板语法）复制到 ChatGPT，并提示：“请将这个 EJS 模板重写为使用 Remix 的 React 组件，样式改用 Tailwind 类，保留页面逻辑”。ChatGPT 几乎在几秒钟内就返回了对应的 JSX 代码片段，包含了等价的结构和 Tailwind 的类名。我需要做的只是稍加调整组件状态管理，将其包装成 Remix 路由导出即可。通过这种方式，我们批量转换了十几个页面，大大节省了机械式敲代码的时间。

AI 辅助重构旧代码：对于旧系统中一些复杂的业务逻辑函数，我则采用了“解释-重构”的方式让 AI 帮忙。比如有一个计算用户权限的函数，原始实现晦涩难懂且充斥着硬编码。我先让 ChatGPT 阅读这段代码，并用自然语言帮我解释其作用，然后根据解释提出重构建议。ChatGPT 给出了清晰的要点总结，并指出可以用更现代的语法和数据结构来优化。我继续要求它“按照上述思路重写函数，使用 TypeScript 类型定义权限数据结构”。很快AI给出了重构后的代码。我再将其集成到新项目中，并编写相应的单元测试验证功能正确性。这个过程中，ChatGPT 实际扮演了助手和顾问的角色：加速了我们理解旧代码、生成新代码的过程。

类型推导与接口定义

利用 AI 进行类型推断：旧项目的很多数据结构没有明确定义，例如前端 AJAX 调用返回的 JSON 没有模式说明。这导致在迁移时，我们需要为这些数据创建 TypeScript 接口和类型。手动梳理数据结构既枯燥又容易遗漏。这时我尝试把一些示例 JSON 或旧代码中对对象的使用片段提供给 ChatGPT，询问“根据这些使用场景推断对象的接口定义”。ChatGPT 几乎立刻给出了合理的 TypeScript interface 定义，有时还会贴心地将字段按字母排序或注明可能的可选值。这相当于快速完成了一遍“类型文档化”。之后我再根据实际情况微调，最终确定接口定义。总的来说，有了 AI 的协助，我们得以及时为新项目补充上完善的类型说明，使开发过程中 IDE 提示、编译检查都更加友好。

API 接口重设计： 在后端，由于架构变化，我们的 API 也需要重新设计。我会先用自然语言向 Claude 描述我们要提供的某个服务接口的功能、输入输出、可能的错误情况，然后让它给出 API 的 TypeScript 定义草案和说明文档。Claude 擅长处理大段文本和逻辑，在我的提示下，它产出了比较全面的接口说明，包括函数签名、参数和返回值类型定义，甚至连 JSDoc 风格的注释也写好了。这些生成的文档初稿为我们团队讨论新 API 提供了基础材料。经过人工检查和调整，我们很快就敲定了新系统的 API 设计。

表单处理与验证迁移

旧系统的表单处理往往涉及前后端多处校验：前端 jQuery 简单验证 + 后端重复验证。而在新系统，我们希望利用 Remix 的机制配合 Zod，实现统一的表单验证逻辑。为此，我将某些典型表单（如用户注册表单）的字段规则列出，例如“邮箱必须合法、密码需要至少8位且包含数字”等，并要求 ChatGPT 使用 Zod 写出验证schema。ChatGPT 很快生成了对应该规则的 Zod 代码：

const SignupSchema = z.object({
  email: z.string().email(),
  password: z.string().min(8).regex(/\d+/, "需包含数字"),
  confirmPassword: z.string()
});

甚至，它还贴心地补充了一个自定义校验，用于检查 confirmPassword 和 password 是否一致（使用 refine 方法）。这个结果让我十分惊喜——AI 几乎洞察了实际需求，在我的提示下给出了可用的解决方案。最终我将这些代码集成到 Remix 的 action 方法中，保证提交时服务器也严格验证输入。借助 AI 的力量，我们完成了多个复杂表单的迁移和验证逻辑实现，不仅速度快，而且减少了遗漏业务规则的风险。

同时，对于在 React 中构建表单 UI，我也会让 ChatGPT 辅助生成样板代码。例如，“请给我一个使用 Tailwind 样式的多步骤表单组件模板，包含上一步/下一步按钮”。AI 给出的代码结构清晰，我在其基础上填充具体内容，再由AI协助调整细节，很快就完成了多步骤表单的编写。整个过程如同有一个熟练的搭档与我结对编程，大大提升了效率。

Prompt 设计与多模态尝试

要充分发挥 AI 的作用，如何与你的AI对话（Prompt工程）是一门学问。我在迁移过程中逐渐摸索出一些提示技巧：

• 明确分解任务： 一开始我曾抛给 ChatGPT 一个宏大的指令：“帮我把整个 Express 项目迁移到 Remix”。显然这过于宽泛，AI 给出的回答也是泛泛而谈。后来我学会将任务拆解，比如先聚焦于单个模块：“这是一个用户认证的中间件，实现了X功能，请将它改写为 Remix 风格的认证逻辑（如使用 Remix 的 loader 检查session）”。分步进行不仅让AI输出更准确，也方便我逐块验证结果。
• 提供充足上下文： 每次提示时，我尽量把相关的代码片段、错误信息都提供给 AI。比如在调试某个函数时遇到错误，我会把错误栈和相关代码一并发给 ChatGPT，请它分析原因。上下文越具体，AI 回答的针对性就越强。此外，Claude 支持更长的上下文，让我可以贴上千行的日志或代码进行分析，极大地方便了对复杂问题的讨论。
• 要求给出理由： 对于AI生成的解决方案，我通常会追加一句“请解释你这样做的原因”。这既可以验证 AI 的思路是否正确，也有助于我学习和判断方案可行性。在多数情况下，ChatGPT 会给出详细的说明，让我明白代码背后的逻辑，再决定是否采用。

值得一提的是，我还尝试了多模态的提示。例如，在重构前端样式时，我将旧系统页面的截图提供给支持图像输入的AI模型，让它据此提供UI改进建议和对应的Tailwind代码。这种方法相当于把设计草稿直接“展示”给AI，效果非常直观。AI 可以基于截图理解页面布局，然后输出修改HTML结构或Tailwind类名的建议。不过这类多模态能力目前还在早期，我更多是用它来做思路发散，最终代码还是由我结合AI建议完成。

控制复杂度：避免落入“Vibe Coding”陷阱

在AI高度参与开发的过程中，我也始终警惕着不要让自己变成 AI 的“傀儡”。最近业界出现了一个词汇——“Vibe Coding（氛围编程）”，指的是一种高度依赖 AI 编程的模式：开发者只需用几句话描述需求，由大型语言模型自动生成代码，程序员从写代码的角色转变为指导、测试和完善 AI 代码。这种模式听起来很美好，也确实降低了编程门槛，因为理论上即使新手也能通过 AI 产出可运行的软件。然而，Vibe Coding 也潜藏风险：开发者可能对AI生成的每一行代码都缺乏深度理解，如果盲目接受而不加审视，长期来看软件质量和可维护性会受到影响。

本次项目中，我刻意避免陷入“纯粹按AI感觉编程（vibe coding）”的陷阱。首先，在架构和核心模块设计上，我坚持由人来做决策。AI 非常擅长在已有模式下扩展代码，但对于宏观的架构权衡仍需要有经验的工程师拍板。例如，我们选择拆分哪些服务、确定数据边界、哪些功能优先开发，都是通过团队讨论决定，然后才让AI参与具体实现。其次，我对 AI 给出的代码始终保持审查和测试。正如 Andrej Karpathy（提出“vibe coding”概念的人）所提醒的那样，AI 工具有时并不真正“理解”代码执行时出现的错误，也不一定能提供正确的修复方案。他甚至提到为了解决AI代码中的问题，不得不尝试一些无关变更直到问题解决——这显然不是严谨的工程方法。我在实践中也偶尔遇到类似情况：某次AI给出的代码在边缘情况下崩溃，但它未能调试出原因，还建议了一些风马牛不相及的修改。最终我不得不亲自介入，运用传统调试手段找出了问题（一个隐藏的状态同步bug）并修复。这个教训让我更加认清：AI 代码辅助再强大，也不能完全取代我们对系统的理解和把控。

为避免不知不觉滑向 vibe coding，我采取了几项措施：

• 严格代码评审： 无论这段代码是人写的还是AI写的，我们都一视同仁地走代码评审流程。团队成员会审查AI生成的代码，提出改进意见。很多时候，同事们能发现AI代码里不符合业务逻辑的细节，我们据此调整。这保证了即使AI一开始理解有偏差，最终交付的代码也是经过人类校准的。
• 补充测试用例： 针对AI生成的新功能，我会额外编写单元测试或集成测试。测试的一大作用是迫使我们真正理解功能期望行为，从而检验AI代码是否符合预期。当测试不通过时，我们再回头要求AI 调整或手工修复，形成闭环。
• 限定AI作用范围： 我发现让AI完全自由发挥时，容易引入过度工程或不必要的复杂方案。例如AI有时会尝试引入它“觉得”有用的库或模式，但这些对于我们的项目未必合适。后来我学会在提示时明确约束，比如“不引入额外依赖，用现有工具实现X功能”。这样AI提供的方案更贴合我们的实际环境，也减少了事后清理不必要代码的麻烦。

通过这些手段，我们尽量享受AI带来的效率提升，同时保持对项目复杂度的可控性。最终的新系统代码库相对简洁，有清晰的结构，而不是东拼西凑的“AI拼盘”。

项目协作与效率提升：AI在团队中的角色

本次迁移项目时间紧、任务重，但在AI助力和团队协作下，进展超出了预期。我们仅用了不到两个月就完成了原计划三到四个月的工作量。这其中有几个关键因素：

1. 明确分工与并行开发： 我们将前后端工作分开并行推进：我主要负责核心架构和后端服务，同事们分头认领前端页面和组件重构。借助AI，每个开发者都像多了一个助手。例如，我在开发一个新的后端API时，会让ChatGPT帮忙生成部分单调的代码；而前端的同事在用Remix重写页面时，也不断用AI来查询用法或生成样板代码。这样一来，各自的开发速度都有提升，整体进度自然加快。

2. 团队知识共享： 开始迁移前，我组织了一次内部分享会，将自己摸索出的 AI 提示技巧、踩过的坑告诉团队成员。例如，我展示了如何用 ChatGPT 将一段 jQuery 代码改写成 React Hooks，以及如何提示AI输出更符合我们编码规范的结果。这让大家对AI工具有了更深理解，少走了弯路。平时，我们还创建了一个共享文档，收集大家在AI协作中发现的好用Prompt句式和应对AI出错的经验。当有人遇到AI给出的方案不对劲时，我们会讨论是否换一种提问方式或干脆手工解决。通过这种透明的沟通，AI 成为了团队共同的辅助工具，而非只有少数人掌握的“黑魔法”。

3. 进度管理与反馈： 项目经理对我们借助AI提速持支持态度，但也担心质量风险。因此我们采用了短迭代、快反馈的方式：每周都进行一次阶段性演示，将已经迁移完成的模块在新系统中跑给相关利益干系人看，及时收集反馈。这种做法一方面让大家对新系统有了信心，另一方面也促使我们严把每周的交付质量，不敢因为用了AI就放松对细节的关注。事实证明，借助AI我们不仅交付快，质量也有保障——几次演示下来，新系统页面运行流畅、功能完善，令人眼前一亮。

有意思的是，团队士气也因为AI的加入而提高了。以前大家可能会对重复的重构工作感到厌烦，但现在有了AI当助手，很多苦差事迎刃而解。开发者可以将精力更多放在创造性的部分，琐碎的活儿交给AI处理。正如某研究所指出的那样，使用AI助手后，员工完成任务的时间显著缩短（有报告称减少了约40%），而输出质量却提升了约18%。我们在实践中深刻体会到了这一点：本来以为要加班熬夜的工作，现在反而游刃有余。当然，我们也保持着清醒——AI 带来的效率提升是一把双刃剑，如果不注意方法，可能加速写出糟糕的代码。所以整个过程中，我们始终以工程最佳实践为纲，AI 为辅。

结语：AI时代的开发者成长

回顾这次迁移，从老旧SSR系统到现代全栈架构的转变，无疑是一次浴火重生般的过程。借助新技术栈，我们的应用在性能、可维护性、用户体验上都上了一个台阶：页面加载更快了、界面更美观了，团队开发速度也快了很多。更令人鼓舞的是，AI 工具为我们插上了翅膀，使得原本紧张的工期大大缩短。据麦肯锡的一项调查，生成式AI有望自动化开发者日常工作中近30%的任务，并将生产力提高多达45%——我们的实践正验证了这一点。

当然，AI 并非万能。在享受它带来的便利时，我们也需要保持理性和专业性。AI 可以成为得力的助手，但架构的掌舵者始终应该是我们人类自己。 只有将AI产出与人类洞察相结合，才能打造出真正优秀的软件系统。这次项目让我深刻意识到，新技术的引入（无论是Remix这样的框架，还是ChatGPT这样的AI）最终目的都是为了服务于业务目标和用户价值。技术只是手段，如何有效地运用手段才是考验开发者的关键。

对我个人而言，这是一次宝贵的历练。我不仅更新了技术栈、交付了令人满意的成果，还学会了在AI时代下与智能工具协作的新技能。这份经验将指引我在未来的项目中更加游刃有余地拥抱变化、迎接挑战。希望我的分享能给同样面临遗留系统升级困境的开发者一些启发：也许下一个推倒重来的勇气，就蕴藏在你对AI的善加利用之中。让我们在快速变化的技术浪潮中，既乘风破浪，也稳舵前行，共同书写AI时代的软件开发新篇章！

参考资料：

• 【1】Wikimedia: Vibe coding (AI-dependent programming technique)
• 【5】维基百科：Vibe coding（氛圍編程）的提出与局限
• 【6】Drizzle ORM 官网: A lightweight and performant TypeScript ORM
• 【15】MIT News: ChatGPT boosts productivity (40% faster task completion, +18% quality)
• 【17】GitHub Copilot & McKinsey 调查: AI助力开发者效率数据
• 【26】Encore 官方网站: Encore.ts 与 AI 整合和性能优势
• 【29】Strapi Blog: Remix 框架简介（全栈、统一前后端）
• 【31】Encore 官方网站: Encore vs Express 性能对比