文章讲述了知名客户Lee Robinson放弃使用Sanity CMS,转而采用Markdown等更简单方案的过程。作者承认传统无头CMS确实存在过度复杂、预览流程繁琐等问题,但也指出这种方案仍能解决许多内容管理的实际需求,暗示简单方案并非适用于所有场景。文章反思了CMS行业存在的问题,同时为专业内容管理工具的价值进行了辩护。

标题：为什么你永远不该自建CMS？来自Sanity的深度反思

核心事件

知名开发者Lee Robinson将个人网站cursor.com从Sanity CMS迁移至Markdown文件+GitHub+Vercel的组合，并公开分享了这一过程。他通过344次AI代理请求和约260美元成本完成了迁移，主要动机包括：
- 简化流程：避免传统无头CMS的复杂抽象层
- AI友好性：让AI代理能直接通过grep检索代码库中的内容
- 成本优化：减少CDN费用（原方案因视频托管方式不当导致高昂开销）

Sanity的辩证回应

认同的痛点：
1. 预览功能笨拙：需多重登录（CMS/GitHub/托管平台）才能查看内容
2. 数据冗余：迁移后代码量从33.2万行缩减至4.3万行
3. AI访问障碍：认证API阻碍了代理直接查询CMS内容（现已推出改进版MCP服务）

但Markdown方案存在本质缺陷：
- 内容=页面的陷阱：
- 多页面引用同一内容（如定价信息）需手动同步多处文件
- 法律条款更新需人工比对47个页面的文本变体
- 无法实现结构化查询（如"查找所有提及某产品的内容"）
- Git不适合内容协作：
- 代码的机械合并冲突 ≠ 内容的语义冲突（如段落改写意图）
- 实时协作需求与Git异步特性矛盾
- 规模化后会出现"文件锁""内容冻结"等CMS已解决的问题

结构化内容的不可替代性

• 关系型数据优势：类似数据库范式化，产品信息作为独立文档可被多页面引用
• 查询语言必要性：GROQ等工具能实现"筛选价格>100美元的在库商品"等复杂查询，远胜grep的字符串匹配

关于AI代理的认知纠偏

• 误区："代理能读代码"≠"内容应存于代码"
• 正解：代理更擅长处理结构化API（如Sanity新版MCP支持代理直接管理内容模式、生成合规字段）

适用边界

Lee的方案仅适合：
- 全员懂代码的团队
- 内容仅用于单一网站
- 无需合规审计或复杂权限
而多数企业需要：
- 多终端内容分发（App/邮件/AI引擎）
- 实时协作与审计追踪
- 内容运营与工程解耦

未来方向

CMS行业应摒弃：
- 垃圾HTML的富文本编辑器
- 不可查询的布局JSON块
- 繁琐的Webhook配置
转向：
- 结构化内容：支持AI读写与语义理解
- 无界面操作：通过代理+API直接管理
- 实时性：变更无需部署即可生效

结语

Sanity承认传统CMS的弊端，但强调回归Markdown是倒退。真正的解决方案是构建AI原生的内容基础设施——既能被机器理解，又不牺牲人类协作效率。

（注：本文保留技术细节和核心论据，删减了部分重复论证和宣传性内容）

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

反对将Git作为CMS的观点

1. 非技术人员使用困难

   • "That seems backwards and hellish when you want to grow your content and marketing team" (inesranzo)
   • "Now the engineers would need to be bothered by the marketing department" (inesranzo)

2. 已有成熟CMS解决方案

   • "This is the reason why CMS's like Sanity, Wordpress, Directus exist" (inesranzo)
   • "75% of the web runs on WordPress... Scalability is solved. Usability by non tech editors is solved" (camillomiller)

3. 扩展性问题

   • "using Git as a CMS doesn't make sense at scale" (inesranzo)
   • "The 'simple' system will accrete complexity because content management is complex" (sublinear引用原文)

支持轻量级或替代方案的观点

1. CMS过度复杂且不灵活

   • "Every time the customer came back with 'can I do this or that'... it fell in a blind corner of the CMS" (d--b)
   • "They never worked well and have always caused more problems than they solved" (sublinear)

2. 简单方案更高效

   • "Let the customers write using markdown... it did what the customers needed" (d--b)
   • "Less time to build this than to actually install/understand a CMS" (d--b)

3. AI/工具化趋势

   • "UI first approach is dying... if cursor can solve it for me" (ianberdin)
   • "The points about structured content... go away as AI improves" (swazzy)

其他关键讨论

1. WordPress的争议

   • 支持方："WordPress is actually GREAT for headless" (camillomiller)
   • 反对方："WordPress (as much as I hate its ubiquitous existence)" (fullstackchris)

2. 技术可行性争议

   • "Git merges are extremely semantic... author went on defensive mode" (ozim)
   • "You could just as well build one that reads structured front matter" (adamscybot)

3. AI生成内容的批评

   • "Partially or fully AI generated... several layers of marketing" (samdoesnothing)
   • "The AI-generated points aren’t as compelling as the prompter thinks" (adamscybot)

中立/补充观点

• 实践价值：
  "Build something CMS like for fun... useful to experiment" (finaard)
• 行业立场质疑：
  "Written by a proprietary CMS company... slightly bias" (RobotToaster)

（注：所有评论评分均为None，未体现认可度差异）