@bytewalk #9 emmm 个人觉得相对没那么占用吧，毕竟得在电脑上播放视频。我的标准是风扇不响就行，对比其他应用，和你的邮箱钉钉都差不多。能接受的话 我觉得挺养眼的哈哈

@bytewalk 这个不是 windows 的 wallpaper 。你说的应该是最近 windows 的 wallpaper 下架应用模块的事吧。
这是另外一个 Mac 上的 APP 。它不支持 wallpaper 那种内置一个应用，就是一个很单纯的动态壁纸应用

@Varusteki 我相信你能找到免费的办法，当然你也可以先试用，真的很漂亮（无推广，单纯喜欢）

@rainfox 你逛分享区就为了找喷？

@rainfox ？？我贴了什么邀请码了吗？张口就来？

@catinsides 使用场景不一样，Openclaw 和 Hermes 对我来说不是生产力工具，但很适合当日常助手，玩玩项目收藏、新闻日报啥的、记一记笔记啥的。

但是这俩的更新都有点往 Codex Claude 的方向靠，作为日常助手有点臃肿了说是。

这都成日经帖了： https://blog.1874.cool/stable-vibe-coding-workflow

@smileeast 可以，我试试你这个。我目前 Token 比较充足，所以还在用，只不过很少用它来走完整流程。

@tudouxiong 他们的代码中还专门针对表格和其他各种各种有专门文本处理逻辑，但内核是文本消息的话，怎么适配都不能解决根本问题。我改成 Cardkit 后，是没有做任何额外的适配处理，直接输出的原文。目前体验一切正常。

@tudouxiong 没用的，他们底层没有使用 Cardkit 来渲染，走的是文本消息，所以表格的体验一直很差，这也是我为什么选择自己改代码。

社区 issue 中其实有很多已经实现的 Cardkit 设计，我也是参考了他们的设计来开发的。

@sesshomaru0 Openclaw 和 Hermes 的消息渠道插件架构不一样。

OpenClaw 有第三方飞书插件，自己也内置飞书插件。他的在飞书上的消息都已经是 Cardkit 模式了，对 Markdown 的支持都很完善。但还有 bug 。

Hermes 的飞书插件没有第三方的，内置的飞书消息发送渠道是跟着源码走的。我大部分改的还是飞书消息 Adapter 本身。但是有一些功能我必须得改 Hermes 的源码才能实现。

我之所以用 Hermes 是因为
1. Hermes 的消息输出模式我更喜欢一些
2. 改动 Hermes 的代码然后更新到自己的服务器上比 Openclaw 简单一万倍。。。。。
3. Openclaw 的飞书插件也有问题，但是我改完想自用测试，简直是地域，还得编译，还得打包（因为他是 TS ）
4. Hermes 因为是 Python 编写，服务器上的源码就是本地代码，我直接改 origin 就能替换成我自己的代码

当然 Hermes 也有一堆问题

他的自我进化对于我的使用场景 简直是地狱，特别是 SKILL 的自动生成非常烦。我反复横跳过一段时间，最后还是选择 Hermes ，然后把自我进化相关的功能都关了，目前使用比较稳定。

怎么得出的结论。。。

？我的好着的啊

@little_cup 我感觉 你可以总结下他的 过度的防御式编程 规则,然后把不想要的规则写进本地文档,然后在一开始聊天时让他读一下,放到上下文应该能解决一部分

@1874w 如果这些本地文档不想提交到远端仓库 或者 污染提交历史,可以参考我的这篇博客来设置 git 忽略

这样 Vibe Coing 过程中产生的项目本地文档, 甚至可以放更多私人流程和信息,而不用考虑会被 AI 提交到远端仓库


https://blog.1874.cool/vibe-coding-mid-doc

我个人觉得大部分是人的问题.

如果始终是许愿式开发.评价体系为 AI 能一次猜到你想的 = 聪明,猜不到 = 不聪明

那任何模型应该都存在这个问题,除非他能接你的脑机接口,知道你脑子里的全部上下文

而且由于变量的不同,会有一些可能存在的错误判断.

比如在 Claude 中聊问题 A, 发现他能很快明白你的描述,解决你的问题.

后面 换到到 Codex 时,聊的是问题 B,但是他没能立马明白你的描述,得聊多轮才能解决你的问题

所以得出的结论: Claude 比 Codex 聪明.或者 Codex 降智严重

但实际上有可能同样的提示词放到 Claude 中也未必能立马解决问题 B

==========================================================

所以我个人感觉许愿式开发,总的来说是不稳定的,除了模型本身的能力是一个影响因素外,一个相对稳定的工作流是很重要的, 最重要的就是得让 AI 知道你当前问题的足够上下文.

理论来说用能力相对低一些的模型 + 稳定工作流 也能解决你的问题.

superpowers 的 Brainstorming SKILL 本身的设计理念,就大概是这个意思. 当然毕竟它比较重和费 Token,不是所有问题都得用 superpowers 来解决.

所以 AGENTS.md/CLAUDE.md 和一些你本地的文档,都是非常重要的上下文.

我日常使用时,基本都会让 AI 把稳定的流程固定成本地文档.

例如和他聊完当前项目是怎么部署的,怎么修 bug 的,项目的架构等等文档,都可以在聊完之后让他沉淀成固定文档.下次让他读这些文档就知道怎么开始了.

之前在 X 上也看到一个方法论:

在和 AI 聊完和并改完 BUG 之后,可以再最后问 AI 一句: 如果回到一开始,我该怎么和你描述,你才能一次性解决这个问题

感觉可以试试,也能学习到该如何和 AI 进行交流

Hermes 原来的飞书消息

https://i.imgur.com/93WZJiX.png


我更新后的

https://i.imgur.com/nrf9xI6.png

目前我自己更新了以下功能

1. 私聊场景不带回复引用,群聊/话题群不受影响
2. 流式输出和工具 Cron 输出使用飞书 Cardkit 卡片展示

其他的全部保持官方代码没动过

重置了，刚重置的