仓库与技术栈总览 ​

1. Monorepo 结构 ​

Plate 使用 pnpm workspace + Turbo 的 monorepo。核心结构在 tooling/CONTRIBUTING.md 和根 package.json/turbo.json 可直接看到：

• apps/www：Next.js 文档站 + 组件注册中心（也是“参考实现”）
• packages/*：功能包（核心、节点插件、AI、协同、序列化等）
• docs/*：MDX 文档体系

packages 当前是高颗粒度拆分（本地可见 48 个 package），这是插件化生态和 tree-shaking 的基础。

2. 关键工具链 ​

• 包管理：pnpm@9
• 构建编排：turbo
• 包构建：tsdown（根脚本 p:build/p:build:watch）
• 质量：biome + eslint + bun test
• 发布：changesets

这套组合的目标很明确：多包并行构建 + 低发布摩擦 + 能快速迭代 breaking changes。

3. 包分层（需要会讲清） ​

建议按“基础层 -> 能力层 -> 场景层”回答：

1. 基础层
   • @platejs/slate：对 Slate 能力做 API/Transform 抽象
   • @platejs/core：插件系统、编辑器初始化、核心插件链
2. 能力层
   • 节点/标记插件：basic-nodes、list、table、media 等
   • 序列化插件：markdown、docx、html 等
   • 协同与高级能力：yjs、ai
3. 场景层
   • apps/www 的 registry、模板、playground

4. 项目状态与工程哲学 ​

从仓库规则与迁移文档可以看出：Plate 是“快速演进”的框架型项目，允许高频大版本调整，优先级通常是：

• DX 与 API 清晰度
• 可组合性与扩展性
• 性能和大文档体验
• 再兼顾兼容性（而不是绝对优先）

这会直接影响你在交流中的判断：Plate 的很多“重构式改动”不是不稳定，而是为了框架长期可维护。

5. 你可以主动提的亮点 ​

• 核心包不是“功能大杂烩”，而是明确把创建、解析、覆盖、扩展拆开
• React 层和非 React 层有清晰边界（withSlate vs withPlate）
• 官方把 issue/PR 当成架构讨论场，很多决策动机在 PR 和 migration 中是显式写出来的

小结 ​

先把 Plate 当作“可组合编辑器平台”而不是“单一富文本组件”。理解这一点后，后面插件系统、api/tf 分层、Yjs/AI 设计都会自然很多。