| name | smartui-page-development |
| description | 用 SmartUI 做 Ray 页面开发与组件选型。基于官方组件文档输出页面方案、示例代码和样式建议。 |
SmartUI 页面开发指南
适用场景
- 用户要求使用 SmartUI 新建、改造或补全一个页面
- 用户只给了页面需求,需要你从 SmartUI 组件中做选型
- 需要为页面补齐导航、布局、展示、录入、反馈类组件
- 需要基于 SmartUI 文档产出页面结构方案、TSX 示例或样式建议
开始前
- 先读取
llms.txt,把它当作 SmartUI 官方文档导航入口。
- 只把
llms.txt 和它指向的官方文档/Wiki 当作默认上下文来源。
- 如果用户已经点名组件,优先查对应文档;如果用户只描述页面需求,先完成组件选型再编码。
- 如果用户没有提供具体工程文件,默认输出可复用的页面方案、组件组合建议和 Ray 风格 TSX/Less 示例。
文档阅读顺序
SmartUI 组件文档通常按下面的结构组织,阅读时优先按这个顺序提取信息:
介绍:判断组件是否适合当前页面需求。
引入:确认组件名、依赖组件和基础用法。
代码演示:优先参考真实示例,确认推荐组合方式。
API:核对 Props、Events、Slots,避免误用属性。
样式变量:需要定制视觉时,优先使用 CSS 变量或主题能力。
常见问题:检查滚动、嵌套、交互限制等使用边界。
默认工作流
- 读取
llms.txt,定位本次任务涉及的组件文档、主题文档、FAQ 或最佳实践。
- 拆解页面需求,明确页面包含哪些区域:导航、内容区、表单区、反馈区、底部操作区。
- 优先使用 SmartUI 现有组件组合页面,不要先写自定义基础控件。
- 先看组件文档里的“代码演示”和“API”,再补读主题、样式定制和 FAQ。
- 完成实现后,检查主题、交互反馈、样式覆盖方式和组件组合是否符合文档约定。
- 如果任务落地依赖用户项目中的实际文件结构、状态管理、路由或接口数据,而用户没有提供这些上下文,先明确假设再给出示例代码。
组件选型原则
- 布局优先看:
Layout、Grid、Sticky、Tab、DropdownMenu
- 导航优先看:
NavBar、Tabbar、Sidebar、IndexBar
- 展示优先看:
Cell、Tag、Empty、NoticeBar、Divider、Image、Icon
- 数据录入优先看:
Field、Search、Checkbox、Radio、Switch、Slider、Stepper、Calendar
- 反馈优先看:
Toast、Dialog、Popup、BottomSheet、ActionSheet、Picker
如果需求可以通过多个 SmartUI 组件组合完成,优先组合现有组件;只有在 SmartUI 明确没有对应能力时,才补充少量自定义结构或样式。
页面实现约定
- SmartUI 默认按 Ray 风格、接近 React 写法的 TypeScript + less 组织示例;在用户未指定技术栈时,可按这个风格给出示例代码。
- 能通过 SmartUI 属性、插槽能力、主题能力完成的效果,优先不要用大量自定义样式硬改。
- 先用组件现有 Props、Events、Slots 解决需求,再考虑自定义结构或样式。
- 如果组件文档里有明确注意事项或使用限制,优先按文档限制实现。
- 涉及全局主题、统一样式、暗黑模式或品牌色时,优先查
llms.txt 里的 ConfigProvider、主题文档和相关 Wiki。
- 涉及组件样式定制时,先看
llms.txt 中的“如何去自定义修改SmartUI组件的样式”。
补充说明
- 如果用户提供了自己的文件、目录或代码片段,再基于用户显式提供的上下文进行实现或改写。
- 如果需要多语言方案,但用户未提供 i18n 体系,优先使用直写文案或占位符,并在回复中说明可接入用户自己的 i18n 方案。
输出要求
当你完成页面开发类任务时,最终回复中应尽量说明:
- 本次页面用了哪些 SmartUI 组件
- 你参考了哪些组件文档、主题文档或最佳实践
- 哪些需求是通过 SmartUI 直接实现的,哪些是必要的少量自定义补充
- 哪些地方基于文档做了合理假设,以及还缺哪些项目上下文
遇到信息不足时
- 先补读
llms.txt 中对应组件文档
- 优先查看组件文档里的“代码演示”“API”“常见问题”
- 再从
llms.txt 中继续查主题、FAQ、样式定制或相关组件文档
- 如果仍缺少落地信息,向用户补充询问目标页面结构、交互流程、视觉要求、数据来源或目标文件内容
- 如果仍然没有匹配组件,明确告诉用户 SmartUI 中暂无直接对应组件,并给出最接近的组合方案