#Sanity | cosine - 前端人の日常频道

#优质博文 #CMS #Sanity #AI
"You should never build a CMS" | Sanity：Sanity 回应 Cursor 将 CMS 迁移至 Markdown 的热议，分享了许多非常好的使用 CMS 的理由。

感觉这个确实：

当同一条信息（如价格、法律条文）出现在多个地方时，Markdown 需要手动更新多处，而结构化内容只需修改一处。

AI 摘要：这篇文章是 Sanity 官方对 Lee Robinson（Cursor 团队）近期将内容从 CMS 迁移到 Markdown 文件这一趋势的深度回应。作者承认了传统 Headless CMS（无头内容管理系统）在复杂性、身份验证和 AI 接入方面的痛点，但指出“删除 CMS 并不等于删除了管理需求”。文章强调 Markdown 方案在处理非规范化数据、复杂语义协作和高级查询（Grep 的局限性）方面存在天然缺陷。Sanity 认为，真正的解法不是退回到原始的扁平文件，而是利用如 MCP（Model Context Protocol，模型上下文协议）等新技术，让 AI 直接与结构化内容 API 交互，构建真正面向 AI 的内容基础设施。

[以下是方便搜索索引的大纲 (AI 生成)，请读原文]

1. 现状反思：为何开发者想要逃离 CMS
• 承认 Headless CMS 带来的复杂性并没有为所有用户提供成比例的价值。
• 痛点分析：笨重的预览工作流（Preview workflows）、碎片化的身份验证（Auth fragmentation）以及高昂的存储成本。
• AI 接入障碍：传统的 API 验证屏蔽了 AI Agent，使其无法像读取本地代码库一样轻松访问 CMS 内容。

2. 核心争论：Markdown 的“内容即页面”陷阱
• 简单性的错觉：Markdown 适合一对一的简单页面，但无法处理内容的规范化（Normalization）。
• 维护噩梦：当同一条信息（如价格、法律条文）出现在多个地方时，Markdown 需要手动更新多处，而结构化内容只需修改一处。
• 实体与字符串：Markdown 本质上是字符串的堆砌，缺乏实体（Entities）概念，难以进行复杂的关联分析。

3. 工具边界：Git 与内容协作的错位
• 合并冲突的本质：代码合并是结构化的（Mechanical），而内容合并是语义化的（Semantic），Git 无法理解内容修改的意图。
• 实时协作需求：内容团队通常需要实时反馈，而非 Git 式的异步提交与拉取。
• 扩展性瓶颈：随着内容规模增长，Git 方案往往会演变成需要通过 Slack 协调修改或复杂的 PR 审核流程。

4. 技术深潜：Grep 无法替代结构化查询
• 检索局限性：Grep（全局正则表达式搜索）只能做简单的模式匹配，无法处理逻辑复杂的查询（如“查询某日期后发布的所有企业类案例”）。
• 查询语言的力量：展示了 GROQ 语言在处理复杂数据筛选时的优势，强调结构化数据才是 AI Agent 推理的最佳底座。

5. 未来趋势：面向 AI 的内容基础设施
• MCP 服务器的兴起：介绍 Sanity 推出的 MCP 服务器，使 AI Agent 能直接操作内容模式（Schema）并管理发布。
• 格式误区：区分“适合 AI 输入输出的格式（Markdown）”与“适合作为基础设施的格式（结构化数据）”。
• 真正的 AI 驱动：内容应是可查询的（Queryable）而非仅可搜索的（Grep-able），且应与展示层无关（Presentation-agnostic）。

Sanity.io

“You should never build a CMS” | Sanity

Lee Robinson migrated cursor.com off Sanity. He made good points. Here's what he missed.