前端秋招必看｜简历写"熟悉Cursor"，面试被追问怎么办？

写在前面

2024年下半年，我在参与公司的校招面试时，遇到了一个有趣的现象：简历上写"熟悉Cursor"的候选人越来越多，但真正能说清楚的不到20%。大部分人要么背功能列表，要么说"就是用AI写代码"，这让我意识到，这道题背后藏着更深的考察逻辑。

这篇文章不是教你背话术，而是想和你聊聊：面试官为什么要问这个问题？他想从你的回答里看到什么？以及，你应该怎样真实地展现自己的能力。

一、面试官到底在考什么？

从一次真实面试说起

上个月面试了一个应届生，简历上写着"熟练使用Cursor进行前端开发"。我问他："能具体说说怎么用Cursor的吗？"

他的回答是："就是写注释，然后AI自动生成代码，很方便，效率提升了很多。"

我追问："生成的代码质量怎么样？"

他说："挺好的，基本能用。"

再问："遇到过什么问题吗？"

他想了想："有时候生成的代码风格不太一样，需要改一改。"

最后我问："你知道什么是上下文工程吗？"

他愣住了。

这个候选人最终没有通过。不是因为他不会用Cursor，而是因为我从他的回答里看到了三个危险信号：

第一，他对工具的理解停留在表面。他只知道"写注释生成代码"，但不知道为什么有时候生成得好，有时候生成得不好。这说明他没有建立系统的方法论，只是在碰运气。

第二，他对代码质量的认知不清晰。"基本能用"是个很模糊的标准。在实际项目中，代码需要符合团队规范、类型要严格、性能要优化、错误要处理。他说不出具体的质量评判标准，说明他可能没有认真review过AI生成的代码。

第三，他对技术的学习不够主动。上下文工程是2024年下半年就开始流行的概念，到2025年已经是Cursor使用的核心。如果一个人真的在深度使用这个工具，不可能不了解这个概念。这反映出他可能只是"用着"，而不是"学着"。

面试官真正想看到什么

坐在面试桌对面这么多年，我发现从2024年开始，问AI工具的面试官越来越多。到了2025年，这已经成为前端面试的标配题目。但这道题从来不是在考你会不会用某个工具，而是通过你对工具的理解，来判断你的几个核心能力：

学习能力是最基础的。技术迭代这么快，Cursor这样的新工具从出现到流行不过一年多时间，你能不能主动去学习和掌握？更重要的是，你学的是表面功能，还是深入理解了背后的方法论？

工程能力是更关键的。会用工具只是第一步，怎么在实际项目中应用、怎么保证代码质量、怎么与团队协作、怎么建立规范，这些才是工程能力的体现。我见过太多同学，用AI写代码很快，但生成的代码要么风格混乱，要么bug一堆，code review的时候被打回来好几次。这不是提升效率，而是在制造麻烦。

思考深度是最容易被忽视的。你有没有想过，为什么同样的工具，有的人用得很好，有的人用得很差？为什么有时候AI生成的代码质量高，有时候质量低？如果你能把这些问题想清楚，说明你不是在机械地使用工具，而是在理解工具背后的原理。

技术敏感度在2025年变得更重要了。MCP协议、Rules配置、上下文工程，这些概念都是近一年才开始流行的。如果你还停留在"写注释生成代码"的认知水平，说明你对技术的敏感度不够，没有跟上行业的发展。

说到底，面试官想看到的是：你是一个会学习、会思考、有方法论的工程师，而不只是一个会用工具的操作员。

二、从"写注释生成代码"到"上下文工程"

为什么你的Cursor用不好

很多人刚开始用Cursor的时候，都是这样的：

// 创建一个用户列表组件，包含搜索、分页功能

然后AI就生成了一堆代码。你看着还不错，复制粘贴到项目里，然后发现：

• 代码风格和项目其他部分完全不一样
• 用的是class组件，而项目统一用函数组件
• 类型定义很随意，到处是any
• 状态管理方式也不对，项目用的是Redux，它生成的是useState

于是你开始改，改来改去花了一个小时，最后想想：还不如自己从头写。

这就是大部分人的困境：AI是用了，但好像没什么帮助。

问题出在哪里？其实很简单：AI不了解你的项目。

