需求与造型规划

把模糊、零散的想法变成一份确认过的创意 brief 和逐人完整的造型方案，一个人或任意多人都行：单人写真、情侣写真和订婚照、婚纱、家庭亲子多代同堂、闺蜜兄弟朋友群像、伴郎伴娘婚礼派对、乐队团队公司形象、旅行群像、古装民国时代群像、Cosplay 和游戏动漫影视角色群像、原创世界观的多人角色摄影。情侣只是关系预设之一，不是数据结构的前提。

做到摄影执行层之前为止：机位、焦段、每张的光线、姿势调度、取景和 Shot List 归拍摄与八宫格。本 skill 自己不出图。

先守入口的共守规矩，尤其是两种模式、人物、妆发在方向阶段定稿。

解析需求

用户可以从任何一个口子进来：人数、关系、主题、服装、地点、旅行、文化风格、IP、角色、颜色、氛围，甚至「我不知道」。这些都是入口信号，不是必填类别。

先解析已知的，不做巨型问卷；没说的字段通常直接推断，不为了「字段完整」连续追问
用户明确的条件优先于推断，尽量保留用户的原话：题材、地点、关系、服装、角色、比例、禁忌
宽泛请求也要落到具体的时空方向上
用户说过的不再问；全家福和其他多人的总人数、性别构成、关系结构属于人物结构确认，缺了必须先补

各类入口要抽出的东西：

人数和关系（「我一个人拍」「一家五口」「新郎新娘加 6 个伴郎伴娘」「一个 7 人乐队」）：人数、固定的称呼和角色、关系预设、层级或中心人物、是不是每张都要所有人出镜、子群逻辑
主题和类型（「古风一家五口」「韩系闺蜜写真」「民国四人群像」）：时代或文化体系、正式度、廓形家族、角色区分、群体配色、场景兼容性
作品、IP、Cosplay：作品名、每个人的角色（给了的话）、还原程度（高还原 / 真人影视化 / 时装化改编 / 只借气质）、作品内的时代和认得出的地点。所有人都要合理地属于那个世界，不能一个角色还原得准、其他人变成无语境的现代路人
地点和旅行：地点是语境，不等于穿当地民族服装；优先级和精度见地点

用户点名作品或用流行文化词描述风格时，按影视与流行文化联想把抽象风格翻成具体的服装语言。

只在用户还没给、又会改变方案时才确认：拍摄类型和用途、人数和名单、性别构成（全家福和多人必问，情侣默认一女一男）、人物关系和角色层级、套数、核心主题或世界观、具体角色或 IP、明确的服装锚点、强避免项。地点用户指定了就锁定，没指定的普通现代题材由系统随机名胜补，不单独追问。

由系统推导、不问用户：领型、袖型、腰线，面料组合，鞋履首饰，每个人之间的层级呼应，道具归属。用户不用逐字段做专业选择。

出方向卡

新主题第一屏直接给 A/B/C 三张方向卡；时空规则见时空方向，卡的格式见方向卡
每张卡先有明确的时空、核心场景和逐人服装草案，然后依次跑发型师、化妆师，妆发定稿后才展示
方向卡只管时空和视觉路线，不锁 Shot 级的微点位
多人即使共享色盘、正式度，服装也不能合并成一个字段，共享规则只能作补充
主题、正式度、时代、地点、色彩、群体关系或 Editorial 强度有明显分支时，把分支拉开到三张卡里，不单独问一轮

选定后展开完整 Look

整个流程只有一个面向用户的确认点，就是方向选择；完整 Look 文档本身就是确认稿，写法见完整 Look。

用户选了方向、合并了几张卡的字段，或者说了「就这个」「用 1 的场景和 3 的衣服」这类清楚的认可，就当方向已确认。除非还有关键歧义，下一条回复直接展开完整 Look，不让用户把同一个方向确认两次
用户一开始的请求已经清楚到能直接设计，就直接出完整 Look。顶上可以有一段简短的创意摘要，但它是同一份文档的一部分，绝不代替逐人的 Look
不单独输出一张只有「拍摄类型 / 人数 / 服装倾向 / 色彩倾向 / 避免项」的卡片然后停下来等确认 —— 那是质量倒退
完整 Look 只继承并展开方向卡定好的妆发，不重新设计
出完立刻交给拍摄与八宫格；用户之后要改某个 Look、某个人、地点或服装，按改一个变量只更新依赖项
抽卡模式由 AI 自动选定并检查完整 Look，继续往下走

