2026年1月11日周日窗外在下雨。我花了整个下午把自己在2025年留下的笔记、git提交记录和聊天记录翻了一遍才决定写这篇年度总结。这不是公司要求的季度汇报也没有固定模板纯粹是我需要站在一个时间点上看清楚过去一年换过的工具、踩过的坑、做完的项目哪些真正留下了哪些应该被淘汰。这篇总结适合想给自己做年度复盘的技术从业者也适合还在各种效率工具里反复横跳的同行同样适合好奇一个技术博主一年到底在忙什么的普通读者。我的原则是每个结论尽量讲清楚“为什么”以及具体怎么做不只有一句“挺好用”。1. 回看2025真正改变我工作流的那几件事1.1 编辑器迁移从VS Code到Neovim我折腾了半年才敢说值2025年年初我手上的项目突然多了起来。几个前端工程加上两个Python服务VS Code开着三个窗口风扇就开始呼呼响。最让我受不了的不是内存占用而是打开大文件或者做全局搜索时索引经常卡住几秒光标在原地打转。那时候正好刷到不少关于Neovim的视频加上手头有一个常驻服务器需要远程改代码我决定认认真真试一次迁移。我没有从零手写配置而是直接选了LazyVim发行版作为起点。原因很简单我需要的不是“学习配置的痛苦过程”而是“先跑起来再慢慢改造成自己的”。LazyVim默认集成了telescope.nvim、treesitter、gitsigns、nvim-lspconfig这些核心插件终端打开就是一套相对完整可用的IDE体验。我给自己定了一个规矩前两周所有日常开发都在Neovim里完成即使效率下降也不切回VS Code直到顺手为止。事实证明前两周确实痛苦。最卡的不是熟悉快捷键而是肌肉记忆。CtrlS按成空格加字母的组合单文件改动一件小事都要想一下操作。但第三周开始频率明显降低。真正让我决定彻底切换的是两个场景一是远程连服务器改代码Neovim在终端里直接跑不需要本地的文件同步和端口转发二是在一台只有2GB内存的小机器上Neovim的启动时间不到50msVS Code光初始化就要等好几秒。我用mason统一管理LSP服务python-lsp-server和typescript-language-server装好之后跳转定义、自动补全、诊断提示基本都够用。git操作直接落在gitsigns里改哪一行、撤销哪个改动行号旁边看得清清楚楚。flash.nvim替代了原来的搜索跳转按下两三个键就能在文件里精准定位这个体验确实比鼠标滚动快很多。需要老实说的是我并没有完全放弃VS Code。遇到复杂调试、Android项目、或者需要图形化插件支持的场景我还是会切回去。我的建议是不要把编辑器迁移当成信仰问题而当成工具匹配问题。如果你日常只写Java或者C#VS Code和对应IDE已经很完善没必要折腾。但如果你经常跑服务器、写脚本、做轻量前端Neovim非常值得投入时间因为长期看省下的切换成本是实打实的。1.2 笔记体系从“工具收藏家”变成“能用纯文本检索的人”2025年之前我的笔记经历了一段极其混乱的时期。Notion里存了一堆数据库飞书文档里又有一批本地还有几个乱糟糟的Markdown文件。到后来我根本不知道某条笔记存在哪里只能靠搜索但搜出来又经常是旧版本。年中一次记错项目时间节点之后我下定决心把笔记体系整理干净。最终的选择是Obsidian配合纯Markdown文件存放在本地文件夹里。核心原因只有一个数据不绑架工具。任何笔记软件都可能停止维护、调整收费或者出现同步问题但纯文本永远不会过期。我用git来管理这个笔记仓库出门前push一次回家pull一次每次改动都有历史记录比任何云同步都让人放心。我的文件命名规则是YYYY-MM-DD-主题.md比如2025-05-12-数据库索引笔记.md。标签我控制在三类主题类比如#python、#工程化状态类比如#idea、#done、#todo来源类比如#book、#视频、#实践。这样做的效果是搜索时不需要记得标题只需要回忆一个大概的主题词和时间范围。截止到年底我的笔记仓库一共有一千两百多个文件git history清晰我可以随时回溯任何一个知识点当初是在什么背景下记录的。这里有一个容易踩的坑给自己定太多规则最后坚持不下去。我试过耶鲁笔记法、康奈尔笔记法、卡片盒笔记法每一种都坚持不到两周。后来想明白了笔记体系的第一目标不是“记得漂亮”而是“找得回来”。所以我给自己定的底线就三条新笔记一定进当天日期文件重要结论一定用加粗和列表突出每周日晚上花十分钟清理无用的临时笔记。规则越少越能长期坚持。2. 工具选型复盘为什么我留下的东西越来越少2.1 终端方案Alacritty和tmux的组合最终留了下来过去一年我在终端上前后试过六七个方案。年初还在Windows上用Windows Terminal后来换到macOS试过iTerm2、Warp、Alacritty、WezTerm最后固定下来的是Alacritty配合tmux。先说为什么放弃Warp。Warp的交互做得确实新颖输入提示和命令补全都很聪明但它依赖云端账户体系输入内容会和账号绑定这一点让我不太舒服。而且一旦自定义需求变多它的配置反而比传统终端复杂快捷键体系也要重新学。iTerm2非常成熟功能全但对一个主要用tmux管理会话的人来说它的很多功能其实用不到内存占用却一直不低。Alacritty的核心卖点是GPU渲染和极简配置。它没有标签页、没有分屏这些功能我在Neovim和tmux里已经足够。配置文件是一个YAML新版本改成了类似TOML的格式我把它放在dotfiles仓库里任何机器上clone下来就能用。配合tmux我的典型工作流变成打开Alacrittytmux自动恢复上一次的会话左边窗口跑后端服务右边窗口开Neovim底下再放一个窗口看日志。tmux的配置我做了几处关键调整。第一是把前缀从CtrlB改成CtrlSpace大幅减少小指按错的概率。第二是用插件tmux-resurrect保存会话突然断开重新连上的时候窗口布局和当前目录还在。第三是绑定了几个常用快捷键Alt方向键切换窗口Shift方向键调整窗格大小。这些改动花了我大概两个晚上但之后每天省下的时间是持续的。如果你还在纠结终端我的建议是不要把选型搞得太复杂。先想清楚你需要的是什么如果只是本地写代码系统自带的终端已经足够如果需要远程工作流和会话复用把省下来的时间花在学tmux上回报率远高于换终端本身。2.2 看板与待办放弃All-in-One后我反而不再焦虑2025年上半年我一度沉迷于搭建“完美”的个人管理系统。Trello上有看板Notion里有项目管理数据库滴答清单里排着每三十分钟一个的任务手机桌面全是工具小组件。结果忙了一个季度事情一件没少做但每天光维护“管理工具”就要花掉大半个小时。某天我打开Trello看板发现两个月前建的一条卡片还在待办区躺着而这事我早已通过聊天工具完成了那个瞬间我决定做减法。最后留下的方案朴素到有点寒酸一个todo.md文件放在笔记仓库里分成三块——本周重点、今日安排、随时记录。每天早上打开文件把昨天没做完的事移到今天晚上看一眼能完成就打勾未完成就写下原因。看板只保留一个场景团队合作时用。个人任务用看板完全是过度的信息层级一个列表三行字就能表达清楚不需要拖拽卡片、标签颜色和截止日期。这套方案刚用的时候我还会反复去检查“这个方式是否足够科学”后来才意识到这也是问题的一部分。待办工具的核心价值是提醒而不是秩序感。当工具本身变成你每天最大的开销时它就已经失败了。2.3 自托管与最小家庭服务器一台旧笔记本解决三个需求2025年夏天我把一台闲置的旧笔记本改装成了家庭服务器装的是Debian系统跑着少量Docker容器。初衷不复杂就是想解决三件事多设备文件同步、订阅源阅读、统一书签管理。文件同步我用了Syncthing在笔记本、台式机和服务器之间建立双向同步。好处是数据不经过任何中间云服务商组织结构由自己控制手机上装个客户端也能访问。订阅源阅读用的是一款轻量RSS阅读器每天固定时间抓取更新我在浏览器里通过阅读器界面消费不再被算法推送裹挟。书签管理则是把浏览器的收藏导出成HTML文件再用一个简单的自建页面托管所有设备共用同一个入口。这里我想提醒一句自托管非常容易上瘾也很容易翻车。很多人一上来就规划装Nextcloud、装GitLab、装媒体中心、装智能家居平台最后服务器变成一台持续Debug的玩具。我的原则是只用它解决无法用免费工具舒适解决的需求而且服务数量控制在三个以内。但凡市面上有一个成熟靠谱的托管服务我都不优先自己搭。服务器是给需求服务的不是需求给服务器服务的。3. 2025年踩过的坑每条都能写进教训清单3.1 一块移动硬盘突然不认盘才让备份策略变成立场问题2025年4月我一块用了三年的移动硬盘插上电脑后毫无反应指示灯都不亮了。硬盘里有我过去几年的设计稿、两期视频的工程文件和一些旧项目代码。送修后确认盘体损坏数据恢复的报价高得离谱最终只能含泪放弃。这个坑一点都不新鲜但轮到自己头上还是让人很不舒服。复盘之后我发现问题出在“备份”这件事做得过于随意平时只往外拷文件没有做任何异地冗余。硬盘坏掉的那一刻本地机器上其实也没全量副本。之后我建立了一套相对可靠的备份方案核心是3-2-1法则三份数据副本两种不同存储介质至少一份异地存放。具体执行上我用restic作为备份工具加密后发送到对象存储。每周日凌晨系统自动执行一次全量备份备份结束后会通过通知机器人给我发送一条“备份完成”的消息。半年下来我做了一次恢复演练完整地把一个项目文件从备份中还原到新目录确认可用。经验总结下来就几句话备份流程必须自动化靠手动的备份早晚会断档必须有恢复演练备份不能恢复等于没备份必须考虑加密和隐私数据放到第三方存储前先加密。我把这三条写在了服务器的配置注释里保证自己任何时候打开都能看到。3.2 自动化脚本翻车现场cron任务里那点环境变量的事2025年有一阵子我写了个Python脚本用来定期清理临时目录和旧日志。脚本在本机手动执行一切正常但放进cron里就是不按预期工作日志里留了一堆报错最典型的是command not found。排查了半天才发现问题是cron环境变量和交互式shell完全不同。交互式终端里PATH通常由/etc/profile、~/.bashrc等加载包含了python的安装路径。而cron执行时使用的是一个极简环境PATH基本只有系统默认路径python根本不在里面。脚本第一行虽然写了#!/usr/bin/env python3但env找不到python路径自然执行失败。这次教训之后我给自己定了几条规则。cron脚本里要么在脚本开头显式定义PATH要么直接在crontab里加上PATH/usr/local/bin:/usr/bin:/bin确保重要程序都能找到。凡是在脚本里依赖了环境变量的一律在脚本内部使用绝对路径或者显式引入。写shell脚本时开头加上set -euo pipefail避免中途出错还在继续往下跑最后用日志文件记录输出方便排查。发给别人的建议是任何定时任务第一次上线都先设置成每十分钟执行一次观察两小时看日志输出是否符合预期随后再改成目标频率。不要一上来就每天凌晨执行出了问题查起来痛苦。3.3 多设备同步里的文件冲突我差点把一篇写了一半的文章弄丢2025年8月我在笔记本和台式机之间用Syncthing同步笔记仓库。有一天开了两台机器笔记本上的Obsidian正在编辑一篇长文台式机也同步到同一文件且正好触发一次写入。结果两边同时修改Syncthing按照策略保留了一个冲突副本文件名变成了2025-08-15-xxx.md.sync-conflict-20250815-123456-ABCDE.md。我当时没注意直接用Obsidian打开了原文件继续写写完才发现新内容全在那个末尾带乱码的冲突文件里。这件事给我两个启发。第一同步工具不是编辑工具任何实时同步方案在多人或多设备同时编辑同一文件时都可能产生冲突正确做法是尽量避免同一时间在多个设备上打开同一篇待编辑文档。第二建立每周一次“清理冲突文件”的习惯在文件管理器里搜索sync-conflict把冲突内容手动合并或者确认删除防止文件越积越多、最终分不清版本。后来我干脆把Obsidian仓库的同步方式改为git编辑前先pull编辑完commit再push冲突会非常明确地暴露在版本控制里不会像这样暗地里生出一个诡异文件名。这类问题网上讨论不算少但总是被当成个例对待实际上一旦你踏入多设备工作流概率比你想象中高得多。4. 开源参与和知识沉淀从“使用者”到“提PR的人”4.1 这一年我提过的PR和跨过的CI门槛2025年我做了一个决定不再只当开源项目的使用者试着参与进去。先从自己一直在用的工具开始比如一个Markdown预览插件和一个终端提示工具。第一次提PR我以为只要把代码改好push上去就行结果被CI的错误列表当场教训了一轮。最典型的一次我修复了一个小bug本地跑测试全过push之后CI却在lint阶段挂了。原因是我没有安装项目规定的pre-commit钩子代码格式化风格和项目不一致。后来我学到的流程是先看CONTRIBUTING文档再clone官方仓库按项目要求安装依赖和钩子改动之前先跑一遍现有测试确认基线正常功能改动尽量附带对应测试提交说明按约定式提交的格式写清楚。还有一次我踩了测试环境变量的坑。我的改动在本地一直通过CI却失败排查后发现是我本地的环境变量掩盖了缺失配置的问题。真正健壮的测试应该在独立环境下运行不能隐式依赖开发者机器上的全局环境。这个教训对我后续写自己的脚本也很有帮助。整个下来我给七八个项目提过PR合进了五六个。现在回头看最有价值的不是那些被合并的代码行而是我学会了如何与不同维护者的节奏配合问题描述尽量给足复现步骤讨论问题时先摆事实再给观点代码改动范围控制得越小越好。如果你也想参与开源建议从自己真正使用的工具开始这样你会更清楚改动带来的影响也更有动力把测试和文档补完整。4.2 博客与写作为什么我坚持不追热点2025年我的博客更新频率大概是一周一到两篇全年大约六十篇。不追热点、不写“震惊体”内容几乎都围绕一个逻辑做了什么、为什么这么选、最后结果如何。有几篇文章确实没有很多人看但恰恰是那些小透明文章在几个月后帮我解决了好几次重复问题。比如一篇关于本地开发环境配置的笔记后来我在新电脑上重新配环境时直接照着那篇文章操作省了很多搜索时间。我的写作流程固定成每周六下午完成整个过程控制在两到三个小时。先把这一周碰到的实际问题列出来挑一个最值得记录、也最可能让其他人避坑的题目。然后按“背景-操作过程-踩坑点-总结建议”写出干货部分。写之前不看别人的同类文章以免思路被带跑。写完放一个晚上第二天早上再读一遍删掉情绪化表达和不必要的形容词。对于想开始写技术博客的人我的建议是不要等“准备完美”再动手。你不需要流量不需要固定读者甚至不需要特别深的技术主题。只需要把一件自己做成了的事讲清楚就已经比大多数“知识搬运”有价值。长期沉淀下来它能形成属于你自己的知识索引库这是任何收藏夹和书签都比不了的。5. 下一步进入2026年我打算怎么做5.1 大刀阔斧砍掉的事情站在2026年1月11日往回看我最大的感受是“工具并不稀缺稀缺的是注意力”。于是2026年的第一件事就是砍东西。首先淘汰所有“摸鱼式效率工具”。凡是需要额外打开一个软件才能记录待办、查看数据、整理知识的如果和我的命令行工作流无法自然衔接一律停用。其次不再折腾桌面美化、窗口管理器主题、键盘配置的“终极方案”。这些领域很容易让人投入大量时间但对实际产出几乎没有任何帮助。最后把订阅的RSS源从两百多个砍到四十个左右只保留那些能持续提供高质量信息的源。砍完这些之后我发现每周至少多出五到八小时可自由支配的时间。这些时间用来写代码、写文章或者纯粹休息都比用来维护工具强得多。5.2 打算长期坚持的小原则通过去年一整年反复试错我给自己定了几条长期有效的小原则。第一任何重要数据都必须有自动化备份备份方案必须每年实测一次恢复过程。第二笔记必须使用可迁移格式存储任何无法直接导出为通用文件格式的工具都不值得投入长期内容。第三新工具引入之前先写下“替代了什么、解决什么具体问题、是否值得放弃成熟方案”这三句话想不清楚就不引入。2026年我不打算再列宏大目标。过去几年的经验告诉我目标设得越具体、越夸张放弃得越快。与其定“一年读五十本书”这种数字不如定“每天睡前看二十分钟对提升技能有帮助的资料”这种行为习惯。只要行为在重复结果自然会积累。这篇总结写到这里我脑子里已经很清楚今年该怎么走了。对我来说工具是放大器真正决定生产效率的是每天如何使用它。2026年的主题不是加法是克制。数据选型、写作、开源参与、个人管理都会按这个节奏继续推进。相比去年我少了很多折腾多了一点笃定。