企业官网建设流程全解析

简介：这是一份面向开发者、产品经理及运营人员的Cursor上手教程，内含一份约8.01MB的演示文稿，系统讲解人工智能编程工具的使用方法。整套资源只有一个演示文稿文件，但内容覆盖全面，共分六大章节：从Cursor概述、安装注册开始，依次详解智能代码补全、自然语言编程、代码生成与编辑、项目级代码搜索、自定义规则等核心功能，并结合实际项目展示代码生成、代码改造和排错流程；例如用自然语言生成函数、在大型工程中快速定位代码位置、根据项目需求定制规则，让补全结果更贴合实际。进阶部分还补充了多文件协作、观看实战视频、定制个人规则等技巧，以及常见问题的排查与解决方法。目前已有1679人学习下载，适合零基础入门，也适合希望提升智能编码效率的中高级使用者。通过这份教程，读者可以快速建立从安装到实战的完整知识框架，边看边对照操作，少走弯路。

1. Cursor 是什么：把「聊天」变成「改代码」的 AI 编辑器

Cursor 本质上是一个深度集成大模型的代码编辑器，基于 VS Code 的生态改出来的，所以 VS Code 的快捷键、插件、主题基本都能直接搬过来用。它和 Copilot 这类「补全插件」的最大区别在于：你可以直接在对话框里说人话，让它改文件、建文件、跑命令，甚至一口气把整个项目的结构调整完。对于经常被重复性代码、样板代码、配置文件拖住的人来说，它解决的不只是「少打字」，而是「不用在脑海里先过一遍整个项目的上下文」。

这款工具最适合三类人：日常写业务代码、需要频繁增删改查的工程师；跨语言写脚本、但不想记一堆 API 的开发者；以及带团队做项目、被各种配置折腾到心累的人。下面这些内容不按官方文档来铺，而是按我实际使用三个月后的工作流来拆：从安装、汉化、写规则、进 Agent，再到那些官方不写但你一定会撞上的坑。

2. 下载安装与汉化：界面语言和对话回复语言是两回事

很多人第一次装 Cursor 就卡在「怎么全是英文」。这件事要拆成两个维度来看：界面语言是编辑器本身的按钮、菜单、右键项；对话语言是 AI 回复时用什么语言。这两个是独立控制的，改了一个不会影响另一个，这也是网上教程最容易讲混的地方。

2.1 从下载到注册：注意邮箱和额度限制

去 Cursor 官网下载对应操作系统的安装包，这一步没有太多悬念，装完打开之后会进入登录/注册页面。注册支持邮箱和 GitHub 账号两种方式，比较快的路径是用 GitHub 直接授权登录。需要注意的一点是，如果你准备长期使用某个邮箱注册，尽量选一个稳定的、能收邮件的地址，因为后面涉及订阅付费、设备管理、重置密码都会用到它。

登录之后进入 Cursor Settings，在 General 页面能看到 Account 区域，里面会显示你当前用的是 Free 还是 Pro 计划。免费版每天有一定次数的慢速模型请求额度，Pro 版则是按每月订阅套餐购买请求次数。这里有个常见的误解：Pro 的额度不是「每天随便用」，而是按订阅周期内的请求次数计算，像 Agent 这种多轮操作消耗起来很快，后面避坑章我会细说。

提示：注册后如果提示设备数超限，一般是因为同一账号在 24 小时内登录了太多台电脑，这是官方防止共享账号的策略，不是封号，等 24 小时或者到 Settings 里移除不用的设备即可。

2.2 界面汉化：设置文件和 Locale 参数

界面汉化不需要装额外的汉化包，Cursor 直接继承了 VS Code 的语言配置机制。打开 Cursor 后，按下Ctrl+Shift+P（Mac 上是Cmd+Shift+P）唤起命令面板，输入Configure Display Language，然后选择中文(简体)，编辑器会提示重启，确认后重启即为中文界面。

如果你在命令面板里找不到这个选项，也可以直接改配置文件：打开 Settings，切到 JSON 视图，加入下面的参数：

{ "editor.fontSize": 14, "window.zoomLevel": 0, "locale": "zh-cn" }

locale就是界面语言字段，填zh-cn是简体中文，zh-tw是繁体中文。加上后保存重启即可。Windows 用户如果在安装时选择了「仅为我安装」而非「为所有用户安装」，配置文件路径在C:\Users\你的用户名\AppData\Roaming\Cursor\User\settings.json，Mac 用户在~/Library/Application Support/Cursor/User/settings.json。

