技能使用指南

generate-component-story（组件故事生成）Skill 是什么？如何下载使用？

组件故事生成技能能参照仓库既有 story 写法，用 section! 分段自动生成覆盖基本用法、变体状态、交互示例与边界错误情况的组件故事示例，帮组件库开发者省去逐行手写的重复劳动，让示例风格统一、覆盖完整、便于评审与回归。了解它的安装前提、使用步骤、竞品差异与典型场景，快速提升组件开发效率。

组件故事生成技能Skillgenerate-component-story
8 个章节 约 13 分钟阅读 AI 智能生成

组件故事生成技能：让每个组件都自动拥有完整、可运行、可评审的故事示例

核心结论速览

  • 它是什么：generate-component-story（组件故事生成技能）是一款面向组件库开发的 AI 技能，专门用于按仓库既有风格生成组件故事（story）示例。
  • 它解决什么问题：组件故事需要覆盖所有变体、状态与边界情况，手写费时且容易漏；该技能把“逐个手写”变成“按规则一次生成、再人工校验”。
  • 它的三条固定规则：遵循 crates/story/src/stories 中已有故事文件的写法、使用 section! 组织每个主要部分、全面覆盖组件的选项、变体与用法。
  • 怎么用：安装后在对话中直接说明“为某个组件生成故事”，并给出组件源码路径与需要覆盖的变体即可，输出结构包含基本用法、变体状态、交互式示例、边界与错误状态。
  • 适合谁：Rust 组件库或 UI 框架的维护者、需要交付组件示例的开发者、负责组件评审与文档同步的团队。

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

基本信息

  • 中文名：组件故事生成技能
  • 英文名：generate-component-story
  • 技能 ID：13283

它解决的核心问题

在组件库工程里，“组件本身写完了”往往只是完成一半，真正耗时间的是故事示例：要覆盖组件的全部选项、不同变体与状态、可交互的演示，以及错误与空数据等边界情况。手写这套内容存在三个典型痛点：

  1. 风格不统一：不同开发者写出的 story 结构差异大，评审时无法横向对比；
  2. 覆盖不全：只写了默认态，忘记禁用态、加载态、超长内容、空数据等分支；
  3. 维护成本高：组件改一次属性，一批 story 要跟着改。

该技能的定位非常明确——它不是让你自由发挥写示例，而是把仓库已有的故事写法当作模板，稳定地产出“像同一个团队写的”故事文件。

一键安装的思路与步骤

AI 技能的价值在于“装上即用、无需改造工程”，安装过程通常遵循以下通用路径（具体命令、按钮位置与入口名称以官方说明为准）：

  1. 确认前提：你已经在支持技能（Skill）机制的 AI 客户端、IDE 插件或命令行工具中完成登录；本地已有可访问的组件库项目，并且项目内存在 crates/story/src/stories 目录及 tabs_story.rs、group_box_story.rs 这类既有故事文件。
  2. 找到技能：在技能市场或技能库中搜索英文名 generate-component-story 或技能 ID 13283，进入技能详情页。
  3. 一键启用：点击安装/启用按钮，按提示确认授权范围（一般只需授予当前工作区的读取与代码生成权限）。多数客户端支持“项目级安装”，即只在当前组件库项目中生效。
  4. 验证是否生效：启用后，在对话中提出一个最小请求，例如“参考现有 story 写法，为 group_box 组件生成一个包含基本用法与不同变体的故事”，并观察三点——是否复用了既有文件的样式、是否用 section! 划分主段落、是否覆盖了多个变体。三点都满足，说明技能已正常工作。
  5. 失败排查：若未生效，检查技能是否被全局禁用、当前会话是否绑定了正确的工作区、以及 crates/story/src/stories 路径是否可达。具体排查入口以官方说明为准。

