hkelll如果你是一个开发者，下面这个场景大概率不陌生：某个周三的晚上，代码写完了，功能也跑通了，但你坐在椅子上盯着屏幕，胸口说不上来的闷，既不想关电脑，也不想继续干活。或者，打开新需求文档的第一眼，脑海里蹦出来的不是“怎么做”，而是“怎么又要做”。如果你已经连续几周甚至几个月出现这种感觉，那大概率不是懒，也不是矫情，而是职业倦怠找上门了。
我在这行待了十来年，见过太多同行从当初眼睛发光的少年，慢慢变成每天掐着点等下班的疲惫身影。自己也经历过两次比较明显的倦怠期，第一次靠硬扛，结果越扛越重；第二次才开始认真研究“心态”这件事，一点点把状态调回来。这篇文章不是鸡汤，是我自己反复验证过的经验总结。我把它整理成7个心态调整，写给那些开始对写代码提不起劲、早上起床想到要打开编辑器就累、甚至怀疑自己是不是不适合做技术的开发者。看完你不需要立刻给自己打鸡血，只需要先搞清楚一件事：倦怠不是你废了，而是你过去那套工作方式和评价体系，已经撑不住现在的生活了。
1. 先看清敌人：你到底是累了，还是倦怠了
很多人分不清“最近有点累”和“职业倦怠”的区别，结果要么硬扛到崩溃，要么就急着辞职换工作。想调整心态，第一步不是急着改，而是先给当前的状态做个判断。
1.1 职业倦怠的三个核心信号
心理学上给职业倦怠画了三个典型特征，我自己对照过，非常准。
第一是情绪耗竭，翻译成人话就是“心累”。身体其实休息够了，但一想到工作，整个人就像被抽干了一样。我以前有个阶段，每天下班回家什么也不想干，连游戏都懒得打开，躺在床上刷手机都能刷出上班的感觉。
第二是去人格化，说白了就是“变冷漠了”。以前同事找你帮忙，你会很热心；后来你会觉得“这又关我什么事”。需求方换个说法你忍不住心里翻白眼，用户报个bug你也觉得他们在无理取闹。这其实不是人品变差了，是大脑在自我保护，用“不在乎”来减少消耗。
第三是低成就感。这是最隐蔽的坑。你明明每天在写代码、修bug、发版本，但就是觉得自己做的全是垃圾，没意义，领导看不到，用户也不在乎。哪怕项目上线了，内心也没有波动，只觉得“哦，终于结束了”。
这三个信号不需要全中，只要有两条持续超过一个月，基本就可以判断进入倦怠状态了。
1.2 为什么开发者这个群体特别容易中招
说实话，职业倦怠哪个行业都有，但开发者群体的发病率和隐蔽性尤其高。
原因也很清楚。第一，我们做的是高强度的认知劳动，写代码需要同时处理逻辑、边界、依赖、隐患，这种“持续用脑”本来就比体力活更耗人。第二，开发工作的反馈周期太长，经常是写了一两个月的模块，上线后还要观察一段时间才知道有没有用，不像销售签一单就成一单，成就感来得很直接。第三，技术更新太快，今天还在学这个框架，明天新版本又出来了，这种永不停歇的追赶本身就制造焦虑。
还有一点是团队协作的碎片化。你以为开发的核心是写代码，实际上每天大半时间花在开会、回消息、看文档、对齐需求上。一天下来，代码没写几行，精力倒耗尽了大半。这种“忙却无产出”的感觉，对心灵损耗比加班还要大。
所以看到这里，如果你发现自己中了好几条，别慌，也别觉得自己脆弱。这不是你的问题，是开发者这个职业天然就有通往倦怠的斜坡。接下来要聊的7个心态调整，就是教你怎么在这个斜坡上踩住刹车。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 心态调整之一：重新定义“完成”和“成就”
这一条是所有调整里我最先做的，也是见效最快的一条。开发者之所以容易倦怠，很大程度是因为在长期的工作里，我们把“完成任务”和“做出成就”这两件事彻底搞混了。
2.1 从“写完代码”到“解决了问题”
我以前有个特别不好的习惯：每天下班前看自己写了多少行代码、提了几个commit。写得多，就觉得今天没白干；写得少，就开始自责。后来我意识到，这个评价方式大错特错。代码只是手段，解决问题才是目的。
我调整的方法是，每次接到任务先问自己一句话：“这个需求背后，用户或者业务方真正想要的结果是什么？”然后把这句话写在便签上贴到屏幕边。写代码时不看它，但一旦觉得自己在做无意义的重复劳动，就抬头看看那句话。举个例子，我曾经长时间维护一个数据处理的老服务，每天干的活就是从各种乱七八糟的接口里拉数据、清洗、格式化。那段时间我真的觉得这工作毫无价值。但当我换了个视角，意识到自己做的其实是“帮公司几十个人省掉每周手动核对数据的痛苦”，心态立刻就不一样了。
这个调整背后的原理其实很简单：人需要意义感，而意义感来自于“我做的东西对别人有用”。哪怕同样的代码、同样的任务，只要你把关注点从“我在写代码”切换成“我在帮谁解决什么问题”，成就感来源就会完全改变。
2.2 用一张“自建完成清单”把成就感捡回来
除了重新定义完成，我还建议你建立一张自己的完成清单，跟公司考核无关的那种。
具体做法是，准备一个文档，每次做完一件哪怕很小的事，都记一笔。比如“把支付模块的超时重试问题定位到了根因”“把新同事的Git配置问题解决了”“写了一段能自动生成报表的脚本”。就这一两行字，不搞花哨，重点在于：你看到“我做成了一件事”的事实。
有人可能会觉得这很幼稚，但心理学里有个很常见的研究方向：未完成事项对大脑有持续占据效应。你脑子里挂着一堆没干完的事，这个提醒那个催促，精力就在后台不断被消耗。当你把这些事写下来，相当于告诉大脑“这单子我已经记下了”，大脑才愿意放过你。成就清单同理，写下来的那一刻，它就从“流动的焦虑”变成了“被确认的成果”。
这个习惯我坚持了很多年，最大的感受是：人特别容易忘记自己做过什么。如果靠记忆，你只会记得那些失败的、被批评的、没做好的；但当你把“做成的事”一条条摆在那里，你就会发现，原来自己根本没这么差。
3. 心态调整之二：允许平庸，拒绝完美主义
说到倦怠，就绕不开完美主义。我认识的开发者里，十有八九对自己都有点“变态”要求：代码要优雅、结构要清晰、性能要极限、命名要精准。有追求是好事，但过了头，就是给自己上刑。
3.1 承认没有完美的方案，代码能跑就是胜利
我年轻的时候写一个模块，会反复重构，觉得这个设计不够抽象、那个地方复用不够彻底。结果怎么改都不满意，最后项目延期，自己也很崩溃。后来我师父跟我说了一句话，我记到现在：“软件工程不是做艺术品，是在约束条件下做决策。”
什么叫约束条件？有时间约束、成本约束、团队能力约束、历史包袱约束。你永远不可能在一个老系统里写出教科书式的漂亮代码，就像你不可能在预算有限、工期固定的情况下装出样板间的房子。你要做的不是“最好”，而是在当前条件下“够用又不太差”。
这个心态转变之后，我整个人轻松了一大截。写代码的时候不再纠结“能不能更优雅”，而是先问“能不能稳定解决问题”。等业务跑起来了、测试过了、上线没问题了，再考虑要不要优化。先可用，后完美，这个顺序不能反。
我是真心觉得，很多开发者的累，不是活儿太多，而是自己给自己加了一堵“必须完美”的墙。每一行代码都在接受内心的审判，这种审判比任何Code Review都消耗人。
3.2 把批评当成调试信息，而不是人格审判
完美主义还有个孪生兄弟，叫“过度在意批评”。code review被同事指出问题，第一反应不是“哪里要改”，而是“我是不是不行”。需求被产品打了回票，第一反应不是“怎么调整”，而是“他是不是针对我”。
我自己中过这个招。有一次评审的时候，新来的同事连着提了好几个意见，我当时脸上挂着笑，心里已经炸了：我一个写了这么多年的人，要被你一个小年轻教？回家越想越气。后来冷静下来，把批评意见一条条列出来，发现七八成其实说得有道理，确实是我考虑不周。
之后我就练了一个习惯：收到任何批评，先复制到文档里，当场不回复，给自己至少十分钟的缓冲。等情绪过了，再回来看，把里面有价值的部分提取出来，当成“调试信息”。代码报错了，你会怪那个报错信息吗？你不会，你会顺着日志去修。批评也是一样，它是系统输出的日志，告诉你哪里可以改进，跟“你这个人好不好”没有半毛钱关系。
这一条很难，但值得练。练成了，你会发现别人评价对你的杀伤力直接砍半，而你能从批评里拿到的营养反而翻倍。
4. 心态调整之三：夺回节奏，别被需求和会议推着走
职业倦怠还有一个特别隐蔽的来源：失控感。你明明是个技术从业者，却感觉自己像一个皮球，被需求的脚踢来踢去。今天加个功能，明天改个字段，后天开个对齐会，你永远不知道下一个小时要干什么。这种感觉一旦持续，人很快就会从“主动工作”变成“被动消耗”。
4.1 用时间块保护你的深度工作
开发者的核心产出靠的是深度工作，也就是一段连续、不被打断、让你完全沉浸进去的时间。写一个复杂模块，你需要先把整个上下文加载到脑子里，这本身就是一件耗时的事。如果你每隔十五分钟就被拉去开个会、回个消息，你的大脑永远处于“刚加载一半就被清空”的状态，效率低不说，那种“什么也没完成”的挫败感，才是真正要命的。
我的做法是每天固定在某几个时间段给自己划“深度工作块”。比如上午9点半到11点，下午2点到4点，这段时间我会关掉消息提醒，把耳机戴上，在日程上标出“不可打扰”。刚开始团队不习惯，有人找不到你还会意见很大。后来我把“深度工作块”的规则说清楚：紧急事情直接打电话，非紧急事情留言，等我出来统一处理。坚持了一个月，大家也就接受了，反而觉得找我一次能把问题说不透的时间变多了。
别小看这个动作。当你恢复了对自己时间的主导权，你就不再是“被安排的人”，而是“安排自己做事的人”。这个掌控感的回归，对心态的恢复作用远远超过多写几行代码。
4.2 练习“主动关闭”任务的能力
除了保护时间，你还要学会在心理上“关闭”任务。这个能力很多人完全没意识到存在。
我以前有个体验：功能还没上线，我脑子就开始想“上线之后会不会出问题”；功能上线了，我又开始想“下一次迭代要改什么”。每天回到家里，脑子里还在跑生产环境的代码，这就是典型的“任务没关闭”。大脑一直开着后台进程，你以为你在休息，其实没有。
我的解决方法特别土但也特别有效：每天下班前花五分钟，在笔记本上写下“明天还要做的事”。注意是写下来，不是想一想。写下来这个动作，相当于把你的待办从大脑里卸载下来，装进了一个外置硬盘。大脑这时候才会告诉你：好了，今天的任务已经全部交出去了，可以下班了。
还有一招是给自己设定一个“完成仪式”。比如每次提测完，轻声说一句“这单子我可交付了啊”，或者合上电脑前敲两下屏幕。听起来很傻，但仪式感能帮助大脑建立“这件事真的结束了”的信号。我自己靠这个方法，成功把很多“下班后还在想工作”的夜晚抢了回来。
5. 心态调整之四：把评价体系从别人手里拿回来
开发者是社群动物，刷技术社区、逛开源平台、看同行动态，本来就是学习的一部分。但你有没有发现，看得越多，自己越焦虑？别人七天就写了个新框架，别人跳槽年薪翻倍，别人开源项目几百star，你对比一下自己，感觉自己啥也不是。这种“对比式焦虑”，是倦怠的一味毒药。
5.1 对“技术大神”祛魅，你看到的是剪辑过的片段
我以前也特别崇拜那些高产出的技术大佬，总把对方想象成一天二十四小时都在写代码、每段代码都完美无瑕的神人。直到我自己也开始写一些技术文章、维护开源项目、偶尔做分享之后，我才明白一件事：你在外面看到的任何一个人，都是他“被剪辑过的高光版本”。
他不会把自己改了三天的bug贴出来，不会告诉你他在项目里的历史遗留代码有多烂，更不会说他自己也有对着需求文档发呆的夜晚。你看到的几百个star背后，可能是他连续几个月周末都在熬夜。你看到的“三天写完新框架”，可能是建立在过去几年大量积累之上的结果。
想到这一层，“差距焦虑”就能缓解不少。你不必用别人的高光时刻来审判自己的幕后日常。你唯一需要比对的，是昨天的自己，而不是视频里那个把自己包装得很完美的同行。
5.2 给自己画一张多维价值雷达图
很多开发者的自我评价特别单一：技术强不强、代码写得好不好、工资高不高。一旦这几个指标不满意，就觉得自己整个人都不行。这就是评价体系太单薄了。
我建议你做一件事：拿出纸笔画个雷达图，列出你觉得对工作至关重要的维度，比如技术能力、业务理解、沟通协作、文档表达、推动落地、帮助他人成长、情绪稳定、责任意识。然后挨个给自己打分。你会发现，技术能力可能只有6分，但推动落地8分，帮助同伴9分。这说明你这个人价值并不低，只是从前你把所有目光都放在自己最弱的那一栏上。
我这么一提，是在提醒自己别忘了：软件开发从来不是单打独斗。一个团队里，能写出漂亮代码的人很重要，能把复杂事情讲清楚的人、能稳定推进项目的人、能让团队氛围变好的人，同样重要。你不是只会写代码的机器，你的价值体系越多元，你就越不容易被某一个领域的滑坡击溃。
6. 心态调整之五：让学习重新变回自己的事
任何聊开发者倦怠的话题，都不可能不提“学习焦虑”。技术圈永远不缺新名词，每个月都有新框架、新工具、新理念。你不学吧，怕自己淘汰；学吧，白天上班那么累，晚上还要逼自己刷课，越学越累，越累越焦虑，形成恶性循环。
6.1 按需学习，别再为焦虑“打卡式”刷课
我有一段时间特别着迷于“跟上热点”，今天看推荐说是微服务，明天看怎么说AI开发，买了好多课程、收藏了几百篇文章，周末不是在听课就是在看讲义。结果怎么样？两个月后我再回头，那些东西几乎全忘了，唯一记住的只有“自己又好落后”的焦虑感。
后来我想明白一个道理：没有落地场景的学习，只是一场自我安慰。真正有效的学习是“带着问题学”。比如你手头遇到一个性能瓶颈，你带着这个具体问题去查资料，学到的解决方案不仅能立刻用上，还能因为你理解了问题的背景而记得特别牢。这种“按需学习”，效率不知道比“为了焦虑而学”高多少。
所以我现在给自己定了规矩：不因为“听说很火”而学，只因为“我眼下遇到了什么问题”而学。学完立刻用在项目里，没有项目支撑的技术，再好也先放一边。这个规矩看似保守，但它让我把学习从“负担”变回了“工具”，快乐和效果都回来了。
6.2 允许自己慢学、选学、不学
“不学”这个词，很多人一听就慌。但我想告诉你，明确列出一张“暂时不学清单”，是非常成熟的选择，不是逃避。
怎么列？就是把那些你听很多人说过、但跟当前工作和个人方向关系不大的技术，主动划入“一年内不碰”的范畴。比如你明确不做移动端，那移动端全家桶的热点你完全有理由不看；你工作里不涉及大数据平台，那堆组件你也不需要关心。这不是落后，是把有限的注意力放到真正重要的东西上。
我自己年轻的时候，曾经因为某个旧框架全公司都在讨论，花了两周熬夜学，结果后来公司换了技术栈，那个框架彻底用不上，白费了两周精力。教训就是：你的学习清单不该由别人手里的喇叭决定，该由你自己的需求和兴趣决定。允许自己慢一点、挑一点，甚至堂堂正正地不学，学习这件事才不会变成压垮你的另一根稻草。
7. 心态调整之六：给工作设置“下班模式”
程序员这行有个很普遍的现象：人走了，但脑子还在工位上。回家路上刷手机都在想今天那个bug到底为什么，吃饭的时候还在复盘需求逻辑，睡前最后一个念头还是“明天那道难题怎么解”。这种下班不离线，其实是真正的持续加班，而且比身体加班更伤。
7.1 建立一套固定的“工作切换仪式”
你有没有这样的经验：周六明明人躺在床上，但心里总有一根弦绷着，觉得“好像有什么活儿还没干完”，结果整个周末都过得心神不宁？这就是因为你没有给自己的大脑一个明确的“下班信号”。
建立切换仪式不难，关键是固定化。我认识的那些状态保持得比较好的开发者，各有各的仪式：有人下班后会去跑半小时步，有人回家先冲个澡换身衣服，有人喜欢做一顿复杂的饭，有人就打一局游戏。重点不在于做什么，而在于这个动作每天重复，让大脑知道“用这个动作开启非工作模式”。
如果你没有别的爱好，我强烈建议把“散步十五分钟”作为下班仪式。不需要看手机，就慢慢走，看看路边的树，听听风声。这个方法救过我很多次。很多想不明白的难题、理不清的思路，恰恰是散步的时候突然想通的。开发者的创造力本来就依赖大脑的“离线处理”，你越不给自己离线时间，你的思维反而越卡。
7.2 把工作消息从私人空间里挪出去
下班之后还频繁看工作群，是大脑持续保持工作状态的一大元凶。一会儿“丁丁”响，一会儿“有人@你”，哪怕只是无关紧要的水群，你都会习惯性分神。这种状态一旦持续到深夜，第二天再开机，大脑就像一个晚上都没关机的手机，续航自然越来越差。
我建议你做几个很简单的设置。第一，把工作聊天工具的提醒关掉，只保留电话和紧急联系人能打断你。第二，把工作App从手机桌面第一屏移走，藏进一个不容易看到的文件夹里。第三，给自己定一个“工作消息查看时间”，比如中午休息时和下午五点半各看一次，其他时间不回。一开始你可能会担心错过重要消息，但坚持一段时间你会发现：真正紧急的事，别人会打电话找你。能等你几个小时的事，本身也没那么紧急。
晚上睡前一小时，尽量不要碰工作消息。你不需要第一时间知道所有事，你需要的是让大脑真正相信“我下班了”。就这一个改变，我敢说你第二天的精神状态和工作效率都会好很多。
8. 心态调整之七：主动经营精力，而不是硬扛
很多开发者，特别是年轻一点的，会把“能熬夜”“能连着干十几个小时”当成一种荣誉。这种观念害人不浅。人的精力是有限的，你不可能永远靠透支身体来维持产出。心态调整到最后，其实要解决的就是一个底层问题：如何让能量收支平衡。
8.1 摸清自己的精力曲线，把难事放在高点
每个人每一天的精力不是平均分配的。有人早上最清醒，有人下午才来劲，有人夜深人静时效率爆表。可惜的是，大多数开发者的日程是外部安排的：早上开站会、上午对需求、下午改bug、晚上才有时间写代码。这种安排完全没考虑你的精力曲线。
我的建议是花一周时间做个简单的记录，每天分时段给自己打一个精力分，比如早上8到10点、10到12点、下午2到4点、晚上8到10点，各打一个1到10的分。一周之后，你基本能画出自己的“精力地形图”。然后调整工作顺序：把最烧脑的任务安排在精力峰值时段，把周报、回邮件、整理文档这类琐事放在低谷时段。
你可能觉得自己没法控制工作安排，但事实上，很多任务的时间是可以自行调整的。你完全可以把那一个小时的“深度编码时间”从晚上挪到早上，只要提前跟团队同步一下你的工作偏好就行。当你把最重要的脑力用在精力最好的时候，你会发现产出翻倍，累感反而下降。
8.2 把休息当成任务认真对待
前面聊的都是怎么省着用精力，这一节说的是怎么补充精力。很多开发者的作息有个严重问题：工作的时候拼命，休息的时候也不安心，总觉得自己“应该做点什么”。结果就是休息质量极差，刷了一天手机比上一天班还累。
我把休息分为两种：一种是碎片式恢复，比如每隔四十五分钟或者一个小时起来倒杯水、看看窗外、伸个懒腰，让眼睛和大脑从屏幕上解放一下。另一种是整段时间的深度恢复，比如周末至少要拿出半天，去做一件完全不碰代码的事。
最容易被忽略的是碎片式恢复。久坐不动盯着屏幕，看起来不累，其实大脑和身体都处于持续紧绷状态，这是隐形的消耗。我见过很多人下午三四点就精神涣散，还以为是自己老了，其实就是缺那一口“恢复”。给自己定几个“休息闹钟”吧，哪怕只是站起来走两分钟，回来再开写，状态都会不一样。
至于深度恢复，我的原则是：周六周日不碰任何技术内容，至少保证一天是完全“断电”的。运动、做饭、爬山、看展、发呆，随便什么都行，只要别再看代码。技术是你的职业，但不该是你唯一的人格。给自己的生活留一块不追求产出的自留地，这恰恰是你继续走远路的本钱。
9. 落地实操：我一直在用的三个防倦怠小工具
前面七个心态调整聊得比较散，这一节我帮你把它们收拢成三个可以落地的工具。工具不在多，每天真用上才管用。
9.1 成就日志与情绪垃圾桶
这两个东西在我看来是防倦怠的黄金搭档。准备一个文档，左边记“今日成就”，右边记“今日烦事”。成就栏不用写宏大的项目里程碑，写小而具体的事就行：“修好了那个偶现的登录报错”“给同事解释清楚了缓存失效的原理”“把一个用了一个月的临时脚本替换成了正式方案”。不需要赞美，只需要记录。
情绪垃圾桶那块也很有用。把让你烦的事写出来，比如“上午的需求变更打乱了我的计划”“被领导催进度，感觉不被信任”。写完以后，在下面画一道线，或者干脆把它标记成“已处理”。写下来的意思是：我把这件烦心事从脑子里拿出来了，我不需要再反复咀嚼它了。这个动作虽然简单，但真的能有效减少睡前胡思乱想。
9.2 季度复盘与“减负清单”
每三个月抽一个下午，做一次全面复盘。打开你的日程和任务列表，把你正在做的事全部列出来。然后逐一贴上标签：A类是“必须做且和核心目标有关”，B类是“应该做但不是非我不可”，C类是“只是习惯，其实没人等你做”。
做完分类后，重点处理B类和C类。B类看能不能授权出去或者降低频率；C类直接砍掉。我最近一次复盘，发现我每周要开两个例会，其实有一个议题我已经连续五周没发言了，纯纯浪费时间。砍掉之后，每周多出两个小时，团队同学也没人觉得少了什么。你以为的那些“不做不行的事”，很多只是惯性在拉着你走而已。
9.3 每周强制留出半天“非技术时间”
最后这个工具看起来最简单，执行起来最难。我建议你每周无论如何留出至少半天，做一件跟技术完全无关的事。不用多，半天足够。
难在哪儿呢？难在很多开发者已经把“活儿没干完的时候刷技术资讯”当成了一种心理补偿，真让他彻底不碰技术，反而浑身不自在。但你可以做个实验：连续一个月，每周六上午不看任何工作和技术内容，只做一件自己真正喜欢的、跟产出完全无关的事。一个月后回看，你会发现自己工作时间并没有变少，脑子反而清醒了很多。
这个“非技术时间”不一定要有意义，甚至可以很“无用”——看一部无脑爽片、拼一个巨大的拼图、去河边坐着晒太阳。目的只有一个：让大脑从持续的高密度认知负荷里彻底退出来。你的身心恢复能力恢复了，倦怠自然就失去了生存的土壤。
10. 心态调整的边界：什么情况下该换环境而不是硬调整
聊完7个心态调整，我必须诚实地说一句：心态调整不是万能的。有些时候，你要做的不是调整自己，而是换一个环境。
10.1 警惕“我应该心态好”带来的二次内耗
看了一些自我调整的文章之后，有一种反效果需要提前预防：有些人会把“心态好”变成新的KPI。今天又觉得烦躁、又想偷懒、又对队友不耐烦，就开始自责：“我学了那么多方法，怎么还这样？是不是我太矫情了？”
我要说，真的是没必要对自己这么苛刻。倦怠是一种长期的消耗造成的状态，不是看一篇文章就能一键清空。偶尔崩一下、烦一下、骂一句“这破班一天也不想上”，是再正常不过的事。这不代表你调整失败了，只代表你是个活人。允许自己有状态不好的一天，明天该干嘛干嘛，这才叫真正的接纳。
10.2 真正该离开的信号：环境性倦怠
心态调整帮你稳住内核，但改变不了客观环境。如果你的倦怠主要来自下面这些情况，那你再怎么调整心态，也只是在漏水的船里往外舀水而已：持续半年以上无休止的加班，长期不合理的排期，项目本身没有意义甚至有害，领导以打击压榨为管理手段，团队氛围让人每天上班都感觉窒息。这些属于环境性倦怠，根子不在你的脑子里，在系统里。
这种时候，真正该做的是调整环境：找一个更合理的团队、跟管理者摊牌谈工作负载，或者干脆换一份工作。不要因为“我要学会调整心态”就把自己钉在一个消耗你的位置上。心态调整的价值是帮你缓冲压力、看清方向，而不是让你忍受一切。
我自己的经验是，当你开始自我怀疑到“我是不是适合做这行”的时候，大概率不是你不行，是你待的地方不行。换一个环境，很多人又恢复了当年那个写起代码就停不下来的自己。
最后再分享一点个人体会。我第二次走出倦怠期，靠的不是某一个惊天动地的决定，而是那些看着很琐碎的小习惯：每天记成就日志、每周六早上写本周总结、给自己划出不可打扰的时间块、下班后坚决不看工作消息。这些东西单独拿出来都不起眼，但叠在一起，就帮我重新建立了一整套和工作的健康关系。
职业倦怠不是职业失败的标志，它更像是身体和心理在提醒你：过去那种活法，已经不适合现在的你了。心态调整说到底不是跟自己说“我没事”，而是把方向盘重新拿回自己手里——清楚自己为什么在做这件事，知道自己的价值在哪，明白什么时候该停下来休息，也明白什么时候该换条路走。希望这7个调整，也能帮你把那盏快要灭掉的灯，重新点亮。