在 AI Coding 提效这件事上，我想我的经历让我有充分的发言权。今年上半年，作为团队中的 24 届 JDS，我承接了两位离职同事的业务模块。面对密集的大促需求，我不仅扛住了"以一当三"的交付压力，同时保证了线上零事故。这一切，离不开 Cursor 的深度辅助------我的订阅也从去年的 Pro 升至 Pro+，甚至在大促攻坚与黑马程序员大赛期间，不惜投入每月 200 美元升级至 Ultra Plan，只为将开发效率推向极致。
先上干货：
Cursor 实战 case 展示
以下展示了过去一年中，我使用 Cursor 开发的部分前端项目。这些页面平均的 AI 生成代码占比超过 60%，业务场景横跨 B/C 两端，技术栈全面覆盖 Vue、React、通天塔楼层以及 Tailwindcss、Antd 等多种方案，充分体现了 Cursor 全面的技术能力与显著的效率提升。
移动端
京粉app h5 页面，中秋前夕晚上 22 点业务来电话说想要一个中秋推广的活动页，使用豆包生成背景图，使用cursor进行样式设计，0-1开发仅耗费两个半小时，0:30 完成上线：
信息流广告中间页 ，UI 提供的初版 Lottie 动画是一个完整页面，无法拆分。由于大促排期紧张，等待 UI 支持较慢。为此，我借助 Cursor 直接解读 Lottie 的 JSON 配置文件，成功将火焰、杀价、折扣等核心动效元素，精准地解析为独立的动画，并通过CSS实现，降低了引入资源体积的同时还优化了动画的效果，加速通过了协同工作的卡点：
pc端
东皇钟资损防控平台 ，该项目由研发发起，在没有产品原型和UI设计的情况下，借助 Cursor 结合 Shadcn UI，我独立完成了平台 0-1 的交互与界面构建，最终成果获得了后端与测试团队的一致好评：
落地页中心动态分流 ，该模块核心代码近万行，表单联动逻辑复杂，整体由 Cursor 生成实现。面对 5 层以上的嵌套数据结构，人工理解其层级关系并控制动态联动不仅难度大，且极易出错。通过引入 Cursor，深入解析数据结构与联动逻辑，显著降低研发的理解成本，提升整体开发效率。
精准链路分析项目 ，黑马参赛项目，基于 Cursor 从零启动，单人仅用两天便快速构建出功能完整的精美 Demo。项目完整实现了基于 React Flow 的 JAVA 调用链路展示与组合 、AI 流式报告 及智能Agent对话 等多种高级能力。
工程化
工程化历来是前端领域的核心挑战，充斥着依赖版本冲突与繁杂的配置逻辑。为验证 Cursor 处理系统级任务的能力，我尝试将完整升级流程交由它主导：从依赖分析、版本管理到工程配置更新，让其直接操控终端、执行 npm 命令。
在 京粉 App H5 项目中，我基于 Cursor 成功完成了从旧版本到 Vue 2.7.16 + Webpack 5 的升级全流程：《京粉AppH5 升级 Vue 2.7.16 + Webpack 5 记录》
cursor 提供的升级方案（部分对话）：
更新依赖版本和配置文件（部分对话）：
自动执行终端命令与修复报错（部分对话）：
此外，我也让 Cursor 实现了京粉 h5 从 Webpack 到 Vite 的迁移路径验证，核心构建流程已全部跑通。目前因部分边界场景报错尚未完全解决，未形成正式文章，但该实践已初步验证 Cursor 在复杂工程链路中具备可行的辅助潜力。
Cursor 使用经验分享
重中之重：模型的选择
模型是 AI 的基座，地基不牢，地动山摇。在此直接上结论：无脑选择 Claude 。
这不仅因为在大模型代码能力评测中 Claude 持续领先（如上图所示），更是笔者自 Sonnet 3.5 版本发布以来，实际体验 Claude 在代码生成、逻辑理解与上下文关联方面的能力，相比同时期的模型，确实一骑绝尘。
需要注意的两点：
- 警惕 Auto 模式： 若账号用量不足，Cursor 会自动切换至 Auto 模式，此时可能分配到性能较弱的模型，输出质量会显著下降。该模式可用于技术交流，但不建议用于代码生成与编辑。这也是我升级了订阅计划的原因。
- 关注上下文长度： Cursor 会实时显示上下文使用情况。若接近限制，可主动选择支持更长上下文的模型，或开启多倍计费的 Max Mode 以扩展处理能力，避免上下文丢失带来的输出质量下降。
Talk is cheap. Show me the code.
相信研发同学对这句话都不陌生。这句话，在此处不妨视作 Cursor 对我们提出的要求。与 Cursor 协作的第一原则是：能提供代码片段，绝不用文字描述；能用变量名指代的，绝不用中文名。
手动添加上下文
- 选中代码片段，点击"添加到聊天上下文"按钮（快捷键 Ctrl+I）；
- 若仅提问不希望 Cursor 改动代码，可使用 Ctrl+L；
- 在目录中右键点击文件或文件夹，将其加入对话；
- 在输入框中输入 @，手动选择要引用的文件或目录。
尤其在涉及多文件改动时，主动告知 Cursor 相关文件路径，效果远优于依赖其自行检索。
统一语义表达
在业务沟通中，请始终使用精准的变量名与 Cursor 交互。例如，在价格相关需求中，应直接使用 purchasePrice、wlPrice 等已有变量名，而非口语化的"到手价"、"京东价"。这能确保 AI 在后续所有交互中对概念理解一致，无需反复推理映射关系。
同样，在描述界面元素与交互逻辑时，精准引用标识符而非依赖自然语言描述，是提升 Cursor 理解准确度的关键。
- 定位界面元素 ，应明确指出其
className或id，而非使用模糊的自然语言。
例如：❌ "那个下载按钮" → ✅ "类名为.download-btn的按钮" 或 "ID 为#export-download的元素"。 - 描述交互逻辑，应直接提供回调函数名或方法名称，而非笼统描述行为意图。
例如：❌ "点击按钮后弹窗" → ✅ "在handleConfirmClick函数中调用showModal()方法"。
这种方式能够有效避免界面中存在多个相似元素时造成的歧义，也便于 Cursor 直接在代码库中定位相关逻辑，实现精准编辑。
如何使用 cursor 定位故障？
在"AI 能否取代程序员"的持续讨论中，精准定位并修复线上故障一直被视作人类工程师的关键优势。其根本原因在于：AI 虽能较好地解析静态代码结构，却难以感知系统运行时的动态状态。而很多深层问题------如内存泄漏、线程竞争、环境依赖异常等------恰恰隐藏在静态代码与动态执行之间的鸿沟中，这构成了当前 AI 在故障处理中的认知边界。
那么，我们如何为 AI 架起一座跨越这道鸿沟的桥梁？
答案正在于我们人类最熟悉的调试手段：日志。既然日志能够成为开发者和运行中系统之间的沟通媒介，那么它同样可以转化为 AI 理解运行时行为的关键信息来源。
引导 AI 插入关键日志
当你发现某个功能异常，可指示 Cursor 在关键逻辑路径上添加日志点。只需简单指令，如："请帮我在xx功能相关的函数内部添加 console.log，输出关键变量的值。"
运行代码并捕获日志
执行添加日志后的代码，复制运行时所生成的完整日志输出。
将日志与代码共同提交给 AI 分析
然后再将日志复制发送给cursor，神奇的事发生了，本来它改动了几遍都没能解决的问题，一下就定位到了根因：
技巧背后的逻辑
此方法之所以有效，是因为它将 AI 从纯粹的代码静态分析者，转变为了一个具备"运行时视野"的调试伙伴。通过日志，AI 能够：
- 追踪变量的实际变化轨迹
- 识别逻辑分支的真实执行路径
- 发现数据流与预期不符的具体位置
添加 Rules：让 AI 记住你的工程规范
在使用日志与 Cursor 协作调试时，我遇到了一个典型问题：项目中已有大量日志，新增的调试信息很快被淹没，难以快速定位。我希望 Cursor 在每次插入调试日志时，自动在开头附加 【xx功能调试】 这样的标识，以便在控制台中快速筛选。但若每次对话都重复这一要求，既低效又容易遗漏。
这时，Cursor 的 Rules 功能便可发挥关键作用。你可以在规则中固话这类常见的工程约束或团队规范，例如：
Cursor 支持为不同项目配置独立的规则集，灵活适配各工程的特定规范。具体设置方法详见官方文档：Cursor - 规则
完成规则配置后，我们重新执行之前的调试对话。如下图所示，现在每个 console.log 语句的开头都已自动加上了对应的函数名作为标识，极大方便了在控制台中的筛选与查看：
集成 MCP：拓展能力边界
在使用日志辅助 Cursor 进行调试的过程中，我逐渐发现两个影响效率的典型问题：
- 手动复制繁琐：频繁从控制台复制日志再粘贴至 Cursor，本质上仍是一种重复劳动，与 AI 协作的自动化理念相悖。
- 日志内容杂乱 ：控制台中的引用类型数据（如对象、数组）若不展开或格式不当，难以完整复制；同时，控制台自动插入的代码位置信息（文件路径与行号）常混杂在日志正文中，导致最终提供给 Cursor 的文本结构混乱、难以解析。
上图正是这一问题的直观体现：日志中穿插了源代码位置，而对象数据未完整展开，这样的信息直接交给 Cursor，会影响其理解与推理的准确性。
而此时，正是 MCP（Model Context Protocol）可大显身手的场景。 通过为 Cursor 配置浏览器 MCP 服务，我实现了工作流的质的飞跃：
MCP 赋予 Cursor 直接控制浏览器的能力，使其能够：
- 自动捕获页面截图
- 直接读取控制台日志
- 分析 DOM 结构
当前 Cursor 的浏览器 MCP 仅支持内置窗口与 Chrome。若你使用 Edge 或其他浏览器，可选用微软推出的 Playwright 作为替代方案。
同时，主流前端工具已纷纷提供 MCP 或知识库。以 Ant Design 为例，将其官方知识库 LLMs.txt - Ant Design ，添加到 Cursor 的指定位置：
添加后，Cursor 即可基于官方最新文档提供准确的组件使用建议。
优先选用 AI "擅长"的技术栈
何为 AI "擅长"的技术栈？简单来说：React、TailwindCSS 属于 AI 表现优异的技术栈；微信小程序次之；而像 Taro、uni-app 这类一码多端的框架，则往往是 AI 的弱项。
其背后的逻辑在于数据可见性：开源生态越丰富、网络公开样本越多的技术，大模型在训练时接触到的相关代码就越充分，生成质量自然更高 。反之，闭源、文档稀少的场景，AI 由于缺乏学习材料，表现往往不尽如人意。
在实际的 Taro 项目中，当我尝试让 AI 协助处理 H5、小程序与 RN 三端的代码适配时，其表现确实令人沮丧。我最常遇到的状况是：好不容易让 AI 修复了 H5 端的样式错位，转头就发现小程序端布局崩溃；当 RN 端的交互问题被解决后，H5 端又出现了新的渲染异常。
因此，在 AI Coding 日益普及的背景下，我们不得不重新审视如 Taro、UniApp 等一码多端框架的效率等式：其带来的跨端便利，是否足以抵消因 AI 支持薄弱而导致的额外研发成本？这一点值得深思。
破局之道或许在于深度拥抱 AI 生态。如果这类框架能官方的推出强大的 MCP 服务，将其多端差异和配置逻辑"结构化"地注入 AI 的认知过程，它们将有潜力从当前的"AI 洼地"转变为"智能跨端"的典范。
反直觉：0-1不难，1-100 更难？
读过不少 AI 编程文章的人都会发现，多数内容都在展示如何从 0 到 1 快速搭建应用。但实际上存在一个反直觉的真相：用 AI 从 0 到 1 并不难，真正难的是让它接手和维护存量代码。
在新项目中，AI 面对的是清晰的上下文和现代技术栈。而在存量代码中，它需要理解混乱的命名、隐含的业务逻辑和特殊的实现方式，同时要避免"修复一个 bug 引入两个新 bug"的连锁反应。这就像让新人从头做项目，远比让他修改复杂的老系统要简单。
要让 AI 有效接手存量代码，关键在于像帮助新人一样为它提供清晰的指引。核心方法有二：
为 AI 优化的代码注释
传统的业务背景介绍对 AI 帮助有限，应该采用更代码化的注释方式。避免长篇大论地介绍业务逻辑，而是清晰地指出代码和业务之间的关系，魔法数字的具体含义等。
比如，不要写"这里是价格计算模块，因为历史原因需要区分新老用户"，而应该写"新用户(level=1)享受首单优惠，老用户(level>=2)按原价计算，优惠金额固定为20"。重点注释魔法数字的实际含义、复杂条件判断的业务背景、接口字段的映射关系等。
TypeScript 的天然优势
在接手现有项目上，TypeScript 有着得天独厚的优势。类型定义相当于强制展示了一遍代码结构，如果再加上每个变量的注释，就是现成的知识库。
通过"精准注释 + 完整类型"的组合，即使是最复杂的遗留代码，AI 也能快速理解并安全修改，真正突破从 1 到 100 的瓶颈。
AI Coding时代，优秀研发需要哪些新特质？
聊了这么多 Cursor 的强大表现，难免让人心生疑问：研发是否正在被 AI 取代？恰恰相反，我认为 AI 正在急剧拉大开发者之间的能力差距。今年几乎人人都用上了 AI 编程工具，可能是 Cursor，也可能是 Joycode。但如果你去 review 团队中的代码，就会发现：强者的代码因AI而更优秀，弱者的代码因AI而更紊乱。
结合实践中的经验，我总结了 AI 编码时代一名优秀开发者最应具备的几种核心能力：
1️⃣有责任心，做代码的owner
早期使用Cursor时，我常常陷入一种状态：AI生成的代码占比太高，以至于我对新增部分失去理解和掌控。一旦被问及业务逻辑，或是出现线上问题，甚至会不知从何查起。
这就像一位艺术家通过AI生成画作，很难像对待自己亲笔作品那样珍视并负责。我的改进方案是：在每次 Agent 完成编码之后，阅读其改动总结；在每次提交前，仔细Review Cursor生成代码的Diff。这个过程强制我理解每一行变更，重新建立起对代码的掌控感。
如上图，通常 cursor 在修改完成后都会自动生成总结（也可以通过添加 rules 控制），可以结合总结阅读 diff。
2️⃣代码品味，超越能跑就行
AI生成的代码能运行、测试通过、上线不出事故，就足够了吗？如果你的技术认知水平在 AI 之下，无法判断其实现是否为最佳实践，就可能在系统中埋下无数隐患。
举个例子，上周在体验 relay 设计稿 AI 转代码的时候遇到过一件事：
AI 将图中的商品列表拆分为多行布局------一行图片、一行商品名、一行价格、一行按钮。然而，具备前端组件化思维的同学一眼就能看出，更合理的做法是将其封装为独立的商品卡片组件进行循环渲染：
尽管 AI 的产出在功能上可以运行，测试、产品与用户也难以察觉差异，但这样的结构严重缺乏可复用性。若未来其他页面需要复用相同样式的商品展示，我们将不得不重复编写样式与逻辑，违背了组件化的设计初衷。
因此，我的建议是：坚持阅读高质量的代码，无论是优秀的开源项目，还是身边同事的成熟实现。遇到问题时，不必过度沉溺于调试错误实现，而应主动学习并理解最佳实践，勇于对不合理的代码进行果断重构。。
3️⃣知识广度，做好技术决策
AI在执行明确、具体的指令时表现更佳。这要求开发者既要有广泛的知识储备，又要能精准描述需求。研发就像行政总厨，而AI是精通各菜系的厨师------总厨必须清楚做什么菜的时候，需要备哪些料，使用哪些厨具餐具，才能调度后厨高效产出。
以前端开发为例，若能明确指定使用某个具体的 JavaScript 库，AI 的响应质量将显著提升。例如，在实现"前端解析 Excel 文件"功能时，若直接提示 Cursor 使用 xlsx 库，仅需二三十行代码即可获得目标数据结构：
而若未提供任何技术栈提示，AI 可能倾向于使用原生 JS 实现，代码量激增五倍以上，且逻辑复杂、未经充分验证：
因此，持续在技术社区交流，关注经典工具与前沿方案，是提升技术决策能力的关键。 只有清楚"用什么"和"为什么用"，才能最大限度地发挥 AI 的编码潜力。
4️⃣表达精度，说 AI 听得懂的话
一个不善于使用搜索引擎的人，往往也难以通过AI获得理想结果。 从模糊的需求到清晰的提示词，本质上是一种结构化与抽象能力的体现。
继续用行政总厨的比喻：如果只说"番茄炒蛋要甜一点"，厨师会困惑------是加糖还是加番茄酱？如果能明确"300克番茄配3个鸡蛋，需要加5克白糖"，产出质量就有保障。
精准表达的能力，与个人知识储备和语言表达能力相关，不好举例说明。建议有意识地阅读完整书籍、观看有深度的长播客，避免被短视频时代的碎片化表达削弱这种能力。
对未来的展望
笔者作为 Joycode 的早期深度用户，为其界面交互提出过被采纳的优化建议；我也是团队中最早体验并给研发同事安利 Cursor，给产品同事安利使用 v0 生成原型图的人，我很高兴看到如今公司已全面拥抱 AI。
然而，当业产研测各环节都在大力推进"+AI"时，我不禁思考：AI 提效，是否真的等同于在现有流程的每个环节简单叠加 AI？
这让我想起从功能机到智能机的过渡时期：早期的触摸屏设备仍保留着大量实体按键，或者在屏幕底部保留了触摸版的菜单键和返回键，交互逻辑仍是旧时代的延伸。直到多年后，真正的全面屏与手势导航出现，才彻底释放了触摸交互的潜力。
我们当前对 AI 的应用，或许正处在那个"仍带着实体按键"的阶段。 若只满足于在原有流程上"+AI"，恐怕难以触及其真正的变革性潜力。AI 不应仅是效率工具，更应成为流程重构与体验重塑的催化剂------而这，才是我们接下来需要共同探索的方向。