全栈开发工程师 · 独立创作者
我专注于 |
热爱用代码解决真实问题，专注 Web 开发、云原生与人工智能。写博客分享技术思考，偶尔折腾开源项目。
你好，我是林一。一名 5 年经验的软件工程师，目前在一家科技公司负责平台架构与前端工程化。 工作之余喜欢写技术博客、研究开源项目和打磨个人工具。
我相信技术应该服务于人，也相信持续输出是最好的学习方式。
聊聊 Monorepo、增量构建与缓存策略如何把发布耗时从 20 分钟压到 3 分钟。
这篇文章记录了我在团队内推进构建流水线优化的完整过程。起点很朴素：一次发布要等 20 分钟，所有人都把发布当成了「下午茶的开始」。经过梳理，瓶颈主要在三处——依赖安装、跨项目重复构建、以及缺乏缓存。
最终方案是引入 pnpm workspace 配合内容寻址缓存，并给每个构建产物打上可复现的指纹。改动上线后，平均发布耗时从 20 分钟降到 3 分钟以内。文中也会分享踩过的几个坑，比如缓存命中率虚高、增量构建的边界问题等。
一次低成本接入检索增强生成的实战记录：向量化、召回与重排的取舍。
接到需求时，团队最大的顾虑是成本与风险：旧系统的文档散落在多个内部平台，直接训练模型不现实。RAG 成了唯一合理的选项。
文章会拆解完整链路：文档清洗与分块策略、Embedding 选型、向量库对比，以及最关键的一步——召回质量差时如何用重排兜底。结尾附上了我们在生产环境的评测数据与调参心得。
从 Pod 反复重启到定位到 cgroup 内存限制，记录完整的排查路径与预防措施。
某天凌晨告警系统连续推送 Pod 重启通知。一开始以为是发布回滚问题，直到发现重启时间点毫无规律，才意识到方向错了。
顺着 kubelet 事件、container 日志、cgroup 内存文件一步步排查，最终定位到是应用在高峰期内存暴涨触发 OOM。文章整理了完整的排查时间线与三个预防手段：内存限额预留、优雅退出与容量规划。
关于持续输出、知识沉淀与个人品牌的几点真实感受。
三年、80 多篇文章，经常被问「写博客真的有用吗」。我的答案一直是：有用，但收获不在流量。
写作强迫我把「感觉会了」变成「真的会了」，每一次被读者纠正都是一次免费的技术评审。文章也从最初的笔记式流水账，慢慢变成有框架、有结论的分享。这篇聊聊我踩过的弯路和坚持下来的方法论。
无论是合作、交流还是单纯打个招呼，都欢迎通过以下方式找到我。
