随着部门深入使用 dify，逐渐遇到了一些卡点问题，因此我也顺便看了下 Dify 社区的贡献指南，想着给社区提供一些我们这边的思路。
目前来说是做了两个 feature：
这两个 feature 都能显著提升平台使用体验。
第一个 feature 在开发工作流的过程中，一般我们是先搭直线的流程，再通过迭代节点等来进行流程的优化，此时如果要将许多节点一次性复制到迭代节点内部，就会特别方便，在以往只能重新再迭代节点内部再重搭一次流程。这个 feature 已经被合并到主分支且在 1.9.0 正式上线了。
在参加完 Vue Conf 25 后，跟大佬们一通交流，当时又燃起了参加开源的想法，加上得到了和一位社区同学 Little Sound 的交流，了解到了开源对于普通开发者来说也不是那么的遥不可及，我就在想，要不我也开始试试吧？
正好当天最后一个主题是我偶像 antfu 大佬的 vitejs/devtools 分享，大佬在演讲完成后当场将库开源，我也是急匆匆地点上了 star，在后面的一个开发工作中，我遇到了一些 vite 打包的性能优化问题，我就想起来这个 devtools，想看看能不能帮上忙，结果发现其实这个项目还在 WIP，这下是真的一个好机会了，我也就在这里面找到了一些 TODO，开始尝试做贡献。我找到的这个 TODO 是给 devtool 中的 plugin 视图加上 flamegraph，即火焰图。
star 数：10346
npm 下载量：260944
npm 上次更新时间：2022-10-18
GitHub：Akryum/vue-virtual-scroller
python 项目依赖管理结构发展：
pip 安装依赖，但安装在全局，容易出现依赖版本冲突的问题
venv 为每个项目搭建一套自己的虚拟环境，使得 pip 能安装到每个项目中，但是使用前需要先激活虚拟环境
依赖列表使用 pip freeze > requirements.txt 生成，但默认会将所有相关依赖都列出来，删除一个依赖就只会删除一个依赖，不会将其相关的依赖也删除，其他的就变成了孤儿依赖
引入 pyproject.toml 来管理依赖，将依赖放置在 dependencies 中，使用 pip install -e . 来安装依赖，就会自动处理好所有的间接依赖了
手动去编辑 pyproject.toml 太麻烦了，就催生了 uv poetry 这样的项目管理工具，本质上是对 pip venv 等的高级封装（但我看到 uv 是新的实现，完全使用了 rust 重写），提供了用户友好的高级接口方便地进行操作
GPT5 deepresearch canvas 功能内置，无需手动开启，模型会自己去推理现在应该使用什么工具
支持混合思考模式，简单的问题直接输出，复杂的问题会自动开启深度思考
更新了语音交互与视频交互功能，但是估计在国内用不太起来，语音功能已经支持让说话变得更快和更慢，挺厉害的
增强了记忆功能
几处都提到了显著降低了幻觉，同时减低了欺骗性，欺骗性指的是大模型有些时候会谎报自己的工作结果，或者说是为自己错误的行为做找补。
GPT 5 使用了 4o-3 来强化学习，使用了上一代模型生成的内容，来作为下一代模型的训练材料
typescript enum 会被编译为 IIFE，因此无法被正常的 treeshaking 掉，如果有 treeshaking 的需求，建议不要使用 typescript 中的 enum
React 中真的处处都是坑（重点）
最初是发现 props 变更时会导致许多不应该发生的 re-render
function App() {
return (
<div>
<Chat class="p-4" messages={messages}></Chat>
<Button
type="primary"
onClick={() => {
setMessages([
...messages,
{
id: `${Date.now()}`,
content: '测试消息',
role: 'user',
loading: false,
},
])
}}
>
test add
</Button>
</div>
)
}
const Chat: React.FC<ChatProps> = ({
difyAPIUrl,
difyAPIKey,
messages,
}: ChatProps) => {
const memoMessages = React.useMemo(() => messages, [messages])
return (
<>
<XProvider theme={theme}>
<DifyContext value={{ difyAPIUrl, difyAPIKey }}>
<ChatList messages={memoMessages}></ChatList>
</DifyContext>
</XProvider>
</>
)
}
function ChatList({ messages }: ChatListProps) {
const rolesAsObject: GetProp<typeof Bubble.List, 'roles'> = {
assistant: {
placement: 'start',
avatar: { icon: <UserOutlined />, style: { background: '#fde3cf' } },
typing: { step: 5, interval: 20 },
styles: {
content: {
backgroundColor: 'white',
},
},
variant: 'shadow',
shape: 'corner',
messageRender: renderMarkdown,
classNames: {
header: 'w-full',
},
},
user: {
placement: 'end',
// avatar: { icon: <UserOutlined />, style: { background: '#87d068' } },
shape: 'corner',
},
}
const renderMessages = useMemo(() => {
return messages.map((item) => ({
key: item.id,
role: item.role,
content: item.content,
header: renderWorkflow(item.workflowProcess),
loading: item.loading ?? false,
}))
}, [messages])
return (
<>
<Bubble.List
items={renderMessages}
roles={rolesAsObject}
className="h-full"
></Bubble.List>
</>
)
}RAG 架构本质上是一种压缩，为了解决大模型上下文有限做出的一种方法，将文章和文本进行切段、做筛选、建索引、召回，以达到将上下文给到上下文有限的大模型的目的。
一个简单的问题，我们可以直接作为 prompt 交给到大模型，但毕竟大模型的上下文空间是有限的，即便是现在最新的 GPT5，上下文达到了 400k，即 40w 这么大了，还是有可能不够用，我们自然会想到，那我们将这么大的文章中一部分相关的内容给到大模型，结合问题就能得出想要的结果，这就是向量化的思路。
embedding 就是做这个事情的，它将一段话转换成多维数组坐标系，相似的文本在坐标系中的落点就会相接近，因此可以通过这种方式来找到相似的内容，就能实现在庞大文本中找出相似内容的目标。平时我们接触的数学中的二维坐标系、三维坐标系，自然是比较简单，但很容易就会将维度中的落点空间用完，所以先进的 embedding 模型转换成的是 3000 多维，甚至更多，来解决空间不够的问题。
在 Vue 3 中，有一个需求，想要通过判断用户是否传入事件处理函数，如果传入事件处理函数证明点击事件需要被处理，来决定是否给元素添加 pointer 的样式，因此我们需要有一种方式能访问到传入的事件处理函数。
在看 Vue 源码的时候我们知道其实本质上事件处理函数也是挂载在 props 上的，因此我尝试直接通过 $props 去获取，结果发现并无法获取，结合之前看的源码，props 本质上也是一个 Proxy，在这个 Proxy get 的时候会去判断这个属性是否显式地在 props 上定义，如果是的话才会返回，否则就不返回，直观的表现就是无法访问到这个属性。很明显我们是通过 defineEmits 去定义的事件，因此 props 这个 Proxy get 的时候并不会将事件处理函数返回。