工作流的节点捷径已经可以使用deepseek-v3, r1, r1联网, 豆包1.6, 还能自定义模型了。而且deepseek和豆包这些模型都不需要提供API key，目前可以免费使用。【有必要更新一下】
因此：看下能否解决之前周几到周几的计算准确率有限的问题。
示例输入：下下周二去吃火锅
预期输出：2025-09-02的晚上
默认：2025-09-02 18:00
V3：2024-06-25 12:00
R1：2025-09-02 18:00
豆包1.6：2025-12-09 18:00
【从日志中发现除了默认的模型，其余模型传递过去的提示词，时间都变成了UNIX时间戳传递的，所以会导致巨大误差】因此在原提示词基础上补充信息告诉模型这是unix时间戳
默认：2025-09-02 19:00
V3：2024-06-25 12:00
R1：2025-09-02 18:00
豆包1.6：2025-10-28 18:00
综上看到，只有默认和R1能够正确推断时间。进一步提供更多案例（8个）
这周六早上出发去上海
默认：2025-08-24 08:00【弄成周日了】
R1：2025-08-24 08:00
下周六中午吃饭
默认：2025-08-31 12:00
R1：2025-09-27 12:00【R1不符合预期，时间戳转换上有故障】
下周日中午吃饭
默认：2025-08-25 12:00【弄成周一了，特别有规律】
然后：对比了目前A1工作流中拆解的计算方式，还是目前的好，所以结论就是没改动。
工作流中默认的"AI生成文本"使用的模型应该是更新过了，现在是提示：字节跳动自研的云雀模型
由于新增了节点捷径的"AI理解图片"，因此是可以支持A1工作流中识别到输入类型为image的后续步骤了，但是，这一点和用户的场景不匹配（用户的要录入图片的场景分为两种：单独图片/混合图片和文字，也就是对应image/post，而post的消息类型，暂时在工作流中无法被拆分出来post中的图片和文字部分，也就无法进行下去，那么此时这种场景就是被割裂开的，那还不如维持现状，在对话框中输入图片或post，一律都引导到单独的输入界面去）。因此，不做A1和A2的合并。【唉】
【而且，消息内容中的图片，无法把收到的图片存入附件】
【等以后post能被拆分并识别了，可以将A1和A2合并】
很明显，也可以用节点捷径来实现纯语音输入了，也就是audio类型，但是，用户场景通常就是将语音转换成文字录入到备忘录中，但是这里要考虑到一个惩罚系数的差异，用户用飞书的语音消息录入如果识别错误，会导致最开始的转文字就存在错误了，后续步骤出错的影响会被扩大，因此这一点我更倾向于用手机输入法或其他工具让用户自己在这条消息发出之前就转成文字了，避免给到模糊的文字信息
飞书目前的windows客户端，其后台行为非常频繁，占用计算和网络资源，且在没有任何用户行为的情况下，但后台行为就可以在长达12个小时的静置中，徘徊于3%26%之间的CPU占用。所以：如无必要不要运行飞书win客户端挂着后台。【优化和内存管理很差】
switch分支条件中的前端页面始终显示placeholder样式的这个BUG已经被飞书修复了，不过其他那几个BUG一个都没解决
原先：数据表中的字段捷径中心的选择远远多于工作流中的AI操作，本想把全部的AI操作都归纳在工作流中，多模态输入必须借助字段捷径【AI图片理解（豆包），或者 通用文字识别】
现在：工作流中多了节点捷径中心，涵盖的AI操作跟字段捷径中心基本是一致的了。
特别注意：这两个还不是一回事，免费额度存在差异。而工作流中的节点捷径的AI读取链接，是没有免费额度这一说法的，搞不明白。【真是逆天啊】
因此：A1工作流中，原先需要在判断纯链接之后，多一步把链接写入纯链接字段，再触发字段捷径来实现AI读取网页链接，现在只需要在工作流中就可以实现解读了。
但是：本次不考虑改动，因为我不清楚飞书内部逻辑是否还会变化，且免费额度并未说明，存在未知BUG的可能性。
在A1, A2这两个工作流完全未改动的前提下，点进去加载后，就提示发生了修改需要你保存【这一点就十分印证了我之前说的：飞书的内部逻辑发生变化，可能会导致已有工作流出现问题】
节点捷径还能调用扣子工作流了【不过我不会在这上面去开发别的应用了，路径太长，依赖太长，耦合程度进一步扩大，风险实在是太大了】
飞书还能给企业微信、钉钉发消息了【我用不上，有需要的用户自行配置，如果有很多用户反馈需要这个功能的话，可以出个视频教学一下】
飞书工作流前端页面的加载速度快很多了（之前大概20秒，现在1秒钟，提升很大）
