用AI打造EmDash CMS自定义主题：Devin实战全记录

EmDash（文中常被口语化读作"M-Themes"或"M-Dash"）是一个基于 Astro 构建的现代化 CMS，它采用"区块（blocks）"的方式来组织页面内容。这篇文章记录了一位 YouTube 创作者如何借助 AI 编程助手——先是 Claude Sonnet，后是 Devin Desktop——从零构建 EmDash 自定义主题的完整过程，并探讨了 AI 辅助建站的能力边界与设计取舍。

EmDash CMS 是什么：基于 Astro 的区块化内容系统

EmDash 是一个运行在 Astro 之上的内容管理系统，部署在 Cloudflare Workers 上，主打速度与灵活性。作者在前一天已经用 AI 搭建了一个名为 "M-Themes HQ" 的站点，用来集中展示 EmDash 相关的所有内容。

这个站点结构相当完整：首页有醒目的 Hero 区块，下方依次是教程、YouTube 视频、插件、主题与服务展示，以及 FAQ 部分。此外还有独立的视频页、主题页、插件页、服务页和联系页。在后台管理界面中，可以看到已添加的页面、带有教程和视频的"内容中枢（Content Hub）"、媒体库、菜单、挂件与区块（sections）管理。

值得一提的是，作者还开发了一个用于注入自定义脚本的插件——比如在页面头部加入 Plausible 这类访客追踪脚本，或在 header/body 中插入自定义 HTML。这展示了 EmDash 在扩展性上的可能性。

后台可添加视频等内容

Astro 是一个以"内容优先"为设计理念的静态站点生成框架，其核心特性是"孤岛架构（Islands Architecture）"——默认输出零 JavaScript 的纯 HTML，只在真正需要交互的组件上按需加载 JS。这使得 Astro 构建的站点在性能评分上通常远优于 React 或 Next.js 全量渲染的方案。EmDash 选择 Astro 作为底层正是看中了这一点：内容页面以静态方式输出，动态数据从本地数据库拉取，再通过 Cloudflare Workers 的边缘网络分发，三者叠加带来了极快的首屏速度。Cloudflare Workers 本质上是运行在全球边缘节点的无服务器运行时，请求会被路由到离用户最近的数据中心处理，省去了传统服务器的地理延迟。

主题文件结构：理解 AI 要操作的核心

要理解 AI 是如何构建主题的，首先得搞清楚 EmDash 主题的文件组成。作者拆解了自己前一天完成的 "M-HQ" 主题，这些文件构成了整个主题的骨架：

Astro 配置：包含 live config 等基础配置，属于"生成后不要动"的部分；
Style tokens（样式令牌）：承载设计相关的变量与风格定义；
Seed 文件：极为关键，它决定了区块在数据库中如何被创建，从而让所有 blocks 能正确添加到各个页面；
内容模型（Content Model）：包含示例内容、菜单设置；
组件与区块：如 Site CTA、资源服务等组件，它们都从数据库动态拉取数据；
Base Layout 与 lib：基础布局和库文件，其中还包含 AI 自动生成的图标集和 YouTube 链接组件。

作者强调，样式文件是其中最复杂的部分，而其他组件大多只是"连接数据库并拉取数据"。这种动态化设计意味着页面内容与模板彻底分离——页面通过 slug 匹配，具体内容全部来自数据库。

Seed 文件在 EmDash 主题体系中扮演着"数据库初始化脚本"的角色，值得重点理解。当一套主题被安装到新站点时，Seed 文件会自动向数据库写入预定义的区块类型、默认内容和页面结构，让主题从一开始就呈现出完整的演示状态，而不是空白框架。这与 WordPress 的"导入演示数据"功能类似，但以代码形式声明，更易于版本控制和自动化部署。Style tokens（样式令牌）则是设计系统中的变量层，用于统一管理颜色、字体、间距等视觉属性。通过修改 token 值而非直接改动组件样式，可以在不触碰具体组件代码的前提下全局切换视觉风格——这也是亮暗双模式能够优雅实现的技术基础。

两套 AI 工具的实战对比：Sonnet 与 Devin

在主题构建上，作者先后动用了两套 AI 方案，形成了有趣的对比。

