[日志整理] 不要重复造轮子

type

Post

status

Published

date

Jul 6, 2026

slug

260706

summary

设计最终是为了满足需求而非炫技，流程每多一环，失效的风险越大

前言

当我们着手实现某个想法时，也许会历经前所未有的困难，遭遇数不清的挫折，甚至一度迷失方向、陷入沉思——但回过头来不妨想想：这个想法，是否本可以用一种更简单的方式来实现？
——MC 260706

最近状态不太好。广州的天气阴晴不定，心情和精神也跟着起伏，谈不上稳定。

最初的想法是以 Hermes 作为统一入口，整合任务归集与想法记录，构建一套 Hermes + n8n + Pushcut + Shortcut 的自动化工作流。思路听起来不错，但落地过程堪称一路踩坑。

1. Hermes 的触发模式差异

Hermes 目前主要有两种触发方式：OpenWebUI 的 API 模式，以及微信的 Gateway 模式。两者在路由分发上存在明显差异——OpenWebUI 无法灵敏地调用 Skills，只有微信模式可以。这个问题前期并不显眼，却在后续引发了大量的 JSON 编写工作。

2. Pushcut 的字段限制

最初自定义了 JSON 字段结构，数据库跑通、Pushcut 也打通之后，才发现推送内容根本不显示。回头仔细翻文档，才意识到 Pushcut 只支持特定的保留字段——这个坑完全可以在设计阶段就规避掉。

3. Shortcut 的读写难题

Pushcut 只负责将 JSON 推送过来并触发 Shortcut，而 Shortcut 本身极难上手。"读取数据并写入提醒事项"这个环节，最终没能搞定。

4. Hermes 插件注册机制

发现 Skills 和 Plugins 的调用还需要在底层进行注册，又花了大量时间编写插件，期间遇到若干细节 Bug，反复修复调试。

经过层层简化，最终实现的功能是：在微信窗口输入指令（如 /task 提醒我晚上 22:30 准时睡觉），Hermes 通过插件生成 Cron 脚本，提前 15 分钟将消息推送至 n8n 的 Webhook，最终在 Pushcut 中显示这条提醒。

说实话，功能本身非常轻量——本质上只是一个统一接口下的简单提醒，连持久驻留都做不到。但搞完之后确实感觉挺新鲜的：Hermes 第一次有了实质性的控制作用，也真正打通了 Apple 生态的推送链路，算是一个有意义的起点。

投入了大量时间和精力，换来的却是一个轻量提醒——问题的根源，还是思路设计与技术可行性之间的脱节。

回过头来看，有几点值得记录：

信息场景分层处理更合理。 对于领导布置任务这类信息密度高、留存时间长的场景，最好的做法还是先用笔记下来，再交给 Hermes 做标准化存档（如发邮件归档），最后再流转至 GTD 工具或 Obsidian 中跟进。

计划永远大于执行，是当前最大的瓶颈。 工具再精妙，没有持续执行的能力，也不过是海市蜃楼。不能"为了一瓶醋，包了一顿饺子"——本末倒置，才是最应该警惕的地方。

技术攻坚对自信心的消耗是真实的。 每次遭遇几乎无法逾越的技术壁垒，都会有不小的挫败感。但这次也真切地看到了 Hermes 的潜力：借助 Pushcut 与 n8n，还有很大的探索空间，甚至可以结合智能家居做一些小型自动化。

折腾技术的人，内心大多是孤独的。就这样吧。

今天基本没读书。最近对文学的阅读热情似乎又退潮了，那种可以慢慢品读的心境，暂时找不回来。这段时间主要在复习模拟电路、理解相关概念，偶尔背背单词。总之，还会 emo 一阵子。

最终的设想，依然是围绕 Hermes 强大的理解与编排能力展开——在信息收集与处理、习惯养成，乃至知识加速理解等维度上持续探索。

希望能真正沉下心来，专注于自身的成长，减少对不可控之事的消耗，把生活一点一点结构化起来。