Key 只在你的浏览器里。Key 由浏览器直接发送给服务商，不经过我们的服务器，我们不记录也不保存。建议使用专门创建、设了额度上限的 Key，用完及时到服务商后台删除。
输入
结果
结果会显示在这里。功能需求通常是工单或群聊里的一段话：谁提的、大概想要什么、一两条规则。在任何人能估工作量之前，它得先变成用户故事——“作为计费管理员，我希望……，以便……”——每条都带着测试能验证的验收标准。把需求贴进来，选好拆成几条，这里会写出带 Given / When / Then 场景的用户故事，每条覆盖主流程，外加至少一个失败或边界情况；确有依赖关系时还会附一行备注。如果故事要通过 API 进 Jira、Linear 或脚本，而不是写进文档，就选 JSON 格式。
它是怎么工作的
- 合并了 Fabric 的两个模式：create_user_story 提供“描述 / 验收标准”结构和不许套话、不许凑字的要求，agility_story 提供 Given/When/Then 验收标准和 JSON 输出结构。
- 按交付给用户的价值拆分故事，而不是按前端、后端分层；每条都控制在一个迭代能完成的大小——也就是 INVEST 经验法则。
- 中文输入会使用 Gherkin 的中文关键字“假如 / 当 / 那么 / 而且”，Cucumber 等 Gherkin 工具都认，写出来的场景可以直接作为真实 feature 文件的起点。
- 需求文本从本页发往你选择的服务商，用你自己的 Key 认证——为这类工具单独准备一个设了上限的 Key，比用你产品线上跑的那个 Key 安全得多。
你的数据去了哪里
使用自带 Key 时，你输入的内容和 Key 由浏览器直接发送给你选择的 AI 服务商，不经过 hysenlabs 的服务器。使用官方托管时，内容经我们的服务器转发给我们的服务商（DeepSeek），按 credits 计费；我们只记录每次运行的 Token 数和成本用于计费，从不保存你输入的内容和返回的结果。服务商如何处理这些内容，以它自己的隐私政策为准。
本工具会接触密钥和凭证，因此任何一次运行都不会被保存，连你自己的历史里也不会有。
关于你的 API Key
我们承诺不会收集、存储或泄露你的 Key：它只保存在当前页面的内存里（除非你勾选“在本标签页记住”），关闭页面即消失。但任何 Key 一旦在网页里用过，都值得多一分小心——建议专门为这里创建一个设了额度上限的 Key，用完后及时到服务商后台删除或轮换。
它要花多少
本工具完全免费，不需要登录，也不消耗积分。
常见问题
- 为什么每条故事都有一个失败场景？
- 因为主流程是大家早已达成一致的部分。真正导致返工的问题——日期范围为空时怎么办、谁能看到这个按钮、导出失败时邮件怎么写——只有在有人必须把失败情况写下来时才会暴露。不适用就删掉，总比到了测试阶段才发现要省事。
- JSON 能直接导入 Jira 吗？
- 不能直接导入：Jira 的导入器只接受 CSV 或它自己的 REST API 格式。这份 JSON 是干净的中间格式——一个包含 topic、story、criteria、notes 的数组——写个小脚本就能通过 Jira 或 Linear 的 API 提交，也可以转成 CSV。
- 故事里出现了我没提过的规则，为什么？
- 提示词要求模型把缺失的规则写进备注、标明是假设，而不是当成事实写，但模型偶尔会疏忽。把验收标准当成问题清单来读：每个你没提供的数字或权限，都要找提需求的人确认一遍。
- 一个需求该拆成几条故事？
- 有几块能独立交付价值的内容，就拆几条。示例里的发票导出——带筛选、权限控制，大批量导出走后台任务——自然就是三条。模型拆不出那么多时会少写，不会凑数；如果某条看起来仍像一周的工作量，调大数量再跑一次。
背后的开源项目
本工具的提示词改编自 danielmiessler/Fabric（MIT），由你选择的模型执行。想在命令行或自己的程序里批量使用同样的能力，可以直接用这个项目。
danielmiessler/Fabric也常被称作
- 用户故事模板
- 验收标准怎么写
- 用户故事生成
- given when then
- 敏捷用户故事
- gherkin验收标准