HyperFrames 能力菜单（Capability Menu）解析：一条菜单，三种读者，如何把全部能力装进一次视频创作
【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes
HyperFrames 的 skill 体系中有一份名为 Capability Menu 的清单，它用一张表回答了“一段视频里 HyperFrames 能做什么”，同时规定了三个不同的使用者——提案轮（pitch round）、意图层（intent layer）、伴随模式（companion mode）——各自如何引用它。读完本文，你能掌握这份菜单的完整 15 行能力定义（所有者 skill、入口命令、产出物）、跨 skill 借用能力时的npx hyperframes skills update规则、设计规格（frame.md）的三态询问策略，以及各能力背后真实脚本与文档的仓库位置。
一张清单，三种读者
原文档开篇点明这份菜单的消费方式：同一张表，服务三种读者。三者引用方式不同，但都指向同一份事实来源 capability-menu.md：
- 提案轮（pitch round）：在任何人把这张表当作菜单阅读之前，提案就先“说出”它。每个提案概念都会点名它所依赖的一到两个能力，措辞直接取自菜单的中间列（“Say it to the user as…”）——即“用户在概念内部体验到的那一行”。这是大多数用户第一次理解“自己可以期待什么”的方式。该流程的完整规则见 pitch-round.md：五个概念、采样门槛（至少两个概念的主观概率须低于 0.10，防止全部落在“中位数”上）、先全部展示再推荐一个等纪律都定义在那里。
- 意图层（intent layer）：即 intent-interview.md 的第 7 步。它从菜单中“推荐”——只推荐确认后的概念真正需要、而所选提案尚未点名的那一两行；当用户追问“还能做什么”时，才展示经路由过滤后的切片（route-filtered slice）。
/general-video伴随模式（companion mode）：用同一张表作为执行地图，扮演两个角色——触发清单（trigger list）：每一行的通俗说法，正是对话触碰到该行能力时的“主动提议时机”；以及每一遍（plan / sketch / build checkpoint）的升级通道（upgrade channel）：检查点可以附带一到两条可溯源的主动提议，指向用户正在看的素材。
这个设计的核心是原文档结尾的原则：Offer, don't unload（提议，而不是倾倒）。意图层只推荐确认后的概念自身所要求的一两行，每行用一句通俗语言表述、可回溯到 brief，并且只问一次；完整表格只给 companion 模式使用。
借用规则（Borrowing rule）：跨 skill 取能力前先安装
菜单里标记了“家工作流（home workflow）”的能力，其脚本和文档都住在那个工作流的 skill 目录里，而工作流 skill 是惰性安装的。原文档为此定了一条硬性规则：
在伸手去别的 skill 目录取能力之前，先用裸名（不带
/）执行npx hyperframes skills update <that-workflow>；解析安装后的 skill 目录，用绝对路径调用其脚本；当脚本接受项目根参数时显式传入；工作目录始终保持在项目根。
原文档特别强调：永远不要假设同级相对路径，例如../media-use或../music-to-video——项目可能位于任何位置。这条规则对应入口文档 SKILL.md 第 4 节的安装动作npx hyperframes skills update <workflow-name>，以及第 5 节“按需加载领域 skill”的映射表。
能力总表：Home → Entry → What you get
菜单最后一列的读法是家（owning skill）→ 入口（确切文档或命令）→ 产出物（artifact）。下面完整继承全部 15 行，并对每行补注了经仓库核实的确切文件路径。
| 能力 | 对用户这样说… | 家 → 入口 → 产出物 |
|---|---|---|
设计规格（frame.md）— 一个文件锁住色板、字体与版式气质，每一帧都遵守它（webdesign.md的视频优先姊妹版） | “一套视频设计系统——颜色和排版保持一致” | /hyperframes-creative→ design-spec.md（规格是什么 + 解析顺序）；预设：frame-presets/<name>/（随 skill 常装，浏览无需借用）；应用机制build-frame.mjs（家：/faceless-explainer、/product-launch-video，即 skills/faceless-explainer/scripts/build-frame.mjs 与 skills/product-launch-video/scripts/build-frame.mjs）→ 项目根下的frame.md。问法见下文The design ask一节 |
| 网站采集（Website capture）— 对真实站点的 headless-Chrome 爬取：截图、品牌 token、素材 | “我可以采集你的站点，用它的真实观感来构建” | CLI →npx hyperframes capture <URL> -o ./capture→capture/（截图、提取的 token / 文本 / 素材）；方法论（doctrine）：/product-launch-video |
| 节拍分析与音频响应式动效（Beat analysis & audio-reactive motion）— 一条音轨的确定性节拍 / 能量地图；剪辑落在网格上、元素随音乐脉动 | “如果有音乐，我可以按它的节拍剪片——并让元素随它动起来” | 节拍网格：/music-to-video→ analyze-beatgrid.py →audiomap.json（节拍、能量、段落）；元素响应：/hyperframes-creative→ audio-reactive.md + extract-audio-data.py |
| 动效蓝图（Motion blueprints）— 按节拍挑选的成熟场景形状（揭示、计数、图表、立体场景） | “每个场景都有一套经过验证的动效处理，而不是即兴发挥” | /hyperframes-animation→ blueprints-index.md + rules-index.md → 构建时按节拍读取的blueprint:id |
| 配音、音乐、音效、图片、logo、媒体处理— 解析后的媒体，加上来源感知的调色、特效、隐私处理、揭示方式与有据可依的叠加层 | “配音、音乐、音效、真实素材——并且把画面打磨或风格化以贴合叙事” | /media-use→ 确定性解析 / 操作工具 + media-treatments.md；shader 像素经hyperframes media-treatment持久化，可选叠加层来自 Registry，有限动效使用宿主 GSAP 时间线 |
| 生成式视频（Generative video）— AI 主持人口播脚本；静图变成会说话的片段；成品视频被译制成另一种语言 | “AI 主持人可以出镜念你的脚本；我可以让一张照片变成会说话的片段，或者给视频做译制” | /media-use→ operations.md § Generate: video（heygen video create/video-translate；符合条件时 OAuth 免费额度）→ 采纳进assets/的 mp4 片段 + manifest 记录 |
| 转录与字幕（Transcription & captions）— 逐词计时的转录；贴在成品视频上的风格化字幕皮肤 | “精准字幕，风格与全片匹配” | /media-use→ transcribe.mjs → 逐词计时转录；字幕机制captions.mjs（家：/faceless-explainer，即 skills/faceless-explainer/scripts/captions.mjs）→ 字幕轨 |
| 按转录剪片（Cut footage by its transcript）— 通过选句子而不是选时间码来裁切片段 | “我可以靠挑选要保留的句子来修剪你的片段” | /media-use→ transcript-cut.mjs → 修剪后的片段 + 更新后的转录 |
| 用户素材上的设计叠加（Designed overlays on user footage）— 与口播同步的动力学标题、下三分之一（lower-third）、数据标注 | “你自己的片段也能带上设计感标题和信息条，时机对准语音” | 整段诉求=/talking-head-recut路由——直接路由过去，不要重建；更大作品中的一个场景=/hyperframes-animation的 lower-third / callout 蓝图 +/talking-head-recut的安全区（safe-zone）思路 → 叠在素材轨上的叠加合成 |
| 真实地图场景（Real map scenes）— 带定位图钉、路线或航线的真实底图 | “涉及地点与旅程时——一张真正的地图，不是画出来的” | /motion-graphics→ locate.mjs（地理编码）+categories/maps/（含 bake-basemap.mjs）→ 确定性烘焙底图 + 定位图钉 |
| Figma 导入（Figma import）— 素材、品牌 token、组件、故事板帧作为运动状态读入 | “如果设计在 Figma 里，我可以直接从它构建” | /figma→ REST/CLI 导入（Motion / shader 走 MCP）→ 净化过的 SVG、var()绑定的品牌 token、帧即状态（frames-as-states） |
| Registry 块（Registry blocks）— 50+ 可安装的场景合成（数据图表、设备 mockup、引言卡片…） | “现成的场景，拿来就能重新调色” | /hyperframes-registry→npx hyperframes add <block>→ 已安装的场景子合成（接线方法：wiring-blocks.md） |
| 场景转场（Scene transitions）— 切、交叉溶解、擦除、场景间 WebGL shader 转场 | “一个场景如何交接给下一个——最高配是全 shader 擦除” | /hyperframes-animation→ transitions/overview.md 然后 transitions/catalog.md；组装transitions.mjs（家：/faceless-explainer，即 skills/faceless-explainer/scripts/transitions.mjs，skills/product-launch-video/scripts/transitions.mjs 同构）→ 注入 index 的转场交接 |
| 用户素材上时间线（User media on the timeline）— 用户自己的图片 / 片段被排进帧、织进画面 | “你自己的素材、截图或照片放进视频里” | 暂存（staging）stage-assets.mjs（家：/music-to-video、/product-launch-video，即 skills/music-to-video/scripts/stage-assets.mjs 与 skills/product-launch-video/scripts/stage-assets.mjs）；采纳（adoption）：/media-use--adopt→assets/内文件 + manifest 记录 |
| 发布到稳定链接（Publish to a stable link）— 成品放在默认私有的托管 URL 上；重新发布会更新同一链接 | “做完了我可以发布到稳定链接——默认私有，你要公开就说” | /hyperframes-cli→ preview-render.md（npx hyperframes publish）→ 显式可见性的稳定托管 URL |
从源码结构看，这份菜单并非纸面承诺：表中点名的脚本与文档在仓库中逐一存在且归属与菜单标注一致——例如analyze-beatgrid.py确在skills/music-to-video/scripts/，captions.mjs与transitions.mjs同时存在于faceless-explainer、pr-to-video、product-launch-video等多个叙事工作流目录中，印证了菜单“home → 借用”的分布模型。
深入两行能力：节拍网格与设计规格
节拍网格：从音轨到audiomap.json
菜单第三行的入口 analyze-beatgrid.py 是一个 Python 引擎，其文件头注释说明了它合并了六类分析：librosa 节拍跟踪得到的可靠 tempo + 节拍网格 + 强拍、16 分音符小节网格上的事件律动位置（强 / 弱 / 切分 / 脱格）、按频段划分的鼓件分类（kick / snare / hihat / perc）、特殊音频事件（riser / glitch / crash-impact / hard-stop 静默）、音频驱动的能量叙事（段落命名由 Music Reader 完成，而非固定 Intro/Build/Drop 模板），以及用于视觉规划的短语层与每段密度预算。脚本用法为：
python3 analyze-beatgrid.py track.mp3 -o audiomap.json python3 analyze-beatgrid.py track.mp3 --print # 同时打印可读摘要依赖 ffmpeg/ffprobe + librosa / numpy / soundfile。所谓“确定性”，指同一音轨重复运行产出同一份audiomap.json，这正对应 HyperFrames 全框架强调的 determinism 原则（参见 docs/concepts/determinism.mdx）。元素层面的“随音乐脉动”则走菜单第三行后半：/hyperframes-creative的 audio-reactive.md 与 extract-audio-data.py。
设计规格frame.md：三态询问
菜单第一行指向 design-spec.md，其中定义了：规格是YAML frontmatter（规范层，colors / typography / spacing / components 为机器可读真值，必须逐字引用、不得编造或取整）+ markdown 正文（语境层）；解析优先级为frame.md → design.md → DESIGN.md（读第一个存在的即可，frame.md恒为小写）；规格只在第 1 步加载一次，后续所有步骤消费已加载的规格。
菜单的The design ask一节把这一行定义为一个三态问题，而非讲解：
- 用户已经有规格（品牌规范、
frame.md、design.md）：把路径记入BRIEF.md§ Assets，工作流将其作为品牌真值读取（解析顺序仍见 design-spec.md）。 - 没有、但观感重要——展示，而不是报菜名：从已上架预设中挑 2–3 个观感匹配预设 / 语气 / 受众的（浏览 frame-presets/），并在浏览器中打开每个预设的
frame-presets/<name>/frame-showcase.html，让用户凭眼睛选，永远不要给用户一份名字清单。选择以style_preset落入BRIEF.md——这是一个带记忆偏好的键，下次运行它会作为带凭据（receipt）的推荐答案出现。在会采集真实站点的路由上，展示打开时要说句实话：showcase 穿的是预设自己的色板，站点的品牌色和字体会被重新混色（remix）到最终胜出的预设上——你选的是版式骨架，不是颜色——并提供替代方案：把选择推迟到采集之后，届时能拿着真实品牌来判断（这是一个声明过的 deferred ask；任何昂贵构建之前，sketch 遍都会展示混色后的真相）。 - 不在意——或没有上架预设匹配：不在意则不再追问，由工作流的设计步骤决定并说明理由；没有匹配则宣布design picker为 deferred ask——工作流的设计步骤会生成贴合其内容的 mood board 供选择（design-picker.md）；它需要一个项目和一个生成遍，因此永远不在意图对话内运行。
预设本体是 skills/hyperframes-creative/frame-presets/ 下的固定集合，仓库中现有biennale-yellow、blockframe、blue-professional、bold-poster、broadside、capsule、cartesian、code-editorial、cobalt-grid、coral、creative-mode、daisy-days、editorial-forest等目录，每个目录含FRAME.md（大写模板，采用时转为小写frame.md）、caption-skin.html与frame-showcase.html预览联系表——design-spec.md 明确后者只用于“看”，永不进入项目。应用预设到项目的机制脚本即build-frame.mjs，其家在 skills/faceless-explainer/scripts/build-frame.mjs、skills/product-launch-video/scripts/build-frame.mjs 与 skills/pr-to-video/scripts/build-frame.mjs。
流派透镜（Genre lenses）：叙事工作流的品味，可借用
菜单最后一节指出：叙事类工作流各自携带按流派调校过的设计参考——story-design.md（叙事原型与节拍）、visual-design.md（流派的观感）、motion-language.md+cut-catalog.md（动效与剪辑教义）。当 companion 或自由创作的作品神似某个流派时，在规划或构建之前先读那个工作流的透镜（遵守上文的借用规则）：
| 作品神似… | 借用自 |
|---|---|
| 产品宣传片 / 发布 / 站点展示 | /product-launch-video→references/ |
| 主题 / 机制 / 概念讲解 | /faceless-explainer→references/ |
| 代码变更讲解 | /pr-to-video→references/（代码帧再加code-vocabulary.md） |
motion-language.md与cut-catalog.md在三者之间几乎相同——从你已神似的那个流派取，或取/faceless-explainer的作为中性默认。原文档划出的一条红线是：借形状与品味，永不借机制（machinery）——那些脚本与目录规则属于它们各自的流水线；任何构建的通用后半段都住在 production-loop.md。
小结：为什么一张表值得三个消费端
Capability Menu 的价值不在行数量，而在它为“能力”同时提供了三种接口：对提案轮，它是中间列的措辞库（能力必须被包装进用户能想要的概念里才被点名）；对意图层，它是第 7 步的推荐来源（推荐的一两行必须可回溯到确认概念，能适合任何视频的提议直接淘汰，至多一条可标记为带成本说明的 challenger）；对 companion 模式，它是触发清单 + 升级通道（对话触碰到某行能力时主动提议，检查点附带一两条可溯源的升级）。而借用规则保证了跨 skill 取用时的确定性：先npx hyperframes skills update <workflow>、绝对路径调用、显式传项目根、不假设同级相对路径。这三重机制叠加，使 HyperFrames 的 agent 工作流在“少即是多”的提问纪律下，依然能按需触达从网站采集、节拍分析到 shader 转场、稳定链接发布的全部能力。
【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
