AI时代程序员两条路：造系统，还是造垃圾？-平芜编程栈

Cursor首席设计师最近抛了一个挺扎心的判断：AI时代，程序员只剩两条路，造系统，或者造垃圾。这句话这两天在不少技术群里被转疯了，有人焦虑，有人不服，也有人觉得就是标题党。我做了十几年开发，这两年又几乎天天泡在Cursor这类AI编程工具里，想认真拆一下这句话背后的东西——它到底在说什么，什么样的程序员在造系统，哪些人明明很努力却一直在造垃圾，以及我们怎么确保自己站到前一条路上。

这篇文章不打算贩卖焦虑，也不准备吹捧某个工具。我会结合自己用Cursor从原型到上线做完整项目的实际操作经验，把这条“警告”掰开揉碎讲清楚，顺便分享一套我自己跑顺了的AI辅助开发工作流。不管你是刚入行的新人，还是带团队的老手，应该都能从里面找到点有用的东西。

1. 先拆解这次“警告”：两条路到底在分什么

1.1 “造系统”的本质不是写代码，而是搭认知框架

很多人一听“造系统”，第一反应是操作系统、ERP、大型分布式平台这些庞然大物。但我觉得这位设计师说的“系统”，远没有这么狭义。

他说的系统，指的是“有意图、有结构、有边界、能演化的软件体”。哪怕你只做一个几百行的小工具，只要它有清晰的数据模型、合理的模块划分、明确的错误处理和可维护的迭代路径，它就是系统。反过来，一个代码量很大的“项目”，如果没有人说得清它的依赖关系、数据走向和变更影响范围，那它本质上就是一堆代码的堆砌，不能叫系统。

这里有个关键点：造系统最核心的环节不是“写”，而是“想”。你需要在动手之前，甚至在使用AI之前，先把问题域梳理清楚。数据从哪里来，到哪里去，谁在什么条件下触发什么动作，失败的时候怎么兜底，未来哪些地方大概率要变。这些思考形成一套认知框架，代码只是把框架物化出来。

我见过太多人用Cursor走“反方向”——打开编辑器，一句话让AI“给我写一个博客系统”，然后AI哗啦啦生成一堆文件，看起来功能都在，但一加需求就崩，一改逻辑就到处冒烟。这就是典型的没有框架，只有代码。你把AI当成打字机，它就只能还给你一堆需要返工的文字。你把AI当成施工队，前提是你手里得有一张图纸。

1.2 “造垃圾”不是AI的锅，是判断力的缺位

再来看另一条路。“造垃圾”这三个字很刺耳，但它描述的现象在AI时代确实被放大了。

垃圾代码长什么样？第一种，AI生成什么就用什么，完全没有审查，边界条件不管、异常处理不写、安全隐患一堆。第二种，代码能跑但没人说得清逻辑，变量命名随意、模块耦合严重、改一处崩三处。第三种，为了“看起来有产出”，疯狂堆功能，从不考虑一致性和可维护性。这类代码在短期内有产出，在长线上全是负债。

你可能已经发现了，这三类垃圾都有一个共同点——不是AI写出来的，是程序员“允许”它变成这样的。AI没有判断力，它只知道根据你给的指令生成看起来合理的文本。谁来判断这段代码是不是真的符合业务逻辑？谁来决定哪些依赖该引入、哪些不该引入？谁在需求变更时评估影响面？这些全是人的活。

在Cursor里我曾经做过一个实验。同一个功能，我分别让两个不同水平的同事去用AI辅助实现。一个先花20分钟画了数据流和边界条件，再让AI逐个模块生成，最后review了两轮；另一个直接说“给我写一个导出Excel的功能”，把AI生成的代码粘进去就交差了。结果前者半小时搞定，一次通过；后者看着也跑通了，但一遇到空数据就抛异常，字段多了一个就错位。同一个AI，同一个项目，产出天差地别。差别在哪？就在使用者的判断力。

1.3 为什么这句话偏偏是Cursor的设计师说的

这里有个挺有意思的视角。Cursor这家公司做的核心事情，就是“放大程序员的产出”。他们最清楚AI到底改变了工作流的哪个环节——编码执行层被大幅压缩，而人类对需求的理解、对方案的决策、对质量的把控，成了新的瓶颈。

