Agent Skills › yang0/handraw-style › couple-photo-orchestrator

couple-photo-orchestrator

GitHub

专业摄影方案编排技能,支持人像、婚纱等类型。通过时空方向筛选、妆发造型规划及Shot List生成,输出具有戏剧张力的专业级拍摄方案与图像提示词,实现从需求到视觉成品的自动化流程。

skills/couple-photo-orchestrator/skills/zongkong/SKILL.md yang0/handraw-style

Trigger Scenarios

用户提出个人写真、情侣照、婚纱照、全家福或Cosplay等拍摄需求 用户输入特定服装、地点、氛围或作品角色关键词

Install

npx skills add yang0/handraw-style --skill couple-photo-orchestrator -g -y
More Options

Non-standard path

npx skills add https://github.com/yang0/handraw-style/tree/master/skills/couple-photo-orchestrator/skills/zongkong -g -y

Use without installing

npx skills use yang0/handraw-style@couple-photo-orchestrator

指定 Agent (Claude Code)

npx skills add yang0/handraw-style --skill couple-photo-orchestrator -a claude-code -g -y

安装 repo 全部 skill

npx skills add yang0/handraw-style --all -g -y

预览 repo 内 skill

npx skills add yang0/handraw-style --list

SKILL.md

Frontmatter
{
    "name": "couple-photo-orchestrator",
    "version": "2.24.26",
    "language": "zh-CN",
    "description": "Orchestrates professional portrait, couple, wedding, family, cosplay, and themed photography planning from direction selection through Look, scene micro-zones, Shot List, and on-demand image generation."
}

couple-photo-orchestrator

1. Purpose

将用户从任意入口提出的人像拍摄需求,快速收敛为专业影楼 / Editorial 摄影方案。

支持:个人写真、私房、情侣、婚纱、亲子、全家福、古风/汉服/唐风、旗袍、新中式、民国、旅行、职业形象、Cosplay、主题创意等。

默认目标不是普通游客照、自拍、网红照或泛 AI 美女图,而是具有完整人物、造型、美术、动作、光线、色彩和构图关系的专业样片。

通用摄影关键词

  • 所有摄影拍摄类型均在可复制方案与最终生图提示词中原样加入:高级摄影师风格,创意构图,强烈的戏剧张力。
  • 个人、情侣、婚纱、亲子、全家福、古风、私房、职业、Cosplay 等类型,以及自主推荐、抽卡、八宫格、单张和放大优化均适用;不得省略或仅以同义词替代。
  • 通过机位、空间层次、光影和情绪落实关键词;继续遵守已确认的人物身份、服装、妆发、画幅及 Shot 动作约束。
  • 保持现有“先三方案选向 → 八宫格预览 → 按需单张/放大”的交付流程。

2. Source of Truth

执行前优先遵循根目录 CORE_REQUIREMENTS.md。 如本文件与 CORE_REQUIREMENTS.md 冲突,以核心需求最新版本为准。 每次修改:先更新 Core Requirements → 记录 Changelog → 再改 Skill。三者每次正式变更必须同步使用同一版本号。

3. Entry Behavior

本 Skill 是用户唯一入口。不要要求用户手动调用内部子模块,不向用户暴露内部编排。

用户可以从任何角度进入:

  • 拍摄类型:个人 / 情侣 / 婚纱 / 家庭
  • 服装:古风、旗袍、韩系、礼服、Cosplay
  • 地点:西湖、瑞士、海边、城市街头
  • 作品 / 角色:电影、电视剧、动漫、游戏
  • 氛围:甜蜜、抓拍、华丽、清冷、私房
  • 单品 / 道具 / 时间等

所有入口最终收敛为:方向候选(服装草案 → Editorial 发型师 → Editorial 化妆师)→ 用户选向/自动选向 → Look 继承展开 → 场景位点 → 姿势与情绪规划 → Share Card Compiler → Shot List / 按需出图。

4. Modes

MODE A|自主模式(默认,轻量逐步确认)

自主模式是默认执行状态,不是一个需要用户选择的菜单项。

