providing-feedback（用户反馈与通知系统）Skill 是什么？如何下载安装使用？

用户反馈与通知系统Skill：让每一次「保存成功」和「出错了」都被用户准确感知

核心结论速览：

这是一个专为「把系统状态讲给用户听」而生的 AI 技能，覆盖 Toast 通知、警报横幅、模态对话框、进度指示器、空状态、工具提示等全部常见反馈形态。
它最有价值的部分不是代码，而是一套反馈类型决策矩阵：按「紧急性 + 是否阻塞」帮你判断该用模态、横幅、Toast 还是内联提示，避免"小事弹模态、大事没提示"。
技能内置了可量化的时机标准，例如成功提示 3-4 秒、错误提示 7-10 秒、加载超过 100 毫秒才需要指示器，让"弹多久"不再靠拍脑袋。
它默认把可访问性纳入交付标准，包含 aria-live、焦点捕获与恢复、ESC 关闭等 ARIA 模式，减少上线后的无障碍返工。
它按需推荐并给出 Sonner、Radix UI 等库的实现代码，同时提供示例文件与消息模板资产，属于"拿来即用"型技能。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

技能基本信息

项目	内容
技能中文名	用户反馈与通知系统Skill
技能英文名	providing-feedback
技能ID	13395
技能类型	前端交互体验 / 组件实现类技能

它解决什么问题？

在真实项目里，用户"不知道发生了什么"是最常见的体验事故来源：表单提交后没反应、上传卡住不知道是死是活、删除操作没有二次确认、搜索没结果却显示一片空白、报错信息埋在控制台里用户根本看不到。这类问题并不难写代码，难的是每次都要重新做一遍判断：这个场景该用 Toast 还是对话框？提示该停留几秒？要不要自动关闭？无障碍怎么标注？

providing-feedback 技能就是把这套判断沉淀成了可复用的规则和实现范式，让你在向 AI 助手描述需求时，直接得到「该用什么组件 + 为什么 + 怎么写 + 怎么测」的完整答案。

一键安装 AI 技能提升开发效率的思路

AI 技能的核心价值在于"一次安装、长期复用"：装上之后，助手遇到相关需求会自动按这套规范工作，无需你每次重复交代背景。

确认安装前提：需要一个支持 AI 技能（Skill）调用的开发环境，例如具备技能/插件体系的 AI 编程助手、IDE 助手或命令行助手；同时你的项目应是前端项目（技能示例以 React 18+ 为主，涉及组件库依赖）。
找到技能入口：在所用工具的技能市场、技能库或技能管理面板中，用英文名 providing-feedback 搜索，或通过技能ID 13395 精确定位。不同客户端的具体入口与命令以官方说明为准。
执行安装/启用：按客户端提示完成添加并在当前会话或项目中启用该技能。若客户端支持命令行安装，具体命令以官方说明为准，请勿自行拼凑。
验证是否生效：安装后向助手提出一个具体需求，例如「请用 providing-feedback 技能，给我的 React 表单加一个保存成功的提示和一个删除前的确认框」。如果回复中出现了反馈类型决策矩阵、Sonner 或 Radix UI 的具体代码、自动关闭时长建议，说明技能已正常加载。
长期可用：技能一旦启用，后续涉及通知、确认、加载、空状态的开发任务都会自动对齐同一套规范。

该技能的主要功能和特点

反馈类型决策矩阵：把"该用哪个组件"变成可执行的判断规则。 技能给出明确映射：关键且阻塞 → 模态对话框；重要但非阻塞 → 警报横幅；成功/信息且临时 → Toast/Snackbar；上下文帮助 → 工具提示；进行中 → 进度指示器；无数据 → 空状态。
按紧急程度的快速参考表。 直接列出每种组件的持续时间与是否阻塞交互，例如模态"直到操作完成"、Toast"3-7 秒"、内联消息"持久显示"，让设计评审有据可依。
Toast 落地参数齐全。 位置推荐右下角，时长分档（成功 3-4 秒、警告 5-7 秒、错误 7-10 秒），堆叠上限建议 3-5 个。
模态对话框的焦点管理规范。 打开前保存焦点、打开后聚焦首个可交互元素、Tab 循环锁定在模态内、关闭后焦点回到触发按钮，避免键盘用户"焦点丢失"。
进度指示器的分级阈值。 小于 100 毫秒不显示指示器；100 毫秒至 5 秒用 Spinner 加说明文案；5 至 30 秒用可确定的进度条；超过 30 秒则进度条 + 预计时间 + 取消按钮。
空状态的完整构成。 明确要求包含插图、标题、正文、行动按钮，并区分首次使用、零结果、错误、权限被拒四种类型。
可访问性（ARIA）模式内置。 提供 role="status" aria-live="polite" 与 role="alert" aria-live="assertive" 两种公告写法，区分非关键通知与关键警报。
设计令牌化。 所有反馈组件通过令牌统一主题化，覆盖颜色、间距、排版、阴影、动效五类令牌，便于接入设计系统。
配套脚本与资产。 提供生成 Toast 配置、格式化用户消息、计算自动关闭时机的脚本，以及消息模板、错误码映射、时机配置等 JSON 资产。
跨技能协同。 明确说明它如何增强表单、数据可视化、表格、AI 聊天、仪表板、搜索、媒体上传等其他组件技能——凡是"需要告诉用户状态"的地方，它都能接管。

