Content Remix

内容二创

把“这个爆款为什么成立”迁移成“泊舟凭什么能讲这件事”。二创不是同义改写，也不是把原稿换几个名词，而是保留功能机制、替换事实来源、重新确定内容承诺并按平台原生组织。

必读与调用

每次运行先读：

• references/remix-contract.md：输入合同、原创边界、平台适配器、输出格式和保存约定。
• <NOTES_VAULT>/我的设定/个人创作方向.md：判断是否符合长期定位。
• <NOTES_VAULT>/我的设定/受众画像.md：确定目标读者和真实需求。

生成成稿时，再读取并遵循：

• 已安装的 bozhou-writing-style Skill 及其要求的动态偏好。
• content-angle：用户没有给出明确新角度时，先确定区别于原内容的角度。
• hook-writing：生成目标平台标题、封面文案或前三秒钩子时使用。

边界与路由

• 只消费已经选定、已经拆解的样本。只有原链接、原文或逐字稿时，先交给 viral-video-benchmark 完成判级、证据化八部分拆解和入库；本 Skill 不跳过上游门禁。
• 正式爆款笔记的 analysis_status 必须是 current；limited 只允许迁移未受缺失证据影响的机制，并明确降低置信度；stale 必须先重新拆解。
• 八部分拆解至少要有 可复用点、不能照搬 和 本账号适配。缺少任一部分时不生成可发布草稿。
• 找新选题用 topic-extract，判断值不值得做用 topic-priority，普通改稿用对应写作或润色 Skill，发布后复盘用 creator-data-review。
• 本 Skill 只生成二创方案或内部草稿，不发布、不登记 publication、不上传图片、不写飞书、不采集后台数据。

工作流

1. 锁定样本与目标

确认唯一的爆款拆解笔记、platform + post_id、evidence_version、analysis_version、关联母题、目标平台和目标形式。标题不能充当样本身份。

多个样本或多个母题都可能匹配时，列出候选与证据，让用户选择；确认前零写入。一次二创只设一个主对标，其他样本只能作为补充证据。

目标平台未明确时：

• 上下文能唯一推出平台时直接使用；
• 无法唯一推出时先交付二创迁移卡，不同时生成多个平台成稿；
• 小红书默认以图文为主路径，小红书视频只在用户明确指定时生成。

2. 提炼一个主机制

从八部分拆解中选择一个最值得迁移、且本账号具备事实条件的主机制。把它写成与原句无关的功能链，例如：

圈定人群 → 结果前置制造信息差 → 过程证据建立信任 → 方法清单形成收藏理由 → 行动指令承接需求

同时记录：

• benchmark_id = {platform}:{post_id}；
• mechanism_id = {benchmark_id}#{简短机制名}；
• mechanism_version = {analysis_version}；
• 该机制需要哪些一手事实才能成立；
• 发布后什么表现会支持或推翻迁移判断。

不要因为样本数据好，就假定其中每一个表达都有效。观察、传播假设和只能确认相关的指标必须继续分开。

3. 建立原创边界

逐项完成四栏迁移：

1. 保留功能：用户需求、钩子功能、信任功能、信息推进和行动功能。
2. 删除来源表达：原句、特色比喻、镜头组合、页面设计、叙事顺序和高度可识别的表达。
3. 禁止借用事实：原作者身份、经历、客户、收入、结果、评价、数据和素材。
4. 注入本账号内容：泊舟自己的经历、项目、截图、流程、判断、失败和产品连接。

出现下面任一情况时，判定原创距离不够，重新构思：

• 标题或钩子只是替换名词；
• 段落、卡片或镜头与原内容逐段一一对应；
• 沿用同一案例、数字、结果承诺或独特比喻；
• 结论与原内容相同，只有语气变化；
• 去掉来源后，剩下的仍能明显反推出原稿表达。

4. 映射一手素材

沿关联选题的 materials、用户指定文件和相关笔记寻找素材。每个“我做过 / 我发现 / 我的客户 / 我的数据 / 我的结果”都必须能回到用户提供的信息或本地来源。

至少具备以下两项，才生成无占位符的完整草稿：

• 一个只有泊舟能提供的一手事实、过程、演示或失败；
• 一个明确属于泊舟的判断，并能说明它与原内容的区别。

素材不足时不得编造。只输出“可迁移机制 + 素材缺口 + 建议补证方式”，或在用户明确接受时生成带 [待补：真实事实] 的内部骨架，并标记“不可发布”。

5. 重新确定内容承诺

先用一句话写清：

• 原内容给谁什么承诺；
• 泊舟的新内容给谁什么不同承诺；
• 新承诺由哪条一手事实支撑。

用户没有指定角度时调用 content-angle。新角度不能只靠反义、夸张或改标题制造差异；它必须改变观察位置、核心判断、事实来源或读者所得中的至少一项。

6. 按平台独立生产

严格使用 references/remix-contract.md 对应的平台适配器：

• 小红书图文（主路径）：重新设计搜索/点击承诺、标题、封面、完整图文正文、收藏理由、评论问题和可选卡片页规划。
• 抖音视频：重新设计前三秒口播与画面、信息推进、证据出现位置、完整口播、屏幕字、画面提示和结尾动作。
• 小红书视频（辅助路径）：保留小红书的搜索、封面、收藏、信任与产品承接逻辑，再增加前五秒和时间推进。

同一机制做多个平台时，从迁移卡分别重写；禁止先写一篇长文再机械压缩成视频，也禁止把抖音逐字稿直接切成小红书卡片。

7. 过发布前质量门

逐项检查：

• 一手事实和数字都有来源，没有把原作者事实改成第一人称；
• 新承诺、开头、案例、结构和结论至少有三处实质差异；
• 标题和钩子兑现正文，不借爆款结果做虚假承诺；
• 平台结构成立，不混用小红书与抖音模板；
• falsifiable_statement 只描述本次机制迁移假设，不承诺必爆；
• 草稿符合泊舟最新写作偏好，且人工最终确认事实、隐私、品牌语气和公开边界。

未通过时先修复；缺真实材料时保持“不可发布”，不要用流畅文案掩盖证据缺口。

8. 保存与交接

用户只问“怎么二创 / 给方案”时，返回迁移卡，不写文件。用户明确要求“写成 / 做成 / 生成草稿”时，按 vault 约定保存：

• 小红书图文：创作/图文/；
• 抖音或小红书视频脚本/逐字稿：创作/视频/；
• 工程代码、图片、音频和渲染产物不写入上述目录。

输出 frontmatter 必须保留 source_benchmark、benchmark_id、evidence_version、analysis_version、mechanism_id、mechanism_version 和 falsifiable_statement，供后续预测与 T+3 复盘冻结版本。关联选题时写 topic，但不把完整二创方案写进母题。

用户之后说“准备发布 / 已经发布”时，交给 creator-data-review 建立具体 publication；由它默认调用 topic-priority 生成发布预测。本 Skill 不提前创建 publication 或预测播放量。

完成条件

• 主对标、版本和主机制唯一；
• 可保留机制与不可照搬内容分开；
• 至少一个一手事实和一个独立判断，或明确标记不可发布；
• 新稿不是原稿的逐段映射；
• 平台输出符合对应适配器；
• 保存的草稿带完整来源和可证伪机制字段；
• 没有自动发布、登记或采集数据。