event-vip-social-program

活动 VIP 社交活动

你负责一个房间：在这场活动中，其他地方人人都能进入，但这个房间不是人人都能进入。整个工作只涉及三项决策，而且仅此三项：

• 多方提交名单时，如何确定座位名单。
• 如何发出邀请并管理入场，同时不公开存在某个等级。
• 这场聚会在公共日程中的位置。

默认答案是没有独立房间。这是第一个选项菜单中的一个档位，并非拒绝提供帮助；在社区主办的活动中，这也是最常见的正确结果。

这项技能负责的范围有多小，以及这是有意为之的原因

读者所说的“VIP 社交活动”几乎所有内容都已有归属。剩下的范围很窄。

• 是否存在面向特定嘉宾的活动 → 不归你负责。 samber/dev-event-organizer-skills@event-vip-management 会作出决定，依据的是它所述的一项义务，而非头衔的测试；而它最常见的正确答案是无人符合范围。它还负责陪同安排的细致程度、嘉宾本人的可见度，以及义务名单。
  • 先运行它。如果它发现无人符合条件，这项技能就无事可做。
• 提供什么餐饮，以及是否举办晚间活动 → 不归你负责。 samber/dev-event-organizer-skills@event-hospitality 决定餐饮形式、酒精饮品安排，以及是否举办晚间活动或社交活动。它的参考文件已经明确区分了你所处位置之间的两种活动：“晚间活动”和“受邀晚宴”是不同的活动；它只设计前者。
• 演讲者晚宴 → 不归你负责。 samber/dev-event-organizer-skills@event-speaker-experience 负责该晚宴，且拥有独立的预算项；event-hospitality 也从自身职责出发说明，它绝不会“重新决定演讲者晚宴、志愿者餐食或 VIP 桌”。该预算项只针对演讲者，不涉及其他人。绝不要把它沿用到以下各档。
• 已售出的聚会 → 你无权分配。 samber/dev-event-organizer-skills@event-sponsor-fulfillment 负责交付已签署协议承诺的内容，前提是款项已支付。请准确区分这两种情况，因为很容易弄反：
  • 赞助商_要求_在你的聚会上安排座位，这是这项技能的分配问题。
  • 协议_售出_的聚会是那项技能负责交付的内容，你无权对其进行配额分配。
• 他人举办的派对 → 不归你负责。 samber/dev-event-organizer-skills@event-side-event-coordination 审批第三方举办的活动并协调时间安排冲突；它从自身职责出发明确了分界：“那项技能负责提供的晚间活动，就是你负责许可的活动。”由赞助商主办的招待会归他们负责。你负责的是自己主办的房间。
• 人人都能参加的社交活动 → 不归你负责。 samber/dev-event-organizer-skills@event-official-social-program 为全体观众设计公开公布的社交活动。如果对“这是为谁举办的？”这个问题，诚实的答案是“任何想来的人”，那么该由那项技能负责，而不是这项技能。
• 将仅限受邀者参加的晚宴作为整场活动 → 不归你负责。 samber/dev-event-organizer-skills@business-event-formats 会从公司主办的活动形式中作出选择，这些形式中晚宴_本身就是_活动。而这里的晚宴只是他人会议中的一个房间。

排除上述所有事项后，剩下的就是私人聚会的运作机制，而且仅限于此。event-vip-management 明确将这些事项交由这项技能负责，但自己不设计其中任何一项：“因此，嘉宾的桌席归你负责；桌上的食物不归你负责。”这项技能负责的就是这张桌席。

如何使用这些菜单和默认选项

下面每项排序都是默认选项，不是硬性规定——会随情境和执行者而变化。访谈结束后，根据你已了解到的情况重新排列这三份菜单。以下任何一项都可能推翻默认排序：

• 场地有一间侧厅。
• 团队成员已经与申请席位的人建立了关系。
• 有一份沿用自上一届的名单。
• 组织者已经认识每位宾客。

本文不会规定任何数量——席位数、上限、提前时间或人数都不规定——因为凭空编造的数字会被误认为基准。文中出现的任何数字，要么引自已发布的指南，要么是读者描述自己场地时所用的说法，绝不是本技能设定的门槛。

指定负责人

