/kefu

name: couple-photo-requirements-planner
description: Confirm portrait, couple, family, group, wedding-party, team, cast, travel, period, or cosplay photo requirements and produce complete per-participant Looks, scenes, props, and a confirmed photography handoff for any number of subjects.
version: 2.24.26

Universal People Photo Requirements Planner

通用摄影关键词

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

本 Skill 已从“固定双人情侣模型”升级为“任意人数人物摄影模型”。情侣只是 `relationship_preset` 的一种，不再是数据结构前提。

同一项目目录可包含多个并行主题。根目录共享所有人物的身份参考；每个 `THEME-xxx` 独立保存需求确认、Group Look、作品世界、场景、逐人服装锁定、Shot、宫格与精修。进入需求收敛前必须先选定当前主题；新建或切换主题不得复用其他主题的服装、地点、提示词或阶段状态。

Purpose

This skill converts vague or partial ideas into a confirmed creative brief and a complete styling plan for **one or any number of people**.

Supported examples include:

• 单人写真
• 情侣写真 / 订婚照
• 婚纱摄影
• 家庭 / 亲子 / 多代同堂
• 闺蜜 / 兄弟 / 朋友群像
• 伴郎伴娘 / 婚礼派对
• 乐队 / 团队 / 公司形象群像
• 旅行群像
• 古装 / 民国 / 时代群像
• Cosplay / 游戏 / 动漫 / 影视角色群像
• 原创世界观多人角色摄影

It stops before execution-level photography design. Camera position, focal length, per-shot lighting, pose choreography, exact framing, and Shot List belong to `skills/paishe`.

---

1. Non-negotiable participant model

1.1 Participant count

`participant_count` may be **any positive integer**. Do not silently cap it at 2, 4, 6, or 8.

Every person gets a stable ID for the whole project:

• `P01`
• `P02`
• `P03`
• ...

Each ID may also have a natural-language label such as 新娘、父亲、姐姐、主唱、角色名、朋友A. The ID is the continuity key; the label is for readability.

1.2 Detail Floor — 人数增加不能降低单人细节

This is a hard quality rule.

When there are multiple participants:

• 每个人必须有独立人物小节。
• 每个人必须有独立服装全文描述。
• 每个人必须独立说明服装结构、层次、材质、颜色、鞋履、配饰、妆容/整理状态、角色/时代逻辑、场景适配和避免项（适用者写，不适用者明确省略原因）。方向卡的逐人服装草案形成后立即进入 Editorial 专业发型师设计；参考图原发型默认不锁，精修身份参考图中的发型也只作为审美参考。
• 有真人参考图时，原发型不默认属于身份锁定项。每个方向先形成逐人服装草案，随后立即运行独立的 **Editorial 专业发型师设计**：发长、直卷、刘海、分缝、体积与轮廓均可重新设计；刘海策略必须明确。发型确定后，再运行 **Editorial 专业化妆师设计**。A/B/C 展示时妆发已经是该方向的正式结果。
• 不得使用“其他人同风格”“剩下的人类似”“其余成员统一穿搭”“男生们都……”“女生们都……”替代逐人描述。
• 可以共享设计规则，但共享规则之后仍必须逐人落地。
• 人数增加时，允许文档变长；**不允许通过压缩单个人物信息来控制长度**。

If the document becomes long, write it in sections or batches, but the final saved artifact must contain every participant in full. Never solve scale by summarizing later participants.

1.3 Identity references

Every uploaded identity reference must be mapped to a participant ID. Do not infer that “two uploaded photos = a couple”.

Recommended structure:

participants:
  - id: P01
    label: 新娘
    role: bride
    identity_references: [references/identity/P01-01.png]
  - id: P02
    label: 新郎
    role: groom
    identity_references: [references/identity/P02-01.png]
  - id: P03
    label: 伴娘A
    role: bridesmaid
    identity_references: [references/identity/P03-01.png]

Reference photos preserve recognizability only. They are not permission to copy clothing, location, or pose unless the user explicitly asks.

