写代码的人越来越多，但程序员定义越来越窄：AI时代的代码重构

前几天在一个技术社群里看到有人抛出这个问题：“现在有多少人在写代码？”评论区瞬间吵翻了。有人觉得遍地都是程序员，随便一个培训出来就能写；有人说真正的开发者其实很少，大部分人在用AI“拼”代码，根本不算写代码。

有意思的是，我顺手翻了翻近期的热搜词，“写代码”相关的搜索几乎全被这类内容占据了：怎么用AI写代码、Codex能写什么、Qwen Code好不好用、VSCode写C为什么没有代码提示、嵌入式开发全靠AI写代码行不行……大家关心的已经不是“该不该学写代码”，而是“今天的人到底怎么在写代码”。

所以这个问题背后真正值得聊的东西，其实不是某个具体数字，而是“写代码”这件事本身正在被重新定义。我想借这篇文章，把这些变化拆开讲清楚，顺便聊聊我对“还有多少人真的在写代码”这件事的判断。

1. 先搞清楚一件事：什么才叫“在写代码”

1.1 程序员真的在“写”代码吗

我见过很多刚入行的朋友，觉得写代码就是坐在那里噼里啪啦敲键盘，像写作文一样，一个字一个字把它们敲出来。这个画面放到十年前基本没错，但放到今天就非常失真了。

现在的开发工作里，真正的“敲键盘”时间占比其实很低。我自己的日常大约是：看需求文档和讨论设计占三成，读以前的代码和排查问题占三成，写新代码只占两成，剩下两成在处理联调、部署、改bug和各种沟通。真正落到“手指在键盘上产生字符”这个动作上的时间，其实非常有限。

而且所谓“写代码”这件事，在不同人手里完全不是同一个动作。对底层基础设施的开发者来说，写代码是在精心设计内存布局和并发模型；对业务开发来说，写代码更像是用代码在“拼积木”，调用现成的框架和接口；对算法工程师来说，写代码是把数学公式翻译成程序和数据的流水线；对运维或SRE来说，写代码是在编写自动化脚本和基础设施即代码。

有人可能会说，只有从头到尾把逻辑一行行敲出来才算写代码，调用现成的东西不算。这个看法我不太认同。就像写文章，引用别人的观点和研究成果也是写作的一部分，关键是最终你组织出来的东西能否解决你的问题。写代码的本质从来不是“敲击键盘产生字符”，而是“用代码表达你的意图，让计算机按你的想法运行”。

1.2 热搜里藏着的“写代码”定义变化

近年来围绕“写代码”的热搜词特别能说明问题。比如有一个词是“vscode写c没有代码提示”，这是典型的IDE配置问题；还有一个是“figma 将设计图转给ai写前端代码”，这是设计稿直接到代码的工作流；“小程序云开发是不是不用写后端代码”，这代表着后端逻辑被云服务封装后的开发方式；“产品经理如何指导程序员写代码”，这更是直接把产品经理拉进了代码开发环节。

这些热搜词反映出一个共同趋势：“写代码”的门槛正在快速下移。以前写代码是程序员的专属技能，你需要掌握编程语言、算法、数据结构、操作系统、网络、数据库一大堆知识。现在的情况是：设计稿可以直接转代码，云开发把后端搭建封装成白屏配置，AI工具只需要你用自然语言描述需求就能生成代码，甚至连产品经理都在研究怎样才能更好地和程序员配合。

在这种背景下，单纯用“全职程序员数量”来回答“有多少人在写代码”，显然是不完整的。因为会写代码、在写代码、靠写代码吃饭、用代码辅助自己工作，这四类人的规模完全不同，而且都在增长。

2. 求一个数：全球写代码的人到底有多少

2.1 用几个公开数据拼一个大概轮廓

要回答“有多少人在写代码”，网上确实有各种统计口径，但大部分都不统一。我这里用几个相对公开、口径比较明确的参照物，帮大家拼一个轮廓。

