Key 只在你的瀏覽器裡。Key 由瀏覽器直接傳給服務商，不經過我們的伺服器，我們不記錄也不保存。建議使用專門建立、設有額度上限的 Key，用完及時到服務商後台刪除。
輸入
結果
結果會顯示在這裡。功能需求通常是工單或聊天群組裡的一段話：誰提出的、大概想要什麼、一兩條規則。在任何人能估算工時之前，它得先變成使用者故事——「身為帳務管理員，我想要……，以便……」——每則都附上 QA 能檢驗的驗收標準。把需求貼進來，選好要拆成幾則，這裡會寫出帶有 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，用完後及時到服務商後台刪除或輪換。
它要花多少
本工具完全免費，不需要登入，也不消耗點數。
常見問題
- 為什麼每則故事都有失敗情境？
- 因為主要流程是大家早就有共識的部分。真正造成返工的問題——日期範圍為空時怎麼辦、誰看得到這個按鈕、匯出失敗時通知信怎麼寫——只有在有人必須把失敗情況寫下來時才會浮現。不適用就刪掉，總比到了 QA 階段才發現划算。
- JSON 可以匯入 Jira 嗎？
- 無法直接匯入：Jira 的匯入工具只接受 CSV 或它自己的 REST API 格式。這份 JSON 是乾淨的中介格式——一個包含 topic、story、criteria、notes 的陣列——寫個簡短腳本就能透過 Jira 或 Linear 的 API 送出，也可以轉成 CSV。
- 故事裡出現了我沒提過的規則，為什麼？
- 提示詞要求模型把缺少的規則寫進備註、標明是假設，而不是當成事實陳述，但模型偶爾還是會失誤。把驗收標準當成問題清單來讀：每個你沒提供的數字或權限，都要向提出需求的人確認一次。
- 一個需求該拆成幾則故事？
- 有幾塊能各自帶來價值的內容，就拆幾則。範例中的發票匯出——有篩選、權限控管，大量匯出走背景工作——自然就拆成三則。模型找不到那麼多時會少寫，而不是湊數；如果某則看起來仍像一週的工作量，就調高數量再執行一次。
背後的開源專案
本工具的提示詞改編自 danielmiessler/Fabric（MIT），由你選擇的模型執行。想在命令列或自己的程式裡批次使用同樣的能力，可以直接使用這個專案。
danielmiessler/Fabric也常被稱作
- 使用者故事範本
- 驗收標準怎麼寫
- user story 產生器
- given when then 範例
- 敏捷使用者故事
- gherkin 驗收標準