AI 时代，我开始不再用「学会了什么技术」衡量自己的成长

这两年，AI 编程工具的发展速度，比我原本预想得快得多。

最开始，我用它们补全几行代码、解释报错，偶尔让它帮忙写个简单函数。后来，它已经能根据一段自然语言描述直接生成类、接口、数据库操作和页面，异常处理、日志、注释也能一起补上。再到现在，我经常会用自己并不熟悉的语言和框架去完成实际需求。

这在以前对我来说有点难以想象。

现在碰到一个陌生技术，我通常不会先花几天把教程从头学一遍。很多时候，我只需要先搞清楚几件事：这个东西能干什么，适不适合眼前的问题，输入输出是什么，有哪些不能碰的限制，以及最后应该得到什么结果。至于 API 怎么调用、样板代码怎么写、测试怎么补，完全可以先让 AI 去做。

我当然还是要看代码，也还是要调试。但整个顺序已经变了。

以前是「先掌握工具，再拿工具做事」。

现在越来越像「先知道自己要做什么，需要什么工具，再边做边补」。

甚至这篇文章本身，也使用了 AI 做整理、扩展和润色。

这件事给我的冲击，已经不只是「以后写代码会更快」这么简单。我开始怀疑以前那套衡量技术成长的方式，是不是正在慢慢失效。

过去回头看两三年的成长，很容易列出一张清单：新学了一门语言，多会了几个框架，接触了新的数据库，开始用 Linux、Docker，或者终于把某个 SDK 用熟了。

这些当然都算成长，但如果两年以后，我总结自己最大的进步仍然只是「C# 写得更熟了，又会了两个框架」，我现在会有一点不安。

因为 AI 正在迅速降低这类能力的获取成本。

所以我现在更愿意隔一两年问自己一次：

除了把原来的事情做得更熟练，我有没有获得一种新的、明显更难被替代的能力？

再具体一点就是：

两年前的我只能负责多大的问题，现在的我能不能接住一个更复杂、更模糊、跨更多领域的问题？

我觉得，这个问题可能比「今年又学会了什么技术」更值得长期追踪。

「掌握一门技术」正在从前置条件变成按需补充

以前想进入一个陌生领域，学习路径通常很完整。

想写前端，就从 HTML、CSS、JavaScript 开始，再往后学框架、构建工具、组件库。想写某种设备程序，就先啃 SDK 文档，看 Demo，把调用流程弄明白。不会一门语言，也得先把基本语法和标准库熟悉到一定程度，才敢真正开始写。

这种路径没有问题。过去它甚至是最合理的方式，因为掌握工具本身就是完成工作的前提。

现在情况有点不一样了。

我自己的博客就是一个很直接的例子。

我平时主要做 C#、工业视觉、运动控制和设备通信。前端我能看一点，HTML、JavaScript、CSS 不至于完全陌生，但肯定谈不上熟练。

以前如果我想改博客主题，比如在页脚插入备案信息、调整某块页面样式、增加版权协议、改留言板，或者在现有主题里加一块新的显示内容，我大概率会先去看主题结构，再打开浏览器开发者工具找 DOM，一点点试选择器和 JavaScript。

现在我基本不会从这里开始了。

我会先把主题允许的注入方式、现有页面结构、目标位置和我想要的效果告诉 AI。它先给出一份 HTML、CSS 或 JavaScript，我放进去跑；不对就把实际效果、控制台报错和新的限制继续丢回去，再改。

很多时候，我根本谈不上「学会了前端」，事情已经做完了。

这和真正的前端工程能力当然不是一回事。真让我从零设计一个大型 Web 应用，碰上复杂状态管理、构建系统、安全、性能和长期维护，我还是远不如长期做这一行的人。

但对于很多边界清楚的小需求，「完整掌握对应技术栈」已经不再是必须先跨过去的一道门槛。

以前经常是「我不会这个，所以做不了」。

现在更接近「我知道它大概能解决这个问题，也知道结果应该长什么样，那就可以先做」。

我觉得这才是 AI 编程真正改变我的地方之一。它没有让我突然精通更多语言，却明显扩大了我能碰的事情。

写代码正在变便宜，技术门槛也在一起变低

