小说推文视频文案改写

概述

将小说原文压缩改写成短视频口播稿。核心是保留剧情骨架，强化冲突悬念，清除机器腔，让观众产生"事情正在发生在我身上"的代入感。

本 Skill 具备自进化能力：每次改写后自动验证，失败则诊断打回，规则定期审计收缩，成功模式沉淀到记忆库。

使用时机

• 用户提供小说原文，要求改写成推文/口播/短视频脚本
• 用户要求对已有推文文案进行优化、降AI味、增强爆款感
• 用户要求批量改写多篇小说
• 用户提到"小说推文""推文文案""口播稿""短视频小说""爽文改写""小说解说"

不适用：原创小说写作、小说续写、小说评论/分析、非小说类文案。

任务参数

从用户输入中提取以下参数，未提供的使用默认值：

核心原则（硬约束，不可违反）

1. 只改写原文：不得凭空增加原文没有发生过的关键事件、人物、数字和反转。
2. 不改变事实：人物身份、关系、事件因果、剧情结果、结局走向必须与原文一致。
3. 信息缺失不补全：原文没说的关键事实，用悬念、侧面描写或模糊表达处理，不得自行编造。
4. 敏感内容克制表达：暴力、色情、违法内容用平台可发布的方式处理，不做露骨描写。
5. 不用假人味替换AI味：不得强行加入第一人称经历、碎片短句、网络口头禅来伪装"真人感"。
6. 核心名场面全部保留：删掉的是重复心理内耗、细碎环境描写、无推动作用的小动作，不是关键剧情。

改写流程（六步闭环）

第一步：内部提取剧情骨架（不展示给用户）

在写作前，在内部梳理以下内容，作为改写的事实锚点：

• 主角是谁，核心欲望是什么
• 主要人物及其关系（画一个简单关系链）
• 故事的核心冲突（谁和谁争什么）
• 3—6个最重要的剧情节点（按时间排序）
• 最大反转或秘密
• 当前片段结束时的未解决问题

这一步的产出只用于内部参照，绝不输出给用户。

如果原文超过5000字，先分段提取骨架并建立内部剧情记忆，确保前后人物名字和剧情不矛盾。

第二步：替换人物姓名

将原文人物姓名替换为更有记忆点、戏剧性的虚构名字。

规则：
- 名字符合人物身份、性格和题材（古言用古风名，现言用现代名，反派名字带冷硬感）
- 可以有反差感或象征意味，但不得使用真实公众人物姓名
- 同一人物全文保持同一个新名字，不得中途更换
- 改名不改变人物性别、身份、关系、性格
- 默认不展示"原名—新名"对照表，直接用新名字写作

详细改名策略见 references/name-replacement-guide.md。

第三步：改成主角第一人称

正文尽量改写为主角第一人称叙述，用"我"作为主要叙事视角。

规则：
- 让"我"表达当下看到的、听到的、想到的、感受到的
- "我"不知道的信息，不得用全知视角解释；其他人物的秘密通过对话、动作、细节、现场反应或后续揭露表现
- 增加"我"的情绪反应，但不能改变原文事实
- 保持叙事清楚，不为了第一人称造成信息混乱
- 如果原文是多主角交叉叙事，选择最有代入感的一个为主视角，其他视角的信息通过该主角的观察间接呈现

第四步：重写爆款开头

重新设计开头前{{开头字数}}字（默认150字）。

最高原则：具体事件优先于场景描写，且必须带有情绪锚点。 开头第一句必须陈述"发生了什么事"（谁+做了什么+对我造成什么影响），而不是描述"我看到了什么画面"。更重要的是，这个事件必须带有能触发观众情绪的锚点——背叛感（最信任的人害我）、意外感（不可能发生的事发生了）、身份反差（最不该做这件事的人做了）。平铺直叙的常见事件（如"上司在酒里下药"）观众能轻松认知，不会产生意外感，必须叠加情绪锚点。