你给它一句话，它只能按通用的模式生成代码。它不知道你们团队的编码规范是什么，不知道你的项目用的是什么技术栈，不知道你们怎么管理状态，不知道你们怎么处理错误。就像你找了一个完全不了解你们公司业务的外包团队，给他们一句需求描述，他们能写出完全符合你们标准的代码吗？显然不能。

这就是为什么会有"上下文工程"这个概念。

什么是上下文工程

上下文工程的核心思想很简单：让AI理解你的项目。

具体来说，就是通过系统化的方法，把你的项目信息、编码规范、技术约束、业务逻辑传递给AI，让它生成的代码不是"通用的"，而是"适合你项目的"。

这听起来很抽象，我们来看一个实际的例子。

假设你要用Cursor创建一个用户管理页面，传统做法是这样：

提示：创建一个用户列表页面，包含搜索、分页、编辑功能

AI会给你生成一些代码，但这些代码可能和你的项目格格不入。

现在用上下文工程的方法，你需要先做三件事：

第一步，配置项目规范。在项目根目录创建一个.cursorrules文件，告诉AI你的项目是什么样的：

# 技术栈
- Vue 3.4 with Composition API
- TypeScript 严格模式
- Pinia 状态管理
- Element Plus UI库

# 编码规范
- 组件必须使用 <script setup> 语法
- Props类型必须用 defineProps<T>() 明确定义
- 禁止使用any类型，必要时使用unknown
- 可复用逻辑必须抽离为composables

# 架构模式
- API调用统一使用 @/api/request.ts
- 状态管理优先用composables，复杂场景用Pinia
- 错误处理使用统一的errorHandler

这个文件就像是给AI的一份项目手册，告诉它遵循什么规则。

第二步，提供参考代码。光有规则还不够，AI需要看到具体的例子。你可以用@符号引入项目中已有的代码：

@components/ProductList.vue
@composables/useTable.ts
@api/user.ts

这些文件告诉AI：这是我们项目里已有的类似实现，你可以参考这种模式。

第三步，明确需求并迭代。现在你再给提示：

基于以上上下文，创建用户管理页面：
1. 先实现基础的列表渲染
2. 使用项目中的useTable处理分页逻辑
3. 参考ProductList的搜索实现

这时AI生成的代码就完全不一样了：

• 自动使用了<script setup>语法
• 类型定义严格，没有any
• 复用了项目的useTable composable
• API调用方式和项目统一
• 错误处理也符合项目规范

更重要的是，你不是一次性生成所有代码。你先生成基础结构，review一遍，确认没问题，再加搜索功能，再review，再加表单，再review。每一步都在你的掌控之中。

这就是上下文工程的威力：不是让AI瞎写代码，而是让AI理解你的项目后，生成符合规范的代码。

从原理上理解为什么这样做有效

你可能会好奇：为什么配置了Rules和上下文，AI就能生成更好的代码？

这要从大语言模型的工作原理说起。GPT这类模型本质上是在做模式匹配和续写。当你给它一段文本，它会根据训练数据中的模式，预测接下来最可能出现的内容。

如果你只给它一句话："创建用户列表页面"，它看到的上下文很少，只能按照训练数据中最常见的模式来生成。而训练数据来自整个互联网，包含各种不同风格、不同技术栈的代码，它生成的自然是一种"平均值"——既不特别好，也不特别差，但肯定不符合你的具体需求。

但如果你先给它看了几千个token的上下文：你的.cursorrules文件、你的参考代码、你的类型定义，那么在它眼里，"创建用户列表页面"这个任务就有了明确的约束。它会想："这个项目用Vue 3 Composition API，那我就不能用Options API；这个项目的表格组件都用useTable，那我也应该用；这个项目的API调用都用request函数，那我也应该这样。"

本质上，你是在用上下文引导模型的生成方向。这就像你去一家新公司，如果什么背景都不给你，让你做个需求，你肯定不知道怎么做符合他们的标准。但如果给你看几个类似的实现，给你一份编码规范文档，你就知道该怎么做了。AI也是一样的道理。

这也解释了为什么要分步迭代。每次生成后，你review代码、给出反馈，这些信息都会加入到上下文中，指导下一次生成。这个过程就像你和一个新同事结对编程：一开始他可能不太了解项目，但随着你们不断交流、调整，他会越来越理解你的意图。