2. 该技能的主要功能和特点

  • 遵循现有模式，拒绝自创风格：技能会优先参照 crates/story/src/stories 中已存在的故事文件（如 tabs_story.rs、group_box_story.rs）来确定结构、命名与导出方式，产出的新故事与存量故事天然保持同一种写法。
  • 用 section! 分段组织：每个故事的主要部分都以 section! 调用组织，让示例天然具备“分区可读”的结构，评审者能一眼看出哪一段是基本用法、哪一段是变体、哪一段是边界情况。
  • 全面覆盖组件能力：要求覆盖组件的所有选项、变体与使用示例，而不是只给一个默认态的最小 demo。这正是人工手写最容易偷懒、评审最容易漏掉的环节。
  • 四类内容的标准骨架：典型输出包含基本用法示例、不同变体和状态、交互式示例、边缘情况与错误状态，形成固定的内容清单，方便逐项核对。
  • 与仓库约定强绑定：输出面向组件库自身的 story 工程体系，而不是通用前端示例，避免“生成了却跑不起来”的尴尬。
  • 可复用为团队规范：一旦团队用同一技能生成故事，故事结构就变成事实标准，后续新人只需提交组件源码即可得到合规示例。

与普通代码补全工具的差别在于：普通工具只保证“这段代码语法正确”，该技能保证“这段代码符合本仓库的故事规范且覆盖面完整”。

3. 如何使用该技能？

分步骤使用指南

  1. 确认工作区与目标组件：打开组件库项目，确认 crates/story/src/stories 目录存在，并找到要生成故事的组件源码文件与其公开接口（属性、枚举变体、事件）。
  2. 给出明确的触发指令：采用“组件 + 覆盖范围 + 风格参照”三要素描述需求。例如：

    “为 GroupBox 组件生成故事文件，参照 crates/story/src/stories/group_box_story.rs 的写法，覆盖默认态、禁用态、带图标、超长标题四种情况，并用 section! 分段。”

  3. 补充组件信息（可选但推荐）：若组件接口较复杂，把构造参数、可选枚举、回调签名一并贴出或指明文件路径，可显著提高生成结果的可用性。
  4. 获取输出：技能会按照既有模式产出故事文件内容，通常表现为“基本用法 → 变体与状态 → 交互式示例 → 边缘与错误状态”的段落顺序。
  5. 人工校验三件事：编译是否能通过、命名与导出是否符合本仓库习惯、是否遗漏了组件真实存在但你未提到的变体。
  6. 运行与评审：在故事预览环境中确认每个示例都能渲染，然后作为组件评审材料提交。
  7. 补漏再生成：如果发现漏了某个状态，直接把缺的状态名追加给技能，例如“再补充空数据和无权限两种情况”，避免整篇重写。

输入示例（自然语言即可）

“参照 tabs_story.rs，为标签页组件生成故事：需要默认选中、禁用某项、项数很多导致溢出、以及初始未选中四种情况，每个部分用 section! 包起来。”

输出说明

生成的成果应满足四条可核对的标准：结构上分段清晰；写法上与同目录既有故事文件一致；覆盖上包含基本用法、变体状态、交互式示例、边界错误；内容上不出现组件本身不存在的属性。若不满足，通常是因为指令中缺少组件接口信息或覆盖范围描述，补充后再生成即可。

4. 同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
generate-component-story（组件故事生成技能） 面向组件库的 AI 故事生成器 按仓库既有模式生成 story，section! 分段，覆盖全部变体与边界 低：启用技能后在对话中描述需求即可 Rust 组件库新增组件、补全历史组件示例、组件评审 优势是风格一致、覆盖完整、不脱离本仓库工程；不足是依赖存量故事作为参照，全新工程需先有样例
手写故事文件（人工参照 tabs_story.rs 等模板） 传统做法 完全由开发者逐行编写 中：需熟悉规范与组件接口 少量组件、特殊定制示例 优势是可控性最高；不足是耗时、易漏变体、风格随人而变
通用 AI 编码助手直接对话 通用代码生成 可生成任意语言的示例代码 低 单次尝试、探索性示例 优势是灵活；不足是不了解 crates/story/src/stories 约定，常需大量返工，覆盖度无保障
组件库自带脚手架/模板命令 工程化模板 生成固定骨架文件 中：需掌握命令参数 新建组件时快速起骨架 优势是稳定可批量；不足是骨架通常只含基本用法，变体、交互与边界仍需人工补齐

