Cursor预测程序员行业倒计时：CTO应做好50%裁员计划

提供AI咨询 +AI项目陪跑服务，有需要回复1

前两天跟几个业内同学做了一次比较深入的探讨，时间从15.00到21.00，足足6个小时！

其中有个问题特别有意思：从ChatGPT诞生到DeepSeek爆发2年多了，真正的文字类爆款AI应用是什么？

不出所料，大家一致认为是Cursor ，原因很简单：开源生态的繁荣为代码领域的AI突破提供了关键燃料，而程序员群体对开源的"狂热"在客观上创造了大量高质量语料库。

GitHub上有超过2亿个开源仓库，涵盖几乎所有编程语言和技术栈，这种结构化、标注清晰（通过代码逻辑隐式标注）的文本数据是训练代码模型的理想素材。

而开源项目通过社区协作（Pull Request审核、Issue讨论）天然筛选出较高质量的代码，相比通用文本（如社交媒体内容），代码的噪声更低、逻辑更严谨。

对比其他领域的数据困境：

**医疗AI：**患者数据涉及隐私，获取难度极高；
**法律AI：**判例和合同文本分散且版权敏感；
**金融AI：**交易数据封闭性强，且噪声复杂；

代码领域几乎是唯一一个数据既开放又结构化的大规模垂直场景，这直接导致代码AI的"先发优势"。

但怎么说呢，其结果也许不是好的，因为他真的会大量杀死码农 ，所谓程序员**"杀死"**程序员，老程序员"断送"新生程序员后路，就是如此...

今天，我们就来简单介绍下这个**"程序员AI杀手：Cursor"！**

Cursor

Cursor 是 Anysphere 公司推出智能代码编辑器 。先从资本情况来看看这个产品，恐怖如斯：

2022年获得1100万美元种子轮融资；
2024年完成4亿美元A轮融资；
2024年底，完成1亿美元B轮融资；
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	半自主代码编辑：功能迭代/规模化修改	新功能开发/重复代码生成/中规模代码调整	依赖明确的任务拆解

选择哪种模式取决于具体需求：

构建新项⽬或解决复杂问题时选择Agent模式；
理解和探索代码库或进⾏⼩范围调整选择Ask模式；
专注于添加或修改代码时则选择Edit模式；

Cursor Rules

Cursor Rules 是一系列自定义规则，指导 AI 生成代码、提供建议和进行补全。它们对于提升开发效率和代码质量至关重要：

**提⾼代码质量：**确保 AI ⽣成的代码符合你的编码规范和最佳实践；
**提升开发效率：**减少⼿动编写重复代码的时间，让 AI 帮你完成更多⼯作；
**增强代码⼀致性：**在团队项⽬中，统⼀代码⻛格，避免混乱和冲突；
**定制化 AI ⾏为：**根据你的项⽬需求和个⼈喜好，定制 AI 的⾏为，让它更懂你；

其他技巧

写好提⽰词。明确表达需求，避免模糊或简略的描述，以确保生成的代码准确；
定制项目规则 。
为项目设置符合团队代码风格和规范的 Cursor Rules，减少后续调整工作量；
任务拆解细化 。
拆解任务：将复杂任务分解为更小、更具体的子任务，以提高生成结果的质量；
系统设计阶段，考虑 AI 的参与⽅式 。
在设计时提前规划 AI 的参与方式，充分利用其优势，规避潜在的局限性，提升整体开发效率；

最后进入争议话题：Cursor到达会不会干掉程序员？

Cursor "杀死"程序员

先说结论：Cursor 确实能在某些场景下实现 10 倍甚⾄ 100 倍的效率提升，但在真实业务开发环境中，实际的效率提升通常不到 30%。

为什么差距会这么⼤？接下来，我们详细拆解这个问题：

10倍提效场景

在许多 Cursor 的宣传案例中，我们经常看到这样的⽰例：

复制代码

输⼊提⽰词：
"帮我实现⼀个数独游戏，使⽤ JavaScript 实现。"

