过去三周我陷入了一种很奇怪的忙每天从早九点坐到晚十点编辑器开了几十个文件git 提交也像模像样但一到周五晚上复盘却说不出这周到底“完成”了什么。后来我意识到这种状态本身就是最大的效率问题——我不是在写代码而是在跟环境、跟上下文、跟自己的反复纠结搏斗。于是我做了一次相对系统的复盘把开发效率拆成可以统计的东西一点一点找原因。这篇文章不是方法论总结就是一次真实的周复盘记录这三周我砍了哪些低效动作、换了哪些工作方式、哪些网上流行的效率技巧在我的场景下根本不好使以及最后留下的几条真正能复用的东西。1. 复盘先给“效率”定标准过去三周我是怎么记录有效产出的1.1 为什么突然想复盘写代码这么多年我一直靠感觉判断“今天效率不错”。直到三周前一个本应两天搞定的需求被我拖到了第五天才逼着我承认感觉是会骗人的。那天晚上我把最近两周的 git 记录翻了一遍发现大部分 commit 都是“fix”“wip”“临时提交”真正能对应到需求点的不到三分之一。也就是说我忙了十四天真正对业务有价值的工作可能只有四天。所以这次复盘做的第一件事就是给效率定一个可统计的标准。我没有用什么 fancy 的工时系统而是每天下班前花五分钟记三个数字完成了几个功能点、修复了几个 bug、写了多少“不需要返工”的代码。每个功能点我要求自己必须能对应到一次版本发布或一次合入主干的 MR。换句话说没合入、没经过验证的代码一律不算产出。这一条原则很重要。以前我很容易自我感动觉得“我今天写了三百行代码效率真高”结果那三百行里有两百行都是推翻重来的探索性代码。按现在的口径探索性代码可以写但它属于学习成本和技术债不应该计入“有效产出”。1.2 三周的变化数据先看结果再找原因记录之后数据长这样周次完成需求点修复线上 bug合入 MR 数返工次数估算每日有效时长第一周2455次约3.2小时第二周4382次约4.5小时第三周52101次约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 21 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 aliasgit 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只求关键路径不再因为改动被悄悄破坏把即时通讯工具的回复频率降低集中在每天下午固定时间段批量处理看会不会真的导致协作卡顿。这些都是小规模实验不指望发生奇迹但可以持续校准我对“开发效率”的判断标准。最后说一点个人体会吧。过去三周最大的变化不是我学会了什么炫酷的新工具而是我开始认真对待“时间去哪了”这件事。效率提升没有银弹真正值钱的不是某个脚本、某个写法而是你愿意把忙乱摊开来看、承认哪些动作在消耗你然后一个一个把它们堵上。复盘这件事一旦开始记录就已经赢了。