早上七点的样子是这样的：
谁在哪个房间，他们何时退房，前门锁还剩多少电量，以及有两个知识库主题重复了。所有这些信息都已经存在于我用来管理房源的软件中。
但那里没有这条消息。所以我构建了生成这条消息的工具。
（截图使用合成数据以保护客人隐私。）
为什么
我经营着一处短期租赁房产：一处物业，在 Hospitable 上有三个房源列表，包括整个单元以及单独出租的两个房间。我在早上七点面临的问题是：今天是否有任何我需要处理的事情，以及应该先做什么。有四个障碍阻碍我获得答案。
查看状态需要切换四个屏幕。 先打开应用程序，然后查看收件箱，接着看日历，最后查看设备页面，仅仅是为了确认一切正常。大多数日子里，这就是答案。由于成本太高，我检查的频率低于应有的水平。
应用程序并不总是通知我。 如果登出账户或错过应用程序更新，推送通知就会停止送达，且没有任何迹象表明它们已停止。我发现自己错过了需要关注的事项。我意识到“没有收到通知”并不等同于“没有发生任何事”。
没有任何优先级排序。 仪表板就像一个信息流，上面的所有内容都具有相同的视觉权重。电量仅剩 12% 的门锁和重复的常见问题解答条目看起来同样紧急。我希望在我阅读之前就已经完成分类整理，而不是在阅读过程中进行。
没有任何交叉引用。 预订、咨询、评论和门锁状态各自位于不同的屏幕上，彼此之间相隔三到四次点击，每次切换都需要加载时间。任何需要同时查看两项信息的情况，我都必须在脑海中拼凑，其中一半的精力花在回忆一小时前浏览过的屏幕位于导航栏的哪个角落。
工作原理
五个组成部分：
- Hospitable 应用程序接口（我的物业管理系统的代表状态传输应用程序接口，只读令牌）
- 亚马逊网络服务 Lambda（在无服务器环境下按计划运行代码）
- EventBridge（定时触发器）
- 亚马逊网络服务 SAM（将亚马逊网络服务资源声明为模板）
- 电报机器人应用程序接口（消息投递）
其中没有任何大型语言模型，每项检查都是确定性规则，且令牌没有写入权限，因此我能发布的最糟糕的错误也不过是一条错误的消息。
一次完整的运行流程，从头到尾：
获取数据。 五个端点，分页处理。消息端点似乎允许两个请求
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
