我讲一个真实的故事。

研一刚入学的时候，我们组有个博士师兄，技术在整个实验室是公认最强的那种。强到什么程度呢——导师遇到搞不定的工程问题会直接@他，其他组的老师也会来”借”他帮忙debug。

有一次我遇到一个bug，折腾了两天没解决，去找他帮忙看。他坐下来，没有直接看我的代码，而是先问了我三个问题：

“你觉得问题出在哪一层？” “你已经排除了哪些可能性？” “你是怎么排除的？”

我支支吾吾答不上来。因为我那两天的”debug”方式基本上就是改一行跑一下、改一行跑一下，碰运气式的乱试。

他看了我一眼，说了句让我至今记得的话：

“你现在不是在debug，你是在抽奖。”

然后他花了大概十分钟，没有改一行代码，纯靠看日志和读代码逻辑，就定位到了问题。

那一刻我受到的冲击不是”他好厉害”——而是“我以为自己在编程，但其实我根本不会编程”。

这个认知转折是我后来一系列变化的起点。今天这篇回答，就是从那个起点出发，聊聊我这两年对”编程很厉害”这件事逐渐形成的理解。

不是什么完整的方法论，更像是一路走来踩过的坑和慢慢想明白的事。（不过有一说一，师兄是不是有点小装💢，呜呜呜，不过确实挺强哈哈哈哈）

---

一、首先得搞清楚，”很厉害”到底长什么样

大部分人对”编程很厉害”的想象是：

• 打字飞快，代码哗哗地写

• 会很多语言和框架

• LeetCode刷了上千道

• 能写出很复杂的程序

这些都是外行视角。或者更准确地说，是”初学者眼中的厉害”。

真正编程厉害的人，我观察到的共同特征是完全不同的几样东西：

第一，他们能精确地定位问题。

就像前面那个师兄一样。遇到bug，他不会慌，不会乱试，而是有系统地缩小排查范围——先确定问题在哪一层，再确定是哪个模块，再确定是哪几行代码，最后精确定位。整个过程像外科手术一样干净利落。

这个能力看起来不起眼，但它背后需要的是：对整个系统的运行机制有清晰的心理模型，知道数据从哪来、经过了什么处理、到哪去、每一步可能出什么问题。

没有这个心理模型的人，面对bug就只能抽奖。

第二，他们写的代码是”给人读的”。

初学者追求”代码能跑起来”，进阶者追求”代码跑得快”，而真正厉害的人追求”代码能被别人（包括三个月后的自己）轻松读懂和修改”。

这个追求背后的理念是：代码被写出来一次，但会被读几十次上百次。 写代码的时间远小于读代码、改代码、debug代码的时间。所以代码的可读性、可维护性，比那些花里胡哨的技巧重要得多。

我师兄写的代码我看过，说实话第一感觉是”也没什么特别的啊”——没有什么炫技的写法，变量命名清清楚楚，逻辑结构一目了然，关键的地方有恰到好处的注释。

后来我才明白，能把代码写得”看起来没什么特别的”，恰恰是最难的事情。 因为它意味着你把所有的复杂性都在脑子里理清楚了，然后用最简单直接的方式表达出来。

第三，他们知道什么时候不写代码。

这个最反直觉。

厉害的程序员不是写代码最多的那个人，很多时候他们反而写得最少。因为他们会先花时间想清楚：这个问题真的需要写代码来解决吗？有没有现成的工具或者库可以用？有没有更简单的方案可以避免写一大堆复杂逻辑？

每一行代码都是负债——它需要被维护、被测试、被理解。代码越少，负债越小。能用十行代码解决的问题绝不写一百行。能用现成工具解决的问题绝不自己造轮子（除非是为了学习）。

这个其实我导师也说过哈哈哈哈，说起来，这让我想到了研究生刚入组的时候，当时居然还想 为一个项目专门做一个Python库哈哈哈，然后组里师兄委婉的说工作量是不是太大了哈哈哈。

言归正传，我以前觉得代码写得多说明我效率高、很勤奋。后来才意识到，那只是因为我没想清楚就开始写了，然后在错误的方向上越跑越远，最后还得推倒重来。

（特别是有了AI之后，从前写的多至少还有点苦劳，现在苦劳都没有了哈哈哈哈哈）

添加图片注释，不超过 140 字（可选）

---

二、我走过的弯路

在理解了”厉害”长什么样之后，我回头审视了一下自己之前的学习路径，发现走了不少弯路。这些弯路我觉得很有普遍性，几乎每个自学编程的人都踩过。

添加图片注释，不超过 140 字（可选）

弯路一：疯狂学新语言、新框架，以为会的多就是厉害

我本科的时候，简历上恨不得写十种编程语言。Python、Java、C++、Go、JavaScript、Rust……每个都学了点皮毛，能写个Hello World，能跟着教程做个小demo。

