AI 时代 Coding 还重要吗？

https://www.chaspark.com/#/hotspots/

2025 年了，大家都在谈 Vibe Coding，好像 AI 马上就要把写代码这件事给包圆了。这让我想起前阵子组里有同学问我：“老大，现在还要死磕代码细节吗？是不是太低效了？”

这种焦虑其实挺普遍的。如果你把 Coding 仅仅看作是“把逻辑翻译成计算机语法”，也就是敲键盘，那 AI 确实比我们干得快，也干得好。

但是，写代码这事儿，还真没那么简单。

这就好比盖房子，搭一个让小狗能住的窝，和建一座能用一百年的摩天大楼，虽然都叫“盖房子”，但根本不是一个物种。写 100 行代码，谁都能搞定；但要在 10000 行旧代码的基础上再加 100 行，还能保证不塌房，这就需要真功夫了。Coding 是一项极具创造性的脑力劳动，是用逻辑模拟现实世界的过程，是解决复杂问题的工程艺术。

所以，哪怕到了今天，我依然觉得，把“写好代码”这件小事做极致，是一条通往技术高手的必经之路。

1、我的 Coding 成长路线

在 NEO 以及部门给新同学分享如何去做好 coding 这件事，我反复在提几本书，这几本书印证了我的 coding 成长路线，同时也体现了我的知识局限。有代表性的分别是《代码整洁之道》、《设计模式：可复用面向对象软件的基础》、《重构：改善既有代码的设计》、《敏捷软件开发：原则、模式与实践》、《架构整洁之道》、《领域驱动设计》、《代码大全》、《程序员修炼之道》、《Google 软件工程》。

我给自己列过一个技术书籍阅读清单，这就是我在上篇文章中提到的学习地图，悲惨的是到目前为止只精读了一半吧，剩下没读的基本是跟我当前工作不相关的，如我之前所说，我是“功利性”的即时学习者。

回顾我的技术进阶之路，这并非一条线性的上升曲线，而是一次次认知的重塑与突围。它大致可以分为以下四个阶段：

阶段一：代码层面的极致追求——从“机器语言”到“人类语言”

核心书单： 《代码整洁之道》（Clean Code）

刚工作那会儿，我和大家一样，觉得代码嘛，只要编译通过、功能跑通，任务就算完了。

直到我读了 Bob 大叔那本《代码整洁之道》。这本书给我最大的冲击就是一句话：代码首先是写给人看的，顺便才是给机器跑的。

这一下把我的观念给扭过来了。我开始意识到，你写的那个变量名，不是几个字母的组合，而是你在跟接手你代码的人（很可能就是三个月后的你自己）对话。

大家知道我入职第二年拿了个“金码奖”。说实话，那时我哪懂什么高深算法，我只是养成了一个“洁癖”：绝不让一个函数长得超过一屏幕，绝不写让人猜谜语的变量名。

这其实就是职业素养。就像吴军老师常说的，专业和业余的区别，就在于你是不是能持续稳定地交付高质量的东西。 对程序员来说，写出干净的代码，就是咱们的脸面。

阶段二：设计与重构的辩证法——对抗系统的“熵增”

核心书单： 《设计模式》、《重构》、《敏捷软件开发：原则、模式与实践》

代码写多了，你会发现一个让人头疼的现象：系统好像总是在自动变坏。修一个 Bug，冒出来俩新 Bug；加个小功能，却要改七八个文件。

在物理学里，这叫“熵增”，就是说万物如果不加干预，总会变得越来越无序。软件系统也是一样。

后来我跟着软件教练做大型重构，那段日子特别苦，但也最锻炼人。以前我觉得《设计模式》是用来炫技的，后来我才明白，那其实是前人留下的“避坑指南”。

我拿过公司的“最佳重构项目”，其实我就干了一件事：给系统做减法，让它变轻。 真正的敏捷不是你敲代码的手速有多快，而是你的代码耦合度够低，改动起来像搭积木一样轻松，而不是像拆一团乱麻。