理解了这个原理，你就明白了：用好Cursor的关键不是提示词写得多好，而是上下文建立得多好。

三、面试时应该怎么回答

不要背话术，而要建立自己的理解

我最不希望看到的，就是有人把这篇文章当成面试宝典，把某段话术背下来去面试。因为面试官问的不是"标准答案"，而是"你的理解"。

如果你只是背话术，面试官随便追问两句，你就露馅了。比如他问："你提到了上下文工程，那你觉得上下文是越多越好吗？"如果你没有真正理解，只是背了"要用@引入参考代码"，你可能就答不上来了。

正确答案是：不是的。上下文太多会稀释关键信息，还会浪费token。应该只引入最相关的3-5个文件，按层次组织：类型定义、工具函数、参考组件。如果初次生成的效果不好，再补充上下文。

你看，这不是背出来的，而是理解了原理后自然得出的结论。

所以我的建议是：如果你真的用过Cursor，就根据自己的真实经验来回答；如果没深度使用过，那就诚实说明你的理解程度，然后表达学习意愿。

一个完整的回答示例

假设面试官问："你简历上写熟悉Cursor，能具体说说吗？"

我会这样回答（注意，这是我的回答逻辑，不是让你背诵的话术）：

"我在做毕设项目的时候用Cursor做了主要的开发工作。一开始我也是直接写提示词让它生成代码，但发现效果不太好，生成的代码风格很乱，和我已有的代码对不上。后来我了解到上下文工程这个概念，才意识到问题出在哪里。

我的做法是，先在项目里配置了一个.cursorrules文件，定义了一些核心的编码规范，比如我用Vue 3的Composition API、TypeScript要严格模式、状态管理用composables模式等等。然后每次要写新功能，我会先用@符号引入项目里类似的代码，让AI理解我的项目是怎么组织的。

比如我要写一个用户管理页面，我会先引入已有的商品列表页面作为参考，引入我的useTable composable，引入API调用的封装函数。这样AI生成的代码就和我的项目风格统一了，基本不用大改。

但我也不是盲目信任AI。每次生成代码后，我都会仔细review：类型定义是否严格、错误处理是否完善、性能有没有问题。我还会特别注意边界情况，因为AI经常只考虑happy path。

效果的话，我做了简单的统计，像标准的CRUD页面，以前手写要3-4个小时，现在基本1.5到2个小时能完成，而且代码质量反而更好了，因为每次生成后我都会认真review。

当然这个过程中也踩了不少坑，比如一开始我把整个components文件夹都引入进来，结果AI反而被无关信息干扰了，生成的代码质量更差。后来我才明白要精准地引入最相关的文件。还有一次AI生成的useEffect依赖数组有问题，导致了无限循环，那次之后我每次都会特别注意这种地方。

总的来说，我觉得Cursor是个很好的工具，但关键是要建立方法论，不能只是'写注释生成代码'那么简单。"

你看，这个回答的核心不是"我会用Cursor"，而是：

• 我经历了从不会用到会用的过程（说明真实性）
• 我理解了上下文工程的原理（说明有方法论）
• 我有具体的实践经验和数据（说明不是纸上谈兵）
• 我遇到过坑并解决了（说明深度使用）
• 我对代码质量有把控（说明不盲目依赖）

这些信息综合起来，给面试官的印象就是：这是个会学习、会思考、有工程能力的人。

如果被追问怎么办

面试官如果对你的回答感兴趣，往往会继续追问。这是好事，说明你引起了他的注意。常见的追问方向有几个：

追问Rules配置的细节。这时你可以具体说说你的.cursorrules里都写了什么，为什么要这样配置。重点是展现你的思考：你不是随便写几条规则，而是根据项目的实际情况，提炼出最核心的约束。比如你们项目有个特殊的错误处理机制，你就把它写进Rules，确保AI生成的代码都遵循这个机制。

追问MCP这个新概念。MCP（Model Context Protocol）是2024年底Anthropic提出的标准协议，用于让AI更标准化地访问外部数据源。如果你了解，可以简单说说你的理解：它解决的是AI怎么安全地访问数据库、API文档、内部知识库这些资源。如果不了解也没关系，诚实说"这个我还没深入研究，但听起来是为了解决上下文信息来源的标准化问题，我会找时间了解一下"。这样的回答反而显得真诚。