当时觉得自己挺厉害的，会这么多语言。

后来我发现，这跟”会说十种语言的开头打招呼”差不多——看起来很唬人，其实哪种都不能真正用来交流。

编程语言本身只是工具。你用锤子用得很熟练不代表你是好木匠，你对木材的理解、对结构的直觉、对工艺的审美才决定了你是不是好木匠。

真正厉害的程序员往往就精通一两种语言，但他们对”编程”本身的理解是深刻的——数据结构、算法思维、系统设计、抽象能力——这些东西是跨语言的，学会了在任何语言里都能用。

一个我后来想明白的道理：语言和框架是”学了就会过时”的东西，而编程思维是”学了就跟你一辈子”的东西。 你的时间应该更多地花在后者上。

弯路二：只看教程不写项目，以为”看懂了”等于”会了”

这个坑巨大，而且非常隐蔽。

看教程的时候你会有一种”我都懂了”的错觉——视频里老师敲一行代码，你跟着敲一行，运行成功了，感觉学会了。

但当你关掉教程，面对一个空白的编辑器，要从零开始写一个东西的时候，你会发现脑子里一片空白。

因为”看懂别人的代码”和”自己能写出代码”是完全不同的两种能力。 看懂是识别，自己写是生成。识别的难度远低于生成——你能看懂一篇好文章不代表你能写出一篇好文章，同理，你能看懂一段好代码不代表你能写出一段好代码。

这个弯路我走了很久才转过来。转折点是有一次我强迫自己不看任何教程，纯靠官方文档和搜索引擎从零做了一个小项目。过程非常痛苦，以前看教程两小时能学完的东西，自己摸索花了两天。

但那两天学到的东西比之前看两周教程都多。

因为自己摸索的过程中，你会遇到真实的问题——不是教程里精心安排好的、有标准答案的问题，而是乱七八糟的、文档没写清楚的、Stack Overflow上搜了半天才找到答案的问题。解决这些问题的过程才是真正的学习。

弯路三：追求”最佳实践”，忽视”理解原理”

学到中级阶段的时候，我开始疯狂追各种”最佳实践”——设计模式怎么用、代码架构怎么搭、什么场景用什么技术栈。

收藏了一堆文章和清单，这个场景用策略模式、那个场景用观察者模式、数据量大了用Redis、并发高了用消息队列。

后来发现一个问题：我知道了”该用什么”，但不知道”为什么用这个”。

面对一个具体的问题，我能从收藏夹里翻出一个”最佳实践”往上套，但如果问题稍微变一下形，跟收藏夹里的模式对不上了，我就懵了。

因为我学的是结论，不是推导过程。

真正理解一个技术方案，意味着你知道：

• 它解决的核心问题是什么

• 它的设计思路是什么（为什么这样设计而不是那样）

• 它的trade-off是什么（获得了什么，牺牲了什么）

• 它在什么条件下会失效

到了这个理解深度，你就不再需要记忆”最佳实践”了——因为你可以根据具体场景自己推导出最合适的方案。那些最佳实践不再是你死记硬背的教条，而是你自己也能想到的自然选择。

---

三、后来我做对了什么

弯路走够了之后，我开始做一些不同的事情。不敢说这些事情让我变得”很厉害”了——离那个标准还差得远——但它们确实让我有了明显的进步。

添加图片注释，不超过 140 字（可选）

做对的事情一：开始读别人的代码

这个习惯是我师兄强烈推荐的，也是我觉得投入产出比最高的学习方式之一。

不是随便读，而是挑那些公认质量高的开源项目来读。

一开始读起来非常痛苦。一个大型开源项目，成千上万行代码，完全不知道从哪里入手。后来摸索出了一套方法：

第一步，先读项目的README和文档，搞清楚它是做什么的、核心概念有哪些。

第二步，从一个具体的功能入手，追踪它的执行流程。比如一个Web框架，你可以追踪”一个HTTP请求从进来到返回响应”经过了哪些代码。

第三步，遇到不理解的设计，先想想”如果让我来做我会怎么做”，然后看看作者为什么那样做，差异在哪里。

这个过程中你会学到大量从教程里学不到的东西——代码组织的方式、错误处理的策略、性能和可读性的权衡、工程上的各种小技巧。

而且很多时候你会发现，顶级项目的代码并不是想象中那样”高深莫测”。它们之所以好，恰恰是因为把复杂的问题用简洁的方式解决了。 读完之后你会有一种”原来可以这样啊”的感觉，这种感觉积累多了，你的代码审美和设计直觉就慢慢上来了。

做对的事情二：开始写”完整”的项目

注意这里的关键词是”完整”。

不是跟着教程做一个demo然后就算了，而是从需求定义到最终部署的完整过程全部自己走一遍。