这一阶段，我从单纯的“写代码”，进化到了“设计系统”。我深刻体会到，好的设计不是为了炫技，而是为了让未来的变化变得更便宜。

阶段三：架构与业务的融合——看见森林，而非树木

核心书单： 《架构整洁之道》、《领域驱动设计》（DDD）

等到我在 ICT 软件大会上去分享架构，或者在公司推广 Workorder 框架的时候，我的视角又变了。

以前我总盯着“这个接口怎么定义”、“那个表怎么设计”，后来啃了《领域驱动设计》（DDD），虽然书很难读，但道理很朴素：你的代码模型，必须得是现实业务的投影。

如果不理解业务，技术就是自嗨。

我也读了《架构整洁之道》，很有意思，它说 架构的本质其实是 “保留选择的权利”。什么意思呢？就是一个好的架构，能让你在还看不清未来的时候，不需要把所有决定都定死，能给未来留有余地。

这时候我才真正明白，技术是手段，业务价值才是归宿。 如果架构不能让大家干活更顺手，不能帮业务更快赚钱，那这架构就是失败的。这也是我从一名纯粹的 Coder 向技术管理者思维转变的关键期。

阶段四：从“码农”到“工程师”——引入时间的维度

核心书单： 《程序员修炼之道》、《Google 软件工程》、《代码大全》

到了现在，作为 SGM 回顾这五年，再读《Google 软件工程》，我才真正理解了 Programming（编程）和 Engineering（工程）的区别。

• 编程 是关于如何写出一段逻辑。
• 工程 是关于如何让这段逻辑在漫长的时间跨度里、在成百上千人的协作中，依然保持生命力。

《Google 软件工程》 中提出了一个振聋发聩的公式：软件工程 = 编程 + 时间。

编程是瞬间的动作，而工程是长期的承诺。我们需要考虑代码的可维护性、可测试性、团队的协作成本，甚至是技术栈的生态演进。这不仅需要技术深度，更需要广阔的视野和对人性的理解。《程序员修炼之道》里提到的“注重实效”，其实就是要求我们在有限的资源下，追求全局的最优解。

所以你看，哪怕是 Vibe Coding 时代，AI 能帮你写出逻辑，但它很难帮你去做那些关于“权衡”、“审美”和“人性”的决策。

做好每一件小事，在代码里，就是认真对待每一次提交，每一行注释。这不仅是对机器负责，更是对你的队友负责，对未来的自己负责。

2、实现与抽象：从“看山是山”到“看山是脉络”

如果是写 100 行代码，我认为坚持 Clean Code，去坚持有力的命名、注释，职责单一的函数，差不多就够了。那 1000 行代码呢？

面试的时候，如果我们问面向对象的特征，十个人里有九个会背书一样回答：“继承、封装、多态”。

这没错，但太浅了。在我看来，Coding 能力的分水岭，在于第四个词——抽象。

把现实世界的问题，抽象成代码世界里的问题；抽象是多个问题的共性解法，实现是某个问题的特定解法；抽象是软件设计的过程，实现是代码生产的过程。

很多同学写了好几年代码，依然停留在“翻译机”的水平：产品经理说“这里要加个红按钮”，他就写一行代码把按钮画红。他看到的是具体的“点”，而没有看到背后的“线”和“面”。

2.1 抽象是丢弃细节，抓住灵魂

为什么说 Coding 是模拟现实世界的过程？因为现实世界太复杂了，我们不可能把原子的运动都写进代码里。我们必须 舍弃。

案例：开发一个地图导航应用

• 现实世界：街道上有坑洼、路边有野花、那个红绿灯甚至有点掉漆。
• 抽象世界：无论路况多复杂，在算法眼里，它只是一个“节点（Node）”和一条“边（Edge）”。