第一个参照物是全球最大的开源托管平台GitHub的用户数。根据GitHub自己公布的官方数据，其全球用户总数已经超过1亿。这1亿用户里，有大量是高校学生、研究者、开源爱好者、非技术背景但会上传配置和文档的人，不能全部算入“开发者”。但哪怕是其中只有一半人真正写过代码，那也是几千万人的量级。

第二个参照物是Stack Overflow的年度开发者调查。这份调查覆盖了全球数万名开发者，近几年的数据里有个有趣的现象：受访者中接近三分之二的人已经在日常开发中使用AI编程工具。这说明“写代码的人”里已经有很大比例的人同时是“用AI写代码的人”。

第三个参照物是Gartner这类咨询机构的预测数据。它们曾给出过“到2025年全球将有一半以上低代码平台的用户来自业务部门而非IT部门”之类的判断。如果这个趋势成立，那么借助低代码平台“顺手写一点逻辑”的非专业开发者数量，会远远超过职业程序员的数量。

把这些数据拼在一起，我的体感判断是：职业程序员（靠写代码吃饭的人）全球大概在3000万到5000万之间；如果算上经常写代码的数据分析师、运维、测试开发、自动化脚本作者，以及用低代码平台搭建应用的业务人员，这个数字至少要翻几倍；再把学生、兴趣爱好者、偶尔写个小脚本就收工的人算进去，全球“正在或偶尔写代码”的人，说有几亿人都不夸张。

2.2 这个数字本身其实没那么重要

但说实话，“到底有多少人”这个精确数字，在今天已经没那么重要了。真正重要的是人群结构的变化。

十年前，写代码的人群基本呈“金字塔形”：底座是庞大的学习者，上面是数量不多的程序员，最顶端是少部分架构师和研究员。今天这个结构正在变得像“三叶草”：一片叶子是职业开发者，他们依然深度参与系统设计、架构演进和核心代码编写；一片叶子是准开发者和跨领域写代码的人，像数据分析师、运维工程师、产品经理、科研人员，他们写代码是为了解决自己的工作问题；还有一片叶子是非技术岗位但借助AI和低代码工具实现“思路表达”的人，他们不一定懂得变量作用域和生命周期，但能折腾出可运行的程序。

所以“有多少人在写代码”这个问题，更准确的回答方式是：如果你指职业程序员，那还是千万级；如果你指所有通过代码表达逻辑的人，那数量已经可以按亿计了，而且还在快速增长。数据本身不一定精确，但这个趋势方向是明确的。

3. AI成了“合著者”：从热搜里看今天怎么写代码

3.1 几乎所有写代码的场景都被AI渗透了

关于“AI写代码”的热搜词我在前面已经提了不少。这里我想把它们归类，因为这恰好能反映AI在写代码这件事里渗透的深度。

第一类是“AI写代码工具好不好用”的讨论，比如“codex写代码”“学习如何利用ai写代码qwen code”“写代码好用的ai”。第二类是“AI编程工具的选型对比”，比如“对于写代码deepseek v4 flash 和kimi-2.7code哪个会更好”。第三类是“AI如何结合具体场景落地”，比如“嵌入式全靠ai写代码”“figma 将设计图转给ai写前端代码”。第四类是“AI时代下角色与流程的变化”，比如“产品经理如何指导程序员写代码”。

从这些分类你就能看出来，AI写代码已经不是少数极客的玩具了，它正在变成所有开发者日常工作中绕不开的话题。

我对这件事的态度是：AI写代码确实有效，但它更像是给程序员配了一个反应极快、知识面极广的“合著者”，而不是可以完全甩锅的“代写枪手”。你仍然需要知道自己要什么，仍然需要能读得懂AI生成的东西，仍然需要对运行结果负责。

3.2 选型角度：不同AI写代码工具怎么挑

既然热搜词里大家对工具选型感兴趣，我就分享一点我自己的选型思路，不具体点名说“谁最强”，因为工具更新换代太快，说死了没意义，但选择框架是稳定的。

