真相、认知、执行，
各自有一个归处。
Friday SaaS 记录业务发生了什么，PAC 把数据整理成可用的患者认知，Friday AI 把认知用在每一次服务里。
2026.10.04
一张图，看清它们怎么协作
点击系统，查看它的职责一个上游，一套口径
Friday AI 需要患者、预约、病历等业务数据时，统一向 PAC 读取。PAC 负责不同宿主的数据接入和标准化，Friday AI 消费同一套契约，不重复建设患者数据中枢。
实线展示已建立的协作路径；虚线展示设计中的写回路径。图中箭头表示职责和信息流。
一条预约，怎么变成服务？
业务系统里的预约，经 PAC 提供给 Friday AI，再由规则生成需要执行的工作。
患者约了哪家店、哪位医生、什么时间，业务事实保留在宿主。
接入宿主数据，统一字段和患者口径，向已授权的读方提供预约信息。
按规则识别需要确认的预约，联系患者；没有绑定微信时，安排电话确认。
患者回话后，谁来负责？
AI 和员工围绕同一段会话协作。需要人判断的事项，交接给责任人。
Friday AI 留存会话、识别联系人与患者的关系，并读取服务所需的上下文。
标准问题可回复，医疗问题、改约等事项交给人；回复发送前经过守卫和发送检查。
在工作台或自己的企微里回复。服务过程留在 Friday AI；预约、病历等真实业务变更由人按业务流程办理。
三条边界，让关系保持清楚
业务事实在宿主
患者、预约、病历、收费由业务系统持有。AI 的判断与任务结果不能自行成为医疗或预约事实。
患者读取经 PAC
多源适配集中在 PAC。未来需要实时号源时，也应通过 PAC 的实时读取契约提供。
服务过程在 Friday AI
身份、权限、组织、会话、待办、交接和审计由 Friday AI 自有。患者档案保存引用，业务事实按需读取。
现状与下一步
现有协作与规划分别标明读事实，做服务
PAC 提供患者上下文，Friday AI 开展接待、交接与预约确认，ECom 承担企微收发。
写回真实业务系统
设计由 Friday AI 的宿主连接器调用合作宿主写接口。当前不能把“患者说会来”当成已更新宿主确认状态。
读取实时业务状态
PAC 的标准化数据有同步时延。实时号源等需求，要增加透传读取能力，不能直接拿历史副本做即时承诺。