这两者的差距有多大？列一下你在做”完整项目”时会遇到而在”跟教程做demo”时永远遇不到的事情：

• 需求不清晰，你得自己定义问题的边界

• 没有人告诉你该用什么技术，你得自己调研和选型

• 代码写到一半发现最初的设计有问题，你得决定是重构还是打补丁

• 要处理各种边界情况和异常场景

• 要写测试，要考虑部署环境跟开发环境的差异

• 要在功能、性能、可维护性之间做取舍

• 要处理”这个bug在我的机器上明明没问题”这种让人想砸电脑的情况

这些问题加在一起，才构成了真实世界里”编程”的全貌。只做demo的人永远接触不到这些，所以他们的能力会卡在一个看不见的天花板上。

做什么项目不重要，关键是完整。一个完整的、哪怕功能很简单的项目，学到的东西比十个半吊子demo加起来都多。

做对的事情三：刻意练习”思考在前、编码在后”

这个习惯是被那个师兄”骂”出来的。

以前我拿到一个任务，第一反应是打开编辑器开始写代码。写到一半发现思路不对，删掉重来。再写，再发现不对，再改。一个下午过去了，代码改了七八版，最终版跟第一版比可能完全不一样。

师兄跟我说：”你花在键盘上的时间太多了，花在脑子里的时间太少了。”

后来我强迫自己养成了一个习惯：拿到任务之后，先不碰键盘。

先在纸上或者脑子里把几个问题想清楚：

• 这个任务的输入是什么、输出是什么

• 核心逻辑分几步

• 哪些地方可能出问题

• 有没有我不确定的技术点需要先调研一下

想清楚了再开始写。

一开始很不适应，因为”打开电脑开始敲代码”会给人一种”我在工作”的安全感，而坐在那里对着白纸发呆会让人觉得自己在偷懒。但慢慢地我发现，想清楚再写的总耗时反而更短——因为不需要反复推倒重来了。

而且代码质量明显更好。因为在想的过程中你已经把各种情况都过了一遍，写出来的代码天然就考虑得更周全。

后来我在一本书里看到一句话，跟师兄说的是一个意思：

“Weeks of coding can save you hours of planning.” （几周的编码可以让你省下几小时的规划——反讽。）

幽默但真实。很多人以为编程的瓶颈在手速，其实瓶颈在脑子。

做对的事情四：学会在正确的层次上偷懒

这个说法可能有点怪，我解释一下。

所谓”在正确的层次上偷懒”，意思是：把精力集中在真正需要你动脑子的地方，其他地方能省则省。

举几个例子：

能用现成的库就不自己写。你的时间应该花在业务逻辑和核心算法上，而不是花在重新实现一个JSON解析器上。

能用工具自动化的就自动化。代码格式化、静态检查、测试、部署——这些重复性的工作全部交给工具，你的脑力留给更有价值的事情。

能用AI辅助就用AI辅助。Copilot这类工具对于写一些模板代码、查API用法、快速生成初始版本是非常好用的。但要注意——AI生成的代码你必须能读懂、能评判、能修改。 如果你只是无脑复制AI的输出，那你不是在编程，你是在当AI的人肉运行器。

我见过两种极端。一种人对所有工具和库都抗拒，什么都要自己从头写，觉得这样才”扎实”。另一种人对所有工具和库都依赖，离了框架和AI什么都写不出来。

两种都有问题。理想的状态是：你有能力从底层开始写，但你选择不这样做——因为你知道你的时间更值得花在哪里。

这种”有能力但选择不用”的状态，跟”没能力所以只能用工具”的状态，外表看起来一样，但本质完全不同。前者是站在高处往下看，后者是被困在低处出不来。

---

四、几个我至今还在琢磨的问题

前面说的那些东西，都是我觉得比较确定的、已经验证过的。接下来说几个我还没有想透彻、但觉得很重要的问题。

问题一：编程能力的增长到底是线性的还是阶梯式的？

我自己的体感是阶梯式的。

会有很长一段时间你觉得自己没什么进步，每天写代码的感觉跟上个月差不多。然后突然有一天，某个东西”通了”——可能是你突然理解了某个底层概念，可能是你做完一个项目之后发现自己看问题的视角变了——然后你明显感觉自己上了一个台阶。

这种阶梯式的特征带来一个问题：在”平台期”你很容易失去耐心和动力。 你觉得自己在做无用功，想放弃或者换方向。但其实平台期可能恰恰是你在积累”量变”的阶段，只要坚持下去，质变会来的。

当然这只是我个人的体验，不一定有普遍性。但如果你也有过这种”明明一直在学但感觉没进步”的困惑，也许可以参考一下。

问题二：怎么平衡”广度”和”深度”？

这个问题我到现在也没有一个满意的答案。

一方面，编程这个领域太广了——语言、框架、工具、方向——你不可能什么都学。不做选择，精力会被稀释成一盘散沙。