看任务类型。如果你主要是写前端界面，那么能把设计稿（比如Figma设计图）转成代码的工具效率最高，可以把设计师到前端开发之间那段翻译工作交给AI做。如果你做的是后端业务逻辑，那么代码补全类和对话生成类工具都能帮上忙，关键看它对主流框架和语言的理解深度。如果你是做嵌入式开发，ASM、C语言、寄存器操作这些偏底层的内容，生成式AI的“幻觉”风险会更高，你必须对硬件细节有判断力，不能盲信生成结果。

看上下文长度和处理能力。当前主流AI编程工具基本都支持大上下文，能一次性处理很多文件。这一点在“改一个跨多文件的功能”时特别重要——如果AI看不到相关文件，它给出的建议就很容易跑偏。

看代码审查和纠错能力。好的AI写代码工具不应该只是“生成一段代码就结束”，还应该能指出你已有代码的问题、解释为什么报错、给出重构建议。这些能力在实际开发中比“生成”更值钱。

看隐私和部署方式。有些企业代码是不能随便送到外部服务的，那就要关注是不是支持本地私有化部署。个人开发者则更关心免费额度和性价比。

说实话，今天的AI编程工具已经不能简单比“谁写得快”了，因为它们生成的代码质量在伯仲之间，真正拉开差距的是对项目上下文的理解深度、对错误信息的解读能力，以及和开发工具链（IDE、CI/CD、调试器）的集成程度。选型时多从这几个维度打分，基本不会踩大坑。

3.3 我的工作流里AI承担了什么

拿我自己的实际工作举例。我平时写业务代码和脚本比较多，AI在我这里的角色大概是这样的：

第一，需求翻译器。把模糊的需求描述变成初步的代码骨架，比如“给我写一个从S3拉取文件并解析CSV的Python脚本”，它能在十几秒内给你一版能跑的程序。虽然离生产还有一些距离，但比从空文件开始写要快得多。

第二，快速上下文切换器。我经常需要在不同语言、不同项目间切换，从Go切到Python再切到TypeScript。以前每次切换都需要回忆语法和标准库，现在直接问AI就能拿到准确的用法，省掉了不少查阅时间。

第三，Bug排查的预筛器。遇到报错信息时，先把报错丢给AI，它能快速指出常见原因和排查方向。相当于一个不会累的调试伙伴，能帮我缩小问题范围，然后我再深入定位。

但有一件事我始终坚持：AI生成的关键业务代码，我一定会自己完整读一遍，理解每行的意图后再提交。这不是不信任AI，而是因为生产环境的bug成本太高，你不可能让一个模型来为线上事故负责。这个责任最终还是要落在开发者自己身上。

4. 细看热搜里的典型困境：IDE、单片机与前端设计图

4.1 VSCode写C没有代码提示：一张排查清单就能搞定

热搜词里有个很典型的问题：“vscode写c没有代码提示”。这个问题几乎每周都会有人问，因为它涉及好几个容易踩坑的环节。

先说你需要准备什么：VSCode本质上是一个编辑器，它本身并没有内置完整的C语言智能感知能力，你需要安装C/C++扩展（由微软官方出品），再加上配置编译器路径和头文件路径。很多人的问题是只装了编辑器，根本没装扩展，那自然没有代码提示。

按这个顺序排查，基本能解决九成问题。

第一步，确认C/C++扩展已安装并启用。我见过不少人装了好几个不同版本的C/C++扩展，结果互相冲突，代码提示反而失效。

第二步，确认编译器已安装且能被VSCode识别。Windows上如果是MinGW-w64，需要把gcc的bin目录加到系统PATH里；macOS上通常是装了Xcode Command Line Tools；Linux上一般是gcc或clang直接可用。你可以在终端做一个小检查，输入gcc --version，看能不能正常输出版本。这一步是很多人忽略的。

第三步，配置includePath。C语言的代码提示依赖头文件搜索路径。如果你的项目里用了第三方库，需要在c_cpp_properties.json里把第三方库的头文件目录加进去。很多初学者配置到第二步就开始用，一旦包含自定义头文件，VSCode的IntelliSense就会变“哑巴”，只能提示系统自带的标准库。这个文件可以在命令面板里搜索“C/C++: Edit Configurations (UI)”来生成，图形界面里直接添加路径即可。

