企业官网建设流程全解析

CLI-Anything 合成素材（Found-Footage）来源甄别实战：证据分级、sources.json 清单与 video_doctor 自动校验

【免费下载链接】CLI-Anything"CLI-Anything: Making ALL Software Agent-Native" -- CLI-Hub: https://clianything.cc/项目地址: https://gitcode.com/GitHub_Trending/cl/CLI-Anything

本文以 CLI-Anything 仓库cli-hub-matrix/video-creation矩阵技能体系下的参考模块 source-triage.md 为主体，系统讲解"剪辑互联网素材、公共领域片段、平台来源媒体或具名场景"时必须执行的来源甄别（Source Triage）方法论：从三级证据等级、sources.json/music_sources.json强制字段清单、源音频角色分类，到video_doctor.py的 probe / frames / sources 子命令工作流、拒用清单与联系表纪律。读完本文，你可以为任何一部依赖网络素材的剪辑建立"可下载 ≠ 可用"的证据台账，并在进入时间线之前自动排查缺失出处、弱证据、低质量、缺音频角色与高风险混音策略等问题。

甄别在视频矩阵中的位置：为什么必须先于剪辑

在 CLI-Anything 的视频创作矩阵中，video-creation/SKILL.md 将视频制作拆成可组合的能力（capabilities）：video.search、video.download、media.analyze、sound.design、text.caption、composite.assemble等，并以"配方"（recipe）的方式按需组合。其中found-footage-montage配方专门处理"从互联网下载片段、策展后再剪辑"的场景。

source-triage 参考模块正是这条链路上的"闸门"：

• 在video.search能力中，SKILL.md 明确要求：凡交付物是合成素材（found-footage）或涉及"平台来源"声明，必须先阅读本参考模块，并把每个候选素材分类为"直接平台来源 / 可验证的平台来源转存 / 弱镜像"；
• 在media.analyze能力的 found-footage gate 中，SKILL.md 再次要求："不要因为素材下载成功就使用它"——拒绝清单直接引用本参考模块；
• 矩阵在"Known gaps"中如实声明rights.provenance（自动许可证 / TOS / 出处校验器）目前是缺口，其变通方案就是：手工把 URL、创作者、许可证、用途、署名与传输证据写进sources.json/music_sources.json，并按本模块的证据等级分级。

也就是说，source-triage 不是锦上添花的质量建议，而是矩阵明确承认"缺乏自动化权利校验"之后，Agent 需要依赖的人工纪律与证据格式。

一、三级证据等级与授权边界

甄别的第一步，是在剪辑之前给每个来源定性。原文档给出了三级证据等级，下表完整继承其含义，并补充了各等级在实际工作流中的使用建议：

与证据分级同等重要的是一条红线原则，原文档用一句话概括："Downloadability is not permission."（可下载不等于已授权）。具体约束包括：

• 不得绕过 DRM、付费墙、登录限制或访问控制；
• 仅当用户已获得访问授权时，才允许使用 cookie；
• 许可证或用户授权不明时，先询问再决定是否用于交付物（SKILL.md 的video.search与music.search能力中反复强调同一原则）。

这一原则在代码层面也被体现为甄别信号：sources子命令会把"缺少 platform/source URL"与"缺少 evidence_level"作为source_provenance信号单独列出（见 video_doctor.py 中sources_doctor的检查逻辑），因为出处证据本身就是分类的前提。

二、sources.json 强制字段清单：一个来源一个对象

甄别的载体是结构化清单sources.json。原文档规定：每个来源对应一个 JSON 对象，字段覆盖来源身份、下载命令、本地文件、探针（probe）结果、选中区间、音频属性与权利备注。下面完整复刻原文档模板并逐字段注释：

