凌晨三点，他盯着屏幕上的报错日志，手指悬在回车键上方。过去72小时，第三十七次部署失败。

这位在硅谷干了八年的全栈工程师，此刻正在怀疑自己是不是"搞砸了"。不是某个具体的技术决策，而是整个人生路径——从稳定的大厂跳去创业公司，从熟悉的领域转向陌生的赛道，从确定性的年薪数字走向股权的未知数。

技术债务像滚雪球。他清楚记得入职时CTO拍着他的肩膀说"快速迭代"，现在才明白那意味着"先跑起来，坑以后填"。代码库里藏着十七种不同的状态管理方案，三个版本的组件库并行运行，而文档永远停留在"TODO：补充说明"。

更隐蔽的消耗来自决策疲劳。每天早晨站会要解释为什么进度滞后，每个下午要和产品经理博弈需求边界，每晚要安抚焦虑的实习生。他发现自己花在沟通上的时间超过了写代码，而真正的技术深度却在流失。

这种怀疑并非软弱。斯坦福大学2023年的一项研究显示，技术从业者在职业中期出现"能力怀疑峰值"的比例高达67%，远高于其他行业。问题的核心在于：技术迭代速度远超个人学习曲线，而行业文化又将"持续学习"包装成一种道德义务。

他最终没有按下回车键。凌晨四点，他关掉IDE，打开文档，开始写下第一份技术债务清偿计划——不是给团队的，是给自己的。列出三项必须深耕的技术领域，设定六个月的学习里程碑，并明确一条底线：不再接受"以后再说"的妥协。

自我怀疑的反面不是盲目自信，而是清醒的自我定位。工程师的困境往往源于把"能解决问题"等同于"必须解决所有问题"。承认某些问题需要交给时间、交给团队、交给更合适的工具，本身就是一种技术成熟。

天亮时，他提交了第三十八次部署。这次通过了。但他知道，真正的修复发生在那之前——当他决定停止用战术上的勤奋，掩盖战略上的模糊。