Forwarded from 轻惋养生 🍵 (Misskey Telegram Bridge)
Misskey Timeline Update
最近 Telegram 搞了个新东西——类似 Cloudflare Workers 的无服务器边缘函数，自带 JS 运行环境和数据库。目前看是完全免费，请求次数也不限，挺香的。
不过也有几个槽点：
1. 没法"延时干活"。我试了半天，没找到让机器人过个几分钟再自动跑下一步的办法，也没法让它先"睡一会儿"再继续。而且单次请求最多只能跑 30 秒。
2. 还是绕不开官方 bot-api。文件超过 50MB 就传不了，MTProto 协议的底层接口也调不了，能玩的花样少了很多。
3. 无法使用任何外部 npm 库，甚至有些内置的类，比如 URL 都没法用，比 Workers 还精简属于是。
总的来说，目前只能写点简单的小机器人。这功能现在只对大会员开放。
https://core.telegram.org/bots/serverless
深海小涛 发表于 2026-09-08 00:28:04
点赞: 0 | 回复: 0 | 转发: 0
最近 Telegram 搞了个新东西——类似 Cloudflare Workers 的无服务器边缘函数，自带 JS 运行环境和数据库。目前看是完全免费，请求次数也不限，挺香的。
不过也有几个槽点：
1. 没法"延时干活"。我试了半天，没找到让机器人过个几分钟再自动跑下一步的办法，也没法让它先"睡一会儿"再继续。而且单次请求最多只能跑 30 秒。
2. 还是绕不开官方 bot-api。文件超过 50MB 就传不了，MTProto 协议的底层接口也调不了，能玩的花样少了很多。
3. 无法使用任何外部 npm 库，甚至有些内置的类，比如 URL 都没法用，比 Workers 还精简属于是。
总的来说，目前只能写点简单的小机器人。这功能现在只对大会员开放。
https://core.telegram.org/bots/serverless
深海小涛 发表于 2026-09-08 00:28:04
点赞: 0 | 回复: 0 | 转发: 0
r/nichijou/
古法编程时期，虽然我的水平不怎么样，但是我写东西时一直都是强迫症拉满的，会刻意的雕琢各种代码风格与软件UI细节。如今时代变了，虽然用上了vibe工具，我的习惯却没有怎么改变，依然会刻意的跟ai讲这个地方一定要这样设计不能那样设计，这个函数要抽象出来复用，那个类不能直接改要再新增一个子类... 但是渐渐地我发现，这样扣细节不仅会浪费更多的token，还会降低写东西的效率，最后换来的仅仅是一个看起来更好用的软件或者更优雅的代码架构。至于你说代码质量，也没有高到哪去。 那么问题就是，在 vibe 时代刻意追…
即使在古法变成时代，扣细节也是非常让人疲惫的部分，也会由于工程上的因素和 deadline 让人多少会忽略一些次级的目标。
这点从来没有改变过，只是，之前 沟通 -> 实现 -> 不满意，再次沟通 -> 再次实现 之间的时间拉的比较长，显得不是非常拖时间；或者，对于自行实现的代码细节，总的代码生产速度是很慢的，是有时间扣这些细节的。
而 AI 时代，很容易被拉爆，吭哧吭哧写半天 prompt，哪怕说也要想一会儿吧，说的速度极限也就是敲字的 3x，但是要想，还要修订一些专有名词问题。这个时候变成了 提示词 -> 实现 ，不满意的话实现出来要构建、修订提示词，相比 one-shot 形式就多了很多麻烦。（特别拿 tg 举例，所有需要人力介入的测试，只要跟审美有关就不可能自动化，这个时候反复测试、返工修改，无疑比之前能工智人时期显得更麻烦和间接了很多，毕竟不是因为 bug 返工，而是因为审美差异和人机沟通问题；叠加上修改完重新编译要等的时间，就显得更严重了）
当然，肯定有很多规范化的手段，比如 plan mode, 设计工具，但又或多或少降低产量，也只能解决一部分问题。
所以好像还是挺无解的。拿来用的话差不多就够了，还得看具体的情形，胜听一席话了属于是
这点从来没有改变过，只是，之前 沟通 -> 实现 -> 不满意，再次沟通 -> 再次实现 之间的时间拉的比较长，显得不是非常拖时间；或者，对于自行实现的代码细节，总的代码生产速度是很慢的，是有时间扣这些细节的。
而 AI 时代，很容易被拉爆，吭哧吭哧写半天 prompt，哪怕说也要想一会儿吧，说的速度极限也就是敲字的 3x，但是要想，还要修订一些专有名词问题。这个时候变成了 提示词 -> 实现 ，不满意的话实现出来要构建、修订提示词，相比 one-shot 形式就多了很多麻烦。（特别拿 tg 举例，所有需要人力介入的测试，只要跟审美有关就不可能自动化，这个时候反复测试、返工修改，无疑比之前能工智人时期显得更麻烦和间接了很多，毕竟不是因为 bug 返工，而是因为审美差异和人机沟通问题；叠加上修改完重新编译要等的时间，就显得更严重了）
当然，肯定有很多规范化的手段，比如 plan mode, 设计工具，但又或多或少降低产量，也只能解决一部分问题。
所以好像还是挺无解的。拿来用的话差不多就够了，还得看具体的情形
🔥1
Forwarded from Real Nullptr
接下来一段时间如果没有解封，其余管理员会陆续把源码托管在 module repo 上的仓库转移给作者，之后模块仓库可能会更换新架构，不再使用 GitHub org 形式
这次事件教训是基础设施强依赖单一代码托管平台是很危险的
这次事件教训是基础设施强依赖单一代码托管平台是很危险的
即使如此，GitHub 已经算最类人的平台了。
其他托管平台更烂…
过去十几年 GitHub 能一直以几乎免费的价格提供不限量的 Git 存储，随着被收购之后降本增效，可能要逐渐结束了。
过去十几年 GitHub 能一直以几乎免费的价格提供不限量的 Git 存储，随着被收购之后降本增效，可能要逐渐结束了。
刚去小米某交付中心测了一下 n90 max 探索版的充电：
测了 6 个 type c，主副驾 2 个，中岛后方 2 个，帐篷 1 个，右后车门后面一个
即兴出门没提前准备，没带仪表拿 17u 测的，只有副驾和中岛右边支持 65W，其余目测都是 18W
无线充支持 50W
目测只能带个轻薄本啊，真拿 mac 跑重活是够呛，还好车内有 220V
测了 6 个 type c，主副驾 2 个，中岛后方 2 个，帐篷 1 个，右后车门后面一个
即兴出门没提前准备，没带仪表拿 17u 测的，只有副驾和中岛右边支持 65W，其余目测都是 18W
无线充支持 50W
目测只能带个轻薄本啊，真拿 mac 跑重活是够呛