Svelte前端开发最佳实践Skill:让 AI 写出的 Svelte 5 代码符合团队规范
- 一句话定位:这是一个把 Svelte 5 工程规范「写进 AI 脑子里」的技能,覆盖 TanStack Query 突变、shadcn-svelte 组件组织、属性类型内联、自包含组件等最佳实践。
- 解决的核心问题:AI 生成的 Svelte 代码往往能跑但不规范——父级状态到处污染、无意义的
handle*包装函数、独立的Props类型声明满天飞,团队 Review 成本极高。 - 能力范围:突变模式(
createMutation/.execute())、shadcn-svelte 组件与导入规范、Lucide 图标写法、cn()样式组合、属性类型内联、自包含组件组合模式。 - 适用人群:使用 Svelte 5 + TypeScript + TanStack Query + shadcn-svelte 技术栈的前端开发者、技术负责人与团队 Code Review 人员。
- 上手成本:低。安装完成后无需改变原有工作流,继续在熟悉的 AI 编码环境里提需求即可,技能会在后台约束输出风格。
该技能叫什么?如何下载安装 AI 技能提升开发效率?
技能基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | Svelte前端开发最佳实践Skill |
| 技能英文名 | svelte |
| 技能 ID | 11860 |
| 技能类型 | 前端开发规范 / 代码生成约束类技能 |
| 适配技术栈 | Svelte 5、TypeScript、TanStack Query、shadcn-svelte、Tailwind CSS |
它到底解决什么问题?
Svelte 5 引入了 Runes($state、$derived、$props),写法与 Svelte 4 差异明显;同时 TanStack Query 的突变模式、shadcn-svelte 的目录约定、Lucide 图标的按需导入方式,都有一套「社区公认但文档分散」的最佳实践。通用 AI 助手在没有约束的情况下,很容易写出以下「能跑但被吐槽」的代码:
- 在
.svelte里手动维护isLoading、error一堆布尔量,而不是用createMutation的isPending/isError/isSuccess; - 在父组件里维护
deletingItem之类的共享状态,用一个「中央弹窗」处理所有行的删除; - 为每个按钮写一个
handleShare()包装函数,逻辑与 UI 相隔十几行; - 为每个组件单独声明
type Props = {...},甚至给children加类型注释; - 从
lucide-svelte一次性导入多个图标,导致打包体积失控。
这个技能的作用,就是把这些「团队里反复强调的规范」固化成技能上下文,让 AI 生成的代码一次成型。
一键安装的思路与步骤
AI 技能的安装通常遵循「获取技能 → 挂载到 AI 客户端 → 验证生效」三步。由于本技能详情中未附带具体的下载链接与安装命令,以下为通用流程,实际操作请以官方说明为准:
- 确认安装前提:拥有可挂载技能(Skill)的 AI 编码客户端或助手,且已在本地建立 Svelte 5 项目(含
src/lib/components/ui/结构更佳)。 - 获取技能:在技能市场中按技能 ID
11860或英文名svelte检索并安装;或通过官方提供的安装入口 / 命令拉取技能包,具体命令以官方说明为准。 - 挂载与启用:在客户端的技能列表中启用该技能,使其在对话或编码会话中默认加载(部分客户端支持按项目启用)。
- 验证是否生效:在会话中输入类似「帮我写一个删除会话的按钮组件」的需求,观察输出是否同时满足——
- 使用
createMutation而非手写 loading 状态; onSuccess/onError作为.mutate()的第二个参数传入;- 没有出现
handleXxx包装函数; - 属性类型直接内联在
$props()中。 若以上多条同时命中,说明技能已正常生效。
- 使用
- 反馈与迭代:若发现生成结果仍有偏差,可在提示中显式引用技能条款(如「按技能的突变模式偏好来写」),帮助模型锁定上下文。
该技能的主要功能和特点
- 突变模式强约束:在
.svelte文件中优先使用 TanStack Query 的createMutation,直接获得isPending、isError、isSuccess三态,无需手写加载与错误状态机,用户体验与代码整洁度双赢。 - 回调就近原则:要求把
onSuccess与onError作为.mutate()的第二个参数传入,让成功/错误处理与触发操作「贴在一起」,能直接访问局部状态(如关闭弹窗isDialogOpen = false)和路由跳转上下文。 .ts文件的正确姿势:明确.ts环境(加载函数、工具函数)必须使用.execute(),因为createMutation依赖组件上下文;同时给出仅有的三种例外场景——不需要加载状态、一次性操作、需要细粒度异步控制。- 禁止
handle*包装函数:如果函数只用一次且逻辑不深,一律内联进模板,让逻辑和触发它的 UI 元素处在同一处,减少「跳读成本」。技能还贴心地把() => (deletingItem = item)这类写法与反面案例并列展示。 - shadcn-svelte 工程化规范:规定使用 CLI
bunx shadcn-svelte@latest add [组件]添加组件;每个组件独立文件夹放在$lib/components/ui/下并带index.ts导出;文件夹名用 kebab-case。 - 导入模式明确分工:多部件组件用命名空间导入(
import * as Dialog from ...),单组件用命名导入(import { Button } from ...),两类场景不混用。 - Lucide 图标按需单导入:统一从
@lucide/svelte/icons/*逐个导入,路径用 kebab-case,导入名可自由命名(通常 PascalCase,可带 Icon 后缀),避免整包导入。 - 样式与定制约定:始终用
$lib/utils的cn()组合 Tailwind 类;直接改组件源码而不是用复杂 CSS 覆盖;用tailwind-variants管理变体;遵循background/foreground颜色约定与 CSS 变量做主题。 - 属性模式简化:属性类型内联写在
$props()中,禁止单独声明type Props;children在 Svelte 中隐式类型,永不加类型注释。 - 自包含组件模式:以「每行一个删除按钮、每行一个对话框」替代「父级维护共享状态 + 单个中央弹窗」,消除父级状态污染、无需回调、扩展性更好。
和普通工具相比强在哪?普通的 Lint 工具只能事后检查语法风格,无法阻止「架构层面不优雅但语法正确」的写法;通用 AI 助手需要每次长提示词重申规范。这个技能把规范前置到生成环节,属于「预防式」而非「纠正式」。
如何使用该技能?
第一步:启用技能并确认技术栈上下文
在 AI 客户端中启用本技能后,建议在项目根目录准备好 Svelte 5 + TypeScript 环境,并确保提示中说明使用的是 Svelte 5(Runes 语法)。若使用 shadcn-svelte,组件应已位于 $lib/components/ui/。
第二步:用自然语言描述组件需求
无需背诵规范,直接描述业务即可。例如:
「在会话列表里,每一行需要一个删除按钮,点击弹出确认框,确认后调用
rpc.sessions.deleteSession,成功后 toast 提示并跳回/sessions。」
第三步:检查生成代码是否符合技能条款
技能生效后,典型输出会长这样(节选自技能示例的写法):
<script lang="ts">
import { createMutation } from '@tanstack/svelte-query';
import * as rpc from '$lib/query';
const deleteSession = createMutation(
() => rpc.sessions.deleteSession.options,
);
let isDialogOpen = $state(false);
</script>
<Button
onclick={() => {
deleteSession.mutate(
{ sessionId },
{
onSuccess: () => {
isDialogOpen = false;
toast.success('会话已删除');
goto('/sessions');
},
onError: (error) => {
toast.error(error.title, { description: error.description });
},
},
);
}}
disabled={deleteSession.isPending}
>
{#if deleteSession.isPending}
删除中...
{:else}
删除
{/if}
</Button>
输入:一句业务描述 + 数据接口名。
输出:一个自带三态处理、错误提示、跳转逻辑与内联事件处理的组件片段,无需再补 isLoading 变量,也无需额外写 handleDelete 函数。
第四步:在纯 TS 场景切换 .execute()
当需求落在加载函数或 +page.ts、工具模块里时,直接说明「这是 .ts 文件里的逻辑」,AI 会切换为:
const result = await rpc.sessions.createSession.execute({
body: { title: '新会话' },
});
const { data, error } = result;
第五步:让 AI 组织 shadcn-svelte 组件
需要新组件时,提示「用 shadcn-svelte 加一个 dialog」,AI 会优先给出 bunx shadcn-svelte@latest add dialog,并按命名空间导入方式组织代码:
<Dialog.Root bind:open={isOpen}>
<Dialog.Trigger>
<Button>打开</Button>
</Dialog.Trigger>
<Dialog.Content>
<Dialog.Header>
<Dialog.Title>标题</Dialog.Title>
</Dialog.Header>
</Dialog.Content>
</Dialog.Root>
第六步:Code Review 阶段复用技能
把生成的代码丢回会话,附上「按本技能规范检查」,可快速定位 type Props、handle* 函数、lucide-svelte 整包导入等违规点。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| Svelte前端开发最佳实践Skill(本技能) | AI 生成阶段的 Svelte 5 规范约束器 | 突变模式、shadcn-svelte 组织、属性内联、自包含组件、图标导入规范 | 低:挂载技能即可,具体命令以官方说明为准 | 用 AI 写 Svelte 5 业务代码、团队统一 AI 产出的风格 | 优势:规范前置,一次生成即合规;不足:仅覆盖技能文档列出的规范范围,不含完整 Lint 规则 |
| 通用 AI 编码助手(不挂技能) | 通用代码生成 | 可写任意语言与框架 | 极低:开箱即用 | 一次性脚本、原型验证 | 优势:无需配置;不足:需在提示词里反复重申 Svelte 5 规范,产出风格不稳定 |
| Svelte 官方文档 / 教程 | 学习与查阅 | 语法、Runes、编译器等权威说明 | 低:直接浏览 | 学习新语法、查 API | 优势:权威、全面;不足:不参与代码生成,无法自动落到项目里,团队约定需自行补充 |
| ESLint + Prettier + svelte-check | 事后静态检查 | 语法风格、类型检查、格式化 | 中:需配置规则与 CI | 提交前拦截、CI 卡口 | 优势:机器可验证;不足:难约束架构性写法(如父级状态污染),发现问题时已写完代码 |
| shadcn-svelte CLI | 组件分发工具 | 添加组件源码到项目 | 低:一条命令 | 引入 UI 组件 | 优势:组件即源码、可自由改;不足:只负责「装组件」,不约束写法与组合模式 |
该技能的典型应用场景与实际体验情况
场景一:管理后台的表格行操作
角色:全栈开发者小李。痛点:一个用户列表里每行都有「删除」「编辑」按钮,此前 AI 生成的版本把 deletingUser、editingUser 全部提升到父组件,父组件越写越长。
使用方式:要求「每行拆成自包含组件」。技能给出的方案是 DeleteItemButton.svelte 内部自带 open 状态与 createMutation,父组件只需 {#each items as item}<DeleteItemButton {item} />{/each}。
实际体验:上手零成本,生成的组件可独立复用;注意点是每行都会实例化一个对话框实例,团队需接受「多实例而非单例」的心智模型——技能本身也说明了现代框架能高效处理。
场景二:表单提交与错误提示统一化
角色:前端负责人。痛点:不同成员写的提交逻辑五花八门,有的用 try/catch 手动置 loading,有的用 isSubmitting 变量,错误提示文案位置各不相同。
使用方式:让 AI 生成统一的 createMutation 模板,并把 onError: (error) => toast.error(error.title, { description: error.description }) 作为标准写法固化。
实际体验:三态(isPending / isError / isSuccess)自动可用,按钮禁用与「删除中…」文案几乎零手写;需要注意 .options 要包在访问器函数里、不要在 .options 上直接加括号,这类细节技能已明确写出,减少踩坑。
场景三:UI 组件库接入与图标治理
角色:设计系统维护者。痛点:打包体积被 lucide-svelte 整包导入撑大,$lib/components/ui/ 目录命名混乱。
使用方式:让 AI 按技能规范新增组件并改造导入。图标统一为 import Database from '@lucide/svelte/icons/database',组件目录统一 kebab-case 且带 index.ts。
实际体验:改动机械但收益直接,构建体积与可读性同步改善;注意路径需 kebab-case(如 more-vertical),导入名可自定义但建议 PascalCase。
场景四:服务端/加载函数里的数据请求
角色:负责 +page.ts 与工具模块的开发者。痛点:在 .ts 文件里照搬组件内的 createMutation,运行报上下文错误。
使用方式:说明当前文件类型,技能自动切换为 .execute() 并给出 { data, error } 解构范式。
实际体验:这是最容易踩的坑,技能把「何时用 .execute()」的三条例外写得非常具体,排查效率明显提升。
该技能能为用户带来的价值
- 效率提升:省去「生成 → Review → 打回 → 重写」的往返。以突变逻辑为例,手写 loading / error / success 三态加事件包装函数,通常需要多轮补丁;技能约束下基本一次成型,组件级任务的沟通轮次可从 3~5 轮压缩到 1~2 轮。
- 门槛降低:刚接触 Svelte 5 Runes 与 TanStack Query 的开发者,不必先通读全部文档,就能产出符合社区共识的代码;团队新人接入项目的「风格磨合期」显著缩短。
- 一致性收益:把散落在 Code Review 评论、内部文档、口口相传中的规范,收敛成一份可执行的技能条款,减少「同一个问题被指出十次」的重复沟通成本。
- 可维护性长期价值:自包含组件、内联属性类型、禁止
handle*包装这几条,本质是在降低单文件复杂度与跳读成本;随着页面数量增长,收益会持续放大,重构时也更敢动刀。 - 可迁移性:技能条款以「模式 + 正反例」的方式组织,即使将来换框架,这种「把团队规范固化给 AI」的工作方式依然可复用。
常见问题 FAQ
Q1:这个技能怎么安装?需要付费吗?
A:在支持技能(Skill)的 AI 客户端或助手市场中按技能 ID 11860 或英文名 svelte 检索安装,按提示启用即可。由于本技能详情未提供具体下载链接、安装命令与定价信息,安装步骤与收费情况请以官方说明为准。
Q2:它和 ESLint、svelte-check 冲突吗?需要二选一吗?
A:不冲突,二者互补。ESLint / svelte-check 属于事后的静态检查,能发现语法与类型问题;本技能作用在 AI 生成阶段,约束的是「语法正确但架构不优雅」的写法,例如父级状态污染、无意义的 handle* 包装函数、单独的 type Props 声明。推荐两者同时使用——技能负责少写错,检查工具负责兜底。
Q3:适合谁用?只用 Svelte 4 的团队能用吗?
A:主要面向使用 Svelte 5 + TypeScript + TanStack Query + shadcn-svelte 的前端团队与个人开发者,对追求 AI 产出风格统一的技术负责人尤其有价值。技能条款大量基于 Runes($state、$props)与 @tanstack/svelte-query,纯 Svelte 4 项目参考价值有限。
Q4:为什么技能要求 .ts 文件必须用 .execute()?我在 .svelte 里也想用怎么办?
A:因为 createMutation 依赖组件上下文,在 .ts(如加载函数、工具模块)中不可用,所以统一走 .execute() 并解构 { data, error }。在 .svelte 文件中确实可以用 .execute(),但仅限三种情况:不需要加载状态、执行一次性操作、需要细粒度控制异步流程。其余场景仍建议 createMutation。
Q5:自包含组件模式会不会导致对话框实例太多、影响性能?
A:技能明确说明:为每行实例化一个对话框、而不是维护一个带复杂状态的共享对话框,是完全可行的,现代框架能有效处理,换来的代码清晰度值得。真正需要评估的是超长列表(数千行同时渲染)的极端场景,此时可结合虚拟滚动或按需挂载,这属于业务层优化,不改变模式选择。