指定一位联系人，负责保管和编制席位名单、发送邀请、把守入口并回应每一次拒绝。治理和组织实践确立了这一模式。同一位负责人决定是否在入口处对名单作出例外处理。

• 可延续到私人聚会：这一角色。
• 不可延续的内容：礼宾办公室自身的人员配置，或其对建筑物的管理权限。

访谈

每次只问一个问题，尽可能采用选择题。问题 4、7 和 8 的存在，是因为下面的菜单在见效时间、持久性和精力上限方面差异很大——不能替用户选定这些默认选项。

1. samber/dev-event-organizer-skills@event-vip-management 是否已经运行，并找到了符合范围的人选？如果没有，请停止并运行它。它会判定是否存在指定宾客计划；本技能假设该问题已有答案，不会重新作出判断。
2. 谁负责这场活动？登记册对身份状态有何说明——一律平等并明确反对等级制度，还是愿意承认在场宾客的身份？
3. 列出聚会专为哪些宾客举办，并用一句话说明这个房间能提供什么，是一般晚间活动无法提供的。针对每位宾客：他们本人或其办公室是否要求不要公开身份、列入名单或拍照？
4. 距离开门还有多久？场地预订、日程安排和任何印刷版节目单是否仍可更改？是否有宾客的到场或离场时间固定？现有时段中是否有适合的安排？
5. 还有谁在申请席位——赞助方、演讲者、董事会成员、你自己的团队？他们分别用了什么原话提出申请？是否已经有人答应过谁？是谁答应的？
6. 房间能容纳多少人？这个数字由谁决定：场地、预算，还是你们实际想要进行的对话？
7. 具体由谁负责——编制名单、发送邀请、把守入口，并回应被拒绝的一方？他们当天是否也在负责主活动？这里的可逆性并不对称：可以增加席位，但发出的邀请无法收回，收回邀请造成的代价会超过席位本身。
8. 这是一次性活动，还是每届都会举办？已有内容是否以某种形式发布或承诺？载体是什么——宣传书、协议、日程安排还是电子邮件？
9. 哪些资源会改变默认排序：场地是否有可用的侧厅；团队成员是否已经与申请席位的人建立了关系；是否有上一届的名单？

社区与供应商立场

谁来决定活动安排会影响一个菜单，这与本合集其他内容所主张的社区与供应商分野一致。

• 社区立场。 并非所有人都能进入的房间，与 samber/dev-event-organizer-skills@event-cultural-identity 所设定的基调相悖。在这一立场下，菜单 A 的默认方案并非折中。它通常是正确答案；想要让这个房间体现出一般晚间活动无法提供的价值的人，才有责任说明理由。
• 供应商／企业立场。 私人房间很常见，而且往往正是宾客前来的原因。此时，座位因明确理由而稀缺，菜单 A 的价值中关于可辩护性的部分就占据了主要分量。

如果建议因立场而异，请说明它基于哪种立场。立场只会改变菜单 A 的默认方案，不影响其他内容。菜单 B 和 C 在两种立场下都保持原有顺序。

工作流

1. 进行访谈。如果 Q1 的答案是没有指定宾客计划，就停止并转交给 samber/dev-event-organizer-skills@event-vip-management。
2. 先回答 Q3 的后半部分：这个房间能做什么，是一般晚间活动做不到的？如果这个问题问下来没有任何理由成立，那么菜单 A 的默认方案就是答案，本技能的其余部分无需执行。
3. 设定座位名单的构建规则（菜单 A）。然后参照 references/invitation-and-door-mechanics.md 制作名单——现在就确定其中的字段、指定负责人、流转范围和删除日期。
4. 设定邀请和入场机制（菜单 B）。依据同一参考资料发出邀请：由持有名单的人单独、私下发送。
5. 设定与公开日程的安排关系（菜单 C），然后将时段交给 samber/dev-event-organizer-skills@event-run-of-show，将日程冲突交给 samber/dev-event-organizer-skills@event-schedule-design。告知他们时段。绝不要为了安排私人活动而挪动公开场次。
6. 在收到第一个请求之前写下拒绝规则，并向所有相关方引用同一规则。规则构成了可辩护性的全部内容，而且提前制定成本很低。
7. 将不属于你的事项转交出去：
   • 房间的餐饮和饮品：samber/dev-event-organizer-skills@event-hospitality。
   • 任何无障碍需求：samber/dev-event-organizer-skills@event-accessibility-inclusion——无法进入房间的宾客，首先涉及无障碍问题。
   • 宾客自身安保团队提出的任何要求：samber/dev-event-organizer-skills@event-vip-management。
   • 行为准则对私人房间的适用范围：samber/dev-event-organizer-skills@event-code-of-conduct，由其决定范围条款涵盖哪些空间。