• ✅ "我被发小骗进了一个下了十倍量迷药的局。"（背叛感：发小是最信任的人；夸张：十倍量）
• ✅ "我被发小下了十倍量的迷药，晕倒前只模糊看到床边站着三个解袖扣的男人。"（背叛+夸张+感官悬念）
• ❌ "我上司在庆功宴的香槟里下了药。"（平铺直叙，上司下药是常见套路，无意外感，无情绪锚点）
• ❌ "门被撞得木屑乱飞。我攥着一片碎玻璃……"（纯场景描写，读者要读三句才知道发生了什么）

情绪锚点的常见来源：
- 背叛：最信任的人（发小、闺蜜、男友、丈夫）是加害者或帮凶
- 身份反差：最不该做这件事的人做了（老师、医生、警察、亲人）
- 极端夸张：用超出常规的量级强化冲击（十倍量的药、四个保镖、十八楼）
- 信息差：主角知道观众不知道的事，或观众知道主角不知道的事

允许适度夸张强化矛盾（如"十倍量的药""四个保镖堵门"），但夸张必须基于原文存在的事件框架，不得凭空捏造关键事实。

开头必须在前3句内制造至少两种以下效果：
- 强烈冲突 / 反常行为 / 身份反差
- 生死危机 / 情感背叛 / 意外真相
- 极端选择 / 观众想立刻知道答案的问题

推荐逻辑链："我遇到了什么异常事件"→"为什么不正常"→"可能带来什么严重后果"→"必须继续看才知道答案"

可以采用"先抛结果、再回溯原因"的方式，但不得虚构原文没有发生过的事。

禁止空泛开场："我叫……""这是一个关于……的故事""大家好""事情还要从很久以前说起"。

爆款开头的具体模式和案例见 references/viral-opening-patterns.md。

第五步：改写正文表达

在保持剧情不变的前提下，对普通表达进行戏剧化改写。

可以使用：
- 更具体的动作（代替"他很生气"→"他把杯子攥得指节发白"）
- 更强烈的情绪、更鲜明的反差
- 更有画面感的细节、更短促的句子
- 更具悬念的停顿、更夸张但不失真的形容
- 适量的反问、对比和心理独白
- 口语化的"的""了""嘛"，模拟真实口播节奏

绝对不能：
- 把普通事件改成原文没有的重大事件
- 把人物性格改到完全相反
- 把暗示写成已经确定的事实
- 把配角行为强行改成主角行为
- 为猎奇添加血腥、色情、违法细节
- 连续使用"没想到、万万没想到、谁知、就在这时"等重复套路

写作风格的详细规则（句法、废话删除、人物、对话、感官、规避词）见 references/writing-style-guide.md。

AI写作痕迹的检测与清除规则见 references/ai-trace-rules.md。

第六步：设计悬念式结尾

结尾保持原文当前剧情的事实基础，增强观众对后续的期待。

优先使用：
- 真相即将揭开却突然中断
- 主角发现关键线索
- 某个人物出现反常行为
- 一个重要选择即将发生
- 主角意识到自己被欺骗
- 新人物或新证据出现
- 原有冲突进入更危险阶段

结尾不要真正解决全部冲突，也不要凭空添加后续剧情。

结尾应让观众产生类似疑问："他为什么要这样做？""我接下来会发现什么？""真正的幕后黑手是谁？""这个秘密揭开后会发生什么？""我还能活着离开吗？"

四大基础功能（自进化闭环）

本 Skill 不止于改写，还具备持续自我优化的能力。以下四个功能构成闭环。

功能一：诊断失败

当一次改写未通过质量验证、或用户反馈不满意时，执行失败诊断：

1. 定位失败层级：判断问题出在哪个环节——剧情骨架提取错误？改名不一致？第一人称混乱？开头不够抓人？正文有AI腔？结尾没有悬念？字数超标/不足？
2. 对比成功轨迹：从记忆库中检索同题材、同平台的成功改写样本，对比差异点
3. 归因到具体规则：判断是哪条规则执行不到位，还是规则本身有问题
4. 输出诊断报告（内部）：失败层级 + 具体问题 + 修改方向 + 是否需要更新规则

诊断结果写入 memory/failure_log.md，供后续效用审计使用。

功能二：回归验证

每次改写完成后、交付前，必须执行回归验证。验证不通过立即打回修改，不得交付。