Mode-selection Hard Gate

  • 禁止输出任何“请选择进入方式 / 方式 A 快速推荐 / 方式 B 抽卡 / 两种进入方式”之类的模式选择页。
  • 不得把自主模式称为“方式 A”,也不得把抽卡模式称为“方式 B”。
  • A / B / C 专属于首轮的三张候选方向卡,永远不能用作模式编号。
  • 用户回复 a / b / c 时大小写不敏感;只要上一轮存在尚未消费的 A/B/C 方向卡,就必须直接选择对应方向并继续完整方案,不得重新路由成某种模式。
  • 抽卡只由用户明确输入“抽卡”或清晰同义指令触发;不能把 B、b、2 推断成抽卡。

用户提出新主题后:

  1. 不做长串字段确认,也不先解释模式。
  2. 第一屏默认直接给 3 个方向卡:2 个现代现实世界著名景点 + 1 个穿越方向;若全家福/其他多人缺少人数、性别构成或关系结构,先执行一次人物结构确认 Gate,再立即给三张卡。
  3. 三张卡固定编号 A / B / C。
  4. 卡片末尾只用一句话告诉用户也可以回复“抽卡”。
  5. 用户回复 A / B / C,直接进入对应方向。
  6. A/B/C 展示前,每个方向已完成逐人正式发型与正式妆容;用户选中后直接继承该方向的妆发,输出完整 Look + 场景位点 + 姿势与情绪规划 + 默认 8 张 Shot List。
  7. 只有确实会改变结果的关键条件才继续确认;禁止逐字段问卷式追问。

MODE B|抽卡模式

用户明确说“抽卡”后:

  1. 不展示 3 张卡,不要求用户选方向。
  2. 系统自行随机选择一个符合用户原始需求的方向。
  3. 自动完成:方向 → 人物/关系 → 场景与逐人服装草案 → Editorial 发型师定稿 → Editorial 化妆师定稿 → Look 继承展开 → 姿势与情绪规划 → 道具 → 摄影基调 → Share Card Compiler → 8 张 Shot List → 8宫格预览出图。
  4. 中途不逐项确认;未指定项由系统合理补全。
  5. 自动选择的方向必须先通过 Few-shot Hard Gate 和当前主题去重 Gate;命中禁用方向就丢弃重抽。

5. Spacetime Direction Rules

首轮 3 个方向固定为:

2 个现代现实世界著名景点 + 1 个穿越方向

Generic-request Hard Gate

  • “情侣照 / 个人写真 / 婚纱照 / 全家福”等宽泛请求不会降低时空锚点要求。
  • 禁止输出“城市日常 / 自然系 / 高级影楼 / 甜感 / 电影感”这类纯风格卡作为一级方向;这些只能作为已确定时空方向里的二级视觉描述。
  • A/B 必须出现可识别的真实世界著名地点;C 必须出现明确古代时期+真实地点、未来现实地标,或已知作品+地点。
  • 首轮卡片固定使用 A/B/C,禁止改成 1/2/3。

Reality A / B

  • 必须是当代现实世界中真实存在、全球有辨识度的著名景点 / 地标 / 城市空间。
  • 两个现实方向优先跨国家 / 城市 / 地域,不要只是同一地点的近似变体。
  • 地点必须真正影响建筑、材质、气候、生活方式、服装适配和摄影语言。

Time-travel C

从以下三类任选其一:

  • Ancient:明确历史时期 + 真实著名地点;
  • Future:明确未来时代 + 可识别的现实城市 / 地标未来化版本;
  • Known Fiction:已知作品 + 明确世界 / 城市 / 地点。

Common

  • 三个方向必须首先确定明确的时空坐标,不能用抽象风格替代。
  • 禁止系统自行创造无出处的一级世界坐标,例如:蒸汽朋克空中小镇、未来东方城市、梦幻森林王国、赛博古城。
  • 用户自己明确提出原创世界时可以继承。
  • 三方向应拉开地域、世界观、人物身份、服装体系、色彩光线、空间结构和摄影语言。
  • 用户已明确限制时代 / 作品 / 地点时,用户条件优先;在可行范围内再保持 2 现实 + 1 穿越。
  • 每个方向必须能继续拆成至少 8 张有差异的照片。

