从 Rails 到 Phoenix：AI 工具如何改变我的技术栈

过去一年，我的个人项目技术栈走过了一条曲折的路：纯 Rails 搭配 Hotwire → Rails 搭配 Inertia 和 React → Phoenix LiveView。

Rails 依然是个出色的框架，但探索 Phoenix——尤其是结合 Tidewave.ai 这样的 AI 工具——让我重新思考什么技术栈最适合我的个人项目。

我是怎么走到这一步的：从 Hotwire 到 React

在用 Rails 构建交互式副项目时：

Hotwire：我喜欢服务端渲染的理念，但构建复杂的 UI 组件（组合框、多状态对话框）让我很吃力，因为我的 CSS 技能有限。
Rails + React（Inertia.js）：转向 React 让我用上了 shadcn/ui，并且能借助 AI 快速搭建组件原型。但时间一长，React 疲劳就来了：管理客户端与服务端之间的状态、处理 Node.js 构建流程，还要在 Ruby 和 TypeScript 之间频繁切换上下文。

我想要的，是服务端渲染 HTML 那种单一语言的简洁，同时具备现代实时交互和开箱即用的优质 UI 组件。

LiveView 的心智模型很直白：状态存在于服务端进程（一个轻量的 BEAM 进程）中，UI 更新通过 WebSocket 连接流式传输。

没有客户端状态同步库，没有 REST/GraphQL 胶水代码，也不用等前端打包编译。一切都在 Elixir 里完成。

Phoenix 开箱即带 Tailwind CSS 和 DaisyUI。虽然 DaisyUI 的默认风格不是人人都喜欢，但预置好的组件（标签页、模态框、提示、徽章）直接可用，消除了当初把我推向 React 的样式瓶颈。

这是最出乎意料的一点。在使用 Claude Code 和 Tidewave（一个专为 Phoenix 打造的 MCP 工具）这类 AI 编码工具时：

单一上下文：由于 LiveView 组件把状态、生命周期回调和 HTML 模板都封装在 Elixir 里，AI 能在一个文件中获得完整上下文，而不必跨控制器、序列化器和 React 组件去拼凑。
显式状态与模式匹配：Elixir 的函数式特性和不可变数据结构让业务逻辑变得清晰明了。相比多层 JavaScript 状态图，AI 模型在 Elixir 中产生的幻觉状态错误要少得多。

在最近的一个个人项目中，Tidewave 仅凭高层功能提示就生成了几乎完整的 LiveView CRUD 和 UI 工作流，几乎不需要调试。

Phoenix 并非毫无摩擦：

生态系统规模：Rails 的生态系统非常庞大；如果你需要集成某个小众第三方服务，Rails 几乎肯定有成熟的 gem 可用。而在 Elixir 中，你偶尔需要自己编写封装。
学习曲线：如果你多年从事面向对象的 Ruby 开发，函数式编程、OTP 和模式匹配需要你转变思维方式。

转向 Phoenix LiveView 让我在独立开发中兼得两者之长：既有我想要的 React 式组件便利性，又有我怀念的纯 Rails 那种服务端渲染、单一语言的简洁。对于把开发速度和低维护成本放在首位的个人项目来说，它已成为我的首选。