原文标题：《Codex新用户超两成都不是专业开发者，但千万别说“人人都是程序员”》，作者：Zetze，审校：凯文，题图来自：视觉中国

6 月初，OpenAI 公布了一组颇具象征意味的数据：Codex 周活跃用户已突破500万，较 2 月桌面版发布时增长超过6倍；更值得注意的是，在过去一个月新增的 Codex 用户中，分析师、营销人员、运营人员、设计师、研究人员、投资者等非开发者占到了 20%，且增长速度超过开发者 3 倍。这个最初为软件开发而生的工具，正在迅速进入泛化阶段，参与更多人的日常工作，让更多以前调用开发资源相对困难的人，低门槛的获得了代码能力。

OpenAI 同时推出了可以把工作成果直接转化为托管网站和应用的 Sites 功能。用户不只可以让 Codex 处理文件和数据，还可以生成一个能够通过 URL 分享的交互式工具。这也就意味着，一个原本从事数据分析岗位的人可以利用Codex 快速完成原本要申请开发团队资源才能够完成的可视化互动模型，直接打包成一个可发布的互动页面，大大提高了工作效率。编程工具正在变成通用生产工具，软件创造也第一次如此大规模地走出开发部门。

乍看之下，这似乎是“人人都是程序员”的又一个证据：当市场、运营和研究人员都开始调用编程智能体，当一个想法可以直接变成网站和应用，程序员与普通人的边界似乎正在消失。

相比较 Codex 在持续弱化自己专业编程工具，力图给自己贴上通用生产力标签的同时，WWDC 2026 上苹果对 Xcode 的更新提供了一个很关键的补充视角：在 AI 能力迅速进入写代码环节的同时，专业开发工具的理念并没有被削弱，反而进一步把 Agent 深度嵌入到开发流程中——让它可以参与构建、运行测试、分析错误，并通过与工具链的协作来完成修复与迭代。这种设计意味着 AI 不只是“生成代码的助手”，而是被纳入了一个真实的工程执行闭环之中，并在 IDE 的约束下与构建系统、测试系统和预览系统共同工作。

这两件事同时发生，或许才是 AI Coding 当下最真实的图景：越来越多人可以借助 AI 创造软件，但能够生成软件，并不等于自动拥有了工程能力。

有一种关于 AI Coding 的流行叙事正在变得越来越廉价：只要会说话，人人都能成为程序员。

这句话听起来很有时代感，也足够鼓舞人。它暗示软件创造的门槛正在消失，过去需要多年训练才能掌握的编程能力，如今可以被几句自然语言提示词替代。一个不会写代码的人，也许只要打开 Cursor、Claude Code 或者某个 AI Agent，就能做出自己想要的产品。

这当然不是全错。

历史上也许从来没有一个时刻，普通人距离“把一个想法变成可运行的软件”如此之近。一个略懂产品、略懂业务、略懂计算机概念的人，今天确实可以借助 AI 做出过去很难独立完成的东西。一个原本只有 0.3 分能力的人，可能被 AI 放大到 0.8，甚至 0.9。

但问题也在这里：AI 可以放大 0.3，却很难凭空生成那最初的 0.3。

如果一个人不知道自己到底想要什么，不知道如何描述问题，不知道什么叫边界条件，不知道一个软件从 Demo 变成服务需要经历什么，也不知道错误应该在哪里被暴露、数据应该如何被组织、系统应该如何被维护，那么 AI 带来的往往不是创造力的爆发，而是混乱的加速生成。

所以，AI 时代当然会出现更多“能做软件的人”。但这并不等于人人都是程序员。

更准确地说，AI 正在放大一种能力：结构化理解世界、拆解问题、组织上下文、调用工具，并为结果负责的能力。程序员只是最早被迫系统训练出这种能力的一群人。

在和一位长期深度使用 AI Coding 的资深工程师交流时，他反复提到一个判断：AI Coding 最容易被误解的地方，是人们总把它想象成“让 AI 写代码”。出于职业身份和项目信息的考虑，本文称他为 CC。在 CC 的实践里，AI 真正改变的并不是敲代码的速度，而是整个研发过程里“理解、表达、验证和协作”的方式。

CC 的几个经历，恰好能说明这个变化。

一个人和 AI 都读不懂的项目