这就是 抽象的本质——忽略无关的细节（实现），只保留解决问题所需的特征（抽象）。 如果你的代码里充斥着 if (city "Beijing" && street "Changan") 这种逻辑，说明你深陷在“实现”的泥潭里；如果你能把它抽象成 Graph.shortestPath(Node A, Node B)，你就拥有了上帝视角。

2.2 抽象是应对变化的护城河

我在做 Workorder 测试框架时，深刻体会到：实现是廉价的，抽象才是昂贵的。

案例：身份认证系统

• 实现（Implementation）：是告诉机器“怎么做”。比如“打开 Chrome 浏览器，输入网址，点击登录”。这很容易写，但也很容易挂——一旦浏览器升级或者按钮改名，代码就崩了。
• 抽象（Abstraction）：是告诉系统“做什么”。比如“执行身份认证”。

今天你是通过 Chrome 登录（实现 A），明天你可能通过 API 令牌登录（实现 B），后天可能通过指纹登录（实现 C）。如果你定义好了 Authenticator 这个抽象接口，无论具体的实现怎么变，上层的业务逻辑都不需要动。抽象，就是在变化的洪流中，寻找那个不变的锚点。

2.3 走出代码：团队文化中的“抽象”与“实现”

作为 SGM，我常思考一个问题：什么样的团队才是最健壮的？

如果是代码，我们知道写死所有逻辑（Hard-code）的系统最脆弱，充满多态和抽象的系统最健壮。团队管理亦是如此。

在团队建设中：

• 实现（Implementation）是“制度与KPI”。比如“早上9点必须打卡”、“代码注释率必须达到 30%”、“每周必须输出一篇技术博客”。
• 抽象（Abstraction）是“文化与价值观”。比如“工程师的工匠精神”、“为客户创造价值”、“不仅把事做完，要把事做好”。

痛点案例：如何提升团队的技术氛围？

很多技术团队都面临“氛围沉闷”的问题，大家只顾埋头搬砖，不关注技术成长。

• “实现”层面的管理（堆砌规则）： 为了解决这个问题，我制定了一条 KPI：“每人每月必须进行一次技术分享，否则扣绩效。” 这就是典型的“面向实现编程”。结果可想而知：大家为了凑指标，开始分享“怎么配置 Outlook 邮箱”、“Excel 快捷键大全”。规则（实现）是死的，人是活的，很容易被“绕过”。
• “抽象”层面的管理（重塑文化）： 后来我意识到，我需要设计一个“抽象接口”，而不是规定具体的执行路径。我不再强制要求分享，而是建立了一种“以此为荣”的文化抽象。
  1. 定义接口：我在团队里不断强化一个概念——“我们不是代码搬运工，我们是解决问题的工程师。”
  2. 运行时绑定：当有同学在代码里运用了一个巧妙的设计模式解决了难题，哪怕没做分享，我也在全员会上公开表彰；当有同学为了赶进度写了堆烂代码，哪怕他经常加班，我也在私下严肃指出这是“不专业”。

当“追求卓越”这个抽象被大家认同后，具体的实现便不再需要我规定。有的同学选择去重构旧代码，有的同学选择组织读书会，有的同学选择在 Code Review 时死磕细节。大家用不同的“实现方式”，共同实现了同一个“抽象接口”。

回到 Coding 的启示：

低级的管理是“控制”，就像面向过程的代码，充斥着指令和检查；

高级的管理是“共识”，就像面向对象的代码，定义好核心抽象（愿景），然后信任每个对象（成员）能用最适合自己的方式去实现它。

当你写下一行代码时，不妨停下来问自己：我现在是在堆砌砖块（实现），还是在设计蓝图（抽象）？我是只解决这一个问题，还是解决了这一类问题？

真正的技术大拿，不是那个能把键盘敲出火星的人，而是那个能从杂乱无章的业务需求中，抽离出简洁模型的人。Coding 的极致，就是用最少的抽象，覆盖最大的现实。

3、分而治之：对抗复杂度的头号武器

