开发 Prosefly
内容提要
作者在运营 Typlog 后开发新项目 Prosefly，用于管理 GitHub 仓库中的文档文章，并提供可视化编辑器。他认为 AI 时代静态网站容易搭建，但写作仍需要友好的界面，Prosefly 还能按项目自定义 frontmatter 字段。开发顺序为先做编辑器，再做 Astro 模板，最后建平台。选型时曾误用 Cloudflare Workers for Platforms 导致架构复杂，后改用 Durable Objects 实现数据隔离，平台得以简化并继续推进。
延伸解读
AI 时代为何仍需可视化编辑器
文章指出，AI 让静态网站搭建变得容易，Markdown 文件与代码共存也方便 AI 读取修改。但作者强调，用文件保存数据与如何写文章是两回事。调整格式、插入图片等操作，可视化编辑器更舒适，无需每次改源码。这提醒我们，工具效率的提升并不完全取代写作界面的友好性，两者解决的是不同环节的问题。
自定义 frontmatter 字段的灵活性
Prosefly 直接读取项目中用文本定义的 frontmatter schema，并据此生成编辑界面。与 Typlog 预先定义字段、用户不便修改不同，Prosefly 允许按网站需求灵活增删字段，例如写书评时加入作者和评分。这种设计让内容模型与网站代码同步演进，做新模板时无需先确认平台是否支持对应字段，降低了平台对内容结构的限制。
先做编辑器与模板的开发顺序
作者没有一开始就构建完整平台，而是先花大量时间设计可视化编辑器，确保保存 Markdown、MDX 的同时提供可视化写作体验。编辑器接近完成后，又先创建 GitHub 组织、制作 Astro 主题和模板，再开发 Prosefly 平台。这样做能在实际网站中检验内容组织与 frontmatter 定义，让编辑器与模板提前配合，降低后续平台开发的不确定性。
Cloudflare 选型弯路与简化
开发 Prosefly 时，作者需要按组织拆分数据、实现数据隔离，最初选用 Cloudflare Workers for Platforms，结果架构变得特别复杂，一度打算放弃。后来发现 Durable Objects 就能满足需求：每个组织的数据放在各自的 Durable Object 里，应用仍是同一个，无需部署和管理不同 Worker。这一教训说明，选型时应先明确核心需求，避免为隔离引入过度复杂的方案。
Q&A
Prosefly 是什么？它主要解决什么问题？
Prosefly 是一个用于管理 GitHub 仓库中文档和文章的工具，提供可视化编辑器来写作。它解决的是：虽然 AI 时代用 Markdown/MDX 文件保存内容很方便，但写作本身仍需要一个友好的可视化编辑界面，避免每次改源码。
Prosefly 的 frontmatter 字段和 Typlog 有什么不同？
Typlog 的 frontmatter 字段由平台预先定义，用户不方便修改；Prosefly 则直接读取项目中用文本定义的 frontmatter schema，再按它生成编辑界面。这样用户可以根据网站需要自定义字段，比如写书评时加上作者和评分。
Prosefly 的开发顺序是怎样的？
先花很久设计可视化编辑器，保存 Markdown/MDX 并追求可视化写作体验；等编辑器接近完成，再创建 GitHub 组织、做 Astro 主题和模板；最后才开始开发 Prosefly 平台。
为什么 Prosefly 先做 Astro 模板再做平台？
先做模板有机会把内容组织和 frontmatter 的定义放进一个实际的网站里，看看编辑器怎样配合。到开始写平台时，已经有了可以编辑的内容，也有了使用这些内容的网站。
Prosefly 在 Cloudflare 选型上犯了什么错？后来怎么解决的？
一开始选了 Workers for Platforms 来做按组织拆分数据、实现数据隔离，结果把项目弄得特别复杂，一度打算放弃。后来发现 Durable Objects 就能做所需的数据分离：每个组织的数据放在各自的 Durable Object 里，应用还是同一个应用，不需要部署和管理不同的 Worker。换成这个方案后平台简单了很多。
Prosefly 为什么选择用 Cloudflare Workers 开发？
文章提到作者是用 Cloudflare Workers 来开发 Prosefly 的，需要按组织来拆分数据、做数据隔离。但并未详细解释选择 Workers 的原因，只说明了后续在 Workers for Platforms 和 Durable Objects 之间的选型调整。