6. Known-work Adaptation

引用影视、动漫、游戏、文学世界时:

  • 借用世界观、空间、时代和视觉语境。
  • 默认把用户设计成“进入该世界的人”。
  • 不直接让用户扮演原角色。
  • 不机械复制原角色服装或经典剧照。
  • 用户明确要求 Cosplay / 指定角色时,才进入角色复刻逻辑。

7. Few-shot Hard Isolation

few-shot 的唯一用途:示范结构、字段、长度、语气、交互。它不是创意来源,不是运行时推荐池。

Hard Gate

  • 系统推荐、重新推荐、换主题后的新推荐、抽卡自动选择,绝对不能与任何 few-shot 方向相同。
  • “相同”按语义锚点判断,不只比较标题字符串。以下任一情况命中即禁止:
    • 同一个“时代 + 真实地点”;
    • 同一个“作品 + 世界 / 城市 / 地点”;
    • 标题不同,但核心时空坐标实际相同。
  • 不得通过换标题、换身份、换服装、换妆发、换光线、换摄影语言来规避;只要核心时空/作品锚点相同,仍判定为 few-shot 冲突。
  • 正式输出前必须建立 few_shot_exclusion_set 并逐个校验候选。命中后:丢弃 → 重生成 → 再校验;禁止把冲突候选展示给用户。
  • 自主模式必须保证 A/B/C 三张卡全部通过 Hard Gate。
  • 抽卡模式自动选择的方向也必须通过 Hard Gate,之后才允许继续 Look、场景、Shot List 和出图。
  • 用户自己明确点名某个 few-shot 中的地点 / 作品 / 方向时,可按其明确要求执行;这不算系统推荐。

当前主题去重

used_spacetime_set = 当前主题已经推荐、抽到、自动选中或用户选中过的时空点

用户说“换一个 / 再来一版”时,从未出现且不在 few_shot_exclusion_set 的时空点生成。 如果用户条件过窄,应继续寻找新的合法锚点;不得因为候选不足而回退到 few-shot。

8. Direction-selection State

  • 输出 A/B/C 三张方向卡后,建立 pending_direction_cards = {A, B, C}。
  • 下一条用户消息若为 A / B / C(大小写不敏感),优先消费对应卡片并直接进入完整方案。
  • 消费后清空 pending_direction_cards,避免旧卡在后续误触发。
  • 在 pending_direction_cards 存在时,a 不得被解释为“自主模式 / 快速推荐”,b 不得被解释为“抽卡”。
  • 只有用户明确说“抽卡”才触发抽卡模式。

8.5 Participant Structure Gate

  • 情侣:默认 2 人、1 女 + 1 男;不为人数/性别加确认。
  • 全家福/其他多人:A/B/C 前必须已知总人数、性别构成、关系结构;缺失时一次性只问缺失项。
  • Gate 补齐后立即输出 A/B/C,不继续问卷。

9. First-turn Output Format

每个候选方向使用固定核心字段 + 动态逐人服装字段;人数越多,服装字段随人物数量增加。

格式必须紧凑:

  • 字段名和值同一行。
  • 使用中文冒号。
  • 字段之间不留空行。
  • 每项写短句,不写解释性长段落。
  • 三张卡之间可以留一行。

模板:

A|{方向名}

时空坐标:{明确时代+真实地点 / 已知作品+地点} 人物身份:{每个人在这个世界里的身份} 人物关系描述:{情侣/多人必填;关系结构、角色层级与互动基础} 核心场景:{3–5 个具体可拍空间} {人物标签/P01}服装:{该人物独立服装;情侣默认“女方服装”} {人物标签/P02}服装:{该人物独立服装;情侣默认“男方服装”} …逐人服装:{人数>2 时继续逐人展开,禁止合并为一个服装字段} {人物标签/P01}发型定稿:{Editorial 发型师的具体结果} {人物标签/P01}妆容定稿:{Editorial 化妆师的具体结果;女性默认白皙柔焦影楼精修} …逐人妆发:{所有人物分别输出;禁止合并} 色彩 / 光线:{主色关系 + 光源逻辑} 人物状态:{可执行动作/关系事件} 摄影语言:{景别、机位、构图、镜头观察方式}

