产品通知需求太笼统，Agent 怎样整理触发、接收对象和用户偏好

产品需求写“状态变化后通知用户”，仍缺少几个决定：哪个状态、通知谁、属于哪类消息，以及用户关掉该类提醒后怎样表现。Agent应把它们整理成事件与接收关系矩阵，先明确产品行为，再讨论发送实现。这里不把投递成功与产品规则完整混为一件事。

一条事件可能对应几种身份

场地预约里有申请人、代订人、实际使用人和管理员。它们有时是同一个人，有时不同。收件规则应说明依据哪种关系取人，不是搜索一列“用户ID”后全部发送。若只写通知用户，矩阵要显示缺少接收角色，不直接扩成群发。

每行包含业务事件、对象、接收关系、内容范围、消息类别和偏好策略。业务事件是产品事实，例如预约改期；渠道只是它如何呈现。应用内、邮件或手机通知可以有不同入口，但不应因此产生互相矛盾的业务含义。

官方机制说明1：Android 8.0起通知归入渠道，用户能修改渠道行为；源只支持Android渠道机制。

Android渠道只是具体机制参考，不能推广为所有端的统一能力。它提醒产品团队：某些呈现行为最终由用户设置控制，规格不能承诺关闭渠道后仍必然弹出。其他渠道采用什么偏好，由客户实际应用和规则说明。

合成输入1。 预约被管理员改期，申请人开重要通知但关闭营销类别

预期处置：列事务通知类别与偏好适用，未定类别交产品确认

合成输入2。 代订人为甲、实际使用人为乙，需求只写通知用户

预期处置：并列两种身份待定，不自行全量群发

合成输入3。 每日摘要与单条提醒同时覆盖同一预约

预期处置：指出产品层重复触达策略缺口

第一条需要先确定改期消息的业务类别，不能看到用户关了营销就推断事务提醒也关闭，或反过来无视所有设置。第二条需要产品决定代订和实际使用关系；接收人不同，所需说明也可能不同。第三条则是同一预约既出现在摘要又有单条提醒，要求定义产品层频次，而不是靠技术去重随机丢一条。

改期通知可以需要原时段、新时段和查看入口，但是否显示申请备注要按接收角色说明。矩阵中的“内容”不是让模型自由写一段话，而是获准事实字段和需要用户采取的动作。这样同一事件在不同渠道改写时，核心事实不会变化。

用户偏好也要有适用范围。只控制声音、不控制应用内记录的设置，与完全退出某类消息不同；没有材料时先列待定，不能把一个开关解释成所有渠道的全局同意或拒绝。营销名单和法律同意判断并不属于本题。

从一条改期事件查应出现哪些候选通知，再从代订人或使用人反查他应该看到什么，能帮助发现重复、遗漏和身份混用。实际发送与回执另留验证，不在静态规格上填已送达。

如果已有通知中心能维护模板和渠道，定制助手可以只负责从PRD、角色关系和偏好说明生成审阅矩阵。讨论时拿同一预约的三种输入让产品人员独立判断；无法一致回答的行，就是本期最值得先澄清的产品工作。

单条改期提醒与每日摘要可能各有用途，不能只因业务对象相同就删除其一。矩阵记录摘要覆盖的是哪些事件、单条提醒是否仍有时效意义以及偏好作用在哪一类，产品据此选择保留、合并或提供设置。助手给的是冲突位置，不预设某个频次更合适。

代订案例可以沿关系反查：同一条预约的提交者、使用者与管理员分别需要哪项事实。角色未明确时，先要求补接收关系，而不是复制所有字段给所有人。类别未批准时也保留原词，避免助手先把消息归类，再拿自己的分类解释用户设置。这样通知规格才能成为可讨论材料，而不是一组未经确认的发送命令。

下载本题合成输入与可填写工作表。附件保留实际结果、复核人和证据位置空栏。