dimensions

​
背景与动机：应对开发者生态的演进

Dify 最初的成功很大程度上源于其产品的直观易用性。对于核心用户（User/Buyer），产品本身的体验往往足以引导他们；对于少数需要深度定制的早期开发者而言，他们通常具备直接阅读源代码的能力。因此，初期的文档建设并非最高优先级。

然而，随着 Dify Plugin 插件生态的上线和蓬勃发展，情况发生了显著变化：

  1. 受众扩大化： 我们的开发者社区不再局限于能够深入源码的核心贡献者。大量拥有一定技术背景但可能不熟悉 Dify 底层或特定编程范式的**“半专业开发者” (Citizen Developers)** 或集成开发者涌现，他们需要清晰、循序渐进的指导来构建和贡献插件。
  2. 内容交织与目标模糊： 现有的文档往往将面向最终用户的帮助内容（如何使用插件）与面向开发者的技术内容（如何开发插件）混合在一起，导致两类受众都感到困惑，增加了信息查找成本。
  3. 结构缺失与导航困难： 文档缺乏统一的组织结构和逻辑顺序，使得开发者（尤其是新加入者）难以找到所需信息，也无法形成对插件开发生命周期的完整认知。现有导航难以承载日益增长的内容。
  4. 构建开发者关系 (DevRel) 的基石： 一个清晰、有效、结构优异的开发者文档体系，是构建成功开发者关系、繁荣插件生态不可或缺的一环。它直接影响开发者的体验、贡献意愿和成功率。

基于以上挑战，以及对业界优秀范例（如 Zapier Developer Platform, Cloudflare Docs）的分析——它们都展现了清晰的受众分离、结构化的内容组织和面向不同技能水平的路径设计——我们认识到对 Dify 的开发者文档进行系统性重构的迫切性。

dimensions系统应运而生。它并非一套僵化的格式要求，而是我们为了解决上述问题，将结构化思维、受众细分、渐进式学习等理念，通过一套基于元数据的自动化流程沉淀下来的解决方案。它旨在为 Dify 插件开发者提供一个清晰、一致且易于导航的技术知识库。

​
核心原则：元数据作为规范性数据源

本系统的基石在于以下核心原则：

  • 元数据驱动 (Metadata-Driven): 每篇 Markdown 文档的 Front Matter 中定义的元数据（特别是 dimensions, standard_title, language）是描述该文档内容属性、目标受众和预期用途的规范性数据源 (Normative Data Source)。
  • 内容与表现分离 (Decoupling Content from Presentation): 文档的最终呈现形式——包括文件名、在文档网站上的排序、导航菜单结构——都必须由自动化工具根据这些元数据动态生成。作者应专注于内容本身及其元数据描述的准确性。
  • 自动化保障一致性与可维护性 (Automation for Consistency & Maintainability): 自动化流程确保了整个文档库在结构、命名和排序上的一致性。对分类体系或排序逻辑的调整，只需修改中央配置和生成脚本即可全局应用，极大地提高了可维护性。

这种方法论让内容创作者（作者）和技术实现者（文档系统维护者/DevOps）能够有效协作，共同服务于最终开发者读者的需求。

​
元数据规范

每篇开发者文档（Markdown 文件）必须包含一个 YAML Front Matter 块，定义如下关键字段：

---
# --- 核心元数据 ---

# 'dimensions' 用于内容分类和自动排序
dimensions:
    type: # 主要类别 (Conceptual, Implementation, Operational, Reference) - 决定宏观顺序 (W)
        primary: <primary_type_value> # 次要类别/细节 (Introduction, Basic, Core, Examples...) - 决定章节内顺序 (X)
        detail: <detail_type_value>
    # 目标读者级别/内容复杂度 (Beginner, Intermediate, Advanced) - 决定微观顺序 (Y) 及优先级 (P)
    level: <level_value>

# 'standard_title' 用于生成可读的文件名，并供概览页面使用
standard_title: '文档的标准、描述性标题'

# 'language' (ISO 639-1 代码如 'en', 'zh') 用于国际化(i18n)和文件名后缀
language: <language_code>

# --- 其他可选元数据 ---

# 'summary': 文档内容的简短摘要 (可选, 可能用于列表页或 SEO)
# 'tags': [关键词列表] (可选, 用于过滤或关联内容)
# ... 其他未来可能需要的字段
---

Type Dimension (Primary)

-   conceptual: Theoretical or explanatory content
-   implementation: Code and development content
-   operational: Content related to running and maintaining the system
-   reference: Reference materials

Type Detail Dimension

-   For conceptual: introduction, principles, architecture
-   For implementation: basic, standard, high, advanced
-   For operational: setup, deployment, maintenance
-   For reference: core, configuration, examples

Level Dimension

-   beginner: For newcomers to the topic
-   intermediate: For users with basic understanding
-   advanced: For advanced users

​
dimensions 深度解析：为内容赋予意义

