简诗 AI 用户故事生成

它解决什么问题

把一个功能拆成用户故事，看起来简单，实际做起来常见的坑有三个：一是只写出“作为一个用户我想……”这一句卡片，缺少对话和确认环节，开发拿到手不知道边界在哪；二是验收标准写成愿望清单，没有可测行为，测试阶段再补就容易遗漏边界情况；三是故事之间耦合在一起，或者一个故事塞了太多东西，排期时无法估算也无法拆分。

这个技能把这件事做成一个有固定输入、有明确步骤、有结构化输出的流程，而不是凭感觉写几句。

它如何工作

输入是四个参数：$PRODUCT 产品或系统名，$FEATURE 要拆解的新功能，$DESIGN 设计稿链接（Figma、Miro 等），$ASSUMPTIONS 关键假设和上下文。参数给齐之后按七个步骤走。

前两步先理解功能再识别用户角色和各自旅程，不同的角色对应不同的叙事路径，而不是把所有用户笼统成一个“用户”。第三步套用 3 C's 框架：Card 是简单标题加一句话，Conversation 展开意图和讨论，Confirmation 落到清晰的验收标准，三层缺一不可。第四步对照 INVEST 原则——Independent、Negotiable、Valuable、Estimable、Small、Testable——逐个校验，确保故事之间不互相依赖、大小适合单个冲刺。

验收标准要求写成可观测行为：系统如何校验、边界情况如何处理、有无性能和可访问性考虑、是否涉及外部集成。模板默认给 4 到 6 条，覆盖正向路径和异常路径。描述统一用简单直白的话，目标是小学文化程度也能读懂，避免内部黑话。

输出交付物是一组完整的用户故事，每条包含标题、描述、设计稿链接和 4 到 6 条验收标准。故事之间相互独立，开发顺序可以任意调换，单条故事大小对齐一个冲刺周期，同时关联相关设计文档方便查阅。

适用边界

输入参数必须明确，$FEATURE 和 $ASSUMPTIONS 缺一不可，否则拆解出来的角色和验收标准会偏离实际业务。它处理的是单个功能的拆解，不负责整个产品的路线图规划或多迭代方案设计。

安全边界方面，这个技能不自动安装依赖、不修改系统权限、不创建持久化任务、不执行下载内容。涉及发送、发布、删除、付款、部署或其他外部写入操作时，先展示目标与影响并取得确认。凭据只用于对应的官方服务，不回显、不记录、不转发到无关地址。命令和代码默认作为参考，只有明确要求且目标范围清楚时才执行。