从对比可以看出，该技能的差异化位置在于“懂本仓库规范 + 保证内容完整”这两件事同时成立，而这恰恰是手写与通用助手都难以稳定保证的部分。

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

场景一：组件库维护者新增组件 角色：负责组件库迭代的核心开发者。痛点是新组件上线前必须补齐故事，否则评审无法进行。使用方式是提交组件源码后，直接要求技能“按现有模式生成完整故事”。实际体验：上手难度很低，第一版通常可覆盖 80% 以上的常规变体，剩余部分多为团队自定义的展示细节，需要微调。

场景二：组件评审与设计走查 角色：负责体验一致性的设计或前端负责人。痛点是没有可点击的示例，评审只能看代码。使用方式是要求技能生成“包含不同变体与状态的交互式示例”。实际体验：分段清晰的 section! 结构让评审能逐区确认，讨论效率明显提升；注意事项是必须真实运行确认渲染结果，不能只看代码。

场景三：新人接手历史组件 角色：刚加入项目的开发者。痛点是老组件没有示例，不敢改。使用方式是让技能基于现有故事文件风格，为历史组件补一份完整示例。实际体验：这是该技能性价比最高的场景之一——补出来的故事既当文档又当回归基线；注意要提醒技能严格参照同目录文件的写法，避免引入新风格。

场景四：属性变更后的示例同步 角色：组件 API 调整的执行者。痛点是改完属性后一批 story 失效。使用方式是将新接口喂给技能，要求“更新受影响的故事段落”。实际体验：比整篇重写更省力，但仍需人工确认边界状态是否仍然成立。

整体体验总结：上手门槛低（会用自然语言描述需求即可），效果高度依赖两件事——是否提供了组件接口信息、是否明确列了要覆盖的变体。务实的使用姿势是“技能出初稿、开发者做校验与补漏”，而不是把生成结果直接合入主分支。

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

  • 效率提升：把“逐行手写故事 + 逐个补变体”的重复劳动压缩为一次描述加一轮校验，原本需要反复核对的结构、命名、分段工作由技能一次性完成。
  • 门槛降低：新成员不必先通读目录下所有故事文件才能动手，只要描述组件与覆盖范围，就能得到符合团队规范的结果。
  • 质量一致：统一的 section! 分段结构与固定的四类内容骨架，让故事可横向对比、可快速评审，减少“有人写了禁用态、有人没写”的落差。
  • 覆盖度可控：把“所有选项、变体和示例都要覆盖”写成硬性要求，避免默认态一路走天下的常见问题。
  • 长期价值：故事示例本身就是组件库的活文档与回归基线。故事越完整，后续改动越安全，新人上手越快——这是一次投入、长期复利的工程资产。

7. 常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？ A：在支持技能机制的 AI 客户端或 IDE 插件中，用英文名 generate-component-story 或技能 ID 13283 搜索并一键启用即可，通常无需改造工程。是否需要付费、是否有免费额度，取决于所在平台的计费策略，以官方说明为准。

Q2：适合谁用？非 Rust 项目能用吗？ A：最适合 Rust 组件库的维护者、需要交付组件示例的开发者，以及负责组件评审与文档同步的团队。技能的核心逻辑是“参照 crates/story/src/stories 中的既有故事文件来写新故事”，若你的项目没有这一目录结构与 section! 约定，生成的参考价值会下降，建议先确认工程是否匹配。

Q3：生成的代码可以直接提交吗？ A：建议当作高质量初稿。提交前请核对三点：能否编译通过、命名与导出是否符合本仓库习惯、是否遗漏了组件真实存在的变体。技能负责“结构完整、风格一致”，最终正确性仍需开发者把关。

Q4：它和我手动参照 tabs_story.rs 写有什么本质区别？ A：手动写时你需要自己决定覆盖哪些状态，且容易只写默认态；该技能把“覆盖全部选项与边界情况”作为固定要求，并统一用 section! 分段。区别不在语法，而在覆盖完整度与风格一致性。

Q5：会不会生成一堆冗余示例，让 stories 目录变得臃肿？ A：可以在指令中限定范围，例如“只生成默认态、禁用态与空数据三种”。建议按需生成、逐步补充，而不是一次要求覆盖所有想象得到的状态组合。