2.3 对话回复语言：在 Chat 面板和 Rules 里双重控制

界面汉化完成之后，你会发现 AI 回复可能仍然是英文。这时候需要改的是对话侧的语言设置。在 Chat 对话框底部的模型名称旁边，有一个语言选择下拉菜单，里面可以直接选「中文」，这个菜单是 Cursor 新版本内置的功能，选一次之后当前会话就有效。

要让所有新会话默认走中文，更稳的做法是在项目根目录写一个.cursorrules文件，第一条规则就写明回复语言：

Always respond in 中文. 回复时使用简体中文，代码注释和变量名保留英文，解释部分用中文。

这里要解释一下.cursorrules的机制：Cursor 在每次对话时会把项目里的.cursorrules内容注入到系统提示词里。它对这个文件有很高的优先级，接近系统级指令，所以写在这个文件里的语言要求比你在对话框里临时说的「用中文回答」要稳定得多。实测效果是：即使你中间不小心发了一句英文提问，它收到.cursorrules的约束，还是优先用中文回。

3. 从 Tab 补全到 Agent：Cursor 的四种核心工作方式

把编辑器的基本操作过完之后，真正决定工作效率的是你用什么姿势和它配合。Cursor 不是只有一种「聊天改代码」的模式，它内置了从轻到重的四种操作方式，分别适合不同颗粒度的任务，用对了顺序能省掉大量来回修改的时间。

3.1 Tab 补全：不是智能提示，是「预测你的下一步」

在 Cursor 里按 Tab 键接受补全，这个动作看起来和传统 IDE 的代码补全很像，但底层逻辑完全不同。传统补全基于你当前文件里的符号和语言服务器的类型推断，而 Cursor 的 Tab 补全会读取你最近的编辑历史、当前文件上下文，甚至跨文件的信息来预测你接下来要写的代码。它一次可能补出好几行，或者补完一个if块整个函数体。

实际使用中我的习惯是：写完一个函数签名后按一下Ctrl+K，把意图告诉它，再按 Tab 接受建议。如果建议不对，不要按 Esc 之类的键去「取消」，直接继续打字，补全建议会自动消失，这比刻意去关掉它更顺。Tab 补全默认是开启的，如果你觉得它在你写代码时刻频繁弹出干扰注意力，可以在 Settings > Editor > Suggestions 里关闭 inline suggestions。

几个比较值的补全参数：editor.tabCompletion控制是否开启 Tab 补全；"cursor.tabCompletion.enableNativeAutoCompletion"控制是否启用原生自动补全；还有cursor.minimalPreviews，填入true之后预览窗口会变小，屏幕不会一直被大块代码撑满，建议常开。

3.2 Ctrl+K 行内编辑：改函数、修注释、处理单文件

Ctrl+K（Mac 上是Cmd+K）是 Cursor 使用频率最高的一个快捷键。它和 Chat 的区别在于：Chat 是悬浮在右侧的对话窗口，而 Ctrl+K 是聚焦到当前光标位置附近的输入框，直接输入「把这段代码改成不抛异常」或者「给这个函数加参数校验」，改动会直接以 diff 形式插进当前文件，并非开一个新对话窗口。

下面是一次实际的修改过程。假设我在utils.js里有一个解析 URL 参数的函数，我想让它更健壮一点：

// 修改前：没有处理空值和非法输入 function getParam(name) { const url = new URL(window.location.href); return url.searchParams.get(name); }

光标放在这个函数内，按Ctrl+K，输入：让 getParam 兼容 query 和 hash 两种参数来源，如果拿不到值返回 null 而不是报错。它返回的 diff 大致长这样：

// 修改后：兼容 query 和 hash，取不到返回 null function getParam(name) { const url = new URL(window.location.href); const fromQuery = url.searchParams.get(name); if (fromQuery !== null) return fromQuery; const hash = window.location.hash; if (!hash) return null; const hashParams = new URLSearchParams(hash.slice(1)); return hashParams.get(name); }