8. 按章节逐一展示——目的、名单规则、名单、邀请和入场、安排、拒绝规则——并在定稿前取得每一章节的明确批准。

如果你的 harness 具有持久记忆功能，请按届次记录：

• 房间的用途。
• 谁申请了座位，以及对每个人的答复。
• 引用了哪条规则。
• 名单是否在指定日期删除。
• 是否有与会者事后提起过这个房间。

下一届活动从这些记录开始，无需对相同的请求重新争论。

菜单 A - 座位名单构建规则

当组织者、赞助商和演讲者都有人选时，如何汇总名单。两种价值轴几乎相反，因此本菜单列出两种价值排序，而非一种。

• 工作量（组织者耗时、各方之间的协调、拒绝所需付出的沟通成本、留存的记录）：公开提名并公布标准，主办方有否决权 > 主办方名单 + 限制每个提名方的提名数量 > 仅由主办方提名 > 不设单独名单
• 价值：合适的人在场（聚会旨在服务的人确实在场）：仅由主办方提名 > 主办方名单 + 限制提名数量 > 公开提名并公布标准 > 不设单独名单
• 价值：决定有理可据（能向每个提出请求的各方说明原因，并且对每方都适用同一规则）：公开提名并公布标准 > 主办方名单 + 限制提名数量 > 不设单独名单 > 仅由主办方提名
• 合规成本（触发审查、消耗的可逆性）：公开提名并公布标准 > 主办方名单 + 限制提名数量 > 仅由主办方提名 == 不设单独名单
• 效率：不设单独名单 > 主办方名单 + 限制提名数量 > 仅由主办方提名 > 公开提名并公布标准

支配关系检查：四个阶梯，六组比较，零组严格支配关系——而且全部六组比较由两种不同机制解释，并非一种。

其中四组比较因两个价值维度方向相反而无法判定；每组中，让合适的人在场的阶梯，恰恰是规则最难以辩护的阶梯：

• 公开提名与限制提名数量。
• 公开提名与仅由主办方提名。
• 限制提名数量与仅由主办方提名。
• 仅由主办方提名与不设单独名单。

其余两组比较则受成本而非价值冲突阻碍：工作量更大的阶梯在两个价值维度上都胜出，却在工作量上落败：

• 公开提名与不设单独名单。
• 限制提名数量与不设单独名单。

这个选项菜单有四组比较从设计上就不存在支配关系，另两组则是成本权衡；无论如何，这都不算通过检验。效率维度的排序依据如下对每个阶梯的具体论证。

合规维度上的 == 有其理由：合规是唯一一个成本较低的两个阶梯结果相同的维度，因为工作量已经将它们区分开来，而此维度特意不作区分。

• **仅由主办方提名：**会形成一份记录了姓名的短名单，并伴随一项保留决定。即使没人被告知这份名单，也仍可缩短——它只保存一项记录，不消耗可逆性。
• **不设单独名单：**完全不留记录。发出的每份邀请都是口头邀请，没有记录，也无法妥善撤回——它消耗可逆性，却什么也不留。

暴露程度相同，代价却各不相同。两个工作量更大的阶梯都高于这两者，因为限制提名数量意味着留存某位担保人为他人提供的姓名，而公布标准则意味着作出一项承诺，下一届仍可能要对其负责。

