AI 杀死了 CMS — 至少对简单网站而言

TL;DR

对于简单网站 — 作品集、博客、着陆页、小型企业站点 — 传统 CMS 正在变成不必要的负担。Claude Code、Cursor 和 GitHub Copilot 等 AI 工具现在可以直接编辑你的代码库、理解上下文、翻译内容，并通过 git 部署更改。CMS 曾经提供的抽象层正在被一个更智能的接口所取代：自然语言。

你正在为 CMS 支付的隐性成本

每个 CMS 都带有隐性成本。不只是订阅费 — 还有围绕你那本来很简单的网站所产生的整个复杂生态系统：

• 基础设施：需要托管的数据库、需要维护的 API、需要保护的管理面板。仅 WordPress 就占据了约 43% 的网站份额和约 90% 的 CMS 定向攻击。
• 性能：动态页面生成、每次请求都要调用 API、CMS 数据的客户端注水。你那 3 个页面的作品集现在拥有了 SaaS 产品级别的架构。
• 供应商锁定：你的内容存在别人的数据库模式中。从 Contentful 迁移到 Sanity？那是一个项目，而不是改个配置。
• 上下文切换：在 IDE 中编辑代码，然后切换到浏览器中的 CMS 管理面板来修改一个标题。两种不同的心智模型，做的却是本质上相同的操作。
• 费用：Headless CMS 的定价通常随 API 调用次数或内容条目数增长。一个个人博客不需要每月 $99 的内容基础设施。

对于一个每天有 50 人编辑内容的营销网站，这些成本是合理的。对于开发者的作品集或小企业的着陆页呢？你在为了跨过一个水坑而建造一座桥。

变化在哪里：AI 理解你的代码

CMS 存在的理由很简单：非技术人员（甚至包括不想为了改内容而碰代码的开发者）需要一个可视化界面来更新网站。代码太复杂、太脆弱、太容易出错。

AI 从根本上改变了这个等式。现代 AI 编码工具不仅仅是自动补全 — 它们理解项目结构、读取现有模式，并做出上下文正确的编辑。工作流程的变化是巨大的：

# Old workflow: CMS
1. Open browser → log into CMS dashboard
2. Navigate to content → find the right page
3. Edit in WYSIWYG editor → fight with formatting
4. Preview → looks different from production
5. Hit publish → pray the cache invalidates

# New workflow: AI
1. Tell AI: "Change the pricing on the landing page to $29/month"
2. AI edits the file, you review the diff
3. Push to git → deploy

这不是假设。你正在阅读的这个博客运行在 SolidStart 上，内容存储为 TypeScript 文件。每篇文章 — 包括这一篇 — 都是通过告诉 AI 写什么、审查输出、然后推送到 git 来创建的。没有 CMS 管理面板。没有数据库。内容和代码之间没有任何 API 层。

来自本站的真实案例

这个网站支持 10 种语言，有博客，动态生成 OG 图片，并产出 RSS 订阅源和站点地图。以下是内容层的样子 — 纯 TypeScript：

// This blog post you're reading right now is a TypeScript file.
// No database. No API. No CMS dashboard.
// Just a typed object that AI can read and edit directly.

export const myPost: BlogPost = {
  slug: "ai-killed-cms",
  date: "2026-04-17",
  translations: {
    en: {
      title: "Why I stopped using a CMS",
      description: "AI understands my codebase better than any CMS UI.",
      content: makeContent(proseEn),
    },
    uk: { /* ... */ },
    de: { /* ... */ },
    // 10 languages — AI translates them all
  },
};

以下是我用 AI 完成的、传统上需要 CMS 才能做到的事情：

• 添加新博文："写一篇关于 X 的新文章，遵循现有文章的结构" — AI 创建文件、添加翻译、在索引中注册
• 更新着陆页文案："把主标题改成 Y" — AI 找到正确的文件并更新
• 翻译内容："为定价页添加德语翻译" — AI 阅读英文版本，生成文化适配的翻译，而非逐字翻译
• 修正错别字："about 页面有个拼写错误，'recieve' 应该是 'receive'" — 3 秒搞定，带有有意义的提交信息推送到 git

CMS 真正解决了什么 — 以及 AI 如何替代它

让我们坦诚地看看 CMS 带来了什么，以及每项能力如何映射到 AI 工作流：

核心洞察：git 已经是一个比任何 CMS 曾经构建的都更好的版本控制系统。而自然语言是比任何 WYSIWYG 编辑器都更好的接口 — 因为它承载的是意图，而不仅仅是格式。

范式转变：代码就是内容层

我们正在见证一次反转。二十年来，趋势是将内容与代码分离 — 把内容放进数据库，通过 API 暴露，在前端渲染。当代码难以编辑、内容需要让非开发者也能访问时，这是有道理的。

AI 并不是通过成为更好的 CMS 来淘汰 CMS 的。它是通过让代码像管理面板一样易于使用，从而淘汰了 CMS。

Web 内容管理的演进遵循着清晰的轨迹：

1. 2000 年代：单体 CMS（WordPress、Drupal）— 内容与展示耦合在一个系统中
2. 2010 年代：Headless CMS（Contentful、Strapi）— 内容通过 API 分离，由前端框架渲染
3. 2020 年代：静态站点生成器 + Markdown（Hugo、Astro）— 内容以文件形式存在，部署时构建
4. 2025+：代码即内容 + AI — 内容存在于类型化代码中，AI 是编辑接口

什么时候你仍然需要 CMS

这不是一个 "CMS 已死" 的论断。CMS 在规模化场景下解决了真实的问题。在以下情况下你仍然需要它：

• 大型编辑团队：10 名以上内容编辑需要基于角色的访问控制、审批工作流和同时编辑。Git 合并冲突不是内容编辑该解决的问题。
• 高频内容更新：每天发布 50 篇以上文章的新闻网站需要优化的编辑流水线，而不是 git 提交。
• 复杂的内容关联：拥有数千个 SKU、产品变体和动态定价的电商目录需要结构化数据库。
• 合规要求：需要审计追踪、内容审批链和法律规定的审查流程的行业需要专门构建的系统。

界限很清楚：如果你的内容变更需要多个非技术利益相关者高频协调，CMS 的复杂性就是值得的。如果你是独立开发者、小团队，或者管理的是每周而非每小时更新一次的网站 — AI + 代码更简单、更快、更便宜、也更可靠。

未来：AI 作为通用接口

这个趋势远不止 CMS。每一个因为 "底层系统太复杂，无法直接交互" 而存在的软件抽象层，都在被 AI 压缩。管理面板、配置界面、可视化数据库编辑器 — 所有这些都是将人类意图转化为系统变更的接口。AI 天生就能完成这种转化。

对于简单网站，未来已经到来。你的内容就是代码。你的编辑器就是 AI。你的版本控制就是 git。你的部署就是一次推送。整个 CMS 层 — 管理面板、数据库、API、托管 — 曾经是你的意图和你的网站之间的中间件。AI 消除了对这个中间件的需求。

最好的 CMS 就是没有 CMS。不是因为内容管理不重要 — 而是因为 AI 让代码本身成为了我们有史以来最直观的内容管理接口。