CRUD、配置文件、数据结构转换、接口封装、简单页面、重复业务逻辑、测试代码、日志代码，这些工作不会消失，但完成它们的成本已经和几年前不在一个量级。

以前遇到陌生问题，我的常规流程大概是搜索关键词、翻文档、看 GitHub Issue、找 Stack Overflow，再从几份差不多的答案里拼一份能跑的实现。

现在我通常先把上下文、报错、相关代码和限制一起交给 AI。

有时候它第一次给出的实现就能直接用。有问题的话，再把运行结果反馈回去。

以前半天才能推进的事情，现在可能十几分钟就做完。

这种效率提升当然很好，但它也带来一个很现实的问题：当某种能力的获取成本越来越低，它就很难继续单独构成长期竞争力。

所以我现在看到「精通某某语言」「熟练掌握某某框架」这种说法时，心态和以前已经不太一样了。

它们当然重要。语言熟练、框架熟悉、API 记得多，做事肯定会更顺手。

只是我不太愿意再把这些东西本身叫作「护城河」。

如果我的优势只是比别人更熟某个 API，那么 AI 最擅长做的事情之一，就是迅速把别人和我的这段信息差抹平。

技术深度没有失去价值，只是用途变了

这里很容易走到另一个极端。

既然 AI 会写代码，是不是以后就不用认真学语言、线程、内存、网络、数据库这些东西了？

我反而觉得不是。

我现在比以前更在意底层知识，只是学习它们的理由变了。

过去，技术深度很大程度上决定「你能不能把东西做出来」。

以后它可能越来越多地决定「AI 给你一个看起来很对的答案时，你能不能看出哪里不对」。

AI 写多线程代码没有任何困难。

但如果自己根本不懂线程池、锁、竞态、内存可见性和对象生命周期，那就很难判断一段代码到底只是「能跑」，还是在高负载和边界条件下也成立。

AI 也可以很快写出数据库访问代码。程序成功写入一条数据，并不能证明事务、一致性、索引、连接池和异常恢复没有问题。

设备 SDK 更是如此。

一段代码编译通过，函数调用顺序看着也合理，离「设备可以长期稳定运行」还差得很远。现场的通信时序、硬件状态、超时、无效值、设备断线、恢复方式，都不会因为代码长得漂亮就自动解决。

所以我不会得出「以后不用学基础」这种结论。

只是以前学习 API，多少会有一种「我要记住，以后自己写」的感觉；现在我更关注的是，它为什么这样工作，它依赖哪些条件，什么情况下会失败。

AI 可以替我记住很多东西。

但如果连判断依据都一起外包出去，那我最后只剩下一件事：相信它。

这对工程项目来说显然不够。

我现在不太喜欢再谈「程序员和软件工程师的区别」

我以前写过一种很常见的说法：

「程序员负责把需求变成代码，软件工程师负责解决问题。」

当时我觉得这个区分挺有道理。现在回头看，会觉得有点太方便了。

因为它很容易变成一种自我安慰：把 AI 已经很擅长的工作叫「程序员的工作」，再把 AI 暂时还做不好的部分统统装进「软件工程师」这个框里，最后得到一个舒服的结论，「AI 会压缩程序员，但不会真正取代软件工程师」。

问题是，AI 根本没有停在写代码这一步。

需求分析、代码审查、测试设计、架构讨论、日志分析、故障定位、方案比较，它都已经在做，而且还会继续进步。

今天我们觉得比较安全的那一层，两年以后未必还是同一回事。

所以我现在已经不太想问「到底哪些能力 AI 永远不会」。

这个问题大概率没有一个能用很多年的答案。

我更关心的是另一件事：

AI 的能力边界一直往外扩，我自己的能力边界有没有一起往外走？

以前 AI 只能帮我补一个函数，我就要能负责一个模块。

现在它能帮我写完整模块，我就应该把更多精力放到系统。

哪天它连系统设计都能做得很好，我就得把视野再往外扩，去理解业务、硬件、现场、交付、成本和最终目标。

这不是说人一定能永远跑在 AI 前面。我没有这么乐观，也没法证明。

只是如果自己的工作边界几年都没有变化，只是借助更强的工具把同一类事情做得越来越快，那种「成长」可能并没有看起来那么稳。

