过去三周，我陷入了一种很奇怪的忙：每天从早九点坐到晚十点，编辑器开了几十个文件，git 提交也像模像样，但一到周五晚上复盘，却说不出这周到底“完成”了什么。后来我意识到，这种状态本身就是最大的效率问题——我不是在写代码，而是在跟环境、跟上下文、跟自己的反复纠结搏斗。于是我做了一次相对系统的复盘，把开发效率拆成可以统计的东西，一点一点找原因。这篇文章不是方法论总结，就是一次真实的周复盘记录：这三周我砍了哪些低效动作、换了哪些工作方式、哪些网上流行的效率技巧在我的场景下根本不好使，以及最后留下的几条真正能复用的东西。
1. 复盘先给“效率”定标准：过去三周我是怎么记录有效产出的
1.1 为什么突然想复盘
写代码这么多年，我一直靠感觉判断“今天效率不错”。直到三周前，一个本应两天搞定的需求被我拖到了第五天，才逼着我承认：感觉是会骗人的。那天晚上我把最近两周的 git 记录翻了一遍，发现大部分 commit 都是“fix”“wip”“临时提交”，真正能对应到需求点的不到三分之一。也就是说，我忙了十四天，真正对业务有价值的工作可能只有四天。
所以这次复盘做的第一件事，就是给效率定一个可统计的标准。我没有用什么 fancy 的工时系统，而是每天下班前花五分钟记三个数字：完成了几个功能点、修复了几个 bug、写了多少“不需要返工”的代码。每个功能点我要求自己必须能对应到一次版本发布或一次合入主干的 MR。换句话说，没合入、没经过验证的代码，一律不算产出。
这一条原则很重要。以前我很容易自我感动，觉得“我今天写了三百行代码，效率真高”，结果那三百行里有两百行都是推翻重来的探索性代码。按现在的口径，探索性代码可以写，但它属于学习成本和技术债，不应该计入“有效产出”。
1.2 三周的变化数据：先看结果再找原因
记录之后，数据长这样：
| 周次 | 完成需求点 | 修复线上 bug | 合入 MR 数 | 返工次数 | 估算每日有效时长 |
|---|---|---|---|---|---|
| 第一周 | 2 | 4 | 5 | 5次 | 约3.2小时 |
| 第二周 | 4 | 3 | 8 | 2次 | 约4.5小时 |
| 第三周 | 5 | 2 | 10 | 1次 | 约5.8小时 |
第一周的数据基本暴露了我的老问题：两天甚至三天才完成一个需求点，五次返工里有三次是因为需求边界没想清楚就动手，两次是因为改了 A 模块顺手把 B 模块的逻辑弄坏了。第二周开始有意识调整，但数据仍然不漂亮。到第三周，日均有效产出基本翻了一倍，返工次数降到了一周一次。
第三周我还单独记录了一项“间接产出”：搭建了一套接口 mock 工具，并给项目补了自动化回归脚本。这类工作很难直接计入需求点，但对后续开发效率的影响很关键。复盘的时候我单独给它一个标记，不混进需求统计里，否则数据会失真。
1.3 记录行为本身就在改变行为
你可能觉得这套记录麻烦，但我实测下来，它最大的价值不是数据有多准确，而是让你在做每个动作之前多停顿一秒。比如下午三点原本想顺手改一个无关紧要的样式，一想到“这不算需求点，也不修 bug，今天又没产出了”，我多半会收手。这其实就是一种行为矫正，跟健身时拿手机记每组动作是一个道理。
我用的模板很简单，Markdown 里放一个表格，每周一个文件：
## 第X周产出记录 | 日期 | 需求点 | 修复bug | 返工原因 | 今日备注 | |------|--------|--------|---------|---------| | 周一 | 用户列表筛选 | | 未对齐筛选条件，返工一次 | 前置设计缺失 | | 周二 | | 登录态失效 | | 环境问题耗时1h |不需要专门去买什么效率软件，一个 note 文件足够了。真正有用的不是工具，是“你决定记”的那一瞬间。
2. 三个被我堵上的时间漏洞：等待、切换、手工试错
2.1 把“等一下”变成“零等待”：本地环境和热更新的优化
第一周记录里，最让我意外的是“等待时间”的占比。项目的本地环境一直靠手动起服务，前端、后端、数据库三条链路，每次启动都要按顺序敲命令，敲错一个就得重来。更难受的是改完前端代码后，热更新经常要两三秒才生效，改一个样式要来回刷新好几次，一天的碎片时间就这么耗没了。
第二周我花了一个下午把这事彻底收拾了一下。后端、数据库写进 docker compose，前端单独跑，用一份脚本一键拉起。脚本本身不复杂：
#!/bin/bash # 一键启动开发环境 echo "Starting mysql..." docker compose up -d mysql echo "Starting backend (port 8080)..." cd backend && mvn spring-boot:run > backend.log 2>&1 & echo "Starting frontend (port 5173)..." cd frontend && pnpm dev踩了一个小坑：启动顺序不能乱，数据库必须先于后端就绪，否则后端起不来。日志重定向也很有用，以前后端报错会直接刷到终端里，跟前端日志混成一团，现在分开写文件，排查起来清爽很多。
前端热更新慢的问题，根因是某个依赖监听了大量文件，Vite 默认的 watch 策略容易被拖垮。我在配置里做了针对性调整，把不必要的目录排除掉，热更新时间从两秒多降到了五百毫秒左右。这个优化每天帮我省下十几二十分钟，而且省下的是碎片化等待，心情上的收益比时间上的收益更大。
2.2 上下文切换是最隐蔽的黑洞：从“多线程”改成“批量回合”
回看第一周的数据时，我还发现一个特别讽刺的现象：我同时并行三个需求，最后三个都没在计划时间内完成。原因不难理解，我每天的工作状态是“需求A写十分钟，回个消息，切到需求B看两眼，再切回需求A还得重新回忆刚才的思路”。每一次切换，大脑都需要重新加载上下文，这个加载时间保守估计要十分钟以上，而且加载完后思路经常接不上。
后来我把工作节奏改成了“批量回合制”：一天被切成上午、下午两个大块，每块只做一条主线任务；中间穿插的碎片时间统一用来处理回消息、看 MR、顺带改小 bug。跟纯番茄钟不一样的是，我不强制每 25 分钟响一次铃，而是给自己设了一个“切换闸门”——任务没做到一个阶段（比如某个函数写完并且能跑通）之前，不允许切走。
这套做法执行了大概一周，明显感觉到脑子里的“缓冲栈”变小了。以前是同时压着四五个任务的半成品状态，现在一次只压一个。CPU 占用率低了，出错率自然也就下来了。
2.3 手工试错交给脚本：接口 mock 与回归验证
做后端开发的老哥应该都有过这种经历：前端同事跑过来问“后端接口好了没”，你说“还在调”，然后两边一起卡住。第一周里我发现自己至少有两天是在等联调环境，或者在前端还没接好的情况下反复用 Postman 手工测接口。
第三周我给前后端之间加了一层接口 mock。做法很朴素：后端先定义好接口文档和字段格式，前端用 mock 数据把页面流程先跑通；后端开发同时对接真实数据库，两边不再互相等。我挑的例子是列表页的筛选接口，mock 配置大概长这样：
// vite mock 插件示例 export default { 'GET /api/admin/users': ({ query }) => { const { status } = query const allUsers = [ { id: 1, name: '张三', status: 'active' }, { id: 2, name: '李四', status: 'disabled' } ] return { code: 0, data: status ? allUsers.filter(u => u.status === status) : allUsers } } }这套东西带来的效率提升，不是让你敲键盘更快，而是把“人和人之间的串行等待”变成了“人和系统的并行开发”。配合一份简单的回归脚本，接口一旦变更，能立刻发现前端调用处的错误，不用再靠肉眼和手工点来点去。
3. 变化最大的根源：我把“边写边想”改成了“先想后写”
3.1 15 分钟的前置设计，换来一整天的顺畅
第二周开始前，我做了一个自己都觉得有点“反直觉”的决定：所有需求，不管大小，动手前必须先写一份“最小设计笔记”。不是正式设计文档，就是三五条要点，写清楚输入是什么、输出是什么、数据从哪来、异常情况怎么处理、验收标准靠什么。
第一周我有一个典型的反面案例：做一个 Excel 导出功能，我拿到需求就开始写代码，写到一半发现“大数据量导出时内存会不会爆”没想清楚，推翻重写了一轮。第二周再接类似需求时，我强迫自己先写设计笔记，结果在开发前就发现了三个边界问题：数据量大时必须分批写入、导出权限要按角色过滤、列顺序明明有现成的配置项但我一直不知道。
15 分钟的前置思考，换来的是一整天不返工。这笔账怎么算都划算。我常用的模板很简单：
## 需求：xxx - 输入：xxx - 输出：xxx - 数据来源：xxx - 异常情况：xxx - 验收标准：xxx - 顺带会改动到的代码模块：xxx最后一条“顺带会改动到的代码模块”尤其关键。很多返工不是因为核心逻辑不会写，而是因为改了一个地方，忘了另一个地方的依赖关系。
3.2 小步提交：把一天拆成 40 分钟的小循环
以前我的提交习惯是写一大段代码再统一 commit，经常出现一个 commit 里塞了半个需求的改动。出问题时想回滚，都不知道该滚到哪。第二周开始，我把节奏改成“每个可运行状态都提交一次”，哪怕中间状态还很粗糙，但保证代码能通过编译、页面能正常打开。
为了降低提交成本，我加了几个 git alias：
git config --global alias.cm 'commit -m' git config --global alias.st 'status -s' git config --global alias.lg "log --oneline --graph --all -15"真正的变化不只是提交频率。每次提交前，我会过一遍自查清单：这段代码里有没有遗留的调试输出？有没有跟本次任务无关的改动？测试能不能跑通？这个习惯逼着我不再把“顺手改点东西”混进主流程，每个 commit 的边界都变得非常清晰。回滚、找问题、review 都轻松不少。
3.3 验收标准前置：不再用“感觉”判断做完了
跟产品、测试对需求的沟通过程，以前也会消耗不少时间。我习惯直接问“这个功能大概怎么做”，大家嘴上说清楚了，但写出来的验收标准往往是“功能正常、界面美观”这种没法判定的废话。
第二周我换了一种问法：先确认“怎么算完成”。比如需求是“列表页增加筛选”，我就把验收一句话描述出来——选择状态等于已通过时，列表只显示已通过记录，且 URL 上的查询参数可以被分享和还原。这个标准写清楚之后，我写代码时会很自然地知道哪些分支要覆盖，不用写完之后再猜测。
这个变化直接反映在返工次数的数据上：第一周返工五次，第二周两次，第三周一次。五次里有三次都是验收标准模糊导致的。如果你发现自己经常补逻辑改判断条件，大概率是前置验收标准没写利索。
4. 手速不是瓶颈：真正提升的是决策速度
4.1 写代码时，决策次数才是上限
很多人一谈开发效率就想到打字速度、工具链、IDE 快捷键，但我的实际体感是：大部分时间花在“决定怎么写”而不是“写”上。变量叫什么、这个函数要不要抽出来、接口参数用对象还是单个传、这层判断放在前端还是后端……每一个都是一次决策，每一次决策都需要消耗认知资源。
举一个很生活化的例子：开车的时候，决定你到目的地快不快的不是踩油门的力度，而是你提前多久判断路况、什么时候变道。写代码也一样，手速只是油门，决策路径才是路线。第三周我统计数据时发现，我每天的代码行数并没有明显增加，但返工次数大幅下降，就是因为决策质量上来了。
4.2 模板、规范、清单：把决策提前做掉
减少决策最有效的办法，是让一部分决策根本不需要发生。过去我建一个新页面，要现场想文件夹结构、命名、组件划分；后端写一个新接口，要现场想路径、参数、错误码格式。这些事每次想一遍，看着不起眼，日积月累就是很大的损耗。
三周里我给自己定了三条硬规则：
- 前端新增业务页面，一律按统一目录模板生成，模块划分、样式文件命名固定下来；
- 后端接口路径统一以
/api/admin/开头，列表接口统一分页结构，错误码统一从常量表里取； - 所有异常处理走统一入口，不在业务代码里到处 catch 后乱返回。
规则定了之后，大部分新需求的开发变成“套模板往里填业务逻辑”，不需要每次现想现摸着过河。这里的提升不是工具层面的，而是把高频、低价值的决策转移到了规范和模板里。
4.3 拒绝“顺手优化”：一次只允许一个非计划内动作
我过去效率低的另一个原因，是太容易“顺手”做计划外的事。写着需求 A，看到一处旧代码很丑，顺手重构；改着 B 模块，发现 C 模块有个明显 bug，顺手修了。结果就是 A 被晾在一边，等我回来时已经忘了一半思路，还要花时间重新读代码。
第二周我给自己立了一条规矩：顺手发现的问题一律记进“技术债便签”，不在主线任务里处理。便签本身就是一个 Markdown 文件，按模块分类记录，等到专门的技术任务时段再去集中消耗。执行效果很直接：第三周我的主线任务中断次数大幅减少，每个需求点的完成时间都变得更稳定。
这里想特别强调一个感受：拒绝“顺手优化”不是冷漠，而是对自己注意力的保护。真正重要的需求不该被突如其来的“好人好事”打断。技术债值得还，但要在一个可控的窗口期里还。
5. 试错记录：几个流行效率方法在我这里的失效分析
5.1 番茄钟：为什么我只坚持了两天
网上很多人推荐番茄工作法，我也试过，但很快就放弃了。原因很真实：写代码进入心流状态通常需要十到十五分钟，而番茄钟每到 25 分钟就强制响铃，等于专门挑你最专注的时候打断你。打断之后重新进入状态又要十分钟，一来一回，我的产出反而比不用番茄钟更低。
后来我做了个改良：只用第一个番茄钟作为“入场仪式”，帮自己启动任务。启动之后铃一关，让它自然滚动。这样一来，既保留了“开始前排除干扰”的好处，又去掉了“强制打断”的副作用。如果你试过番茄钟觉得难受，大概率不是你的问题，是响铃机制对深度工作不友好。
5.2 多标签页多任务：看起来很忙，产出很低
我还复盘了一个很常见的行为：浏览器里开着几十个标签页，同时铺开需求 A、需求 B、需求 C 的代码，随时来回切换。表面上很忙，但每个任务都只前进了 10%。因为每次切回一个任务，都要花时间回忆这个任务的当前状态和下一步计划。
第三周我换了一种做法：桌上只放一张“当前任务卡”，卡片上写着本阶段唯一在做的事；代码分支只开当前任务相关的一个；浏览器标签页也只留跟当前任务相关的两三页。其余任务统一放到下午的固定时间再拾起来。这个变化让我的“心理切换成本”降到接近于零，每个任务都更容易推进到完成态。
5.3 从“要更快”转向“要更少返工”：反向清单
复盘的过程中，我整理了一份“反向清单”，写的是三周里证明不该做的事：
- 不在周五下午动核心模块，因为临近收尾时人的注意力最容易涣散，改出问题没时间收拾；
- 不在没写验收标准之前动手写业务代码，这是返工的最大来源；
- 不在临下班前开新分支、做新方案，大脑过一晚就会遗忘刚才的思路，第二天又得重新读代码。
“反向清单”听上去很消极，但非常有效。很多时候效率问题不是因为你不知道做什么，而是因为你忍不住去做那些高风险、低收益的动作。把“不要做”的东西列出来，比列“要做”的东西更能稳住基本盘。
6. 下一轮实验：把提升固化成默认习惯
6.1 过去三周的提升点，哪些能继续保留
复盘的价值在于沉淀，而不是总结完就忘。我梳理了三周后确定要长期保留的三件事：
第一，动手之前写五行的设计笔记。以后凡是新建分支，先写下这个分支要解决的问题、边界和验收标准。写不满五行说明需求压根没想明白，这时候不应该动手。
第二，进入新项目的头一天就配好一键启动脚本和 mock 方案。以前总觉得这些事情“等有空再说”，但正是这些“等有空”的事，日后每天在零敲碎打地吃你的时间。
第三，技术债便签跟周报工具合并。发现问题顺手记，周五统一看一次，安排专门的时间集中消化，不让技术债变成主线任务的噪音。
6.2 下三周准备验证的三件事
保持记录这套机制，我还会继续跑下去。下一轮想验证三个更进一步的假设：
- 上午 9:30 到 11:30 这段最清醒的时间，完全留给最难的需求，看每个需求点的平均完成时间能不能再压缩两到三成；
- 在核心模块上尝试“测试先行”，写代码前先写好最小单测和回归样例，不求全面 TDD，只求关键路径不再因为改动被悄悄破坏；
- 把即时通讯工具的回复频率降低，集中在每天下午固定时间段批量处理，看会不会真的导致协作卡顿。
这些都是小规模实验，不指望发生奇迹，但可以持续校准我对“开发效率”的判断标准。
最后说一点个人体会吧。过去三周，最大的变化不是我学会了什么炫酷的新工具，而是我开始认真对待“时间去哪了”这件事。效率提升没有银弹，真正值钱的不是某个脚本、某个写法，而是你愿意把忙乱摊开来看、承认哪些动作在消耗你，然后一个一个把它们堵上。复盘这件事，一旦开始记录，就已经赢了。