和普通做法比强在哪？ 普通做法是"打开组件库文档 → 找一个 API → 凭感觉设个时长 → 上线后发现无障碍不过关"。这个技能给的是决策链 + 参数标准 + 可访问性 + 令牌接入的完整闭环，产出一致性显著更高。

如何使用该技能？

步骤 1：描述场景，让技能确定反馈类型

输入示例：

“用户在一个商品编辑表单里点了保存，请求大约 2 秒，成功和失败都要有提示。另外删除商品需要二次确认。请按 providing-feedback 规范给出方案。”

输出说明：技能会先按紧急性、持续时间、是否需要用户操作、是否与特定元素相关这四个维度评估，然后给出结论——保存结果用 Toast（非阻塞），删除操作用模态对话框（关键且阻塞）。

步骤 2：确定实现模式参数

按技能给出的标准落地：Toast 放右下角，成功 3-4 秒自动关闭，失败 7-10 秒或手动关闭；模态最大堆叠遵守 3-5 个上限。

步骤 3：安装依赖库

技能推荐的现代 React 技术栈：

npm install sonner @radix-ui/react-dialog

步骤 4：接入 Toast 与 Promise 状态

import { Toaster, toast } from 'sonner';

// 应用根节点
<Toaster position="bottom-right" />

// 保存操作
toast.promise(saveData(), {
  loading: '保存中...',
  success: '已保存！',
  error: '保存失败'
});

步骤 5：实现模态确认与焦点管理

import * as Dialog from '@radix-ui/react-dialog';

<Dialog.Root>
  <Dialog.Trigger>删除</Dialog.Trigger>
  <Dialog.Portal>
    <Dialog.Overlay />
    <Dialog.Content>
      <Dialog.Title>确认删除</Dialog.Title>
      <Dialog.Description>删除后不可恢复，确定吗？</Dialog.Description>
      <Dialog.Close>取消</Dialog.Close>
    </Dialog.Content>
  </Dialog.Portal>
</Dialog.Root>

步骤 6：补上可访问性公告

<!-- 非关键通知 -->
<div role="status" aria-live="polite">文件上传成功</div>

<!-- 关键警报 -->
<div role="alert" aria-live="assertive">错误：保存失败</div>

步骤 7：接入设计令牌

.toast {
  background: var(--toast-bg);
  color: var(--toast-text);
  padding: var(--toast-padding);
  border-radius: var(--toast-border-radius);
  box-shadow: var(--toast-shadow);
  animation-duration: var(--toast-enter-duration);
}

步骤 8：按清单自测

用键盘走一遍 Tab 顺序、开启屏幕阅读器听一遍公告、打开系统的"减少动效"设置看动画是否降级、确认同类操作反馈类型是否一致。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
providing-feedback 技能	AI 辅助的反馈体系设计 + 实现规范	决策矩阵、时机标准、ARIA 模式、令牌接入、多库代码示例	需在支持 Skill 的 AI 助手中启用；无需额外运行时依赖	从零搭建反馈体系、统一团队规范、可访问性整改	优势是给出"为什么这么选"的判断逻辑与跨组件协同；不足是最终代码仍需按项目技术栈调整
Sonner	专注 Toast 的 React 组件库	通知弹出、Promise 状态、堆叠管理	需自行安装与调用，需自己决定时机与位置	快速接入 Toast	优势是体积小、可访问性好；不足是只管 Toast，不解决模态与空状态
react-hot-toast	轻量 Toast 库	基础通知弹出	包体积小于 5KB，接入简单	包体积敏感的轻量项目	优势是极小；不足是功能相对单一，复杂反馈需另配方案
Radix UI / Headless UI	无头组件库	模态对话框、焦点管理、ARIA 支持	需自行组装样式与交互	设计系统、Tailwind 项目	优势是无样式、可定制；不足是学习成本高，缺少"何时该用"的决策层指导

选择建议：如果你缺的是"判断标准与整体规范"，用技能；如果你只缺一个 Toast 组件，直接装库更快；如果既要规范又要落地，用技能驱动库的组合效率最高。