很多所谓的编程问题，最后发现根本不是编程问题

我之前中途接手过一个 VR 显示模组 AA 项目。

设备是双目结构，左右各有一套运动轴，两边需要按照相同的步骤工作。

原来的程序里，左右运动大致是类似这样的写法：

Task.Run(() => LeftAxis.Move());
Task.Run(() => RightAxis.Move());

从代码表面看很自然。

两个任务都扔进线程池，看起来就是「同时执行」。代码短，也没有明显的语法问题。

但真正跑到设备上以后，两边经常出现明显不同步。有时一边已经开始运动，另一边过一会儿才启动；更严重的时候，步骤本身也会出现异常。

原本期望的动作顺序是下面这样：

实际运行时，中间某一步可能没有按照预期完成。

在普通软件里，这种问题可能只是一个异常、一个错误结果，或者界面表现不对。放到运动设备上，后果可能就是机构撞击。

后来我重新调整了执行逻辑，问题没有再复现。

如果只看这个结果，很容易总结成「Task.Run 不靠谱，换独立线程就好了」。但现在再看，我觉得这个结论其实太浅，甚至可能误导别人。

Windows 的普通用户态线程本身也不是实时系统。换成 Thread，不等于突然获得了严格同步。

这个案例里更值得追问的是：两根轴的同步到底应该由谁保证？

如果设备真的要求高精度同步，上位机开两个线程分别调用两个 Move()，也许从一开始就不是最合适的设计。更应该确认运动控制器有没有多轴联动能力，SDK 的调用是否线程安全，指令队列是不是严格按顺序执行，运动完成信号靠不靠谱，状态机有没有在前一步尚未完成时提前往下走。

还要考虑一侧失败以后另一侧怎么办，软件互锁和硬件限位是否真的能兜住最坏情况。

一开始，我看到的问题是「怎样同时启动两个函数」。

后来才发现，真正需要解决的是「这套设备的同步应该由系统中的哪一层保证」。

这两个问题看起来只差一句话，层级完全不一样。

前一个问题很适合直接交给 AI。

后一个问题如果一开始就没意识到，AI 很可能只会认真地帮你把错误的问题做得更漂亮。

AI 很会回答，但项目现场往往没有现成的问题

现实项目很少像考试题。

通常不会有人把条件、边界、目标、风险全部整理好，再递给开发人员说：「好了，现在请作答。」

我们拿到的更多是一堆现象。

比如软件偶尔会卡住几十秒，UI 好像还能动，相机没有掉线，PLC 还在跑，日志里也没有特别明显的异常，但看门狗偏偏判断程序已经失去响应，然后把进程强制重启。

这时候如果直接问 AI「软件为什么卡」，它完全可以给出一长串可能性：UI 线程阻塞、死锁、第三方 DLL 卡住、通信超时、线程池饥饿、GDI+ 跨线程、GC、驱动异常……

这些答案大部分都不能说错。

问题是，列出可能性没有那么难。

难的是接下来先查什么。

应该在哪些位置补日志？要不要抓 Full Dump？Dump 该在什么时机抓？哪些线程最值得看？哪个异常只是伴随现象？哪条线索的区分度最高？软件查到什么程度以后应该开始怀疑驱动或者硬件？

调试真正有价值的地方，是让问题一步步收敛。

我现在更喜欢把这件事理解成一个循环：

AI 可以参与这个循环里的每一步。

它甚至可能比人更快地读日志、比较大量代码、整理候选原因。以后这方面只会更强。

但不管执行者是人还是 AI，一个故障最终能不能被解决，靠的都不是「谁能一下说中答案」，而是有没有办法用证据不断压缩错误空间。

所以比起「知道答案」，我现在更看重「知道怎么逼近答案」。

AI 把实现成本压下去以后，现实世界反而更显眼了

我主要做工业软件。

做得越久，我越觉得代码在整个系统里只占很薄的一层。

程序最后控制的是现实里的东西。

相机会真的丢帧，网络会真的抖，PLC 的数据会因为类型和字节序出问题，线程调度会带来时序差异，传感器会吐出无效值，运动轴会撞，第三方 DLL 也真的可能把整个进程直接带崩。

数据库偏偏可能在最不合适的时候写入失败。