{ "id": "source_short_name", "platform_url": "https://...", "transport_url": "https://...", "evidence_level": "direct-platform|verified-transport|weak-mirror", "download_command": "yt-dlp ...", "cookie_file": "path or null", "local_file": "sources/source_short_name.mp4", "probe": { "duration": 123.45, "width": 1920, "height": 1080, "fps": "30000/1001", "video_bitrate": 8000000, "audio_bitrate": 160000 }, "selected_ranges": [ { "start": 12.3, "end": 18.8, "role": "setup|reveal|impact|contrast|proof|payoff", "audio_role": "silent_or_mute|ambience_keep|dialogue_keep|music_only|mixed_music_speech|needs_separation", "source_music_present": "none|light|dominant|unknown", "speech_needed": false, "overlap_policy": "mute_source|keep_ambience_low|source_dialogue_foreground|source_music_only|duck_new_music|separate_vocals|reject_range", "separation_tool": "none|demucs|spleeter|uvr|api", "quality_notes": "why this range survives triage", "risk": "watermark/source subtitle/soft crop/etc." } ], "creator": "name if known", "license": "license or unknown", "rights_notes": "authorization/attribution/caveat", "quality_caveat": "none or specific caveat" }

各字段的实战含义：

• id/local_file：短名需与落盘文件命名保持一致（如sources/source_short_name.mp4）。甄别工具会用id标识信号来源，并在本地文件缺失时给出强信号（source_manifest）；
• platform_url/transport_url：平台 URL 与"实际下载通道"分离记录。前者证明"声称的出处"，后者回答"到底从哪里拿到"。只有 transport_url 而无 platform_url 时，doctor 会提示source_provenance信号；
• evidence_level：即上一节三级证据等级，缺失该字段会被 doctor 标记；
• download_command/cookie_file：可复现的下载命令与授权 cookie 路径（无授权时填null），保证台账可回溯；
• probe：媒体事实探针。注意fps用有理数串表示（如"30000/1001"），video_doctor.py的parse_rate()会把"30000/1001"解析为约 29.97；实际执行probe子命令可自动生成 duration / width / height / bitrate 等事实；
• selected_ranges[]：甄别后真正入选的区间集合，也是剪辑与混音的直接依据（详见下文）；
• creator/license/rights_notes/quality_caveat：署名、许可证、授权与质量让步记录——这是矩阵在rights.provenance缺口下唯一可依赖的人工权利台账。

原文档同时规定：音乐来源需在music_sources.json中记录等价的细节字段（URL、创作者、许可证、上传者、版本说明、权利/署名等），由music.search/music.download能力负责维护。

音频字段的触发条件

音频相关字段并不是永远必填。原文档给出的规则是：当一个选中区间带有音轨、且成片实际使用任何源声音时，才必须分类源音频。据此，"先听清素材里有什么声音，再去混音"被前置到甄别阶段，而不是留到 sound design 阶段才发现冲突。

三、源音频角色分类：把"混音冲突"消灭在选片阶段

对于每一段要进入成片的源声音，原文档要求在剪辑前完成六类角色判定。下表完整列出其语义与处理决策：

与角色分类配套的还有三组字段：

• source_music_present：none | light | dominant | unknown，描述源音乐在区间内的强弱；
• speech_needed：布尔值，标明该区间是否需要源人声；
• overlap_policy：覆盖策略枚举mute_source | keep_ambience_low | source_dialogue_foreground | source_music_only | duck_new_music | separate_vocals | reject_range；
• separation_tool：none | demucs | spleeter | uvr | api，当角色是混合音或需要分离时必须给出具体工具，否则 doctor 会给出强信号。

原文档还特别强调一条容易踩坑的纪律：如果源音频仅用于"真实性"氛围，必须证明它就是环境声；绝不要把说话声/音乐串音含糊地标注为"texture"（质感）。这一条在工具实现里被编码成两组成语料：SOURCE_AUDIO_CONFLICT_TERMS（如under the music、source texture、retain all source audio）被视作冲突描述，SOURCE_AUDIO_RESOLUTION_TERMS（如mute、duck、separate、demucs、spleeter、uvr、source-only）被视作已解决描述——凡"提到冲突却没有对应解决用语"的区间都会被source_audio_overlap信号点名（定义见 video_doctor.py）。

