DSH还是太全面了，我直接给他做了个邮箱插件
起因是我的邮箱比较多，设备也比较多，有时候在不同设备上查收邮件有点麻烦
正好dsh现在可以直接网页访问，等于我在任意设备上访问都可以看到这些邮箱，所以直接参考Gmail来做了一版本，
没想到效果这么好哈哈哈
51
发现个新思路来解决Obsidian同步的问题
直接转到DSH！
缺少插件就自己干，或者让Agent翻译一下Obsidian插件到DSH
再给DSH配个DDNS + 域名，随处都可以用域名访问自己电脑上的DSH和文件
1
1
234
Skill的可复制、可迁移性质很容易导致这种问题
之前应该也有人搞过远程Skill，需要授权后才可以访问，不过现在很少看过，说明不是很好用
在我看来，后面可以多做应用，少做Skill，Skill即应用。
把自己领域的SKILL深度定制成应用，还能上架赚钱
气死我了！今天发现，我的好几个 Skill 被 WorkBuddy 改名换姓上架了。
WorkBuddy，搬运我的开源 Skill，为什么连作者署名都省了？
完全没有获得商业授权，为什么能上架我禁止商业使用的 Skill？
甚至都不敢用我的 Skill 名称，拙劣地改了名字直接上架？
目前已经发现的有四个。
1. Lieflat Charts（github.com/larashero3-dotcom…）
在 WorkBuddy 上，展示名称被改成了“模板图表与报告”，截图里的标识是 `wbzl-lieflat-charts`，还给我加上了面向 Workbuddy 中文用户，谁允许你们用这种方式改编？
这个项目采用非商业使用许可，商业使用需要另行取得授权。请 WorkBuddy 说明，收录的是哪个版本，依据什么授权将它集成到产品并提供给用户使用？
2. Lieflat Gongwen （github.com/larashero3-dotcom…）
在 WorkBuddy 上，展示名称变成了“公文语料写作教练”。
这个项目同样采用非商业使用许可，项目说明明确写了，未经单独书面许可，不得集成到商业产品或商业服务中。请问，上架前有没有核对这些条件？对应的授权依据是什么？
3. 去 AI 味（lieflat-less-ai-tone）github.com/larashero3-dotcom…
到了 WorkBuddy 上，展示名称变成了“AI写作痕迹清理”，完全没有我的署名。
4. 写作 DNA 蒸馏器（writing-dna-skill）github.com/larashero3-dotcom…
安装前的展示页面里，我没有看到作者和原项目来源。安装之后，在正文底部能看到原项目链接和 MIT License 标注。
但作者和来源，为什么不能在用户选择、安装这个 Skill 时就清楚展示？为什么需要安装后翻到正文底部，才能看到出处？
自己花时间写的东西，被放进别人的产品里，换了名字，用户看到了可以直接安装，却不容易知道是谁做的。作为作者，这个感受非常糟糕。
我把作品公开分享，贡献给开源社区，使用条件写得非常清楚，也希望这些条件得到尊重。怎么到了产品上架的时候，内容拿走了，作者署名和使用限制却没有得到同样的重视？
我希望 WorkBuddy 正面回应：
- 说明这四个 Skill 的来源、收录时间、具体版本和授权依据。
- 补全作者署名，在安装前的详情页明确标注原项目链接及许可信息，说明名称和内容做过哪些修改。
- 逐项核查使用许可，停止不符合许可条件的使用，该下架的下架。
- 对涉及未经授权商业使用的项目，说明使用时间、范围及相关分发情况，承担相应责任，并就损失赔偿及合理维权费用提出处理方案。
- 说明以后如何审核来源和授权，避免其他作者遇到同样的问题。
请尊重开源创作者的创作，遵守资源使用规则，珍惜产品口碑。
2
214
之前看到乔木的qiaomu-design项目，感觉挺不错的，自己模仿着做了一个banana-studio，主要服务定位是做自媒体用。
目前支持的功能：
1.封面、配图设计，支持60+模板，Agent可以根据文章内容自己选择对应的风格模板进行生成，包括配图标题的设计。 构思和生图通过不同的模型来进行搭配生成。这里的图片生成方案和乔木老师的其实是不一样的，我这个是直接生图，把这个交给提示词，乔木老师的则是由模板控制，整体样式更好控制
2.发布功能。 目前支持微信公众号、推特的发布功能。其中微信公众号主要是通过api的方式，并支持设置服务器中转来避免家庭宽带的IP变更。推特则是官方api模式
项目地址发到评论区
1
1
113
今天把Agent的上下文好好的理了一波
怎么理解这个事情？
就是当很多记忆、文档混乱的放置在各处，Agent很有可能会读取到这些错误的判断、记录，导致做出错误的理解和推测，最终影响任务结果。
所以需要设定一个规则方案让上下文具备可迭代、可恢复，多Agent读取表现一致。
举个例子，比如访问推特帖子，以前我可能用的是twitter cli，并且安装了对应的skill，这个时候让Agent去访问推特，自然而然会去调用这个CLI。
不过后来发现可能导致封号，所以又换成了浏览器方案，之前的Twitter CLI方案并没有被推翻或者并没有被更正，就会导致有的时候Agent还会使用CLI来访问。
这个时候上下文的注入清理就很重要，要把这些历史包袱给收编掉，避免把错误的信息都放进到上下文。
我这里的方案就是建立一个统一的中心上下文，不额外写文档，每次读取的时候只看最新的内容，写入则需要用户确认后才可以。最终形成的上下文才能是凝练、有价值的。
3
216
以前最早看到逆向还是在吾爱论坛里
现在配个顶级Agent 都能自己逆向护城河这么深的应用了
AI这个杠杆牛逼坏了
i think the coolest thing about rea is everyone contributing what they're working on
i'm seeing people work on agriculture tech, cars, drones & all manner of consoles
rea today isn't perfect but together we're putting it all together
thank you to all our contributors!
114
