第 25 篇已经给每日流程加了生产检查。接下来要把日报送出去。第 26 篇先不接飞书、不接邮件只做提醒通道抽象。消息怎么生成是一回事发到哪里、是否被接收是另一回事。先稳定发送接口提醒通道最容易一开始就写死。今天发到文件明天想发到飞书后天又想发邮件。如果日报生成逻辑直接依赖某个具体通道后面改起来会很别扭。回执对象第 26 章新增app/notification_channels.py。dataclass(frozenTrue) class NotificationReceipt: channel: str accepted: bool destination: str message_title: str sent_at: datetime error: str 发送动作必须有回执。没有回执就无法在后续健康报告里判断提醒是否真的被通道接收。这里的“接收成功”只表示通道层愿意接收这条消息不等于读者已经看到消息。真实系统里通常还会继续拆成发送成功、平台回执成功、用户已读等更细的状态。第 26 篇先保留最小语义消息是否被通道接受。通道协议class NotificationChannel(Protocol): name: str def send(self, message: PaperAlertMessage, *, destination: str, sent_at: datetime) - NotificationReceipt: ...这个协议很小只约束输入消息、目的地和发送时间。具体通道可以是文件、飞书、邮件也可以是测试用的内存实现。当前联动运行结果第 26-30 篇现在可以通过同一条命令运行uv run python -m scripts.chapter_examples paper-notify这条命令会先生成目标权重、取价格、跑每日流程然后把日报发到内存通道和文件通道。第 26 篇关注的是通道协议和回执这次运行里内存通道返回acceptedTrue目的地是paper-daily。这个结果后面会进入运行健康报告成为判断“日报是否真的送出”的依据。本章更新与代码仓库本章更新内容新增app/notification_channels.py。定义通知回执和通道协议。实现MemoryNotificationChannel用于离线测试。增加paper-notify联动示例展示每日流程生成日报后的通道回执。补充通道接收成功与用户已读之间的语义边界。新增tests/test_notification_channels.py覆盖有效消息、缺目的地和空正文。代码仓库https://github.com/ax2/zi-quant-platform本章代码git clone https://github.com/ax2/zi-quant-platform.git cd zi-quant-platform git checkout chapter-26 uv sync --extra dev uv run pytest tests/test_notification_channels.py第 26 章提交为6bf1a6ftag 为chapter-26。本篇小结提醒通道要先有边界再接具体平台。第 26 篇把发送接口和回执结构稳定下来。下一篇会实现一个文件型通道让日报发送在本地也能被验证和回放。