这些事情还会互相影响。

拿一个高帧率工业视觉项目来说，表面需求可能只是「从相机拿图，送给算法检测」。

真正开始做以后，问题一下就多了。

相机采集速度和算法速度差多少？生产节拍允许多少延迟？算法跟不上时，是堆队列、阻塞采集还是直接丢帧？队列最多能攒多少张？连续跑十个小时以后内存会不会失控？UI 有没有必要显示每一帧？如果只是给操作员看，为什么不能降低显示频率？

再往后还有故障处理。算法 DLL 崩了以后整台设备怎么办？一件产品已经检测到一半，是继续、重试还是直接判废？数据库暂时写不进去，是停机还是先落本地缓存？程序重启之后，软件状态能不能和 PLC、相机、运动轴重新对上？

这些问题拆开看，都不算多么神秘。

最难的是它们同时存在。

AI 可以告诉我 BlockingCollection 怎么写，相机 SDK 怎么调，SQLite 怎么插入，线程怎么启动，异常怎么捕获。每一段局部实现都可以很快生成。

可是一个系统能不能在现场连续跑几个月，不取决于其中某一个 API 写得多漂亮。

它取决于大量局部选择叠在一起之后，系统还成不成立。

以前写一个功能本身就要花掉大量时间，很多精力会自然消耗在实现上。现在实现越来越便宜，原来被代码工作量挡住的那些系统问题，反而变得更显眼。

我觉得这是一件好事。

至少它逼着我把注意力从「这一段怎么写」往「整个东西为什么能工作」上移。

「会什么技术」已经越来越难描述一个人的能力

简历上当然还是要写技术栈。

C#、C++、SQL、Python、某个数据库、某个 UI 框架，这些信息能让别人快速知道你做过什么。

但如果是我自己评价自己，我已经不太喜欢靠这张清单了。

它很容易制造一种错觉：技术名词越多，能力就越强。

一个人完全可以每年学两个新框架，五年后简历写得密密麻麻。可真碰到一个陌生问题，还是只能等别人把需求拆干净，再负责实现。

另一个人也可能几年都在用差不多的技术栈，语言没怎么变，框架也没怎么换。

但他的工作已经从「需求给我，我写出来」，变成「给我一个现象，我去找原因」，再到「给我一个目标，我来设计整套方案」。

我觉得这两种成长不是一回事。

所以现在比起「又会了什么」，我更想看自己的问题尺度有没有变化。

以前只能安全地改一个函数，后来能负责一个模块；再后来可以接住一整套软件；继续往前，也许要同时理解软件、算法、设备、机械、流程和现场。

如果能力边界真的发生了这种变化，即使这两年没有多学几门语言，我也不会觉得自己停在原地。

反过来，如果只是把同一类工作越做越熟，速度越来越快，我现在反而会更警惕。

因为「把原来的事情做快」恰好是 AI 最擅长帮人完成的那部分。

比掌握某个工具更重要的，也许是迁移能力

技术变化得太快，是另一个绕不开的问题。

今天热门的框架，几年以后可能已经没人愿意碰。现在最好用的 AI 编程工具，两年之后大概率也会换一批。

如果职业安全感主要来自「我对某个具体工具比别人熟」，这种安全感会越来越脆。

我现在更在意的是，旧工具失去价值以后，我还能不能很快建立新的生产力。

遇到一个陌生系统，能不能尽快搞清楚它的边界；看到一项新技术，能不能判断它适不适合实际项目；自己缺知识的时候，能不能借 AI 很快补上；AI 给出答案以后，能不能发现它在哪些地方靠不住。

还有一点很重要：过去的经验能不能迁移。

比如今天突然让我去写一门以前没怎么用过的语言，我可能连标准库都不熟。

但如果我仍然理解数据怎么流、线程怎么协作、状态怎么维护、错误怎么传播、资源什么时候释放、系统应该怎样验证，那么很多经验都能重新映射过去。

语法可以问。

API 可以查。

框架可以边做边学。

真正不容易临时补出来的，往往是你怎么看一个问题。

那么「护城河」到底是什么

写到这里，似乎应该给出一个明确答案。

但我现在反而不太想这么做。