dimensions 元数据是本系统的核心，它要求我们为每一篇文档回答三个基本问题，从而赋予其明确的语境、范围和受众定位。这种分类是后续所有自动化结构和排序的基础。

  • dimensions.type.primary：定义内容的“性质”

    • 核心问题: 这篇文档从根本上属于哪一类知识？它是关于“是什么/为什么”（理论），“如何做”（实践），“如何运行/维护”（运维），还是“精确查找”（参考）？
    • 作用: 这个维度确立了文档在整个知识体系中的宏观类别。我们采用 conceptual, implementation, operational, reference 这几个业界通用的分类，来划分开发者关注的主要领域。这个分类决定了文档所属的顶层章节或主题区域，是构建文档信息架构的第一步。

  • dimensions.type.detail：明确内容的“主题焦点”

    • 核心问题: 在上述宏观类别下，这篇文档具体是关于该类别的哪个特定方面或子主题？例如，是某个概念的“入门介绍”，还是某个实现的“标准用法”，或是某个参考信息的“核心 API”？
    • 作用: 它在主类别内部提供了更精细的主题划分。这使得相关的文档能够聚集在一起，形成逻辑连贯的子章节或段落。选择恰当的 detail 有助于用户在浏览特定章节时快速定位到具体内容点。

  • dimensions.level：标定内容的“复杂度与受众”

    • 核心问题: 这篇特定主题的文档，主要是为哪个经验水平的读者准备的？或者说，其内容的复杂度如何？是入门 (beginner)，通用 (intermediate)，还是深入/专门 (advanced)？
    • 作用: 这个维度具有双重关键作用：
      1. 细粒度排序: 在同一具体主题下，它允许内容按从易到难的顺序排列，优化学习曲线。
      2. 优先级判定: 它（尤其是 advanced 级别）是系统区分“核心内容”与“进阶/深水区内容”的关键输入，直接影响内容是否被后置（见第 5 节）。

为内容精准地打上这三个维度的标签，是确保文档库结构合理、易于导航、满足不同用户需求的前提。

​
排序机制：PWXY 前缀与优先级规则

为实现一致且逻辑清晰的文档呈现顺序，系统将根据 dimensions 元数据为每篇文档自动生成一个 4 位、零填充的数字前缀 (PWXY)，并以此作为文件名的一部分来实现排序。

  • P 优先级 (Priority): 第 1 位。区分常规 (P=0) 与后置/深水区 (P=9) 内容。
  • W 主类编号 (Primary Type): 第 2 位。体现 primary 类型的宏观顺序。
  • X 子类编号 (Detail Type): 第 3 位。体现 detail 类型在主类内的顺序。
  • Y 难度级别编号 (Level): 第 4 位。体现 level 在子类内的顺序。

优先级 (P=9) 规则详解:

将内容标记为 P=9 的目的是，将对入门和常规使用非必需的、复杂度较高的内容自动后置，从而为主流用户群体提供更平滑的学习曲线和更聚焦的核心内容流。触发 P=9 的条件是：

  1. 内容本身定义为高级: level: advanced。
  2. 实现类目下的特定复杂细节: primary: implementation 且 detail 为 high 或 advanced。

P=9 的内容可被视为文档库的“附录”、“深度探讨”或“高级参考”。

​
文件名生成策略

最终部署的文件名由自动化脚本基于元数据生成，其概念格式为： PWXY-[sanitized_standard_title].language.md

此文件名主要用于机器排序和内部标识。文档的人类可读标题以 standard_title 元数据和文档内的 H1 标题为准。自动化脚本负责处理元数据提取、PWXY 计算、标题清理、语言后缀、基于 GitHub 的编辑与反馈按钮的自动实现等所有细节。

​
面向受众的设计原则：渐进式披露与路径优化

本系统的设计贯穿着“渐进式信息披露” (Progressive Disclosure) 的核心原则，旨在优化不同背景开发者的信息获取路径。

  1. 优先级机制 (P 值区分): 这是实现渐进式披露的主要手段。系统性地将基础、核心、高频使用的内容 (P=0) 与高级、复杂、特定场景的内容 (P=9) 分离开来。这保证了用户默认首先接触到的是一个相对精简、聚焦核心的知识体系。
  2. 结构化分类 (基于 type.primary 和 type.detail): 即便在同一优先级内，内容也被清晰地组织成不同类别和主题，为所有用户（尤其是经验丰富的用户）提供了一个可预测的“信息地图”。

基于以上原则，系统致力于为不同目标受众提供优化的体验：

  • 学习者与初探者 (Learners & Newcomers, incl. Citizen Developers): 通过默认阅览 P=0 的内容序列，获得一条从概念到基础实践的、结构化的学习路径，从而循序渐进，降低初期认知负荷。
  • 经验丰富的开发者与贡献者 (Experienced Developers & Contributors): 利用清晰的结构进行高效的随机访问，快速定位特定参考信息或实现细节，或根据需要直接深入 P=9 的高级内容。文档库对其而言更像一本可快速查阅的技术手册。
  • 自动化工具与服务 (e.g., LLMs): 承认其与人类不同的信息消费模式。结构化的元数据使我们能够为其生成专门优化的、可能更扁平化的数据输入流（如 llms-full.txt），提升其理解效率。