很多人第一次理解 AI Coding，是从“它能替我写代码”开始的。但在真实的软件现场，AI Coding 最有价值的时刻，往往不是写新代码，而是让旧系统重新变得可理解。

CC 曾接手过一个历史项目。项目原先由一位算法背景很强、但工程经验并不充分的开发者长期维护。项目核心是一组庞大的 Python 脚本，单个文件动辄几千行。业务逻辑、数据处理、模型调用、文件读写、异常处理混在一起，模块边界模糊，命名风格不统一，重复逻辑到处散落。

更复杂的是，这个项目里还夹杂着早期 AI 补全时代留下的代码。当时模型能力有限，AI 更像一个智能补全器，而不是今天意义上的编码 Agent。它能生成一些局部片段，却很难理解系统整体。于是项目逐渐变成了一个奇怪的混合体：算法专家的快速实验代码，加上早期 AI 补全生成的碎片，再加上长期缺乏工程治理积累下来的技术债。

对人来说，它几乎不可读。对 AI 来说，它同样不友好。

这点经常被忽视。过去我们说代码要“对人友好”，意味着结构清晰、命名明确、模块边界合理、文档足够完整。到了 AI Coding 时代，代码还要“对 AI 友好”。一个几千行的巨型脚本，不只是折磨接手项目的人，也会严重消耗模型的上下文窗口和推理能力。模型越难理解系统，就越容易在局部改动中制造新的混乱——注意：AI几乎不可能告诉你“我看不懂这段代码”，但这可能是更大灾难的到来，说明它要准备瞎编了。

CC 后来复盘这段经历时说，接手这种项目时，最自然的冲动可能是马上重构。但真正有效的第一步不是动代码，而是让系统显影。

CC 的做法是，让 AI 扮演架构师，逐步阅读代码库，梳理模块关系、调用链路、数据流向和关键职责。让它生成一份可以 onboarding 的文档，画出流程图和设计图。再由人根据自己的工程经验去校准这些文档：哪里是主链路，哪里是历史包袱，哪里只是临时绕路，哪里是业务上必须保留的复杂性。

这时，AI 的角色不是“替你写代码的实习生”，而更像一台结构显影仪。它把原本埋在几千行脚本里的系统形状重新照出来，让人可以开始讨论它、切分它、修改它。

在这个项目里，真正的转折点就发生在这一步之后。等系统结构被重新看见，重构才变得可行：文件结构被重新划分，模块边界逐渐出现，重复逻辑被抽取，可测试性增强，运行稳定性提升。更重要的是，用 CC 的说法，项目重新变得可维护了。

这里的“可维护”不仅是对人而言，也是对 AI 而言。

一个结构清晰的代码库，会让后续 AI Agent 更容易理解上下文，更容易做小步安全修改，更容易根据测试反馈修正问题。反过来，一个混乱的代码库会同时拖垮人和 AI。AI Coding 并不会神奇地绕过工程复杂性。它只是让工程质量的好坏，以更快的速度显现出来。

这也是为什么“人人都是程序员”的说法会误导人。AI 不是把工程能力取消了，而是把工程能力变成了更底层的基础设施。

Demo 和服务之间，隔着一整套工程责任

Vibe Coding 最迷人的地方，是它让软件创造变得像说话一样自然。

你描述一个想法，AI 给出页面；你再补一句需求，AI 接着生成接口；你说这里不好看，它替你调样式；你说想加登录、支付、数据看板，它似乎也都能往前推进。一个晚上做出一个 Demo，这件事已经不再稀奇。

但 Demo 和服务之间，隔着一整套工程责任。

Demo 的目标是“看起来能用”，服务的目标是“长期可用”。Demo 可以容忍数据结构混乱、异常处理粗糙、权限模型简化、部署流程手工化、日志缺失、测试缺位。服务不行。服务要面对真实用户、真实数据、真实并发、真实成本、真实安全风险，以及真实的后续维护。

这也是很多 Vibe Coding 文章最容易讲浅的地方。它们乐于展示“一个不会写代码的人做出了一个 App”，却很少继续追问：这个 App 能不能稳定运行？出了问题谁排查？数据坏了怎么办？权限泄露怎么办？业务规则变化后如何迭代？半年后还有人看得懂吗？

能跑起来，是软件生命的开始，不是结束。