抽象能解决 1000 行代码的问题，在代码之上增加上层设计，那 1 万行、1 亿行代码呢？

软件开发的很大一部分难处来自于其复杂度，复杂到人脑难以一次性处理完。

学过算法的同学都熟悉分治思想，对应快速排序、归并排序等算法。其核心非常朴素：如果一个问题大到难以解决，就把它切碎，直到每一个小块都能被轻松搞定。

在软件 Mini 课程里，我常讲“任务分解”，其实就是分治思想的体现。我们把一个模糊的需求（比如“做一个电商系统”）拆解成子系统，再拆解成模块，最后拆解成一个个类和函数。软件开发的过程，本质上就是不断进行“分而治之”的过程。

当然在实际工程中，高明的分治，不仅仅是把大块切成小块，而是通过合理的“分离”，让系统在面对变化时依然稳如泰山。

以下是我在实战中体会最深的几种关键分离策略：

3.1 职责与边界的分离——模块化

这是分治思想在物理结构上的第一步，也是最基础的“收纳术”。

核心思想： 很多初级工程师习惯把代码写成一锅粥，所有的逻辑都堆在一个包、一个类甚至一个函数里。这种架构在软件工程中有一个著名的称呼——“大泥球”（Big Ball of Mud）。模块化的核心原则是高内聚（High Cohesion）与低耦合（Low Coupling）——我们将关系紧密的代码聚合在一起，形成坚固的堡垒；将关系疏远的代码隔离开来，减少不必要的纠缠。

案例：庞大的“网元适配层”

在早期的网管系统中，为了支持一款新设备，我们往往会写一个巨大的 NeService 类。它简直无所不能：既要负责建立 Telnet/SSH 连接（网络层），又要负责解析设备返回的命令行字符串（解析层），还要负责把这些数据转换成告警对象存入数据库（业务层）。

这就是典型的“大泥球”。一旦设备升级了固件，改了某条命令的返回格式，我们就得去改这个核心类，稍有不慎就把告警入库的逻辑给搞挂了。

分治策略： 我们按照关注点分离进行了模块化拆解：

• 南向适配模块（Southbound Adapter）：只负责底层的 Socket 通信和协议交互，不管业务。
• 命令解析模块（Parser）：只负责将生硬的命令行转化为结构化的 Java 对象。
• 业务处理模块（Business Logic）：只负责告警的过滤、压缩和入库，完全不感知设备是用 Telnet 还是 SNMP 连上来的。

拆解后，适配新设备变得像搭积木一样简单，再也不用在一个 5000 行的类里战战兢兢地改代码了。

3.2 抽象与实现的分离——你不需要知道电是怎么发的

如果说模块化是空间上的分离（把代码分家），那么抽象与实现的分离就是时间上的分离。实现是解决当下的问题，抽象是应对未来的变化。

核心思想： 调用者（Client）只依赖一个抽象的约定（Interface），而不依赖具体的干活细节（Implementation）。这就像你用插座充电，你只需要知道插座能供电（接口），完全不需要知道这电是火电、水电还是核电（实现），也不需要知道它是怎么传输过来的。

案例：Tomcat 与 Servlet

大家每天都在用 Tomcat，但你有没有想过：Tomcat 的开发者在写代码时，根本不知道你未来会在里面跑什么业务逻辑——是卖书、送外卖还是做社交？

同样的，你在写 HelloController 或 LoginServlet 时，也根本不需要去管 Tomcat 是怎么监听 8080 端口的，怎么解析 TCP 二进制流的，又是怎么把 HTTP 报文头拆解出来的。

分治策略： 这就归功于 Servlet 规范（Interface）。Java 定义了一套标准的接口（javax.servlet.Servlet），规定了 request 怎么进，response 怎么出。

• Tomcat（容器侧）：负责脏活累活，管理线程池、解析网络协议。它只认识 Servlet 接口，只管调用标准定义的 service() 方法。
• 我们（业务侧）：负责核心逻辑，继承 HttpServlet，重写 doGet/doPost。