另一方面，只钻一个方向的话，视野会变窄，你可能会错过其他领域的好思路和好工具，而且万一这个方向过时了你就很被动。

我目前的做法是一个不太优雅但还算实用的策略：

选一个主方向深挖，同时保持对其他领域的”新闻级别”的关注。

什么叫”新闻级别”？就是你大致知道其他领域最近发生了什么、有什么新趋势、核心概念是什么，但不深入细节。如果某天你需要用到那个领域的东西，你知道该去哪里学、学什么。

这种程度的广度不需要太多时间投入——平时刷刷技术社区、看看别人分享的文章、跟不同方向的同学聊聊天就够了。但它能让你在需要的时候不至于两眼一抹黑。

问题三：AI时代，编程能力还重要吗？

这个问题最近被问得越来越多了。毕竟我自己就是做AI方向的，对大模型写代码的能力有比较直观的感受。

我的判断是：编程能力不但没有变得不重要，反而变得更重要了——只不过”重要的编程能力”的内涵在变化。

以前，编程能力中有相当一部分价值来自于”记忆”——记住语法、记住API、记住各种写法的细节。这部分价值确实在被AI替代。你不需要记住Python里某个库的某个函数的参数顺序了，问AI两秒钟就能得到答案。

但编程能力中另一部分——设计能力、抽象能力、问题拆解能力、系统性的调试能力、对复杂性的管理能力——这些东西不但没有被替代，反而因为AI降低了编码的门槛而变得更加稀缺和宝贵。

因为当所有人都能借助AI快速写出代码的时候，瓶颈就不再是”能不能写出来”，而是”知不知道该写什么、该怎么设计、出了问题该怎么排查”。

换句话说，AI把编程的下限提高了（不太会写代码的人也能写出能跑的东西），但上限并没有降低（真正复杂的系统设计和架构决策，AI目前做不了）。

在这种情况下，处于中间层的”能写代码但没有太多思考深度”的程序员会被压缩，而两端——”完全不会写代码但现在可以借助AI做一些简单的事情”的人和”真正理解系统设计和底层原理”的人——都会获益。

如果你想成为”编程很厉害的人”，你应该瞄准的是后者。

---

五、如果让我重新来过

最后，如果让我回到刚开始学编程的时候，知道我现在知道的这些东西，我会怎么做？

第一年：打地基。

不追求学很多语言和框架，选一门语言（比如Python或者C++）老老实实地学透。同时把数据结构和算法的基础打好——不是为了刷题，而是为了建立”用计算机解决问题”的思维方式。

每周做一些小练习，但更重要的是读代码。找几个经典的开源项目，每周花几个小时读，不求全读完，但求读懂的部分真的理解了。

第二年：做项目。

开始做完整的项目。从小项目开始，逐渐增加复杂度。每个项目结束后做复盘：哪些地方设计得不好？如果重做一遍会怎么改？

这个阶段也开始接触操作系统、计算机网络、数据库这些基础课程。不用学得多深，但核心概念要理解——因为你写的代码最终是跑在这些东西上面的，不理解它们你就不知道你的代码在底层到底发生了什么。

第三年及以后：找到方向，深扎下去。

到了这个阶段你应该对自己的兴趣和擅长有一些认知了——是对系统底层感兴趣，还是对应用开发感兴趣，还是对算法和数据感兴趣？选一个方向深入进去。

同时开始参与开源社区、做实习、或者在其他真实场景中检验自己的能力。因为到了一定阶段之后，闭门造车的学习效率会急剧下降，你需要来自真实环境的反馈来知道自己差在哪里。

当然这只是一个理想化的路径。实际情况肯定不会这么整齐，每个人的节奏也不一样。但大方向我觉得是对的：先打基础，再做项目，然后找方向深入。不要反过来。

---

写在最后

这篇回答写下来，我自己也重新梳理了一遍这两年的学习过程。说实话，写到一半的时候有点心虚——我自己也还在路上，远远没有达到”编程很厉害”的标准，凭什么来回答这个问题？

后来想了想，也许正因为我还在路上，我的这些体会反而比那些已经到达终点的人的回忆更贴近正在赶路的人的真实处境。大佬回头看自己的成长路径，往往会不自觉地简化和美化。而我现在还记得每个坑摔进去的时候有多疼。

最后借用那个师兄跟我说过的另一句话作为结尾。有一次我问他”你觉得你是什么时候变厉害的”，他想了一会儿说：

“没有哪个时刻。只是有一天回头看，发现以前觉得很难的东西现在觉得很自然了。然后你又遇到了新的觉得很难的东西。这个循环好像一直没停过。”

大概编程就是这么一件事——永远觉得自己不够厉害，但确实一直在变厉害。（呜呜可恶又被他装到了💢）

共勉。