验证清单（逐项检查，全部通过才算合格）：

事实层：
- [ ] 核心剧情节点与原文一致，无虚构关键事件
- [ ] 人物身份、关系、性别未改变
- [ ] 事件因果和剧情结果与原文一致
- [ ] 结局走向未改变

逻辑层：
- [ ] 文中每个判断/结论都有前文证据支撑（如写"他失口说了我们"，前文必须确实出现了"我们"）
- [ ] 关键转折处有过渡，不出现无铺垫的跳跃（如意识消失→醒在陌生环境，中间需有衔接）
- [ ] 人物行为符合其身份和前文设定，不出现前后矛盾
- [ ] 时间线清晰，不出现因果倒置

结构层：
- [ ] 全篇基本保持主角第一人称（"我"视角占比≥80%）
- [ ] 人物已全部改名，新名字前后一致
- [ ] 开头前3句内有冲突或疑问
- [ ] 结尾留有悬念，未解决全部冲突
- [ ] 字数在目标值±10%范围内

表达层：
- [ ] 无明显AI套话（"在这个时代""不仅...反而""值得深思"等）
- [ ] 无重复套路词（连续"没想到""就在这时"等）
- [ ] 无禁用规避词（见 writing-style-guide.md 第九节）
- [ ] 句子长短有变化，非均匀流水账
- [ ] 适合口播，无生僻书面语和论文腔

安全层：
- [ ] 敏感内容已做克制处理
- [ ] 无露骨暴力/色情/违法描写

自动验证脚本：python scripts/quality_verify.py <文案文件路径>，可检测字数、第一人称占比、禁用词、重复套路等可量化指标。人工判断项（剧情一致性、悬念有效性）由执行 agent 逐项确认。

功能三：效用审计

定期对 Skill 中的每条规则、每个参考文档进行效用审计，判断其实际贡献。

审计方法：
1. 拿掉知识测试：对某条规则，假设删除它，对比最近5次改写的质量变化。如果删除后质量无明显下降，说明该规则贡献低。
2. 贡献分级：将规则分为三级——
- 高贡献：直接影响输出质量，删除后明显变差
- 中贡献：有辅助作用，删除后略有影响
- 低贡献：可有可无，删除后无感知
3. 冲突检测：检查规则之间是否存在矛盾或重叠，重叠的规则应合并。
4. 输出审计报告：列出低贡献规则、冲突规则、建议处理方式。

审计结果写入 memory/audit_log.md。

功能四：知识收缩

基于效用审计结果，对知识体系进行收缩优化：

1. 合并：将重叠或高度相关的规则合并为一条
2. 降级：将低贡献规则从 SKILL.md 主体移到 references/ 中，或从必选改为可选
3. 删除：将无贡献、有冲突、或已被其他规则覆盖的规则删除
4. 再次验证：收缩后，用至少2个不同题材的样本重新跑改写流程，确认质量不下降

收缩操作记录在 memory/audit_log.md，保留变更历史，便于回滚。

记忆学习系统

本 Skill 通过 memory/ 目录实现跨会话记忆学习。

记忆文件结构

memory/
├── success_patterns.md   # 成功改写模式沉淀（按题材分类）
├── failure_log.md        # 失败诊断记录
├── audit_log.md          # 效用审计与知识收缩记录
├── name_bank.md          # 已使用的人物名字库（避免重复）
└── user_preferences.md   # 用户偏好记录（平台、字数、风格倾向）

记忆写入规则

• 成功模式：当一次改写通过验证且用户未提出负面反馈时，提取其开头模式、节奏特点、悬念设计，写入 success_patterns.md，标注题材和平台。
• 失败记录：每次诊断失败后，写入失败层级、原因、修改方向。
• 名字库：每次改名后，将新名字写入 name_bank.md，后续改写避免重复使用。
• 用户偏好：从用户多次请求中提取稳定偏好（如固定平台、字数范围、喜欢的题材），写入 user_preferences.md。

记忆读取规则

