婚礼回执的下一问，为何会随着前一个回答改变

婚礼宾客看到的回执表，未必每个人都有完全相同的问题。Joy的What Is Smart RSVP把Smart RSVP定义为依来宾回答调整后续提问的回应系统。它采用条件逻辑：某个回答成立，后面的相关问题才出现；另一种回答则可能让这些问题保持隐藏。这个结构改变的是表单的提问路径，不是把所有宾客的答案预先分成相同内容。

最直接的分支来自是否参加。页面说，接受邀请之后，可以显示只与确认参加者有关的后续问题；婉拒时，这些问题不显示。前一个答复因此成为下一问的条件。若资料只写“表里有交通和住宿问题”，还没有说明这些题是否会向每个人出现，便省去了原厂介绍中关键的可见范围。

How Smart RSVP Works把这种联系称作if-then结构。它不同于一张从第一页到最后一页都固定排列的表：固定表把问题一起列出来，条件表则让部分项目依赖先前回答。本文在这里解释信息关系，没有搭建或测试表单，也不采用页面关于回复更快、准确率提高等营销性结论。

携伴姓名提供另一种具体例子。Joy说，当宾客确认携伴时，条件字段可以提示补充这位同行者的全名。确认携伴与写出同行者是谁，是先后相连的两项信息。姓名字段出现，并不意味着姓名已经填写；它不出现，也不能脱离前面的回答路径，直接认定某位宾客拒绝提供资料。

多活动的显示还有邀请范围这一前提。页面将排练晚宴、欢迎聚会或早午餐作为婚礼周末的例子，说明系统可以分别询问，并只显示某位来宾获邀参加的活动。因此，前一回答触发后续题，与该来宾原本被邀请参加哪些活动，需要分别理解。一个活动没有出现，不必然就是已经收到该活动的婉拒答复。

交通与住宿题同样被放在确认参加者的范围内：可以询问是否需要接驳或酒店房间信息，而对婉拒者隐藏。假设一份纯说明的回执记录中，有人确认参加后才遇到接驳问题，就应把是否参加与是否需要接驳留为两个回答。这是依据字段关系设的阅读例子，没有真实名单、车辆安排或房间预订。

对婚礼策划资料而言，条件分支的重要内容，是某个问题在什么前提下可见、它又期待哪类信息。邀请范围、参加回答、携伴确认与姓名并不能只压成一个“已回复”标签。本文采用Joy当前公开文字，首发日期未知，不使用饮食健康实例，不保证回复率或出席人数，也没有发送邀请、处理个人资料或判断供应商合同。