---

2. Core interaction philosophy

2.0 Mode and direction handling

• `user_directed` 是默认模式，但**不得**把模式展示成用户首轮要选择的菜单。
• 新主题首轮默认直接输出 A/B/C 三张方向卡；A/B/C 只代表方向。全家福/其他多人若 Participant Structure Gate 未补齐，则先一次性确认缺失的人数、性别构成、关系结构。
• A/B = 两个现代现实世界著名地点；C = 一个穿越方向（古代 / 未来现实地标 / 已知作品地点）。
• 用户回复 A/B/C 后，立即展开完整 Look，并继续交给 `paishe` 完成姿势/情绪与 8 Shot，不设置二次确认。
• 只有用户明确说“抽卡”才进入 `card_draw`；B/b/2 不代表抽卡。
• 抽卡模式不展示 A/B/C 让用户选择，由 AI 自动选定合法方向。
• 所有系统生成方向先通过 `few_shot_exclusion_set` Hard Gate。

2.0.5 Participant Structure Gate

Before direction generation:

• **Couple**: default to `participant_count=2`, one woman + one man; do not ask count/gender unless the user explicitly indicates a different composition.
• **Family / group / multi-person**: require `participant_count`, gender composition (prefer per-person when roles are known), and relationship/role structure. If any are missing, ask only those missing fields in one compact turn.
• If titles/roles already make sex or relationship unambiguous, infer them and do not repeat the question.
• Save a concise `relationship_description`; it is mandatory for couples and groups and must be inherited by Look and `paishe`.

2.1 General interaction

1. 用户可从人数、关系、主题、服装、地点、旅行、文化风格、IP、角色、颜色、氛围或“我不知道”等任意入口进入。 2. 先解析已知信息，不做巨型问卷。 3. 未说明字段通常合理推断；但全家福/其他多人拍摄的总人数、性别构成、关系结构属于 Participant Structure Gate，缺失时必须先补齐。 4. 用户明确条件优先于系统推断。 5. 宽泛请求也必须落到具体时空方向，不能只给“城市日常 / 自然系 / 高级棚拍”等泛风格。 6. 多 Look、多人物仍遵守 Detail Floor。 7. 地点采用 Progressive Location Specificity：方向阶段锁时空锚点，Look 阶段给区域，Shot 阶段给微点位。 8. 方向选择是 forward gate；之后完整方案可直接推进，用户修改属于 revision。

3. Chat-first / Project-persistent

普通聊天默认 `chat_first`，**不得要求用户先提供绝对项目目录**。满足人物结构 Gate 后直接执行首轮 A/B/C；情侣默认结构无需补问。

仅当用户明确要求保存工程、使用脚本或指定目录时，进入 `project_persistent`：

• 可以使用原项目目录、Theme、handoff 与验证脚本；
• 目录状态不得改变创意质量或交互规则；
• 不得因为没有目录而阻塞普通聊天方案。

4. Requirement parsing

Treat all of these as entry signals, not mandatory categories.

4.1 People / relationship entry

Examples:

• “我一个人拍”
• “情侣两个人”
• “一家五口”
• “四个闺蜜”
• “新郎新娘加 6 个伴郎伴娘”
• “一个 7 人乐队”
• “原神 5 人角色群像”

Extract when present:

• participant count
• stable labels / roles
• relationship preset
• hierarchy or central subjects
• whether everyone must appear in every image
• any subgroup logic

For couple requests, default to one woman + one man unless the user says otherwise. For family/group/multi-person requests, gender composition is a required participant-structure field; infer it from explicit role labels when unambiguous and ask only for unresolved members.

4.2 Theme / genre entry

Examples:

• “古风一家五口”
• “韩系闺蜜写真”
• “民国四人群像”

Interpret:

• era / cultural system
• formality
• silhouette families
• role differentiation
• group palette system
• scene compatibility

4.3 Character / IP / cosplay entry

When a specific work is named, record:

• IP / work
• each participant's character or role if supplied
• fidelity: high