关于 Byline

Byline 为何存在

Byline 源于一种挫败感，而我们怀疑许多项目都有同样的感受。根据我们的经验，大多数内容管理系统至少会在三个根本性关注点中的一个上表现吃力：版本控制、工作流或内容翻译。很多系统在这三方面都会遇到困难。而当它们试图同时支持这三者时，往往就会出问题——有时很明显，但更常见的是，问题会以不易察觉的方式潜伏，直到你已经深陷一个真正的项目、面对真实的利害关系时才浮现出来。

三大支柱

我们相信，内容管理建立在三大支柱之上，而且这些支柱可以共存，而不会形成相互排斥的状态，也不需要在彼此之间进行取舍。

内容翻译并不等同于界面翻译。你撰写内容所使用的语言，与管理系统所使用的语言并不是一回事。大多数 CMS 平台都会混淆这两者。Byline 在数据模型层面将它们区分开来。

版本控制应当是不可变的，并且默认启用。每一次变更都会创建一个新版本。文档的当前状态是一个指针，而不是一次修改。版本控制不是一个功能；它是基础。

工作流应当默认启用。编辑工作流应当是一项一等公民式的核心关注点，而不是通过插件或配置事后拼接上去的附加功能。

而且，这三个关注点都应当协同工作。

数据所有权

我们相信，如果你创建并存储了内容，你就应该能够把它完整地取出来。不是通过一个勉强能用的导出插件。也不是通过一个只能返回你所存储内容 80% 的 API。你的数据应当可以被迁移、提取，并且随时都能被完整使用。

这不是一种意识形态立场，而是一种务实的立场。我们与足够多的组织合作过，他们被平台锁定，或者在迁移中丢失了内容，或者太晚才发现他们的 CMS 以一种让数据提取变得痛苦且有损的方式存储内容。

以开放方式构建

Byline 的开发者与非营利组织和 NGO 有过广泛的合作，而这项工作让我们看到了某些自由的价值：拥有、控制并分享那些值得被看见的内容的自由。我们选择以开放方式构建，是因为我们认为自己正在解决的问题是共同的问题，也因为相比于孤立地开发，我们更愿意与理解这些问题的人一起构建。

关于在 Byline 开发中使用 AI 的说明

Byline 的核心存储模型、早期 UI，以及 schema / 管理配置系统，最初都是由人工开发完成的，建立在多年基于其他框架构建解决方案的经验之上。在我们的核心模型稳定下来之后，并且在 2025 年 12 月左右 AI 编程助手经历了那次“重大飞跃”之后，我们越来越多地采用一种“引导式”的方法，使用基于 LLM 的生成式 AI 来设计和规划各个工作阶段。这是一段非凡的旅程。Byline 的开发边际成本因此显著下降——下降的幅度之大，以至于仅凭一个 2 人团队，我们就能够独立做出一个“相当不错”的 v1 版本。下一阶段的开发将聚焦于稳定性、重构和文档编写。

我们的直觉是，即使在基于 LLM 的 AI 这个快速演化的世界里，像 Byline 这样的内容管理系统仍会是对我们的工作以及我们所支持的组织都有用的工具。我们也对在 Byline 之上构建更高层级、由 AI 赋能的服务的前景充满期待。很难预测这一切最终会如何发展，尤其是在一个快速变化的软件开发世界中，不过我们相信，上述使命与愿景——连同我们关于 AI 时代的内容管理 的说明——依然成立。时间会证明我们是否猜对了。;-)