• 不单独设名单——默认选项：不设私人聚会，由一位具名人士带宾客融入一般晚宴。这也是唯一不会产生等级的档位。
  • 它的投入产出比最高，因为只有当该档位所提供的价值仍然非零时，几乎零投入才划算，而这里通常确实如此。私人房间提供的大部分价值，是一组简短且能明确说出名字的对话，而这些对话可以通过主动走到人们面前来促成。
  • 做得妥当时，参考文件中有专门的安排机制：一位具名陪同者、提前写下介绍对象、明确的离场时间。敷衍了事时，宾客只会端着饮料站在房间边缘，那比不邀请他们更糟。
  • **晋升条件，以 Q3 为准：**当 Q3 指出房间里有一般晚宴确实无法提供的内容时，提升一个档位——例如公共场合会破坏的保密要求，或需要固定一组人且不能有其他人在场的对话。“希望他们能见见面”不算，而这正是提出这个问题的目的。
• 主办方名单 + 每个提出请求的团体限额提名——由组织者拟定名单，每个提出请求的团体获得相同且明确的名额。价值两个维度均居第二，投入也排第二；它的投入产出比胜过仅由主办方提名，因为无论有没有规则，这些请求都会出现。
  • 名额上限是将每项请求转化为一个明确答复的最廉价凭据；与单独拟定名单相比，只需多定一个数字、加一句话。
  • 针对这一场景的活动策划指南也提出了相同机制：在任何资金易手之前，先将出资方的名额确定为一个数字，因为“你有 20 个名额”与“你想邀请谁”是两种不同的对话。
  • **晋升条件，以 Q5 为准：**只要 Q5 指出已有不止一个团体提出席位请求，就采用这一档位。
• 仅由主办方提名——组织者拟定名单，不接受提名。在“名单是否合适”这一维度上居首，因为没有人比主办方更清楚哪些人必须到场，而每个留给提名的席位，都是主办方无法分配的席位。
  • 效率排第三，因为它确实能节省投入，而由此产生的不满，恰恰会影响本场聚会旨在服务的人际关系。
  • **晋升条件，以 Q5 为准：**当 Q5 没有发现任何提出请求的团体时，就采用这一档位——没人会挑战的上限，只是白白设立的规则。
• 开放提名，公布标准并由主办方保留否决权——最不利的一档：投入最高、合规成本最高、可辩护性维度最高，而且从未被效率维度选中。它在“名单是否合适”这一维度上也输给了上文所有档位，因为它依据申请者而非必须到场的人来筛选。
  • **晋升条件，以 Q8 为准：**当 Q8 表示这场聚会已通过人们可以阅读的凭据公布或售出时，提升至这一档位。一旦某项承诺写入文件，未公布的规则就会成为投诉的缘由，此时筛选标准不再是可有可无的。
  • 资历不会让这一档位晋升，支票金额也不会。
• **当 Q6 表示席位数量由场地或预算决定，而非由对话决定时，删除：开放提名这一档。**将其从此菜单和上方的维度说明中删除。针对一个你无法控制的数量公布标准，是无法兑现的承诺，还会把容量限制变成违约。
• **当 Q2 表示采用明确反对等级的扁平化安排，且 Q3 未指出一般晚宴无法满足的义务时，删除：除默认档位外的所有档位。**将它们从此菜单和上方的维度说明中删除。
  • 分别评估两个条件：仅满足 Q2，仍无法履行保密义务；仅满足 Q3 且其答案落在供应商一侧，则不删除任何档位。
  • 两个条件都满足时，在身份定位拒绝等级的活动中设置私人房间，就是在门上加了一道门槛——即使暂时被放在菜单底部，它也会在下一个策划周期以提案的形式再次出现。

菜单 B - 邀请与入场机制

邀请如何发出，以及入场如何管理。这个菜单决定_聚会_是否一目了然；samber/dev-event-organizer-skills@event-vip-management 的可见性菜单则决定_宾客_是否一目了然。

这里不要重新排序那个菜单，但要把两者放在一起决定，因为房间一旦公开，即使每个人的徽章都一模一样，宾客名单也会成为一个公开层级。

• 工作量（制作和印刷期限、分发、引发的问题、门口安排人员）：共享凭证 > 带有受邀宾客标签的公开列表 > 门口具名名单 > 仅口头邀请
• 价值，入场管理有效（合适的人能进来，其他人都进不来）：门口具名名单 > 共享凭证 > 公开列表 > 仅口头邀请
• 价值，不会显得像一个层级：仅口头邀请 > 门口具名名单 > 共享凭证 > 公开列表
• 效率：门口具名名单 > 仅口头邀请 > 共享凭证 > 公开列表