该技能的典型应用场景与实际体验情况

场景一：后台管理系统的表单保存与删除

角色是业务前端开发，痛点是"提交成功没提示、删除没确认"反复被测试打回。使用方式：向助手描述表单与删除流程，技能输出 Toast + 模态 + 错误文案的组合方案。实际体验：决策矩阵省掉了争论，"成功 3-4 秒、错误 7-10 秒"这类明确数值让评审一次通过。注意点是不要为了"显得重视"把所有提示都做成模态。

场景二：文件上传与长耗时处理

角色是媒体/文档类产品开发，痛点是用户不知道上传是否在进行。使用方式：按技能的阈值分级——请求 100 毫秒内不加指示器，1 至 5 秒用 Spinner 加文案，超过 30 秒换成进度条 + 预计时间 + 取消按钮。实际体验：分级标准避免了"页面到处转圈"的焦虑感，也避免了短请求闪一下 Spinner 的闪烁问题。

场景三：搜索与筛选的零结果页

角色是数据产品前端，痛点是搜不到内容时页面一片空白，用户以为系统坏了。使用方式：用技能的空状态规范，区分"首次使用"和"零结果"，输出插图 + 标题 + 说明 + 引导操作。实际体验：空状态从"顺手做一下"变成有明确构成要素的交付物，用户能立刻知道下一步做什么。

场景四：AI 聊天与流式响应的状态沟通

角色是 AI 应用前端，痛点是流式输出期间、限流时、超时后缺乏清晰反馈。使用方式：借助技能的跨技能集成建议，用内联指示器表达"进行中"，用警报横幅表达速率限制警告。实际体验：这类"半成功半失败"的模糊状态最容易被忽略，技能的分类方式能帮你把状态拆清楚。

整体上手评价：上手难度低，因为技能不要求你先读完文档，而是直接给结论和代码；效果上限取决于你描述场景的清晰度，把"用户在什么位置、做了什么、期待什么"说清楚，产出质量会明显更高。

该技能能为用户带来的价值

对开发者：减少重复决策，缩短实现路径。 过去做一套完整反馈要查多个库文档、自己拍时长、后期补无障碍，现在从选型到代码到自测清单一次成型，单个功能的实现与联调时间通常能从数小时压缩到几十分钟量级。

对团队：把体验规范从"口头约定"变成"可交付物"。 反馈类型与时机有了统一标准，不同成员写的提示不会出现"这里 2 秒那里 8 秒""这里弹窗那里发 Toast"的割裂感。

对产品：降低用户困惑，减少无效客服与重试。 明确告知"发生了什么、该怎么办"，配合撤销、重试、取消等恢复路径，能显著减少用户因不确定而产生的重复提交。

对合规与长期维护：无障碍从成本项变成默认项。 aria-live 策略、焦点捕获与恢复、遵守减少动效设置，都写进了标准流程，减少上线后的整改风险。

对设计系统：视觉一致性可被复用。 反馈组件全部走设计令牌，主题切换、品牌改版时无需逐个组件返工。

常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？

在支持 AI 技能调用的助手中，用英文名 providing-feedback 或技能ID 13395 搜索，按客户端提示安装启用即可。是否需要付费、有哪些套餐、是否支持团队授权，取决于你所使用的平台，请以官方说明为准。技能本身不引入额外的运行时服务。

Q2：我不写 React，用 Vue 或原生 JS 能用吗？

能用。技能的核心资产是反馈类型决策矩阵、时长阈值、可访问性模式、空状态构成这些跨框架的方法论，与框架无关；只有示例代码和推荐库偏向 React 生态。你需要把"Sonner / Radix UI 的写法"替换成自己技术栈的等价实现，判断标准可以完整沿用。

Q3：它会把所有提示都做成弹窗吗？

不会，恰恰相反。技能的第一条关键原则就是"匹配紧急性到注意力"——不要为不关键信息使用模态。它的默认倾向是：能用 Toast 就不用横幅，能用横幅就不用模态，只有关键且必须阻塞用户操作的场景才使用对话框。

Q4：提示应该显示几秒？有没有统一答案？

技能给出的是分档标准而非单一数值：成功 3-4 秒、信息 4-5 秒、警告 5-7 秒、错误 7-10 秒或手动关闭，带操作按钮的建议 10 秒以上或不自动关闭。实际项目可根据文案长度微调，但不建议偏离量级。

Q5：和直接装一个 Toast 库相比，我该怎么选？

如果你已经清楚每个位置该用什么组件、时长和 ARIA 都有人负责，直接装库最省事；如果你正在从零搭建、需要统一多人规范、或可访问性整改压力较大，先用这个技能把"判断标准"定下来，再装库落地，整体返工最少。两者是互补关系，不是替代关系。