Cursor预测程序员行业倒计时CTO应做好50裁员计划
提供 AI咨询 + AI项目陪跑 服务，有需要回复1 前两天跟几个业内同学做了一次比较深入的探讨，时间从15.00到21.00，足足 6个小时！ 其中有个问题特别有意思： 从ChatGPT诞生到DeepSeek爆发2年多了，真正的文字类爆款AI应用是什么？ 不出所料，大家一致认为是 Cursor ，原因很简单： 开源生态的繁荣为代码领域的AI突破提供了关键燃料，而程序员群体对开源的“狂热”在客观上创造了大量高质量语料库。 GitHub上有超过2亿个开源仓库，涵盖几乎所有编程语言和技术栈，这种结构化、标注清晰（通过代码逻辑隐式标注）的文本数据是训练代码模型的理想素材。 而开源项目通过社区协作（Pull Request审核、Issue讨论）天然筛选出较高质量的代码，相比通用文本（如社交媒体内容），代码的噪声更低、逻辑更严谨。 对比其他领域的数据困境： 1. 医疗AI： 患者数据涉及隐私，获取难度极高； 2. 法律AI： 判例和合同文本分散且版权敏感； 3. 金融AI： 交易数据封闭性强，且噪声复杂； 代码领域几乎是 唯一一个数据既开放又结构化的大规模垂直场景，这直接导致代码AI的“先发优势”。 但怎么说呢，其结果也许不是好的，因为他真的会 大量杀死码农 ，所谓程序员 “杀死” 程序员，老程序员“断送”新生程序员后路，就是如此... 今天，我们就来简单介绍下这个 “程序员AI杀手：Cursor”！ ## Cursor Cursor 是 Anysphere 公司推出 智能代码编辑器 。先从资本情况来看看这个产品， 恐怖如斯 ： 1. 2022年获得 1100万美元 种子轮融资； 2. 2024年完成 4亿美元A轮融资 ； 3. 2024年底，完成 1亿美元B轮融资 ； 4. 2025年3月，Anysphere正与投资者洽谈新一轮融资，目标估值接近 100亿美元 ； Cursor基于 VS Code 深度开发，提供⾃然语⾔⽣成代码、上下⽂感知补全、实时错误诊断以及修复等 AI 增强功能 ，并能⽆缝融⼊现有开发环境，显著提升开发效率与代码质量。 这里先来个案例尝尝鲜： ### 实际案例
你是⼀位优秀的 Java ⼯程师，现在需要根据以下需求构建⼀个 Java Web 系统。
技术栈要求
Spring Boot + MyBatis + MySQL + Maven
功能需求
你需要开发⼀个简单的图书管理系统，主要包含以下三个管理模块：
图书管理：包括图书的增、删、改、查功能，每本图书需要关联出版社和货架。
出版社管理：独⽴管理出版社信息，⽀持增、删、改、查。
货架管理：独⽴管理货架信息，⽀持增、删、改、查。
数据库设计
设计数据库结构，创建合适的表，确保数据关联性（如图书与出版社、货架的关联关系）。
注意数据库设计不要设计外键的关联关系
⽣成 init.sql ⽂件，并将其放⼊ 项⽬/scripts/ ⽬录下。
开发要求
采⽤ Spring Boot 构建后端，并使⽤ MyBatis 进⾏数据库操作。
设计 RESTful API，提供对应的增、删、改、查接⼝。
采⽤ Maven 进⾏项⽬构建和依赖管理。
项⽬结构清晰，遵循分层架构（如 controller、service、mapper、entity 等）。
编写适当的测试代码，确保接⼝功能正常。
请按照以上需求进⾏开发，并确保代码清晰、可读、易维护。
上图是Cursor完成后⽣成的readme⽂件，项⽬可以正常启动，我阅读了⼤部分代码，都是正常可运⾏， 但是测试⽤例并没有⽣成。 接下来，我们需要让他将测试⽤例⽣成，另外我会给他增加⼀个需求，就是查询货架的时候，需要将上⾯关联的图书返回： Cursor最终⽣成了所有接⼝的测试⽤例，货架管理模块要求查询时返回关联图书列表功能也添加成功。 虽然Cursor通过MyBatis的 collection 标签实现了延迟加载，但这种⽅式与惯⽤的 JOIN 查询结合DTO映射模式存在实现路径差异，并不符合常见开发习惯和实际项⽬中代码⻛格。 以下是一些实际技巧，大家可参考： ## Cursor技巧
三种模式
Cursor提供了三种不同的模式：Agent、Ask和Edit： 模式 核心能力 使用场景 边界 Agent 全自主项目构建：代码生成、Shell命令执行、上下文关联 创建完整项目/复杂任务（重构/纠错/自动化） 需清晰需求描述 Ask 交互式代码问答：代码库探索/局部修改/调试支持 理解代码逻辑/快速调试/单文件问题解决 不适合复杂系统级设计 Edit 半自主代码编辑：功能迭代/规模化修改 新功能开发/重复代码生成/中规模代码调整 依赖明确的任务拆解 选择哪种模式取决于具体需求： 1. 构建新项⽬或解决复杂问题时选择Agent模式； 2. 理解和探索代码库或进⾏⼩范围调整选择Ask模式； 3. 专注于添加或修改代码时则选择Edit模式；
Cursor Rules
Cursor Rules 是一系列自定义规则，指导 AI 生成代码、提供建议和进行补全。它们对于提升开发效率和代码质量至关重要： 1. 提⾼代码质量： 确保 AI ⽣成的代码符合你的编码规范和最佳实践； 2. 提升开发效率： 减少⼿动编写重复代码的时间，让 AI 帮你完成更多⼯作； 3. 增强代码⼀致性： 在团队项⽬中，统⼀代码⻛格，避免混乱和冲突； 4. 定制化 AI ⾏为： 根据你的项⽬需求和个⼈喜好，定制 AI 的⾏为，让它更懂你；
其他技巧
- 写好提⽰词 。明确表达需求，避免模糊或简略的描述，以确保生成的代码准确；
- 定制项目规则 。 为项目设置符合团队代码风格和规范的 Cursor Rules，减少后续调整工作量；
- 任务拆解细化 。 拆解任务：将复杂任务分解为更小、更具体的子任务，以提高生成结果的质量；
- 系统设计阶段，考虑 AI 的参与⽅式 。 在设计时提前规划 AI 的参与方式，充分利用其优势，规避潜在的局限性，提升整体开发效率； 最后进入争议话题： Cursor到达会不会干掉程序员？ ## Cursor “杀死”程序员 先说结论： Cursor 确实能在某些场景下实现 10 倍甚⾄ 100 倍的效率提升，但在真实业务开发环境中，实际的效率提升通常不到 30%。 为什么差距会这么⼤？接下来，我们详细拆解这个问题： ### 10倍提效场景 在许多 Cursor 的宣传案例中，我们经常看到这样的⽰例： ``` 输⼊提⽰词： "帮我实现⼀个数独游戏，使⽤ JavaScript 实现。"
⼤约 30 秒后，Cursor 即可完成从需求分析、问题拆解、编码实现到效果预览的完整流程。⽰例效果： 这个数独游戏不仅实现完整，还⽀持响应式布局。 如果让开发者⼿动编码实现，⼤约需要 4-8 ⼩时，⽽ Cursor 仅需 30 秒，提升的效率何⽌ 10 倍？甚⾄ 100 倍。 这类场景的确容易让⼈认为 AI 具备颠覆性的效率提升。但我们需要拆解这些案例的特点： 1. 需求清晰、任务简单 ：数独游戏的规则固定，AI 只需基于已有的训练数据⽣成代码，⽽不需要额外的上下⽂理解；
2. 代码质量不重要： 在展⽰“AI 速度”的场景中，代码的健壮性、可维护性往往被忽略。哪怕⽣成的代码不符合团队规范、不易扩展，也不会影响展⽰效果；
3. 极端场景的放⼤： ⼀些演⽰视频可能会挑选 AI 表现最优的时刻，⽽忽略它犯错的情况。例如，在 Cursor ⽣成 UI 代码时，可能会遗漏复杂交互的细节，导致实际使⽤时需要⼤量修改；
这种能⼒对于⾮专业开发者、初创团队或需要快速验证 MVP、短平快的原型开发、简单⼯具编写的场景⾮常有帮助，让技术⻔槛⼤幅降低。 然⽽，这仅仅是理想化的场景，现实中的业务开发却远⽐这个复杂得多。 ## 真实场景提效
为了分析 Cursor 在业务开发中的实际提效，我们先拆解前端开发的典型流程，以及各环节的⼤致时间占⽐： 开发环节 时间占比 需求分析 10% 技术方案设计 5% UI 设计与组件开发 20% 业务逻辑与状态管理 20% API 集成 15% 路由与权限控制 5% 测试与调试 15% 构建与部署 5% 其他 5% 从表格可以看出，占据开发者较多时间的环节主要是： 1. 需求分析
2. UI 还原与组件开发
3. 业务逻辑实现
4. API 集成与调试
接下来，我们分析 Cursor 在这些环节中的实际表现： ### 需求分析：Cursor 介⼊难度极⼤
原因很简单： 1. 需求分析涉及业务背景、上下⽂理解、利益取舍，需要⼤量主观判断。
2. 需求变更频繁，AI 很难⾼效处理动态变化。
3. 许多需求难以⽤⾃然语⾔准确描述，导致 AI ⽣成的内容不够精准。
结论： Cursor 在需求分析环节⼏乎⽆法发挥作⽤。 ### UI 还原：能⼒有限，仍需⼤量⼈⼯调整
当前 Cursor 可以基于 Figma 设计稿或截图⽣成 UI 代码，但仍然存在较多问题： 1. ⼤多产品UI⻛格定制化程度⾼，AI 难以精准适配。
2. 解析图⽚时容易丢失信息，导致代码偏差较⼤。
3. ⽆法抽离公共组件，导致代码冗余，复⽤性差。
4. ⽆法直接与现有组件库（如 Ant Design、Material-UI、内部⾃定义组件库）⽆缝对接。
结论： 还原效果不稳定，仍需⼿动调整，不如⾃⼰编码实现。 ### 业务逻辑实现：Cursor 提效最明显的环节
如果我们能够把功能模块拆解清楚，提供⾜够的上下⽂，清晰表达要做什么事情，Cursor 确实能够⼤幅提升开发效率。适⽤场景： 1. ⽣成 CRUD 代码（增删改查）
2. ⽣成算法实现（如排序、解析等）
3. ⽣成⼯具函数
4. 代码重构与优化
5. 代码⾃动补全与⽂档⽣成
6. 单元测试⽤例的⽣成
7. 历史代码的阅读理解
8. 潜在的bug分析
结论： Cursor 在这⼀环节能带来 30% 左右的提效 。 ### API 集成与调试：介⼊难度⾼
这里的挑战是： 1. 前后端项⽬分离，AI对于后端项⽬⽆感知，⽆法协同
2. 接⼝字段对接繁琐，隐性使⽤条件多，难以⽤⾃然语⾔描述完整
结论： Cursor 在 API 集成环节的作⽤有限，调试环节⼏乎⽆能为⼒。 ### 小结
综上所述，在完整的前端开发流程中，Cursor 能真正带来显著提效的环节主要是业务逻辑编码实现，在其他环节的作⽤⾮常受限。 整体来看： Cursor 实际带来的提效约为 20%-30%， 那么，是否意味着我们只能接受这个上限？并不⼀定。 ## 何重塑⼯作流
⾃媒体宣传中 Cursor 提效可达 10 倍，⽽实际业务开发中仅提升 30%，核⼼区别在于 上下⽂的缺失。 当前 Cursor 在代码理解和⽣成⽅⾯已⾮常强⼤，要让 Cursor 在业务开发中发挥更⼤作⽤，我们需要调整⼯作流，使其更适应 Cursor 参与。 关键在于 清晰表达需求并提供⾜够的上下⽂。 如果 cursor的实现未达预期，先反思⾃⼰是否描述清楚 ⸺ 毕竟，AI ⽆法读懂你的⼼思。 ### 分治思维，逐步验证
在使⽤Cursor agent模式的时候，切记不要⼀次性完成⾮常庞⼤的功能再验证，不然可能会越改越乱。 最佳的实践： 将复杂的功能拆解为多个⼩的独⽴功能模块，每完成⼀个⼩的独⽴功能就验证是否正确，如果正确在进⾏下⼀个功能模块。 ### 结构化需求，让 AI 能够更好的理解
从产品源头采⽤更标准化的需求⽂档格式，如 Markdown、JSON 结构化描述需求。团队可共享这份结构化的需求⽂档，避免开发⼆次表达导致信息失真。 结合 AI Prompt 设计优化，提⾼输⼊的精准度。 利⽤反向费曼学习法，通过Cursor chat模式，让AI反诉需求，看他是否真正理解了你的需求，并让他提出质疑，去挖掘你更深层次的需求或者⽋考虑的场景。 ### 提供 UI 设计标准规范、组件库与 API ⽂档等更多上下⽂
通过Cursor rules提供上下⽂信息： ### 代码与测试⼀体化
让 Cursor⽣成代码的同时⽣成单元测试，减少调试时间。 结合 CI/CD 流程，让 Cursor直接检测代码问题。 ...... ## 结语
Cursor 作为 AI 辅助开发⼯具，确实能够提升开发效率，但如果⼯作流不变，仅仅依赖 AI 来适应当前流程，最终的提升可能不会超过 30%。 真正的 10 倍效率提升，不是 AI 本⾝带来的，⽽是 结合 AI 进⾏⼯作流重塑的结果。 如果我们能够优化需求管理、UI设计标准及组件库对接、API 接⼝集成、测试⾃动化等环节，AI辅助编程⼯具的潜⼒才能被真正释放，实现指数级的效率提升。 最后，依旧要 让各位焦虑一下 ： 据GitHub数据，AI已参与46%的新代码生成（2023），Gartner预测2027年AI将承担40%开发任务。 根据普华永道的报告，到2026年，AI将迫使程序员转向更具创造性和战略性的角色，例如AI系统的设计、优化和维护。 因此，程序员未来的竞争力将取决于其对AI工具的掌握以及跨领域的综合能力，而不是仅仅依赖于编写代码的能力。 言尽于此 ...
> 原文链接: https://www.cnblogs.com/yexiaochai/p/18804067
