一个流水水水水账
在飞机上不知道干什么，忽然想起来自己之前嚷嚷着要写一下大作文，因为自己两星期之后就21岁了，却还没有象征性得写过阶段性大作文 既然写自传文章，那我还是从最近发生的开始写吧，因为过去的事情大多我已记不太清了，所以有些地方写的简略一点在所难免 就从打重庆开始说起吧，其实我本来是没有想过打重庆的，因为毕竟太远了，加上也没怎么训练实力也就铁牌，所以意愿不高，当然当时想着可以在南昌这种近的地方打星去感受一下热爱的感觉，由于种种因素没有去成，赛时姑且认为负贡献吧，就写了一个签到还wa了一发，当时石头人让我上机写，脑子直接糊成一坨浆糊，重新整理一下就好了，但还是wa了一发，OK这之后就没有我的事了，整个人有点懵，看着白熊跟石头人说说笑笑，我也跟着笑，然后他们就过题了😁，说到重庆，吃了不挂科火锅，我甚至没意识到不挂科是名字，吃了两口简直辣到发昏，已经说不出来话了，也是成功完成喷射任务了，也是面基了长相，说实话我都没想到说那么s的话，长的那么老实，甚至吃完火锅马上就回去打开cf，写他的dsu on tree（正赛还想看我板子有没有，但我没点这个科技树😂），还是有点感慨的，因为自己也没有一个人出...
中文分词-最大匹配算法
1. 最大匹配算法最大匹配法是指通过词典进行单向分词，优先选择词的长度，逐步对句子扫描分词 我们举个从左向右的例子 12345678910111213141516171819假设当前句子为： 你学会最大匹配算法了吗 词典当中有 你 学会 学 会 最大匹配算法 了 吗(其实还有最大 匹配等等就不写了)第一次分词 | 你学会最大匹配算法了吗你学会最大匹配算法了吗 没有这个词你学会最大匹配算法了 没有这个词你学会最大匹配算法 没有这个词你学会最大匹配算 没有这个词...你 对咯 那就下一个第二次分词 | 学会最大匹配算法了吗显然结果是 学会第三次分词 | 最大匹配算法了吗 这里就有个问题 选择 最大匹配算法 还是 最大|匹配|算法我们首先要考虑的肯定是词的长度越长越好 词典之中已经拥有显著的意义就没必要在分词所以选择 最大匹配算法 最大匹配法主要包括正向最大匹配法（FMM，刚刚这个例子就是）、反向最大匹配法（BMM）和双向最大匹配法，均是基于词典的 缺点有： 因为是基于词典的 所以如果新词没记录没更新，就会识别不出来 2. 正向匹配算法(FMM)也就是...
LLM Wiki 与 Agent 知识层：从零散资料到可持续进化的知识系统
原文链接：用 Karpathy LLM Wiki 方法论，为 AI Agent 系统构建结构化知识层 这篇文章讲的不是“再做一个知识库”，而是把知识库当成 Agent 系统的长期知识层来设计。它的核心启发是：企业知识不应该只停留在一堆文档、网页收藏、聊天记录里，而应该被整理成可检索、可链接、可更新的结构化 Wiki。 先说结论我理解这篇文章的重点有三个： Agent 需要的不是一次性 RAG，而是长期可维护的知识层。 检索不应该只靠向量，grep + 向量 + 图谱扩展 可以互相补失败模式。 中文技术知识里，精确词、缩写、同义词和领域术语非常重要，不能盲目相信 embedding。 传统 RAG 更像“问一次，临时找资料，再回答”。LLM Wiki 的思路更像“先把知识编译成一个持续增长的代码库”。每次新增资料，不只是存进去，而是要抽取概念、建立链接、更新索引，让后续检索和推理都能复用这部分沉淀。 LLM Wiki 的关键变化Karpathy 的 LLM Wiki 有一个很有意思的比喻： Obsidian 类似 IDE。 Wiki 类似代码库。 LLM 类似程序员。 ...
Claude Code 的检索方式：为什么 grep 可能比 RAG 更适合代码库
原文链接：RAG 已死？从 Claude Code 源码到行业实践看 Grep 的回归 这篇文章讨论的是一个很容易被标题带偏的问题：Claude Code 这类编程 Agent 为什么不一定需要传统 RAG？ 我的理解是，它并不是在说 RAG 彻底没用了，而是在说：对于代码库这种高度结构化、随时变化、天然可搜索的材料，LLM + grep/ripgrep + 文件读取 这种动态检索方式，很多时候比“提前切分、向量化、建索引”的传统 RAG 更直接。 先说结论传统 RAG 的典型流程是： 把资料切成 chunk。 对 chunk 做 embedding。 存到向量库。 用户提问时先召回相似片段。 再把片段塞给模型生成回答。 这个流程在知识库问答里很常见，但放到代码库里会遇到几个问题： 代码变化很快，索引很容易过期。 chunk 切分可能破坏函数、类、调用链的完整语义。 向量相似度不一定能准确命中真实入口。 检索出来的内容仍然需要模型继续判断是否相关。 而 Claude Code 这类工具更像一个会使用命令行的程序员：先看目录，再用关键词搜索，再读文件，再顺着调用关系继续...
Go 里的 recover：如何优雅地兜底 panic（写给初学者）
很多 Go 初学者第一次遇到 panic 都会很慌：程序直接崩了，错误信息一大堆。于是就会听到一句话：用 recover 可以救回来。 但 recover 并不是“哪里都能用”的万能药，它有非常明确的触发条件和边界。本文用最小示例把 panic / defer / recover 的关系讲清楚，并列出常见坑和工程里正确的兜底方式。 1. panic / defer / recover 到底是什么关系？ panic 让当前 goroutine 进入异常流程：从当前函数开始向上“展开调用栈”（stack unwinding） 在展开过程中，会执行每一层函数里注册的 defer defer 延迟执行：函数返回前执行 发生 panic 时也会执行（这是 recover 能工作的原因） recover 作用：在 panic 发生后，把 panic 的值取出来，并阻止程序继续崩溃 只能在 defer 调用的函数里生效，否则返回 nil 一句话总结：panic 触发异常 -> defer 仍会执行 -> defer 里调用 recover...
Go标准库中的context包
本文总结了 Go 标准库中 context 的常见用法，包括创建、传递、取消、超时部分场景。 1.context包负责Go当中的上下文传递机制1.1 问题场景 一个 HTTP 请求可能启动多个 goroutine（调用下游服务、查数据库、写日志） 如果客户端断开连接，需要取消所有相关操作，避免浪费资源 如果某个操作超时，需要及时停止，而不是一直等待 1.2 传统方式的问题 没有统一的取消机制，每个 goroutine 需要自己管理停止逻辑 难以在调用链中传递取消信号 1.3 context 的价值 统一取消机制：一个 ctx.Done() 可以通知所有相关 goroutine 自动传播：子 context 会继承父 context 的取消状态 超时控制：可以设置超时时间，自动取消 2.context的接口实现1234567// 主要包含四个方法type Context interface { Deadline() (deadline time.Time, ok bool) // 获取截止时间 Done() <-chan struct{&#...
调试 LeetCode 之 “一键补全头文件” 超简教程
本文 100% 亲测有效，3 步解决 #include <bits/stdc++.h> 标红、commoncppproblem2.h 找不到等 IDE 烦恼。 ✨ 前置准备 安装 Leetcode 登录使用不多赘述。 下载「Debug LeetCode」插件 商店搜索 Debug LeetCode，点击 Install。 成功后会在侧边栏看到一个 💡 的 LeetCode 图标。 若你尚未配置本地 C/C++ 环境，可参考 官方文档 进行 GCC/Clang 安装与 C/C++ 扩展配置。 🚀 三步搞定自动补全头文件 步骤 操作 截图 Step 1 打开任意 LeetCode 题目，点击顶部的 Debug 按钮 Step 2 首次运行时插件会 自动生成 main.cpp，并把缺失的系统头文件一次性补齐 Step 3 若仍出现 #include "commoncppproblem2.h" 的红色波浪线 —— 添加 inclu...