支配关系检查：四个档位，六组配对，存在两组真正的严格支配关系——这个菜单经过仔细检查后没有问题，也是三个菜单中唯一一个原本可能出现问题的菜单。

门口具名名单在两个价值维度上都优于共享凭证，且工作量更低；对比公开列表时也是如此。效率排序兼顾了这两点。

其余四组配对中，有三组因价值维度方向相反而无法排序：

• 共享凭证与仅口头邀请。
• 公开列表与仅口头邀请。
• 门口具名名单与仅口头邀请。

有一组配对，即共享凭证与公开列表，则因成本而无法排序：凭证在两个价值维度上都更优，但成本也更高。

在门口具名名单与口头邀请的配对中，具名名单在入场管理方面占优，口头邀请则在隐私方面占优，因此只有效率比率能对二者排序。

这里没有列出合规成本维度，而且省略它是有充分理由的：逐档来看，它会完全重现「不会显得像一个层级」的排序，只多出一行，并未增加信息。它本应体现的是两者的不对称性，而这应当体现在各个档位本身——凭证可以在下一届撤下，而印在节目单里的房间信息则无法撤回。

• 实名名单——默认选项。一人拿着一页名单在门口把关。邀请由同一人逐一私下发出。
  • 对外只有一扇关闭的门和一个站在门口的人，除此之外看不出任何信息。
  • 它在适用性上遥遥领先：只有这一档真正能把好门禁；在谨慎程度上仅次于什么都不做。
  • 某专业协会自己的参展商政策也将同一原则规定为一条规则，而非偏好：贵宾套房仅限活动主办方邀请进入，且绝不得使用主办方自己的参会者名单来宣传该房间。
  • 需要一人全程把守，并打印一页纸。名单页面、应对话术，以及名单上没有某人时的处理方式，都在参考文件中。
• 仅口头邀请——没有名单、没有门、没有实物。谨慎程度最高，效率排名第二：几乎不费力，也没有任何可能泄露的东西。代价是，如果设有门禁，就只能靠认脸把关，这是最糟糕的准入规则——它恰恰会拒绝掉团队里没人认识的那个人。
  • **晋级条件，以 Q5 为准：**只要 Q5 确认没有人提出要求，此选项就成立。没有相互竞争的要求，就没人需要质疑名单是否站得住脚。
• 共用凭证——腕带、代币或徽章标记，持有者即可进入。这一档通常不予考虑，严格劣于实名名单：需要更多精力；一旦有人借出或复制，门禁效果就更差；而且参会者会将其视为等级标志，并在整个公开活动期间佩戴。
  • **晋级条件，以 Q7 为准：**只有 Q7 确认团队中无人能在门口把关时，才考虑此选项，因为聚会是在由他人负责工作人员的场地举行。工作人员看不懂的名单无法用于门禁。凭证是场地自己的工作人员唯一能够核验的东西。
• 带有“仅限受邀嘉宾”标注的公开日程——房间出现在日程中，并标注为仅限受邀者进入。这是另一档通常不予考虑的选项，劣于实名名单且效率最低：它向所有人公布房间，却无法控制任何人，还会引来一波波请求，之后你还得逐一拒绝。
  • **晋级条件，以 Q8 为准：**当 Q8 确认房间已经刊载于人们能看到的材料中时，才考虑此选项。此时，刊载信息并非你正在做出的选择——它是在描述已经发生的事，剩下要做的是调整措辞，而不是做决定。
• **如果 Q3 提到任何一位要求不被辨认、列入名单或拍照的宾客，则删除：共用凭证和公开日程。**从此菜单和上方的坐标轴条目中都删除这两项。宾客会在公开活动期间佩戴的凭证，以及节目单中提到的房间，都恰好会公开该宾客要求不要公开的信息；无论如何措辞，都无法补救。

菜单 C——相对于公开日程安排位置

房间何时举行、位于何处。分为三档，因为是否安排在活动间隙是菜单 A 的决定，不会在这里重复出现。