追问会不会太依赖工具。这是个陷阱问题。如果你说"不会"，面试官会觉得你缺乏反思；如果你说"会"，面试官又会担心你的基础能力。正确的回答方式是承认确实有这个风险，但你在主动避免。比如你每周会做LeetCode保持算法能力，会手写核心组件理解原理，会阅读优秀的源码学习设计模式。关键是让面试官看到：你在用AI提升效率的同时，也在持续提升自己的基础能力。

追问AI生成的代码质量。这时候不要说"挺好的"这种模糊答案，而要具体分析。AI在哪些方面做得好（代码规范、类型定义），在哪些方面容易出问题（边界情况、性能优化、复杂逻辑），你是怎么把控质量的（review checklist、测试、性能分析）。最好能举一两个具体的例子：某次AI生成的代码有什么问题，你是怎么发现的，怎么改进的。

记住，追问不是为难你，而是想更深入地了解你。你只需要真实地展现你的思考过程就好。

四、具体的技术实践

Rules配置的关键点

.cursorrules这个文件看起来简单，其实很有讲究。我见过很多同学的Rules配置要么太简单（只写了"用Vue 3、TypeScript"），要么太复杂（写了五六千字的详细规范）。

一个好的Rules配置应该抓住三个核心：

技术栈约束是基础。你要明确告诉AI：我用的是Vue 3还是React，是Vue 2的Options API还是Vue 3的Composition API，TypeScript是什么模式，状态管理用什么方案。这些信息直接决定了AI生成代码的基本框架。

编码规范是关键。这部分不是写给人看的编码规范，而是AI能理解的约束。比如"组件必须使用<script setup>"比"尽量使用Composition API"更明确；"Props类型用defineProps<T>()定义"比"Props要有类型"更具体。你要把规范翻译成AI能执行的指令。

架构模式最容易被忽视，但最重要。你的项目有一些特定的模式：API怎么调用、状态怎么管理、错误怎么处理、可复用逻辑怎么抽离。这些模式如果不写进Rules，AI就不知道，会按照它认为的"通用最佳实践"来，结果和你的项目格格不入。

举个例子，如果你的项目有个约定：所有列表页面的分页、搜索、加载状态都用一个叫useTable的composable来处理，那你就应该在Rules里写清楚：

# 列表页面规范
- 使用 @/composables/useTable 处理列表逻辑
- 不要自己实现分页、搜索状态管理
- 参数格式：useTable({ fetchFn, defaultPageSize })

这样AI在生成列表页面时，就会自动使用你的useTable，而不是自己重新实现一套。

Rules文件不需要太长，500到1000字足够了。太长了反而会占用太多上下文空间，影响其他信息的传递。关键是要准确、具体、可执行。

上下文引入的策略

用@符号引入文件看起来很简单，但其实有策略。

很多人的第一反应是：引入越多越好吧？把整个components文件夹、整个utils文件夹都引入进来，让AI全面了解项目。

这是错的。

上下文空间是有限的，大部分大语言模型的上下文窗口是10万到20万token。你引入的文件越多，每个文件能传递的有效信息就越少，AI反而会被无关信息干扰。就像你去一个图书馆找资料，给你10本相关的书比给你100本乱七八糟的书更有帮助。

正确的策略是分层引入：

最底层是类型定义。如果你要生成涉及某个业务实体的代码，先引入这个实体的类型定义文件。比如要做用户管理，就引入@types/user.ts。类型定义通常很简洁，但能让AI准确理解数据结构。

第二层是工具函数和基础hooks。比如你的API调用封装、常用的composable、工具函数。这些是项目的基础设施，AI需要知道怎么使用它们。

第三层是参考组件。找一个和你要实现的功能最相似的已有组件，引入进来。AI会学习这个组件的结构、命名方式、处理逻辑。注意只引入一个最相似的，不要引入多个类似组件。

如果初次生成的效果不好，再考虑补充上下文。比如生成的错误处理不对，就补充一个有正确错误处理的例子；API调用方式不对，就补充API封装文件。

一般来说，3到5个文件就足够了。超过10个通常就是过度了。

迭代优化的思路

分步迭代是很多人容易忽视的点。他们希望一次性生成完整的功能，结果往往是代码质量很差，需要大量返工。