所以这句话与其说是警告，不如说是一线工具厂商对自己用户群体的观察报告。工具越强，使用者的判断力越重要。以前编码能力占一个人竞争力的七成，这种能力需要长时间训练；现在编码可以由AI代劳，剩下的三成反而成了主战场——需求分析、架构设计、代码审查、工程质量。这三成才是人和人拉开差距的地方。

我一个做技术管理的朋友说得更直接：“以前我面试看候选人刷过多少题、写过多少年代码，现在我看他丢给AI一个需求之后，能不能看出AI给的东西哪里有问题。”这句话我琢磨了很久，确实说到了点子上。

2. 别急着恐慌，先看看Cursor现在到底能干什么

2.1 三个核心入口，各自管好一件事

聊完了虚的，说点实的。既然绕不开Cursor，那就先把它的能力边界摸清楚。很多人口中的“用Cursor”，其实只是把它当成一个带自动补全的编辑器，这太浪费了。

以我常用的版本为例，Cursor有三个核心入口，每个入口解决的粒度完全不同。

第一个是Tab补全。它不只是补你光标后面的一行代码，而是能根据当前文件和项目上下文，预测你接下来多处的修改。比如你改了函数签名，它可能连带着把调用处、测试用例一起改掉。这个能力的恐怖之处在于，它理解的不只是语法，而是项目里的变更模式。我实测下来，一个熟练工用Tab可以把日常编码的“手打”时间压缩掉一半以上。

第二个是Cmd/Ctrl+K，选中文档或代码后直接发起内联编辑。这个适合局部修改——选中一段逻辑，让AI优化性能、补上错误处理、换个实现方式。它不会动你选中范围以外的东西，可控性很强。

第三个是Chat和Composer（不同版本叫法略有差异）。Chat适合围绕项目全局提问，“这个模块的调用链是什么”“帮我分析一下这个报错”；Composer则适合跨文件的大改动，“帮我给整个项目加上统一的鉴权逻辑”“按这个表结构生成一套完整的CRUD接口”。这种全局入口才是真正能帮你“造系统”的工具，因为它操作的单位不是一行代码，而是整个模块和架构。

这里要特别提醒一句：别一上来就用Composer做全局改动。它越强，越需要有明确的上下文约束。我之前在项目里直接让它“重构一下订单模块”，它把不该动的定时任务也改了，差点出事故。全局操作之前，先告诉它边界在哪里、哪些文件不要动、遵循什么风格，这样产出的东西才可控。

2.2 一次真实的完整开发流程：从需求到最小可用系统

讲原理容易抽象，我拿自己最近做的一个内部小工具当例子，复盘一遍完整的Cursor辅助开发流程。说实话，做完这个项目之后，我对“造系统”和“造垃圾”这句话的理解深了很多。

需求背景很简单：团队需要一个项目管理看板，能记录任务状态、负责人、截止时间，还要能一键导出周报。技术栈我选了Python加FastAPI加SQLite，前端用简单的HTML加HTMX，没有引入重型框架。这个选择本身就有讲究——它需要快速交付、方便维护，而这两条恰好是AI最擅长加速的方向。

流程分六步走。第一步，我没有打开Cursor就开始写，而是在它的Chat里用自然语言把我的需求完整描述了一遍，附带几个关键约束：单机部署、不需要账号体系但要有简单的访问口令、数据结构要支持以后加字段、导出格式要兼容现有周报模板。我要求Chat先不给代码，只给我一个技术方案和数据模型设计。这一步非常关键，等于让AI先帮我做了一个低成本的需求评审。

第二步，方案确认后，我在Composer里让它按方案生成项目骨架，包括目录结构、数据库初始化和核心依赖。第三步，逐模块填充逻辑——任务增删改查用Cmd/Ctrl+K逐步迭代，前端页面用Chat生成后我手工微调布局。第四步，我把数据流、异常分支、边界条件列成清单，逐条要求AI补上处理逻辑。第五步，让AI写测试用例和接口文档。第六步，我人工做最后的整体review，跑一遍完整流程，处理了几个AI没考虑到的边缘场景。

整个项目从零到可部署，花了一个周末。放在两年前，这个工作量大概需要三四天。但我必须诚实地说，省下来的时间不是因为我“打字变快了”，而是因为“决策变快了”——AI把那些我已经知道答案的、重复性的编码工作做掉了，让我把精力集中在需要判断的地方上。

2.3 中文用户必看的设置与常见坑

