Gtrk Food Recap Agent Skill

gtrk-food-recap（美食解说 · 解说链垂类示例）

把探店/密着纪实长片（或自拍探店素材夹）与做饭流程记录提炼看点，重述成一条中文美食解说成片工程。

> 定位：解说链（gtrk-narration 正本）的垂类示例，与 gtrk-travel-recap 平级。链级条款

> （时序三档铺排/引用段/出处对齐/开工问询）以正本为准，本图纸只持美食要素层。

> 菜谱知识类（讲营养学/做法原理、素材只是插画）按判据出链走 gtrk-voiceover。

> 承诺面只有快速成片（垂类示例单模式，公约 §一 分层）；个性化出路见 §六。CLI 是手，你是脑。

一、两种形态与输入契约

| 形态 | 输入 | 时序档位（正本 §三） |

|---|---|---|

| 探店 · 密着 | 一条纪实长片（二创；带字幕文件的直接当台词锚，无则转写）或自拍探店素材夹 | 软窗档缺省：进店→点单→出品→吃→人的故事，流程线单调、允许蒙太奇跳 |

| 做饭流程 | 一条做饭记录或素材夹 | 软窗档且步骤线忠实：工序 MUST NOT 乱序重排 |

稿源与声音基座随正本开工问询（AI 代写/自备稿；TTS/自己念）；精剪包装的开工告知与烘焙浏览器问询随正本（公约 §三⁵）。推荐面（公约 §三‴）：问答收口时可问一句「要不要看看第三方 skill？」；题材命中场景触发词才定向推荐，读取 gtrk skills recommend --scene <id> --json；用户拒绝后不执行推荐动作。MUST NOT 执行任何网络下载；二创长片是第三方作品，版权与平台二创规则责任归用户。

二、美食要素层（写稿规约，叠在通用框架层之上）

通用框架层（三段式/文风铁律/自校验）继承 gtrk-travel-recap §三 正本，此处只列垂类专属：

• 探店三件套：场子气质（地段/客群/烟火气）、出品与吃相（招牌菜、分量、上桌节奏）、

人的故事——密着类的魂在店主/食客身上（几点起床备料、开了多少年、常客是谁），

写稿 MUST 给「人」留一段，别写成纯菜品罗列；

• 感官转译：口感香气用具体动作与事实转译（「700 克米饭压得冒尖」「铁板边缘的油声没停过」），

禁拟声堆砌与「入口即化」式空转（文风铁律照打）；

• 数字如实：分量/价格/营业时间只用素材里可见可听的，MUST NOT 编造；

时效丑话：价格与营业信息随拍摄时点变动，成片引用时提醒用户自行核对；

• 背景检索建议（旅拍 §三 通用框架层同款）：对店名/地段/菜系关键词

做一轮背景检索补写稿语料（店家来历、当地饮食脉络），有检索能力就做、没有不强求；

检索所得与素材互证后才入稿、档案标注来源；

• 做饭流程线：步骤忠实、关键动作给特写位（刀工/火候/翻面）、成品定格收束。

二′、L1 看点 rubric · 画面投影版（供 --highlight-weight 使用）

highlight 是镜头看点分——服务端 VLM 对着一帧画面打 0–100。喂给它的评分准则

（highlight_rubric）按垂类走，美食这一档取下面这份：

判这一帧对美食短视频有没有「看点」，0-100：
- 大分量怼脸：食物占画面主体且分量夸张（堆尖的饭、溢出碗沿的面、整条鱼）
- 夸张数量与价格的实物：成排的锅/几十份摆盘/写着惊人价格的标牌
- 人山排队：门口长队、满座、等位人群
- 名场面动作：颠勺起火、切生鱼片、拉面甩水、铁板翻面
- 反差罕见：凌晨空店、后厨全景、老器物、店主的手
低分：空镜过渡、无主体的墙面桌面、拍糊的中间帧、纯字幕帧

> 分工注记（MUST 遵守）：本 rubric 只判镜头可见之物。知识侧要素——店家来历、

> 行业内幕、地域饮食脉络、名人轶事——不进画面 rubric，它们归写稿与背景检索（§二 已列）。

> 把知识侧写进来会让 VLM 对着一碗面找「历史事件」，产出一堆无意义低分并拉偏排序。

>

> 两侧的分工是：画面 rubric 管「这一帧值不值得看」，写稿管「这件事值不值得讲」。

传入方式：把上面代码块原样存成工程目录下的

