夜雨聆风大家好，我是飞哥。最近这段时间用 AI 写代码，我越来越明显地感觉到一个变化，以前我们总觉得程序员最核心的能力是把代码写出来，需求来了能不能快速落地，Bug 出了能不能马上修，接口不会写能不能自己查资料搞定，这些都是判断开发能力强不强的直接标准，但现在用 AI 用得越多，我反而发现，很多时候真正让我停下来的已经不是某一段代码怎么写，而是我到底有没有把问题想清楚、说清楚，以及给 AI 的上下文是否足够接近真实业务里的那一摊东西。
这个变化刚开始其实不太容易察觉，因为 AI Coding 最先给人的冲击一定是效率。一个接口几秒钟生成，一段重复逻辑直接补齐，一个单测文件很快写完，甚至一个不太熟悉的框架，只要把需求描述清楚，它也能先搭出一个差不多能跑的版本。刚开始用的时候确实会有一种爽感，因为过去很多需要查文档、翻博客、搜报错、反复试错的事情现在变得轻了很多，你会觉得自己一下子省掉了大量消耗，但用得越久，我越发现 AI 真正考验人的地方并不是生成代码，而是能不能控制它生成代码之前的方向。
前段时间我接到一个需求，本身不复杂，只是在一个老流程里加一段状态判断，这个流程跑了多年，代码看起来不算复杂，但里面有不少历史逻辑，很多地方一眼看过去会觉得绕。按照以前习惯，我会先把整个流程从入口过一遍，再翻历史提交记录，顺便问问之前接触过这个模块的人，那天我想试试看能不能让 AI 先帮分析，于是把相关文件、需求背景和大概理解的流程丢给它，让它先分析应该怎么改。它给出的方案看起来很像样，代码结构清楚，判断条件也补得比较完整，甚至顺手考虑了几个边界情况。第一眼看过去，我确实觉得这次应该能省不少时间，因为从代码实现角度，它没明显问题，甚至比预期还要规整。
但后来我习惯性把状态流转前后翻了一层，才发现它漏掉了一个特别关键的东西。那个状态不是普通状态，而是几年前为了兼容某个老业务留下的中间态，它在现在主流程里看起来没有太强存在感，测试数据也很难覆盖，但下游有一个同步服务一直默认依赖。如果按 AI 方案直接改，代码层面大概率能跑，测试环境也不报错，因为测试数据根本覆盖不到那些历史状态，可一旦上线，某些老数据可能被错误推进到下一个阶段。
看到这里我愣了一下，因为 AI 并不是不会写代码，它真正不知道的是这个系统当年为什么变成今天这样，它不知道这个状态为什么没有删掉，不知道某个看起来多余的判断其实是以前线上事故后留下的保守方案，也不知道有些字段和流程虽然没人管，但下游系统已经默认依赖多年。这些东西正是日常研发里最麻烦的部分。
很多人说 AI 需要上下文，但我觉得这句话说得太轻。很多人理解的上下文，可能只是把代码文件贴过去，把报错日志发过去，把需求描述复制一下让 AI 给方案，但真实业务里的上下文远远不只是这些，还包括需求为什么要做，哪些逻辑是历史兼容，哪些字段看起来能改但其实不能动，哪些接口虽然没人维护但还被调用，哪些异常不是 Bug，而是业务长期演化留下的结果，这些东西如果不说，AI 大概率不会知道。更麻烦的是，它不会因为不知道就停下来，它通常会继续生成一个看起来完整、很自信的答案，一个新人如果不确定，可能还会问一句这个字段能不能改，这个状态有没有下游，这个逻辑是不是历史遗留，但 AI 很多时候不会这样，它会基于你给出的局部信息直接推导出完整方案，如果自己没意识到上下文缺失，就很容易被这种完整感带走。
这也是我最近对 AI Coding 感受变化大的地方，以前我会更关心能不能写代码，现在更关心有没有把问题喂对。只要问题描述偏一点，漏掉关键前提，或者没有说明隐性约束，它生成越快可能偏得也越快。最可怕不是写错语法，少一个 if 判断，而是给了你一个看起来合理但放到真实业务会出问题的方案。
这也让我重新理解程序员能力。过去很多年，我们习惯用实现能力衡量一个人，会不会写接口、查日志、改 Bug、搭项目，把需求从零做到上线，都是成长指标，尤其刚入行那几年，很多人的成长就是靠不停写代码、修问题、踩坑、返工慢慢堆出来的。但 AI 出现后，我明显感觉能力权重往前移动，不是说写代码不重要，而是代码之前的东西变得更重要，你能不能先判断需求真正解决什么问题，能不能把关键上下文补齐，能不能知道哪些信息不能让 AI 猜，能不能在它给出方案后，看出哪些地方只是“代码正确”但业务可能错。
这个变化放在校招生和初级开发身上更明显，以前做项目慢虽然痛苦，但逼着人去理解细节，为什么表要这样设计，接口不能随意拆，权限逻辑不能写死，缓存一致性问题，需求小却牵一堆边界，很多能力不是教程学来的，而是在一次次写错、改错、推翻过程中慢慢长出来的。现在不一样了，AI 可以把很多过程压缩，一个项目几天跑起来，一个页面生成，一个接口完成，效率确实变高，但问题也来了：如果中间真正需要思考的环节被工具填满，最后可能只是看起来完整的项目，而不是属于自己的理解。
我不是说不好，事实上我每天大量使用 AI，而且越用越觉得它很难从开发流程拿掉。很多重复代码、方案草稿、文档整理、问题排查，AI 确实能省下大量时间，如果完全回到以前什么都靠自己查资料状态，我也会觉得不适应。但也正因为用得多，我才越来越感觉，AI 并没有让程序员不需要思考，反而把思考位置往前推。以前你可以先写再改，现在需要先想清楚再让 AI 执行；以前靠熟练度提高效率，现在靠表达和判断控制方向；以前怕不会写，现在更应该警惕自己还没想明白就拿到看起来完整答案。
这可能是 AI 时代程序员成长里一个微妙变化。代码生成越来越便宜，答案获取越来越容易，工具能力越来越强，但过去看似“不技术”的能力反而更重要，比如能否把复杂问题拆清楚，准确描述需求目标，判断哪些上下文必须补充，意识到方案上线可能出问题。这些能力过去也重要，只是藏在写代码过程，现在 AI 提前暴露出来了。
所以我越来越觉得，未来程序员之间差距可能不仅是会不会用 AI，也不仅是会不会写代码，而是面对模糊、复杂、信息不完整的问题时能不能先把它说清楚，因为只有问题说清楚，AI 才可能真正帮忙，否则它生成得越快，偏差也可能越大。以前觉得程序员要解决问题，但现在真正厉害的程序员可能首先要知道自己到底在解决什么问题。你们用 AI 写代码时，有没有遇到过代码看起来完整，但前面的问题根本没想清楚的情况？
以上，如果觉得不错，随手点个赞、关注、转发三连，这对我们特别有帮助，谢谢你看文章，我们下次再见。