这段逻辑的关键在于：它先查 query 参数，再去解析hash部分，用slice(1)去掉开头的#。如果你不想让它改文件，而是只想要它给个建议，可以在输入指令末尾加「不要改，给我方案」，它就会只输出思路。Ctrl+K还支持用/开头的斜杠命令，比如/fix修复当前文件里的明显问题，/explain解释选中的代码，这些命令在输入框里敲/就能看到列表。

3.3 Chat 对话：用 @ 符号把上下文喂给模型

Chat 是 Cursor 的第二个核心面板，适合需要「边聊边看」的场景。在这个面板里你可以直接提问、让它解释代码、检查 bug，也可以让它按你的要求改文件。但这里有一个新手很容易忽视的关键操作：只发一句话，AI 是不知道你在说什么的，它只能看到当前打开的文件和模糊的项目上下文。要用好 Chat，必须学会用@符号显式引入文件、文件夹、代码片段甚至整个文档。

输入@之后会弹出选择列表，你可以点选文件，也可以继续输入路径过滤。选中的文代会作为上下文附加到这次对话里，模型在回答时会优先参考这些内容。我在改一个跨文件的数据流时习惯这样做：@utils/api.js @pages/home.jsx @store/user.js 帮我看一下从 login 到获取用户信息的链路有没有问题。三个文件被喂进去之后，回答质量比不带任何 @ 时高了一个量级。

Chat 面板底部还有一个上下文模式的下拉菜单，默认是Cursor，还有Agent和Ask两种模式。Ask只回答不做修改；Agent模式下它会自己决定改哪些文件、跑什么命令，权限更大也更容易失控。我的建议是：第一次跑不熟悉的任务时先用Ask了解它打算怎么做，确认过方案再切成Agent动手。

3.4 Agent 模式：多文件改动、自动跑命令、一键回滚

Agent 模式是 Cursor 里最重的一把锤子。它不只是改当前文件，而是会分析整个项目的文件结构，找到相关的引用关系，然后动手改多个文件，甚至帮你自动执行命令。比如你给它一个新需求：给用户表加一个 age 字段，并同步生成对应的接口、mock 数据和前端展示，它会自己梳理出涉及的文件列表，逐个改动，改完后在对话里报告每一处改动。

但权限越大，风险越大。Agent 模式会调用终端执行命令（比如npm install、python manage.py migrate），而且这些命令是它依据自己的理解生成的，不一定和你的项目环境完全兼容。第一次用 Agent 处理重要分支时，我强烈建议先手动创建一个新的 git 分支，这在实验性质的多文件改动里几乎就是后悔药——改砸了直接切回主分支，不会污染主干代码。

git checkout -b feature/cursor-agent-experiment

跑完这一行再进 Agent 模式操作，改完检查没有问题之后，删掉这个临时分支即可。另外 Agent 模式下对话会显示当前任务用掉了多少请求次数，右上角能看到模型名称和请求计数，如果发现烧得飞快，就切回 Chat 模式手动控制上下文，这个我后面避坑章再展开。

4. 把 Cursor 调成自己的形状：Rules、MCP 与插件

很多人在网上问「Cursor 有哪些 Skill 推荐」「怎么下载插件」，其实都是在做同一件事：把默认的 Cursor 调成贴合自己习惯的工具。这一章我们过三个比较关键的自定义手段——.cursorrules项目级指令、MCP 外部工具接入、以及插件/主题的安装边界。

4.1 写好一份 .cursorrules：决定 AI 懂不懂你的项目

.cursorrules是 Cursor 的灵魂。它适合用一两组完整模板来把「AI 的行为规范」固定下来，而不需要每次在新项目里重新唠叨一遍。这个文件放在项目根目录，Cursor 会自动识别并加载。

给一个最基础、可以直接抄走的模板，我用它度过了适应期：

你是一名资深全栈工程师，具备严谨的代码审查习惯。 代码规范： - 优先使用 TypeScript，类型定义必须完整，避免 any。 - 函数和变量命名采用 camelCase，组件文件采用 PascalCase。 - 所有对外接口必须写注释，注明参数和返回值。 回答规范： - 回复使用简体中文，代码变量和注释可以保留英文。 - 修改代码前先列出改动文件和改动方案，不要直接改。 - 涉及第三方库时，给出引用版本和引入理由。 项目背景： - 当前项目是前后端分离结构，前端使用 React + Vite。 - 后端是 Python FastAPI，数据库使用 PostgreSQL。 - 代码规范参照项目根目录的 .editorconfig 和 eslintrc。

