AI时代，别再提“人人都是程序员”了

先说说两组有意思的数据。

6月初，OpenAI公布了几个数字：Codex的周活跃用户已经冲破了500万大关，跟2月份桌面版刚发布那会儿比，增长了不止6倍。更值得玩味的是，在过去一个月的新增用户里，分析师、营销人员、运营、设计师、研究员甚至投资人——这些非开发者群体，占了整整20%。而且他们的增长速度，比传统开发者快了3倍。一个当初纯粹为软件开发而生的工具，现在正以惊人的速度“出圈”，深度嵌入到各行各业的工作流里。说白了，就是让那些以前想调用开发资源但困难重重的人，突然发现写代码这件事的门槛，一下子低了很多。

同期，OpenAI还上线了一个叫Sites的功能，允许用户直接把自己折腾出来的成果一键变成托管网页和应用。你不仅可以指使Codex处理文件和数据，还能顺手生成一个能通过链接分享出去的交互式工具。这意味着什么？一个做数据分析的朋友，过去要搞个可视化互动模型，得先走各种流程申请开发团队资源；现在呢？自己用Codex就能快速搞定，并且直接打包成一个可发布的页面。编程工具，正在变身成通用的生产工具。软件创造这东西，头一回大规模地走出了开发部门。

光看这些，很多人会觉得：这不就是“人人都是程序员”的最好证明吗？市场、运营和研究人员都在用编程智能体了，一个想法就能变成网页和应用，程序员的边界似乎正在消融。

这边Codex在拼命给自己贴上“通用生产力”的标签，那边WWDC 2026上苹果对Xcode的更新，却提供了一个完全不同的视角。苹果的做法是，在AI能写代码的同时，不但没有弱化专业开发工具的理念，反而把Agent更深地嵌入了开发流程——让AI参与构建、跑测试、分析错误，并且跟工具链协作，来完成修复和迭代。这种设计逻辑很清晰：AI不只是个“生成代码的助手”，而是被纳入了真实的工程执行闭环里，在IDE的约束下，跟构建系统、测试系统和预览系统一起工作。

这两件事同时发生，或许才拼凑出了AI Coding当下最真实的全貌：越来越多的人确实能借助AI创造软件了，但“能生成软件”这件事，跟你“是否拥有工程能力”完全是两码事。

现在有个关于AI Coding的流行叙事，越来越显得廉价——只要会说话，人人都能当程序员。

这话听起来很酷，也很鼓舞人心。它暗示着，创造软件的门槛消失了，过去要花多年练就的编程能力，现在几句自然语言提示词就能搞定。一个不会写代码的人，打开Cursor、Claude Code或者随便哪个AI Agent，似乎就能做出自己想要的产品。

当然，这不是全错。

历史上确实从来没有哪个时刻，让普通人离“把一个想法变成能跑的软件”如此之近。一个略懂产品、略懂业务、略懂计算机概念的人，现在确实可以借助AI做出过去很难独立完成的东西。一个原本只有0.3分能力的人，可能被工具放大到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后来复盘时说，接手这种项目，最自然的冲动可能是马上重构。但真正有效的第一步不是动代码，而是让系统“显影”。

他的做法是：让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在这个上下文里工作。

在他的工作流里，一个需求通常不是从“请帮我写代码”开始，而是先把产品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放大的不是职业标签，而是人的基本功。