当角色为dialogue_keep/music_only/mixed_music_speech/needs_separation（即"前景性声音"）却没有overlap_policy时，doctor 会报出risky_audio_policy；当角色是mixed_music_speech/needs_separation却没有分离工具、也没有任何解决用语时，会升级为强信号，要求你"分离、把源人声当前景、静音或换更干净的区间，然后再去加旁白/新音乐层"。

四、甄别工作流：probe → 联系表 → sources doctor → 人工裁决

原文档给出的甄别工作流共七步，可直接照做：

1. 逐源探针（在细看素材之前先获得媒体事实）：

python cli-hub-matrix/video-creation/scripts/video_doctor.py probe sources/source.mp4

probe子命令用ffprobe汇总时长、分辨率、帧率、码率、音视频流等事实（video_doctor.py 中的probe_doctor），加--raw还可输出完整 ffprobe JSON。它的作用是把"文件是好的"这种主观印象替换成可写入probe字段的客观数字。

2. 生成源素材概览联系表（contact sheet）：

python cli-hub-matrix/video-creation/scripts/video_doctor.py frames sources/source.mp4 review/source_name

frames子命令会在输出目录生成first.jpg/middle.jpg/last.jpg、全片抽样联系表（默认每 2 秒一帧，5×5 拼贴）、末 10 秒联系表以及"终幕高密度联系表"（默认取全片后 20% 段，可用--final-act-fraction调整），并附带画面感知多样性统计（video_doctor.py 的frames_doctor）。这是后续判断"静态镜头、卡片、硬字幕、水印"的视觉底稿。

3. 起草sources.json后运行来源医生：

python cli-hub-matrix/video-creation/scripts/video_doctor.py sources sources.json --root .

sources_doctor会逐一检查清单中的每个条目（video_doctor.py 中sources_doctor），产出结构化信号。

4. 阅读医生信号，作为深入调查的提示词。原文档明确：doctor 不是权利核验器，它只是调查提示——它检查的是"证据是否缺失、是否矛盾、是否自洽"，而非"你是否有权使用"。

5. 给可能可用的区间标注叙事角色。原文档规定：没有角色的区间，不构成入选素材（a range without a role is not selected footage）。角色的意义可参见 story-structure-audio.md 中"每个片段都要有叙事职责（setup / reveal / escalation / contrast / proof / impact / payoff）"的装配规则，并与 SKILL.md 的 assembly discipline 保持一致。

6. 为选中区间或高密度动作段生成联系表。

7. 在进入时间线之前拒绝坏区间，不要等问题留到调色、裁剪、字幕或 NLE 特效阶段去"补救"。

sources doctor 到底检查什么

把工具实现与文档信号类别对应起来，sources子命令实际执行的核查包括（对应sources_doctor中的检查分支）：

报告本身会给出signals数组、agent_instruction与逐条investigate建议；加--json可输出机器可读 JSON。正如模块与工具注释反复强调的：报告是证据与调查信号，不是 pass/fail 判决（sources_doctor的agent_instruction原文即 "Use this as a provenance and source-selection investigation, not as a license verdict"）。

甄别阶段之后：音频医生的复核入口

甄别阶段填好的音频角色不会就此沉睡。在quality.review阶段运行音频医生时，可以把这些台账直接喂回去做重叠复核（video_doctor.py 的audio_doctor）：

python cli-hub-matrix/video-creation/scripts/video_doctor.py audio final.mp4 qc/audio \ --sources-manifest sources.json \ --music-manifest music_sources.json \ --sound-design sound_design.md

它会从 manifest 中读取audio_role、overlap_policy与时间窗，在声明的重叠窗口自动导出 WAV 片段供人工试听，并提示"叠了两层音乐床、源评论压在新闻旁白下、标称环境声其实是说话声/音乐声"等典型事故。这正是"甄别阶段分类 → 混音阶段自动复核"的闭环价值：好台账能让最终质检自动定位可疑的混音窗口。

五、硬字幕、台标与平台 UI：记录风险与缓解措施

当源素材带有硬编码字幕、广播图形、水印或平台 UI时，原文档要求在选中区间中记录风险与缓解方式：安全区放置（safe-zone placement）、裁剪（crop）、遮罩/模糊（mask/blur）、替换（replacement），或写清"可接受"的书面理由。source doctor 会专门标记"提到文本类风险却缺少缓解备注"的区间（即source_text_occupancy信号）。

