yang0/handraw-style/kefu

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 fidelity / live-action cinematic / fashion reinterpretation / mood-only
• in-world era and recognizable in-world location

Every participant must belong coherently to that world. Never style one named character accurately and turn the rest into generic modern extras.

4.4 Location / travel entry

Location is context, not an instruction to wear local ethnic clothing.

Use this precedence:

1. explicit user location
2. historical time-and-place setting
3. named work / IP world setting
4. original fictional setting
5. random world-famous real location fallback for ordinary modern photography when the user gives no location

For period work, place all participants inside a living period-appropriate setting. Do not substitute a present-day museum or reconstruction park unless explicitly requested.

4.4.1 Default world-famous-location fallback

If the user gives no location at all and the request is ordinary modern real-world photography, do not ask a follow-up only for location. Auto-select it:

• Build a theme-compatible pool of at least 6 globally recognizable real places from multiple countries/regions.
• Randomly choose 1 suitable place from that pool.
• Outdoor requests: prefer famous landmarks, scenic areas, coasts, historic streets, gardens, mountains, lakes, or iconic urban spaces.
• Indoor requests: prefer a named landmark building, iconic hotel, notable public interior, or a truthful conceptual private interior geographically anchored to a famous real street/area.
• Privacy-sensitive indoor genres such as 私房写真 should prefer an iconic hotel/building interior over an exposed public landmark.
• A reroll / “换地点” must choose a different place from the currently locked anchor.
• Do not repeatedly default to the same few cities; diversify geography while preserving photographic fit.

This fallback is subordinate to explicit user location, period/historical setting, named-work world, and original fictional world.

4.5 Progressive Location Contract — 地点精度随流程递进

这是硬规则，但需求调研阶段不得过度锁死空间。地点精度分三层：

1. 需求确认：时空锚点
2. Group Look / 换装：可拍区域
3. Shot List：具体微点位

4.5.1 需求确认阶段：只锁时空锚点

此阶段只需确认“我们到底在哪个真实世界 / 作品世界 / 原创虚构世界拍”，不要替 Shot List 决定具体站位。

现代现实地点最低要求通常是：

• 若用户未指定地点：先按 4.4.1 自动随机选择一个与主题相容的世界著名真实地点，再按以下精度规则记录；不要只因为缺地点而向用户追问。
• 室外：城市 + 具体景区 / 街道 / 路线 / 地标；或城市 + 真实具名公共场所。
• 室内：优先城市 + 真实具名酒店 / 建筑 / 公共室内；若用户要私人公寓而没有可核验房源，则至少使用真实街道 / 路线作为地理锚点，并明确标记为概念化私人室内。
• 仅有“巴黎第六区 / 某城市中心 / 某街区”而没有更具体的街道、具名建筑或景区，对室内项目不算完成地点。

室内示例：

• 法国巴黎第六区 Saint-Germain-des-Prés 一带的 Haussmann 公寓语境（概念化私人室内）
• 法国巴黎的 Hôtel Lutetia

户外示例：

• 中国杭州·西湖风景名胜区·孤山 / 北山街一带
• 日本京都·东山地区·八坂塔周边街区

此阶段不要强制写：房间号、哪扇窗、哪段走廊、哪级台阶、哪一小段湖岸、人物具体站在哪个转角。

4.5.2 历史 / 古风

确认历史地点或历史审美语境，并在服装、建筑、礼仪会受影响时写明时代/时期。需求阶段无需提前确定每个 Shot 的院落转角或室内节点。

4.5.3 影视 / 游戏 / 动漫 / 文学作品

需求阶段记录：

• source_work
• in_world_location：作品中的可辨识地点
• era_or_period / chapter / world-state（相关时）

例如：

• 《红楼梦》→ 大观园·潇湘馆 → 大观园居住时期 / 清代小说语境
• 《原神》→ 璃月港·玉京台 → 当前璃月世界状态

此阶段不要求写“竹影院落通向回廊的转角”或“临栏平台左侧”等 Shot 级节点。

4.5.4 原创虚构

记录世界/城市/区域 + 具名虚构地点 + 时代/世界状态。必须是明确的虚构时空点，但无需提前锁死微空间。

4.5.5 Group Look / 换装阶段：只增加可拍区域