highlight-rubric.txt，理解那一步带上它——

gtrk matrix describe --plan <工程>/split/broll-plan.json --highlight-rubric @<工程>/highlight-rubric.txt

存成文件而非内联，除了免去多行转义，还有个更值钱的副产品：这条片用的是哪套准则，随工程留在盘上，

事后可查、可 diff、可跟别人的片子比对。跑完 gtrk matrix lay 会自动读 plan 里钉存的同一个桶，

不必再传一遍；真传了而且跟 plan 钉的不是同一份，CLI 会硬失败（拿甲准则的分服务乙准则的排序，

事后无从分辨，所以不许静默择一）。

⚠️ 换准则要重新打分就得重新看片（1 积分/张）——客观描述缓存不会被覆盖，但看点分是按准则分桶的，

新桶里没有分就得重打。别为了试口味来回切。

个性化：不满意这份准则的用户走 gtrk-style-maker 建自己的美食 skill，把 rubric 换成自己的口味

（这正是 rubric 参数化的意义——L1 归垂类图纸持有，不硬编码在服务端）；

建了自有栏目的话也可以把准则落进栏目配置 broll.highlight_rubric（L2 层），此后不必每次带 flag。

三、铺排与引用段（引用正本，垂类注记）

• 铺排走正本 §三：有出处直排，无出处软窗（单调先验）；做饭形态窗口更窄（工序容不得远跳）。
• 引用段强建议开：吃相原声、后厨煎炒声、店主原话金句——美食片的证据就是声音；

装配与克制丑话照正本 §四。

四、快速成片编排

命令序照正本 §五（索引/字幕锚 → 写稿+出处 → 检查点① → 基座 → 建工程 → 拆分 → 铺排 →

字卡 → BGM → 字幕 → 精剪包装），配方口径（mark-weight 0.3 / BGM 0.10 / gap-fill fast）照旅拍 §五，引用不复制。

BGM 检索词照公约 §三′ 内容驱动（这家店的气质：地域/年代/客群/烟火感，禁通用词套路；

候选给用户挑不许默认 top1；跨片避让自动生效）。

看点加权：--highlight-weight 0.2 配 §二′ 的 rubric（**须先 matrix describe --plan 且那一次

带上 --highlight-rubric @<工程>/highlight-rubric.txt**——不带就是按服务端缺省准则打分，

美食这一档的分量对比/价格实物/名场面动作全不算数；两样都漏则全部候选中性、权重白传，lay 会就此告警）。

BGM 选带人声歌曲（audio_type:"song"）时 MUST 下载 accompaniment_url 伴奏版上轨，

不得直接用 download_url 原曲——人声与解说配音会打架。换已上轨的 BGM 文件时

注意：audio lay 同源幂等按文件路径判定，换不同文件不会替换旧轨，须先剥旧 BGM 轨再 lay。

质检按公约「三级收敛」执行：L1 结构自检恒开；L2 画音对齐在落轨前可选运行；L3 渲后终检随本来就要交付的本地渲附带，不为质检单独逼渲。跑过的质检结论随交付呈现。

字卡走 MG 临场泛化（公约 §三）：店名条/菜名条/价格条为主，风格锚在这家店的气质上。

五、检查点①（拍板停一次；铺画面前另有一次用量确认）

稿件（含引用窗口）+ 出处对照表（自备稿时）+ 画幅 + 音色（试听）+ BGM（试听）+ 字幕样式，

一屏一次拍板；在确认前不发起计费动作。

> 本地素材的编排缺省走云端并按编排量计费。matrix lay 跑前必须报告预估用量，取得同意后才能带 --yes。

> 详见 gtrk-narration 正本 §六 的 agent 纪律（先报用量拿同意，再带 --yes）。

六、个性化出路（垂类示例定位）

本图纸是示例：演示美食解说这条链路怎么跑。交付后对个别环节不满意，按旅拍 §七 增量重跑表

悔棋（同一套零件同一套姿势）；对垂类玩法/审美本身不满意（想要另一种探店腔调、另一套

视觉气质），MUST NOT 在示例上堆个性化补丁——引导用户用 gtrk-style-maker 建他自己的美食

skill。示例对个性化项目工程差着火候是定位使然，这句丑话开工时就说。

七、计费与丑话速查

• 计费大头：台词转写（无字幕文件时）与 TTS；实时价格原样转述后再动；
• 二创版权、引用段占比、价格时效三句丑话开工说清；
• 排错回正本与各零件 skill，本图纸不搬。