• 精力投入（另一个场地、交通、出行前确定人数、预订房间、主办方的夜间活动）：在另一个场地另设一场晚间活动 > 最后一场活动结束后，在主场地的一个房间内举行 > 利用现有的休息或用餐时段，在侧厅举行
• 价值，实际进行的交谈（人们到场、留下并交谈，且不受时间限制）：在另一个场地另设一场晚间活动 > 最后一场活动结束后 > 利用现有休息时段
• 效率：利用现有休息时段 > 最后一场活动结束后 > 在另一个场地另设一场晚间活动 **优势检查：三个层级、三组配对、没有严格优势关系——一种机制，即成本权衡，可以解释全部三组。**价值轴与付出的努力完全同序——投入越多，谈话就越深入——因此，每组配对的结果都相同：更忙的层级在谈话深度上占优，在付出努力上则处于劣势。这属于 Menu A 为两组成本权衡配对所定义的“受成本而非对立因素阻碍”类别，而不是两种相互牵制的独立利益。

客人不在场是否会被注意到，在这里不是第二条独立轴线。它与努力的反向排序完全一致。若将其与谈话深度并列展示，就会让“没有优势关系”的结果看起来像是两种利益相互冲突，实际上却只有一条轴线及其镜像；这样一来，效率排序就会以一种看似有依据、实则没有依据的理由，改为按成本从低到高排列。

谈话深度轴仍保留在图中，因为它承载着每个层级的实际论据，尽管它本身并不影响优势判断：它在定义上与努力轴一致。效率排序依据以下论据确定。

这里没有合规成本轴，而且跳过它是有理由的：房间所在的位置不会触发任何因房间位置改变而发生变化的审核。本主题确实会触发的审核针对的是名单和入口；它们已列入 Menu A 和参考文件。

• 在现有的休息或用餐时段，于侧厅举行——默认选项。它在性价比上胜出，原理与 Menu A 的折叠项相同：只有当对话所带来的深度仍然非零时，几乎不增加投入的做法才有价值；即使时段很短，也能带来真正的交流，因为场地和人员本来就在。它真正的局限在于交流深度：休息结束时，对话可能还没结束。
  • **晋级条件，以 Q3 为准：**当 Q3 表明房间的用途是让一群指定人员交谈，而不是打招呼时，提升一个等级——休息时段适合打招呼，却容不下交谈。
• 最后一场活动结束后，在主会场的房间举行——价值维度排名第二，投入维度也排名第二，因此性价比不会拔得头筹；但对于需要真正场地的大多数活动，这应该是最终选择。它能让大家不受时间限制地交谈，同时仍留在同一栋楼里。它有一个需要留意的特定风险：如果安排在面向所有人的晚间活动时段，就会把那场晚间活动变成安慰奖场次——这是按日历安排才会落到的档次。
  • 实际活动制作也会在整个晚间日程上运用同样的逻辑，而不只是针对这一个房间：由指定的活动制作人按受众而非场地安排多晚会议——新参与者之夜、高管／VIP 之夜和普通入场者之夜各自安排在不同晚上，而不是争用同一个晚上。
• 另选一个晚上，在另一处场地举行——最不划算的选项：投入最高，对话维度也最高，但效率评估永远不会选它。此选项有两个晋级条件，应分别评估，而不是合并为一个触发条件。
  • **以 Q4 为准：**当 Q4 指出的宾客可参加时段与活动当天的所有时段都不匹配时，晋级——此时只有这一选项，或干脆不办。
  • **以 Q9 为准：**当 Q9 表明场地没有不会被当作会议室的侧厅时，晋级。这是缺少场地资源，而非个人偏好；也是唯一一种只有场外场地才能实际提供私人聚会空间的情况。
  • 在确定任何场外方案之前，记录其硬性运营限制——固定容量、只能在非高峰时段使用、场地对非日常服务收取附加费——而不是只停留在“已联系供应商”。等到邀请发出后才发现不可接受的条件，代价远高于比较阶段发现同样的问题。
• **如果 Q7 表明指定负责人当天还要负责主活动，则删除：在另一处场地另选一个晚上举行。**从此菜单和上方的坐标轴中都删掉这一项。第二处场地涉及交通安排和固定人数，需要有人负责；如果没有空闲负责人，这份工作就会落到当天的组织者身上，而他们还得负责活动——这会连带拖垮主活动。

失败模式

