AI发展有一段时间了,各位程序员还记得曾经的手艺吗?

现在写一个接口，先让AI生成；遇到报错，把日志贴进去；要加功能，直接让它改一版。

代码确实写得更快了。可有时候，程序能跑起来，自己却说不清它为什么这样跑；线上出了问题，第一反应不是看调用链，而是继续问AI该怎么修。

AI发展已经有一段时间了。各位程序员，有没有偶尔想起自己曾经的手艺？

01 以前写得慢，但知道每一行在做什么

刚开始写代码时，一个小功能可能要查很久文档，改几个参数，还要自己构造输入去验证。

那时候没有现成的解释，遇到问题只能读报错、查源码、打日志、一步步缩小范围。慢是慢，但每解决一次，都会多知道一点系统的脾气。

现在AI可以很快给出一段看起来完整的代码。它适合处理模板、样板和熟悉的实现，但“看起来合理”不等于“在当前系统里正确”。依赖版本、数据边界、并发场景、权限设计，都可能藏在几行漂亮代码后面。

代码生成节省的是敲键盘的时间，理解系统才决定最后交付的质量。

02 调试能力，正在变成更稀缺的基本功

AI可以根据错误信息列出一堆可能原因，却不能替你判断哪个原因最接近现场；它可以建议改配置，却不知道这项配置会不会影响另一个服务。

真正的排错，仍然要从现象开始：什么时候发生，哪些请求受影响，最近改过什么，能不能稳定复现，日志和指标是否互相印证。

这些动作看上去不新鲜，却是程序员把“猜”变成“证据”的过程。AI可以陪你列假设，但你要负责验证假设。

如果一个人离开AI就不会定位问题，他拥有的可能只是工具熟练度，还没有形成自己的诊断能力。

03 重新练习把需求拆成可验证的问题

以前写代码，很多时间花在设计数据结构、拆分模块、想清楚异常情况。现在AI能迅速生成方案，更容易让人跳过这些步骤，直接进入修改代码的阶段。

但需求没有变清楚，代码只会变得更多。一个“做个导出功能”，里面可能包含权限、分页、超时、文件大小、失败重试和审计记录。问题拆得越细，AI越能帮上忙；验收标准越明确，返工越少。

程序员需要重新练习的，是把模糊的业务话说成清楚的技术问题，再把技术方案说回业务能理解的话。

会提问、会取舍、会定义完成标准，比会复制一段代码更接近工程能力。

04 有些手艺，应该交给AI；有些不能丢

重复的脚手架、格式转换、测试样例、文档初稿，可以放心让AI先做。写完以后检查边界，补上测试，确认依赖和安全风险，再合并进项目。

架构取舍、数据权限、线上故障、重要重构和对外承诺，需要程序员自己理解并承担。AI可以提供多个选项，却不能替你决定哪种方案适合当前团队，也不能替你在事故复盘会上解释为什么这么做。

所谓“手艺”，不只是手写代码的速度。它包括读代码、查问题、做实验、写测试、控制复杂度，以及在不确定的时候知道该停下来确认。

AI越强，越应该把这些基本功重新捡起来。因为未来的程序员，可能不再靠写出最多代码证明价值，而是靠更快看懂系统、更早发现风险、更稳地把需求变成可以长期运行的产品。

如果你也是程序员，今天可以打开一个熟悉的旧项目：不问AI，先自己画一遍调用链，找一个曾经修过的bug，重新写下它的复现条件和真正原因。

工具可以替你写下一段代码，手艺让你知道这段代码该不该存在。

你最想捡回哪项编程基本功？欢迎留言聊聊，也把这篇转给还在和AI一起写代码的同行。