加班内卷的IT行业，我选择躺平：一位技术负责人的自白

引言：从“拼命三郎”到“躺平达人”

2017年刚入行的时候，我也曾是个热血青年。那时的我信奉“996是福报”，觉得加班加点赶项目是一个工程师应有的担当。可随着工作的深入、团队的扩大和项目的复杂化，我逐渐发现：盲目地拼时间，并不能解决真正的问题。

这篇文章，我想从自己的亲身经历出发，谈谈我在面对“加班内卷”的时候如何重新思考工作方式，最终选择了一条不一样的路 —— 躺平。但请别误会，“躺平”不是摆烂，而是更聪明地努力、更理性地生活。

问题描述：当“高效”变成“低效内卷”

1. 那个让人心累的项目

大概是在2021年中，我们接到了一个非常关键的客户项目 —— 为一家大型连锁零售企业搭建一套会员运营平台。项目需求看似清晰：用户注册、积分体系、优惠券系统、数据报表……但从一开始，气氛就不对劲。

客户给的时间很紧，只有4个月上线，但功能模块多到让人怀疑这是否合理。为了按时交付，我们团队几乎全员开启了“加班模式”。每天晚上九点下班成了标配，周末单休甚至双休变单休。连续几周下来，大家的状态都开始下滑。

2. 看似高效，实则低效

最明显的一次发生在开发“积分兑换商城”功能时。那天晚上我和前端工程师一起改了一个BUG，改来改去还是不行。当时已经快凌晨了，两个人都很疲惫。第二天早上再来看，才发现是一个简单的配置错误。如果当时能好好睡一觉，可能早就解决了。

后来复盘整个项目，我发现：

• 50% 的BUG是因为疲劳导致的逻辑疏漏
• 团队沟通效率大幅下降
• 开发节奏失控，经常出现“救火式开发”

项目虽然最终上线了，但整个过程让我深刻意识到一个问题：我们并不是在高效工作，而是在用时间换质量。这种“加班文化”背后隐藏的是管理失效与流程混乱。

解决方案：转变思维，重构开发流程

1. 为什么选择“躺平”？

“躺平”对我而言，是一种对“过度加班”的否定，是对效率优先的回归。我开始尝试从以下几个方面入手，调整团队的工作模式：

（1）拒绝无意义的加班

我们设立了一个新的制度：非紧急情况，禁止超过晚上9点离开办公室；周末必须有一整天休息。起初大家都不太习惯，总觉得“不加班完不成任务”。但经过一段时间后，反而发现白天工作效率提升了不少。

（2）优化协作流程

过去我们采用的是瀑布式开发，每个阶段划分得很清楚，但响应速度慢、反馈周期长。后来我们决定引入 敏捷+小步迭代 的方式：

• 每两周一个版本迭代
• 每天站会不超过10分钟，只讲关键进展与卡点
• 每个任务分配明确，谁做？何时交付？标准是什么？

这一改变极大提高了团队透明度和执行效率。

（3）引入自动化工具链

我们开始使用 GitHub Actions 来做 CI/CD，每次提交代码都会自动进行代码扫描、测试和部署预发布环境。之前测试人员手动测试要一天才能完成的版本验证，现在不到两小时就能搞定。

我们在项目中还加入了 Linter 工具（如 ESLint + Prettier），强制规范代码格式，减少了大量 review 时间。

2. 技术选型的权衡

在这个项目中，我们面临一个关键技术决策：是继续使用老项目遗留下来的 Ruby on Rails 后端，还是迁移到 Node.js？

从经验来看，Rails 虽然成熟稳定，但在并发处理能力和生态更新上明显不如 Node.js。尤其对于我们这样一个需要快速响应业务变化的小团队来说，Node.js 显得更加轻量且灵活。

我们做了如下对比：

维度	Ruby on Rails	Node.js
上手难度	高	中
并发能力	较低	高
社区活跃度	稳定但增长缓慢	快速发展
技术栈一致性	更适合传统MVC架构	更适合微服务、API优先

最后我们选择了基于 Node.js 构建微服务架构，并配合 MongoDB 做数据层支撑。虽然初期迁移成本不小，但从长远来看，这种架构更容易维护和扩展。

3. 实践中的一个小插曲

有一次上线前夜，我们的支付回调接口突然频繁超时。排查了一圈日志也没发现问题，眼看临近发布时间，大家都紧张得不行。

后来我灵机一动，在测试环境中模拟了一下高并发请求，结果发现是数据库连接池太小，默认设置的 pool size 是 5，而实际同时访问数达到了 30 多。简单调大参数后问题就解决了。

这件事让我意识到：很多时候问题并不复杂，关键是找到合适的排查方法和工具。

效果总结：质量提升了，人也轻松了

项目正式上线两个月后，我们做了一次回溯评估：

• BUG率下降了约40%
• 客户投诉减少
• 团队整体离职率降低
• 新员工上手更快（因为文档齐全、流程清晰）

最重要的是，大家终于不用再熬夜赶工了。有同事笑着说：“我现在每天下班能赶上末班车了，终于有时间健身了。”

经验分享：我的“躺平哲学”

1. 不追求“表面上的努力”，要追求“实质上的产出”

很多公司都喜欢看“出勤率”，却忽略了真正的效率。如果你能在八小时内高质量完成任务，为什么要熬到深夜？不要用感动自己来代替结果导向。

2. 学会拒绝不合理的需求

作为技术负责人，我们要勇敢对产品说“No”。有时产品想要的功能并不合理，或是实现成本过高，这个时候我们就需要站在全局角度权衡利弊。

举个例子：曾经有次产品经理要求我们在一周内加入一个AI推荐算法，但实际上这个算法不仅没有现成数据支持，还要改动整个用户行为收集逻辑。我们最终说服他先做基础埋点，后面逐步迭代。既保证了进度，又不会把团队压垮。

3. 建立良好的工程文化

• 代码要有注释
• 提交信息要规范
• 接口要有文档
• 测试覆盖率不能低于80%

这些看似“浪费时间”的小事，其实正是长期稳定的基石。

4. 让自动化成为你的左膀右臂

现在我们项目里大部分构建、部署、监控都已经实现了自动化，甚至连接口文档也能通过代码自动生成（比如 Swagger 或 Postman 的集成）。这节省了大量人力成本，也减少了人为失误。

5. 给年轻人一点空间，也给自己一点耐心

我一直鼓励年轻工程师多提意见、多试错。有时候他们提的方案不够成熟，但我并不会直接否掉，而是带着他们一起分析优劣，共同寻找更好的解法。

这样的氛围不仅能培养人，也能让大家更有归属感。

结语：躺平不是放弃，而是更好地坚持

写到这里，我想起一句话：“走得远的，不是跑得快的，而是能持续走下去的。”
在这个“卷”字当头的时代，我们每个人都容易迷失方向。而我想做的，就是在这股洪流中，选择一条更适合自己的路。

我不是反对努力，而是反对无效的拼搏。
我不是不讲责任，而是不想让责任变成负担。
我不是不求进步，而是希望用更健康的方式前行。

如果你也在加班文化的泥潭中挣扎，请相信：总有一种方式可以让你既做好事，又活得轻松。
愿你也能找到属于自己的“躺平之道”。

---

作者简介：
某头部互联网公司技术总监，十年全栈工程师出身，主导过多个大型系统重构与创新项目，坚信技术应服务于人而非奴役于人。