B|...

同结构。

C|...

同结构。

结尾只做最小交互: 回 A / B / C,我直接继承该方向已定稿的服装+妆发,继续 Look+场景位点+姿势与情绪规划+8 张 Shot List;也可以回“抽卡”。

9.5 Relationship Description

  • 情侣与所有多人拍摄必须有独立“人物关系描述”,与人物身份分开。
  • 情侣默认 2 人、1 女 + 1 男,不额外询问性别;用户明确其他组合时覆盖默认。
  • 多人必须在方向卡前补齐总人数、性别构成和关系结构(只问缺失项)。
  • 人物关系描述作为后续 Pose & Emotion、接触拓扑、站位、视线网络和 Shot 事件的约束。

10. Outfit / Look

选中方向后,每一个出镜人物都必须单独设计服装。

每个人至少明确:

  • 单品 / 类型
  • 轮廓
  • 主色
  • 面料
  • 关键细节
  • 鞋履
  • 主要配饰
  • 必要时的外套 / 头饰 / 功能性配件

情侣 / 多人:

  • 从 A/B/C 方向卡阶段开始就逐人分字段设计服装,不能只写“情侣协调穿搭 / 全家统一浅色系”。
  • 情侣默认字段名为“女方服装 / 男方服装”;多人使用角色名或 P01/P02…,每个人独立一行。
  • 同时控制双方色彩、材质、正式度和轮廓关系。

题材约束:

  • 私房:高级时装化内景,不做普通家居睡衣感。
  • 婚纱:必须有仪式感、材质层次和完整轮廓。
  • 古风 / 汉服 / 唐风 / 旗袍 / 新中式 / 民国:结构、层次、时代逻辑正确,避免串代。
  • 避免廉价 Cosplay、塑料面料、普通淘宝影楼服感。

11. Scene / Micro Zone

不要只写“街头 / 古建筑 / 酒店 / 未来城市”。

场景必须具体到可拍位置,例如:

  • 门厅入口
  • 楼梯转角
  • 临窗座位
  • 拱廊尽头
  • 湖边平台
  • 石阶中段
  • 站台边缘

人物必须与空间发生关系,并能建立前景 / 中景 / 背景。

真实地点尊重当地建筑、气候、生活方式。 虚构地点保留作品的空间逻辑,可做摄影化改编。

道具只保留能触发动作或叙事的物件,不堆装饰。

12. Pose & Emotion Planning

在输出 Shot List 前必须先做姿势与情绪规划,但不要把它写成人体参数表。

每个 Shot 的规划层级: 动作意图 → 关键身体力学 → 人物关系/接触 → 情绪动机 → 景别适配

A. 动作意图

  • 先回答人物正在做什么、准备做什么或刚刚发生什么。
  • 姿势应该由事件自然产生,不先摆 Pose 再强行补故事。

B. 关键身体力学

  • 每张只写当前镜头真正影响姿势成立的 2–4 个关键力学信息。
  • 可按需要使用:脚位、前后脚关系、支撑脚/放松脚、脚尖/膝盖方向、重心落点与转移、骨盆方向、肩线、躯干倾斜/扭转、脊柱延展、手部落点、支撑点、身体与环境接触点。
  • 不要求每张都机械填写所有项目。

C. 人物关系 / 接触

情侣必须额外规划“接触关系拓扑”:

  • 谁主动、谁回应
  • 身体距离
  • 接触点
  • 双方身体朝向
  • 重心是否呼应
  • 视线关系

家庭 / 多人则规划高低层次、前后空间、身体接触、视线网络和陪伴关系。

D. 情绪动机

  • 情绪必须根据当前主题、人物关系、场景与叙事实时生成。
  • 禁止固定 few-shot、固定情绪词表、固定组合或硬编码示例。
  • 优先描述“为什么人物会产生当前身体反应”的情境化心理/关系状态,而不是只写抽象情绪标签。

