# NotionNext 愿景与路线图 NotionNext 的长期目标，不是把 Notion 简单包装成另一个博客模板，而是让它成为一个稳定、可演进、可由社区共同维护的内容发布系统。 Notion 负责内容生产、资料整理和团队协作；NotionNext 负责公开访问、主题展示、SEO、部署、性能和长期运营。两者连接得越自然，站长需要手工维护的地方就越少，内容也越容易持续沉淀。 ## 5.0 方向 5.0 不应只是“多几个功能”的版本。它更应该回答一个问题：一个普通站长如何在不被 Git、部署平台和 Notion 数据结构反复打断的情况下，长期维护自己的站点？ 围绕这个目标，后续路线会优先关注这些方向。 ### 1. 降低使用门槛 NotionNext 仍然是开源项目，但部署、升级、排错不能只服务熟悉工程流程的人。未来需要继续减少这些摩擦： - 更清楚的升级路径，降低分支、Fork、Pull Request 带来的理解成本。 - 更稳定的构建和缓存策略，减少“代码已经更新但网站仍是旧状态”的困惑。 - 更友好的错误提示和自检工具，让站长能先判断是配置问题、缓存问题还是代码问题。 - 更完整的文档，把常见真实场景沉淀成可复用的排查步骤。 ### 2. 更完整地承接 Notion 数据库能力 Notion 的数据库、视图、筛选和排序是许多站长真正依赖的能力。NotionNext 应尽量理解这些结构，而不是要求用户额外维护大量重复标签。 近期已经开始补齐嵌入数据库视图筛选等兼容问题。长期可以继续推进： - 更稳定地读取 Notion 数据库视图筛选、排序和分组结果。 - 支持更多 Notion 属性类型和多条件组合。 - 降低“为了网站展示而重复造标签”的人工维护成本。 - 明确哪些 Notion 行为可以可靠支持，哪些需要降级或文档说明。 ### 3. 主题、版型和内容模块化 NotionNext 已经有多套主题，但长期维护的关键不是主题数量，而是主题之间能否共享稳定的基础能力。 后续可以逐步沉淀： - 更清晰的主题接口和配置边界。 - 可复用的文章卡片、列表、图库、导航、筛选页面等内容模块。 - 面向不同场景的版型能力，例如案例库、作品集、知识库、产品页和导航站。 - 更容易迁移和维护的主题文档、预览图与测试方式。 ### 4. 更安全的升级体验 很多站长会在 Fork 后修改配置、样式或主题。项目需要承认这种现实，而不是假设所有人都只使用原始代码。 未来需要继续优化： - 把站长自定义配置和核心代码改动尽量分离。 - 让版本升级更容易判断哪些冲突必须人工处理。 - 对常见下游分支维护方式提供更明确的建议。 - 在 CI、测试和发布流程中尽早发现破坏性变更。 ### 5. 让更多角色能参与 开源项目不只需要核心代码贡献者。NotionNext 的真实使用场景很多，站长、设计师、文档维护者、测试者都能帮助项目变好。 我们希望把任务拆得更小、更清楚，让不同经验的人都能找到入口。 ## 可以如何参与 如果你还不熟悉代码，可以从这些事情开始： - 复现问题：提供网站链接、Notion 页面、分支名、部署平台和截图。 - 测试修复：在自己的站点或测试分支验证 PR 是否解决真实问题。 - 补充文档：把踩过的坑整理成教程、FAQ 或排查步骤。 - 改进体验：指出哪些概念、配置或升级流程对非开发者不友好。 - 贡献主题素材：补主题截图、使用说明、适用场景和配置示例。 如果你已经能改代码，可以优先关注： - Notion 数据结构兼容性和测试用例。 - 主题公共组件和版型模块。 - 构建、缓存、部署和升级稳定性。 - 文档站、CI、发布流程和维护工具。 - 带有 `good first issue` 或 `help wanted` 标签的问题。 ## 近期适合拆分的任务 这些方向适合逐步拆成 Issue、Discussion 或 RFC： | 方向 | 可拆任务 | | --- | --- | | Notion 数据库能力 | 补齐视图筛选、排序、状态分组、多选、日期、关系属性等兼容测试 | | 图文卡片版型 | 为标签页、分类页或指定数据库视图提供稳定的卡片展示方案 | | 升级体验 | 梳理 Fork 用户如何同步上游、如何处理分支和部署缓存 | | 主题模块化 | 抽象文章卡片、列表、图库、筛选页等跨主题可复用组件 | | 文档维护 | 把真实用户反馈整理成 FAQ、排查手册和升级指南 | | 测试与 CI | 为关键数据格式、构建缓存、主题渲染补充小范围自动化验证 | ## 协作原则 - 先讨论真实场景，再设计功能。 - 大改动先写 RFC，小修复保持 PR 小而清楚。 - 优先补测试和文档，减少后续维护成本。 - 允许非代码贡献存在价值，真实反馈本身就是项目路线的一部分。 NotionNext 的 5.0 不是某个人一次性完成的大版本，而是社区持续把复杂度收拢、把门槛降下来的过程。每一次可复现的问题、一次文档修正、一个小范围 PR，都会让后来的站长少踩一个坑。