CC 后来做过一个更复杂的业务系统项目。出于商业保密，这里不展开具体行业和客户，只保留问题形态：它并不是一个单纯的技术项目，而是一场从线下纸质流程到线上数字化系统的迁移。它需要理解不同岗位的工作方式，观察真实流程，而不是只听一句“我们想做个系统”。它需要把业务语言翻译成数据表、权限规则、审批流、统计口径、接口边界和异常场景。

这种项目复杂的地方，并不在于某个单点技术有多炫。真正复杂的是业务细节和数据关系：几十张表之间如何关联，数百个 API 如何组织，不同角色如何使用同一套数据，不同流程之间如何互相影响。过去，这类项目往往需要产品、后端、前端、测试、运维等多种角色协同。

AI 的确改变了这里的效率结构。一个有经验的人，可以借助 AI 把很多过去需要多人分担的工作串起来。但前提是，他必须知道该把什么上下文交给 AI。

这就是 AI Coding 和普通代码生成的分水岭。

AI Coding 的本质不是写代码，而是写上下文

今天更成熟的 AI Coding，已经越来越不像“打开聊天框让 AI 写函数”，而像一条端到端的研发链路。CC 把自己的做法概括为：尽可能替 AI 构建足够丰富的上下文，然后让 AI 在这个上下文里工作。

在 CC 的工作流里，一个需求通常不是从“请帮我写代码”开始，而是先把产品 PRD、需求文档、需求评审会议的逐字稿、上下游系统的技术文档、已有代码库和项目规范都提供给 AI。然后让 AI 基于这些材料生成技术方案。方案不是直接进入开发，而是先沉淀成一篇文档，交给工程师、产品和相关业务同事 review。

这一步很关键。

因为 AI 的输出不是用来跳过沟通的，而是用来提升沟通质量的。过去，很多需求评审的问题在于不同角色脑中的系统模型并不一致。产品说的是用户流程，工程师想的是数据结构，业务同事关心的是线下例外情况，上下游关心的是接口契约。AI 可以把这些散落的材料先组织成一个可讨论的版本，让团队更早发现理解偏差。

确认技术方案后，再进入编码、单元测试、回归测试和人工验收。开发完成后，CC 还会让 AI 继续生成对接文档。这个文档表面上是给上下游同事看的，但在 AI Agent 普及之后，它还有一个新的用途：成为别人 Agent 的上下文。

这是一种很有意思的变化。过去，文档主要写给人读；今天，文档也开始写给 AI 读。接口说明、业务规则、验收标准、错误码、数据样例，都会成为另一个 AI Agent 开发对接功能时的输入。

于是，所谓 AI Coding 的核心对象发生了变化。

过去我们写代码，今天我们也在写上下文。这里的上下文不是一段 prompt，而是一个工作场：需求文档、会议记录、代码库、测试用例、日志、项目规范、技术决策、验收标准、接口文档、历史讨论，都在其中。

谁能组织更好的上下文，谁就能更好地使用 AI。

这也是为什么“会 prompt 就够了”是另一个误解。真正重要的不是某句神奇提示词，而是你能否把一个模糊问题整理成 AI 可以理解、可以执行、可以验证的结构。提示词只是入口，上下文才是主体。

如果上下文是错的，AI 会高效地产生错误。如果上下文是乱的，AI 会高效地放大混乱。如果上下文缺少验收标准，AI 就会倾向于给出“看起来完成了”的结果。

AI Coding 的上限，不只由模型决定，也由人类组织上下文的能力决定。

程序员并没有被 AI 取代，他们正在用 AI 进入各行各业

“程序员要失业了”是 AI 浪潮里最常见的句式之一。

程序员自己说这句话，很多时候是自嘲。这个行业长期站在技术变化前沿，习惯了每隔几年就被新的语言、框架、平台、范式重新教育一遍。自嘲背后，往往有真实焦虑，也有对变化的敏感。

但当这句话被简化成“AI 会写代码，所以程序员不重要了”，它就变成了一种外行式误判。

编程当然包含写代码，但程序员的核心能力从来不只是记住语法。一个合格程序员长期训练的是另一组能力：把模糊需求拆成明确任务，把复杂系统拆成模块，把异常情况前置考虑，把重复劳动抽象成工具，把现实世界的不确定性压进可以运行、可以调试、可以维护的结构里。

