换个底座的 Wot Starter 居然让 AI 更懂项目！

你大概也遇到过：让 Agent 在项目里加个页面，它把自动生成的 pages.json 当源文件改了，或者在一堆插件配置里找不到该动哪。

问题往不在模型，在项目本身对 AI 是不是黑箱。

我把 wot-starter 的底座换成 oiyo 之后，最想解决的就是这件事：让项目变成人和 AI 都读得懂的样子。

如果你用过 wot-starter，应该对它不陌生：基于 vitese-uni-app，把 Wot UI 组件库深度整合进来，一个挺完整的 uni-app 起手项目。

oiyo-starter 没有彻底推翻它。组件库依旧是 wot ui，router、图表、ci 这些周边也基本沿用。真正换掉的是工程底座，从插件拼装，换成 oiyo 框架的一体化约定。

下面这张表是两边的总览，后面我挑几处最有体感的差异展开说。

维度	wot-starter	oiyo-starter
工程底座	vitese-uni-app + 一堆 Vite 插件	Oiyo 框架，一体化约定
配置入口	vite.config、manifest.config 分散	oiyo.config.ts 集中
应用壳	uni-ku-root 插件模拟 App.vue	原生 OiyoPage / OiyoLayout
页面与导入	各自插件约定	definePageMeta + Oiyo scan
请求库	Alova	OiyoHttp
AI 支持	.agent、.cursor/rules	内置成套 Skills
命令	vite / uni 脚本	oiyo dev / build / prepare

01 配置从分散到集中

wot-starter 那套的思路是插件拼装。基于文件的路由、组件自动加载、API 自动导入，每一样背后都是一个 plugin，配置散落在 vite.config、manifest.config 和各插件选项里。

这套能跑，但代价是你想改一处约定，得先知道它归哪个插件管。项目一大，配置的心智地图就越来越模糊。

Oiyo 的做法是把这些收进一个入口。扫描哪些组件、哪些 API、哪些目录，都写在 oiyo.config.ts 里：

arduino 复制代码

scan： {
  components： ['@wot-ui/components/**/*.vue'， /* ... */]，
  apis： ['apis/*.ts'， 'utils/*.ts'， 'stores/*.ts'， 'pinia'， /* ... */]，
}

一个文件，就能看清这个项目自动导入了什么、页面从哪扫。配置面小了，记忆负担也就小了。

02 应用壳从插件模拟到框架原生

uni-app 原生的 App.vue 能力是受限的，想要一个真正的"根组件"来挂全局状态和布局，wot-starter 借助的是 uni-ku-root 这个插件，本质是模拟。

oiyo 把这件事做进了框架本体。App.vue 里直接用 OiyoLayout 包住 OiyoPage，全局状态用 defineRootContext 定义：

xml 复制代码

// App.vue
<script setup lang="ts">
const { theme, toast, dialog } = defineRootContext<RootContext>(() => {
  // ...
})
</script>

<template>
  <WdConfigProvider :theme="theme.theme">
    <OiyoLayout>
      <OiyoPage />
    </OiyoLayout>

    <WdNotify />
    <WdDialog selector="global" />
    <WdToast selector="global" />
  </WdConfigProvider>
</template>

页面插槽是 OiyoPage，布局入口是 OiyoLayout，跨页面共享的东西挂在根上下文里。渲染链路是显式的，不再是一个插件在背后帮你模拟。

03 页面与导入从插件约定到框架约定

wot-starter 的页面注册和自动导入依赖插件约定，能用，但每个能力对应一个插件，心智是碎的。

oiyo 把它统一成两件事。页面元信息用 definePageMeta 写在页面顶层，路由和 pages.json 自动生成：

php 复制代码

definePageMeta({
  type： 'home',
  layout： 'tabbar',
  style： { navigationBarTitleText： '首页' },
  tab: { iconPath: 'static/home.png' }
})

自动导入走同一套 scan 约定。页面怎么注册、符号从哪来，都收敛到 oiyo 一套心智里，不用在多个插件的文档间来回切。

04 请求库：少接一个生态，能力一个不少

wot-starter 用 Alova，好用，但要单独接一套请求生态，配一份 alova.config.ts。

oiyo-starter 直接用框架自带的 OiyoHttp，同源，零额外配置。请求成功默认只给你精炼后的 data，想要状态码再传 raw： true，干净利落。

真实项目用 createHttp 建公共实例，按"公共 → 鉴权 → 业务"层派生，token 写一次就全局生效。生命周期钩子、按幂等性的自动重试、请求随时中断，这些常用能力开箱就有。

05 AI 支持：让 Agent 照着约定走，少返工

wot-starter 也带了 .agent 和 .cursor/rules，方向对，但那是零散提示，Agent 读到的是碎片。

oiyo-starter 内置成套 Skills，把 Oiyo 的工程约定和 Wot UI 的用法整份喂给 AI。页面怎么加、配置在哪、导入怎么走，Agent 一读就懂。

以前让它加个分包页面，它爱去改自动生成的 pages.json，或者把 definePageMeta 写错位置。现在 Skill 里把规矩写死了，它照着走，我的返工肉眼可见地少了。

这也是我把 Skills 做进模板的原因。能让 AI 读懂的项目，新人和未来的自己一样能快速上手。

06 什么时候该换这个底座

如果你正在用 wot-starter，又常被这几件事困扰，可以试 oiyo-starter：配置太散、应用壳靠插件凑、让 AI 改代码总是改错地方。

router、uni-echarts、CI 这些都沿用了，迁移不会太陌生。上手也简单，pnpm install 会自动跑 prepare 生成类型和路由，pnpm dev 选平台就能跑。

如果你也在琢磨怎么让项目对 AI 更友好，欢迎进群一起聊，群在文末。觉得有用,去仓库点个 star，把它拉下来跑一遍，比看十篇介绍都直接。

关于作者

sky $Skiyee$ ，切图仔、全干攻城猫、轮子砖家。

Github: github.com/skiyee