- 路径重构:脚本创作 V1.0/Lite1.0 扁平化(去技能文件夹层),分镜技能迁移至 短视频提示词生成/V1.0,旧路径清理 - 输出边界铁律固化:创作流程规范.md 新增「交付物输出边界(通用铁律)」+ S9 输出模板新增「输出边界」块(验收口径=执行约束非输出内容) - 开场钩子铁律三层固化:00_开场/06_编导终审/S9 相关规则 + S5 预设钩子口径区分(前3秒=呈现窗口,3-7秒=开场段总时长) - 帮助文档:新增「从账号分析到脚本创作」跨技能章节(你这样问|我会做什么风格) - mcn-dou-analysis 内嵌副本:红线边界声明+人设卡术语更新(设定分析说明)
9.6 KiB
9.6 KiB
Case-02:商 K 包厢闺蜜打闹 · 路径 C v2 验证(已主动放弃)
注意:本 case 的工作流是「Agent 产出 prompt + 主理人手动在 Seedance 平台跑」,非 CLI 自动化。CLI 字段省略。
0. ⚠️ 状态:主理人已放弃
主理人 2026-05-13 早上反馈:"商 K 的放弃了"
放弃原因(推测):
- 商 K 场景本身合规风险偏高(夜场+紧身着装+多人打闹),即使在合规边界内表达,post-TNS 拦截率仍较高
- 主理人可能在跑 v2 时直接被平台拦截或效果不达预期且评估投入产出比不值
- 用户没有继续给出"想怎么改"的方向,是直接放弃路径而非要求 v3
因此本 case 不出 v3 改进版本。保留 v2 prompt 与设计记录作为"高合规风险场景的踩坑参考"。
1. 基础信息
- Case 编号:02
- 简称:商 K 包厢闺蜜打闹(朋友扑搂 × 笑得更失控)
- 图片来源:用户提供(CodeX 内 GPT Image 生成)
- 图片尺寸:9:16 竖版
- 执行日期:2026-05-12(v2 产出后主理人决定放弃)
- 迭代版本:v2(已放弃,无 v3)
2. 第 1 轮:读图分析(v2 字段必填)
| 字段 | 内容 |
|---|---|
| 主体 | 包厢内站立的年轻女孩,黑色短款拉链开衫+黑色短裤+网纹过膝袜+黑色短靴+黑色手表带,举手机自拍张大嘴灿烂大笑 |
| 当前画面氛围 | 商 K 包厢典型环境(皮质沙发+狼藉桌面+冰桶+绿色和品红霓虹),夜场后半段松弛欢乐 |
| 最有戏的元素 | 大笑+举手机+左下朋友的手已经在动作中(已有的物理预告) |
| 画质来源判定(v2) | 手机闪光夜场自拍(高位俯视自拍角度、霓虹强对比色温、夜场高 ISO 噪点) |
| 对应画质策略(v2) | 手机自拍录像质感、霓虹下传感器轻微过曝、夜场高 ISO 数码噪点、轻微鱼眼畸变、自动白平衡漂移、握持微抖 |
| 比例诊断 | 9:16 → 9:16(无需扩图) |
| 建议时长(v2) | 8 秒 |
| 推算理由(v2) | 小剧情=朋友扑搂动作 1s + 笑的子节拍 ≥2.5s + 延展 2s + 收束 1s;硬拉 15s 必中段编造导致衔接崩 |
| 平台合规风险(v2) | 中度 —— 短款上衣露腹+黑色短裤+网袜在夜场环境下属常见装扮但偏敏感;动作放大时若镜头角度低/身体局部特写可能触发 post-TNS;有 20-30% 拦截风险 |
| 风险检查 | 真人脸: AI 生成 ✅ / 文字水印: 无 ✅ / 清晰度: ✅ / 合规:中度 |
3. 时序角色询问
主理人的回复:首 最终采用:首帧(0-1.5s 严格锁定 @图片1 原构图) 理由:这张图最大特点是"动作正在发生中"——左下朋友的手已经伸出来、她已经在笑。作首帧让视频从原图状态自然延续到"打闹爆发",叙事最顺
4. Hook 候选与选定
候选 A:朋友扑搂 × 笑得更失控 ★★★★★
- 演化轨迹:0-1.5s 首帧锁定+BGM 已响 → 1.5-2.5s 朋友扑搂触发 → 2.5-5s 笑的三拍子节拍展开(眼角先松 0.8s/嘴角扬起 0.7s/露齿出声爆笑 1s) → 5-7s 延展+背景朋友走过 → 7-8s 朋友松手+女孩身体回正收束
- 传播因子:朋友突然扑过来=夜场聚会标志性瞬间+笑按子节拍真实展开+BGM 从 0 秒就在的连贯感
- 适用度:★★★★★
候选 B:朋友扑搂 × 反扑回去 ★★★★
- 演化轨迹:0-1.5s 首帧 → 1.5-2.5s 扑搂 → 2.5-4.5s 笑前半 → 4.5-6s 她反扑拍朋友肩膀 → 6-8s 双向打闹
- 传播因子:双向互动更平衡,姐妹感强
- 适用度:★★★★(双向动作崩面风险高)
主理人选定:A
5. 第 2 轮:v2 完整 Seedance 提示词
8秒商K包厢姐妹自拍打闹手机录像质感,9:16竖屏,@图片1为0-1.5秒首帧锁定。
画质:手机自拍录像,广角轻微鱼眼畸变、高ISO数码噪点、霓虹下传感器轻微过曝、白平衡漂移、握持微抖。非电影级非Cinematic。BGM电子舞曲低音鼓点从第0秒稳定贯穿全片,不可中断不可渐入不可中段才出现。环境音:朋友尖叫笑声、冰块碰撞、远处过道音乐回响。绿色和品红霓虹交替游走于墙面地面桌面。
0-1.5秒:@图片1为静态首帧(中近景略仰拍四分之三侧),女孩举手机自拍大笑姿态锁定原图,左下朋友手臂已在画面持续向腰侧伸近做物理预告,霓虹从绿过渡到品红,冰桶反光闪烁,女孩因BGM节拍身体极轻微节律摇晃。
1.5-2.5秒:朋友扑搂触发,左下朋友从腰侧搂住女孩戏谑打闹,背后另一女孩从右上探手扯她衣角协同捣蛋,女孩笑得更夸张身体被搂得右倾30度脚步不挪,右手本能向上举高。朋友动作严格限定搂腰拍肩不可过激。冰桶冰被带动跳起落桌发清脆碰撞声。
2.5-3.3秒:笑第一拍·眼角先松(0.8秒):眼角松开带笑意、呼吸因笑变急。
3.3-4秒:笑第二拍·嘴角扬起(0.7秒):嘴角咧开牙齿露出苹果肌推起、肩膀小幅抖动。
4-5秒:笑第三拍·露齿出声爆笑(1秒):露齿笑出声持续,肩膀中幅度抖动、头微后仰又收回,身体保持右倾30度。
5-7秒:延展(微Pull Back),背景深处另一朋友手举空酒杯走过画面边缘不靠近主体(仅作群演)。女孩从爆笑过渡到笑到岔气余韵,搂她的朋友松手退后半步分离,霓虹切纯品红。
7-8秒:收束,朋友完全松开退后女孩身体回正,笑未收住已过渡到带喘气余韵、左手抹笑出的眼泪、肩膀继续轻抖,最后0.3秒定格。音收束为哄笑余音+BGM鼓点继续不断。
光影:顶部暖黄主光+绿品红霓虹交替+冰桶散点光斑打下颌+酒水反光不规则光晕+霓虹下传感器轻微过曝。
风格锁定:非电影级非Cinematic;环境元素严格按原图服装按首帧锁定;多人物互动幅度严格搂腰拍肩不可摔倒倒地推出画面,背景路过朋友仅作群演;全程高位俯视手机自拍视角不可切低角度仰拍不可身体局部特写;BGM电子鼓点贯穿全片不可寂静不可渐入;笑必须在2.5秒内分三拍渐进完成不可瞬间跳变。禁止任何文字字幕、LOGO、酒标、水印。
字符数:935(≤ 2000 ✅)
自检 v2 字段:
- 风格总纲含画质来源关键词("手机自拍录像、广角轻微鱼眼畸变、霓虹下传感器轻微过曝")
- 现实类反应按子节拍展开(笑三拍:眼角先松 0.8s + 嘴角扬起 0.7s + 露齿出声爆笑 1s = 2.5s)
- 时序角色显式(首帧 0-1.5s)
- 时长 = 推算值 8s(非默认 15)
- BGM 贯穿声明(针对 v1 反馈"前半段没 BGM 第 10 秒才出现")
- 合规规避声明(高位俯视视角锁定、动作幅度限定搂腰拍肩范围)
6. 设计意图(v2)
- 前 2 秒生死线:原图本身高密度(大笑女孩+举手机+左下朋友的手+霓虹氛围+桌面狼藉)+ "BGM 已经在响"
- 核心 hook:1.5-2.5s 朋友扑搂触发 + 2.5-5s 笑的三拍物理时间常数展开
- 画质真实感:手机自拍录像 + 噪点 + 鱼眼畸变直接对应"图来自夜场手机自拍"
- BGM 贯穿全片:风格总纲就写"从第 0 秒稳定贯穿全片不可中断不可渐入不可中段才出现",三重声明
- 合规规避:高位俯视视角锁定+动作幅度限定搂腰拍肩+不可身体局部特写
- 时长服从内容:8s(非 15s)
7. v2 出片效果反馈(主理人 2026-05-13 早上反馈)
主理人原话:
商 K 的放弃了
主理人未给出具体出戏点——直接放弃路径而非要求 v3。
7.1 推测的放弃原因
| 可能原因 | 严重度 | 备注 |
|---|---|---|
| 被平台 post-TNS 拦截 | ❓ 待主理人确认 | 中度合规风险已预警 20-30% 拦截率 |
| 出片效果不达预期 | ❓ 待主理人确认 | 多人物打闹动作 + 笑子节拍对 AI 视频是高难度组合 |
| 投入产出比评估不值 | ❓ 推测 | 即使跑出来"姐妹打闹"内容传播性也比球场/演唱会窄 |
| 内容方向调整 | ❓ 推测 | 主理人可能临时不想再做夜场题材 |
7.2 v2 四原则验证(无法判定)
由于主理人未提供具体出片描述,v2 四原则在本 case 上的验证结果留空。
8. 无 v3 改进
主理人主动放弃本 case,不出 v3 版本。
9. 给主理人的反馈
- 本 case 是否值得保留作为典型 case:
- 作为"高合规风险场景的踩坑参考"保留 —— v2 prompt 中关于"中度合规风险的防御性声明模板"(视角锁定+接触范围+服装锁定+不可身体局部特写)值得作为以后类似场景的参考
- 不作为内容方向的典型 case —— 主理人已主动放弃
- 方法论改进建议:
- 第 1 轮合规风险预警必须更前置:v2 当前的合规风险评估在第 1 轮已经做了"中度警告",但没有让用户在投入产出比角度做选择。建议 v3 SKILL.md 在合规风险=中度时,主动询问用户:"这条 case 有 20-30% 拦截风险(约 X 积分浪费),你确定要跑吗?还是想换个相似但合规更低的场景?"
- "主动放弃"应作为合法的 case 收尾状态:当前 SKILL.md 假设用户都会跑完每个 case,但实际上"评估后放弃"也是正确选择。case 报告应支持"已放弃"状态字段
报告完成时间:2026-05-13 09:08 报告人:Claude(晚间执行 Agent · 用户工作流为"产 prompt + 主理人手动跑")