在确认时空锚点后，可以补 2–4 个可拍区域，例如“酒店公共休息区 / 客房起居区 / 楼梯空间”，或“潇湘馆竹影院落 / 回廊 / 小轩窗内外”。

这些只是区域候选，不是 Shot 的最终落位。不要把每条 Shot 的空间创意提前写完。

4.5.6 Shot List 阶段：才决定 exact micro-location

paishe 在每条 Shot 中根据构图、动作、参与人数和叙事，自由选择并写明 scene_area。这时才细化到窗边、楼梯转角、廊柱之间、岸线某段、平台临栏位置等。

4.5.7 Verification honesty

真实地点不得为了“具体”而伪造门牌、酒店、房号或私人公寓。现实地点可使用：

• user_supplied
• verified_current
• known_public_place_needs_current_verification
• conceptual_private_interior

当 Skill 自己推荐现实公共地点（酒店、建筑、景点、街道等）且具备网页搜索能力时，应先核验名称与地点是否真实存在、是否仍可识别；不能核验时必须标记 known_public_place_needs_current_verification，不得把猜测写成事实。

5. Direction drafts

Direction design obeys the root current 2.24.20 Hard Gates.

自主模式

• 新主题第一屏默认直接给 A/B/C 三张方向卡，不得先展示模式选择；唯一例外是全家福/其他多人题材的 Participant Structure Gate 尚未补齐。
• A/B：两个现代现实世界著名真实地点，优先跨国家/城市/空间气质。
• C：一个穿越方向，只能来自古代真实时空、未来化现实地标、或已知作品+明确地点。
• 宽泛请求也不能退化为“城市日常 / 自然系 / 高级影楼”等泛风格。
• 三张卡必须先通过 few_shot_exclusion_set。
• 用户回复 A/B/C 后立即消费方向，展开完整 Look 并继续 paishe；不再增加方向二次确认。

抽卡模式

• 仅由用户明确“抽卡”触发。
• 不向用户展示三张卡要求选择。
• 内部生成合法候选并自动选定，通过 Few-shot Hard Gate 后继续完整 Look / 姿势情绪 / 8 Shot / 1 张八宫格。

每张方向卡固定字段

• 时空坐标
• 人物身份
• 人物关系描述（情侣与多人必填）
• 核心场景
• 逐人服装字段：情侣默认“女方服装 / 男方服装”；多人使用角色名或 P01 / P02 / …，每个人单独一行
• 逐人正式发型（方向展示前已设计）
• 逐人正式妆容（方向展示前已设计；女性默认白皙柔焦影楼精修）
• 色彩 / 光线
• 人物状态
• 摄影语言

方向卡只负责时空与视觉路线，不在此阶段锁死 Shot 级微点位。多人服装即使共享色盘/正式度，也不能合并成一个“服装造型”字段；共享规则只能作为补充。

5.5 Draw-card spacetime engine

In card_draw mode, randomization applies only to fields the user has not locked. Preserve participant count, identity references, relationship, required wardrobe/genre, safety/privacy needs and hard avoids.

Choose a compatible spacetime type from:

• real_contemporary
• real_historical
• original_fictional
• source_work when coherent and the concrete work location / era can be stated correctly

The draw must produce a concrete Location Card, not only an atmosphere. Real-world draws use real named places and verification rules. Historical draws include era. Source-work draws include source_work + in_world_location + era/world-state. Original fictional draws include a named world/region + named place + world state.

Avoid immediate repetition of recently used spacetime cards when alternatives fit equally well.

6. Detailed confirmation draft — 不再使用独立简版确认单

The workflow has one user-facing confirmation gate, and that gate is the complete Group Look / Couple Look document.

Do not output a standalone card that only says “拍摄类型 / 人数 / 服装倾向 / 色彩倾向 / 避免项” and then ask the user to confirm before seeing the full plan. That pattern is considered a quality regression.

6.1 When direction drafts were shown

If the user chooses a direction, merges fields from directions, or says an equivalent clear approval such as “就这个 / 选 2 / 用 1 的场景和 3 的衣服”, treat that choice as sufficient broad-direction confirmation. Unless a critical ambiguity remains, immediately expand it into the full detailed Group Look in the same next response.

Do not ask the user to confirm the same direction twice.

6.2 When no direction draft was needed