/dbs-script-flow
检查短视频逐字稿的段落衔接、信息密度和口播流畅度,定位观众可能划走的位置。用户要求检查逻辑延续、文稿顺畅度或流失风险时使用。
$ npx -y skills add dontbesilent2025/dbskill --skill dbs-script-flow --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/dbs-script-flow
Context preview
The summary Claude sees to decide when to auto-load this skill.
检查短视频逐字稿的段落衔接、信息密度和口播流畅度,定位观众可能划走的位置。用户要求检查逻辑延续、文稿顺畅度或流失风险时使用。
SKILL.md
dbs-script-flow.SKILL.mdname: dbs-script-flow
description: 检查短视频逐字稿的段落衔接、信息密度和口播流畅度,定位观众可能划走的位置。用户要求检查逻辑延续、文稿顺畅度或流失风险时使用。
dbs-script-flow — 逻辑延续检查
**版本**:v1.1 **适用场景**:检查短视频逐字稿的段落衔接、信息密度和口播流畅度,找出"观众会在哪一秒划走"的风险点
输出边界
使用普通 Markdown 在当前对话中交付检查报告和改稿记录,保持平台无关。不得依赖特定笔记软件,不负责创建、保存或打开本地审阅文件;文件渲染与应用打开由项目外部能力处理。
---
触发条件
当用户:
- 说「检查逻辑延续」「看看逻辑有没有断」「有没有啰嗦的地方」
- 说「帮我看看这个稿子顺不顺」「这个稿子能不能一直看下去」
- 说「检查完播率风险」「哪里会划走」
- 使用 `/dbs-script-flow`
---
与其他 Skill 的区别
| Skill | 检查什么 | 类比 | |-------|---------|------| | `dbs-script-flow` 之外的其他 Skill | 各自按其英文标准名调用 | 按对应任务检查 | | `/dbs-script-flow` | 微观衔接:每段到下段是否丝滑 | 检查每层楼梯有没有断掉 |
---
核心原则
**完播率的敌人不是内容差,而是某一个瞬间观众跟不上了。**
观众划走只有三个原因: 1. **逻辑断裂**:前一段讲 A,下一段突然跳到 C,中间缺 B 2. **信息密度掉了**:某一段在重复已经说过的东西,或者绕圈子 3. **口播卡壳**:句子太长、太书面、自问自答,念不出来
---
检查流程
第一步:分段
把逐字稿按自然段落(话题切换点)分成若干段,每段标注:
- 段号
- 段落主题(一句话概括这段在讲什么)
- 段落功能(开场 / 背景铺垫 / 论证 / 案例 / 转场 / 高潮 / 结尾)
第二步:逐段扫描三个维度
对每一段,依次检查:
维度 1:逻辑衔接(前后段之间)
问自己:
- 上一段的最后一句,和这一段的第一句之间,有没有逻辑跳跃?
- 观众听完上一段,能不能自然地理解为什么要讲这一段?
- 如果不能,缺的那个承上启下的信息是什么?
**常见问题:**
- 从个案突然跳到宏观分析,中间缺一句过渡
- 从解释原因突然跳到另一个话题,前一个话题没收束
- 从数据跳到观点,中间缺一句「所以」
**修复方法:**
- 加一句过渡句(通常一句话就够)
- 在前一段末尾加一句收束
- 调整段落顺序
维度 2:信息密度(段落内部)
问自己:
- 这一段有没有在重复前面已经说过的信息?
- 这一段有没有绕圈子(用了 5 句话说了一个 1 句话就能说清的事)?
- 如果把这一段删掉,观众会不会 miss 掉关键信息?
**常见问题:**
- 同一个意思换了三种说法反复讲
- 解释一个概念时举了太多例子,观众已经懂了还在举
- 某一段是「正确的废话」——说了等于没说
**修复方法:**
- 删减重复的表述,只保留最有力的一种
- 合并冗余段落
- 标注「可删」让用户决定
维度 3:口播流畅度(句子级别)
问自己:
- 这句话能一口气念出来吗?(超过 30 字的单句要警惕)
- 有没有书面语?(「针对」「鉴于」「基于以上分析」)
- 有没有自问自答?(「你以为 X 吗?其实 Y」——偶尔可以,连续用会烦)
- 有没有生造的概念?(观众听不懂的术语,且没有即时解释)
**常见问题:**
- 定语套定语,一句话里塞太多信息
- 用了一个术语但没有马上解释
- 连续几个短句节奏太碎,或连续几个长句节奏太闷
**修复方法:**
- 长句拆成两句
- 术语后面紧跟一句大白话解释
- 调整长短句交替的节奏
第三步:标注风险等级
对每个发现的问题标注风险等级:
| 等级 | 含义 | 说明 | |------|------|------| | 🔴 高风险 | 观众大概率在这里划走 | 逻辑断裂、信息密度严重下降 | | 🟡 中风险 | 观众可能走神但不一定划走 | 衔接不够顺、稍有啰嗦 | | 🟢 小建议 | 改了更好,不改也行 | 口播微调、用词优化 |
---
输出格式
## 逻辑延续检查报告
### 段落结构
| 段号 | 主题 | 功能 | 状态 |
|-----|------|------|------|
| 1 | [主题] | 开场 | ✅ |
| 2 | [主题] | 背景铺垫 | ✅ |
| 3 | [主题] | 论证 | 🟡 |
| ... | ... | ... | ... |
### 问题清单
**🔴 问题 1:第 X 段 → 第 Y 段,逻辑断裂**
> 原文(第 X 段末尾):「……」
> 原文(第 Y 段开头):「……」
**问题**:[具体描述为什么这里会让观众跟不上]
**修复建议**:在第 X 段末尾加一句过渡:
> 「[具体的过渡句]」
---
**🟡 问题 2:第 Z 段,信息密度下降**
> 原文:「……」
**问题**:[具体描述为什么这里观众会走神]
**修复建议**:
> 改为:「[精简后的文本]」
---
**🟢 问题 3:第 W 段第 N 句,口播不顺**
> 原文:「……」
**问题**:[具体描述为什么这句话念不出来]
**修复建议**:
> 改为:「[改写后的句子]」
---
### 整体评估
- **逻辑衔接**:[一句话总结]
- **信息密度**:[一句话总结]
- **口播流畅度**:[一句话总结]
- **总结**:[整体判断,需要改几处,改完可以发]
### 按已有请求决定是否改稿
用户在当前请求或前文已经说「帮我改」「直接改」等,直接进入标记式改稿,不再次询问授权。入口编排转交的用户原始请求同样有效。
用户只要求检查、尚未表达改稿意图时,在整体评估后可以询问:
> 要直接帮你标记式改稿吗?改的时候保留你的原文,用删除线和 🆕 emoji 标出改动。
用户明确只要检查、不希望改稿或讨论下一步时,交付检查结果即停止。没有改稿请求时,不自行改写原文。
---
标记式改稿流程(用户确认后执行)
用户在当前消息或前文说「改」「帮我改」「直接改吧」「改原文」时,启动标记式改稿,无需再次回复确认。
核心原则
**永不抹除用户原文**。改稿是在原文上叠加标记,不是用新版本替换旧版本。用户必须能一眼看出: 1. 哪些是他自己写的 2. 哪些是 AI 删除/替换建议 3. 哪些是 AI 新增的内容 4. 哪些是 AI 之前改过又被还原的(避免在多轮反馈里弄丢历史)
三种通用 Markdown 标记符
| 符号 | 用途 | 示例 | |------|------|------| | `~~删除线~~` | 标记建议删除或被替换的原文 | `~~重点是在于,这里划重点啊~~` | | 🆕 | 标记新增/改写的内容 | `🆕 这里有个关键点` | | ⚠️ | 标记 AI 自己撤回判断、还原原文 | `⚠️ 上面的删除判断错了,已还原。这三段不是跑题,是在拆解……` |
改稿规则
1. **改的过程直接在原文位置操作**——不要写一个完整的新版本贴在底部,要原地标记 2. **每个改动都成对出现**——`~~原文~~` 紧跟着 🆕 新版本,让对照关系一目了然 3. **整段删除时**:保留原段落用删除线,下面用 🆕 解释为什么删(或给压缩版替代) 4. **改完末尾给一个改动清单**——表格形式,列出每处改动的位置、类型、原因,让用户快速 review 5. **多轮反馈要追加不要覆盖**——如果用户指出某处改错了,用 ⚠️ 标注还原,不要直接改回去当作没发生过
改完输出格式
[原文 + 标记式改动,原地操作]
---
### 改动清单
| 位置 | 类型 | 说明 |
|---|---|---|
| 开头 | 🟢 替换 | [简短说明] |
| 第 X 段 | 🔴 整块删除 | [原因] |
| 结尾 | 🟡 新增 | [新增了什么、为什么] |
末尾给一句话决断(哪几处一定要改、哪几处改不改都行),让用户知道优先级。
---
注意事项
1. **不要改内容观点**:这个 skill 只管"怎么说",不管"说什么"。不要改用户的论点、案例、数据 2. **修复建议要口语化**:给出的过渡句和改写必须能直接念出来,不能是书面语 3. **不要过度诊断**:如果稿子整体很顺,就说"没什么问题",不要强行找茬 4. **优先标高风险**:宁可漏掉一个小建议,也不要把高风险问题淹没在一堆小问题里 5. **保持用户的语气**:改写时要保持用户自己的说话风格,不要把用户的话改成"AI味" 6. **给出具体位置**:每个问题都要引用原文,让用户一眼就能找到 7. **拍摄方式会影响具体修改时再确认**:先利用已有信息。若拟改动涉及并列清单、板书、手势或「划重点啊」「看这里」等视觉配合,且不同拍摄方式会改变删改结论,在修改这些位置前问清拍摄方式。白板视频中的清单和指示词可能有必要作用,应保留。与拍摄方式无关的逻辑跳跃、冗余和长句可以先处理;不要仅因未说明拍摄方式就暂停整份改稿,也不要自行认定是纯口播。 8. **判断"跑题"前先问一句**:如果删掉这段,观众在前一个关键节点能不能靠自己脑补出具体含义?如果脑补不出来,那这段就是必要的论证肉,不是赘肉。不要只看"话题字面上偏不偏",要看"这段话在服务哪个论点"
---
实战案例
案例:「小红书被告了」逐字稿(2026-04-09)
**🟡 问题 1:第 5 段第 46 行,口播绕**
> 原文:「你就会进入另外一个类似叫商家流量池的一个区间」
**问题**:「另外一个类似叫……的一个区间」连续两个「一个」,念起来会卡。而且「商家流量池」是术语,观众不一定懂。
**修复建议**: > 改为:「你就没什么流量了,也不是完全没有,但是会很差」 > 直接说结果,不引入概念。
---
**🟡 问题 2:第 7 段 → 第 8 段,缺过渡**
> 原文(第 7 段末尾):「所以接下来就是你违规引流,平台给你封号。」 > 原文(第 8 段开头):「然后接下来更有意思的事情就发生了」
**问题**:从"律师被封号"直接跳到"庭审发言",中间缺一个收束。观众还在消化"律师被封号"的信息,突然被拉到了庭审现场。
**修复建议**:把第 7 段末尾改为: > 「所以这个律师接下来被限流的遭遇,其实就是这套流程的标准结局。」 > 「标准结局」收住前面的分析,再打开新信息。
---
完成当前任务后直接结束。用户的请求超出本 Skill 的范围、任务完成后用户的材料里出现明确的后续需求,或用户询问下一步时,用一句话说明还需要哪种能力,不点名其他 Skill;当前环境已经安装 `/dbs` 时,补一句「可以输入 `/dbs`,由它匹配对应的 Skill」。
Read more
name: dbs-script-flow description: 检查短视频逐字稿的段落衔接、信息密度和口播流畅度,定位观众可能划走的位置。用户要求检查逻辑延续、文稿顺畅度或流失风险时使用。
dbs-script-flow — 逻辑延续检查
**版本**:v1.1 **适用场景**:检查短视频逐字稿的段落衔接、信息密度和口播流畅度,找出"观众会在哪一秒划走"的风险点
输出边界
使用普通 Markdown 在当前对话中交付检查报告和改稿记录,保持平台无关。不得依赖特定笔记软件,不负责创建、保存或打开本地审阅文件;文件渲染与应用打开由项目外部能力处理。
---
触发条件
当用户:
- 说「检查逻辑延续」「看看逻辑有没有断」「有没有啰嗦的地方」
- 说「帮我看看这个稿子顺不顺」「这个稿子能不能一直看下去」
- 说「检查完播率风险」「哪里会划走」
- 使用 `/dbs-script-flow`
---
与其他 Skill 的区别
| Skill | 检查什么 | 类比 | |-------|---------|------| | `dbs-script-flow` 之外的其他 Skill | 各自按其英文标准名调用 | 按对应任务检查 | | `/dbs-script-flow` | 微观衔接:每段到下段是否丝滑 | 检查每层楼梯有没有断掉 |
---
核心原则
**完播率的敌人不是内容差,而是某一个瞬间观众跟不上了。**
观众划走只有三个原因: 1. **逻辑断裂**:前一段讲 A,下一段突然跳到 C,中间缺 B 2. **信息密度掉了**:某一段在重复已经说过的东西,或者绕圈子 3. **口播卡壳**:句子太长、太书面、自问自答,念不出来
---
检查流程
第一步:分段
把逐字稿按自然段落(话题切换点)分成若干段,每段标注:
- 段号
- 段落主题(一句话概括这段在讲什么)
- 段落功能(开场 / 背景铺垫 / 论证 / 案例 / 转场 / 高潮 / 结尾)
第二步:逐段扫描三个维度
对每一段,依次检查:
维度 1:逻辑衔接(前后段之间)
问自己:
- 上一段的最后一句,和这一段的第一句之间,有没有逻辑跳跃?
- 观众听完上一段,能不能自然地理解为什么要讲这一段?
- 如果不能,缺的那个承上启下的信息是什么?
**常见问题:**
- 从个案突然跳到宏观分析,中间缺一句过渡
- 从解释原因突然跳到另一个话题,前一个话题没收束
- 从数据跳到观点,中间缺一句「所以」
**修复方法:**
- 加一句过渡句(通常一句话就够)
- 在前一段末尾加一句收束
- 调整段落顺序
维度 2:信息密度(段落内部)
问自己:
- 这一段有没有在重复前面已经说过的信息?
- 这一段有没有绕圈子(用了 5 句话说了一个 1 句话就能说清的事)?
- 如果把这一段删掉,观众会不会 miss 掉关键信息?
**常见问题:**
- 同一个意思换了三种说法反复讲
- 解释一个概念时举了太多例子,观众已经懂了还在举
- 某一段是「正确的废话」——说了等于没说
**修复方法:**
- 删减重复的表述,只保留最有力的一种
- 合并冗余段落
- 标注「可删」让用户决定
维度 3:口播流畅度(句子级别)
问自己:
- 这句话能一口气念出来吗?(超过 30 字的单句要警惕)
- 有没有书面语?(「针对」「鉴于」「基于以上分析」)
- 有没有自问自答?(「你以为 X 吗?其实 Y」——偶尔可以,连续用会烦)
- 有没有生造的概念?(观众听不懂的术语,且没有即时解释)
**常见问题:**
- 定语套定语,一句话里塞太多信息
- 用了一个术语但没有马上解释
- 连续几个短句节奏太碎,或连续几个长句节奏太闷
**修复方法:**
- 长句拆成两句
- 术语后面紧跟一句大白话解释
- 调整长短句交替的节奏
第三步:标注风险等级
对每个发现的问题标注风险等级:
| 等级 | 含义 | 说明 | |------|------|------| | 🔴 高风险 | 观众大概率在这里划走 | 逻辑断裂、信息密度严重下降 | | 🟡 中风险 | 观众可能走神但不一定划走 | 衔接不够顺、稍有啰嗦 | | 🟢 小建议 | 改了更好,不改也行 | 口播微调、用词优化 |
---
输出格式
## 逻辑延续检查报告 ### 段落结构 | 段号 | 主题 | 功能 | 状态 | |-----|------|------|------| | 1 | [主题] | 开场 | ✅ | | 2 | [主题] | 背景铺垫 | ✅ | | 3 | [主题] | 论证 | 🟡 | | ... | ... | ... | ... | ### 问题清单 **🔴 问题 1:第 X 段 → 第 Y 段,逻辑断裂** > 原文(第 X 段末尾):「……」 > 原文(第 Y 段开头):「……」 **问题**:[具体描述为什么这里会让观众跟不上] **修复建议**:在第 X 段末尾加一句过渡: > 「[具体的过渡句]」 --- **🟡 问题 2:第 Z 段,信息密度下降** > 原文:「……」 **问题**:[具体描述为什么这里观众会走神] **修复建议**: > 改为:「[精简后的文本]」 --- **🟢 问题 3:第 W 段第 N 句,口播不顺** > 原文:「……」 **问题**:[具体描述为什么这句话念不出来] **修复建议**: > 改为:「[改写后的句子]」 --- ### 整体评估 - **逻辑衔接**:[一句话总结] - **信息密度**:[一句话总结] - **口播流畅度**:[一句话总结] - **总结**:[整体判断,需要改几处,改完可以发] ### 按已有请求决定是否改稿 用户在当前请求或前文已经说「帮我改」「直接改」等,直接进入标记式改稿,不再次询问授权。入口编排转交的用户原始请求同样有效。 用户只要求检查、尚未表达改稿意图时,在整体评估后可以询问: > 要直接帮你标记式改稿吗?改的时候保留你的原文,用删除线和 🆕 emoji 标出改动。 用户明确只要检查、不希望改稿或讨论下一步时,交付检查结果即停止。没有改稿请求时,不自行改写原文。
---
标记式改稿流程(用户确认后执行)
用户在当前消息或前文说「改」「帮我改」「直接改吧」「改原文」时,启动标记式改稿,无需再次回复确认。
核心原则
**永不抹除用户原文**。改稿是在原文上叠加标记,不是用新版本替换旧版本。用户必须能一眼看出: 1. 哪些是他自己写的 2. 哪些是 AI 删除/替换建议 3. 哪些是 AI 新增的内容 4. 哪些是 AI 之前改过又被还原的(避免在多轮反馈里弄丢历史)
三种通用 Markdown 标记符
| 符号 | 用途 | 示例 | |------|------|------| | `~~删除线~~` | 标记建议删除或被替换的原文 | `~~重点是在于,这里划重点啊~~` | | 🆕 | 标记新增/改写的内容 | `🆕 这里有个关键点` | | ⚠️ | 标记 AI 自己撤回判断、还原原文 | `⚠️ 上面的删除判断错了,已还原。这三段不是跑题,是在拆解……` |
改稿规则
1. **改的过程直接在原文位置操作**——不要写一个完整的新版本贴在底部,要原地标记 2. **每个改动都成对出现**——`~~原文~~` 紧跟着 🆕 新版本,让对照关系一目了然 3. **整段删除时**:保留原段落用删除线,下面用 🆕 解释为什么删(或给压缩版替代) 4. **改完末尾给一个改动清单**——表格形式,列出每处改动的位置、类型、原因,让用户快速 review 5. **多轮反馈要追加不要覆盖**——如果用户指出某处改错了,用 ⚠️ 标注还原,不要直接改回去当作没发生过
改完输出格式
[原文 + 标记式改动,原地操作] --- ### 改动清单 | 位置 | 类型 | 说明 | |---|---|---| | 开头 | 🟢 替换 | [简短说明] | | 第 X 段 | 🔴 整块删除 | [原因] | | 结尾 | 🟡 新增 | [新增了什么、为什么] |
末尾给一句话决断(哪几处一定要改、哪几处改不改都行),让用户知道优先级。
---
注意事项
1. **不要改内容观点**:这个 skill 只管"怎么说",不管"说什么"。不要改用户的论点、案例、数据 2. **修复建议要口语化**:给出的过渡句和改写必须能直接念出来,不能是书面语 3. **不要过度诊断**:如果稿子整体很顺,就说"没什么问题",不要强行找茬 4. **优先标高风险**:宁可漏掉一个小建议,也不要把高风险问题淹没在一堆小问题里 5. **保持用户的语气**:改写时要保持用户自己的说话风格,不要把用户的话改成"AI味" 6. **给出具体位置**:每个问题都要引用原文,让用户一眼就能找到 7. **拍摄方式会影响具体修改时再确认**:先利用已有信息。若拟改动涉及并列清单、板书、手势或「划重点啊」「看这里」等视觉配合,且不同拍摄方式会改变删改结论,在修改这些位置前问清拍摄方式。白板视频中的清单和指示词可能有必要作用,应保留。与拍摄方式无关的逻辑跳跃、冗余和长句可以先处理;不要仅因未说明拍摄方式就暂停整份改稿,也不要自行认定是纯口播。 8. **判断"跑题"前先问一句**:如果删掉这段,观众在前一个关键节点能不能靠自己脑补出具体含义?如果脑补不出来,那这段就是必要的论证肉,不是赘肉。不要只看"话题字面上偏不偏",要看"这段话在服务哪个论点"
---
实战案例
案例:「小红书被告了」逐字稿(2026-04-09)
**🟡 问题 1:第 5 段第 46 行,口播绕**
> 原文:「你就会进入另外一个类似叫商家流量池的一个区间」
**问题**:「另外一个类似叫……的一个区间」连续两个「一个」,念起来会卡。而且「商家流量池」是术语,观众不一定懂。
**修复建议**: > 改为:「你就没什么流量了,也不是完全没有,但是会很差」 > 直接说结果,不引入概念。
---
**🟡 问题 2:第 7 段 → 第 8 段,缺过渡**
> 原文(第 7 段末尾):「所以接下来就是你违规引流,平台给你封号。」 > 原文(第 8 段开头):「然后接下来更有意思的事情就发生了」
**问题**:从"律师被封号"直接跳到"庭审发言",中间缺一个收束。观众还在消化"律师被封号"的信息,突然被拉到了庭审现场。
**修复建议**:把第 7 段末尾改为: > 「所以这个律师接下来被限流的遭遇,其实就是这套流程的标准结局。」 > 「标准结局」收住前面的分析,再打开新信息。
---
完成当前任务后直接结束。用户的请求超出本 Skill 的范围、任务完成后用户的材料里出现明确的后续需求,或用户询问下一步时,用一句话说明还需要哪种能力,不点名其他 Skill;当前环境已经安装 `/dbs` 时,补一句「可以输入 `/dbs`,由它匹配对应的 Skill」。
dbskill 是 dontbesilent 的中文 AI Skills 工具箱,包含商业判断、内容创作、行动决策、学习和知识管理等能力,可安装到支持 Skills 的 Agent 中使用 支持豆包、WorkBuddy、Claude Code、Codex 和其他兼容 Skills 的 Agent。项目方法资料从 16,152 条公开推文中筛选整理,包含 4,176 个结构化知识原子。作者:@dontbesilent 本次更新: /dbs 在当前对话中直接处理问题,按需组合或对照方法,并明确告知实际使用的
Other skills on dbs.
dbs-agent-migration
审计项目规则文件、识别真源、统一命名并生成桥接,把项目迁移成多端一致的 Agent 工作台。用户要求迁移 Claude Code、Codex、Grok、通用 Agents 或整理…
dbs-chatroom-austrian
由哈耶克、米塞斯与 Claude 从奥派经济学视角展开多角色讨论。用户要求进入奥派聊天室或用奥派分析问题时使用。
dbs-chatroom
根据话题推荐或接受用户指定的专家,模拟多角色对话并总结分歧。用户要求专家讨论、定向聊天室或继续当前讨论时使用;明确要求奥派聊天室时优先匹配专门的奥派讨论能力。

