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 多维，甚至更多，来解决空间不够的问题。
在平时使用 git 时，我们时常会遇到代码需要回退的情况，一般我们使用 git 作为代码管理的工具，我们有两种方法来回退代码：
git resetgit revert两者的区别是，git revert 是提交一个新的版本来回退，将需要 revert 的版本内容再反向修改回去，会创建一个新的版本，不会影响之前提交的内容；而 git reset 是直接将 HEAD 向后移动了一下，直接回退到之前的版本，如果代码已经推到远端仓库，就无法再直接同步代码了。
我们时常需要 undo last commit，使用到的命令是：git reset --soft HEAD~
阮一峰 CSS Grid 网格布局教程
https://www.ruanyifeng.com/blog/2019/03/grid-layout-tutorial.html
因为看到需要实现 n 行 n 列的效果，自然就会想到使用 grid 布局。
grid 布局默认的放置方式是先行后列，如果要想先列后行，可以使用 grid-auto-flow: column 这个属性来实现。
hash 模式本质上就是对 history 模式的上层封装
export function createWebHashHistory(base?: string): RouterHistory {
// Make sure this implementation is fine in terms of encoding, specially for IE11
// for `file://`, directly use the pathname and ignore the base
// location.pathname contains an initial `/` even at the root: `https://example.com`
base = location.host ? base || location.pathname + location.search : ''
// allow the user to provide a `#` in the middle: `/base/#/app`
if (!base.includes('#')) base += '#'
if (__DEV__ && !base.endsWith('#/') && !base.endsWith('#')) {
warn(
`A hash base must end with a "#":\n"${base}" should be "${base.replace(
/#.*$/,
'#'
)}".`
)
}
return createWebHistory(base)
}在平时的开发过程中，分支之间的合并是十分常见的操作。我平时都是使用 merge 一把嗦，无论是开发分支到线上分支，还是线上分支到开发分支，基本都是使用的 merge。反观之前有一个后端同事，他们组内会有多人开发同一个功能的情况，他除了最终将开发分支合并到线上分支使用了 gitlab 的 merge request 去 merge，平时都是使用 rebase 来将别人的功能分支合并到自己的开发分支上。
在看到了这些情况后，我对 merge 和 rebase 有什么区别产生了疑问，正好去搞明白这两个操作究竟有什么不同。
merge 是我常用的功能，这个我自己比较熟悉，一般来说可以分成两种情况：当前分支与合并目标分支有无变更。如果当前分支就是从合并目标分支上出来的，merge 操作其实看起来就像是在合并目标分支后进行了多次 commit，commit log 也是一条直线；但很多情况下存在多人同时开发的情况，就会有变更操作，存在变更操作的时候，merge 操作会产生一条 merge 的 commit log，commit log 也会变成一条折线。很多同学可能会有强迫症介意这条折线，所以 rebase 是他们更常见的选择。