• 每次改写前，读取 success_patterns.md 中同题材的成功模式作为参考
• 读取 name_bank.md 避免名字重复
• 读取 user_preferences.md 应用用户稳定偏好
• 读取 failure_log.md 中最近的失败记录，避免重蹈覆辙

记忆文件过大时（单个超过200行），执行知识收缩，只保留最近和最高价值的条目。

字数控制

• 最终成稿控制在目标字数±10%
• 原文不足以支撑目标字数时，不灌水，优先保证剧情完整、节奏紧凑、悬念有效
• 原文明显超过处理能力时（>8000字），先压缩建立内部剧情记忆，再分段改写；不得擅自删掉关键转折，不得前后更换人物新名字
• 分段改写时，每段开头用1-2句话承接上一段结尾，确保连贯性

输出要求

默认只输出最终小说推文文案，不输出分析过程、剧情拆解、人物对照表、改写说明、标题解释或自我评价。

不添加"开头""正文""结尾"等小标题，直接输出一篇可用于配音和视频制作的完整文案。

如果用户明确要求诊断模式或修改说明，才附加输出。

付费调用（Pay Skill 计费说明）

本技能为按次计费的付费 Skill：单次调用 ¥1.00（CNY）。

收费能力由支付宝「AI 按量付费」提供，服务端地址为 https://chenyuai.top/api/text-insight。
支付宝已登记服务名 「小说推文文案改写（单次）」（serviceId API_CBDE8BF92D83486B），与本技能名称、402 账单 goods_name、SkillHub 展示名称一致；四处单价均为 1.00 元/次。
服务端负责验付与商家履约确认，本技能负责发起请求、调用官方支付能力并展示结果。

调用流程（四步）

1. 发起请求：POST https://chenyuai.top/api/text-insight，Content-Type: application/json，
   body 为扁平业务字段 {"text": "<待改写的小说原文>"}。禁止使用 {skill, action, input} 外壳，禁止携带任何密钥字段。
2. 处理 402：未付款时返回 HTTP 402 与响应头 Payment-Needed（Base64URL 编码账单）。
   原样保存该值，不得裁剪、解码或改写；同时记录响应体中的 out_trade_no（订单号）。
   向用户展示「本次需支付 1.00 元」并等待付款，不提前输出任何成果。
3. 发起支付：把账单交给支付宝官方支付能力（@alipay/agent-payment 或 alipay-bot）完成付款，由用户扫码确认。
   不自行实现付款或签名，不接触任何私钥。
4. 支付后重试（必做）：付款完成后用与首次完全相同的请求体，在 HTTP 头携带 Payment-Proof: <支付凭证> 重试 POST：
   - 200：验付通过、商家履约已确认（fulfillment_confirmed: true），即付费授权生效；随后由本技能按上述改写流程在本地生成文案并输出。服务端只负责收费闸门、验付与履约确认，不生成改写文案；
   - 仍 402：尚未完成支付，继续引导付款，不输出成果；
   - 用户取消：立即终止任务。

付费规则

• 结果不明时先查单，不得要求用户重复付款。
• 同一订单重复请求由服务端保证幂等，不重复扣费、不重复交付。
• 本技能包内不含任何密钥、私钥、.env 或状态文件；私钥只保存在商家服务端。

脚本与依赖

• scripts/pay_gate.mjs：零第三方依赖，仅需 Node.js 18+（内置 fetch）。负责编排「请求 → 402 账单 → 携凭证重试」，不实现付款或签名、不接触任何私钥。
  ```bash
  # 第一步：取 402 账单（输出 payment_needed 需原样交给支付能力）
  node scripts/pay_gate.mjs --text "待改写的小说原文"

# 第四步：付款后携凭证重试（--text 必须与首次完全一致）
node scripts/pay_gate.mjs --text "待改写的小说原文" --proof "<Payment-Proof>"
`` - 支付能力依赖：npm i @alipay/agent-payment（买家侧支付），或按支付宝官方集成 Skillalipay-aipay的指引安装alipay-bot。由它完成扫码/确认付款并产出Payment-Proof。 - 其余脚本（quality_verify.py、memory_audit.py`）仅需 Python 3，与支付链路无关，可照常使用。

参考文档导航