storyboard

storyboard 技能概览

storyboard 技能可以帮你把一个产品想法转化为一个六格叙事，展示用户如何从问题走向解决方案。它特别适合需要快速、以人为本地判断概念的利益相关者，尤其适用于 demo、对齐 pitch，以及为 Prototypes 制作 storyboard。不同于通用 prompt，storyboard 技能提供的是一套可重复的结构，让用户痛点、紧迫感、解决方案和收益一目了然，便于快速扫读。

storyboard 适合用来做什么

当你需要在搭建 UI 之前解释行为、动机或价值时，就该用 storyboard。它输出的是叙事型产物，而不是屏幕设计系统。这个区别很关键：当问题是“这个想法用户能不能理解”时，这个技能最强；如果你想解决的是“每个像素应该长什么样”，那它就不是最佳选择。

这个 storyboard 技能的突出之处

这个技能采用经典的六格推进：角色、问题、升级、解决方案、突破，以及解决之后的生活。这样的结构能减少空泛的产品话术，逼迫你把“之前/之后”的故事讲清楚。尤其当输入比较粗糙、你需要借 storyboard 把缺失的假设暴露出来时，它会非常有用。

最适合的使用场景

这个 storyboard 技能适合概念评审、产品愿景讨论、利益相关者 demo，以及早期原型验证。当你想要的是一份能帮助你传达共情和结果，而不只是功能点的 storyboard 指南时，它是个好选择。如果你已经有了详细的视觉规格说明，那它大概率不是合适的工具。

如何使用 storyboard 技能

安装并找到源文件

使用下面的命令安装 storyboard 技能：

npx skills add deanpeters/Product-Manager-Skills --skill storyboard

安装完成后，先读 SKILL.md，再读 template.md，最后读 examples/sample.md。这些文件会展示预期的输入形式、六格输出格式，以及什么才算“好”。由于这个 repo 里没有额外的 rules/、resources/ 或脚本，大部分有价值的指导都集中在这三个文件里。

输入要足够具体、足够正确

要让 storyboard 发挥作用，输入里最好明确一个用户、一个具体问题、一个升级点，以及你打算提供的解决方案。好的输入像这样：“一位自由设计师总是错过发票，需要一个自动提醒流程。” 差的输入像这样：“做一个关于支付的 storyboard。” 第二种写法会让 persona、利害关系和结果都变得过于模糊，模型只能猜。

把粗想法打磨成更好的 prompt

在调用 storyboard 技能时，可以使用下面这个结构：

• 主角是谁？
• 他们想完成什么？
• 哪里出问题了，或者情况变得更糟了？
• 解决方案或产品是什么？
• 解决之后发生了什么变化？
• 用什么视觉风格来引导这些画面？

这样能帮助模型产出连贯、对决策有帮助的 storyboard。对于 storyboard for Prototypes，别只给功能名，还要补充用户背景和原型承诺传达的价值。

能产出更好结果的工作流

先从 persona 和痛点开始，不要先从解决方案入手。然后要求六个分镜重点体现情绪上的转变，而不只是事件本身。如果第一次输出显得很泛，就补充数字、截止时间或真实约束，比如损失了多少时间、可能面临多少收入风险，或有哪些讨厌的手工步骤。这些细节会让 storyboard 更可信，也更适合拿去展示。

storyboard 技能 FAQ

storyboard 是 UI 设计技能吗？

不是。storyboard 技能面向的是叙事沟通，不是像素级界面设计。它帮助你解释用户旅程和产品价值，因此非常适合在原型工作之前，或与原型工作同时使用。

什么时候该用 storyboard，而不是普通 prompt？

当你想要一套可重复的六格结构，并尽量减少 prompt 漂移时，就该用 storyboard。普通 prompt 也许足够应付一次性的概念表达，但如果你需要在多个想法或多个团队之间保持一致的讲故事格式，storyboard 技能会更稳。

storyboard 指南对新手友好吗？

友好。只要你能描述用户、问题和预期结果，就可以上手。你不需要设计专业背景，但你需要足够的产品上下文，避免生成过于泛化的分镜。

storyboard 不擅长覆盖什么？

它不能替代 journey mapping、UX 规格说明或视觉交互设计。如果你需要详细流程、边界情况或组件状态，应该使用别的产物，把 storyboard 当作定框架的工具，而不是完整规格。

如何提升 storyboard 技能

在生成前先把用户故事写扎实

提升质量最明显的一步，就是把 persona 写得更具体。加入角色、环境和压力点。比如“下班后对账发票的小企业主”，会比“有问题的用户”生成更好的 storyboard。

加一个可衡量的后果

当问题带有可见代价时，storyboard 技能会更强：浪费的时间、错失的收入、焦虑，或延迟。这样第 2 格和第 3 格会更真实，也能让解决方案显得是“应得的”，而不是硬塞进去的。

把解决方案带来的变化写具体

最好的 storyboard 会呈现一个有意义的前后变化。不要只说功能名；要写清楚用户现在能更快做什么、减少了什么阻力，或者更有把握地完成了什么。对于 storyboard for Prototypes 来说，这意味着你要描述原型对行为的影响，而不只是它有哪些屏幕。

针对薄弱分镜反复迭代

如果某一格感觉很单薄，通常是因为输入说明不够具体。把 brief 改写后重新运行 storyboard 技能，重点补失败的那一格：问题太模糊，就给第 2 格补更多上下文；收益太弱，就让第 5 格和第 6 格有更清晰的结果。