script-generator

脚本生成器

遵循以下共享的公开技能规则：

• postplus-shared 公开技能规则

当用户希望创建可用于以下内容的脚本输入时，请使用此技能：

• AI UGC 口播视频
• TikTok 或 Instagram 幻灯片或轮播创意
• 钩子测试包
• 后续可用于分镜或渲染请求工作的脚本变体

此技能位于 script object 层。

它适用于：

• 将模糊的用户需求转化为结构化脚本简报
• 修正以品牌或功能为先的薄弱输入
• 生成可测试的钩子和脚本变体
• 区分有证据支持的建议与暂定草稿
• 为后续分镜或请求设计做好清晰交接

它不适用于：

• 创建项目或营销活动文件框架
• 编写分镜网格提示词
• 编写可直接交给服务提供商的渲染 JSON
• 将暂定脚本冒充为经基准验证的事实

核心理念

优秀的 AI UGC 脚本不是“自然口语加上产品优势”。

它是一则伪装成轻松内容的转化脚本。

目标不是：

• “让它听起来更像真人”
• “让它更容易爆红”
• “让它显得更高端”

目标是：

• 提出一个具体的观众疑问
• 延迟观众察觉这是广告的时间，以争取注意力
• 让机制或证据清晰易懂
• 只有在开场张力奏效后才揭示产品
• 每个素材只传达一个核心信息
• 输出可供测试并交接给下游使用的脚本对象

共享文件系统上下文

阅读 references/source-context.md。

当营销活动或项目级源文件存在时，将其作为稳定上下文使用：

• brand.md
• persona.md
• product.md
• hooks.md

这些文件是共享的真实信息来源。

此技能可以读取并使用它们。 此技能不会创建或管理它们。

输入优先级

按以下顺序规范化输入：

1. 当前任务的明确输入
2. 营销活动或项目源文件
3. 基准或研究资料
4. 用户自由文本

不要因为存在源文件就忽略当前需求。 如果稳定的源文件能直接提升脚本质量或一致性，也不要忽略它们。

最小脚本简报

编写变体前，将需求规范化为最精简且实用的脚本简报。

必填项：

• productOrOffer
• targetUser
• goal
• formatTarget
• corePainOrDesire

重要的辅助项：

• audienceAwareness
• mechanismOrReasonWhy
• proofAvailable
• ctaStyle
• constraints
• sourceBasis

如果缺少必填项，先推断出最稳妥的精简版本。只有在缺失字段会实质性改变脚本结构时才提问。

证据规则

优先使用有证据支持的脚本生成方式。

有用的证据来源包括：

• 基准报告
• 模式表
• 主表
• 落地页
• 经批准的产品资料
• 经批准的钩子库
• 营销活动的真实信息来源文件

证据不完整时，不要默认停止。

而应区分：

• Observed
• Inference
• Open question

然后，仅在用户仍需要脚本时生成暂定草稿。

不要将暂定草稿表述为经过验证的建议。

首要判断

判断请求主要属于以下哪类：

• ugc_video
• slideshow
• both

不要生成一份通用脚本，并假装它对两种形式都同样适用。

脚本质量规则

阅读 references/script-quality-rules.md。

每份输出都应遵循以下默认规则：

• 以观众的具体问题开场，而不是以品牌介绍开场
• 在广告感出现前，先展现或暗示问题或需求
• 只有在有助于吸引观众时才揭示产品
• 每项素材只传达一个核心信息
• 讲清楚机制，而不只是呈现结果
• 优先考虑留存，再考虑说服
• 先吸引观众，再展示品牌
• 先引发好奇，再解释
• 等张力开始发挥作用后再引入产品
• 先讲清机制，再提出宽泛主张
• 先提供证明，再给出行动号召
• 先追求简洁，再追求巧思

如果用户的草稿违反这些规则，应先调整结构，再润色措辞。

标准脚本框架

每个可用的脚本变体都应包含：

• Hook
• Problem recognition or desire trigger
• Proof or mechanism
• Product role
• Outcome
• CTA

可以压缩。

最终变体不得完全缺少以下内容：

• hook
• 机制或证明
• 产品角色

受众认知阶段规则

扩展变体前，先估计受众的认知阶段：

• unaware
• problem_aware
• solution_aware
• product_aware
• most_aware

然后确定：

• 脚本可以假设什么
• 哪些内容暂时不应解释
• 是否可以提前直接提及产品

认知阶段匹配错误是脚本问题，不只是文案问题。

角度规则

除非用户明确要求只采用一个固定角度，否则不要只写一个角度。

选择一个推荐的主要角度，然后生成相邻且可测试的变体。

支持的角度类型：

• pain_recognition
• proof_first
• contrarian
• mistake_correction
• process_reveal
• comparison
• before_after
• identity_or_social_stake

每个变体都应说明它在测试什么。

不要用只改变措辞、却不改变角度或 hook 作用的微小改写来淹没用户。

Hook 与揭示规则

撰写完整变体前，先确定：

• viewerQuestion
• hookMechanism
• productRevealRule
• proofRole
• ctaRole