这段模板里有两个关键的设置原则要说明：第一，规则要具体到「列文件、给方案、再动手」这种行为约束，比单纯写「你是一个专家」有用得多；第二，描述项目技术栈的段落很重要，因为默认情况下 Cursor 对项目的了解是有限的，你主动告诉它的技术栈，能降低它瞎猜的概率。

4.2 MCP 配置：让 Cursor 能直接调外部工具

MCP 的全称是 Model Context Protocol，是 Cursor、Claude 等工具支持的一种通用接口协议，让 AI 对话时能调用外部服务——比如直接查数据库、读写某个 API、操纵本地文件系统之外的工具。配置入口在Cursor Settings > Integrations > MCP，点击Add MCP Server后填入服务地址和命令。

一个典型的本地 MCP 配置如下，比如接一个本地运行的数据库查询服务：

# 通过 stdio 启动一个已有的 MCP server npx -y @some-org/mcp-database-server # 参数说明： # - npx 表示从 npm 远程拉取并运行该包 # - -y 跳过安装确认 # - @some-org/mcp-database-server 是占位包名，换成你要用的实际包名即可

配置完成后，在 Chat 输入@就能看到 MCP 服务里暴露的工具，可以直接在对话里说「用 MCP 帮我跑一条 SQL 查询」，它会调用这个服务获取结果并继续对话。需要注意 MCP 的引入会额外消耗一定的上下文 token，因为工具的描述信息每次对话都要作为上下文发送给模型。项目不复杂、或者你只需要最基本的文件操作时，不建议引入太多 MCP 服务，否则上下文很快被撑爆。

4.3 插件安装：绝大部分 VS Code 插件可以直装

Cursor 兼容 VS Code 扩展市场，这一点被很多人低估了。打开左侧的 Extensions 图标，搜索你常用的插件，直接点 Install 就能装上。对我来说，必装的三件套是：

• Prettier：统一格式化代码，配合.prettierrc后，Ctrl+S 自动格式化很舒服。
• ESLint：代码规范检查，Cursor 补全时撞到 lint 错误的位置能及时看见。
• GitLens：查看每行代码的提交记录，尤其是在用 Agent 改完一堆文件之后，能快速定位到底动了哪些行。

需要注意一个边界：安装插件本质上是在扩充编辑器的功能，但插件自身是独立程序，它的行为不受.cursorrules控制。也就是说你在 rules 里写「不要使用任何插件」是没用的，插件的启用和禁用都在 Settings > Extensions 里手动管理。另外，某些需要登录第三方账号的插件（比如云服务商的登录插件），建议只在需要时开启，避免插件在后台额外消耗资源。

5. 常见问题与避坑：我踩过且你大概率会踩的五个坑

用了三个月 Cursor，大部分网上搜得到的问题我都实际撞过一遍。这一章不写那种「查看官方文档」的废话，只写现象、原因、解决路径。有个心理准备：Cursor 更新迭代很快，某些界面对不上的时候，以版本更新说明为准，但底层逻辑基本不变。

5.1 同一账号提示设备数超限

现象：登录时弹出Too many computers used within the last 24 hours for the same Cursor account，不愿意让你继续用。原因：Cursor 为了防止账号共享，限制了同一账号在 24 小时内登录的设备数量，超过了阈值就会触发这个提示。解决：先去 Cursor Settings 里的 Devices 菜单看看是否有旧设备记录，手动移除不再使用的设备；如果列表里没有可以删的，那就关掉当前不需要的 Cursor 实例，等 24 小时限制窗口过去再登录。注意不要为了绕过限制反复注册新账号，因为注册邮箱和设备信息都会被关联，频繁换号反而容易被标记。

5.2 提示词泄露：把密钥和项目背景一股脑喂给了 AI

现象：同事在对话历史里发现你把数据库密码、云服务的 AccessKey、甚至公司内部项目代号写进了.cursorrules或者 Chat 对话框里。原因：很多人为了追求「让 AI 更懂项目和密钥」，把真实凭证写进了与 AI 共享的上下文里。解决：立下铁规矩——.cursorrules里只写技术栈、代码规范、项目结构这类描述性信息，绝不写真实账号、密码、Token。需要用到密钥的场景，用环境变量导入，让 AI 读环境变量名而不读值。假如已经泄露，立即去对应平台把密钥轮换掉，不要心存侥幸。Cursor 官方说对话数据默认会保存本地，但你自己不能默认一切安全，该做的边界还是得做。