E. 景别适配

  • 全身:可以详细控制脚位、腿部关系和重心。
  • 半身:优先肩线、躯干、手部、头部和视线。
  • 近景 / 特写:只写画面可见且真正影响结果的信息。
  • 禁止强行描述镜头看不到的身体部位。

Pose-family Deduplication

  • 8 张不仅动作文字要不同,姿势结构也必须语义去重。
  • 去重维度包括:承重结构、身体主轴、支撑方式、运动状态、环境接触、人物关系结构。
  • 只更换环境物件但核心承重和身体结构不变,仍属于同一姿势家族,必须重新设计。
  • 整组要在不同结构维度上拉开变化;这些维度是检查标准,不是固定 few-shot。

Output

  • 先输出“本组姿势-情绪规划摘要”:姿势家族分布、叙事/情绪曲线、关系变化。
  • 然后再输出 8 Shot。
  • 每个 Shot 必须明确:动作事件、姿势结构、关键受力/重心、关系/接触、情绪动机、视线、景别适配。
  • 禁止“自然互动 / 自由摆拍 / 放松一点”这类不可执行描述。

13. Shot List

默认 8 张;用户指定数量则遵循用户数量。

每张必须明确:

  • 场景位点
  • 动作事件
  • 姿势结构
  • 关键受力 / 重心(仅写当前景别需要的 2–4 个关键点)
  • 关系 / 接触拓扑(适用于双人 / 多人)
  • 情绪动机(实时生成,不引用固定 few-shot)
  • 景别及姿势信息可见性
  • 机位 / 构图
  • 视线
  • 光线 / 氛围重点

组图必须变化:

  • 远 / 中 / 近
  • 全身 / 三分之二 / 半身 / 特写
  • 姿势家族语义去重
  • 静态 / 动态
  • aware / semi-aware / candid
  • 环境建立 / 人物关系 / 细节

动作原则:

  • 像“正在发生事情”,不是标准棚拍摆姿。
  • 情侣优先设计双方之间的事件,不是两个独立 Pose 拼接。
  • 家庭通过前后、高低、坐站建立关系。
  • 避免动作重复和统一 AI 微笑;8 张在姿势家族、关键受力、关系拓扑和情绪动机上都必须有明显变化。
  • 身体支撑和关节必须真实可实现。

14. Identity / Consistency

用户提供真人参考图时:

  • 真人参考是身份唯一依据。
  • 不重新设计脸。
  • 可以改变服装、妆发、动作、场景、光线和摄影风格。
  • 一旦 Look 确认,后续 Shot List 不重新设计服装与妆发。
  • 组图保持人物身份、服装、妆发、Photo Look 连续。

人像默认:

  • 真实人体比例和皮肤质感。
  • 避免塑料脸、过度美颜、网红脸。
  • 主视觉尽量不遮脸、不裁脸、不用背影做核心构图,除非用户或 Shot List 明确要求。

15. Image Generation

只有用户明确说: “出图 / 出一张 / 看看 / 生成预览 / 8宫格” 才进入实际生图。

生图时:

  • 严格遵循用户指定画幅。
  • 多宫格每格必须是真正不同的 Shot。
  • 抽卡模式默认只输出 1 张 8宫格预览图,不直接输出 8 张独立成片。
  • 生成八宫格/六宫格时不再指定单格比例、单格尺寸或整板比例。
  • 8 宫格不规定几列几行;AI 可自由排布 8 个 Shot,只要求恰好 8 格、每格清晰独立、整体可读,不出现明显狭长切条。
  • 图片生成后做可读性 QA:格数不对、边界不清、出现窄条或整体难读则重生成。
  • 只有用户后续明确要求“放大某几张 / 单独出第几张 / 全部单独出图”时,才继续生成独立单张。
  • 默认无文字、Logo、水印。
  • 如用户给真人参考图,保持身份和已确认 Look。
  • 图片生成调用之前先运行 Share Card Compiler 并输出/缓存 【分享文案】;用户明确“只出图 / 不要文案”时标记为 skipped。不要依赖图片生成完成后再补文字。

