1. 项目概述一个开发者的“瑞士军刀”是如何炼成的在程序员这个行当里干了十几年我越来越觉得一个趁手的开发工具集就像战士的武器、厨师的刀具是效率和心流的直接来源。但和很多人追求“最新最全”不同我的工具集充满了“瞎搞”的痕迹——这个词听起来不专业却是我最真实的写照。它不是一份来自官方推荐的标准清单而是一个在无数深夜调试、项目救火、以及“这玩意儿能不能更好用一点”的好奇心驱使下不断试错、淘汰、组合出来的个人化解决方案。今天我就来聊聊我这个“瞎搞”出来的开发工具集以及我在不同场景下对同类工具的深度比较和选择逻辑。这不仅仅是一份工具列表更是一个老码农在效率、习惯与工具之间寻找平衡点的实战记录希望能给正在构建自己“兵器谱”的你一些启发。2. 工具集构建的核心思路与选型哲学2.1 为什么是“瞎搞”而非“最佳实践”“最佳实践”往往意味着普适性、稳定性和团队协作友好。但对于个人开发环境而言绝对的“最佳”可能并不存在。我的“瞎搞”哲学基于几个核心原则效率至上而非潮流所向一个工具是否流行远不如它是否能解决我的具体痛点重要。例如当大家都在用某个酷炫的终端时我可能还在用经过高度定制化的老牌工具仅仅因为它启动快0.5秒并且所有快捷键都刻在了肌肉记忆里。这0.5秒在一天上百次的开关中节省的是实实在在的注意力资源。深度集成减少上下文切换我的目标是让工具之间“对话”形成一个工作流闭环。比如我的笔记工具能快速捕捉终端命令输出我的编辑器能直接唤起API测试工具。减少在窗口间 AltTab 的次数就是减少思维被打断的可能。可编程性与可扩展性我偏爱那些可以通过脚本、插件或配置进行深度定制的工具。一个“死”的工具很快会过时而一个“活”的、能随需求成长的工具才能成为长期的伙伴。这意味着学习曲线的前期投入是值得的。轻量与本地的权衡在云服务唾手可得的今天我仍然倾向于将核心开发工具和中间数据放在本地。这并非不信任云端而是为了追求极致的响应速度和离线工作的可能性。网络延迟和认证问题在关键时刻可能是致命的。基于这些原则我的工具集更像一个“有机体”工具之间通过脚本、快捷键和约定进行连接而非一个堆砌了所有明星产品的“展览馆”。2.2 核心工具类别与我的选择矩阵我将开发工具粗略分为几个核心类别并为每个类别建立了自己的选择维度。下面这个表格概括了我的核心考量点工具类别我的核心维度说明文本编辑器/IDE启动速度、插件生态、键盘驱动、项目感知能力这是码农的“主战场”速度和多语言支持是底线插件决定了上限。终端与Shell渲染性能、分屏管理、会话持久化、与编辑器的集成命令行的效率直接决定底层操作的流畅度美观和功能需并存。版本控制命令行友好度、图形化辅助工具、分支管理可视化Git是绝对核心但一个好用的GUI工具在代码审查和复杂历史浏览时不可或缺。API测试与调试请求组织能力、环境变量管理、脚本化、团队协作后端和全栈开发的日常结构化管理和可重复执行是关键。笔记与知识管理纯文本友好、双向链接、快速检索、代码块支持用于记录临时想法、项目日志、解决方案必须能无缝容纳代码片段。数据库客户端多数据库支持、查询历史、结果集导出、ER图生成需要同时连接多种数据库高效的查询编写和数据探查能力很重要。这个矩阵不是一成不变的它会随着我主要技术栈的变迁比如从后端转向更多全栈而动态调整。但核心思想不变每个工具都必须在其岗位上贡献独特的、不可替代的价值否则就会面临被精简的命运。3. 核心工具深度对比与我的“瞎搞”配置3.1 编辑器之争VS Code 与 Neovim 的长期共存这可能是最具代表性的“瞎搞”案例。我主力使用 VS Code但同时在终端环境中深度配置了 Neovim。这不是精神分裂而是场景化分工。VS Code我的项目级“指挥中心”我选择VS Code绝不是因为它“流行”而是因为它完美平衡了开箱即用和深度定制。我的“瞎搞”体现在极简启动我禁用了所有非必要的自动更新、遥测和欢迎页面。通过settings.json精心调配关闭了文件缩略图、 minimap对我来说容易分心将工作区设置为只显示当前打开的文件树。目标是启动时间控制在1秒内且界面元素最少。插件精选而非堆砌我只有不到20个插件。核心包括GitLens但只启用“当前行提交信息”等核心功能关闭所有花哨的UI装饰。Remote - SSH/Containers这是我离不开VS Code的决定性原因。它让我能在本地获得近乎原生地编辑远程服务器或Docker容器内文件的能力配合SSH密钥代理体验无缝。Vim模式插件VSCodeVim这是连接我两个编辑器世界的桥梁。让我在VS Code中保持Vim的编辑肌肉记忆。键盘驱动一切我重新绑定了几乎所有常用操作到键盘快捷键目标是手不离键盘完成90%的操作。例如我用CtrlShiftP打开命令面板的频率远高于点击图标。注意VS Code的配置同步功能我并未使用。我选择用Git仓库手动管理我的settings.json和keybindings.json。原因有二一是确保配置变更在我的完全掌控下二是在新机器上搭建环境时git clone一份配置比登录微软账户更符合我的“本地化”哲学。Neovim我的文本处理“手术刀”在服务器上、在快速编辑单个配置文件、或者需要纯键盘流式操作时Neovim是我的不二之选。我的配置方向是“现代化但克制”配置语言从Vimscript转向Lua新的配置更清晰、性能更好。我用Lazy.nvim作为插件管理器它的惰性加载机制让启动速度飞快。核心插件组合Telescope.nvim模糊查找文件、内容、Git提交等是效率的核心。nvim-treesitter提供更好的语法高亮和代码结构感知。nvim-lspconfig 对应LSP提供与VS Code类似的代码补全、跳转、提示功能这是现代Neovim能与IDE抗衡的基础。Harpoon一个极简的项目文件快速切换管理器替代笨重的文件树。终端集成我配置了toggleterm插件可以在Neovim内直接弹出浮动终端执行命令后结果直接回显非常适合运行单次测试或快速查询。比较与心得启动速度Neovim在终端内启动是毫秒级VS Code再优化也是秒级。对于“快速看一眼/改一下”Neovim完胜。项目复杂度对于大型、多语言项目需要频繁在文件间跳转、调试、使用图形化Git工具时VS Code的集成度提供了更顺畅的体验。心智负担VS Code更像一个“系统”我需要管理它的更新、插件兼容性。Neovim则更像一个“程序”配置稳定后可以数年不变心智负担更低。我的选择两者都用但不追求“统一”。我接受两者在快捷键和操作上微小的不一致。VS Code用于深度项目开发Neovim用于运维、配置和轻量编辑。让工具适应场景而不是强迫自己用一种工具适应所有场景这是最重要的“瞎搞”心得。3.2 终端WezTerm 与 tmux 的强强联合终端是命令行的载体它的稳定和高效是底层保障。我最终选择了WezTerm作为终端模拟器并用tmux管理会话。为什么是WezTerm我尝试过几乎所有主流终端Alacritty, Kitty, iTerm2, Windows Terminal等。WezTerm胜在跨平台一致我用macOS和LinuxWezTerm的配置一个Lua文件在两个系统上几乎完全一致减少了环境切换成本。功能全面而内聚它内置了标签页、分屏Pane、滚动回查、图像显示支持。我不再需要额外依赖screen或tmux来做基础分屏尽管我仍用tmux做会话管理。配置即代码所有配置字体、颜色、快捷键、行为通过wezterm.lua文件定义版本化管理极其方便。性能卓越渲染速度快在快速滚屏或输出大量日志时无卡顿。我的WezTerm“瞎搞”配置包括自定义配色方案基于Gruvbox Dark、调整字体连字Fira Code、设置超时较短的防误触快捷键前缀从默认的Ctrlb改为Ctrla但只在需要时启用tmux风格分屏。为什么还要用tmux既然WezTerm有分屏为何还用tmux因为tmux解决的是“会话持久化”问题。它的核心价值在于会话恢复服务器上工作网络断开或关闭终端所有工作状态运行中的进程、多个窗口和面板布局都保存在tmux会话中。重新连接SSH一个tmux attach命令就能完全恢复现场仿佛从未离开。工作区模板我通过脚本定义不同的tmux会话模板。例如一个“web开发”会话启动后自动创建三个面板一个运行前端服务一个运行后端服务一个打开日志文件。一次设置重复使用。与WezTerm互补我通常在一个WezTerm标签页中运行一个tmux会话。WezTerm管理多个“项目标签页”而每个标签页内的tmux管理该项目的“多个工作窗口”。形成了“标签页 - tmux会话 - tmux窗口 - tmux面板”的四层管理结构非常清晰。实操配置片段 我在~/.tmux.conf中进行了大量优化# 更改前缀键为Ctrl-a感觉比Ctrl-b更顺手并设置快速重载配置 set -g prefix C-a unbind C-b bind C-a send-prefix bind r source-file ~/.tmux.conf \; display “配置已重载” # 启用鼠标支持方便调整面板大小和选择窗口 set -g mouse on # 设置面板分割快捷键更符合直觉| 和 - 的形状 bind | split-window -h bind - split-window -v unbind ‘“’ unbind % # 使用vi风格的键绑定进行面板导航 bind h select-pane -L bind j select-pane -D bind k select-pane -U bind l select-pane -R # 启用真彩色支持让颜色主题正确显示 set -g default-terminal “tmux-256color” set -ag terminal-overrides “,xterm-256color:RGB”这套组合拳下来我的终端环境既具备了现代终端的美观与功能又拥有了服务器级的坚韧和可恢复性。4. API测试从 Postman 到 Insomnia 再到 Bruno 的折腾之路API测试工具是我工具集中迭代最频繁的之一因为它直接关系到后端和前后端联调的效率。Postman曾经的王者如今的负担早期我深度使用Postman。它的优势在于生态强大、团队协作功能完善、文档生成方便。但随着时间的推移我越来越感到其“沉重”性能问题随着Collection集合变大客户端启动和切换变慢。强制登录与同步虽然可以离线使用但频繁的登录提示和同步冲突让人心烦。我的API集合是工作资产我不希望它被绑定在一个必须联网的云账户上。商业化导向越来越多的高级功能被移到付费墙后免费版限制增多。Insomnia优雅的替代者于是我转向了Insomnia。它的设计非常优雅用户体验流畅核心的请求组织、环境变量、脚本预处理等功能都很好用。并且它早期版本对离线使用非常友好。然而问题同样出现在商业化和数据归属上。公司被收购后其开源版本Insomnia Core停止更新主力推动付费的Insomnia Designer。我再次面临工具未来不确定性的风险。Bruno我的最终选择——回归文件与本地在经历了上述折腾后我发现了Bruno。它完全契合了我“本地、文件化、可控”的理念革命性的存储方式Bruno不将数据存在私有数据库或云端而是直接使用文件系统和文件夹来管理API集合。每个Collection就是一个文件夹每个请求就是一个纯文本文件使用它自定义的.bru格式实质是易读的标记语言。这意味着什么我的所有API请求、环境配置都可以用Git进行版本管理。我可以清晰地看到每次请求的变更历史。我可以直接用文本编辑器批量修改请求。集合的分享就是复制一个文件夹。离线优先它就是一个本地应用无需账户无需联网除了发送请求本身。基础功能齐全请求组织、环境变量支持多级继承、脚本JavaScript、测试断言、文档生成这些核心功能一个不少。我的Bruno“瞎搞”工作流我为每个项目创建一个Git仓库里面有一个api目录。在Bruno中创建对应项目的Collection路径指向这个api目录。所有的接口调试、文档编写都在Bruno中进行数据实时保存为.bru文件。这些.bru文件随项目代码一同提交到Git。后端同事更新了接口我可以直接拉取代码Bruno里自动就看到了新的或修改过的请求文件。我甚至写了一个简单的脚本将.bru文件中的关键信息如请求路径、方法提取出来自动生成一个简单的Markdown接口目录。从Postman到Bruno我的选择轨迹清晰地反映了一个趋势从依赖臃肿的、云化的、封闭生态的工具转向追求轻量、本地化、数据自主的、能与现有工作流如Git深度集成的工具。这种控制感对于开发者来说至关重要。5. 笔记与知识管理Obsidian 如何成为我的第二大脑作为开发者我们不仅要写代码还要处理海量的信息临时灵感、项目日志、技术方案、会议记录、学习笔记。一个高效的笔记系统就是“第二大脑”。我尝试过Notion、语雀、OneNote等最终锚定在Obsidian。原因很简单它基于本地Markdown文件且拥有强大的双向链接和图谱功能。“瞎搞”出来的开发专用工作流项目日志库我为每个大型项目在代码仓库旁建立一个notes文件夹里面是一个独立的Obsidian库。里面存放Project-Home.md项目概述、核心架构图、关键决策记录。Meeting-Notes/按日期存放的会议记录。Tech-Decisions/技术选型论证过程。Bug-Investigation/对复杂Bug的排查过程和根因分析。API-Specs.md手动维护或从Bruno生成的接口文档。所有这些笔记之间通过[[内部链接]]相互关联。当我在排查一个Bug时可以快速链接到相关的技术决策记录或API文档。代码片段管理Obsidian完美支持代码块。我建立了一个“代码片段”库按语言和功能分类。更重要的是我使用dataview插件让它变成了一个可查询的代码数据库。## 一个Python请求重试片段 python import requests from tenacity import retry, stop_after_attempt, wait_exponential retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min4, max10)) def call_api_with_retry(url): response requests.get(url) response.raise_for_status() return response.json() tags: python, http, retry, snippet然后我可以在任何地方用dataview查询TABLE language, file.cday AS “创建时间” FROM “代码片段” WHERE contains(tags, “python”) AND contains(tags, “http”) SORT file.cday DESC与终端集成通过Shell脚本我可以快速将终端命令的输出捕获到Obsidian中。例如一个命令log_debug “今天部署遇到了依赖冲突”可以自动将当前时间、工作目录和这条信息追加到当天的日志文件中。图谱视图用于知识发现这是Obsidian的杀手锏。当项目笔记积累到一定程度后打开图谱视图可以看到各个概念、模块、问题之间的连接关系。经常能发现之前没意识到的知识关联激发新的解决思路。Obsidian vs. 其他工具Notion强大、美观、协作性好但在线、有延迟、数据导出格式受限。它适合团队文档和项目管理但不适合作为需要快速检索、长期沉淀、且与本地文件系统深度交互的开发笔记系统。语雀/飞书文档优秀的企业知识库同样面临在线和封闭格式的问题。纯文本编辑器文件夹最灵活但缺乏链接和全局检索能力知识是孤岛。Obsidian在“本地文件控制权”和“强大的知识连接能力”之间取得了最佳平衡完美契合了开发者喜欢用文本、喜欢版本控制、喜欢一切尽在掌握的心理。6. 数据库客户端TablePlus 与 DBeaver 的取舍数据库客户端是后端开发的另一大高频工具。我的选择标准是支持多种数据库、查询编辑体验好、数据展示清晰、导出功能灵活。在这个领域我主要在两个优秀工具间做选择TablePlus和DBeaver。TablePlus颜值与体验的担当TablePlus是我个人开发环境中的首选原因如下出色的用户体验界面现代简洁响应迅速。编辑数据像在Excel里一样直观内联编辑这对于快速修改测试数据非常方便。多数据库支持支持MySQL、PostgreSQL、SQLite、Redis、MongoDB等数十种用一个工具搞定大部分需求。连接管理安全将连接信息密码存储在系统钥匙串中安全且方便。实用的细节功能比如可以非常方便地查看和复制一条记录的JSON格式可以给查询结果中的不同数据行高亮标记内置了简单的数据筛选和排序。我的“瞎搞”用法是为每个开发环境本地、测试、预发布建立不同的连接配置并使用颜色标签进行区分避免误操作。DBeaver功能与深度的王者当遇到更复杂、更企业级的场景时我会打开DBeaver功能无比全面它是真正的数据库管理工具而不仅仅是客户端。数据导出导入格式极其丰富包括直接生成INSERT语句。ER图生成、数据对比、SQL脚本版本管理内置Git集成、元数据浏览等功能都非常强大。开源免费社区版功能就足够强大适合个人和团队使用。可扩展性插件体系允许你深度定制。我的选择策略日常开发、快速查询、简单数据操作使用TablePlus。它的流畅和直观能最大化我的效率。数据迁移、生成复杂报表、分析数据库结构、进行数据对比使用DBeaver。它的强大工具集能应对这些专业任务。对于Redis我反而更喜欢用另一个更轻量的专用工具Another Redis Desktop Manager因为它对Redis数据结构的展示和操作更加优化。这个选择再次印证了我的工具哲学没有银弹根据任务场景选择最合适的工具并接受同时维护多个工具的成本只要它们带来的效率提升大于切换成本。7. 其他“小而美”的辅助工具除了上述核心工具我的工具箱里还有一些“小而美”的辅助工具它们各司其职解决特定痛点fzf(命令行模糊查找器)这不是一个GUI工具而是一个命令行神器。它可以与任何产生列表的命令结合进行交互式模糊查找。我把它和zsh集成用于历史命令搜索 (CtrlR)、文件查找、进程查找、甚至Git分支切换。它极大地提升了命令行的交互效率。zoxide一个更智能的cd命令。它学习你最常访问的目录你只需要输入z 部分目录名它就能快速跳转再也不需要输入长路径。bat一个带有语法高亮、Git集成和分页显示的cat命令替代品。查看代码或日志文件时体验提升巨大。lazygit一个终端内的Git图形化客户端。当Git操作变得复杂如交互式变基、解决合并冲突、查看提交图谱时它提供了一个非常直观的TUI界面比纯命令行更友好又比打开大型GUI工具更快捷。httpie/curl对于在终端里快速测试一个API端点httpie的语法比curl更直观易读。例如http POST https://api.example.com/item name”Foo”。我会根据心情和命令复杂度交替使用两者。这些工具的共同点是UNIX哲学的单功能、可组合、通过管道或配置与其他工具协作。它们像乐高积木让我的命令行环境变得无比强大和个性化。8. 工具集维护与迭代的心得构建和维护这样一个工具集不是一劳永逸的。以下是我的一些持续维护心得配置即代码一切版本化我的~/.config、~/.zshrc、~/.gitconfig、 各种工具的配置文件如VS Code的settings.json、 WezTerm的wezterm.lua全部放在一个私有的Git仓库里。换新机器时一个git clone和几个符号链接就能恢复80%的开发环境。这是最重要的“瞎搞”基础设施。定期审视与断舍离每半年左右我会回顾一下我的工具集。哪些工具很久没用了哪些工具出现了更好的替代品果断卸载或替换。工具的“熵增”会拖慢系统并增加认知负担。拥抱自动化用脚本解决重复性配置。例如我写了一个Shell脚本dev-env-setup在新系统上可以一键安装Homebrew/apt、克隆配置仓库、安装我清单里的所有命令行工具和应用程序。不盲目追新但保持关注我不会因为一个工具火了就去用但我会保持关注技术社区。当现有工具确实出现痛点如Bruno解决API测试数据归属问题而新工具能完美解决时就是切换的时机。接受不完美没有工具是完美的。VS Code有时有点慢Neovim配置折腾起来费时间Bruno的生态不如Postman。关键是在核心需求上它是否为你提供了不可替代的价值。接受工具的缺点就像接受队友的缺点一样聚焦于如何协作产出最大价值。折腾工具集的过程本质上是一个不断认识自己工作习惯、优化工作流、追求心流状态的过程。它没有终点但每一次优化带来的顺畅感都是对开发者最好的奖赏。我的这套“瞎搞”方案未必适合你但我希望其中关于“选择背后的思考”、“效率与控制的平衡”、“工具服务于人”的理念能对你构建自己的“数字木工坊”有所启发。记住最好的工具集是那个让你忘记工具本身、沉浸于创造之中的那一套。