正是因为这种彻底的分离，Tomcat 可以运行世界上任何遵循 Servlet 规范的 Web 应用，而你的 Web 应用也可以随时从 Tomcat 迁移到 Jetty 或 Undertow，而不需要修改哪怕一行核心代码。这就是“面向接口编程”的威力。

3.3 业务与技术的分离——保护你的“核心资产”

这是《架构整洁之道》和 DDD（领域驱动设计）的精髓。

核心思想： 业务逻辑是软件的灵魂（核心域），而数据库、缓存、Web 框架只是支撑业务的工具（基础设施）。永远不要让工具的细节污染了灵魂。

案例：纯净的领域模型

很多同学写代码习惯从设计数据库表开始，然后在 Java Bean 上打满 @Table、@Column 这样的注解，甚至在业务 Service 里直接处理 Redis 的连接异常。这导致一个后果：一旦我想换个数据库，或者把单体改成微服务，业务代码就得伤筋动骨。

分治策略： 在重构项目中，我强制要求 “领域模型（Domain Model）”纯净。业务对象里只有单纯的 Java 代码，没有任何数据库注解。存取数据时，通过一个“防腐层”（Repository 接口）去转化。这样，无论底层的技术栈怎么翻天覆地，核心的业务规则（比如“订单金额计算逻辑”）都稳如磐石。

3.4 数据与逻辑的分离——让代码变成“配置”

如果说面向对象（OOP）是把数据和逻辑封装在一起，那么在某些高复杂度的业务场景下，我们反而需要反其道而行之：把数据抽离出来，让逻辑变得通用。这也是函数式编程和规则引擎的核心理念。

核心思想： 硬编码（Hard Coding）是灵活性的天敌。当我们发现代码中充斥着大量的 if-else 或 switch-case，而且这些分支逻辑只是为了应对不同的参数组合时，就应该警惕了。这时候，我们应该把这些判断条件视为“数据”或“配置”，将其从代码中剥离，存入数据库、配置文件或规则文件。这样，当业务规则调整时，我们只需要改数据，而不需要改代码、重新编译和部署。

案例：复杂的“话费套餐计算”

在电信计费系统中，计算话费是一个噩梦。

• 全球通套餐：基本费 50 元，每分钟 0.2 元。

• 动感地带套餐：基本费 20 元，每分钟 0.15 元，但必须要叠加一个短信包。

• 校园卡套餐：寒暑假每分钟 0.1 元，平时 0.3 元，且仅限指定基站区域。

  如果我们用传统的 if (plan "Global") { ... } else if (plan "Campus") { ... } 来写，这个类会随着套餐的推陈出新无限膨胀，最后变成几万行的“天书”。

  分治策略： 我们构建了一个轻量级的“规则引擎”。

• 数据侧（规则配置）：将套餐规则抽象为公式和参数，存入数据库。例如：校园卡 = BaseFee + Duration * (IsHoliday ? 0.1 : 0.3)。

• 逻辑侧（计算引擎）：编写一个通用的表达式解析器。它根本不懂什么是“校园卡”，它只负责读取数据库里的公式，代入通话时长、日期等变量，计算出结果。

  通过这种分离，市场部想搞个新套餐，只需要在后台配几条数据，研发人员甚至不需要介入，系统就能自动支持。这就实现了“数据驱动开发”。

3.5 变与不变的分离——把“变化”关进笼子里

这是设计模式（如策略模式、模板方法模式）最喜欢干的事。

核心思想： 在一个系统中，有些流程是极其稳定的，而有些规则是天天变的。如果我们把它们搅在一起，每次改那个天天变的小规则，都有可能把那个稳定的主流程搞挂。

案例：电商结账流程