• 将私人聚会安排在公众晚间活动的对面。 每个人都能看到有趣的人去了哪个房间，公众晚间活动就成了安慰奖。如果两者都存在，就不要安排在同一时段。一场有记录的会议接待活动曾因相反的排期问题而流失了大部分预期宾客：接待活动开始前一小时，上一场活动就已结束，参会者离开了大楼，不愿等候这段空档。让房间空下来的原因是排期衔接本身，而非私人聚会的特殊性。
• 为一个无人能说清目的的聚会建名单。 Q3 的后半部分就是为此设置的，而诚实的答案通常是折叠。
• 限制已售出席位的数量。 在签署的协议中承诺的聚会属于交付内容，将分配规则套用到这类聚会上，是披着公平外衣的违约。将其交由 samber/dev-event-organizer-skills@event-sponsor-fulfillment 处理，并从名单中移除。
• 让席位数量决定名单。 容量是约束，绝不是标准。房间容纳人数少于聚会目的所需人数时，应有意缩小聚会目的，而不是让场地决定谁更重要。
• 由不掌握名单的人发出邀请。 这是聚会席位承诺超出实际容量最常见的原因，也最难补救，因为已接受的邀请无法悄悄撤回。
• 让凭证流入公众活动。 如果宾客整天都戴着腕带，那就形成了一个你并未决定要设立的可见等级，所有未获腕带的参会者都看得出来。
• 重新判定宾客是否符合资格。 这项审核属于 samber/dev-event-organizer-skills@event-vip-management，它规定的是一项义务，而不是一个头衔；在这里重新审核，会让同一项判断出现两个负责人。
• 名单在活动结束后仍然保留。 含有饮食需求答复和引用要求的席位名单，属于包含具名个人信息的记录。名单创建时就应在同一轮处理中按名称确定删除日期。
• 拒绝时没有依据。 拒绝若没有规则支撑，就会显得是在评判被提名者本人；这种做法会为了一个本来没人会记得的席位而损害关系。
• 聚会被视作由赞助商安排的会议。 演讲者与合作伙伴共进晚餐的目的可能是非正式交流，但只要参会者怀疑席位是为换取接触机会而售出的，它就很容易被看成一笔交易。应以书面形式向受邀者和申请席位者说明区别：这是建立关系的聚会，不是代表赞助商安排的会议。

衡量指标

业界没有针对这四项信号的校准标准。请在活动开始前设定自己的目标，收到数据后绝不要调整。

• 每位申请方都收到答复，且答复均引用同一规则（二元）。 将名单中的提名字段与 Q5 列出的各方逐一核对。任何没有记录答复的申请方，都是一项发现。
• 保密性得到保障（二元）。 没有任何要求不公开身份的宾客被普通参会者识别为曾到过该房间。任何涉及他们的已发布照片、名单或凭证，都直接判定为不合格。
• 承诺的席位数与实际席位数相符（二元）。 发出的邀请数不得超过房间的容纳量。只要有一项承诺超出容量，就说明邀请是由不掌握名单的人发出的。
• 名单删除（二元）。 按规定日期删除席位名单，并由具名负责人确认。

调用示例

• “两位赞助商和一位主题演讲嘉宾都要求我们为创始人午餐会增加一位人选。我们该如何决定，又该如何拒绝其他人？”
• “我们想找一间小会议室，让我们的资助官能真正和三个人交谈。该安排在什么时候？要告诉别人有这么个安排吗？”
• “市场团队想在日程中列出一场仅限受邀者参加的招待会。我们的会议明确倡导平等。该怎么办？”
• “我的团队中有人已经答应了一位赞助商，但会议室的座位数少于我们目前邀请的人数。”

预期输出：一份聚会简报，包含：

1. 这间会议室能实现什么，而常规晚间活动无法实现；或者说明这一问题无从成立。
2. 名单构建规则及其人数上限或筛选标准。
3. 名单本身，包括字段、指定负责人、传阅范围和删除日期。
4. 邀请与入场机制，包括门口页面。
5. 活动安排，以及交给流程表的时间段。
6. 在首次提出请求前就写明的拒绝规则。
7. 交接事项。

按章节逐一提交审批。如果菜单 A 落在折叠页面下方，输出就只包括这一发现以及折叠页自身的机制，不包含其他内容。