visper

当时看到 1.0 发布的消息，想着马上去更新一下，但是一看完更新内容，完蛋了，整个结构都变了的这种把第一个版本当 1.0?这是小白鼠版本啊。bug 应该会不少吧？后来就上 github 之类的看一下各种评论，原来 bug 真的不少，再过几个版本才敢升级了。0.15.3 其实用着也不错，唯一差点的一个是工作流里面没有 agent 节点这样的。

充钱，充钱，有 cursor 爱你很久...

react 像围棋，规则简单，一切都是 js. 但是再结合上它的 hooks 和整个函数重新执行的渲染机制，里面的对性能的担忧及函数的闭包引用，这就是心智负担的来源了。取决说你 js 能力的强弱。基本上 react 各个项目之间看代码，感觉起来相差很多。
vue 像象棋，各种地方规则多了，开始的时候记一些生命周期啊模板语法啊，这些其实很简单半小时的事。其他的坑主要是要理解响应式原理才明白有时候什么不响应了，不过这很少遇到。而且通常做起小项目来，vue 的代码不同水平的相对 react 来说要相近一点。react 高水平的各种高阶函数各种 js 花样玩。

其实都在蹭 deepseek 的热度而已，随便搞点什么然后有了就行了。deepseek 本来擅长的是复杂问题的推理给出一些答案给你思路。具体到 function call 这些来做 agent 的话，因为它没内置支持，而且思考过程长，反而不如 qwen2.5 这些好用。 比如你可以做一个伪需求，先把一些自动化部署的脚本写好，能通过 http 接口调用来做一些自动功能了，然后接入大模型做一个聊天，使用问答的方式让大模型自动抽取参数来调用接口进行自动化运维工作。。。说是伪需求，因为好像不如直接做个按钮点一下方便。

200 都不够看完需求文档的时间。还别说确认需求

字节： 我速度快也有错？

换个赛道：宝妈之友！ AI 辅导作业秘籍!!!

rust 啊，有时候类型复杂了看得头晕。如果晕的话就不优化得了。

首先，我们知道，和大模型聊天的时候，我们可以设计 prompt,例如:
请结合以下上下文内容，回答用户问题:
```
context
```
用户问题如下：
query

-----
那么，上传文档变成知识库，就是把文档分段，使用向量数据库存起来。当用户提问的时候(假设内容叫 query)，拿 query 内容通过向量搜索找到相关的知识片段,组合成 context,拼到上面类似的 prompt 里面一起给大模型回答。
另外，向量数据库搜索只是比较通用的一种方式。知识怎么分段怎么存，你可以自己设计比如存关系数据库都没问题。