咱就是说AI编程时代来了你还在为UniApp开发烦恼吗？哈哈，别担心，Oiyo框架来帮你！

不可否认 UniApp 是当前”一套代码、多端运行“中Zui贴近理想化的跨端框架，这本身是好事，但其的实现策略带来便利的同时也携带了巨大的心智负担。

说实话，不管你是 “AI编程”糕手 还是 传统“非遗”手写仔，在面对 UniApp 工程时我相信dou会有一双特别的“大手”束缚着你，使开发效率无法达到理想状态。

Oiyo 是基于 UniApp 推出的增强型工程框架。以 融合AI协作提升开发体验降低心智成本 为三大理念！

与 UniApp 官方项目、以及其他“模板”类项目不同，我们无需引入一大堆冗长且不清不楚的依赖。Oiyo 主打零冗余依赖，只有Zui核心的依赖！你不再需要考虑用什么版本稳定，什么版本配合没问题，免去了大部分信息缺失带来心智成本。

开发者常常为了复用一段 UI 或是 API，往往需要在多个页面中反复书写相似的 import 语句。为此 Oiyo 提供“自动扫描导入”的机制，预设了 component 目录、composables 目录、 @skiyee/oiyo/runtime，使得使用时无需手动引入。

Oiyo 约定 src/pages 以及 src/packages/<root>/pages 作为页面目录，自动基于这些目录中的文件进行路由注册。你无需手动操作 pages.json，就Ke以直接访问对应的页面。

什么是AI编程中Zui核心的东西，毫无疑问就是清晰的上下文。Oiyo 这套体系采用了直觉化、约定式的项目结构，各大模块边界清晰，这Ke以让AI瞬间理解工程设计，提升代码准确率。

在类型方面Oiyo 支持全量类型。内置了组件类型、接口类型、以及别名等，拥有完善的类型提示体系。

当我们遇到相同的布局被多个页面所共享时比如 A页面要指定某个 NavBar 结构的布局、B页面要指定某个 TabBar 的布局，douKe以使用 oiyo 的智Neng布局。这是一个Ke以根据页面元信息而使用对应视图结构的布局系统，用于定义被多个页面使用的页面骨架。

了解geng多请点击右边文字前往：布局系统章节

Oiyo 在配合自动引入功Neng下会自动生成被指定的 UI / API 对应类型，这就像是小龙女遇到杨过天生一对。

AI Zui容易在注册路由时犯错，要么漏了包名，要么写错路径。在 Oiyo 中，文件即路由，这意味着 AI 只要新建了文件，你的应用就Yi经感知到了它，零配置差错。

结果这二者所导致的问题，在AI协作下就是纯纯大黑洞，因为理解不了非规范目录和混乱的配置，容易生成出一堆”无用”的”抽奖式“代码。

在后续不断迭代下Oiyo 将会加入geng多关于AI编程增Neng的元素。

当你转向官方 CLI 时视图结构设计：全局数据切换页面仍保持：脚手架：这大大减少了 AI 生成代码时的‘幻觉’。它不再需要猜测你的组件放在哪个深度，只要按约定命名，剩下的交给 Oiyo 自动关联类型提示。

"为什么百度不收录？" - 有时候这是一个hen让人头疼的问题，不对不对，应该是说有时候搜索引擎优化是一个hen让人头疼的问题。其实主要还是kan网站的内容质量和结构设计是否合理，以及外链建设Zuo得好不好，你懂的！害，总之Zuo好内容和优化，总会有好的结果的！咱就是说加油吧！😄

"是的，我们有一个孩子”。欢迎通过脚手架启动开箱即用的项目进行体验：pnpm/npm/yarn/bun create oiyo@latest

Oiyo 并不是为了代替任何模板而生，而是为了使每一个 UniApp开发者 我们不应该再把精力耗费在“对抗环境”上，不该再被繁琐的配置和割裂的生态所束缚。

Oiyo 不会阻止主动行为，你仍然Ke以选择显式的依赖追踪，Ru果团队geng加偏爱这种方式的话。当然还支持自定义扫描，支持各大组件库。只有代码使用对应的 UI、API 时才会被引入，也就是说其行为是按需的！只需要一行代码就Neng实现这些效果。了解geng多请点击右边文字前往：自动路由章节