想象一个电商的结账流程：校验库存 -> 计算金额 -> 扣减库存 -> 生成订单。这个主流程（不变）通常很稳定。但是，“计算金额”里的打折规则（变）却五花八门：满减、第二件半价、VIP 折扣等等。

分治策略： 我们不要在主流程里写死 if (isVIP) ...。我们可以应用策略模式，把“计算金额”这个动作抽象出来，把各种打折规则封装成独立的“策略类”。

主流程只负责调用策略接口。这样，运营想搞个新活动，我们只用新增一个策略类（把变化隔离出去），完全不用担心会把“扣减库存”这么核心的逻辑给弄坏。

3.6 关注点的分离（AOP）——让专业的人做专业的事

有些事情很重要，但跟具体的业务没关系，比如打日志、做权限校验、监控性能。

核心思想： 不要让业务代码里充斥着这些“杂音”。如果你的业务函数里，有 80% 的代码都在 try-catch 打日志，只有 20% 在干正事，那就是关注点没分离好。

案例：臃肿的日志代码

在某个旧系统中，每个 Service 方法的入口都写了一行 Logger.info("enter method X")，出口又写一行 Logger.info("exit method X")，还要计算一下耗时。代码显得极其臃肿。

分治策略： 利用 AOP（面向切面编程）技术，将日志记录、性能监控这些“横切关注点”剥离出来，统一在一个地方处理。业务代码瞬间清爽了，只保留最核心的业务逻辑。

分而治之，听起来像是在切分代码，其实是在切分复杂度，是在切分责任。

无论是通过 SRP（单一职责原则） 管理空间复杂度，通过稳定依赖原则管理时间复杂度，还是通过 DDD 管理业务复杂度，其终极目标都是一个：让人脑能够在这个庞大而精密的逻辑宫殿中，始终保持清醒，一次只处理一件事。

当你下一次觉得代码写不下去了，或者脑子成了一团浆糊的时候，不妨停下来想一想：我是不是把太多东西混在一起了？能不能把它们拆开？

一旦你掌握了这把手术刀，你就会发现，再庞大的系统，也不过是由一个个清晰简单的小积木搭成的。

4、Trade off：允许不完美

如果说前面三节讲的是“如何把代码写好”，是在追求一种理想主义的完美；那么这一节，我们要聊聊“什么时候允许代码不完美”，这是在拥抱现实主义的灰度。

在软件工程里，没有绝对的“好”与“坏”，只有特定场景下的“合适”与“不合适”。作为团队主管，我的感受就是：技术决策往往不是在“好”与“坏”之间选择，而是在“糟糕”和“更糟糕”之间权衡。所谓工程，本质上就是在有限的资源（时间、算力、人力）约束下，寻找最优解的过程。

4.1 编码的 Trade off：警惕“过度设计”

刚学会设计模式那会儿，我特别容易陷入一种“手里拿着锤子，看什么都是钉子”的狂热。写一个简单的“Hello World”或者一个一次性的数据迁移脚本，我都恨不得搞个工厂模式，再加个观察者模式，还要把接口层、实现层分得清清楚楚。我觉得这叫“专业”，其实这叫“自嗨”。

