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/CtrlK选中文档或代码后直接发起内联编辑。这个适合局部修改——选中一段逻辑让AI优化性能、补上错误处理、换个实现方式。它不会动你选中范围以外的东西可控性很强。第三个是Chat和Composer不同版本叫法略有差异。Chat适合围绕项目全局提问“这个模块的调用链是什么”“帮我分析一下这个报错”Composer则适合跨文件的大改动“帮我给整个项目加上统一的鉴权逻辑”“按这个表结构生成一套完整的CRUD接口”。这种全局入口才是真正能帮你“造系统”的工具因为它操作的单位不是一行代码而是整个模块和架构。这里要特别提醒一句别一上来就用Composer做全局改动。它越强越需要有明确的上下文约束。我之前在项目里直接让它“重构一下订单模块”它把不该动的定时任务也改了差点出事故。全局操作之前先告诉它边界在哪里、哪些文件不要动、遵循什么风格这样产出的东西才可控。2.2 一次真实的完整开发流程从需求到最小可用系统讲原理容易抽象我拿自己最近做的一个内部小工具当例子复盘一遍完整的Cursor辅助开发流程。说实话做完这个项目之后我对“造系统”和“造垃圾”这句话的理解深了很多。需求背景很简单团队需要一个项目管理看板能记录任务状态、负责人、截止时间还要能一键导出周报。技术栈我选了Python加FastAPI加SQLite前端用简单的HTML加HTMX没有引入重型框架。这个选择本身就有讲究——它需要快速交付、方便维护而这两条恰好是AI最擅长加速的方向。流程分六步走。第一步我没有打开Cursor就开始写而是在它的Chat里用自然语言把我的需求完整描述了一遍附带几个关键约束单机部署、不需要账号体系但要有简单的访问口令、数据结构要支持以后加字段、导出格式要兼容现有周报模板。我要求Chat先不给代码只给我一个技术方案和数据模型设计。这一步非常关键等于让AI先帮我做了一个低成本的需求评审。第二步方案确认后我在Composer里让它按方案生成项目骨架包括目录结构、数据库初始化和核心依赖。第三步逐模块填充逻辑——任务增删改查用Cmd/CtrlK逐步迭代前端页面用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上CtrlK有时会被输入法或截图工具占用建议在设置里改掉快捷键避免关键操作失效。第五个是免费额度问题。免费版的请求次数是有上限的如果你每天重度使用大概率会触发限流。我的做法是把代码补全类操作走本地模型跨文件大改再走云端对话这样额度能撑得更久。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/CtrlK和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才会知道它的输出哪里味道不对。写在最后我个人的体会是AI时代被淘汰的从来不是程序员而是那些放弃判断、把思考外包给AI的程序员。“造系统”和“造垃圾”的岔路口不在工具而在人。Cursor也好其他AI工具也好本质上是能力的放大器——你本身有系统思维它能帮你把系统做得更大你本身就习惯糊弄它只会让你更快地生产垃圾。最后再分享一个小技巧给AI下指令的时候不要只给它目标要给它约束。约束越明确它的输出就越接近系统化而不是碎片化的“看起来能用”。反过来你在写约束的过程中其实也是在倒逼自己把问题想清楚。这一件小事本身就值得长期做。