基于 redis 的简单队列： https://python-rq.org/

既要也要不太可能吧，想要成本低相应容灾肯定相对差点，不过 redis 也可以开持久化不是？

涉及交易肯定是最敏感，感觉指望三方造平台不太现实
目前体验下来信用卡账单还蛮好用的，尽量把交易指向固定的卡，月底看账单就可以了

先看看你的工具注的点有哪些（例如浏览器支持、性能、兼容性）
再去拿需求、商业模型试套下几个框架看看能不能满足

正好是从业者，也做产品，但还是觉得这个需求在实际落地的时候不如 IDE ，属于“看起来很酷炫但不好用”的东西

几个链接：
- https://sourcegraph.com/
- https://github.com/sourcegraph/cody

但就你的问题来说，好像还不需要到 AI 助手吧，1 、2 、3 都是可以静态分析出来的，是需要翻译成更简单的人话？

分析想达到什么目标？维度有点多

感谢对行业的贡献~

black +1

@yeqizhang 以前一度有段时间作者不更了，联系了也不回，后面有好心人接手了~

=。= 项目首先要考虑的不应该是能解决什么问题嘛

同 OP ，最喜欢 Courier New 同类型的打字机风格，有更像的就更好了

@wfhtqp

知道了.. 因为默认配置被不小心提交上去了，这次只是想来 share 下衍生 idea ，没有仔细测 server 这块，感谢！
用 0.7.4 亲测 ok ，compose 也可以，可尝试

@wfhtqp

暂时不带 kafka ，因为这类中间件一般由公司里的基建来承接，就不进 compose 了；

默认情况下请求会打到 server 里的 in-memory 队列，然后有一批 worker 来处理并写进 db ；
没入库目测是 neo4j 还在写，db 是目前最大的问题，太慢了；

试用的话可以先不用 compose 玩玩看，看看流程能走通不： https://opensibyl.github.io/doc/docs/usage/usage-prod#%E5%BF%AB%E9%80%9F%E8%AF%95%E7%94%A8

@wfhtqp

https://github.com/alibaba/jvm-sandbox

history 这个功能我用这个仓测的，貌似没什么问题，也算比较传统大厂仓了。比较怀疑是仓里面有些大文件使得解析直接走到里面去把 cpu 打满了，使得没法继续往下了
后续考虑把过大的源码文件忽略掉，目前只是忽略掉 binary

@wfhtqp

服务端：有队列，可以先看看服务那边有没有日志打出来，如果没有的话过会儿应该就有数据了
卡住：仓的规模大概多大？

@williamfzc 当前支持 golang 、java 、python

https://vimeo.com/780616138

test

又及，目前 openai 没有提供 api ，所以现在几乎所有衍生产品基本都是玩具级