正确的做法是把功能拆解成3到5步，每步生成一个小块，review通过后再继续。

比如要做一个完整的用户管理页面，可以这样拆：

第一步，只生成基础的列表渲染。给AI的指令是："生成用户列表的基础结构，包括表格展示、字段映射、加载状态。"这一步的代码量不大，你可以仔细review：数据结构对不对、类型定义严不严格、加载状态处理得好不好。

第二步，加入搜索功能。"在现有基础上添加搜索功能，包括搜索框、搜索参数处理、搜索触发。"这时你会重点关注：搜索的防抖是否处理、搜索参数的类型是否正确、是否和useTable正确集成。

第三步，加入分页和表格操作。每一步都是在前一步的基础上增量添加，而不是推倒重来。

这个过程的好处是：每一步都在你的掌控之中。如果某一步生成得不好，你可以马上指出问题，引导AI修正，而不是等到生成了几百行代码后再来大规模返工。

而且每次AI的输出都会成为下一次的上下文。你指出了一个问题，AI在下一步生成时就会注意避免。这是个持续学习的过程。

五、质量把控和真实数据

怎么保证代码质量

用AI辅助开发最大的风险是：你可能会降低对代码质量的要求。因为代码来得太容易了，你会想"差不多就行了"。

我的建议是建立一个质量checklist，每次AI生成代码后都过一遍：

功能正确性是第一位的。代码真的实现了需求吗？边界情况考虑到了吗？错误会被正确处理吗？不要因为是AI生成的就降低标准。

类型安全要严格。TypeScript的类型定义是否完整？有没有any类型？类型推导是否准确？AI经常会在类型上偷懒，你要把关。

性能要关注。有没有不必要的重复计算？列表数据多了会不会卡？是否该用computed的地方用了watch？React里是否该用useMemo的地方没用？

代码可读性不能忽视。变量命名是否清晰？逻辑是否易懂？是否需要加注释？AI生成的代码有时会过于简洁或过于复杂，你要调整到合适的程度。

项目规范要遵守。代码风格、文件组织、命名约定是否和项目一致？这个虽然配置了Rules，但还是要人工确认。

最重要的是，你必须能理解每一行代码。如果有代码你看不懂，说明这块知识你还没掌握，不能直接用。要么去学习，要么重写。

效率提升的真实数据

很多人在简历或面试中说"效率提升很多""开发速度提高了"，但说不出具体数据。这会让面试官觉得你在夸大其词。

如果你真的在用Cursor，建议做一个简单的记录：

对于常见的开发任务（CRUD页面、表单组件、列表页面），记录一下以前手写要多久、现在用AI辅助要多久。不需要很精确，大概的时间就行。比如以前做个用户列表页面要3到4个小时，现在1.5到2个小时。

但要注意，这个时间应该是完整的开发时间，包括编码、自测、首次code review。不是"AI生成代码用了10分钟"，而是"从接到需求到提交MR用了1.5小时"。

同时也要记录代码质量的变化：code review平均返工几次、上线后出了几个bug。如果用了AI后返工次数反而增加了，说明你的使用方法有问题。

我自己的数据大概是：标准CRUD页面，从3-4小时降到1.5-2小时，节省约50%；复杂表单，从2-3小时降到1-1.5小时，也是50%左右；TypeScript类型定义，从1-2小时降到20-30分钟，节省70%。

但这些数据要诚实。不要为了好看夸大效果。面试官都是有经验的，他能判断出哪些数据是真实的，哪些是吹出来的。说"效率提升50%"比说"效率提升10倍"更可信。

质量数据也很重要。比如code review的返工率，我以前平均每个MR要返工2到3次，现在降到了0到1次。这不是因为AI写的代码更好，而是因为我在用AI的时候会更仔细地review，反而提升了代码质量。

这些数据不需要很精确，但要真实。面试的时候，你说"我做了简单统计，CRUD页面从3小时降到1.5小时"，比你说"效率提升很多"要有说服力得多。

六、常见问题的真实回答

"如果不用Cursor，你还能写代码吗？"

这个问题是在考察你是不是过度依赖工具。

最糟糕的回答是："当然可以，我只是用AI提高效率而已。"这个回答太空洞，没有说服力。