这些能力恰恰是 AI 时代更容易被放大的能力。

如果一个程序员缺少设计能力，AI 可以补一部分产品原型；缺少前端审美，AI 可以补一部分界面实现；缺少运维经验，AI 可以解释云服务、生成部署脚本、定位日志问题；缺少写作能力，AI 可以协助生成文档、邮件和方案。换句话说，AI 不只是让程序员写代码更快，也让程序员更容易补齐跨界短板。

所以，更值得注意的现象也许不是“程序员正在被各行各业取代”，而是“程序员正在借助 AI 进入各行各业”。

当一个拥有工程思维的人获得产品、设计、运营、数据分析和写作能力的外骨骼，他能做的事情会比过去宽得多。反过来，一个完全没有结构化表达能力、没有系统概念、没有边界意识的人，即使拿到最强的 AI 工具，也很容易卡在第一步：不知道该如何描述自己想要什么。

这并不是说非程序员不能使用 AI 做软件。恰恰相反，AI 的确让很多非技术背景的人第一次拥有了软件创造能力。但他们真正需要补的，不是“语法”，而是问题定义、需求表达、流程拆解和结果验收。

AI 降低的是编码门槛，不是思考门槛。

甚至可以说，AI 越强，思考门槛越显眼。因为工具越能快速执行，错误的方向就越容易被快速放大。过去一个模糊需求可能在漫长开发过程中慢慢暴露问题；现在，它可能在一天之内变成一个结构混乱但页面完整的系统。

这不是民主化的反面，而是民主化之后的新门槛。

AI 最危险的地方不是写错

对 AI Coding 的批评，常常集中在“AI 会写 bug”。但在真实工程里，更麻烦的情况不是它写错，而是它把错误隐藏起来。

CC 在一个数据科学相关项目中，曾经遇到过一种很典型的问题：无论输入数据多离谱，程序最终似乎总能输出结果。表面看，这是系统“鲁棒性”很强；但按业务逻辑判断，某些输入本应在中间环节触发错误，提醒开发者数据不合法、流程不完整或假设不成立。

后来的人工排查发现，问题出在一系列 AI 生成或补全的兜底逻辑上。它在很多环节加了默认值、try-catch、空值兼容和静默降级。每个局部看起来都像是在“增强稳定性”，但串起来之后，系统变成了一个几乎不会失败的黑箱。

这恰恰很危险。

工程系统里，失败不是坏事。该失败的时候失败，错误才能被及时暴露；该抛异常的时候抛异常，系统边界才是清晰的。尤其在数据科学、金融、医疗、教育等领域，一个“永远给出结果”的系统未必可靠，反而可能意味着它正在掩盖异常。

AI 为什么喜欢这样写？一个可能的原因是，它在训练和交互中更容易被奖励“完成任务”。用户说修复错误，它就倾向于让报错消失；用户说程序不要崩，它就倾向于加兜底；用户说保证输出，它就倾向于制造默认路径。但在工程里，报错消失不等于问题解决，程序不崩不等于逻辑正确，有输出不等于有价值。

这就是人类工程师仍然重要的地方。

人要告诉 AI：哪些错误必须暴露，哪些异常不能吞掉，哪些输入必须拒绝，哪些链路必须 fail fast，哪些关键环节需要显式校验。更进一步，这些规则不应该只停留在口头，而应该沉淀进项目规范里，放在代码库根目录，随 git 一起提交。

这会带来一个新的协作模式：人制定规则，AI 执行规则。

过去，团队代码规范依赖培训、文档、code review 和个人习惯。让所有人持续遵守一套规范很难，因为人会遗忘、偷懒，也会在赶进度时妥协。今天，很多规范可以写成 AI Agent 能读取的项目约束：异常处理原则、命名规范、测试要求、禁止行为、提交标准、验收清单。不同成员的 Agent 进入代码库后，都能读取这些规则，并在开发中自动遵守。

这不是说 code review 不重要了，而是规范执行的起点前移了。AI 让团队有机会把“工程共识”变成更可执行的上下文。

从这个角度看，未来优秀工程师的一项重要工作，不只是写业务代码，而是维护一套能让 AI 正确工作的规则系统。

那最初的 0.3 是什么？

如果 AI 可以把 0.3 放大到 0.9，那么问题就变成：那最初的 0.3 到底是什么？

