题图
（题图由AI生成）

今天在一个编程微信群里，有人偶然聊起其部门管理模块的开发，说全部做完至少5000行，我随口回了句：才五千行，很少啊，AI小半天就能搞定，即使古法编程，正常速度，大概也就需要十来天。结果群友回复说自己就是古法编程，一天搞定了2000行，但也不忘补一句——这还不算写错了删掉作废的代码。紧接着又有人跳出来，说他的模块做得极简单。马上有人反对，说背后涉及的东西复杂得很，不是简单的树形关系就能搞定，甚至一些人情世故的因素都得考虑进去。“这就是需求。”

就这么一个话题，引出了不少可琢磨的东西。

先说代码量。我回那位群友说，你相当高产了，我要是一天产出这么多代码，坚持不了多久，而且代码质量很差。能够稳定保持且保证质量的，我最高只能做到四五百行每天。他解释说写的是框架代码，有固定模式，所以速度快。这就引出一个老问题：程序员每天应该写多少行才算正常？

好几年前，听说大牛们每天只写几十行，有的甚至每天是负数——因为重构代码，删的比写的多。我当时还认真琢磨过这事，想着自己是不是得努力练到每天一两百行才算合格。结果还没来得及练，AI辅助编程就来了，把所有计划全部打乱了。现在回头看，“每天多少行"从来就不是一个有效的度量指标。写2000行样板代码和工作逻辑，和写200行经过深思熟虑的代码，含金量完全不同。代码不是写完就完了——它需要被维护、被理解、被修改。那些"每天几十行"的大牛之所以写得少，不是写不出来，而是他们在下笔之前已经把问题想透了，写出来的每一行都经过了取舍和权衡。

AI来了之后，“写"的成本几乎降到了零，但"想"的成本反而变得更突出了。因为可以轻松产出大量代码，就更需要想清楚再动手，否则垃圾代码的产出速度也会同步提升。

这让我联想到群里另一段对话。说模块做得极其简单的人，和说背后极其复杂的人，其实都没错。区别在于他们在做不同的选择——一个人选择在当前阶段保持简单，另一个人看到了未来可能膨胀的复杂度。这两种选择的背后，其实是一种判断力：软件应该做得多"真实”？ 真实世界是无限复杂的，而软件是有限资源的产物。做多了，过度设计；做少了，无法满足需求。需要在"够用"和"够灵活"之间找到那个恰当的切面。这不是技术问题，这是判断力问题。而判断力只能靠实战打磨。

提到大牛每天写几十行甚至负数时，群友插了一句：你说的应该是算法岗老师。这个说法让我想了想。

我对"算法岗"这个提法不太认同。算法这个词，这些年被神化得有点过了，搞得好像算法可以独立于代码存在一样。其实算法没有那么神秘或高大上——我认为，能够按照预设逻辑让计算机执行并得出期望结果，就是算法。这本来就是每个程序员都该掌握的基本技能。真正优秀的程序员，在写代码的同时会兼顾三件事：编码效率、运行效率、未来的维护效率。这三者往往是矛盾的——追求运行效率可能会牺牲可维护性，追求编码速度可能会留下性能隐患。能在第一时间做出合适的选择，靠的是长期实战练出来的感觉。这种感觉不是看书能看出来的，也不是背面试题能背出来的，需要你在真实的项目里踩过坑、写过烂代码、又回来重构过，才能慢慢建立起来。算法从来不是某个特定岗位的专属技能，它是程序员的基本功。把"算法"单独拎出来作为一个岗位，某种程度上是对这个基本功的异化。

这种把某个技能从整体中剥离出来、单独设岗的做法，让我想到大厂的岗位划分逻辑。我的观点是：把岗位划分那么细，完全是大厂为了把每个人都打压到可以随意替换掉的结果。 美其名曰"标准化"和"分工协作”，但本质上是在追求劳动力的可替代性。每个人只做自己那一小块，走了随时换人，不影响整体运转。这种模式对管理层很友好，对个体则未必。更关键的是，它割裂了对问题整体的理解。做前端的不知道后端在干什么，写业务逻辑的不理解数据结构的考量，调算法的看不到最终产品的样貌。每个人都守着自己的一亩三分地，久而久之，对整个系统的认知就会变得支离破碎。

不过，AI正在打破这种壁垒。

AI辅助编程的出现，让一个人完全可以做从前一个小团队才能做的事。效率和质量并不输给过去的分工模式。这不仅仅是因为AI能帮你写代码，更重要的是，AI可以充当那个帮助你弥合认知裂缝的桥梁。不懂前端？让AI帮你生成界面代码。不了解底层原理？让AI解释给你听。需要跨领域知识？AI是最不厌其烦的老师。一个人能做的事情范围在急剧扩大。

但这里有一个陷阱需要警惕：工具越强大，对使用者的判断力要求就越高。 AI能帮你写出5000行代码，甚至一天都不用，但它无法替你判断这5000行代码是否应该写成那样，是否留下了技术债，是否在半年后会让接手的人痛不欲生。框架和工具能提升效率，当然要用，但用的时候要想清楚：它解决了我什么问题？它又引入了什么新的约束？这个约束将来会不会变成技术债？这些思考，AI替不了你。

说到判断力，还要补充一个更具体的环节——代码审核。AI的确能写出大量让人眼前一亮的代码实现，但它也总会在不经意间塞入不恰当的、甚至错误的内容。有时候是一个逻辑漏洞，有时候是一个不该被调用的函数，有时候是看似合理但放在整体架构中格格不入的一段设计。如果不能把这些识别出来并加以修复，交付质量必然受影响。

这就引出了一个新的矛盾。要让AI少犯错，最直接的办法是把需求描述得足够精确。但自然语言的本质是模糊的——越追求精确，描述成本就越高，而且常常事倍功半。你会发现，当你把需求用自然语言写了一大段密密麻麻的说明之后，AI给出的结果反而可能因为过度解读而偏离得更远。因为自然语言中的修辞、语气、上下文依赖，甚至标点符号，都会成为AI"自由发挥"的依据。越是留出"自由发挥空间"的说法，AI越可能犯错。那反过来，用极度精确的自然语言去约束呢？写到那个精确度，反而不如直接用计算机语言来得高效。毕竟代码本身就是一种形式化的精确描述——人类和编译器（以及现在的AI）都能理解，而且没有歧义。

所以，在AI辅助编程的时代，一个关键技能是：知道什么时候用自然语言描述需求，什么时候直接用代码表述意图。 前者适合表达目标和约束，后者适合表达实现细节。两者之间的切换和判断，又回到了前面说的——判断力。

说了这么多，其实就想表达一件事：编程这件事，核心从来不是写代码，而是做判断。 判断什么该做、做到什么程度、用什么方式做、未来会付出什么代价。这些判断力的积累，没有捷径。AI可以帮你写得更快，但不能帮你想得更清楚。至于那些大厂的岗位壁垒，AI确实正在把它们一个个推倒，这是好事。但推倒之后，我们每个人能不能接得住那个"什么都能做"的期望，还要看自己的积累够不够。至少我很确定，无论是否古法，保持每天一定的代码量输出，用以解决实际问题，以此来持续打磨判断力，这条路不会错。

--- END ---