工具把这一条具体化了：SOURCE_TEXT_TERMS词表覆盖hardcoded subtitle、source subtitle、burned subtitles、broadcast graphic、lower third、ticker、watermark、platform ui、logo bug、chinese subtitle、caption collision等；SOURCE_TEXT_MITIGATION_TERMS词表覆盖safe zone、crop、mask、blur、replace、avoid、upper、side、acceptable、intentional等。若风险描述命中前者而未命中后者，就会产生未缓解信号，提示你去补上明确处理方案。这一机制也呼应了 captions.md 中"不要把作者字幕叠在源字幕之上"的字幕纪律。

六、拒用清单：这些区间直接拒绝或裁剪/遮罩

原文档给出了一份可直接抄录进工作流 SOP 的拒用清单。对以下情况，应拒绝对应区间，或裁剪/遮罩（下表整理为"症状 → 处理取向"）：

这份清单与 SKILL.mdmedia.analyze的 found-footage gate 一一呼应：扫描倒计时卡、片尾、硬字幕、水印、大号排名数字与来源标题卡，并对低分辨率、静态、重复、卡片堆砌、字幕主导或跑题的素材执行同样的拒绝/裁剪/遮罩策略。

七、联系表纪律与报告可追溯性

对于合成素材剪辑，原文档要求在review/目录（或同级目录）持续维护四类联系表：

1. 每个原始源一份概览表；
2. 一份全部选中区间表；
3. 装配完成后一份最终使用区间表（final used-ranges）；
4. 对预告片 / 体育 / 音乐类剪辑，额外留一份高密度终幕表，取样尺寸要符合该类型的最终片段规格。

两条硬性纪律随之而来：

• 报告必须指名最终使用的确切源文件与区间（Reports must name the exact final source files and ranges used）；
• 如果某源在评审后被替换，必须重新生成联系表并同步更新 manifest，防止报告指向过期文件。

这条"精确终态路径"纪律在矩阵中是一贯的：render-doctor.md参考模块同样要求从最终路径重新生成帧、更新报告并扫描陈旧路径。甄别阶段的 manifest 与联系表若维护到位，后续 render doctor / audio doctor 的自动化检查才有可靠的事实底座。

小结：把甄别当成剪辑的第一道闸门

综合来看，source-triage 参考模块教给 Agent 的是一套可复制的工程纪律：

1. 分级：每个来源先归入"直接平台来源 / 可验证转存 / 弱镜像"三级，可下载不等于已授权；
2. 立台账：把所有证据写进sources.json/music_sources.json的结构化字段，补齐 URL、命令、probe、选中区间、角色、权利与质量让步；
3. 先探后看：probe先拿媒体事实，frames先生成联系表；
4. 机器初筛 + 人工裁决：sources子命令把缺失出处、陈旧文件、弱区间、低质量、缺音频角色、风险重叠策略等问题变成调查信号——但最终裁决权在阅读证据的人/Agent 手里，doctor 永不代行"是否可用"的判断；
5. 前置拒绝：把坏区间挡在时间线之前，别让问题一路漏到调色、裁剪、字幕与 NLE 特效阶段；
6. 闭环复核：甄别产出的音频角色台账，在 final quality review 阶段回喂给audio doctor，自动定位源音频与新音乐/旁白的重叠窗口。

这套流程的关键输入文件与工具都可以在当前仓库直接查阅与运行：方法全文见 source-triage.md，能力上下文见 video-creation/SKILL.md，甄别、探针、联系表与音频复核的自动化工具有 video_doctor.py（probe/frames/sources/audio等子命令），叙事角色与装配规则可对照 story-structure-audio.md 与 sound-design.md。

【免费下载链接】CLI-Anything"CLI-Anything: Making ALL Software Agent-Native" -- CLI-Hub: https://clianything.cc/项目地址: https://gitcode.com/GitHub_Trending/cl/CLI-Anything