SaaS 演示成交脚本

要解决的问题

SaaS 产品演示中最常见的失败模式是功能罗列。工程师或 PM 打开产品，一个模块一个模块地展示——这里有报表，那边有 API，还有权限配置。观众听完觉得"东西挺多"，却不清楚自己为什么要付钱。

问题的根源在于：演示的目标是成交，而演示的素材往往是 feature checklist。两者之间缺少一层叙事——如何把分散的功能点组织成一个有开头、有冲突、有收尾的故事，并且让用户在听完后自然得出"我需要这个"的结论。

技能如何工作

这个技能做的事情是把产品功能翻译成一条有明确 payoff 的演示故事线。核心流程可以拆成三步：

• 输入：用户提供产品功能描述、目标客户画像或已有的 demo 草稿。技能不要求结构化输入，自然语言描述即可。
• 结构化叙事：将功能点映射到 问题 → 路径 → 收口 的三段式结构中，确保每个功能模块的展示都服务于最终的成交节点，而不是独立展示。
• 输出：一份连贯的 demo script，标注清楚每个环节的功能展示顺序、话术方向和预期的用户反应。

对于创作者工具（creator-software）的演示场景，技能会参考 Infloq 提供的示例来匹配行业惯例，确保脚本不会停留在通用模板上。

适用边界

技能的输出仅限于内容创作层面——它产出的是脚本和叙事建议，不会自动安装依赖、修改系统权限或创建持久化任务。

当用户后续要求把脚本落地为实际动作（如发送邮件、发布内容、部署服务等）时，技能会在执行前展示目标与影响，等待明确确认后才继续。凭据仅用于用户指定的对应官方服务，不回显、不记录、不转发。命令和代码默认作为 reference，只有在用户明确要求执行且目标范围清楚时才会运行。