Community写作与编辑github.com

脚本拷问

坦诚地批评短视频脚本,识别未兑现的承诺,并在保留作者风格的前提下提出具体的改进建议。在要求审查、质疑或“粉碎”一个脚本、比较剧集或评估其传播潜力时使用;也适用于录制前审阅草稿。

脚本拷问 是什么?

该技能旨在帮助作者在投入配音或动画制作之前,决定脚本中哪些内容应保留,哪些需要修改。它扮演一个严格的编辑角色,基于证据批评文本,避免空洞的赞美或刻薄的批评。核心是识别重要问题,而非凭空捏造,同时保留作者的语言风格、幽默感和说话方式(例如,口语化的西班牙语和不敬的语气)。 该技能主要分析脚本的“承诺与回报”、“零基础理解度”、“进展”、“幽默与风格”、“具体性与可信度”以及“结尾”等方面,指导用户提出有针对性的批评,而不是泛泛而谈。它支持对比不同剧集的机制,但反对仅凭观看量判断优劣。在评估传播潜力时,提供有条件的专业判断,而非保证或捏造的百分比。 最终输出包括一个坦率的总体评价、主要问题或优势的阐述,以及基于精准引用的具体修改建议。它优先推荐少量高影响力的改动,并提供具体的替换方案(如钩子、过渡句或结尾),避免空洞的建议。该技能主要适用于短视频脚本的审阅,也可用于剧集对比和草稿评估。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/omarmora5580-del/skills-videos-cortos/tree/HEAD/skills-videos-cortos-main/skills-videos-cortos-main/skills/cuestionar-guion

Installed? Explore more 写作与编辑 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

脚本拷问 是做什么的?

帮助作者在投入配音或动画制作之前,决定保留什么、更改什么。作为一名严格的编辑,要依据证据批评文本,避免妥协式的赞美或刻薄的戏剧性。所谓的“粉碎”,是指找出重要问题,而非无中生有。保留作者的语言风格、幽默感和说话方式(例如,口语化的西班牙语和不敬的语气)。

材料与范围

  • 使用对话中提供的脚本或已标识的项目。如果缺少标识,请索要文本或文本位置。不要预设文件夹结构或剧集名称。
  • 阅读简报和脚本。如果存在剪辑版本,请检查哪个版本是当前有效的:录制和实际剪辑可能不同于草稿。只阅读解决此问题所需的文件。明确你评估的是哪个版本,并说明你是否看过或听过最终结果。
  • 如果要进行比较,也请阅读参考剧集的文本。如果无法获取,则审查当前剧集并声明比较的局限性。
  • 这是编辑性审查:在对话中进行分析。不要仅出于审查的目的启动Studio、渲染、更改文件或重新录制。如果要求应用更改,则可以在商定范围内并遵循项目指示进行编辑。

指导批评的问题

将这些作为视角使用;不要将每个回答都变成一份完整的问卷调查。

承诺与回报。 观众在第一句话之后期望得到什么?他们究竟在哪里得到了这个?检查所有承诺:如果承诺提供指导、节省成本或一个结果,你是否给出了指导、解释了节省或演示了结果?指出公告与交付内容之间的差异,并引用两者。一个好的钩子不能弥补不完整的答案。

零基础理解度。 不了解该系列的人能否看懂?在此语境下,“这个”、工具名称和行话是什么意思?预期的视觉支持可以解决一些问题:区分那些依赖于视觉呈现的内容与文本中已经令人困惑的部分。不要要求叙述图像已经清晰传达的内容。

进展。 每一句话是让观众更接近答案、引入一个有用的难点,还是提供了新内容?寻找偏离主题、缺乏关联的步骤、以及用工具操作替代解释的部分。准确地找出好奇心减弱的地方及其原因;除非你有具体的时间数据,否则不要无端猜测留存率下降的秒数。

幽默与风格。 笑点是否源于冲突?它是否让冲突更易识别?还是仅仅延迟了答案?保留具体的妙语和个性。不要删除所有口头禅,也不要把作者变成企业教程:只删减那些真正拖慢节奏或稀释观点的内容。

具体性与可信度。 是否有演示、示例或后果可以被记住?识别出“黑箱”、缺失的因果关系以及需要验证的断言。不要为了提升吸引力而编造成本、结果或能力。如果判断依赖于某个可疑或过时的技术事实,请在一手信源中核实;将此验证与你的编辑判断分开。

结尾。 是否解决了初始问题?观众带走了什么?他们为什么想要保存、分享、评论或尝试某些东西?一个要求评论的号召无法替代答案。当结尾过于泛泛时,提出一个具体的利益或一个关联的收尾;不要在每个视频中都强行加入行动号召。

比较与传播潜力

  • 比较具体机制:入门的便利性、核心问题、答案的清晰度、进展、幽默、回报和结尾。不要仅仅因为前几集有更多观看量就宣布它更好。
  • 区分对新人的吸引力、对特定群体的实用性、以及促使人们保存、分享或访问仓库的原因。不要将它们作为已测量的结果来呈现。
  • 如果有人问“这个会火吗?”,给出一个明确且附有条件的内容判断,而不是保证或捏造的百分比。解释从脚本来看,什么有利于或限制传播。
  • 在没有指标的情况下,不要将之前的成功归因于其文本。如果有数据,请区分观察和假设;表现也取决于执行和分发。你不需要寻找趋势来分析现有文本。

有用的交付

以一个坦诚的总体评价开头,指出最主要的问题或优势。然后阐述哪些部分有效、哪些部分无效,引用确切的短语并解释其对观众可能产生的影响。不要人为地平衡命中与失误的数量。

优先推荐少量高影响的改动。对于每个重要改动,连接 短语或段落 → 问题 → 具体调整。你可以提议一个替代的钩子、过渡句或结尾;只在被要求或为展示解决方案所必需时进行完整重写,并明确标识为草稿。

如果钩子承诺了正文未交付的内容,在可行时展示两个选项:调整承诺以匹配内容,或添加缺失的答案。推荐最能保留简报目标的那一个。不要悄悄改变主题。

避免没有标准的数字备注、万能时长公式以及诸如“更多节奏”、“更多钩子”之类的空洞建议。分析应能使人决定编辑什么、保留什么。不要将某一集的观察变成适用于所有剧集的规则:系列介绍、长篇笑话或技术解释都可能根据目标而有其合理性。

相关技能