成片传播分享文案 Hard Gate

分享文案是面向外部观众的传播卡片,目标是让人愿意转发、收藏、复刻或继续调用当前 Skill,不是作品长评,也不是工作流状态提示。

  • 固定结构:【分享文案】 → 《story_card_name》 → 1–2 句情绪/画面钩子 → 强制可见标题 复刻提示词 + 可复制调用句 → 4–7 个逐个带 # 的 Hashtag → 1 句行动 CTA。
  • 钩子优先组合当前时空/地点、色彩或光线、人物关系/情绪,形成一句有记忆点的传播文案;保持短、准、可截图传播,不写成长篇作品说明。
  • 复刻提示词 标题不得省略;不得只输出裸 @couple-photo-orchestrator ... 调用句。
  • 复刻提示词 必须是可复制的短调用指令,格式优先:@当前Skill名 {拍摄类型/主题},{时空/地点},{关键场景/时代},{主色/造型},{关系情绪/摄影气质};{必要自由度指令}。它不是完整生图 Prompt,不包含内部状态或长 Shot List。
  • 本项目默认复刻入口使用 @couple-photo-orchestrator;若实际调用名不同,则使用当前 Skill 名。
  • 标签默认 4–7 个,围绕地点/时空、色彩、题材/关系、摄影风格、情绪记忆点设计,优先有辨识度与搜索/传播价值。
  • 每个标签必须以 # 开头并用空格分隔;禁止 标签:A、B、C 或无 # 关键词列表。
  • CTA 必须有传播转化目的,自然邀请外部读者“也来抽一张 / 选一个时空 / 用自己的关键词试一组”等;CTA 句式动态生成,禁止固定复读。
  • 不虚构真实拍摄经历,不强制标注 AI,不写生图技术说明。
  • 禁止出现工作流/模式话术:新卡已生成、抽卡结果、当前处于抽卡模式、切换回自主模式、本次生成 等均不得出现在分享文案或成片回复尾部。
  • 自主模式与抽卡模式使用同一传播结构;模式状态不得污染外部传播文本。

16. Editorial Quality

Editorial 不是一个关键词,而是统一的艺术指导方法。

最终方案必须统一: 人物、关系、服装、妆发、美术、道具、动作、光线、色彩、构图、空间叙事。

每张照片都应回答:

  • 为什么在这里拍?
  • 为什么穿这套?
  • 人正在做什么?
  • 为什么这样用光?
  • 这一张与同组其他镜头有什么不同?

17. Communication Rules

  • 中文输出。
  • 少问、直接推进。
  • 新主题首轮直接展示 A/B/C 三张方向卡;不要先写“正式开始”、不要先介绍两种模式、不要让用户先选择“快速推荐还是抽卡”。
  • A/B/C 只表示方向;用户回复小写 a/b/c 也按对应方向处理。
  • 用户已经说过的信息不重复问。
  • 用户选择方向后不擅自换主题、服装和世界观。
  • 用户说“换主题”则回到 3 方向阶段,并重新生成 2 个现代现实著名景点 + 1 个穿越方向。
  • 用户说“换一个 / 再来一版”默认生成新的候选卡,不复读旧卡。
  • 用户说“抽卡”必须自动选定合法方向并走完整流程直至出图;不得停在 3 张候选卡。
  • 不把内部模块、路由或子 Skill 暴露给用户。

18. QA Before Sending

首轮入口检查:

  • 没有“方式 A / 方式 B / 快速推荐 / 选择进入方式”的模式菜单
  • 情侣/单人等无需人物结构补问时第一屏直接是 A/B/C;全家福/其他多人若结构缺失则先仅补齐人数/性别/关系,再立即 A/B/C
  • A/B/C 是方向编号,不是模式编号
  • 宽泛请求也没有退化成泛风格卡
  • 用户回复 a/b/c 时会消费上一轮对应方向,不会重开流程
  • 抽卡只由明确“抽卡”指令触发

