从去年底的首个原型到今年星标破三百的社区热度，EasyEditor Yi经不再是一个“玩具”。它逐渐演化为一套跨框架、可插件化的低代码引擎，却仍然在多个维度上留下了问号。本文把这些悬而未决的点拆开来聊聊，希望Neng给正在使用或准备尝试的朋友一点参考。

Zui初我们把渲染器写成了纯 JavaScript + JSX 的组合，以求Zui快上线。两个月后业务方开始要求在同一个页面混合 Vue、React 与 Svelte 三种框架的组件。于是我们在路由层面Zuo了“按需拆分”，让语言包体积保持在可接受范围。但这种拆分方式是否会在geng大规模的项目里导致依赖冲突？有没有geng系统的插件机制Ke以把不同框架的运行时统一抽象出来？这仍是团队内部热议的话题。

年底我们给 EasyDashboard 加装了一个简易的聊天机器人，用来帮助新人快速生成表单配置。它基于 Qwen2.5‑1.5B‑Instruct 微调模型，仅凭几句话就Neng输出 JSON 配置文件。实际使用时发现：

模型对业务特有字段理解有限，需要人工二次校验；

提示词工程的调优成本比预期高出两倍。

过去一年我们把文档搬到了 VitePress，并且在 GitHub Pages 上开通了独立域名。发布后阅读量从几百跃升至两万，可见需求旺盛。然而：

搜索功Neng弱：用户常抱怨找不到对应 API 的示例；

版本兼容说明缺失：当核心库升级到 v2.1 时大量老项目报错，却没有明确迁移指南；

社区互动不足：虽然 Star 数增长，但 Issue 的响应时间仍在 48 小时以上。

这些痛点让我们意识到，仅靠“一份文档”并不Neng满足快速增长的生态需求。

2025 年我们共招收三批实习生，分别在 4 月、9 月和 11 月进入团队。Zui初的两个月里他们主要负责 Bug 修复和小工具编写；随后被安排参与 Dashboard 的拖拽交互实现。不过：

任务拆解不够细致：有时一个 Feature 被直接交给新人，导致进度受阻；

远程沟通成本高：尤其是跨时区协作时同步需求往往出现信息丢失；

LMS缺失：没有统一的学习路径，让新人只Neng靠自学或临时请教。

Ru果想把实习生真正培养成项目主力，上述环节必须得到系统化改进。

早期我们只关注本地开发体验，用 npm run dev 把编辑器跑起来即可。但随着企业客户要求将 EasyEditor 嵌入内部平台，部署难题随之浮现：

Nginx + RTMP → RTSP 的协议误差：a/b 测试阶段才发现监控流协议不匹配，导致现场调试耗费大量时间；

CICD 流水线不完整：Pnpm monorepo 在多子包发布时需要手动处理 --global 参数；

SLA缺乏监控模板：客户对大屏实时刷新有严格延迟要求，但我们的默认配置只Neng满足普通业务场景。

因此，一个完善的“一键部署脚手架”和配套监控仪表盘成为迫切需求。

三月份一次针对东南亚市场的需求，让我们尝试按路由拆分语言包，以降低首屏加载体积。结果显示：

Spa 页面切换时语言文件会被重复请求，引起闪烁；

L10n中日期/数字格式需要针对每个语言再Zuo二次处理。

A/B 测试表明，即使粒度再细，也难以兼顾所有语言环境下 UI 的一致性。因此，我们正在评估一种“动态加载 + 本地缓存”的混合策略，希望既保留轻量特性，又Neng避免频繁网络请求。

插件市场化运营：Kits、Theme 与 DataSource 分别独立打包，让第三方开发者Ke以直接上架；

Ecosystem CI/CD：Pnpm + Changesets 完全自动化发布，实现 monorepo 中每个子包dou拥有独立版本号；

AIOps 集成：将运维监控与 AI 错误预测嵌入编辑器，使异常Neng够提前预警并提供修复建议；

LMS+Mentor 双轨制培养体系：- 新人入职即获得学习路线图 - 老成员通过 Review 帮助新人完成任务闭环。

一句话概括：EasyEditor Yi经站在十字路口——要么继续深耕低代码核心技术，要么把焦点转向生态与运营。从现在起，每一次提问dou是一次前进的加速器。