好的回答应该是诚实的："确实，我现在已经习惯了用Cursor辅助开发，如果突然不让用，一开始可能会不适应，效率会下降。但我一直在保持基础能力的训练：每周我会做几道LeetCode，完全手写，不用任何AI工具；我也会定期手写一些核心组件，比如虚拟滚动、无限加载这些，确保自己理解原理；我还在读Vue的响应式系统源码，学习设计模式和架构思想。"

然后可以补充："我觉得这是个平衡的问题。一方面，AI确实可以帮我提升效率，让我有更多时间去思考架构和业务逻辑；另一方面，我也担心基础能力退化，所以会刻意保持练习。我的原则是：AI生成的每一行代码，我都必须能理解、能解释。如果看不懂，说明我的能力还不够，我会先去学习这块知识。"

这样的回答展现了你的自我认知和成长意识，比简单地说"我不依赖工具"要真实得多。

"AI会取代前端工程师吗？"

这是个开放性问题，没有标准答案。但你的回答能体现你对行业的理解和对自身定位的思考。

我的理解是：AI确实在改变前端工程师的工作方式，但不会完全取代。因为前端工程师的价值不只是写代码。

简单的CRUD、标准的组件拼接，AI确实做得很好，甚至比很多初级工程师做得还好。但真正的工程挑战在于：复杂的业务建模、架构决策、性能优化、用户体验设计、团队协作、技术选型。这些需要深入理解业务、权衡各种因素、做出判断，AI目前还做不到。

举个例子，电商的促销规则可能有几十种组合，优惠券、满减、折扣怎么叠加，哪些可以同时用，哪些互斥。这需要深入理解业务逻辑，抽象出合理的数据模型。AI可以帮你写代码实现，但它不能替你理解业务、做出设计决策。

再比如，一个功能是用服务端渲染还是客户端渲染，状态管理用什么方案，数据怎么缓存，这些决策需要考虑性能、SEO、用户体验、团队能力、维护成本。AI可以给建议，但最终决策需要人来做。

所以我觉得，未来的前端工程师会更像是技术架构师加产品设计师的结合体。AI帮我们写重复性的代码，我们负责做决策、解决复杂问题、创造更好的用户体验。那些只会写代码、不会思考的人可能会被淘汰，但会思考、会学习的人会变得更有价值。

这个回答展现了你对技术发展的思考，也说明了你对自己的定位：不是一个单纯的码农，而是一个会思考的工程师。

"你们团队有人在用Cursor吗？效果怎么样？"

这个问题是在了解你的团队协作能力和对工具的推广能力。

如果你是学生，没有团队经验，可以诚实说："我现在还在学校，主要是自己的项目在用。但我有想过，如果将来在团队中推广，应该怎么做。我觉得关键是要建立统一的规范，比如统一的.cursorrules配置、统一的code review标准。因为不同人用AI生成的代码如果风格不一致，反而会增加维护成本。"

如果你有实习或项目经验，可以说说实际情况："我实习的时候，团队里5个人，有2个在用Cursor。效果参差不齐：资深的同事用得很好，他们本来基础就强，用AI只是提升效率；但有一个同学用得不太好，经常生成一些不符合规范的代码，code review的时候要改很多。后来mentor建议我们做了几件事：统一配置.cursorrules、定期分享最佳实践、code review标准不降低。慢慢地大家用得都比较好了。"

重点是展现你的观察和思考：工具是好的，但需要方法论和规范，团队协作中要考虑一致性问题。

"你提到的效率数据是怎么统计的？"

这个问题是在检验你数据的真实性。

不要编造复杂的统计系统。简单诚实的回答更可信："我用Toggl Track记录开发时间，给不同任务打标签。对比了用AI前后做类似任务的耗时。样本量不大，大概十几个任务，所以数据可能不是特别准确，但趋势是明确的：重复性工作效率提升明显，复杂逻辑提升有限。"

然后承认局限性："这个统计方法比较粗糙，没有考虑到任务难度差异、我自己能力的提升等因素。但至少能说明一个趋势：AI确实帮我节省了时间。而且我不只看时间，还看代码质量，比如code review的返工次数、上线后的bug数量。综合来看，效果是正向的。"

诚实和自我批判比完美的数据更重要。面试官想看的是你的思考方式，不是你统计有多精确。

七、简历应该怎么写

技能栏的写法

