我的 2026 开发工作流

上一次写工具类的文章还是 2023 年那篇 Mac 软件推荐。三年过去，列表里一半的软件已经不用了，工作流的变化比我预期的大得多——主要是 AI 工具进来之后，很多原来的「效率神器」变得没什么存在感了。趁春节后整理 dotfiles，记录一版现在的状态。

先说结论：我现在的工作流大概是「终端 + 编辑器 + 两个 AI 入口」，软件数量比三年前少了一半。

终端还是大本营

终端用 Ghostty，从 iTerm2 迁过来一年多了。说实话迁移的理由不充分，就是馋它的渲染速度，迁完之后也没觉得生产力有什么变化，但用着舒服。配置就二十来行，这点比 iTerm2 那个设置面板强。

shell 是 zsh + 一套用了快十年、缝缝补补的配置。几个真正高频的东西：

# fzf 接管历史搜索和文件跳转，每天按几百次
# zoxide 替代 cd，z proj 直接跳，肌肉记忆已经离不开
# direnv 进目录自动加载环境变量，多项目切换的救命稻草
eval "$(zoxide init zsh)"
eval "$(direnv hook zsh)"
source <(fzf --zsh)

项目级的任务统一用 justfile，把「这个项目怎么跑、怎么测、怎么发」固化下来。这个习惯在 AI 时代意外地增值了——Agent 进到项目里，看一眼 justfile 就知道怎么构建和跑测试，不用我在提示词里解释：

# justfile —— 同时给人和 Agent 看
test:
    go test -race ./...

lint:
    golangci-lint run --timeout 5m

dev:
    docker compose up -d db redis && air

编辑器：分裂的一年

这块最不稳定。Cursor 用了一年半，去年下半年开始一部分工作迁回了「Neovim + 终端里的 Agent CLI」的组合。现在的分裂状态是：大块的功能开发和重构，在终端里直接派给 Agent，我盯产出；小修小补和需要「手感」的代码（性能敏感的热路径、棘手的并发逻辑），Neovim 手写。

说不上哪种是终态。观察下来规律是：我对代码的「掌控欲」和任务的风险成正比。风险低的代码我越来越不在乎是谁写的，风险高的代码我必须一行行过手——哪怕 AI 写得比我好。这可能不是理性分工，是心理需求，但工作流要顺应心理，拧着来坚持不下去。

编辑器内的 AI 补全反而关掉了。单行补全的打断感越来越明显，思路总被半截的建议带偏。要么整块委托，要么完全手写，中间态对我来说最难受。这个可能因人而异。

两个 AI 入口的分工

桌面端的 Chat 入口：查资料、讨论方案、读论文、写文档。特点是「我主导节奏，它提供信息」。

终端里的 Agent CLI：派任务。特点是「它干活，我验收」。

听起来是废话，但分工不清的时候真的很低效。早期我习惯什么都丢给 Chat,贴代码、贴报错，来回拷贝，又慢又丢上下文。后来强制自己：凡是涉及「改动这个仓库」的事，一律走 Agent，让它自己读文件;凡是「我需要弄懂一件事」，走 Chat。两边都顺了。

还有个小习惯，每个项目根目录放一个 AGENTS.md（有的工具认 CLAUDE.md，内容同步），写清楚项目约定、测试怎么跑、哪些目录不要碰。这个文件的回报率是所有配置里最高的，没有之一。内容其实就是以前给新同事写的 onboarding 文档，稍微压缩了一下——给 AI 的文档和给人的文档正在变成同一份东西，这件事想想还挺有意思的。

几个自己写的小脚本

零零碎碎写过不少，活下来的就三个。

wip：把当前改动打包成一个带上下文的描述（diff + 相关文件清单 + 最近的 commit），方便随时丢给 Agent 接着干。本质上是给 AI 的「交接文档」生成器，几十行 shell。

prr：拉一个 PR 的 diff 和评论到本地，喂给 Agent 做预审，把它的意见整理成草稿，我过一遍再提交。注意是草稿——直接让 AI 在 PR 上发评论这事我试过一个月，撤了，噪音太大惹人烦。

logq：包了一层日志平台的 API,支持用自然语言描述要查什么，转成查询语句。这个最常用，因为我到现在也记不住那个平台的查询语法，每次都现查文档，干脆不记了。

笔记和知识管理：放弃治疗后反而好了

笔记软件我换过的数量大概两位数，Notion、Obsidian、Logseq 都认真用过一年以上，每次都以「重新设计一遍标签体系然后吃灰」告终。

去年彻底放弃了体系化这件事，退化成两个东西：一个仓库装 Markdown 文件，按年份分目录，文件名就是主题，写完不整理；查的时候不靠目录靠搜索——以前是 ripgrep，现在是直接问 AI，让它在仓库里找相关的几篇并把结论拼出来。

讽刺的是，放弃整理之后笔记的实际利用率反而上去了。以前「这条笔记该放哪个分类」的纠结会让我少记很多东西，现在无脑往里扔，反正检索是 AI 的事。知识管理的瓶颈从来不在存，在取——取的问题被解决之后，存的规矩越少越好。这个变化我花了十年才接受，主要是心理上的：承认自己维护不了一个花园，只能维护一个堆。

博客反而成了我唯一还在「精写」的输出。区别在于读者：笔记是给未来的自己和 AI 看的，越快越好；博客是给别人看的，值得花时间。两边的标准分开之后，两边都轻松了。

不用了的东西

对照 2023 年那篇，被淘汰的：剪贴板历史工具（系统自带的够用了）、窗口管理器（外接一块竖屏后需求消失了）、各种 Markdown 编辑器（全部回到编辑器+预览）、番茄钟（试了十年，承认失败，我就不是这个节奏的人）。

还有 Stack Overflow,不是刻意不用，是有一天突然意识到已经半年没打开过了。有点感慨，那个绿色对勾陪了我整个职业生涯的前半段。

还没解决的问题

也列一下没顺的地方，免得这篇显得太岁月静好。

多 Agent 任务的「精神负担」问题：同时跑三个以上 Agent 的时候，虽然手上不忙了，脑子里要维护每个任务的状态，下班的时候比纯手写代码的日子更累。这个不知道是工具问题还是我的问题，目前无解,只能控制并发数。

AI 产出的代码风格漂移：同一个仓库，不同时期派的任务，生成的代码风格肉眼可见地不一致——错误处理的方式、日志的详略、注释的密度。AGENTS.md 里写了规范，遵守率大概八成，剩下两成靠 review 兜底。比人类同事好管，但没有想象中省心。

碎片时间的利用反而变差了：以前通勤路上刷技术文章，现在习惯了「有问题直接问」，输入变得越来越按需，广撒网式的阅读少了。短期没感觉，长期我怀疑会让「不知道自己不知道」的盲区变大。今年试着恢复每周固定的泛读时间，效果待观察。

写在最后

工具文章有个通病，写的人兴致勃勃，看的人抄完用三天就放弃。所以这篇尽量只写了「为什么这么分工」而不是「装这二十个软件」。工作流这个东西，内核其实就一句：高频动作的摩擦力降到最低，低频动作不要花心思优化。剩下的都是个人口味。

dotfiles 在 GitHub 上,感兴趣的可以翻，不过里面注释是写给我自己的，凑合看。