最新更新请看： https://www.v2ex.com/t/932027

@chancat 人工智能的发展趋势是势不可挡的，一切执行方法最后都会被绕过，无非是绕过成本的问题

刚发布了插件 ChatGPT 就暂停对非普通用户开放了，什么黑天鹅事件

@runtousa hh ，目前我 star 了的有 https://github.com/K-Render/best-chinese-prompt ，可以顺着 chinese prompt 这个关键词搜搜 Github ，我目前主要还是用来写代码

@kebamt 安排

@wzhpro 考虑的考虑的，目前已经上传了，还在审核中，审核通过了会更新的，觉得适合你的话可以先关注一下~

目前还是只支持开发者模式加载（ Web Store 还在审核中），但是优化了一些边界判断，还额外提供了半自助阅读 PDF 的功能，欢迎再尝试一下，新贴在此： https://www.v2ex.com/t/928566#reply0

还是麻烦了，可以尝试分两步，第一步是把 Markdown 每一行读出来，第二步是自动生成相应的国际化版本接口的代码文件。如果痛点是在国际化的话，你现在的 jsx-to-md 相当于只做了第一步，还把第一步整复杂了，第二步还要去找别的库。开发还是要尽量把简单留给别人的

赞一个

发现我忘了附链接（微笑）图也显示不了（微笑）

https://github.com/sailist/chatgpt-markdown-extension

支持一下

@huntzhan 这是最尴尬的事情

@baobao1270 万一能完善，倒逼着改一下政策啥的...（笑死，想多了

@westoy @eason1874 在想如果用区块链的概念或者什么，有没有办法能减少这种养号自重的现象和对自家陪审团的需求

支持

@frinstioAKL 似乎因为编解码方式的问题，图片的 sqlite 读取性能好像不是很客观，而且十分占空间，当时踩完坑后采取的是将图片保存成一个 chunk ，然后 sqlite 记录 chunk path 然后读。因为那段时间工期太赶没仔细测试，你可以再试验一下，我也等一波反馈~

@frinstioAKL 我刚刚路上突然想到一点，我的测试可能有一定错误，因为我存的是数字，可能因为数据太小导致写入速度慢？（这种数据大小导致的某种均匀性我最初还是在 hash 方法里见到的）。我去看了 quickle 提供的 benchimark ，它在 dump 和 load 下好像都是有速度优势的。我看了 @BingoXuan 说的 sqlitedict 的实现，或许可以考虑直接提供一个 backend 参数传入..

lmdb 当初应该有一两百万了吧，忘了是纯文本场景还是文本图像混合场景了，哦对了 lmdb 里面有个 metadata 空间应该也有上限，当初我好像是用来放 label 的，这个也是弃掉的一个原因。 [随便找了一篇说明文档]( https://mozilla.github.io/firefox-browser-architecture/text/0015-rkv.html#:~:text=LMDB%20by%20default%20has%20a,may%20have%20performance%20impact%20too.)

> LMDB by default has a maximum key size set as 512 bytes, there is a compile time configuration to change it, though a larger key may have performance impact too

@frinstioAKL 哦抱歉，我记错了，不是分块读取的；我之前用过 lmdb ，不知道是不是之前代码写的烂的缘故，我记得 lmdb 单个文件数据存储，量级越大读起来就越慢...也是因为当初这件事，我后来尝试了 feather 格式，然后出来了这个库...