需要在概念评审、方案对齐或演示中用叙事打动人心时，用 6…

当你需要在不做任何开发的情况下快速对齐利益相关者、推销功能概念或验证方案的情感共鸣时，用六帧故事板讲一个用户从困境到改善的故事。

适用场景

解决思路

1. 先收集上下文，确保四件事齐全：主角人设清晰（可参考 skills/proto-persona/SKILL.md）、问题理解到位（参考 skills/problem-statement/SKILL.md）、解决方案已定义（参考 skills/positioning-statement/SKILL.md）、用户期望的成功结果明确；若上下文缺失，先做调研，绝不编造人设或问题。
2. 依次逐个回答 7 个故事板问题（一次问一个）来发展叙事：1）谁是经历这个问题的主角？（姓名、年龄、角色、场景）2）描述主角面临的问题或挑战。3）描述问题升级成重大危机的「Oh Crap」时刻。4）解决方案是如何被介绍给主角的？5）描述主角使用解决方案并经历「Aha」时刻。6）使用解决方案后主角的生活变成什么样？7）有没有特定的视觉风格或渲染要求？（默认：粗马克笔 sharpie 风格草图，极简、单色）
3. 按经典叙事弧写出 6 帧叙事（使用 template.md 的完整填充结构）：Frame 1 Introducing the Main Character——介绍主角、场景与背景；Frame 2 The Problem Emerges——描述挑战及其对生活的影响；Frame 3 The 'Oh Crap' Moment——把问题升级为重大危机；Frame 4 The Solution Appears——说明方案如何被引入及主角的初始反应；Frame 5 The 'Aha' Moment——展示主角使用方案并取得突破；Frame 6 Life After the Solution——描述问题解决后的改善状态。
4. 补上可选视觉元素说明：若未指定视觉风格，写明「使用粗马克笔、sharpie 风格草图——极简、单色、手绘感」；若用户提供了视觉元素，则写明「包含用户提供的图片、GIF 或图标」。
5. 为每一帧创建或描述视觉，每帧都要给出三要素：Visual（画面内容，如主角的位置、道具、屏幕上的文字）、Mood（情绪，如忙碌微焦虑、不堪重负、焦虑紧迫、好奇期待、喜悦释然、平静平衡）、Details（具体细节，如时间显示 10pm、日历上的房租到期日、日落背景、6pm 而非 10pm 的时钟）；可用 DALL·E、MidJourney 或手绘草图实现。
6. 交付前用 6 个问题测试故事板：1）主角有共鸣吗——目标人设会认出自己吗？2）问题是否直击感受——Frame 2-3 能让人真切感到挫败吗？3）「Oh Crap」时刻真实吗——是否自然地升级了问题？4）方案引入自然吗——还是显得生硬刻意？5）「Aha」时刻可信吗——用户能想象自己经历这一刻吗？6）「之后」状态令人向往吗——用户会想要这个结果吗？任何一条答「否」就修改。
7. 避免 5 类常见陷阱并按对应方式修复：1）人设太泛（「Meet User, a busy professional」）→ 具体化（「Meet Sarah, 35, freelance designer, juggling 10 clients, home office, loves design but hates admin」）；2）问题太弱（「用户有效率问题」）→ 让它直击感受（「Sarah 每月花 8 小时追逾期发票，错过家庭晚餐，为现金流焦虑」）；3）方案引入生硬（「用户神奇地发现了我们的产品」）→ 展示真实的发现路径（设计论坛里的推荐、同事提及）；4）「Aha」时刻以功能为中心（「用户看到仪表盘并喜欢这些功能」）→ 聚焦结果（「Sarah 收到通知：'$5,000 received!' 她松了口气——不用打尴尬的催款电话」）；5）「之后」状态含糊（「生活变好了」）→ 写具体（「Sarah 现在 6pm 就下班，晚上陪孩子而不是追客户；按时付款率从 50% 升到 80%」）。
8. 始终记住这不是 UI 稿、不是用户流程图、不是功能演示、也不是营销文案，而是聚焦用户结果与情感的故事讲述工具，低保真草图即可。
9. 如果用户在调用时已经提供了信息（技能名之后的文本、粘贴的上下文，或附加的 ARGUMENTS: 行），直接当作已给出的答案使用并跳过相应提问，不要重复询问。用户什么都没提供也可以开始：先问用户是谁、对他们而言发生了什么改变，再构建六帧。

适用边界 · 注意事项

• 需要技术实现细节时——改用架构图。
• 用户问题过于琐碎或已被充分理解时。
• 把它当作用户研究的替代品——故事板只是把洞察具象化，不能创造洞察。