每个人的服装要写到什么程度

每个人一节，读起来像专业造型笔记，不是关键词列表。适用的都要写：

编号、称呼、角色；身份、角色或关系功能；在群体里的视觉角色
服装类别和具体结构、廓形和比例
上装内搭和外层、下装或连衣裙或袍服的结构
领口、翻领、驳领、袖、腰、下摆（相关时）
主材质和辅材质、准确的配色角色和表面质感、结构和装饰细节、动起来的样子
鞋履；首饰、手表、发饰和其他配饰
妆容和整理状态（正式发型由发型师在方向阶段定）
道具归属、季节和实穿性、和场景、时代、作品世界的兼容性、避免项

某个字段可以不适用，但这个人不能被概括掉。

群体搭配关系

所有人写完后讲清：视觉层级、配色关系、材质关系、廓形关系、正式度关系、对比还是和谐、共享母题、刻意的差异、子群逻辑（有的话），以及怎么避免整齐划一的团建照感 —— 除非整齐本身就是用意。

多套 Look

一听到要几套就记下 look_count，整套当一个协调的系统来规划
每套都包含所有计划出镜的人，除非用户明确定义了只有部分人出镜的一套
每套有不同的角色，至少在正式度、廓形、文化或时代、配色、材质、场景、群体情绪、Editorial 强度里拉开 2–3 项
每套状态记 planned / presented / confirmed / needs_revision

人多时

写作流程不设人数上限。人多时：

用编号保持连续，必要时把文档分成 P01–P06、P07–P12 几段
顶上保留一份完整名单；每个人一条完整服装；交接文件里每个人一条 participant_outfits
绝不把后面的人改写成群体概括；几个人共用一套制服底子时，底子写一次，然后逐人列出各自的变化和完整的最终造型
聊天里可以分页展示，保存下来的产物必须完整

换主题、新会话

用户开新会话或说「重新开一个主题」「换一个主题」「从头来」时：

当成全新的创意 brief
细节下限和地点精度规则照旧
除非用户明确要延续，不复制旧主题的内容
不因为之前解释过就缩短字段
重新出完整的人物名单、逐人造型、完整时空锚点的地点卡

重开的主题不是「快速模式」。

保存工程时写交接文件

用户要求保存工程时，方向选定、完整 Look 建好之后，在主题目录写 deliverables/requirements-handoff.yaml，格式见交接文件。

自主模式写 confirmation_source: direction_selected，抽卡模式写 ai_auto_confirmed
visual_lock.participant_outfits 在下游不可改：Shot 可以改动作、构图和局部环境，不能改任何人的身份和服装
方向已由 A/B/C 选择（或合法的抽卡自动选择）授权、每个人的 Look 完整、每个人都锁了发型和妆容时，把 handoff_to_photography_skill.ready 设成 true，并把主题目录 project.yaml 的 stage 改成 LOOKS_CONFIRMED，再跑一次入口的 theme_manager.py switch <工程目录> THEME-xxx 把阶段同步进工程的主题登记（不同步 validate_project.py 报 out of sync）；不再要第二次 Look 确认
有真人参考时，identity_map 逐人登记原图，下游不得串脸

回复

默认用简洁专业的中文；不必要就不暴露内部分类
改一个字段只更新依赖它的项
多人项目里人物编号在之后所有轮次和文件里保持不变
不拿细节换人数，不拿细节换新会话、重开主题或再来一版
不拿具体时空锚点换氛围词；探索需求时也不过早锁死 Shot 级的微点位

reference

时空方向 —— 两个现实名胜加一个穿越、宽泛请求不降级、已知作品怎么借、few-shot 隔离与去重、抽卡池
方向卡 —— 首轮三张卡的格式、逐人字段、结尾那句话
完整 Look —— 选定后的完整 Look 文档模板：创意摘要、逐人服装、群体搭配、地点卡、可拍区域、道具、视觉锁定
交接文件 —— 保存工程时 requirements-handoff.yaml 的格式，脚本读哪些字段
影视与流行文化联想 —— 古装、韩系、Cosplay、作品引用、民国、赛博这些词怎么翻成具体服装和时空
需求示例 —— 古风、瑞士旅行、波西米亚裙、Cosplay、多套、五人群像、地点精度七个示例；只示范结构，不是推荐池