谢邀，研发工作的变化，我觉得最大的变化就是从重「实现」，变为重「设计」了，从「写代码」，变为「教AI写代码」，而且要把它当一个有「实习生业务思维」的「高级研发工程师」。

之前在接研发需求的时候，大部分时间可能花在具体实现上面：调试API、写业务逻辑、处理边界情况，现在的AI工具在代码的具体实现上其实已经很强很成熟了，比如GitHub Copilot、Cursor之类的工具，使用比较强的大模型的代码能力其实已经超过了很多初中级的开发者了。

从「写代码」过渡到「写需求」

但是如何让AI工具「写自己需要的代码」，这个反而变成更不容易更重要的事情。
AI 不是人类，它是不知道你的「文字」以外项目背景、业务逻辑、历史遗留问题，有时候为了让AI理解一些需求，需要花很久来梳理「这个功能到底是干什么」，可能对理解需求还有帮助。
能生成代码，但不一定是「最优解」，所以有一些提前的架构设计工作还是需要自己来，比如用什么技术栈、代码复杂度的上限、性能和可读性的平衡点。毕竟有时候AI会写出很多能跑但不能维护、可读性不怎么好的代码。这些其实就是架构设计的工作，之前是设计完自己实现，现在是设计好了让AI写。

AI无法替代

还有一些AI无法替代的东西，比如理解模糊的业务需求，产品经理说的话，AI听不懂、处理老项目的坑AI理解不了、设计多个跨系统的服务改动，AI对依赖关系还是不能理解的很透彻。所以需要我这个人类来做这个翻译传声筒。

写作文

现在做一个产品、需求，提示词写的文字数量可能比代码要多得多，每次我都调侃是，做一个需求，就写一篇作文、做一个需求，就写一篇作文，等产品上线了，把我的提示词整理整理，基本就是一个完整的文档了。以前写代码的时候，需求紧了文档不重视，现在为让AI干活不得把这些东西写的明明白白，这反而是个好事儿：代码可能会过时，但好的文档一直有价值。
2025年的编程工作，已经从「how to code」变成「what to code」，AI解决了实现问题，但是其他的更上游的工作变的更重要，现在的日常就是，先做设计（写提示词），接着review AI 写的代码，最后再整体审视项目需求完成情况收尾。虽然代码量少了但是脑力劳动强度一点没降低。

本文为参加知乎活动撰写：AI 编程工具在 2025 年对程序员的工作流产生了怎样的重构？