你大概也遇到过这样的问题：

• 让 Agent 在项目里加个页面它把自动生成的pages.json当源文件改了或者在一堆插件配置里找不到该动哪。
• 项目本身对 AI 是不是黑箱，导致 AI 只会按零散提示走。
• 配置文件分散到vite.config。manifest.config,各插件选项里想改一点约定就得先定位到底是哪个插件。
• App.vue只能模拟根组件。真正的全局状态和布局得靠uni-ku-root
• 页面注册、自动导入每个能力对应一个插件，心智碎片化。
• wot-starter 用Alova。需要额外的.config.ts
• .agent、.cursor/rules 零散提示，让 AI 改代码时常改错地方。

从痛点一来看，配置分散。让你找不到方向

wot-starter 的思路是“插件拼装”。话说回来，每个功能背后都是一个 Vite 插件。所有相关配置都撒落在不同文件里：

换底座后只需要一个文件就能看到整个项目的扫描范围、自动导入规则和全局配置，大幅降低记忆负担。 你不再需要在多份文档间来回翻找。其实，

从示例来看，oiyo.config.ts 中的 scan 配置

export default {
scan:{
components:。apis:
}
}

为什么这很关键？

• 避免“我想改一次约定。却不知道它在哪个插件管”，从而节省数小时的排查时间。
• 新手可以一次性看懂项目结构，而不必先学会每个插件的细节。
• 减少跨团队沟通成本，一致的约定让前后端协作更顺畅。

痛点二这方面，应用壳靠插件模拟。根组件难以维护

wot-starter 用@wot-ui/uni-ku-root模拟 App.vue 的根组件，以挂载全局状态和布局。但这只是一个“”，真正意义上没有完整支持 root-level 生命周期和树形结构。说到结果是，

• 根组件无法共享跨页面状态。其实，
`
• 需要手动维护 state 与 UI 同步；任何一次更新都可能导致渲染错误或性能下降。`
• 升级或重构时必须逐层拆解并重新实现全局逻辑。` `
  `

  oiyo 如何解决？

  `

  `oiyo 将根组件功能内置到框架本体中：`