第四步，理解IntelliSense引擎和编译器的区别。VSCode的代码提示用的是IntelliSense引擎，它可能和gcc解释宏的方式存在差异。遇到“代码提示和实际编译结果不一致”这种诡异问题时，优先检查是否有宏定义影响了头文件的展开，例如#define ENABLE_XXX之后，某些函数的声明才会出现。

第五步，检查工作区相关的缓存问题。如果上面都做对了还是没提示，试试重启VSCode，或者执行“C/C++: Reset IntelliSense Database”。这个操作能解决很多“改了配置没生效”的疑难杂症。

4.2 Eclipse创建Java程序后，怎么写代码才规范

“eclipse创建java程序后，怎么写代码”这条热搜，一看就是初学者问的。我理解这些朋友的困惑：Eclipse创建项目时产生了大量文件，像迷宫一样让人无从下手。

其实逻辑很简单。第一步在Eclipse里新建一个Java项目时，它会自动生成src目录（源码目录）和JRE系统库等条目。真正要你动手的地方是src目录下面。右键src，新建包（Package），包名一般用公司域名倒置，例如com.example.demo；在包下再新建类（Class），勾选public static void main(String[] args)，然后代码就写在这个main方法里。

很多人在这一步会犯的一个错误是：不建包，直接在默认包下写类。如果你的项目只是几行代码测试，这么干问题不大；但一旦类多了，不建包会导致类名冲突，而且项目结构非常混乱，后面扩展会越来越痛苦。所以我建议哪怕只是练习，也要养成建包的习惯。

接着讲Eclipse里比较实用的一点：Eclipse的快捷键和自动修复能省很多事。比如在代码里输入syso再按Alt+/，能自动展开成System.out.println()；看到一个红叉报错时，选中错误代码按Ctrl+1，它会弹出一堆修复建议，自动导包、自动生成方法、自动修改变量名，这些功能对新手来说非常友好。

还有就是，Eclipse的“代码提示”默认触发键是输入点号“.”才出现成员提示。如果你觉得提示太弱，可以在Windows - Preferences - Java - Editor - Content Assist里，把Auto Activation Triggers改成abcd等字符串，这样输入任意字母都能触发候选提示。这条我当年也是摸索很久才发现的，对新手很实用。

4.3 ESP32的C语言开发环境：别让环境搭建劝退你

热搜里还有一条“vs + esp-idf怎么搭建写esp32 wrover module的代码”。我猜这位朋友想在VSCode里开发ESP32，但被ESP-IDF的环境搭建折腾得够呛。ESP32的环境搭建确实是个容易让人劝退的环节，我简单说一下关键点。

ESP-IDF是乐鑫官方提供的物联网开发框架，它跟普通的Arduino那种开箱即用的环境不太一样，自带了一套工具链、Python环境、编译系统。装起来不难，但容易卡在网络下载和路径上。

比较顺滑的步骤是：先在VSCode里安装Espressif IDF插件，它会引导你下载ESP-IDF工具链，这时候建议选择“Express”模式，它会自动把IDF、编译器、调试器都装好。安装过程中如果有文件下载失败，可以设置IDF镜像地址或重试几次，网络问题占了安装失败原因的大头。

完成之后，用“ESP-IDF: Show Examples Projects”可以创建一个示例工程。写代码的逻辑并不复杂：真正的项目里，最关键的函数是app_main()，它就相当于ESP32程序的入口，类似C语言的main函数。你在这个函数里调用esp_wifi、esp_event、driver/gpio这些API函数去控制外设和网络，编译后下载到板子里就能跑了。