既然聊到这里，顺手把中文用户最容易遇到的一批问题集中讲一下。这些都是我在自己机器上踩过的坑，网上答案很零散，我统一整理一遍。

第一个是中文界面问题。很多人说“Cursor怎么设置中文”，其实方法很简单——它本质上是VS Code的内核，直接在扩展商店里搜索“Chinese (Simplified) Language Pack”，安装后重启就变成中文界面了。需要注意，菜单是中文的，但AI对话的语言取决于你用什么语言跟它交流，你打中文它就回中文，打英文就回英文。我的习惯是需求描述用中文，技术细节让它用中文回答，代码注释用英文，这样混着用反而效率高。

第二个是Windows下npm报错的问题。这个其实跟Cursor没直接关系，但用Cursor开发Node项目时特别常见。报错信息长这样：npm : 无法加载文件 C:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本。原因是PowerShell默认执行策略限制。解决办法是用管理员身份打开PowerShell，执行一行命令：Set-ExecutionPolicy RemoteSigned -Scope CurrentUser，然后选择Y确认，重开终端就好了。这是开发环境的基础操作，不涉及任何系统安全底线，放心设置。

第三个是项目索引慢的问题。Cursor为了给你提供全局上下文，首次打开大项目时会建索引，项目特别大的时候会卡很久。解决办法是在项目根目录加一个.cursorignore文件，把node_modules、dist、build、.git这些不需要给AI看的目录排除掉，索引速度会快很多，AI的上下文质量反而更高——它不会被无关文件干扰。

第四个是快捷键冲突。在Windows上Ctrl+K有时会被输入法或截图工具占用，建议在设置里改掉快捷键，避免关键操作失效。第五个是免费额度问题。免费版的请求次数是有上限的，如果你每天重度使用，大概率会触发限流。我的做法是把代码补全类操作走本地模型，跨文件大改再走云端对话，这样额度能撑得更久。

3. 想把路走成“造系统”，这几个能力必须补

3.1 上下文喂得好，AI才能干正事

用Cursor的人都会有个感受：同一个AI，在不同的手里，聪明程度完全不一样。差异的根本，就在上下文的质量上。

很多人的习惯是“一句需求就直接生成代码”，比如“写个函数把列表去重”，这种当然没问题。但一旦到了系统层面，这种问法立刻就不够用了。我给AI描述一个需求的时候，会刻意包含四层信息：业务背景（为什么要做）、输入输出（边界在哪里）、约束条件（不能做什么）、验收标准（怎么算完成）。

举个例子。我不说“帮我写个导出的功能”，而是说：“我们有一个任务列表，需要支持导出成CSV。要求是：字段顺序按页面展示顺序；如果列表为空，要提示用户而不是生成空文件；文件名要带上当前日期；导出的数据量可能很大，不要一次性加载到内存，要流式写入。”到这一步，AI生成的代码，和那种“一句话导出”的代码，完全不是一个质量级别。

这一点的本质是：你在用管理者的思维，而不是执行者的思维。你要让AI理解的是“意图”和“边界”，而不是一个孤立动作。这套做法用在团队里其实也成立——你能把需求讲清楚，不管是人还是AI，给你的产出都会好很多。

3.2 代码审查能力：能看懂、能挑错、能兜底

AI生成的代码，人必须做review。这件事的重要性，在使用时间越长之后感受越深。

项目小的时候，AI生成的几百行代码你还能扫一遍；项目大了，它改了个文件全链路都有影响，这时候你再敢直接信任它的输出，就是给自己埋雷。我的经验是，每次AI完成一次较大改动后，我至少从四个维度去看它写的代码。

第一，数据流对不对。它定义的变量、函数传参、返回结果，在真实数据下能不能走通。第二，边界条件有没有处理。空值、异常值、并发场景、超时情况，这些AI经常想不全。第三，安全和合规有没有隐患。SQL拼接、文件路径、用户输入校验、敏感信息泄露，这类问题AI特别容易忽略，因为它的训练数据里“正确写法”太多了，它默认你就处在安全环境里。第四，代码风格和一致性。变量命名、错误处理方式、日志格式，是不是和项目里其他代码一致。

有一招我强烈推荐：让AI自己先review一遍自己的代码。操作很简单，选中刚生成的代码段，在Chat里跟它说“请从正确性、边界条件、安全隐患、可维护性四个维度审查这段代码，指出问题并给出修改建议”。这一步经常能发现我第一轮没注意到的问题。AI对自己生成的代码做审查，比从零写一遍靠谱得多，因为它的逻辑链条还在上下文里。

