技术直觉退化了？不，是换了一种用法
虚，从一次Code Review开始
第四周周一早上，陈钊做了一件已经很久没做了的事——打开IDE，认真看代码。
起因是小李上周提了一个PR，改动量不小，涉及到支付模块的核心链路。按照陈钊以前的习惯，这种级别的PR他至少要审查半小时，逐行过一遍关键逻辑。
但那天他只看了五分钟。
不是没时间，周一上午相对来说清闲一些，他完全可以拿出半小时来。但他发现了一个让自己不安的事实——他看不进去了。
不是代码写得不好。小李的代码风格一向规整，变量命名、模块拆分、注释都挑不出大毛病。
问题出在陈钊自己身上。
那些曾经像母语一样熟悉的代码结构，现在看过去，他觉得自己像是在读一篇外语文章——每行代码都认识，但连起来就是反应不过来意思。
他盯着一段涉及分布式事务的处理逻辑看了两分钟，脑子里突然冒出一个念头：
“如果我还在一线写代码，这段逻辑我会怎么写？”
他想不出来。
不是真的想不出来，是他不确定了。
以前他有笃定的技术判断力——“这里应该用TCC而不是SAGA”、“这个场景用消息队列比直接调用更合适”——这些判断来得自然、迅速，几乎不需要刻意思考。
但现在，他发现自己开始犹豫了。不是技术退步了，而是他已经太久没有沉浸在具体的技术细节里，那种直觉性的判断力在钝化。
这种感觉让他觉得——虚。
不是慌，不是忙，不是压，也不是尬。是一种更深层的、关于自我价值的不安全感：
“我还是一个技术人吗？”
这种"虚"不只你一个人有
先说一个事实：几乎所有从技术岗转到管理岗的人，都会经历这个阶段。
这不是错觉，也不是矫情。
它有清晰的心理学根源。
当你做了几年技术，你的职业认同是建立在"技术能力"上的——“我是团队里技术最强的人之一”、“遇到技术难题找我准没错”、“这段代码只有我能改”。这些认同构成了你职业自信的地基。
当你成为管理者之后，这个地基开始松动。
你的日常从"写代码"变成了"开会、沟通、协调、决策"。你花在技术上的时间断崖式下降，从原来每天6-8小时变成可能每天不到1小时。你的技术判断力没有消失，但它失去了持续"喂养"的养料，开始像没有锻炼的肌肉一样逐渐松弛。
与此同时，你的管理技能还在成长期，还没有建立起足够的新自信来替代旧的。结果是——旧的自信在消退，新的自信还没长出来，中间就出现了这个"虚"的阶段。
这是一个正常的、可预期的过渡期。
但"正常"不等于"无害"。
如果"虚"的状态持续太久，会有两个后果：
第一、你开始回避技术讨论。
在技术方案评审会上，你越来越少发表意见，因为你怕自己说错。你越来越依赖团队里技术最强的人来做技术判断，而你自己变成了一个纯粹的"传声筒"——上级说什么你转达什么，团队做什么你汇报什么。
第二、你开始怀念写代码的日子。
不是因为你真的想回去写代码，而是因为你怀念那种"我能搞定一切"的确定感。管理者的世界充满了不确定性，而代码的世界是确定的——跑得通就是跑得通，报了错就是报了错。
这两种后果如果同时出现，都会让你的管理角色空心化。
一个不参与技术判断的管理者，不是在管技术团队，是在管一个技术外包组。
管理者需要的技术能力，和工程师不一样
在解决这个问题之前，先搞清楚一个问题：管理者到底需要什么样的技术能力？
很多人把这个问题想简单了。他们以为"保持技术能力"就是"继续写代码"，于是拼命挤时间写代码，结果两头都顾不上——管理没管好，代码也写得断断续续。
管理者的技术能力和工程师的技术能力，是两种不同的能力。
工程师的技术能力是"深度能力"： 我能把这个模块写到最优、我能把这段逻辑调试到完美、我对这个系统的每一行代码了如指掌。
管理者的技术能力是"判断能力"： 我能判断这个技术方案是否合理、我能识别潜在的技术风险、我能在多个技术选项中做出正确的取舍。
深度能力需要大量的时间沉浸——每天写代码、调bug、看日志。
判断能力需要的是广度视野和持续的信息输入——你知道业界在做什么、你知道团队在用什么、你知道每个技术选项的利弊是什么。
管理者不需要亲自写代码，但必须保持对技术的判断力。
举个例子，同样是面对一个"要不要上微服务"的决策：
- 工程师会想：“怎么拆服务、怎么做服务发现、怎么处理分布式事务、怎么做链路追踪……”
- 管理者应该想：“我们现在的团队规模和技术能力，真的需要微服务吗？上微服务的ROI是什么？如果上了，团队需要多少人、多长时间、多少资源？这些资源的投入，和当前业务需求的优先级怎么排？”
前者是技术深度，后者是技术判断。
两者都很重要，但管理者更需要的，是后者。
保持技术判断力的四个实践
搞清楚了"需要什么"之后，接下来的问题是"怎么做"。
以下四个实践，是很多技术管理者验证过的、可以在有限时间预算内保持技术判断力的方法。
实践一：参加技术方案评审，而且要真的参与
这不是让你坐在评审会上当听众，而是让你带着问题去。每次技术方案评审前，花十分钟快速看一下方案文档。你不需要理解一行设计，但你需要问三个问题：
- 这个方案要解决什么问题？ 业务目标是什么？
- 有没有更简单的方案？ 是不是过度设计了？
- 风险在哪里？ 如果出了问题，影响面有多大？
这三个问题不需要你亲自写代码，但需要你对技术有基本的判断力——什么样的方案是合理的、什么样的复杂度是不必要的、什么样的风险是不能接受的。
如果你在评审会上问不出这三个问题，说明你的技术判断力在退化，你需要加大投入。
实践二：定期做"技术巡检"——不需要写代码，但需要看代码
每周或每两周，给自己留30到60分钟，专门看团队的代码。
不是看bug修复和小改动，而是看核心模块的架构变更、关键链路的重构、新引入的技术栈。
你需要关注的不是"这段代码写得对不对"，而是：
- 团队的代码质量在变好还是变差？
- 有没有在积累技术债？
- 新引入的技术是否被合理使用？
这些信息不会自动跑到你面前。你需要主动去看，才能保持对团队技术状态的整体感知。
实践三：保持一个"技术雷达"——知道业界在做什么
你不需要追逐每一个新技术，但你需要知道大的趋势和方向。
具体的做法：关注3-5个你关注的技术领域的高质量信息源——可以是技术博客、GitHub trending、行业技术大会的议题清单、你信任的技术团队的公开分享。
你不需要每一篇都深入阅读，但你需要扫一眼标题和摘要。这样当团队里有人提出"我们是不是该用Rust重写这个服务"的时候，你不至于一脸懵——你知道Rust适合什么场景，也知道重写一个服务的成本和风险。
技术雷达不是让你成为技术专家，是让你保持"不至于被忽悠"的底线。
实践四：偶尔亲手做一个小项目或小改动
注意，这里说的不是"在团队的核心系统上写代码"。
很多管理者会犯一个错误——他们觉得"保持技术能力"就是继续在团队的主力系统上写代码。但这样做有两个问题：
一是你的代码质量可能不如以前（毕竟不天天写了），影响团队标准；
二是你在主力系统上写代码会让团队困惑——“这个PR是该由你来提还是不该你提？”
更好的方式是：给自己找一个小项目。可以是一个内部工具、一个自动化脚本、一个side project。不需要多复杂，但需要让你亲手写代码、亲手调bug、亲手经历从"写"到"跑通"的完整过程。
这个过程的目的是让你保持"手感能力"——不只是判断力，还有那种打开终端、敲下命令、看到结果的本能反应。
手感不需要天天练，但不能完全丢。一旦丢了，想捡回来要花的时间比你想象的长。
陈钊的实践清单
周一上午，陈钊在笔记本上写下了四个问题：
- 上周的技术方案评审会，我认真看了方案吗？——没有。总监催得急，我匆匆扫了一眼就让团队过了。
- 这两周我看过团队的代码吗？——没有。小李的PR我还是因为"出了问题"才看的。
- 我最近有没有关注过技术动态？——好像看了几篇公众号推文，但都是标题党，没什么营养价值。
- 我上一次亲手写代码是什么时候？——貌似很久了，想不起来了。
四个答案都让他不太舒服。
但他没有让自己沉浸在"我怎么变成这样了"的情绪里。
他拿起笔，给自己写了一个"技术判断力维护计划"：
每周必做：
- 参加至少一次技术方案评审，提前10分钟看方案文档，准备3个问题
- 花30分钟做一次"技术巡检"——看这周的核心代码变更
每两周必做：
- 花1小时浏览技术信息源，更新自己的"技术雷达"
每月必做：
- 亲手做一个小的技术项目或改动，保持手感
- 他把这个计划贴在了工位旁边的白板上。
不是因为觉得自己做不到，而是因为他知道——如果不写下来，这些事永远不会被排进他的日程里。管理者的时间永远是别人的，只有你自己写下来的东西，才有可能属于你。
他又想起了上周老赵给的那个反馈：“你得学会拒绝。”
学会拒绝不合理的需求是一种能力，学会拒绝时间的碎片化侵蚀，也是一种能力。
保持自己的技术判断力，从保护时间开始。
转身，还没有完
第四周接近尾声的时候，陈钊回顾了一下晋升技术管理者的这一个月。
从第一天坐在那个熟悉的工位上不知道该做什么，到现在，陈钊经历了一次初步的转身。
他翻开笔记本，看到了从第一天到现在自己记下的那些东西：
第一周：慌——坐在那个熟悉的工位上，不知道该做什么。
第二周：忙——每天回两百多条消息，开四到六个会，真正写代码的时间少得可怜，知道自己在做什么，但没有节奏。
第二周下班前：压——一次线上事故，上级的电话让他意识到向上管理的本质不是汇报，是让上级放心。
第三周：尬——茶水间里小张那声变了调的"钊哥"，让他明白关系的转型不是自然而然就会发生的。
第四周：虚——看代码看不进去了，他开始怀疑自己还是不是一个技术人。
这五种情绪，不是弱点，是信号。
每一种情绪都在告诉他：你正在成长。
慌告诉你，你需要重新定义自己的角色。
忙告诉你，你需要管理自己的时间和精力。
压告诉你，你需要学会和上级建立信任。
尬告诉你，你需要重新建立人际边界。
虚告诉你，你需要找到管理语境下的技术存在感。
陈钊站在办公室的窗边，看了一眼窗外的天。天色渐暗，但远处的写字楼还亮着灯。
他想起第一天的自己——坐在那个位置上，像个新入职的实习生一样手足无措。现在回头看，四周好像很长，又好像很短。
他打开了手机，在备忘录里写了一句话：
“转身不是转身离开，是转身面向另一个方向。原来的路还在，只是我换了一个看它的角度。”
合上手机，他看了一眼工位旁边白板上的那张清单——每周评审、每周巡检、每两周雷达、每月手感。
还有那张更长一些的：每月1v1、团队沟通期望说明、小周onboarding计划、消化老赵"学会拒绝"的反馈……
清单越来越长，但状态越来越好了。
不是因为什么都解决了。是因为他开始知道——管理这件事没有"顿悟"的时刻，是一周一周地碰到问题、解决问题，一个问题一个问题地积累判断力和信任。
回头看的时候才发现，自己已经渐渐走了很远。
这是第一季的最后一篇，但不是这个故事的最后一章。
第二季，方向——让团队交付正确的结果。
下期预告：《第二季导读：方向——让团队交付正确的结果》 ——初步站稳了跟脚之后，下一个问题是："我在带着团队往哪儿走？"第二季，我们将从需求评审开始，沿着一条从"接需求"到"交结果"的完整链路，拆解技术管理者的第一核心命题——方向。
S1E5 完 | 约4300字