实际使用与边界
适用场景：当一个人负责仓库、写作、审核和部署时，可以用这套架构先跑通发布闭环。让重复出现的维护问题，而不是想象中的规模，决定是否引入 CMS 或数据库。
边界：这是一种运行方式，不是适用于所有团队的技术栈推荐。多人协作、复杂权限或深度本地化项目可能需要不同工具。
从一个朴素的内容模型开始
一个耐用的网站只需要少量字段：稳定的 slug、清晰的标题、有用的摘要、分类、日期和正文。对独立项目来说，这足以持续发布，不必先花数周开发编辑器。只有当作者、更新时间、阅读时长、要点和来源真正改善工作流时，才增加这些字段。
为下一次修改优化
最好的技术栈，是你六个月后仍然看得懂的技术栈。让路由可预测，把共享界面放在统一位置，并让每次内容改动都小到可以在一个 Pull Request 中审阅。内容放在 Git 中版本化，未来迁移到 MDX 或 CMS 时也不需要重写页面布局。
把发布与分发分开
写文章和让文章被发现是两件事。每个页面都需要规范 URL、有效描述、清晰标题、相关链接和站点地图入口。内链应该帮助读者继续学习，而不是只追求页面浏览量。搜索流量应当是解决具体问题的结果，而不是有用内容的替代品。
部署前设置质量门槛
发布前检查四件事：文章是否来自亲身实践或明确标注的研究？是否兑现了标题承诺？会变化的事实是否有日期或来源？读者是否能找到作者、联系方式和隐私信息？最后运行生产构建，捕获断链和元数据错误。
用本站理解具体的系统边界
aifincode 把内容记录放在 lib/content.ts，把动态文章展示集中在一个 App Router 页面，并把专题与本地化逻辑放在独立的库文件中。这样，修正文稿与调整布局是两类改动，新增文章也不需要新增路由。重点不在目录名称，而在内容来源、URL 逻辑、页面展示和部署检查各自有不同的变化原因；未来迁移到 MDX 或 CMS 时，可以只替换内容来源层，同时保留稳定 slug 和读者访问路径。
先定义触发条件，再选择 CMS
只有当前流程出现可衡量的瓶颈时，CMS 才真正有价值，例如非技术贡献者无法安全发布、审阅需要角色与审批、媒体复用困难，或搜索和更新文章库耗时过高。迁移前先记录触发条件，再用一篇有代表性的双语文章测试字段、重定向、预览、修订、图片元数据和导出备份。CMS 能减少部分编辑摩擦，但也会增加身份认证、schema 迁移、webhook、预览基础设施、供应商可用性和新的恢复路径。
为发布保留证据记录
每次重要发布应记录提交、生产 URL、检查过的页面、构建结果，以及可能过期的内容假设。至少验证一篇文章、对应语言版本、一个集合页、sitemap、robots 规则和一张真实图片。部署后还要检查公开 HTML 与链接，不能假设构建成功就证明域名、代理或分析配置正确。这份小型记录能让未来回归问题与最后一次正常发布直接比较，而不是从头猜测。
一套可持续的节奏
可持续的节奏可以是每一到两周发布一篇扎实文章，事实变化时再做短更新。用问题而不是关键词维护待办清单，每季度检查旧文章、失效链接和示例。小而可靠的维护习惯，长期价值高于一堆无人维护的草稿。
常见问题
新内容站应该一开始就使用 CMS 吗？
不一定。如果每月只有一个人发布几篇文章，Git 文件通常更快、更容易审阅。只有当非技术贡献者、编辑流程或文章规模带来真实需求时，CMS 才更值得引入。