先说结论这句话不是危言耸听但它经常被误解成程序员要失业了或者AI会让所有人都变成架构师。我在最近半年密集使用AI编程工具、也带过几个团队尝试AI辅助开发之后对这句话的理解有了非常具体的体感——它其实是在提醒我们一个正在发生的分层会使用AI的人和有判断力使用AI的人正在走向完全不同的职业轨迹。这篇文章就围绕这句话展开聊清楚造系统和造垃圾的边界在哪里以及普通程序员该怎么选、怎么落地。这篇文章适合正在用或准备用Cursor等AI编程工具的开发者也适合那些对AI时代职业方向感到焦虑的从业者。我不打算给你灌鸡汤也不会给你一份AI替代不了你的安慰清单我只想把我实际踩过的坑、验证过的方法、以及对这个行业的观察尽可能诚实地写出来。1. 先把这个警告拆开看到底在说什么1.1 这句话出现的大背景Cursor是什么我相信关注AI编程的人已经不陌生了。它本质上是一个深度集成大模型能力的代码编辑器你可以在里面用自然语言让AI帮你写代码、改代码、解释代码、重构代码。过去这一年多它从一个不被看好的编辑器套壳项目变成了很多团队实际日常开发的主力工具。一个AI编程工具的首席设计师站出来说程序员只剩两条路这话分量不轻因为他是站在大量用户真实使用数据之上说的。他看到的现实是同样是用Cursor一类开发者用它把产出效率放大数倍另一类开发者用它快速生产出一堆看似能用、实则一碰就碎的代码。前者的产出可以被叫做系统后者的产出就是垃圾。这个观察和我自己的经历高度吻合——我见过一个实习生用AI一天写了2000行代码结果Code Review时发现其中一半是重复逻辑四分之一是根本走不通的伪代码最后那周的迭代速度反而比不用AI时更慢。注意这句话的关键词是只剩。为什么说只剩两条路而不是有很多条路因为工具平权之后中间地带正在迅速消失。过去程序员的能力差距可以体现在打字速度、框架熟练度、API记忆量上这些差距在AI面前都被抹平了。剩下的唯一分水岭是你有没有能力把零散的代码组织成一个能运行、能维护、能演进的系统。有你就是在造系统没有你就是在AI的帮助下更快地制造垃圾。1.2 造系统和造垃圾不是能力差距是思维差距很多人以为造系统指的是要去做大型分布式架构、要会K8s、会微服务、会高并发设计。这是对系统这个词的窄化理解。实际上一个能持续迭代的个人项目、一个内部工具、一个自动化脚本集合只要它有清晰的结构、明确的边界、可测试的核心逻辑它就是一个系统。反过来一个号称微服务架构的代码库如果每个服务之间互相拷代码、配置全靠玄学、上线靠运气那它本质上是垃圾的堆叠。造垃圾也不是说代码写得烂的人才是造垃圾。在AI时代一个原本能力不错的开发者如果失去了对代码的判断力同样会快速产出垃圾。我在实际使用中见过一个很典型的场景开发者让AI优化一段性能有问题的代码AI给了一个看起来更简洁的写法但这个写法把原本的边界条件全部吞掉了线上直接就出了事故。开发者不是不懂代码而是他对AI输出的信任替代了他自己的思考——这才是AI时代最危险的思维退化。所以我把这句话理解成一个思维层面的警告你是在用AI放大你的判断力还是在用AI替代你的判断力前者让你走向造系统的路后者让你滑向造垃圾的路。这个选择题不是一次性的而是每天都在发生每个对话窗口、每次点击接受按钮都在做选择。2. 造系统的人在造什么2.1 系统思维的第一层需求不是功能是上下文我观察那些真正能造系统的人他们有一个共同特点在写第一行代码之前他们会花大量时间搞清楚这个东西是在什么约束下运行的。这里说的约束包括给谁用、在什么环境跑、数据从哪来、挂了会有什么后果、未来半年会有哪些变化。这些信息构成了一个需求的上下文而上下文才是系统的地基。这恰好是AI目前最不擅长的部分。你把一个需求喂给Cursor它能给你一个看似合理的实现但它不知道你们的内部系统已经有一个类似功能的模块不知道你们的数据库权限体系不允许某个查询不知道这个接口的调用方对延迟有多敏感。所有这些上下文在AI眼里是不存在的。所以造系统的人本质上是那个上下文提供者——他们要负责把模糊的现实需求翻译成AI能理解的明确指令并且对AI的输出做现实校验。举个例子我自己维护过一个内部报表系统。有一阵子我让AI帮我生成新的报表组件效率确实高一个组件十分钟就写完了。但用了一个月我发现组件越来越多可复用性越来越差因为每次AI生成的都是一次性的代码——它只针对当前这个报表做了硬编码根本没有抽取公共逻辑。后来我调整了方式先自己把组件的接口、数据流、状态管理这些骨架定义清楚再让AI去填具体的实现。同一个AI产出质量完全不同。这就是系统和垃圾的区别系统有骨架垃圾只有肉。2.2 系统思维的第二层代码是负债架构是资产还有一个特别反直觉的点很多程序员没转过弯来——代码写得越多负债越高。每一行代码都需要被阅读、被测试、被维护、被修改这些都是持续的成本。而架构恰恰相反一个好的架构是随着时间的推移不断增值的资产因为它让你的修改成本越来越低。AI时代这个逻辑被进一步放大了。过去你写1000行代码可能要花一天现在用Cursor可能只要20分钟。但代码的维护成本并没有因为生成速度变快而降低——相反一个不太理解代码逻辑的人生成的代码维护成本可能比手写更高。这就是为什么我身边那些真正高效的技术负责人反而对AI生成代码持更谨慎的态度他们不是不用AI而是对什么代码值得进入代码库把关更严了。我自己的做法是让AI负责草稿我来负责定型。AI生成的代码我会通读一遍看不懂的绝不合并。有一次AI给我生成了一段日期处理的工具函数逻辑非常紧凑看起来也没问题但我不理解为什么要这么写于是让AI解释每一行的意图。解释完我发现它对闰年和时区的处理有隐藏缺陷表面上是优化实际上是埋雷。从那以后我建立了一个习惯AI写的代码必须能通过我的解释测试——如果不能清晰口头解释这段代码为什么这样写就不允许它进入主干。2.3 系统思维第三层AI是杠杆不是替身聊到这儿我想把造系统的人对AI的核心态度说透他们把AI当成杠杆。杠杆的意思是你自己还得先有一个支点和一根棍子AI帮你把力放大。如果你没有支点不懂业务需求、没有棍子没有技术判断力AI只是一个让你更快摔倒的工具。具体来说AI在哪些环节是真正的杠杆我感受最深的是三个第一样板代码和重复逻辑的生成这个AI做得又快又好第二跨语言、跨框架的翻译和迁移以前这种活儿最烦人现在交给AI能省掉大量低级劳动第三测试用例的补全让AI根据你的代码结构生成边界测试能显著提升覆盖率。但有些环节AI目前真的不行强行用就是制造垃圾。比如需要深度业务判断的地方——某个营销活动的规则到底该怎么定义、某个权限边界应该画在哪里这些AI给不了你答案只能给你一个看起来合理的答案。再比如系统间的一致性设计你的服务要怎么和另一个老系统对接、字段映射怎么做、异常怎么兜底AI没有你那些系统里的数据字典和线上事故记录它只能靠猜。所以我现在的工作流是这样凡是AI擅长的大胆用凡是AI不擅长的自己来凡是不确定AI行不行的先小范围试试完再做决定。这个分类处理的习惯就是造系统和造垃圾的分水岭之一。3. 造垃圾是怎么发生的AI时代的三种翻车姿势3.1 拼图式开发把AI生成当复制粘贴我先说说最常见的翻车姿势我管它叫拼图式开发。具体表现是开发者把需求拆成一堆碎片然后像发弹幕一样让AI逐个生成最后把生成的代码拼在一起跑起来没问题就算完事。这套流程听起来效率很高实际隐患极大——因为每个碎片之间需要有契约、有边界、有一致的错误处理策略而拼接动作本身是最容易出错的地方。我团队里有个项目就是这么翻的车。一个同事用AI在两天内搭了一个后台管理系统的雏形当时看着功能齐全页面也有模有样。结果进入联调阶段问题集中爆发有的模块用Promise处理异步有的模块用回调有的接口用驼峰命名有的用下划线错误处理有的抛异常有的返回null。整个代码库像是一个缝合怪修一个bug常常要连带着改三个文件。最后我们花了整整一周重构才把项目拉回正轨。这个教训让我意识到拼图式开发的本质问题是它把系统设计这个最关键的环节省略了。你让AI帮你写每一块拼图但你从来没有自己设计过这张拼图的完整图案。没有图案的拼图拼出来的只可能是垃圾。3.2 上下文缺失让AI猜需求然后接受错误答案第二种翻车姿势更隐蔽也更普遍。很多人用AI的时候把需求描述得特别简略——写一个用户登录接口然后AI给什么就用什么。问题是一个用户登录接口背后有一堆隐含决策密码加密用什么算法、token有效期多长、需不需要验证码、要不要记录登录日志、被锁定了怎么处理。这些决策你不如实告诉AIAI就会用它的默认值来猜而它的默认值往往是通用教材里的标准答案跟你的实际业务场景大概率是错位的。我见过最离谱的一次是有人让AI写一个导出Excel的功能AI生成了一版用了内存缓存来加速的方案结果数据量一大服务直接OOM了。你说这个AI错了吗没有它只是不知道这批数据可能有几十万行不知道服务器内存只有512MB。这个上下文只有开发者自己清楚你不说AI永远不会知道。所以我把能不能给AI提供准确的上下文看作AI时代程序员的核心基本功。你有没有能力把一个模糊需求拆成AI能理解的技术约束决定了你得到的是解决方案还是又一个坑。这个能力不是天生的需要对自己负责的系统和业务有足够的理解而这种理解只能靠深入项目、阅读代码、参与线上问题处理来积累。没有任何捷径。3.3 技术债加速器没有评审和测试的高效交付第三种翻车姿势我觉得是AI时代最危险的因为它披着高效的外衣。具体来说就是团队为了追求速度和产出跳过Code Review、跳过单元测试、跳过设计评审完全信任AI生成的代码。短期看交付速度确实快得惊人中期看技术债会以几何级数膨胀长期看这个代码库会变得没人敢动。技术债这个东西在AI时代变成了技术债加速器。传统开发模式下代码写得烂因为写代码本身需要时间所以烂的产出速度有限。现在不一样了AI一分钟能生成几十个函数如果你不设卡垃圾产出的速度可以快到让整个项目在一两周内就变得不可维护。我自己的经验是AI生成代码的质量分布是极端的两极分化。对于描述清晰、边界明确的小任务AI的产出质量相当高甚至超过很多初级开发者但对于需要全局视野的任务AI的产出质量会断崖式下降而且它会用一种极其自信的语气给出错误答案。如果你没有测试和评审这道过滤网你根本分不清哪些是好的哪些是定时炸弹。所以我在团队里一直坚持AI可以提速但质量关口绝不能省。每个AI生成的模块必须过单元测试、必须过代码评审、必须有相应的集成验证。有人说这样做会拖慢速度我的回答是你省下的那一小时会在未来用十个小时还回来而且还要加上利息。4. 我自己用 Cursor 这类 AI 工具的实际经验4.1 我的AI辅助编程工作流聊完理论和翻车案例我具体分享一下我现在用Cursor的工作流这条流程是我反复试错后沉淀下来的不一定适合所有人但至少能给你一些参考。第一步写代码之前我会先在编辑器里用自然语言写一段任务说明包含四块内容目标是什么、输入是什么、输出是什么、约束有哪些。比如我要写一个汇率转换工具函数我会写清楚输入是金额、原币种、目标币种输出是转换后的金额需要处理币种代码不存在的异常精度保留两位小数。这个说明越具体AI的产出越接近可用状态。第二步让AI在对话窗口里先给出实现方案而不是直接给代码。我会追问它你打算怎么处理时区问题缓存策略是什么这个实现的时间复杂度是多少。等方案讨论清楚了再让它生成代码。这一步能过滤掉至少一半的瞎写。第三步拿到代码后我不会直接合并而是让AI自己写测试用例然后我来补充边界测试。刚才说的那个汇率函数AI只写了正常路径的测试我自己补了币种为空、金额为负数、币种不存在三个边界用例果然跑出来一个空指针。第四步合并之前我一定要自己手写一段核心逻辑哪怕是很短的一段。这是为了保持对代码的手感——如果你长期只审查AI代码、不自己写代码你对代码质量的敏感度会慢慢退化到时候连AI的烂代码都识别不出来。4.2 哪些场景AI真的强哪些场景AI是坑我花了很多时间测试Cursor在不同场景下的表现最后总结出几个高信心区和低信心区分享出来可以帮你少走弯路。高信心区我可以放心让它干的三类事一是配置类、模板类代码比如Dockerfile、CI脚本、脚手架初始化这类代码模式固定、上下文少AI完成度很高二是纯函数和算法片段只要输入输出定义清楚AI写的实现一般既简洁又可靠三是代码重构和翻译把一段老代码从JavaScript迁移到TypeScript把回调改成async/await这些活儿AI做得比人快而且准确率不低。低信心区我会非常谨慎甚至不让AI碰的几类事一是涉及跨模块状态管理的逻辑比如多个组件共享的全局状态AI没有全局视角很容易改坏一个地方连带崩掉另一个地方二是复杂的并发和事务边界AI对这里为什么不能加锁这个事务为什么必须放在这个层级缺乏直觉三是任何涉及历史包袱的代码老系统里那些没人知道为什么存在的魔法逻辑AI很容易把它们当成无用代码优化掉。这个高信心区/低信心区的判断本身也是区分造系统的人和造垃圾的人的试金石。前者知道什么时候该信AI什么时候该靠自己后者对AI盲目信任或者盲目排斥都没能找到正确的使用姿势。4.3 五个用得上的提示词和操作细节最后分享五个我在实际使用中验证过比较有效的提示词技巧和操作习惯都是普通文档里不一定写得清楚的细节。第一个技巧让AI先复述需求。每次给AI派活之前先加一句请先用你自己的话复述一遍我的需求再开始动手。这句话能筛掉一大半的理解偏差。很多时候你写了一段需求AI理解的和你想的根本不是一回事提前让它复述能省掉后面返工的时间。第二个技巧给AI提供反例。只告诉AI你想要什么往往不够还要告诉它你不想要什么。比如不要用全局变量不要引入新的第三方依赖不要在循环里做IO操作。这些反例能在AI生成之前就把最常见的烂代码倾向掐灭。第三个技巧用分步生成代替一次搞定。不要把一个大需求一次性丢给AI让它一口气生成一个完整系统。正确的做法是让AI先设计接口确认无误后再生成实现最后生成测试和文档。每一步之间要有你的审核动作而不是一条龙到底。第四个技巧让AI为自己的代码辩护。收到AI的代码后你可以追问为什么这里要这样处理有没有更简单的实现方式这个实现的性能瓶颈在哪里这一步不是为了找茬而是为了逼自己理解每一段进入代码库的代码。凡是AI解释不通的代码大概率有隐患。第五个技巧善用项目级上下文。新版Cursor支持把整个项目目录作为上下文让AI看到相关文件再回答。实际操作中我建议你不要一股脑把整个仓库都丢给它而是手动指定相关的两三个文件。上下文太杂AI反而会被噪音干扰给出更差的答案。5. 程序员的两条路怎么选怎么走5.1 能力矩阵系统构建者需要哪些技能如果说造系统是一条值得走的路那这条路需要哪些具体技能这可能是大家最关心的问题。我把它总结成一个能力矩阵从三个维度来看技术深度、业务理解、协作沟通。技术深度指的是你对某个领域有扎实的底层理解。过去你可能靠会用某个框架吃饭现在这个门槛已经被AI踏平了。AI可以按需生成任何框架的代码但它不能替你理解为什么这个框架要这么设计什么场景下这个框架不适用。这些底层理解才是技术深度的核心。我的建议是挑一个你业务里最核心的技术领域把网络、存储、并发、安全这几块硬骨头啃透这些知识AI很难替你补课。业务理解维度是我认为AI时代被严重低估的一项能力。造系统的人不是写代码的而是用代码解决业务问题的。你需要知道你的系统服务的业务是什么逻辑、痛点在哪、增长瓶颈在哪。很多程序员觉得业务是产品经理的事这个想法在AI时代会害了你——AI已经能写代码了那你不懂业务你的不可替代性在哪里我认识的几个在AI时代反而越来越吃香的程序员无一例外都是对业务理解极深的人他们能在需求评审会上直接指出产品方案的技术陷阱这种人AI替代不了。协作沟通维度指的是你能不能把你的技术方案讲清楚让非技术人员也听得懂同时能不能把模糊的业务需求翻译成精确的技术约束。这个能力在AI时代也变得更重要了因为AI是一种需要被精确指挥的工具指挥得好不好就看你的沟通和翻译能力。5.2 学习方向调整从学框架到学约束很多程序员问我AI时代到底该学什么我的回答可能有点反直觉少学怎么用多学为什么这么设计把学习重心从框架API转移到系统约束上来。什么叫系统约束举个例子你做一个订单系统你得知道订单状态机怎么设计才不会出现状态错乱你得知道数据库的事务隔离级别会影响什么你得知道消息队列的至少一次投递会导致什么重复消费问题。这些知识不是某个框架的用法而是任何系统都绕不开的约束。框架会过时约束不会。你学会了这些约束AI只是帮你把约束落地成代码的工具你只学会了框架AI生成框架代码的速度比你快十倍你就没有价值了。我建议的学习路径是这样的第一选一个你工作中最常用的系统把它彻底读透。不是读代码而是理解它为什么这么设计——数据流怎么走、容错怎么做、扩展点在哪里。第二亲手从零搭一个完整系统哪怕是玩具级别的关键是走完设计、编码、测试、部署、监控的完整闭环。第三多复盘线上事故每一个事故背后都是一个你没理解的系统约束复盘一次顶得上读十本书。5.3 给不同阶段程序员的建议针对不同阶段的朋友我想给几条具体的建议这些都是我自己经历过或者亲眼见过的。给刚入行的新人AI时代反而是你的机会因为你不用从背API开始职业生涯了。但你要比上一代程序员更早地建立系统思维。我的建议是入职前三个月先别急着写业务代码把公司的系统架构文档翻烂弄清每个服务是干什么的、数据是怎么流转的、异常是怎么处理的。这三个月看起来没产出实际上是在给你未来的效率打地基。地基打得牢AI就是你的火箭推进器地基是沙土AI只会让你更快地坍塌。给工作三到五年的中坚力量你们正处在最焦虑的阶段——往上走有技术天花板往下看新人用AI干得比你们快。我的建议是别再跟AI拼写代码的速度了你拼不过的。你要拼的是判断力凭借经验你知道什么方案在线上会出问题、什么设计在半年后会变成瓶颈、什么需求背后藏着没说的风险。这些判断力是AI给不了、新人拿不走的资产。把你的一部分时间从写代码挪到做设计、做评审、做复盘上这是你走向造系统这条路的必经环节。给技术管理者和团队负责人你的团队会不会变成垃圾制造工厂很大程度上取决于你定的流程。我强烈建议AI的使用规范要在团队里明确写下来什么场景允许用AI、什么场景必须人来写、AI代码的评审标准是什么。不要放任每个人自由使用AI否则你很快会收获一个结构混乱、风格分裂、没人敢改的代码库。这不是限制团队效率恰恰是保护团队长期效率。6. 常见问题与避坑指南6.1 常见问题速查最后整理一份我在实践和带团队过程中最常被问到的问题配上我的实际处理方式问用了AI之后我发现自己越来越不会写代码了正常吗答正常但这是危险信号。找原因是多方面的你长期只读AI代码、只改AI代码自己的码感会退化。我的解决办法是前面提到的每次合并前手写一段核心逻辑哪怕只有十几行。保持手感就像键盘手要保持练习一样不能停。问AI生成的代码有bug是我不会用吗答AI生成的代码有bug是常态不是例外。会不会用体现在你能不能快速定位并修复bug而不是指望AI一次写对。我会让AI先跑测试用例、再让AI解释出错的原因、最后让AI提出两种修复方案我选择更稳健的那个。把debug AI代码当成一个独立技能来练。问该不该把全部代码交给AI重构答千万别。短时间大范围重构是制造垃圾的最高效方式之一。AI重构会悄悄改变你原有的行为逻辑而且你未必能发现。我的建议是只重构你有测试覆盖的代码重构完跑一遍全量测试没有测试覆盖的老代码保持原样等有测试了再动。问团队引入AI之后代码质量下滑怎么办答先看流程别先怪人。十有八九是缺少质量关卡。我在团队里做了三件事第一建立AI代码专用的评审清单包括变量命名是否清晰、有无重复逻辑、异常处理是否完整、是否有隐藏的状态修改第二要求所有AI生成的关键模块必须配套单元测试第三定期组织AI代码复盘会把线上事故中由AI代码引发的问题拿出来分析沉淀成团队的知识库。问开源项目里的AI生成代码能直接用吗答能用但要先做可信度评估。看这个项目的star数、维护活跃度、测试覆盖率看它的作者是否在文档里说明了AI辅助开发的策略。我会优先选择那些有完善的CI、有明确贡献指南、有活跃维护者人工把关的项目。毕竟AI生成的代码缺少人类维护者的长期责任感你需要外部条件来弥补这个缺陷。6.2 我的几条实操心得文章最后我把自己最想强调的几条实操心得放在这里希望你少走我走过的弯路。第一条AI生成代码之前先把不做什么说清楚。和AI协作时正向约束和反向约束同样重要。我曾经让AI优化一段查询代码只说了要快结果它给了一个用空间换时间的方案直接让内存翻了三倍。如果我提前说不要引入额外内存缓存要在现有索引基础上优化就不会踩这个坑。第二条养成质疑AI的自信的习惯。AI给出的答案往往带着同样的笃定语气无论对不对。你必须在心理上建立一个机制AI越自信我越要验证。特别是那些看起来简洁优雅、但你不太理解的实现一定要追问到底。越是漂亮的答案越可能是隐藏的坑。第三条宁可慢一点也要让代码可解释。AI时代代码的可解释性比性能优化更重要。一段代码如果没人能解释清楚它的每一条逻辑那它就是定时炸弹。我在评审时最常问的问题是这段逻辑为什么要这样写谁能解释解释不了即使是AI写的、即使是测试通过的我也不同意合并。第四条也是我最想说的别把AI当成答案机器把它当成思考伙伴。我现在的习惯是遇到一个技术问题先自己思考几分钟列出我倾向的方案和理由然后让AI给我它的看法再对比我们的差异。这个过程看起来比直接问AI慢但它逼着我保持了独立判断的系统。用进废退这个原则在AI时代一样适用——如果你凡事都让AI替你做决定你的判断力会慢慢萎缩最终成为那个只能造垃圾的人。回到开头那个警告。我理解的两条路不是说人人都会变成架构师也不是说用AI的人都会造垃圾。它说的是AI作为一个强大的工具正在把程序员这个职业推向一个关键的岔路口。选择权在每个人自己手里而选择的方式藏在每一个日常的、看似微小的决策里——是让AI替你思考还是和AI一起思考。我的选择已经写在上面了希望你也能找到自己的那条路。