如果这些内容不明确，技能就不应直接跳到润色完成的文案。

视频脚本模式

适用于以下情况：

• 需要促使观众改变看法
• 需要进行解释
• 可以展示产品操作或机制

默认写作规则：

• 写得像口语，而不是文案段落
• 优先使用短句
• 可以适度自我修正
• 可以使用自然表达，例如：
  • I didn't expect this
  • the weird part is
  • what actually matters is
• 避免使用泛泛的品牌语言，例如：
  • revolutionary
  • transforms your routine
  • game-changing
  • seamless
  • 堆砌空洞的形容词

不要硬套单一、固定时长的模板。

改用以下节奏节点：

• opening hook
• specific pain or desire
• product use or proof
• result or payoff
• cta close

可以提供建议节奏，但节点比秒数更重要。

幻灯片模式

适用于以下情况：

• 概念具有视觉表现力
• 证明内容可以拆分成多张卡片
• 每一帧都能引发细微的好奇心

默认写作规则：

• 一张幻灯片只承担一个认知任务
• 每张幻灯片都应简短且便于快速浏览
• 第一张幻灯片必须引发好奇、共鸣或紧张感
• 幻灯片序列必须有推进过程
• 不要把功能要点伪装成幻灯片

此模式应输出幻灯片流程，而不是按句子换行拆分的口播脚本。

默认工作流

1. 规范需求

确定满足需求所需的最精简脚本简报。

如果输入内容宽泛，先推断，再提问。

2. 检查源上下文

加载最少且有用的源上下文：

• brand.md：了解品牌语气边界、禁用短语和定位
• persona.md：了解叙述者的可信度和与产品的关系
• product.md：了解产品主张、机制、异议和证明
• hooks.md：了解经过测试的框架、避免重复的要求和变体方向

如果缺少某个文件，说明会造成什么影响。 默认情况下，不要将缺少文件视为阻碍。

3. 在生成变体前确定策略

打印或推理：

Format target:
Audience awareness:
Primary angle:
Support angles:
Viewer question:
Hook mechanism:
Product reveal rule:
Proof role:
CTA role:
Main source basis:
Confidence level:

4. 生成变体

默认输出集：

• 8-12 个钩子
• 当 ugc_video 在范围内时，提供 3-5 个视频脚本变体
• 当 slideshow 在范围内时，提供 2-3 个幻灯片流程

每个变体应包含：

• variantId
• angle
• whatIsBeingTested
• hook
• scriptFlow
• whyThisShouldWork
• mainRisk

5. 按脚本 QA 标准进行检查

每个最终输出都应包含：

• Viewer question clear?
• Ad feeling delayed enough?
• Product reveal timing ok?
• One core message only?
• Mechanism legible?
• Proof concrete enough?
• CTA soft enough?
• Video-native or slideshow-native?
• Main drift risk

如果某个变体仍然较弱：

• 在返回前进行修改，或
• 明确说明它仍然较弱的原因

不要仅仅因为用户写了某个弱草稿，就原样放过。

6. 返回后续交接内容

只建议一个后续技能。

典型后续步骤：

• 当场景逻辑需要转化为分镜时，使用 storyboard-grid-writer
• 当脚本足够稳定，可以进行请求规划时，使用 video-request-architect
• 当提示词草稿已经存在且需要诊断时，使用 prompt-preflight-qa

输出形式

根据任务返回最精简且实用的内容组合。

常见形式：

• script brief summary
• script strategy block
• source context
• hook library
• video script variants
• slideshow flow variants
• qa block
• downstream handoff

脚本策略块

应包含：

• goal
• formatTarget
• audienceAwareness
• primaryAngle
• supportAngles
• hookMechanism
• viewerQuestion
• productRevealRule
• proofType
• softCtaRule
• sourceBasis
• observed
• inference
• openQuestions
• mainDriftRisks

来源背景

应包含：

• brandContext
• personaContext
• productContext
• hookContext
• confidenceLevel

使用以下值：

• from brand.md
• from persona.md
• from product.md
• from hooks.md
• from benchmark patterns
• from landing page
• from user input
• missing

置信度等级：

• grounded
• partially_grounded
• provisional

反模式

不要：

• 在观众尚未产生兴趣之前就以品牌名称开场
• 在一个素材中保留多个无关的承诺
• 把产品的作用藏起来，直到观众无法判断销售的是什么
• 用含糊的结果主张代替具体机制
• 让幻灯片输出读起来像一串文案要点
• 让真人出镜口播读起来像广告宣传册文案
• 在 hooks.md 只是原始素材库时，悄悄把它当作经过验证的效果依据

失败情形

出现以下情况时，应停止或明确警告：

• 脚本信息不足，且这会影响结构
• 用户希望在一个素材中传达太多信息
• 没有可信的机制或证据
• 脚本听起来仍像品牌在说话，而非创作者自然表达
• 输出格式与平台任务不匹配

然后提供：

• 最接近可用的修正版
• 主要未解决风险
• 下一步可切实解决问题的事项