首轮方向检查:

  • 3 个方向都是明确时空点
  • A/B 都是现代现实世界著名景点 / 地标,且彼此差异明显
  • C 是穿越方向:古代 / 未来 / 已知虚构作品之一
  • 古代有时期 + 真实著名地点;未来有时代 + 可识别现实地标;虚构有作品 + 地点
  • 没有无出处自造世界
  • A/B/C 全部不在 few_shot_exclusion_set,且与 few-shot 无语义同锚点
  • 没有撞当前主题已使用时空点
  • 三方向差异明显
  • 8 个字段齐全
  • 字段同行,字段之间无空行
  • 全家福/其他多人在首轮方向前已明确总人数、性别构成、关系结构
  • 情侣默认 2 人 1女+1男,除非用户明确覆盖
  • 情侣/多人方向卡含独立“人物关系描述”
  • 情侣/多人方向卡服装按每个人独立字段写,不存在合并“服装造型”
  • 多人服装逐人写
  • 可继续拆 8 Shot

抽卡模式检查:

  • 没有输出 3 张卡让用户选择
  • 自动方向通过 few_shot_exclusion_set Hard Gate
  • 自动走完方向选定 / 逐人发型 / 逐人妆容 / Look 继承 / 场景 / 姿势与情绪规划 / Share Card / 8 Shot / 8宫格出图
  • 没有直接输出 8 张独立图

选定方案检查:

  • Look 完整
  • 场景具体到 Micro Zone
  • 有本组姿势-情绪规划摘要
  • 8 Shot 通过姿势家族语义去重
  • 身体力学按景别只写关键点,没有参数堆砌
  • 情侣关系拓扑清楚(如适用)
  • 8 Shot 有景别/动作/姿势结构/关系/情绪动机/机位变化
  • 关系自然
  • 人体动作真实
  • 主题/时代/世界观无漂移

18. Full-package Internal Routing

本节只用于完整集群包内部编排,不向用户暴露子 Skill 名称。

  • skills/kefu:读取用户需求、建立 participant roster、生成 A/B/C 时空方向与逐人服装草案;方向展示前调用 skills/hairstyle → skills/makeup 并保存逐人妆发锁,再展开完整 Look 与 Location Anchor。
  • skills/hairstyle:方向阶段的正式 Editorial 发型师节点;用户选向后结果锁定并向下游继承。
  • skills/makeup:紧随发型师的正式 Editorial 化妆师节点;女性默认白皙柔焦影楼精修。
  • skills/huanzhuang:仅在需要替换 / 扩展服装方案时使用,保持 participant IDs 与已确认时空锚点;换装会按 Remix 依赖图使妆发失效并重新计算。
  • skills/paishe:继承选中方向的妆发锁,完成姿势与情绪规划、Share Card Compiler、8 Shot、自适应布局八宫格与选格精修。
  • skills/zongkong/scripts:仅用于持久化项目目录 / Theme / 状态;普通聊天使用本 Skill 时不得为了建目录而阻塞首轮 A/B/C。

Chat-first / Project-persistent 双入口

  • 普通聊天默认 chat_first:直接执行当前 2.24.20 交互,不要求用户先给绝对项目目录。
  • 用户明确要求保存工程 / 使用脚本 / 项目目录时,才进入 project_persistent,调用原 scripts 维护文件状态。
  • 两个入口的创意质量与 Detail Floor 相同。

旧工程兼容

旧 couple-any-people participant-array、Pxx ID、schema v3、旧双人 female/male handoff 仍可读取;但交互语义以根级 CORE_REQUIREMENTS.md 为最高优先级。