Claude Sonnet：一次性顺利搭建

前一天的 M-HQ 主题完全由 Claude Sonnet 完成。作者评价它"没有任何问题地创建了一切，运行流畅"，甚至帮助完成了部署。唯一的人工介入是后期的重设计——作者对初版外观不满意，手动调整后才达到满意效果，并加入了亮暗双模式。

Devin Desktop：10分钟生成完整主题

本次视频的重点是测试此前未用过的 Devin Desktop（CLI 模式，搭配 Sonnet 作为底层模型）。作者利用了 Devin 当时对 EmDash 用户提供的免费额度，下达了明确指令：修改默认的 marketing 主题，让 Devin 去参考另一个已有站点的设计，把内容细节写入数据库，并使用 Astro Icons 来方便地从 UI 添加图标。

向 Devin 下达构建指令

开启"绕过模式（bypass mode）"后，Devin 独立工作了约 10–15 分钟，最终生成/修改了 21 个文件、277 行代码，并在本地数据库完成了内容填充与测试。Devin 还调用了专为 AI 代理设计的 ego 浏览器来验证运行效果。

Devin 完成构建并添加数据库细节

从结果看，Devin 成功复刻了作者原站点的结构，生成了一个 portfolio（作品集）主题，保留了 Hero、项目展示等区块，视觉上与参考站高度相似，还额外加入了原站没有的亮色模式与一些动效。作者直言 Devin "非常懂 Astro"，在 EmDash + Astro 组合上表现出色。

关键启示：会不会提问，决定 AI 产出的质量

尽管成品外观漂亮、速度极快（本地数据库驱动），但作者指出了一个核心的设计缺陷，也是全文最有价值的洞见。

Devin 把整个页面做成了"一个包含所有内容的完整区块"，所有东西都挤在同一个可编辑页面里。这意味着当作者想添加新项目时，操作变得难以跟踪——内容全堆在一起，而不是分门别类。

所有内容堆在单页区块中，编辑体验混乱

作者真正想要的，是让 AI 为每个板块（如技术栈、项目）创建独立的内容集合（content collections / content types），这样未来可以灵活地单独添加项目条目，而不是面对一个庞大的整体区块。

"这是一个设计决策，"作者总结道，"这正是你为什么需要知道该如何向这些 AI 提问。"换言之，AI 完全有能力实现更合理的结构，关键在于人类是否在提示词中把需求讲清楚。同样的工具，指令粒度不同，产出的可维护性天差地别。

内容集合（Content Collections）是现代 Headless CMS 和静态站点框架中的核心概念，指将同一类型的内容条目（如"项目""文章""团队成员"）统一归类管理，每条条目拥有独立的数据记录和 Schema 定义。与之对立的是"单页大区块"模式——把所有项目信息硬编码进一个富文本或 JSON 字段里，初次生成时看起来结果相同，但一旦需要增删条目、按标签筛选或跨页面复用，维护成本就会急剧上升。Devin 选择"单一区块"方案并非因为能力不足，而是在指令未明确约束的情况下走了"最短路径"——这正是 AI 代码生成的典型行为模式：完成表面任务，而非隐含的架构目标。明确要求"为每类内容创建独立的 content type，并通过关联字段引用"，是将这类问题提前消除的有效提示词策略。

速度与后续：Cloudflare Workers 部署预告

整个过程中，本地运行的速度令人印象深刻——这得益于 EmDash 内容全部来自本地数据库的动态架构。作者通过 npm run dev 启动开发服务器，并使用 bypass URL 免去登录即可进入后台编辑。

作者预告下一步将把这套主题部署到 Cloudflare Workers，验证线上环境的速度表现。对于想上手 EmDash 的开发者，他也推荐查阅官方文档中关于主题概览、seed 文件等章节，配合实践能更快掌握。

小结

这次实战清晰地展示了 AI 编程助手在建站场景下的真实水平：Sonnet 和 Devin 都能在十几分钟内产出结构完整、外观专业的 Astro/EmDash 主题，速度与基础质量都令人满意。但 AI 不会替你做架构决策——内容模型该如何拆分、哪些要做成独立集合，仍需开发者自己想清楚并精确表达。工具越强，提问能力越成为分水岭。