graph TD
    Developer[docs/developer]
    Architecture[architecture/]
    Modules[modules/]
    Guides[guides/]

    Overview[系统地图]
    Runtime[运行时分层]
    DataFlow[数据流与关键文件]
    Business[业务模块]
    TaskGuides[开发任务指南]

    Developer --> Architecture
    Developer --> Modules
    Developer --> Guides

    Architecture --> Overview
    Architecture --> Runtime
    Architecture --> DataFlow
    Modules --> Business
    Guides --> TaskGuides

也可以把这三层理解成：

flowchart LR
    A[architecture]
    B[modules]
    C[guides]

    A -->|先理解系统| B
    B -->|再理解业务边界| C
    C -->|最后落到开发动作| Done[开始修改与维护]

计划中的目录结构

docs/developer/
  README.md
  architecture/
    README.md
    overview.md
    runtime-architecture.md
    data-flow.md
    file-map.md
    decision-log.md
  modules/
    README.md
    extractor.md
    cleaner.md
    validation.md
    auth.md
    update.md
    settings.md
  guides/
    README.md
    local-development.md
    debugging.md
    ipc-development.md
    renderer-development.md
    release-process.md

内容组织原则

这套文档会按“读者任务”来组织，而不是简单照抄源码目录。

文档主要分为三类：

architecture/ 说明系统整体结构、运行时分层、关键数据流和核心设计决策。
modules/ 说明每个业务模块的职责、入口文件、调用链、状态流和常见改动点。
guides/ 说明开发者在实际工作中最常见的任务，例如本地启动、调试、扩展 IPC、修改前端页面、发布版本等。

维护约定

为了保证这套文档长期可用，后续维护建议遵循这些约定：

新增核心模块时，同步补一篇对应的模块文档
发生重要重构时，更新相关架构文档和决策记录
文档优先解释“职责、边界、调用关系”，而不是堆砌实现细节
文档应当多用、善用 mermaid 做图形化表达
遇到结构、分层、调用链、时序、流程时，优先考虑先画图再解释
图负责帮助读者快速建立整体认知，文字负责解释细节和边界
文档尽量附上关键文件路径，并保持图和正文一一对应
文档中的路径、模块名、调用链描述应与当前代码保持一致

当前状态

当前 developer 文档目录刚刚建立，后续会优先补齐这些内容：

项目总览
运行时架构
extractor 模块
cleaner 模块
validation 模块
update 模块

README.md

Developer Docs

文档目标

推荐阅读顺序

开发者文档总导航

计划中的目录结构

内容组织原则

维护约定

当前状态

相关文档