在编码层面的 Trade off，核心原则是 YAGNI (You Ain't Gonna Need It) —— 你在这个阶段根本不需要它。

场景与权衡：

• 场景：这是一个核心业务的长期模块，还是一个明天就要下线的临时活动页？
• 权衡：如果是前者，请务必死磕 Clean Code，多花 3 小时设计是值得的；如果是后者，“快”就比“美”重要。用最简单的 if-else 把功能实现了，哪怕代码丑一点，也是对公司资源的节约。

记住：代码的复杂度必须与问题的复杂度相匹配。 用杀牛刀去杀鸡，不是刀法好，是眼神不好。

4.2 架构中的 Trade off：没有银弹

做架构设计时，最容易出现的争论就是：“单体好还是微服务好？” 、“Java 好还是 Go 好？”

这种争论通常没有结果，因为 脱离了业务场景（Context）谈架构，都是耍流氓。

<font color=blue<架构设计的本质是 “我们要牺牲什么，来换取什么”。</font<这不仅是 CAP 定律（一致性、可用性、分区容错性只能三选二），更是资源的博弈。

案例：网管系统 vs 看板工具

• 在做光产品线的网管系统早期时，因为部署在运营商内网，服务器资源受限，且对实时性要求极高。这时候，我们可能会牺牲“开发效率”（选用 C++ 而非 Java），牺牲“可读性”（极致压榨内存），来换取“高性能”。这是对的。
• 但在做部门内部的看板工具时，如果我们还搞这一套，那就是灾难。这时候，“开发效率”（Python/LowCode）和“可维护性”才是王道。

作为架构师，你的价值不在于你会多少种高大上的架构，而在于你敢拍板说：“在这个阶段，为了快速占领市场，我接受单体架构的笨重，我放弃微服务的灵活性。”

4.3 质量上的 Trade off：管理“技术债务”

提到“技术债务”，很多同学如临大敌，觉得它是绝对的坏东西。但如果有金融常识的同学就知道：合理的负债，是企业发展的杠杆。

在软件开发中，为了赶上“双十一”或者一个关键的交付节点（Time-to-Market），我们是可以允许暂时牺牲代码质量的。

两种债务的区别：

• “鲁莽的债务”：因为无知或懒惰，写出了烂代码，且不自知。这是毒药。
• “精明的债务”：为了赶进度，我有意写了一段耦合度高的代码，但我非常清楚它的风险，并在代码里打上了 // TODO，列入了下个版本的重构计划。这是杠杆。

在质量上做 Trade off，不是让你“破罐子破摔”，而是要 “有意识地妥协”。你可以允许代码不完美，但你必须做到：

1. 显性化：在代码和 backlog 中明确记录下这笔债。
2. 有还款计划：像还房贷一样，每个迭代都要安排人力去填坑，而不是只借不还，最后导致系统“破产”。

一名初级工程师，以写出完美代码为荣；一名高级工程师，知道何时该追求完美，何时该接受残缺。Trade-off 的能力，就是你在理想与现实的夹缝中，依然能带领团队把事做成的能力。

5、总结：功夫在诗外

洋洋洒洒写了这么多，从 Clean Code 谈到架构，从抽象谈到权衡。

其实我想说的很简单：Coding 不仅仅是敲键盘，它是一种思维方式，一种对秩序的追求，一种解决问题的艺术。

回到文章开头大家关心的那个问题：“AI 来了，我们还需要苦练 Coding 吗？”

我的答案是：正因为 AI 来了，我们才更需要去理解 Coding 的本质。（只我们要跳出将现实逻辑翻译成代码的牢笼，成为一个决策者，去思考怎么做，为什么这么做）

• AI 可以帮你在一秒钟内生成一段快排算法（实现），但它很难告诉你，在你的业务场景下，是该选快排还是归并，是该换取时间还是空间（Trade-off）；
• AI 可以帮你生成一个 CRUD 的接口（代码），但它很难帮你划定这个接口的业务边界，避免未来的熵增，建立起团队的通用语言（Abstraction）；
• AI 可以帮你把变量名改得规范，但它很难像你一样，在深夜看着一段刚刚重构完的清爽代码，感受到那种由衷的喜悦和职业尊严。

“失败不是成功之母”，“成功是成功之母。”

那些看似微不足道的“小事”——每一次你强迫自己把函数拆得更小，每一次你为了一个命名纠结十分钟，每一次你在面对烂代码时选择重构而不是绕过——它们都在一点点重塑你的大脑，积累你的工程直觉。

这些直觉，就是你职业生涯中坚不可摧的护城河。

不要因为觉得 Coding 是“搬砖”就轻视它，也不要因为做了管理者就远离它。做好每一件小事，愿我们都能在代码的字里行间，找到属于工程师的诗意。1219001803137515520