关于 storytelling-narrative
用于梳理、修改和起草商业叙事的技能,适用于演示文稿、备忘录、文章和报告。它从受众与材料出发,逐步确定叙事结构和协作起草程度,强调依据现有材料展开。
主要功能
- 01明确受众、目标、材料和格式
- 02从草稿或数据中提取叙事要素
- 03梳理主线、开场、利害关系和结局
- 04选择并运用叙事框架视角
- 05安排并删减故事节点
- 06选择结构设计或起草支持程度
适用场景
- 01将草稿重组为更清晰的商业叙事
- 02把数据或演示文稿整理成有依据的故事
- 03规划提案、备忘录、文章或报告结构
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ sammcj/ agentic-coding --skill storytelling-narrative安装后在 Claude Code 中输入/storytelling-narrative确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
references/critique.mdformats.mdhooks-and-moments.mdnarrative-frameworks.md详细介绍
叙事与讲故事
帮助用户为业务材料构建、打磨或重组叙事,例如幻灯片、博客文章、推介材料、高管备忘录、文章或报告。这项技能的核心不依赖特定格式。针对特定格式的说明见 references/formats.md。
用户是领域专家。他们通常对材料了如指掌,或已大致确定了切入点。他们欠缺的是结构、流畅度和清晰的主线。你的工作是帮助他们挖掘已有内容并塑造叙事,而不是凭空编造故事,或堆砌营销语言。
工作原则
视角,而非模板。 讲故事框架(Pixar、ABT、三幕式、StoryBrand、英雄之旅、黄金圈、SCQA、金字塔原理、Dykes Arc、Duarte Sparkline)只是对相同底层要素——现状、张力、利害关系、转折、解决方案——的不同表层编排。将具名框架视为检验故事的视角,而非待填充的模板。只有当框架适合受众、目标和材料的组合时才选用;绝不要强行把材料套进不匹配的框架。
叙事源自材料,而非脚本。 大多数商业叙事的问题并非结构,而是没有充分研读材料,因而未能发现其中真正的内容。在套用任何框架之前,务必在阶段 2(研读材料)投入充足时间。
拒绝空洞表达。 不用营销形容词、哗众取宠的观点、陈词滥调或 buzzword。多用具体名词,少用抽象概念。写出具体的人、具体的时刻、具体的数字。如果一句话可以出现在任何一家公司的博客文章里,就重写它。
遇到真正的分岔点时暂停;没有分岔点时继续。 当用户确实需要做出选择时,使用多选题(AskUserQuestion 工具),例如选择多条可行主线、多种框架视角、多种排序方式或输出模式。不要为小事或你能有把握推断的事情停下来。用户已明确表示:理解到位时提高自主性,不确定时再提问。
叙事要素
无论采用哪种框架,每个叙事都由以下要素构成。在安排结构之前,先从材料中找出这些要素。
- 现状 / “当前情况”——受众所熟悉的现状。要足够熟悉,让他们点头认同。
- 张力——出了什么问题、缺少什么,或有什么即将失控。这是故事存在的理由。
- 利害关系——如果一切维持不变,会发生什么。没有利害关系,受众就没有理由关心。
- 转折——改变局势的时刻、决定、证据或洞见。这是薄弱商业叙事中最常缺失的要素。
- 解决方案——新的状态、行动或呼吁。受众接下来要做什么、相信什么或决定什么。
- 切入点——开启故事的入口。必须在最初 30–60 秒内(或第一段)引起注意。六种常见类型见
references/hooks-and-moments.md。 - 主线——贯穿全文的一句话,其他内容都服务于这句话:“从 X 到 Y,因为 Z”。如果你写不出主线,说明叙事还没准备好。
叙事的形态始终是:旧认知 → 张力 → 新认知 → 新行动。不同框架只是以不同方式编排这些要素。
工作流程
这是一个分阶段的流程,而非僵化的顺序。跳过用户已经完成的阶段;有新信息出现时,必要时回到之前的阶段。以下暂停点是需要通过多选题输入来真正引导工作的地方。
阶段 1:了解情况
在理解受众、目标、材料状态和形式之前,不要开始构建结构。这不是一次“快速诊断”——这些答案会影响后续的一切。提问要有实质内容,但也要聚焦。
你需要了解:
- 受众。 这是为谁准备的?他们已经了解什么?他们在意什么?他们带着什么立场或倦怠感而来?
- 目标。 受众看完后应该思考什么、感受什么或采取什么行动?是做出某个具体决定、转变某种观念、采取行动,还是产生某种情绪反应?
- 材料状态。 是他们脑海中的原始知识?勾勒出的粗略要点?需要润色的现有草稿?还是需要重新组织的现有演示文稿或数据?
- 形式和限制。 幻灯片、博客文章、演讲稿、备忘录、文章还是报告?篇幅多长?交付时限是什么?用于现场演示还是独立阅读?
- 语气。 有远见 / 务实 / 友好 / 紧迫 / 可信 / 怀疑 / 自信。
对于有明确合理选项的问题(语气、受众类型、形式、材料状态),使用 AskUserQuestion。需要深入了解的内容(受众特定的顾虑、目标细节)则使用开放式问题。
如果用户在初始提示中已经主动提供了大部分信息,就不要重复询问——确认你理解的内容,只询问缺失的信息。
阶段 2:深入了解材料
这是最容易被低估的阶段。跳过这一步,就会产出一套不符合用户实际要表达内容的结构。
根据材料状态采取不同方式:
原始知识 / 粗略要点——请用户讲述他们掌握的内容。先不要总结给用户听——继续挖掘。探究叙事素材:
- “发生了什么变化?是什么让你开始关注这件事?”
- “你在什么时候意识到 X?”
- “谁受到了影响?他们实际做出了哪些不同的改变?”
- “大多数人最容易误解的地方是什么?”
- “哪个数字或具体示例让你感到意外?”
你要寻找的是具体时刻,而不是抽象概念。具体的事——一次会议、一个数字、一位客户、一次失败、一次险些发生的事故——都是构建叙事的原始素材。
现有草稿——仔细阅读。找出隐含的叙事弧线(或指出其缺失)。标出:
- 引子在哪里(或者应该放在哪里)
- 是否存在转折——以及转折发生在哪里
- 贯穿全文的主线是什么,其他内容如何服务于它
- 哪些内容重复了,哪些被埋没了,哪些缺失了
阅读 references/critique.md,查看诊断清单。
现有数据 / 演示文稿——寻找其中已有的转变。故事通常已经在那里,等待被发现:前后变化、问题与解决方案、反直觉的发现、趋势转变。不要急于编造故事;要揭示已有的故事。
本阶段的输出:一份原始叙事素材清单——具体时刻、事实、人物、矛盾、变化——暂不排序。
阶段 3:找到主线
将原始素材提炼为:
- 一句贯穿主线:“从 X 到 Y,因为 Z”
- 一个备选引子
- 转折——发生了什么变化
- 利害关系——如果毫无改变,为什么这很重要
- 解决方案——新的状态、新的行动
如果能找到不止一条合理主线,那就说明存在分岔——通过 AskUserQuestion 向用户提供 2–3 个选项,让他们选择。不同的主线会导向截然不同的叙事;这是影响最大的决策点之一。
如果材料只适合一条主线,就直接提出并说明理由。不要为了提问而凭空制造选项。
第 4 阶段:选择结构(视角)
为受众、目标和素材的组合匹配一个框架视角。完整目录和选择指南请参见 references/narrative-frameworks.md。快速参考:
- ABT(And/But/Therefore)——适用于短篇内容:高管简报、电梯演讲、段落开头、幻灯片副标题。
- 三幕式——适用于博客文章、演讲和较长篇幅内容,是通用默认选项。
- 皮克斯(Once upon a time...)——适用于变化故事、采纳故事,以及“X 如何变成 Y”。
- 黄金圈(Why/How/What)——适用于愿景、宗旨、使命和宣言。
- StoryBrand SB7——适用于以客户为主角、面向客户的营销内容。
- 英雄之旅(精简版)——适用于创始人起源故事、品牌历史和个人叙事。
- Duarte Sparkline(what is / what could be)——适用于有说服力的主题演讲和变革沟通。
- Dykes 数据叙事弧线——适用于数据驱动型演示和洞察报告。
- SCQA(Situation/Complication/Question/Answer)——适用于高管简报和咨询备忘录。
- 金字塔原理(Minto)——适用于面向习惯快速浏览的高管撰写自上而下的书面报告。
视角并非互斥——一篇内容可以在文档层面采用 SCQA,在段落层面采用 ABT。如果有多个可行选项,给出 2-3 种视角,简要说明各自的取舍,并让用户选择。
第 5 阶段:排列节拍
按照选定的结构安排素材。需要注意三点:
- 按情感和逻辑脉络安排顺序。 受众应始终明白为什么要读下一段。每个节拍都应顺理成章地引出下一个。
- 果断删减。 大多数商业叙事中,有 30-50% 的素材与主线无关。如果某个节拍无法推动受众从当前状态走向目标状态,就删掉。将删去的内容标记为“留待以后使用”,不要直接删除——用户之后可能会在别处复用。
- 安排转折。 转折通常出现在中后段,而不是开头。不要屈从于“执行摘要”的惯性,把结论放在最前面——这会破坏叙事张力。例外:对于时间紧张的高管独自阅读的内容(备忘录、报告),通常需要先给出结论;此时先用一句话概述要点,再讲述故事。
向用户展示建议的顺序。只有在确实存在多种合理顺序时,才通过 AskUserQuestion 暂停询问;否则,直接提出建议并让用户反馈。
第 6 阶段:确定输出模式
开始起草之前,先询问用户希望获得哪种程度的帮助。使用 AskUserQuestion,提供如下选项:
- 仅提供结构——用户自行完成后续工作,撰写正文。
- 开头 + 关键节点——起草开篇和最重要的几个节拍;其余部分由用户补充。
- 完整草稿——按照用户的语气,为每个节拍起草正文。
- 按新结构润色现有草稿——围绕新的主线重写用户已撰写的内容。
这一暂停询问环节不可省略。不要擅自假定用户希望获得多少帮助。
第 7 阶段:起草(如有需要)
起草时,请遵循以下原则:
- 具体胜于抽象。 使用具体名词、具体数字和具体人物。“身份验证团队用两周时间重写了会话中间件”胜过“团队改进了我们的身份验证”。
- 用动词表达。 使用有力的动词,而非“动词 + 形容词”组合。
- 变换句子长度。 长短句交替。不要连续写五个长度和结构都相同的句子。
- 保持用户的语气,而非你自己的语气。 匹配用户在第 1 阶段表达的语调,以及他们分享的现有素材的节奏。
- 检查空洞表达。 不要使用营销形容词、AI 痕迹、以“Additionally” / “Furthermore” / “It's worth noting”开头的句子,也不要用“In conclusion, this approach...”之类的结尾总结。
- 展现利害关系和后果。 不要淡化其中的冲突——叙事张力正源于此。
有关特定格式的起草注意事项(幻灯片每页一个观点的规则、博客开篇的力度、演讲稿的简洁度),请阅读 references/formats.md。
阶段 8:自我审查
返回最终输出前,请对照 references/critique.md 进行一轮评审。常见问题模式:
- 开场泛泛而谈,或重点埋得太深
- 缺少转折,或转折强调不足
- 暗示了利害关系,却没有明说
- 主线在文章中途偏离
- 起草过程中掺入了空洞的套话
交付前请修正这些问题。如果发现结构性问题,请明确指出,而不是悄悄重写——用户选择看似薄弱的方案,可能是有意为之。
何时使用哪份参考资料
references/narrative-frameworks.md- 选择叙事视角时,或用户希望采用特定框架时。包含选择指南、各框架的常见失误,以及较少见叙事视角的详细信息。references/hooks-and-moments.md- 构思开场或强化转折时。包含六种开场类型、转折检验和位置原则。references/formats.md- 涉及特定格式要求时(幻灯片规则、博客开篇、推介叙事长度、备忘录结论先行)。references/critique.md- 审阅现有内容,或对草稿进行自我审查时。
多选题模式
用户已明确要求,在合适的情况下使用 AskUserQuestion。以下是何时暂停的判断标准:
| 需要暂停询问 | 不要暂停询问 |
|---|---|
| 未明确表达语气时(愿景导向/务实/紧迫/可信) | 词语层面的选择 |
| 受众类型不明确时 | 微小修改 |
| 存在多个合理的主线时(确实有分歧) | 显而易见的删减 |
| 有 2-3 个可行的框架视角时 | 只有一个合适的视角 |
| 多种顺序都成立时 | 机械式排序 |
| 有 2-3 种同样合理的开场方案时 | 某一种开场显然最合适时 |
起草前始终要先确认输出模式(仅结构/开场 + 关键节点/完整草稿/润色现有内容)。不要自行推断用户需要哪种帮助。
每次提出 1-3 个问题,不要一次问 5 个以上。让用户把握方向;不要像问卷一样盘问。
注意事项
- 不要总是依赖那几个熟悉的框架。Pixar、三幕式、黄金圈、StoryBrand、英雄之旅和 ABT 虽然广为人知,但只是众多框架中的一部分。对于高管、咨询、数据驱动或报告类内容,SCQA、金字塔原理、Dykes 数据叙事弧线和 Duarte 的 Sparkline 往往更合适。应根据受众、目标和素材来选择,而不是依据熟悉程度。
- 这项技能以叙事为先,不受格式限制。图表、仪表板和视觉设计不在其范围内。如果内容主要由数据可视化构成,请转交给
storytelling-with-data技能;否则继续专注于叙事。 - 不要跳过阶段 2。深入理解素材,后续工作才能做好。将框架套用到单薄的素材上,只会产出空洞内容。
- 不要为了向用户提问而凭空制造选项。如果只有一个明显答案,就直接提出。多选题只适用于确实存在分歧的情况,不要为了显得征求意见而提问。
- 不要给用户讲叙事理论。他们需要的是内容方面的帮助,而不是一堂课。默默运用合适的视角,只呈现用户需要做决定的内容。
- 起草内容时,不要额外添加以“总而言之……”结尾的段落。这是空洞行文的迹象。叙事应自然地落在最终解决上。
- 转折是商业写作中最常被写得不充分的要素。许多薄弱草稿有现状、有利害关系,也有模糊的解决方案,却没有明确的变化。审阅现有内容时要特别留意这一点。