核心理念与优势

Yoyo Admin 希望减少的是重复的管理端开发，而不是用另一套框架替代所有页面写法。对开发者而言，重要的是：找到已有能力、接上真实接口、正确处理保存和失败，再验证用户实际操作。

产品组成见产品介绍，可采用范围见能力总览。这里解释开发时的选择，不承诺未经测量的效率比例。

成熟界面起步，业务驱动提取

先采用成熟模板的布局与控件组合，再接自己的业务。新宿主直接使用 Nuxt UI 公开组件和默认视觉，不为 Button、Input、Select 再维护一组同义包装，也不预设必须打通第二套 UI 库。

有价值的 Yoyo 能力来自真实管理任务，例如同一记录编辑、失败保留输入和保存后回读。公共包是实际复用的结果；暂时只有一个消费者时，逻辑可以留在 feature 内。

普通页面与配置化工作台都可以使用

开发方式	适合的事情	开发者维护什么
直接组合 Nuxt UI	普通列表、设置、独特业务页面、先验证真实需求	Vue 呈现、业务 service、必要的局部查询和编辑状态
采用已有 Schema / Data Workbench	重复性强、适合声明字段、查询和动作的标准管理页	页面定义、业务绑定及确实需要的扩展

直接组合不要求先学习完整 IR、registry 和页面宿主。它也不是“零维护”：查询、错误恢复、编辑生命周期要有明确实现，不能每页复制一套认证和通用状态机。

Schema 路径提供编译与诊断，但不决定全部页面布局，也不替代业务设计。已有标准 CRUD 更省事时继续使用，不为采用新 UI 而删除有效能力。细节见 Authoring，其中的宿主与 recipe 限制须按实际版本核对。

后端合同贯穿到页面

后端的 DTO、操作、输入要求和能力目录进入生成边缘；前端使用相应类型、请求与校验。页面只补自己的展示和操作意图，不维护平行的 DTO、API URL 或权限清单。

这让修改有明确顺序：合同变化先改后端，再刷新生成客户端，最后调整受影响页面。只调整布局、文案或组件组合时，不需要重新生成 API。

当前接线可从计量单位教程开始，生成机制参阅 OpenAPI 与 Orval 契约链。

界面能提示，后端必须保证

前端根据实际授权结果显示菜单和操作，但最终授权与数据范围由后端保证。缺权限时说明缺什么、请谁处理；不猜测替代权限，不为演示自动补授权。

租户范围、用户已明确操作后的事务一致性和适用的并发保护不能依赖用户自行注意。另一方面，管理员能通过页面解决的配置，不为了“框架完整”再造自动迁移和修复流程。

保存成功与页面更新成功分开处理

一次编辑至少包含输入、提交、读取实际结果和更新列表。字段错误应定位到输入项；写入失败保留草稿；写入成功但回读失败时，重试只读取，不能重复执行写操作。

这些行为比“弹窗使用哪个名字”更重要。已有正确实现先复用，界面容器可以变化；具体实现是否值得变成公共任务，需要实际使用证据。

AI 与开发者使用同一套接口

Agent 可以帮助查找合同、修改页面、解释错误和执行验证，但不替后端做授权决定，不把生成了文件当成业务已交付。使用 CLI 时先查它实际支持的 recipe；当前没有的创建方式不伪装成 CLI 已支持。

质量检查按改动范围选择。文档构建、代码测试、真实业务验证、用户体验批准与正式发布各有边界，不把一种结果代替全部结果。

接受渐进采用的成本

旧宿主是有效业务的迁移来源，不是失败项目整体丢弃。新页面接通后再处理旧消费者；主题、布局和示例不要求在模板与实际应用之间永久自动同步。

采用团队仍需维护自己的业务规则、环境与升级验证。Yoyo Admin 不以包数量、组件数量或任务百分比证明生产力；应看开发者完成实际业务要修改什么、用户能否安全地完成操作。