这里我特别想提醒做嵌入式开发的朋友：AI生成嵌入式代码确实能用，但一定要谨慎。和Web开发不同，嵌入式代码涉及寄存器配置、时钟树、外设时序、电源管理，这些内容AI偶尔会生成看似合理但实际错误的代码。比如它可能把某个寄存器的位域写得很好看，但跟你的芯片型号或板级配置不匹配，编译不通还算好，万一编译通过但运行行为异常，排查成本会很高。所以嵌入式场景下，AI可以作为文档查阅和参考代码的助手，但每一行关键配置代码都要对寄存器手册验证。

4.4 Figma设计稿转前端代码：能提效，但不能无脑用

再聊聊“figma 将设计图转给ai写前端代码”这条。设计稿直接生成前端代码这件事，确实已经能用了，但它的适用范围和边界你得清楚。

目前比较成熟的模式是：在Figma里给图层命名清晰，然后通过AI插件或平台生成的代码，往往能得到结构还不错的HTML/CSS，甚至React组件代码。这能大幅减少“照着设计稿抠样式”的时间。但这里有个前提：设计稿本身要规范。如果设计师的图层命名是“矩形 13784”“组 23665”这种默认名字，AI生成的代码结构基本没法直接用。

建议是：让设计师在切图前养成给关键图层命名的习惯。同时，生成的代码通常是静态样式的还原，像交互逻辑、事件绑定、状态管理这些还是需要前端开发者自己来，AI只能帮你完成视觉层的还原。如果你要对齐设计稿做像素级还原，这一步可以帮大忙；但如果项目有复杂的响应式布局、交互状态、无障碍要求，生成结果往往只能当起点，不能拿来即用。

5. “不写代码”的写代码者：低代码、云开发与新角色分工

5.1 小程序云开发：“不用写后端代码”是真的吗

热搜里那条“小程序云开发是不是不用写后端代码”很有意思，因为它切中了一个很普遍的认知误区。

小程序云开发这个概念，确实把后端的大部分工作做了封装。传统的小程序开发，你需要自己搭建服务器、写后端接口、维护数据库、处理鉴权、做运维。云开发直接提供了云函数、云数据库、云存储、身份认证这些能力，你可以在不买服务器的情况下完成很多业务逻辑。

但这不意味着“完全不用写代码”。云函数本身仍然需要你写一个函数（通常是Node.js或JavaScript），里面照样有业务逻辑和数据库操作。差别在于你不需要关心这个函数跑在哪台服务器上，不需要自己配置Nginx、负载均衡、监控告警，你只管写业务。所以“不用写后端代码”的真实含义是“不用写后端基础设施和服务器运维相关的代码”，而不是“完全没有代码要写”。

这个模式特别适合两类人：一类是独立开发者，想快速验证一个想法，用云开发能省掉大量基建时间；另一类是前端开发者，想做全栈但后端经验不多，云函数的写法基本也用JavaScript，学习成本很低。如果你问我的建议，我会说：如果你的项目复杂度不高、没有特殊的合规或性能要求，云开发是个非常高效的方案；但如果你的业务涉及复杂的分布式事务、大量的自定义中间件、细致的权限模型，那我还是建议老老实实评估自建后端。

5.2 产品经理要不要学会“指导”程序员写代码

“产品经理如何指导程序员写代码”这条热搜反映出一种新的职场现象：非技术背景的角色开始接触开发过程。

我对“指导”这个词其实有点保留。更准确的说法是，今天的产品经理应该学会“更精确地描述需求”，而不是真的教程序员怎么写代码。借助AI时代的能力，产品经理可以更清楚地理解技术实现的上限和下限，从而把需求定义得更可执行。

我见过一些做得好的产品经理，他们会这样做：在提需求时直接附上一段“伪代码”式的流程图、规则表和异常分支说明，把业务逻辑描述得像代码一样严谨。比如一个优惠券需求，他们会写清楚“什么条件下可用、什么条件下不可用、和满减的优先级如何、退款后优惠券怎么处理”。这种清晰度比单纯写一段自然语言描述高效太多。好的产品经理不是去指导程序员写代码，而是把“要解决什么问题”和“边界条件有哪些”讲得清清楚楚，剩下的实现交给程序员和AI去解决。

5.3 低代码与无代码：业务人员的“外挂”