3.3 架构思维：别只盯着文件，要盯着系统边界

这是老生常谈，但在AI时代它变了形态。以前做架构设计，要花大量时间在编码细节上；现在有了AI，架构设计的成本反而降低了，但它的价值变得更高了。

裸用AI做系统，最大的问题是“无边界”。我见过有人让AI一口气生成了二十多个文件，内容铺满整个业务逻辑，看起来很强，但每个人物之间没有任何清晰的接口约束，数据模型也是写到哪算哪。这种代码别说扩展了，连读都费劲。问题出在哪？出在人类没有做架构决策，把架构决策权悄悄交给了AI。

我自己在做新项目的时候，会先让AI充当“架构顾问”而不是“代码生成器”。我会问它：这个需求有几种方案？每种方案的优缺点是什么？在什么条件下你推荐哪一种？比如用不用ORM、用不用消息队列、用不用容器，这些关键决策我会让AI把trade-off摆出来，最后我自己拍板。这样AI的强项（信息整合、方案枚举）被用上了，而判断和决策权还在我手里。

还有一点，系统边界不等于代码模块。它还包括数据所有权、服务依赖、部署形态、监控边界。我要提醒的是，AI可以帮你写代码，但很少有AI能帮你判断“这个模块该不该拆出去”。这种判断完全依赖你对业务的理解深度，只能靠积累。

3.4 我常用的一套“AI辅助系统开发”工作流

把以上能力串起来，就是一套可以复用的工作流。我在团队内部推过这套流程，新人上手速度明显变快。

这套流程分五个阶段。阶段一，需求澄清。人机协作把需求写成“用户故事+验收标准+边界条件”，这个阶段不用写代码，Chat只用来整理和追问。阶段二，方案设计。让AI给出技术方案和数据结构设计，人工评审后确认，这个阶段可能要多轮对话，直到方案没有明显缺陷。阶段三，骨架生成。用Composer生成项目骨架、目录结构、核心依赖，人工检查骨架的合理性，这是把架构思维固化的关键一步。阶段四，模块迭代。逐模块使用Cmd/Ctrl+K和Chat完成功能开发，每个模块完成后立刻做代码审查，不积压问题。阶段五，集成联调。让AI生成测试用例、接口文档、部署脚本，人工跑完整链路，处理集成层面的问题。

这套工作流的核心逻辑是：AI负责把大任务拆成可执行的小块并高效完成，人负责在每个关键节点做判断。就像开车，AI是引擎和变速箱，人类是方向盘和刹车。你让引擎自己决定往哪走，那出事只是时间问题。

4. 未来两年，程序员真正的竞争力在哪

4.1 需求拆解：把模糊语言翻译成系统语言

这是我认为AI时代最稀缺的能力，没有之一。现实里的需求，往往只有一句话：“这个报表能不能再加一列”“用户说登录太麻烦了”“老板要看营收数据”。这句话背后是一个模糊的诉求，而把模糊诉求变成清晰可执行的系统需求，需要大量的追问、假设和逻辑推导。

AI不能替你完成这件事，至少现在的模型做不到。它可以在你把需求描述清楚之后给出代码，但无法替你判断用户嘴里的“加一列”到底是指数据库加字段、报表加列、还是导出模板加列——这三个看起来一样，实现路径完全不同，影响范围也完全不同。

锻炼这个能力有一个笨办法：复盘。每次做完一个功能，回去翻一翻当初的需求描述，看看和最终实现差了多远。差出来的部分，就是你的逻辑盲区。长期做这个复盘，你会发现自己在需求澄清阶段问的问题越来越多，AI给你的产出质量也随之提升。

4.2 工程责任感：质量、安全和可维护性的底线

AI时代有个很危险的心理暗示：代码是AI写的，所以出了问题可以怪AI。这种心态，是通往“造垃圾”的捷径。

事实上，代码只要是从你手里提交出去的，署名就是你，责任就是你。你的团队信任的不是AI，是那个“用AI做事但为结果负责”的人。工程责任感不是一句口号，它要落在具体的动作上：你提交的代码有没有测试覆盖，你上线前有没有做回滚预案，你依赖的第三方库有没有License风险，你写的日志是不是在关键时刻能帮你定位问题。