⼤约 30 秒后，Cursor 即可完成从需求分析、问题拆解、编码实现到效果预览的完整流程。⽰例效果：

这个数独游戏不仅实现完整，还⽀持响应式布局。

如果让开发者⼿动编码实现，⼤约需要 4-8 ⼩时，⽽ Cursor 仅需 30 秒，提升的效率何⽌ 10 倍？甚⾄ 100 倍。

这类场景的确容易让⼈认为 AI 具备颠覆性的效率提升。但我们需要拆解这些案例的特点：

需求清晰、任务简单：数独游戏的规则固定，AI 只需基于已有的训练数据⽣成代码，⽽不需要额外的上下⽂理解；
**代码质量不重要：**在展⽰"AI 速度"的场景中，代码的健壮性、可维护性往往被忽略。哪怕⽣成的代码不符合团队规范、不易扩展，也不会影响展⽰效果；
极端场景的放⼤：⼀些演⽰视频可能会挑选 AI 表现最优的时刻，⽽忽略它犯错的情况。例如，在 Cursor ⽣成 UI 代码时，可能会遗漏复杂交互的细节，导致实际使⽤时需要⼤量修改；

这种能⼒对于⾮专业开发者、初创团队或需要快速验证 MVP、短平快的原型开发、简单⼯具编写的场景⾮常有帮助，让技术⻔槛⼤幅降低。

然⽽，这仅仅是理想化的场景，现实中的业务开发却远⽐这个复杂得多。

真实场景提效

为了分析 Cursor 在业务开发中的实际提效，我们先拆解前端开发的典型流程，以及各环节的⼤致时间占⽐：

开发环节	时间占比
需求分析	10%
技术方案设计	5%
UI 设计与组件开发	20%
业务逻辑与状态管理	20%
API 集成	15%
路由与权限控制	5%
测试与调试	15%
构建与部署	5%
其他	5%

从表格可以看出，占据开发者较多时间的环节主要是：

需求分析
UI 还原与组件开发
业务逻辑实现
API 集成与调试

接下来，我们分析 Cursor 在这些环节中的实际表现：

需求分析：Cursor 介⼊难度极⼤

原因很简单：

需求分析涉及业务背景、上下⽂理解、利益取舍，需要⼤量主观判断。
需求变更频繁，AI 很难⾼效处理动态变化。
许多需求难以⽤⾃然语⾔准确描述，导致 AI ⽣成的内容不够精准。

结论：Cursor 在需求分析环节⼏乎⽆法发挥作⽤。

UI 还原：能⼒有限，仍需⼤量⼈⼯调整

当前 Cursor 可以基于 Figma 设计稿或截图⽣成 UI 代码，但仍然存在较多问题：

⼤多产品UI⻛格定制化程度⾼，AI 难以精准适配。
解析图⽚时容易丢失信息，导致代码偏差较⼤。
⽆法抽离公共组件，导致代码冗余，复⽤性差。
⽆法直接与现有组件库（如 Ant Design、Material-UI、内部⾃定义组件库）⽆缝对接。

结论：还原效果不稳定，仍需⼿动调整，不如⾃⼰编码实现。

业务逻辑实现：Cursor 提效最明显的环节

如果我们能够把功能模块拆解清楚，提供⾜够的上下⽂，清晰表达要做什么事情，Cursor 确实能够⼤幅提升开发效率。适⽤场景：

⽣成 CRUD 代码（增删改查）
⽣成算法实现（如排序、解析等）
⽣成⼯具函数
代码重构与优化
代码⾃动补全与⽂档⽣成
单元测试⽤例的⽣成
历史代码的阅读理解
潜在的bug分析

结论：Cursor 在这⼀环节能带来 30% 左右的提效。

API 集成与调试：介⼊难度⾼

这里的挑战是：

前后端项⽬分离，AI对于后端项⽬⽆感知，⽆法协同
接⼝字段对接繁琐，隐性使⽤条件多，难以⽤⾃然语⾔描述完整

结论：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工具的掌握以及跨领域的综合能力，而不是仅仅依赖于编写代码的能力。

言尽于此...