我用 7 版 Prompt 把合同抽取准确率从 71% 提到 94%，Token 反而降了 38%
同一个信息抽取任务，我拿 GPT-4o-mini 跑了 7 版 Prompt，从“直接问”到 few-shot、CoT、JSON Schema 约束、分步抽取，逐版对比准确率、输出稳定性和 token 消耗。最终第 7 版在 200 条测试集上字段准确率 94.2%，平均 token 从 1180 降到 731，单条成本降了约 38%。这篇记录了完整的实验过程、踩过的坑和可复用的模板代码。
Milvus与Qdrant选型对比：千万级向量检索性能与资源实测
在图文推荐场景下，我用1000万条768维向量对Milvus 2.4.0和Qdrant 1.9.0做了完整对比。单机部署下，Qdrant以约3.2GB内存支撑200 QPS，P99延迟48ms；Milvus在相同数据量下占用约7.8GB内存，P99延迟72ms，但批量写入吞吐高出约40%。本文给出Docker部署步骤、Python核心代码、实测数据与踩坑记录，帮你在中小规模场景下做选择。
LoRA与QLoRA微调Qwen2.5-7B：显存降到10GB的完整实现
本文记录了在单张RTX 3090（24GB）上微调Qwen2.5-7B-Instruct的全过程。先用LoRA跑通基线，再用QLoRA把显存从21GB压到10.3GB，训练速度只损失约18%。文中包含完整的数据构造代码、peft 0.13.2的配置参数、真实的loss曲线数值，以及微调前后在自建测试集上的对比结果——准确率从61.5%提升到89.2%。如果你也在为7B模型的显存发愁，这篇应该能帮你
从0.71到0.89：一次RAG检索增强生成系统的分块、嵌入与重排优化记录
线上客服知识库RAG系统上线两周，人工抽检200条问答，答案准确率只有71%，其中63%的badcase是"检索到了但排得太靠后"。本文记录完整优化过程：把固定512字符切分改成按标题层级的递归分块，嵌入模型从text-embedding-ada-002切到bge-large-zh-v1.5，再引入bge-reranker-large重排。最终Recall@5从0.71提升到0.89，端到端P95
Milvus与Qdrant向量数据库选型：十万级图文检索场景实测对比
在做一个十万级商品图文检索功能时，我在Milvus 2.4.0和Qdrant 1.9.2之间做了一次完整对比。相同数据集下，Qdrant单查询P99约18ms，Milvus约31ms；但Milvus在批量写入和水平扩展上更稳。本文记录了两者的Docker部署、Python客户端实现、参数调优以及内存和CPU实测数据，帮你判断哪个更适合自己的业务。
从38%到94%准确率：一次文本分类任务的Prompt Engineering对比实验记录
本文以电商评论情感分类为具体任务，在同一测试集（500条）上对比了Zero-shot、Few-shot、Chain-of-Thought、角色扮演+结构化输出四种Prompt策略。实验基于GPT-4o-mini（2024-07-18版本），temperature=0，max_tokens=256。结果显示：Zero-shot准确率仅38.2%，Few-shot提升至71.6%，CoT达到83.4%
从0.63到0.91：一次RAG检索增强生成系统的深度调优记录
线上客服知识库RAG系统上线两周，人工抽检200条问答，准确率只有63%，首token延迟却高达2.3s。本文记录了完整的优化过程：从固定512token切块改为语义+递归混合切块，把bge-large-zh换成本地部署的bge-m3，并引入bge-reranker-v2-m3做重排。最终Top-5召回率从0.71提升到0.94，端到端准确率0.91，P95延迟反而降到1.1s。附完整代码与踩坑记
React Context与Vue Provide性能瓶颈后，我迁移到Zustand和Pinia的完整记录
一个中型后台项目，React 18.2 + Vue 3.3 双技术栈共存，全局状态用 Context/Provide 管理。当页面模块增至 47 个、全局状态字段突破 120 个后，列表页输入框每次按键触发 30+ 组件重渲染，交互延迟从 16ms 涨到 90ms。本文记录我用 Zustand 4.4 和 Pinia 2.1 替换 Context/Provide 的完整过程，含方案对比、迁移步骤、
** 基于LoRA与QLoRA微调Qwen2.5-7B：数据构建、显存优化与推理效果全记录
** 本文记录了我在单张RTX 4090（24GB显存）上微调Qwen2.5-7B-Instruct的完整过程。针对领域问答场景，我构建了约1.2万条指令数据，分别尝试LoRA（bf16）和QLoRA（4-bit NF4）两种方案。最终QLoRA将显存占用从18.6GB降至9.2GB，训练速度约2.1 it/s，3个epoch后验证集loss从1.87降至0.94。文中包含可运行代码、loss曲线
asyncio重构订单查询接口：QPS从120提升到2300的调优记录
一个日均调用量800万的订单查询API，同步阻塞版本在4核8G机器上QPS只有120，P99延迟高达1.8s。我用asyncio + aiohttp + asyncpg重写后，QPS达到2300，P99降到47ms，服务器成本反而下降了一半。这篇文章完整记录了改造过程：从压测数据、方案选型、核心代码到踩过的坑，包含可直接运行的代码和真实的wrk压测对比数据。
FastAPI+Flask双框架API性能调优：从2.3秒到87毫秒的Profiling与缓存改造记录
一个日请求量约40万的商品详情接口，P95响应时间飙到2.3秒，数据库CPU长期跑满80%。本文用cProfile+py-spy定位到N+1查询和同步阻塞调用，通过SQLAlchemy的selectinload、Redis二级缓存和连接池调参，把P95压到87ms，QPS从120提升到1400。文中给出可运行的压测脚本和完整优化代码，附带locust实测数据对比。
从零手写AI Agent：LangChain工具调用与记忆循环实现
本文不依赖AutoGPT等现成框架，用LangChain 0.2.16和OpenAI GPT-4o-mini从零实现一个可运行的AI Agent。全文拆解工具定义、记忆管理、错误重试与循环控制四个核心模块，附完整可运行代码。实测在3轮对话内完成“查天气→算温差→发邮件”任务链，单次推理平均耗时1.8秒，工具调用成功率从62%提升至94%。
用asyncio重构Flask接口，QPS从120提升到1800的细节
一个查询用户订单的接口，原本用Flask同步实现，单机QPS只有120，P99延迟高达1.2秒。我把核心逻辑改成asyncio + aiohttp后，QPS涨到1800，P99降到85毫秒。这篇文章记录了完整的before/after代码、压测配置、以及我踩过的三个坑，包括事件循环复用和连接池参数调优。
React 18 下从 Context 迁移到 Zustand 4：一次首屏渲染耗时从 380ms 降到 120ms 的记录
项目使用 React 18.2 + TypeScript 5.0，全局状态长期依赖 Context + useReducer，随着商品配置面板的交互变复杂，Provider 一更新，整棵子树全部重渲染，Profile 面板单次输入延迟最高到 380ms，DevTools 里一次 commit 有 47 个组件参与。本文记录我把全局状态迁到 Zustand 4.4.7 的全过程：为什么没选 Redu
React Context 与 Vue Provide 迁移到 Zustand 和 Pinia 的实践记录
我们有一个中型后台项目，React 18.2 和 Vue 3.3 双栈并行，状态逻辑最初全用 Context 和 Provide/Inject 实现。随着模块增多，Context 嵌套到 7 层，Vue 侧 inject 命名冲突频发，首屏渲染多出 120ms，热更新时状态丢失。本文记录从 Context/Provide 迁移到 Zustand 4.4 和 Pinia 2.1 的完整过程，包含方案
LangChain与AutoGPT之外：从零手写一个带记忆与循环控制的AI Agent
框架用多了容易飘，我花了一个周末用纯Python手写了一个AI Agent，不依赖LangChain和AutoGPT，只用OpenAI SDK 1.30.0，实现了工具调用、滑动窗口记忆、指数退避重试和最大步数循环控制。在3个真实任务上，平均完成率从裸调GPT-4的42%提升到89%，平均Token消耗降低约31%。这篇文章把每一步实现细节和踩过的坑都摊开讲清楚，适合想真正理解Agent底层机制的
React Context 迁移到 Zustand：一个中台项目 3 天重构与性能对比
我们有一个运营中台项目，早期用 React Context + useReducer 管理全局状态，随着模块膨胀到 47 个 Provider，首屏渲染耗时从 1.2s 涨到 3.8s，任何一个状态更新都会触发 200+ 组件重渲染。本文记录从 Context/Props 迁移到 Zustand 的完整过程，包含方案选型对比、3 天迁移步骤、5 个典型踩坑，以及迁移后首屏耗时降至 1.4s、重渲染
React Context 重渲染拖垮页面后，我把状态迁到了 Zustand
项目用 React 18.2 + Context 管理全局状态，当全局 Store 字段涨到 30 多个后，一个输入框的每次按键都会触发 40+ 组件重渲染，交互延迟从 16ms 涨到 120ms。我把全局状态迁到 Zustand 4.4，局部高频状态留在 Context，迁移后首屏 TTI 从 2.8s 降到 2.1s，输入框按键平均渲染耗时从 120ms 回落到 18ms。这篇记录完整的方案对
React 18与Vue 3中从Context/Props迁移到Zustand与Pinia的项目记录
一个后台管理系统在React 18和Vue 3双技术栈下，随着模块增多，Context嵌套达到7层，Props钻透最多5层，导致一次全局筛选更新触发47个组件重渲染，交互延迟从80ms涨到420ms。我分别用Zustand 4.4.7和Pinia 2.1.7替换原有方案，迁移后重渲染组件降到9个，首屏可交互时间从2.1s降到1.4s，包体积仅增加3.2KB。下面记录完整对比、迁移步骤和踩坑细节。
Milvus 与 Qdrant 向量数据库选型对比：千万级商品检索场景实测
在千万级商品图文检索场景下，我基于 8C16G 单机环境实测了 Milvus 2.4.0 与 Qdrant 1.8.2 的部署难度、查询性能与资源占用。128 维向量、1000 万条数据下，Qdrant 单查询 P99 约 18ms，Milvus 约 27ms；内存占用 Qdrant 约 6.2GB，Milvus 约 9.8GB。本文给出完整部署命令、查询代码与踩坑记录，帮你少走弯路。