很多人在简历的技能栏写"精通Cursor""AI编程专家"，这都是坑。"精通"这个词太重了，你真的精通吗？面试官随便深挖几个问题，你就暴露了。

合理的写法是："熟练使用AI辅助开发工具（Cursor），通过上下文工程和Rules配置提升编码效率40%以上"。

注意这个写法的几个要点：

用"熟练使用"而不是"精通"，给自己留余地。说"AI辅助开发工具"而不只是"Cursor"，显得你的视野更广。提到"上下文工程"和"Rules配置"，说明你理解核心方法论。给出"40%以上"的具体数据，增加可信度。

如果你还没有太多实践经验，可以写得更谨慎："了解AI辅助开发（Cursor），能够配置项目规范和管理上下文，有XX项目的实践经验"。

项目经历中如何体现

比起在技能栏写，在项目经历中自然地体现出来更好。

比如你有个个人项目，可以这样写：

"XX管理系统（Vue 3 + TypeScript）

• 采用AI辅助开发（Cursor）+ 人工Review的混合模式，在保证代码质量的前提下提升开发效率
• 建立项目级.cursorrules配置，统一编码规范，AI生成代码的规范符合度达95%
• 完成8个功能模块，平均开发周期1.5小时/模块，code review一次通过率80%"

这样写的好处是：具体、有数据、有质量把控，而且是作为技术亮点的一部分，不是孤立的技能点。

如果面试官对这个感兴趣，自然会追问，你就可以展开讲你的方法论。如果他不感兴趣，也不会因为你写了这个而减分。

不要把AI使用经验当成核心竞争力

这是最重要的一点。

Cursor只是工具，不是核心能力。你的核心竞争力应该是：扎实的前端基础、良好的工程能力、持续学习的习惯、解决问题的思维。

所以在简历上，AI工具的使用经验应该是点缀，不是主菜。你的项目经历、技术栈、解决的问题、取得的成果，这些才是面试官真正关心的。

如果你的简历上80%在讲AI工具，只有20%在讲实际的技术能力，面试官会觉得你本末倒置了。

合理的比例是：在2-3个项目中提到使用了AI辅助开发，说明你会用新工具，但大部分篇幅还是在讲你的技术方案、遇到的挑战、解决的问题。

八、如果没深度使用过怎么办

诚实是最好的策略

如果你简历上没写Cursor，面试官也没问，那就不用主动提。但如果写了，或者面试官问了，千万不要装。

我遇到过一个候选人，简历上写"熟悉Cursor"，我问具体怎么用的，他支支吾吾说不出来，最后承认只是看了几篇教程，在小项目里试了一下。这个诚实反而给他加分了，我觉得这个人至少不会撒谎。

如果你确实没深度使用过，可以这样说："我了解Cursor的基本功能，也看了一些教程和文章，知道核心是上下文工程和Rules配置。我在自己的小项目里试验过，但还没有在大型项目中深度应用。不过我对这个方向很感兴趣，也在持续学习。"

这个回答的好处是：承认自己的水平，但展示了学习意愿和基本的理解。面试官不会因为你不会用某个工具而拒绝你，但会因为你撒谎而拒绝你。

把面试当成学习机会

如果面试官在这个话题上展开讲了，你可以主动请教："您有什么建议吗？我应该从哪里开始深入学习？"

大部分面试官都愿意分享经验。这个提问本身就展现了你的学习态度，而且你可以真正学到东西。

我自己在面试新人的时候，如果遇到诚实承认不熟、但表现出强烈学习意愿的候选人，我反而会给他更多机会。因为技能可以培养，但态度很难改变。

不要因为一道题否定自己

Cursor这道题只是面试的一小部分。即使你答得不好，也不代表整场面试失败。

前端面试考察的是综合能力：JavaScript基础、框架原理、工程化、性能优化、算法思维、项目经验。AI工具只是其中一个小点。

我见过很多人在这道题上答得一般，但在其他问题上表现出色，最后还是拿到了offer。也见过有人这道题答得很好，但基础不扎实，最后还是被拒了。

所以不要过度焦虑。把这道题当成展示你学习能力和工程思维的机会就好，而不是决定成败的关键。

九、更深层的思考

工具和能力的关系

写这篇文章的过程中，我一直在思考一个问题：我们到底应该怎么看待AI工具？