因为只要我们把某项能力明确宣布成「未来最安全的护城河」，过不了多久，很可能就会看到 AI 开始侵入这一层。

曾经有人觉得创造力最难自动化，后来生成式 AI 很快进入绘画、写作和音乐。

后来又有人说，真正安全的是编程逻辑、系统设计、调试、架构判断。

现在这些事情 AI 都已经开始做了。

我不觉得存在一个学会以后就能安心吃二十年的最终技能。

如果一定要给自己找一个相对长期的方向，我更愿意把它理解成一种持续移动的能力。

工具能帮我写函数，我就别把「会写函数」当成终点。

工具能帮我做模块，我就把注意力移到系统。

工具开始能分析系统，我就继续往业务、硬件、流程、成本和现实约束上看。

重点不是每次都比 AI 多会一点，而是别让自己的工作长期停留在同一个问题层级。

这大概也是我现在理解的「护城河」。

它不是某一门语言，也不是某一个框架，甚至未必是一项固定技能。

更像是当周围工具的能力不断上涨时，我还能不断把自己推到一个新的位置。

至于 AGI，我现在反而没那么想焦虑

聊 AI 职业影响，最后很容易聊到 AGI。

如果以后真的出现一种系统，可以低成本、稳定地完成绝大多数知识工作，那程序员怎么办？

我现在觉得，这个问题到了那一天反而没那么特殊。

因为真走到那个阶段，受影响的不可能只有程序员。

设计、会计、律师、分析、教育、研究、管理，大量依赖知识劳动获得收入的职业都会同时面对同一个问题。

那时候讨论的就不再只是「一个程序员还应该学什么」，而是工资劳动、企业组织、收入分配、社会保障甚至整个生产结构要怎么调整。

这种变化不是我现在多学一门 Rust 就能规避的。

所以相比反复预测 AGI 到底哪一年到，我更愿意处理已经发生的变化。

AI 已经在这里了。

那我现在有没有真正用它扩大自己的能力边界？

这个问题至少是我今天还能控制的。

我现在怎么给自己做「技术年检」

如果以后每隔一两年回头看一次，我可能不会再把「今年又学了几门语言、用了几个新框架」放在最前面。

我更想问自己这些事情：

两年前解决不了的问题，现在能不能解决？

以前必须等别人把需求讲清楚，现在能不能自己把模糊现象整理成一个可以验证的问题？

面对完全陌生的技术栈，我还能不能在短时间里建立足够的生产力？

AI 给出一个错误但很像正确答案的东西时，我有没有能力看出来？

我的工作是不是仍然主要停留在实现别人已经想好的东西？

还有最重要的一条：我现在能负责的问题，是不是比两年前更大、更模糊、约束更多，也更靠近真实世界？

如果这些事情在变好，即使过去两年没有新增多少「熟练掌握」的技术，我仍然会认为自己是在进步。

反过来，如果几年过去，只是同样的事情越来越熟练，原来一天做完，现在半天；原来一小时写两百行，现在借 AI 写两千行，我不会因为数字变大就自动觉得自己更有竞争力了。

效率当然重要。

但效率不是成长的全部。

写在最后

我以前很容易把技术成长理解成「会的东西越来越多」。

后来开始看重工程能力，觉得一个人应该从写代码走向解决问题。

现在再往前想一步，我觉得连「解决问题」这个说法都还可以继续追问。

解决什么规模的问题？

是谁定义的问题？

问题描述本身对不对？

结果怎么验证？

出错以后有没有办法收回来？

语言、框架、数据库、SDK，甚至 AI，本质上都是工具。工具会越来越强，也会一直换。

如果几年以后，我不再需要亲手写下项目里的大部分代码，我不觉得这件事本身有多可怕。

我更在意的是，到那个时候，我还能不能处理一些今天的自己处理不了的事情。

如果两年以后回头看，发现我只是代码写得更熟、提示词写得更顺、AI 用得更快，但负责的问题还是今天这些，那我大概不会认为自己有多大进步。

相反，如果那时我已经能接住更大的系统、更复杂的现场、更模糊的需求，哪怕其中绝大部分代码都不是我亲手写的，我也会觉得这两年没有白过。

对我来说，这可能才是 AI 时代更值得长期追踪的成长指标。