5.3 不加确认就改动代码，项目散架

现象：用 Agent 模式改完一堆文件之后，运行测试发现一堆红色报错，回头看改动记录才发现它把几个不相干文件也顺手改了，比如把api.ts里的接口地址替换成了它自己「猜」的值。原因：Agent 模式下模型会依据推断补全它认为合理的改动，但推断不等于事实，尤其在配置文件、路由表、路径别名这类敏感位置。解决：所有 Agent 任务开始前，先明确说「不要改任何不在我提及范围内的文件」，并且有条件的话先切分支；改动结束之后，在 Chat 里追问一句「列出你改动的所有文件和理由」，把清单过一遍再提交。以后我每次开 Agent 之前都是这么做的，已经救回了好几次被改乱的配置。

5.4 请求额度烧得太快，一个任务就没了半天的量

现象：Pro 用户发现刚开了对话一个小时，额度就见底了。原因：Agent 模式每执行多文件改动，每一步都可能按请求计数，尤其是修改文件多、任务步骤长的项目，一次操作消耗几十次请求很正常。解决：把任务拆小，不要试图一句话让它做完所有事情；能用Ctrl+K行内编辑解决的单文件修改，不要开 Agent；在 Agent 对话里主动说「先只改动 A 文件，完成后停一下」，让它在关键节点暂停，你确认再继续。还有一个实用做法：对简单任务（改文案、调样式），在对话框的模型选择里切到 slower model，虽然响应慢一点，但不会烧 Pro 的快速请求额度。

5.5 上下文太长，文件一多就回答得牛头不对马嘴

现象：把项目里十几个文件全部@进对话框，准备询问整体架构，结果它开始胡言乱语，回答的内容明显不是当前项目里的代码。原因：Windows 的 token 窗口是有限的，文件塞太多超过了上下文容量，早期的内容会被丢弃，模型只能看到最新的尾巴。解决：一次只@与当前问题直接相关的文件，一般不超过 3 个；如果真的要全项目分析，先让 Cursor 用/explain生成每个文件的摘要，再把摘要贴进对话；打开 Settings 里Context Window Indicator，这样对话框底部能实时显示当前 token 占用比例，超过 70% 时就应该主动精简上下文，而不是继续加文件。

6. 进阶一点：把 .cursorrules 当团队规范来做

如果你已经用了一段时间，会发现最影响 Cursor 输出质量的往往不是模型本身，而是你喂给它的项目规范和上下文。我现在每接手一个新项目，第一件事不是写业务代码，而是花 20 分钟把.cursorrules写到能直接给团队复用。

以上面第 4 章的模板为基础，我一般还会在文件里加一段「禁止事项」部分，比如：

禁止事项： - 不修改 .env 文件的内容，只读取环境变量名。 - 不在测试文件里写 mock 外部服务的真实请求。 - 不使用未在 package.json 中声明的第三方依赖。 - 编译报错时先修编译错误，再处理 lint warning。

这段规则在团队场景里特别有用。新同事第一次用 Cursor 时，不需要把项目背景逐条讲给它听，一份 rules 文件就能让 AI 的行为贴近团队既有约定。甚至可以提交到仓库里，保证所有人用 Cursor 时的口径一致。另外可以尝试用.cursorignore文件排除node_modules、dist这类大型目录，让 Cursor 索引更快，也更不容易被无关文件带偏。

关于模型选择也值得多说两句。如果任务本质上属于「快速问答」，比如解释一段代码、给出一个排序算法的思路，直接用 slower model 即可，响应足够好；只有面对复杂重构、跨文件数据流梳理、疑难 bug 定位时，才用 Claude 这类强模型跑 Agent。这是额度管理和输出质量之间很划算的配比。

我现在的习惯已经固定成一套流程：新项目先写.cursorrules，改文件先Ctrl+K对付单文件，跨文件任务先回答方案再切 Agent，Agent 跑完总要翻一遍 git diff。这套流程说不上多聪明，但每次碰壁回头看，几乎都是没按某个环节走。希望这份基于踩坑经验整理的教程能帮到你，少走几步弯路。

本文还有配套的精品资源，点击获取