我在带新人的时候，反复强调一件事：AI可以帮你把代码写出来，但它不替你思考“这段代码以后会被怎么维护”。你要想象一个场景——三个月后，项目出问题了，你凌晨两点被叫起来排查，而你面对的是AI生成的一大堆没有注释、没有日志、没有错误处理的代码。那一刻你会后悔当初为什么没有多花十分钟做review。好的工程师，会用这十分钟换一个安稳的夜晚。

4.3 跨界视野与合规自律：新的护城河

AI把编码门槛拉低之后，一个明显的变化是：纯写代码的技能正在贬值，而“编码+行业知识”的复合能力在升值。

同样是写一个库存管理模块，能让AI十分钟写完的人很多；但能告诉AI“库存要区分可用库存和在途库存，还要考虑批次有效期”的人，才是真正被业务需要的人。行业知识从哪里来？只能从行业里来。我认识几个做MES、WMS、ERP这类系统的老程序员，他们的技术栈可能并不新，但对业务流程的理解深度是AI完全无法替代的。这才是他们在AI时代依然值钱的根本原因。

再补一句跟钱相关的。最近“程序员接单被没收”这个话题上了热搜，说的是一些人在接外包项目时因为合同、税务、知识产权归属问题栽了跟头。这件事在AI时代特别值得注意——AI让一个人接单的产能成倍增加了，但合规问题也被成倍放大了。不管你是兼职接单还是独立开发，务必把合同、发票、权属这些事搞清楚。技术能力只是下限，合规自律才是上限。

5. 常见问题与实战排查：AI辅助开发时最常踩的坑

5.1 Cursor使用高频问题速查

这里把我在使用Cursor过程中遇到的高频问题整理成一张速查表，方便你遇到了直接对照处理。

问题现象	根本原因	解决方案
界面是英文的，看不懂菜单	未安装语言包	扩展商店安装“Chinese (Simplified) Language Pack”后重启
Windows终端运行npm报“禁止运行脚本”	PowerShell执行策略限制	管理员运行PowerShell，执行`Set-ExecutionPolicy RemoteSigned -Scope CurrentUser`
打开大项目卡顿，AI响应慢	索引范围过大	根目录添加`.cursorignore`，排除node_modules、dist、build等目录
AI生成的代码脱离项目上下文	没有提供全局信息	改用Chat/Composer，先问“你了解这个项目的结构吗”再下指令
Composer改了一堆不该改的文件	缺少边界约束	操作前明确告诉它“只改哪些文件，不要动哪些内容”
免费额度很快用光	高频全局对话消耗大	Tab补全走本地逻辑，全局改动集中提交，避免频繁大改
服务器响应慢或报错	网络波动或服务端繁忙	错峰使用、切换备用模型、检查代理设置是否干扰了请求

这些坑，大部分是环境配置和使用习惯问题，不是工具本身不好用。遇到问题先定位是哪一层的问题，再动手解决，别一上来就重装。

5.2 关于“用AI”的三条独家心得

最后分享三条我在实际使用中沉淀下来的心得，这三条对我的帮助比任何工具技巧都大。

第一条，把AI当成结对程序员，而不是自动生成器。结对程序员会跟你讨论方案、指出你的盲区、在你跑偏的时候拉你回来。自动生成器只负责把话变成代码。你的心态决定了你和AI协作的上限。我现在每次让AI干活之前，都会先在脑子里过一遍“如果对面坐的是一个比我资深的同事，我会怎么跟他说这个需求”，然后用这个标准去写提示词。

第二条，每次生成后强制自己做一轮“为什么”审查。AI给出的每一个设计决策，我都会问自己：它为什么这么设计？如果是我，我会不会这么做？如果答案是我也不会，那这个设计大概率是对的；如果答案是“我没想过”，那这个地方就是要补课的地方。这套“为什么审查”做下来，你的架构直觉会成长得很快。

第三条，隔一段时间“不带AI”写一次代码。这听起来很反直觉，但我是认真的。AI用久了，你的手感和直觉会被稀释。每隔一两个月，找一个小工具或者一个算法题，完全手写，不借助任何AI工具。不是为了练打字，而是为了保持对代码本身的敏感度——那种“这里要小心”“这里会出问题”的肌肉记忆，只能靠亲自动手维持。有了这种敏感度，你再用AI，才会知道它的输出哪里味道不对。