实践经验
用 AI 编写 SinleUI 页面时，除了说明需求，还需要提供框架资料和项目约定。下面整理了一些任务安排和检查方法，供开发时参考。
一、先提供能力清单
AI 不了解框架组件时，可能会用原生 view 重复实现已有组件，也可能误用不存在的 sn-xxx，导致返工。
开始任务前，可以先安装 Skill，让 AI 读取能力清单；也可以让它直接读取 uni_modules/sinle-ui/ai-reference.md。有了清单，AI 能根据需求选择组件，不必在指令中逐个点名。比如需要徽标时，可以选用 sn-badge；需要骨架屏时，可以选用 sn-skeleton。
先查再写
可以按「先查索引 → 理解需求 → 阅读文档 → 编写代码」的顺序推进。先确认组件选择，再开始写代码，可以减少在已有结构上反复打补丁的情况。
索引与手册的分工
索引用于查找框架是否提供某项能力、对应文档在哪里，手册说明具体用法。先看索引，再按需阅读文档页，可以减少上下文占用，也方便查阅文档站上的最新用法。
二、把约定写成可检查的规则
约定要具体到 AI 可以在交付前逐项检查。例如，「注意代码质量」很难直接核对，而「页面根节点必须是 sn-page」可以逐文件检查。
下面几种写法比较容易检查：
| 写法 | 示例 | 检查依据 |
|---|---|---|
| 明确规则 | 页面根节点必须是 sn-page | 可逐文件确认根节点 |
| 给出反例 | 不要用 uni.showToast，用 snu.showToast | 明确要避免的调用及替代方法 |
| 给出写法 | 尺寸写 $14，不要写裸数字 | 可直接对照代码核对 |
| 限定修改范围 | 不要改 uni_modules/ | 明确依赖目录不在修改范围内 |
常用约束可以控制在一屏左右，便于一次读完。长篇规范中的细节按任务需要另行查阅，避免重点被大量说明淹没。
三、允许 AI 说明不确定之处
AI 不确定某项能力时，有时会补出一个看似合理的用法。可以在任务中写明：
不确定某个能力是否存在时，先查能力清单与文档站；查不到就说明「框架未提供该能力」，不要编造，也不要在未说明的情况下换成不可用的实现。
允许 AI 明确说明能力缺失，有助于及早发现问题，避免继续沿着错误方案开发。
四、留意尺寸和颜色的写法
样式代码有时语法正确，却不符合框架的写法。常见问题包括：
- 将
$14写成14，尺寸就不会随乘数缩放，用户调整字号时也不会跟着变化； - 将颜色写死为
#4d82ff，切换暗色主题后仍保持原色； - 在脚本中拼接样式，却没有放进
computed，乘数变化时界面不会刷新； - 用
calc(var(--af) * 200ms)，--af是纯数值乘数，放进calc()算时间不成立。
这类问题不容易仅靠阅读代码发现。把对应规则写进约束文件，并在交付前逐项检查，有助于减少遗漏。
五、按步骤完成任务
同时要求 AI 搭页面、接接口、加动画和适配暗色主题时，容易出现细节遗漏。可以把任务拆成几轮：
- 结构：先确定
sn-page、布局和组件选择，暂不处理样式细节； - 数据：接入真实数据，补齐空态 / 加载态 / 错误态；
- 样式：使用
$与calc(var(--xx) * Npx)，统一尺寸与颜色的写法； - 交互：补充加载、禁用、点击态和动效。
每轮完成后分别检查，发现问题时也更容易定位。
六、交付时逐项检查
生成完成后，让 AI 对照清单说明检查结果，便于确认哪些内容已完成、哪些还需要验证。可以使用以下清单：
- [ ] 根节点是
sn-page，弹层都在内部； - [ ] 没有大量写死的
px与十六进制颜色； - [ ] 提示使用
snu.showToast，没有uni.showToast； - [ ] 组件的
ref调用发生在渲染之后； - [ ] 列表页有加载中 / 空态 / 正常三种状态；
- [ ] 明确列出需要人工确认的交互点。
七、描述问题时给出操作和现象
AI 可以根据代码和编译产物分析问题，但不一定能看到实际运行画面。抽屉滑动是否顺畅、交互是否符合预期，仍需要你在运行时确认。
反馈问题时，说明页面位置、操作步骤和实际表现，再附上相关代码，会比只说「不生效」更容易定位。仅说「样式错了」，往往不足以判断原因。