LoRA与QLoRA微调Qwen2.5-7B：从数据构造到loss收敛的完整记录
本文记录了在单张RTX 4090（24GB）上，用LoRA和QLoRA两种方式微调Qwen2.5-7B-Instruct的全过程。数据集为自建的8.6k条中文指令数据，训练框架为LLaMA-Factory 0.9.1 + PEFT 0.13.2。LoRA配置r=16、alpha=32，QLoRA采用NF4量化。最终LoRA峰值显存约19.2GB，QLoRA仅11.4GB，3个epoch后eval_
从零手写AI Agent：工具调用、记忆管理与循环控制拆解
LangChain和AutoGPT把Agent抽象得很美，但真到线上，循环停不下来、工具调用参数错、上下文爆炸才是日常。本文不依赖任何Agent框架，用约300行Python手写一个可运行的AI Agent，拆解工具定义、记忆管理、错误处理和循环控制四块核心。实测在GPT-4o-mini下，单次任务平均2.7轮收敛，工具错误自愈率约85%，Token消耗比裸ReAct降低约30%。
用asyncio重构Flask接口，QPS从120飙到2300的细节
一个查询3个下游HTTP接口的聚合API，Flask同步版压测QPS只有120，P99高达1.2秒。我用asyncio+aiohttp重写后，单进程QPS冲到2300，P99降到48毫秒，内存反而更稳。本文给出完整的before/after代码、wrk压测命令、版本号，以及gather异常处理和连接池这两个坑的解法。
Prompt Engineering实验：同一文本分类任务下6种提示词的Token消耗与输出质量对比
本文用一个真实的中文情感分类任务（1000条外卖评论，3分类），对6种不同Prompt设计做了完整对比实验。模型选用gpt-4o-mini(2024-07-18)与qwen-plus(2024-09-19)，温度统一设为0。实验记录了每种Prompt的输入Token、输出Token、准确率、格式合规率和单条成本。结果发现：带Few-shot的Prompt准确率从78.3%提升到91.6%，但Tok
LoRA微调7B大模型：从数据准备到推理效果对比的完整流程记录
本文记录了使用LoRA/QLoRA技术微调Qwen2.5-7B-Instruct的完整过程。在单卡RTX 4090（24GB显存）上，采用QLoRA 4-bit量化，仅训练约4000万参数（占总参数0.5%），耗时2.5小时完成3轮训练，最终loss从1.87降至0.62。医疗问答场景下，模型回答准确率从基线的52%提升至86%，推理延迟仅增加3ms。文中包含详细代码、踩坑记录与真实效果对比。
我用3轮实验把Prompt从78%优化到96%：提示词工程Token消耗与输出质量对比
同一份商品评论情感分类任务，我写了3版Prompt做对比实验：零样本基线、角色扮演版、Few-shot+格式约束版。在gpt-4o-mini（2024-07-18）上跑200条测试集，准确率从78.5%提升到96.0%，但Token消耗从平均142涨到487，成本翻了3.4倍。本文完整记录了每版Prompt的设计思路、可运行代码、踩坑过程和真实数据，帮你判断什么场景值得为Prompt多花钱。
用LoRA微调Qwen2.5-7B：从数据构造到推理对比的完整记录
本文记录了我在单张RTX 4090（24GB）上用LoRA微调Qwen2.5-7B-Instruct的全过程。训练数据是约1.2万条垂域问答对，采用NF4量化+LoRA（r=16, alpha=32）配置，峰值显存占用约18.7GB，训练3个epoch约2小时40分钟。最终loss从初始的1.82降到0.61，在自建测试集上任务准确率从基线的43%提升到86%。文中给出了完整可运行的训练代码、lo
我用GPT-4o做合同信息抽取：6版Prompt对比，Token从1200降到380，准确率反升到96%
本文以“合同关键信息抽取”为具体任务，在GPT-4o（2024-08-06版本）上对比了6版Prompt的设计效果。从最初的“直接提问”到结构化Few-shot + JSON Schema约束，单次调用Token从1200降到380，抽取准确率从72%提升到96%，单条成本下降约68%。文中包含完整可运行代码、参数配置、踩坑记录和实测数据，适合正在做信息抽取、RAG前置处理的开发者参考。
React Context 迁移到 Zustand：一次电商项目状态管理的性能优化记录
我们维护了一个中型电商前端项目，早期用 React Context + useReducer 管理全局状态，随着 SKU 选择、购物车、用户信息等模块膨胀，Context 触发的全量重渲染让商品详情页在低端机上掉到 28fps，一次加购操作能引发 47 个组件重渲染。本文记录了从 Context/Props 迁移到 Zustand 的完整过程，对比了 Redux Toolkit、Zustand、J
Git分支策略与CI/CD集成：一套支撑30人团队高效协作的工作流配置
团队从SVN迁移到Git后，一度因分支混乱导致每周至少2次合并冲突事故，发布回滚耗时平均45分钟。本文分享我们最终落地的工作流：以Git Flow为基础裁剪出main/develop/feature/release/hotfix五类分支，配合GitLab CE 16.8的Merge Request强制Code Review、Jenkins 2.426流水线自动构建与部署，将发布回滚时间压缩到5分钟
LoRA微调7B大模型：从数据准备到推理效果对比的完整记录
本文记录了使用LoRA/QLoRA技术微调Qwen2.5-7B-Instruct的完整过程。在单张RTX 4090（24GB）上，通过4-bit量化+LoRA，仅训练0.8%参数（约5000万），耗时2.5小时完成3轮训练，loss从1.82降至0.67。在自建测试集上，微调后模型对特定领域问答的准确率从41%提升至87%，推理速度仅下降8%。文中包含完整可运行代码、显存占用数据及踩坑记录。
React 18 项目从 Context 迁移到 Zustand 与 Jotai 的取舍记录
一个中型后台系统在 React 18.2 + TypeScript 5.3 下，把 47 个组件依赖的全局 Context 拆成 Zustand 4.5 与 Jotai 2.6 两套方案做对比。迁移后首屏渲染从 1.9s 降到 1.2s，输入框打字时无关列表重渲染次数从每次 6 次降到 0 次，包体增加 3.1KB gzip。本文给出完整对比数据、迁移步骤和踩坑记录。
asyncio重构FastAPI订单接口：QPS从120提升到2100的优化记录
一个查询订单详情的接口，内部要串行调用用户、商品、库存、物流4个下游HTTP服务，同步版本P99延迟840ms、QPS只有120。我用asyncio.gather把串行改并行，配合httpx.AsyncClient连接池和信号量限流，在Python 3.11 + FastAPI 0.110 + uvicorn 0.29环境下，把P99压到96ms、QPS拉到2100，机器没加一台。这篇文章把bef
基于Git Flow与Trunk-Based的分支策略、Code Review与CI/CD集成配置详解
团队从5人扩展到20人后，我们的单体仓库一度陷入“合并地狱”——每周平均37次合并冲突，发布前需要3天冻结代码。本文记录了我们如何用 Git 2.40 + GitLab 16.8 + Jenkins 2.426 重建工作流：主干开发配合短生命周期分支、强制MR与双人Review、流水线卡点。落地后合并冲突降到每周4次，从提交到生产平均耗时从72小时缩短到45分钟。
LoRA微调7B大模型全流程：数据准备到推理效果对比
本文记录了在单张24GB显存消费级显卡上，使用LoRA/QLoRA技术微调Qwen2.5-7B-Instruct的完整过程。训练数据为1.2万条垂直领域问答对，采用4-bit量化+LoRA（rank=64）方案，峰值显存占用仅18.3GB，训练3个epoch耗时约4.5小时。最终模型在自建测试集上的准确率从基线的61.2%提升至84.7%，同时保留了通用对话能力。文中包含完整可运行代码、Loss曲
React与Vue项目从Context/Props迁移到Zustand与Pinia的实践与性能对比
在一个中型后台管理系统（React 18.2 + Vue 3.3 混合栈）中，我们将原本基于 React Context + useReducer 和 Vue Props + provide/inject 的状态管理，迁移到了 Zustand 4.4 和 Pinia 2.1。迁移后，首屏渲染时间从 1.8s 降至 1.2s，复杂表单页的无效重渲染次数减少 72%，代码行数减少约 35%。本文记录方
从分支策略到CI/CD：一套可落地的Git团队协作工作流配置详解
团队从5人扩展到20人后，我们的Git仓库开始频繁出现合并冲突、误提交和发布回滚。本文分享我们最终稳定下来的工作流：以`main`/`develop`/`feature`/`release`/`hotfix`五类分支为核心，配合GitLab 16.9的Merge Request审批规则、GitLab CI 16.9流水线，以及基于`husky@9.0.11`和`commitlint@19.0.3`
从0.71到0.93：一次RAG检索增强生成系统的分块、嵌入与重排优化记录
本文记录了一个面向企业内部文档问答的RAG系统优化过程。原始方案采用512字符定长分块、text-embedding-ada-002与纯向量Top-5检索，在1200条评测集上Recall@5仅0.71，答案准确率0.63。通过改用语义分块（256-512 token动态）、切换bge-large-zh-v1.5、引入bge-reranker-large重排，最终Recall@5提升至0.93，答
RAG检索增强生成优化：从0.61到0.89，chunk策略与rerank的联合调优
本文记录了一个真实RAG系统（检索增强生成）的优化过程。初始版本召回率仅0.61，答案准确率不足70%。通过将固定chunk从512改为语义分割+滑动窗口、embedding模型从text-embedding-ada-002切换为bge-large-zh-v1.5、引入bge-reranker-large重排序，最终Recall@5达到0.89，端到端准确率提升至86%。文中包含完整代码、版本号、
asyncio重构Flask接口：QPS从120提升到2100的优化记录
一个日请求量800万的内部API，用Flask同步视图处理下游3个HTTP调用和1次MySQL查询，单机QPS长期卡在120，P99延迟1.8s。改用asyncio + aiohttp + aiomysql重写核心链路后，单机QPS达到2100，P99降到95ms，机器数从8台缩到2台。这篇文章把before/after代码、压测数据和踩过的坑都摊开讲清楚。