对专业开发者来说，它越来越不是某个具体框架的熟练度。框架会变，工具会变，模型能力也会快速提升。今天困扰开发者很久的隐藏 bug，也许明天换一个新模型就能被直接定位。很多现在看起来需要技巧的问题，都会逐渐被更强的模型能力吞掉。

但有些东西不那么容易被吞掉。

比如业务理解。你要知道一个需求为什么存在，哪些流程是真需求，哪些只是历史习惯，哪些例外情况必须保留，哪些复杂性可以被砍掉。AI 可以根据材料生成方案，但它很难替你判断一个组织真正需要什么。

比如 spec 能力。也就是把需求写清楚的能力。一个好的 spec 不只是描述“我要什么功能”，还要描述边界、状态、数据结构、角色权限、异常场景、验收标准和非目标。AI 越强，spec 越重要，因为 spec 决定了 AI 执行的方向。

比如验收能力。AI 可以写测试，也可以跑回归，但人要知道什么叫真正通过。页面能打开不代表业务正确，接口返回 200 不代表数据可信，模型给出结果不代表结论可用。

比如系统判断。什么时候继续让 AI 修，什么时候人该接管；什么时候补测试，什么时候重构；什么时候接受局部不完美，什么时候必须推倒重来。这些都不是一句 prompt 能解决的。

对非专业开发者来说，最初的 0.3 也许更基础：能不能描述清楚自己想要什么，能不能把一个大想法拆成几个小问题，能不能意识到软件不仅有页面，还有数据、权限、部署、成本和维护。

很多人以为自己缺的是编程语言，其实第一步缺的是需求表达。

这也是 AI 时代一个很有意思的变化：表达能力变得前所未有地重要。过去，表达不清楚最多影响人与人沟通；今天，表达不清楚会直接影响 AI 的执行结果。一个模糊的想法，会被 AI 快速变成一个模糊的系统。

当然，AI 也能帮助人补齐短板。云服务、计算机网络、数据库、部署流程，这些过去让非技术人望而却步的知识，如今都可以通过 AI 快速解释和辅助执行。只要问题描述得足够清楚，AI 确实能带人跨过很多过去很高的门槛。

但这仍然不是“零门槛”。

AI 时代的门槛从“会不会写代码”，转移到了“会不会定义问题、组织上下文、判断结果”。

别再说人人都是程序员了

“人人都是程序员”之所以流行，是因为它抓住了一个真实趋势：软件创造正在从少数专业人士手里扩散出去。

这个趋势当然值得欢迎。更多人可以把自己的想法做成工具，更多小团队可以用更低成本完成数字化，更多行业知识可以直接转化成软件原型。AI 让创造软件这件事，第一次真正接近大众。

但如果因此认为专业性不再重要，就走向了另一个误区。

AI Coding 不会消灭工程能力，它会重估工程能力。它不会让所有人自动成为程序员，它会让那些具备结构化能力、学习能力、业务理解和责任意识的人获得更强的生产力。它不会让代码质量问题消失，它会让质量问题以更快速度出现，也让治理质量问题的能力更重要。

从这个意义上说，AI Coding 最重要的改变不是“代码由谁敲出来”，而是“谁来定义问题、组织上下文、建立规则、验证结果，并为系统负责”。

未来的软件工程师可能会少写一些机械代码，但会更多地写 spec、写上下文、写测试、写规则、写文档、写给其他 AI Agent 读取的协作材料。软件开发的中心，正在从“代码输入”转向“上下文组织”。

这不是程序员消失的开始，而是程序员角色重组的开始。

AI 的确可以把 0.3 放大到 0.8，甚至 0.9。这是这个时代真正令人兴奋的地方。一个人只要具备一点点计算机基础、业务理解、表达能力和结构化思维，就可能做出过去需要一个小团队才能完成的东西。

但如果没有那最初的 0.3，一切都是空话。

AI 不会替你知道你想要什么，不会替你承担后果，也不会自动理解一个组织、一个行业、一套业务流程背后的真实复杂性。它可以生成代码，也可以生成文档、测试和方案，但它无法替代人对问题本身的理解。

所以，AI 时代，别再说人人都是程序员了。

更准确的说法是：人人都更接近软件创造，但不是人人都自动拥有工程能力。

AI 放大的不是职业标签，而是人的基本功。