Prompt模板迭代实录：从4.2%到82.6%的命名实体识别准确率提升
在医疗文本结构化项目中，我通过7轮Prompt迭代，将GPT-4o-mini的实体识别F1值从4.2%提升至82.6%。本文记录了完整的对比实验：初版零样本Prompt在20条测试样本上仅识别出3个正确实体，token消耗却达12,845；而最终版带few-shot示例与结构化输出约束的Prompt，在相同数据上识别正确实体87个，token消耗降至9,632。全程包含具体代码、参数配置与失败案例
LangChain 0.3手写Agent：工具注册与记忆回滚的7个实现细节
当AutoGPT式任务循环遇到工具调用失败、上下文超限、死循环三大难题时，我基于LangChain 0.3.7与Python 3.11手写了一个仅200行的Agent核心。通过自定义工具装饰器、双缓冲记忆池、三次重试熔断机制，在本地测试中将工具调用成功率从72%提升至94%，单轮任务平均耗时1.8s。本文重点拆解工具定义、记忆管理、错误处理、循环控制的代码级实现，不依赖LangGraph。
Milvus与Qdrant选型实测：千万级向量下资源占用与查询延迟对比
在广告反欺诈场景下，我们需要对2000万条64维用户行为向量进行实时相似度检索。本文基于Docker Compose分别部署Milvus 2.3.4与Qdrant 1.9.2，记录了两者在批量写入、单条查询（Top-10）、内存/磁盘占用、索引构建时间上的真实数据。Milvus在GPU加速下延迟低至3ms，但CPU模式内存占用是Qdrant的2.3倍；Qdrant在纯SSD上召回率稳定，且Rust
Prompt Engineering调优实录：从72.3%到91.8%的RAG问答准确率跃升
在构建基于LlamaIndex的医疗知识库问答系统时，我通过三轮Prompt迭代，将GPT-4-Turbo的答案准确率从72.3%提升至91.8%，同时将单次查询的token消耗从2,847降至1,932。本文记录了针对“药物相互作用”场景的Prompt实验全过程，包含零样本、少样本、结构化约束三种方案的对比数据，并给出了可复用的Prompt模板与成本控制策略。
asyncio重构Flask接口：Web API并发性能提升320%的完整记录
某次线上服务告警，单实例QPS卡在120，CPU闲置但大量请求排队。排查发现是同步阻塞调用拖垮了事件循环。本文记录用Python 3.11 + asyncio + aiohttp重构一个内部报表API的全过程：从最初的同步requests实现，到引入asyncio.Semaphore做并发限流，再到用asyncio.create_task调度IO任务。最终QPS从120提升到506，P95延迟从2
FastAPI慢查询调优实录：Profiling、SQL索引与Redis缓存三层提速12倍
一个用户列表API从1200ms压到95ms，吞吐量从80 QPS提升到1100 QPS。本文记录一次真实的FastAPI性能调优过程，覆盖cProfile火焰图定位、SQLAlchemy N+1查询修复、复合索引设计、Redis三级缓存策略，以及Locust压测数据对比。包含完整的profiling脚本、索引DDL和缓存装饰器代码，适合正在处理API性能问题的开发者参考。
Llama-3-8B QLoRA微调全记录：从loss震荡到指令遵循的调参之路
用单卡A100 80G对Llama-3-8B做QLoRA微调，踩遍了显存溢出、loss不收敛、过拟合三大坑。本文记录完整流程：4-bit NF4量化配置、128条医疗问答数据训练3个epoch，最终在自有测试集上BLEU从12.6提升到28.4，指令遵循准确率从31%到79%。附完整代码、loss曲线分析、以及一个让eval_loss骤降的trick——冻结embedding层。
RAG问答延迟砍半：chunk重切、Embedding换代与Rerank重排实测
线上RAG系统召回准确率卡在68%徘徊，用户对“答非所问”的投诉率两周涨了12%。本文记录了一次完整的检索链路优化：将固定256字符的chunk策略改为自适应语义切分，命中率提升9%；Embedding模型从BGE-large-zh换为Qwen3-Embedding-0.6B后，Recall@5提升6.5%；引入bge-reranker-base重排，最终Top1准确率从41%跃升至73%。单次问
Prompt工程调优实录：从7.2%到81.4%的意图识别准确率跃升
在构建电商客服意图识别系统时，我针对GPT-4o-mini设计了5个版本的Prompt，从最简指令到结构化思维链，token消耗从每请求89增至412，但准确率从7.2%飙升至81.4%。本文将完整还原实验过程，包含温度系数、few-shot数量、输出约束等关键参数的调优路径，并对比了不同Prompt模板在长尾场景下的表现差异。
asyncio重构Flask接口：QPS从120到1800的完整改造记录
一个内部报表接口，单次查询需聚合3个微服务数据，平均延迟850ms。用asyncio + aiohttp重写后，延迟降至180ms，QPS从120提升至1800。本文记录完整改造过程：从同步阻塞到异步并发，包含asyncio.Semaphore限流、asyncio.Timeout超时控制、loop.run_in_executor处理CPU密集任务的实战代码。踩坑包括Python 3.8下async
向量数据库选型实测：Milvus与Qdrant在500万级商品搜索场景对比
在电商以图搜图业务中，我分别用Milvus 2.4.5和Qdrant 1.12.4搭建了500万条768维向量服务。实测Qdrant单机QPS达到3200，P99延迟8ms，内存占用仅6.2GB；Milvus在分布式模式下QPS 2800，P99延迟12ms，但内存占用达到18GB。本文记录了完整部署命令、参数调优和踩坑过程，用真实数据说明选型决策。
React 19与Vue 3.5跨框架状态管理迁移：从Prop Drilling到Pinia/Zustand的工程化改造
在维护一个拥有87个路由页面、月活30万的中后台项目时，我们遇到了组件树层级超过12层的状态传递地狱。本文记录了从原生Context/Props迁移到Zustand v4.5.5（React 19.0.0）与Pinia v2.2.6（Vue 3.5.12）的全过程。通过具体对比三种方案的渲染性能（Context导致重渲染次数增加340%，迁移后FCP提升21.7%），并给出可复制的迁移步骤与性能优
asyncio改造Flask API：并发吞吐提升240%的完整实践
某次线上服务因第三方API调用频繁阻塞，Tomcat线程池耗尽，接口P99延迟飙至3.8s。我用asyncio+httpx对核心数据聚合接口进行异步化改造，将同步串行的5次HTTP调用改为并发协程，配合信号量限流与超时控制，最终QPS从120提升至410，P99延迟降至680ms。本文记录了完整的改造过程，含before/after代码、Python 3.10环境下的asyncio语义细节，以及三
React 19与Vue 3.5下从Props钻取到Zustand/Pinia的迁移实录
在维护一个超300个组件的中后台项目时，Props层层透传和Context频繁重渲染导致首屏交互延迟超800ms，内存占用峰值达180MB。我将核心业务状态从React Context/Props迁移到Zustand v5，同时将Vue子应用从Props/Provide迁移到Pinia v3，对比了两种方案的实现差异。迁移后，React应用交互响应时间降至120ms，Vue应用组件重渲染次数减少6
asyncio重构Flask接口：QPS从120到980的完整记录
一个订单查询接口，平均耗时380ms，QPS 120，压测时CPU闲置但线程池打满。用asyncio+httpx重写后，P95延迟降到89ms，QPS冲到980。本文记录完整重构过程：从Flask同步视图迁移到asyncio原生协程，包含信号量限流、超时控制、连接池复用，以及两个隐蔽的性能坑——EventLoop阻塞和DNS解析阻塞。所有代码和压测数据均来自真实生产环境（Python 3.10.8
asyncio重构Flask接口：QPS从120到2100的并发改造实录
某次压测中，我发现一个基于Flask的订单查询接口在4核8G机器上QPS仅120，CPU利用率不足30%。通过引入asyncio + aiohttp替换requests同步调用，配合semaphore限流和连接池复用，QPS提升至2100，TP99延迟从820ms降至45ms。本文记录了完整的改造过程，包含before/after代码、asyncio.Semaphore、await futures
Milvus与Qdrant选型实测：中文搜索业务下的性能与资源博弈
在电商语义搜索场景下，我们对比了Milvus 2.4.1与Qdrant 1.9.2的部署复杂度、查询延迟与资源占用。实测500万条512维向量，Milvus在16核32G配置下P99延迟为23ms，Qdrant为41ms；但Qdrant内存占用仅为Milvus的58%。本文记录了两者从Docker部署到参数调优的完整过程，包含三次踩坑经历和最终选型结论，为同样纠结于向量库选型的团队提供一份可直接复
Git工作流重构记：从混乱主干到分支策略与CI/CD落地
三个月前，我们的团队还在为“主干提交”引发的冲突焦头烂额：一次上线平均需要2小时手动合并，线上Bug率高达15%。本文记录了我们将Git工作流从“裸奔”升级为“Git Flow + PR Review + Jenkins流水线”的全过程。文中给出了具体的分支命名规范、`.gitignore`与`Jenkinsfile`配置，以及如何通过`git bisect`定位回归。重构后，我们的发布频率从每周
FastAPI性能调优实录：Profiling定位与多级缓存策略
一个线上接口从平均响应1200ms压到180ms，吞吐量提升6.5倍。本文记录一次完整的API性能调优过程。通过cProfile与py-spy定位到瓶颈不在数据库而在序列化与重复查询；随后引入SQLAlchemy 2.0的selectinload预加载、Redis二级缓存以及gzip中间件，最终在wrk压测下（500并发，60秒）P99延迟从2.1s降至320ms。全程基于FastAPI 0.10
Docker Compose编排多服务：网络隔离与健康检查实战配置
本文分享一个真实项目中的docker-compose.yml配置，涵盖3个服务（Nginx网关、Spring Boot应用、PostgreSQL数据库）的完整编排方案。通过自定义bridge网络实现服务隔离，利用volume持久化数据库文件，配置healthcheck保障启动顺序。实测服务启动时间从手动部署的45秒缩短至18秒，容器重启恢复时间控制在5秒内。文中提供可直接运行的配置代码，并详细说明