再往更远一步看，低代码和无代码平台真正改变的是“会写代码的人”的定义。以前业务人员发现系统缺个报表，需要给IT提需求排期等一个月；现在他们可以在低代码平台上拖拽组件，自己搭一个可视化页面，甚至配置简单的触发规则。你说他“写代码”了吗？从技术角度说没有，但效果上他实现了一个原本需要开发人员介入的功能。

这不是坏事。把“会不会编程语言”和“能不能编程”解耦，是未来最大的生产力释放点之一。低代码平台的本质是把常用能力封装成可配置的组件，把使用者从语法细节里解放出来，让他们更聚焦在业务逻辑本身。

但我也想说一个反向观察：低代码平台确实降低了入门门槛，可它并不能完全替代传统代码开发的灵活性和持久性。遇到平台没有封装的能力，你还是要写自定义代码或插件；遇到平台升级带来的兼容性问题，你依然需要懂底层原理才能排查。所以我认为未来的“写代码人群”不是被低代码取代，而是分层更明显：业务人员用低代码解决大部分标准化需求，专业开发者处理高复杂度自定义场景，AI则在这两层之间充当翻译和加速器。

6. 写代码这件事，未来三年的三个判断

6.1 判断一：写代码的人会越来越多，但“程序员”的定义会更窄

以前我认为，写代码是个门槛很高的技能，需要系统学习很长时间。但看到AI生成代码和低代码平台的发展之后，我的判断变了：未来能“折腾出程序”的人会越来越多，就像现在会用Excel的人几乎人人都会做数据透视表一样。

但硬币的另一面是，“程序员”这个职业身份反而会更窄。当AI能处理大部分常规编码工作时，企业需要的程序员不再是“能把代码敲出来”的人，而是能设计系统架构、能评估技术风险、能在模糊需求中找出最优解的人。表达能力、系统思维、工程判断力，这些无法被AI替代的能力会变得更加珍贵。

6.2 判断二：写代码的能力重心从“写”转向“审”

我自己这几年最大的感受是：我在“审查代码”上花的时间，已经明显超过了“写代码”的时间。AI生成的代码越来越多，我的工作变成了阅读它、理解它、判断它是否符合业务预期、是否安全、是否高效，然后调整它。

这个过程有点像编辑和作者的关系。未来写代码的人，核心能力可能不再是“从零创作”，而是“快速理解与准确修改”。这也解释了为什么热搜词里会有那么多人问“AI生成代码的思路怎么写”之类的问题——因为他们已经发现自己不缺“代码生成”，缺的是“生成前的思路组织”和“生成后的判断能力”。

6.3 判断三：工具会变，但解决问题的底层逻辑不会变

从VSCode的配置问题，到ESP-IDF的环境搭建，再到AI写代码工具的选型，我发现大家遇到的困难从来不是“某个具体工具不好用”，而是“工具变化太快，自己跟不上节奏”。

但换个角度看，每个时代都会有一次工具变迁。写代码的本质是“把现实问题抽象成可运行的逻辑”，这个底层能力是恒定的。今天你用AI生成代码，明天可能换成更强大的模型，后天可能有更智能的IDE，但只要你理解问题抽象的逻辑，理解代码执行的流程，理解如何验证结果，你就永远不会被某个工具的兴衰淘汰。

我自己的体会是，与其焦虑“我现在看的教程会不会过时”，不如把基本功打牢：数据结构与算法、操作系统的基本概念、网络的基础原理、数据库的建模思想。这些底层知识能让你在任何一个工具时代都快速上手，因为它们解决问题的框架是稳定的。

所以回到最初那个问题：“现在有多少人在写代码？”我给出的答案是：只要你愿意，你随时都可以成为其中之一，而且今天成为其中之一的路径比过去任何时代都宽阔。但在跨过那道门槛之前，请先想清楚一个问题——你是想成为一个“会敲代码的人”，还是想成为一个“能用代码解决问题的人”。前者在未来会被工具大量替代，而后者，永远都有价值。