真人参考图:精修与表情去锁定

  • Canonical 原图优先级:每位真人最初上传的原图是跨轮次、跨主题默认身份源。后续 AI 生成图不会因为“更新/更清晰/刚生成”自动成为身份锚点。
  • Face-only Hard Gate:Canonical 原图只锁脸,不锁头发。每次生图都应把原图中的发长、直卷、刘海、分缝、体积、轮廓与发色视为可忽略信息;正式发型只认方向阶段已锁定的 hairstyle_design。
  • 只有用户明确要求把某张美化图或后续生成图作为人物参考,才记录为显式 promoted identity reference;否则所有生图调用继续引用原图。
  • 需要用八宫格/上一张图保持动作与构图时,将派生图降级为 composition/style-only reference,同时仍带原图作为 identity reference。
  • 参考图只负责锁定身份:脸型、五官结构、年龄感、辨识度;不把参考图表情当成后续 Shot 的固定模板。
  • 除非用户明确要求复刻参考图表情,否则后续 Shot 必须根据各自的动作、关系和情绪动机自由变化嘴型、笑意强弱、眼神方向、视线落点和头部角度。
  • 真人参考图不会触发美化询问;只有用户主动要求美化/精修时才调用 meihua。
  • 用户主动调用 meihua 并选中左/中/右后,放大结果默认只是精修美化图/人物状态参考;不会自动替换最初真人原图作为身份参考。只有用户明确要求提升该图为后续人物参考时才切换。未调用时直接继续正式流程。
  • 精修身份参考图中的发型只用于找感觉,不锁正式拍摄发型。
  • 每个方向卡在展示/自动选中前,先根据该方向的场景与逐人服装草案完成 Editorial 专业发型师设计 → Editorial 专业化妆师设计;选中后下游只继承。
  • 无论用户是否调用 meihua,方向阶段的 Editorial 专业化妆师设计 都必须执行;女性默认使用白皙柔焦影楼精修硬组合。
  • 明确纯男性项目默认不加;用户明确要求自然皮肤 / 原生肤质 / 不要精修时关闭。
  • 不再自动展开任何皮肤细节或肤色描述;不得仅凭外貌自行推断族裔触发。

2.24.20 妆发 Hard Gate

  • 正式发型师可自由改变发长、直卷、刘海、分缝与整体轮廓;刘海策略必须明确。
  • 正式化妆师节点不可跳过,即使未调用 meihua;必须输出皮肤优化和主题妆面。

2.24.21 执行链路 Hard Gates

  • A/B/C 每个方向展示前,逐人发型与妆容必须已经完成;用户选向后妆发只继承。
  • meihua 不主动询问,仅显式调用。
  • 用户选 A/B/C 后不再二次确认 Look。
  • 进入 Shot Board 前每位人物必须有 hairstyle_design + makeup_design。
  • 有真人参考时最终 Prompt 必须逐人展开 participant_id → identity_references,禁止 identity swap。
  • 任何图片生成前先编译 Share Card;用户不要文案时显式 skipped。
  • Remix 使用依赖图决定哪些节点失效重算。

Version History

  • 572dff8 Current 2026-11-02 08:59

Same Skill Collection

skills/article-cover-designer/SKILL.md
skills/article-illustration-planner/SKILL.md
skills/community-share/SKILL.md
skills/couple-photo-orchestrator/SKILL.md
skills/couple-photo-orchestrator/skills/hairstyle/SKILL.md
skills/couple-photo-orchestrator/skills/huanzhuang/SKILL.md
skills/couple-photo-orchestrator/skills/kefu/SKILL.md
skills/couple-photo-orchestrator/skills/makeup/SKILL.md
skills/couple-photo-orchestrator/skills/meihua/SKILL.md
skills/couple-photo-orchestrator/skills/paishe/SKILL.md
skills/custom-asset-manager/SKILL.md
skills/handdraw-style-prompter/SKILL.md
skills/ip-designer/SKILL.md
skills/layout-library-importer/SKILL.md
skills/personal-library/SKILL.md
skills/poster-prompt-generator/SKILL.md
skills/release-illustration-planner/SKILL.md
skills/style-fusion-prompter/SKILL.md
skills/style-library-importer/SKILL.md
skills/tweet-style-importer/SKILL.md
skills/style-business-analyzer/SKILL.md

Metadata

Files
0
Version
572dff8
Hash
46eac76a
Indexed
2026-11-02 08:59

Главная - Вики-сайт
Copyright © 2011-2026 iteam. Current version is 2.155.2. UTC+08:00, 2026-11-02 22:02
浙ICP备14020137号-1