总而言之，dimensions 系统并非试图用一种方式满足所有人，而是通过结构化分类、优先级排序和元数据驱动的自动化，为不同需求的用户群体提供各自相对最优的信息访问和学习路径。

​
系统收益

  • 结构清晰 & 导航改善: 基于可靠的分类和可预测的排序。
  • 一致性体验: 自动化确保所有文档遵循相同模式。
  • 受众适配: 通过优先级区分，提供差异化的阅读路径。
  • 高可维护性: 调整分类或排序逻辑只需修改中心配置和脚本。
  • 可扩展性: 易于添加新的内容类型或难度级别。
  • 促进协作: 为作者、审阅者和系统维护者提供了共同的理解基础和协作标准。

​
创作流程、角色与治理：应对现实挑战

建立高质量文档库是一个涉及多方协作的过程，并面临现实挑战。dimensions 系统旨在成为这个过程中的一个结构化框架和协作工具。

​
协作模型中的关键角色

  • 创作者 (Creator / Author):

    • 核心职责: 创作准确、清晰、有价值的文档内容。
    • 协作要点: 学习并尝试理解 dimensions 分类体系，在提交时为文档尝试打上最合适的元数据标签（dimensions, standard_title, language）。准确的初始分类有助于后续流程。

  • 审阅者 (Owner / Reviewer):

    • 核心职责: 对文档内容的准确性、清晰度、范围以及元数据的恰当性进行最终把关。这是确保文档库质量和结构一致性的关键环节。
    • 能力要求: 需要具备对相关技术领域的深刻理解，同时要能理解 dimensions 系统背后的整体信息架构和受众细分逻辑（这往往需要一定的系统性思维，类似于架构师视角）。
    • 协作要点: 利用 dimensions 作为客观“标尺”来评审内容定位。如果元数据不准确或内容边界模糊，应指导创作者修改或直接修正元数据。最终合并到主分支的元数据决定了文档的呈现。

  • 运营者 (Operator / DevOps):

    • 核心职责: 维护和优化文档自动化构建、测试、部署的流程与工具。
    • 协作要点: 确保自动化脚本正确、高效地解析元数据并生成最终产物（排序的文件、导航数据等）。他们关注的是流程的健壮性，而非单篇文档的内容细节。

​
应对文档协作的现实挑战

这种角色划分有助于我们正视并尝试缓解一些常见的文档困境：

  • “程序员不爱写文档” vs. “写文档的不懂技术”：

    • dimensions 系统降低了对创作者（程序员）的要求：首要任务是写准技术内容，元数据分类可以“尽力而为”，因为有审阅者把关。
    • 同时，它提升了对审阅者的要求，承认了高质量文档需要深刻的技术理解和架构性思维，并将这种高阶能力引导到对文档结构和元数据的把控上。
    • 对于可能存在的“专职文档工程师”，他们可以作为创作者，或者辅助审阅者进行元数据校验和内容润色，角色更加灵活。

  • 高质量审阅者稀缺且“性价比”疑虑：

    • 确实，具备所需技术深度和架构思维的审阅者是宝贵的。他们可能会觉得审阅文档相比核心功能开发“价值较低”。
    • 关键在于提升认知： 必须强调，高质量、结构化的文档对于开发者生态的成功、降低支持成本、提升产品采用率具有极高的战略价值。dimensions 系统正是将审阅者的高阶思维显性化、规范化，并直接转化为可衡量的文档体验提升的工具。审阅文档不再是“杂活”，而是塑造开发者体验、构建知识体系的关键一环。

  • 流程保障: dimensions 系统提供了一个协作框架。它鼓励创作者思考内容定位，赋予审阅者清晰的评估标准和修正权限，并让运营者可以独立地维护自动化流程。通过将元数据检查纳入 PR 流程（类似 Code Review），可以制度化地保障最终产出的质量。

​
扩展性与代码的角色

  • 系统扩展: dimensions 的分类体系并非静态。随着 Dify 功能的演进，可以（也应该）适时增加新的 primary 类型、detail 类型或 level。这主要通过更新中央映射配置和（如有必要）调整生成脚本来实现，体现了系统的灵活性。
  • 文档与代码的关系: 开发者文档（特别是 Reference 和高级 Implementation 部分）的核心目标之一是作为理解和使用源代码的有效向导。它应解释代码层面的设计、用法、约束，并通过链接等方式促进开发者在需要时无缝地深入到源代码这一最终的、最精确的内容中。文档不是代码的替代品，而是其高质量的另一面和解释器。

编辑此页面 | 提交问题