有人把AI当成魔法，觉得有了AI就不用学习了；有人把AI当成威胁，觉得会用AI的人会抢走自己的工作；还有人把AI当成作弊，觉得用AI写代码就是不道德的。

我觉得这些想法都有偏颇。AI只是工具，就像我们之前用的IDE、脚手架、组件库一样。它的出现确实改变了我们的工作方式，但没有改变我们工作的本质。

前端工程师的本质工作是：理解用户需求，设计合理的技术方案，权衡各种因素，做出正确的决策，然后实现出来。写代码只是这个过程的一部分。

AI能帮我们写代码，但不能替我们理解需求、做设计、做决策。这些需要深入的业务理解、丰富的经验、全局的视野，是AI目前还做不到的。

所以，会用AI的工程师和不会用AI的工程师，竞争力的差距不在于谁写代码更快，而在于谁能更好地理解业务、做出更好的决策、解决更复杂的问题。

保持学习的能力

AI的发展速度很快。2023年的时候，GitHub Copilot还是主流；2024年，Cursor崛起了；2025年，又出现了MCP协议、更先进的上下文管理方法。明年会有什么新东西，没人知道。

在这种快速变化的环境中，最重要的不是掌握某个具体的工具，而是保持学习的能力。

当一个新工具出现时，你能快速理解它的原理、掌握它的使用方法、总结出最佳实践。当一个旧工具过时时，你能及时转换到新工具，而不是固守旧的方式。

这种学习能力，才是你真正的核心竞争力。

面试官问你Cursor的问题，本质上是在考察你的学习能力：你能不能主动拥抱新技术？你能不能深入理解而不是浅尝辄止？你能不能建立方法论而不是盲目使用？

所以，不要把这道题当成"考Cursor"，而要当成"考学习能力"。如果你能展现出强大的学习能力，即使你不会Cursor，面试官也会认可你。

对技术的敬畏

最后我想说的是：对技术要有敬畏之心。

AI很强大，但不是万能的。它会犯错，会生成有bug的代码，会给出糟糕的建议。如果你盲目相信AI，不认真review代码，最后出问题的还是你自己。

我见过有人用AI生成的代码直接上线，结果引发了严重的性能问题；也见过有人因为信任AI，连类型检查都不做，最后生产环境报错。

技术不是儿戏。每一行代码都可能影响用户体验，甚至影响业务。我们使用AI是为了提高效率，但不能因为效率而牺牲质量。

所以，无论是在面试中，还是在实际工作中，都要展现出你对代码质量的重视、对技术的敬畏。这是一个合格工程师最基本的素养。

结语

写到这里，这篇文章已经七千多字了。我想说的核心观点其实很简单：

面试官问Cursor，不是在考你会不会用工具，而是在看你是不是一个会学习、会思考、有方法论的工程师。

如果你真的在用Cursor，就根据自己的真实经验来回答，展现你的思考过程、遇到的挑战、总结的方法论。不要背话术，因为面试官一追问就露馅了。

如果你还没深度使用，就诚实说明你的了解程度，然后表达你的学习意愿。诚实比装懂更重要。

最重要的是，不要把AI工具当成核心竞争力。你的核心竞争力是扎实的基础、工程能力、学习能力、解决问题的思维。AI只是帮你更好地发挥这些能力的工具。

技术在变，工具在变，但一个优秀工程师的本质素养不会变：对技术的热情、对质量的追求、对学习的渴望、对问题的思考。

希望这篇文章能帮到正在准备面试的你。记住：真实、思考、成长，这才是面试官真正想看到的。

祝你面试顺利，找到理想的工作。

附：一些实用资源

如果你想深入学习Cursor和AI辅助开发：

• Cursor官方文档：从基础用法到高级技巧的完整指南
• MCP协议：了解最新的上下文管理标准
• cursorrules最佳实践模板：看看其他项目的Rules配置，学习最佳实践
• AICoding的相关文章：很多开发者分享的实战经验

但记住：看再多文章，不如自己动手实践。找一个真实的项目，配置好Rules，引入上下文，一步步尝试。踩坑、思考、总结，这才是真正的学习。

最后的最后：AI是助手，不是替身。它能帮你写代码，但不能替你成长。保持学习，保持思考，保持对技术的热爱。这才是你作为工程师最宝贵的财富。