企业官网建设流程全解析

说句实在话，用习惯Cursor之后再回到以前的编辑器，最不习惯的不是少了代码补全，而是少了那个“大概知道你下一步想干什么”的结对程序员。Cursor这个AI代码编辑器，圈内讨论热度一直很高，但我发现不少教程停在表面：装完、登进去、问两句就结束，真正决定效率的细节反而没人讲。这篇我从安装开始，一步步演示日常用的几个功能，最后给一份可以直接复制的避坑清单，新手可以按顺序跟着操作，老手挑自己没摸过的部分看即可。

我这篇文章能讲清楚三件事：Cursor到底比传统编辑器强在哪、日常写代码时怎么把它真正用起来、以及用了几个月之后会遇到哪些坑。如果你正在犹豫要不要迁移，或者已经装了但感觉“也就那样”，这篇文章应该能帮你打开一些思路。

1. 先说结论：为什么一个编辑器会因为AI功能重新洗牌

1.1 它补全的不是单词，而是意图

传统编辑器的自动补全，核心逻辑是“语法+作用域”：你敲出一个函数名，它帮你补全参数；你输入一个对象，它列出属性。这种补全很利索，但它本质上是一个“字典查找”，它不知道你接下来要做什么。

Cursor最颠覆的一点，是它的Tab补全能预测你的意图。它不是只在光标附近给提示，而是能基于整个文件的上下文，猜出你接下来要写哪一段逻辑。我第一次被震到，是写一个批量处理函数时，我只写完了循环的前两行，按一下Tab，整个循环体、异常处理、返回值全部生成了。而且生成的不只是“语法正确”，是“语义正确”，和我脑子里想的结构几乎一样。

这就是抽象层级的差别。传统工具在“词”和“表达式”层面辅助你，Cursor在“意图”层面辅助你。你不需要完整地把想法敲成代码，你只需要确认它猜得对不对。

1.2 从“写完代码再问AI”到“写着写着AI就在场”

以前用AI辅助写代码的流程通常是：自己先写，写完复制报错去问，再把答案粘贴回来。这个流程有两个问题：一是上下文割裂，AI看不到你的完整工程，回答经常是“通用建议”；二是切换成本高，来回复制粘贴很打断心流。

Cursor把AI放进了编辑器的每个角落。你写代码时它在旁边等着补全，你想改代码时直接选中按快捷键交代需求，你想问问题的时候它能自动带上当前文件甚至整个代码库。这不是“编辑器+聊天窗口”的拼凑，而是AI真正长在了开发流程里。

我打个比方：以前用AI像是请了个顾问，你写完东西拿给他看，他给意见；用Cursor像是请了个结对同事，他跟你坐在同一台电脑前，你刚伸手他就知道把哪个工具递给你。

1.3 什么样的人最容易从这份教程里获益

如果你属于下面几类，这篇教程的性价比会非常高：

• 刚接触Cursor，装完之后不知道从哪里下手的新手；
• 已经在用，但只用了Chat功能，Tab补全和Rules完全没碰过的同学；
• 想带团队统一AI代码规范，但不知道规则文件怎么写的工程负责人；
• 以及被网上各种“AI生成代码翻车现场”吓到，想安全落地的人。

如果你是纯小白，连插件和扩展都没装过，也没关系。我下面每一步都写得比较具体，跟着做就行。

2. 从安装到顺手：30分钟内完成基础设置

2.1 安装、登录，以及第一次启动后该看一眼的设置

Cursor的安装本身没什么好说的，跟装任何桌面软件一样，下载对应系统的安装包，一路下一步就行。装完打开，用邮箱注册一个账号登录，免费额度会自动生效。

但第一次启动之后，有几个设置我建议你先调掉，不然后面很容易困惑。

第一个是“不保留原编辑器的快捷键习惯”。Cursor默认兼容VS Code风格的快捷键，因为很多用户是从那边迁移过来的。如果你以前用的是别的编辑器，或者对某些快捷键有自己的肌肉记忆，建议先打开设置里的快捷键面板，搜索到自己常用的那几条，改成熟悉的键位。别小看这一步，每天几百次按键操作，顺手与否直接决定你愿不愿意长期用。

第二个是模型选择。在设置里找到模型相关选项，确保你用的是当前看起来最稳的模型。不同版本能选的模型会有差异，不用太纠结，先选一个公认稳定的旗舰模型，之后可以根据具体任务切换。

第三件事是建立索引。打开一个已有的大型项目时，右下角通常会出现索引进度提示。建议等它完全跑完再开始用搜索或对话功能，否则你问“这个函数在哪里定义的”，它可能会答非所问。

2.2 把快捷键和界面调整成自己的习惯

Cursor的界面布局和主流代码编辑器高度相似，左侧是文件树，中间是编辑区，底部可以调出终端，但AI相关操作集中在这几个快捷键上：

• Cmd + K：内联编辑，选中代码后直接对这段代码提要求，这是最高频的操作；
• Cmd + L：打开对话面板，进行更复杂的问答或跨文件操作；
• Tab：接受AI补全，这是写代码时用得最多的确认键；
• Cmd + Enter：在对话面板里接受AI生成的代码修改。

我强烈建议你把前两个快捷键练成肌肉记忆。用了几个星期之后，我写代码的状态基本就是：写几行、Tab补全、选中一段、Cmd+K修改、再继续写。

界面方面，我的建议是不要装太多花哨的主题和图标包，尽量保持默认。因为Cursor的AI功能会往界面上添加各种状态提示（比如补全进度、索引状态、模型切换按钮），第三方主题很容易把这些信息挤得看不清。

2.3 用之前必须理解的三种“上下文”机制

很多人觉得Cursor不够聪明，问题多半出在“没给它足够的上下文”。它毕竟不是读心术，你需要把当前改动的相关背景喂给它。

第一种上下文是当前文件。Chat默认会带上你现在打开的文件内容，所以提问之前先确认你停在正确的文件里。

第二种是主动引用。你在对话里输入@符号，会弹出文件选择器，可以指定某个具体文件、某个函数定义、或者是整个代码库。比如你写“帮我按这个文件里的风格重构当前页面”，那就@一下那个风格参考文件，效果立刻不一样。

第三种是代码库级索引。这是很多人忽略的杀招。当你输入@Codebase时，Cursor会基于语义检索在整个项目里找相关信息，哪怕你问的是“订单状态机在哪里定义的”，它也能给你指路，这个功能比纯文本搜索强大得多，但前提是索引已经建好。

理解了这三层上下文，你就明白了一个核心心法：想让AI答得好，先让它看得到。这比任何提示词技巧都重要。

3. 三个日常最高频的功能，我用实际场景讲透

3.1 Tab补全：最容易被低估的提效功能

很多人听说Cursor很强，一上来就开Chat，用了一会儿觉得“不过是套壳聊天”，然后放弃了。我每次听到这种评价都很可惜，因为他们错过了Cursor最细腻的功能——Tab补全。

Tab补全的精髓在于，它可以连续预测你下一步要写的代码。你写完一个函数名，它补整个函数；你写完一条日志，它补下一个同类操作的日志。它甚至会学着你的风格写，比如你习惯用const还是let，习惯先判空还是先处理异常，它看一会儿就学会了。

实测下来有个规律：Tab补全在写胶水代码、CRUD接口、重复性组件时最爽，因为这些代码模式固定、语境清晰。而在写核心算法、复杂状态流转时，它的表现会弱一些，毕竟这种场景每个项目差异太大，它没有足够上下文。

我现在的习惯是，给它制造“补全机会”。比如我会先把函数的返回值类型、关键参数名写清楚，然后停一下，让补全自己浮现出来。有时它生成的代码比我想的还细致，连参数校验都加上了，我就直接Tab接受再微调。这种“写一半、补一半”的节奏，比纯手敲快很多，也比完全让它生成更可控。

3.2 内联编辑：改代码不再靠复制粘贴

如果说Tab补全是“顺水推舟”，那内联编辑就是“指哪打哪”。它的入口是Cmd + K，用法是：选中一段代码，按下快捷键，输入一句自然语言要求，AI直接在当前光标位置生成修改后的代码。

我日常最常用的几个场景给你列一下：

• 把一段同步请求改成异步模式；
• 给现有函数补充错误处理；
• 把硬编码的字符串抽成常量；
• 把两层循环改成更简洁的写法；
• 自动补全缺失的单元测试。

这些需求如果手改，至少得五分钟，用Cmd+K基本上二十秒搞定。它生成之后会给你一个diff对比视图，你可以看清楚了再接受，这一点非常关键——它不是在偷偷改你的代码，而是把所有改动摆在你面前让你确认。

还有一个技巧：在输入要求时，尽量限定范围。你不说“把这段代码的质量提高”，而要说“把这里的三层嵌套循环改为提前返回的结构，保持输出结果不变”。范围越明确，生成结果越贴合你的预期。

3.3 Chat面板：从问答到直接落地的diff

对话面板（Cmd + L）适合干三件事：问问题、解释代码、跨文件改代码。

问问题时，我的建议是“带着代码问”。比如你把报错信息粘贴进去，然后@一下相关文件，再问“这段代码为什么会NPE”，它给出的答案会结合你的实际代码，而不是泛泛而谈。我还喜欢让它“读给我听”——把一段晦涩的正则或者状态机逻辑选中，问它“这段逻辑到底在做什么”，它的解释比看文档快得多。

跨文件改代码是对话面板的重头戏。你可以直接说“帮我把所有列表页面的分页参数统一改成新的数据结构”，它会去检索相关文件，逐个给出改动建议。但注意，跨文件改动时一定要用@把相关文件都拉进来，否则它只会盲猜。

还有一个容易被忽略的细节：聊天里的代码块右下角通常会有一个“Apply”按钮。点它，AI的回复就会变成编辑器里实际的diff修改。这意味着，你在对话里让它写的一段代码，可以一键落到文件里，然后你继续用Cmd+K微调。对话负责大方向，内联编辑负责精修，Tab补全负责收尾，三个功能串起来，整个流程很顺。

4. Agent模式实战：让AI跨文件干活，但别让它脱缰

4.1 一个完整例子：从一句话需求到可运行页面

如果你以为Chat就是全部，那还差得远。新版Cursor里的Agent模式，能让AI不只停留在“回答和改代码”，而是主动规划、执行、检查，像一个真正的实习生。

我拿一个实际经历举例。有一次我需要快速搭一个待办事项页面，功能很简单：输入文字、点回车添加、可以勾选完成、一键删除已完成。我没有手写，只在Agent对话框里描述了一遍需求，然后看着它自己建文件、写组件、补样式，甚至还在本地起了一个预览服务让我直接看效果。

整个过程我没有手动写过一行代码，而是在每个步骤后审查它的改动，看有没有不符合预期的地方。它创建了三个文件，一个组件、一个管理状态的工具、一个样式文件，结构还算合理。我提了两个修改意见，它很快调整完毕。

这个体验很有冲击力。以前接这种小需求，怎么也得开个会、排个期、写几个小时。现在一个人加上一个Agent，十几分钟就出了可用版本，而且代码结构还是我自己可控的。

4.2 让Agent更可控的三个约束手段

Agent很强，但如果不约束，它也容易跑偏。根据我的实际使用，有三条约束手段非常重要：

第一，在需求描述里圈定边界。你直接说“只修改src目录下的文件，不要碰配置文件”，它就不会乱动无关内容。我见过有人让它加一个功能，结果它顺手格式化了一堆无关文件的教训，边界感必须一开始就立好。

第二，把大任务拆成小步骤。我倾向于让Agent一次只做一件事：先“创建商品列表组件”，再“补上点击跳转逻辑”，再“调整空状态样式”。每完成一步，我会看一遍diff并接受，然后再发下一个指令。这样即使某一步翻车，损失也可控，回滚也容易。

第三，给它足够的“参考资料”。项目里如果有现成的类似页面，让它先读那个再动手，它做出的风格会和老代码非常统一。这一点对团队协作特别重要，否则AI生成的新代码和旧代码风格割裂，后期维护会很难受。

4.3 什么时候该用Agent，什么时候别用

用了一段时间后，我总结出Agent的“适合场景”和“别用场景”。

适合用的场景：一次性搭建脚手架、批量逻辑替换、按需求文档生成初始版本、快速写测试用例。这些任务边界清晰、模板性强，Agent能大幅提升效率。

不太适合的场景：核心业务逻辑的最终定稿、涉及分布式事务或复杂状态的改动、线上紧急修复。这些场景对正确性要求极高，而且经常有很多隐含的边界条件，AI看不到。在这些地方我会自己写核心，让AI只负责周边。

我的使用原则很简单：Agent适合铺量，不适合收口。让它快速铺开战场，最后由人来精耕细作。这样既享受效率红利，也不至于把命运完全交出去。

5. 用Rules文件把AI的“脾气”调成团队风格

5.1 Rules文件放在哪里，优先级怎么算

如果你用Cursor写过几天代码，一定发现一个问题：有时候它生成的代码风格跟你完全不一样。这很正常，因为模型默认会给你一种“通用编程风格”。解决办法是建立一个规则文件，告诉它你的项目和团队是怎么写代码的。

在新版本Cursor里，规则文件分为两级。全局规则放在设置里，对所有项目生效，适合写个人偏好，比如“默认使用单引号”“句末不加分号”。项目规则放在项目根目录的.cursor/rules文件夹下，后缀名是.mdc，适合写项目特定约束，比如“所有API调用必须走统一的请求封装”。

生效优先级是：项目级规则优先于全局规则，更具体路径的规则优先于更泛化的规则。也就是说，如果全局规则写“所有字符串都用双引号”，但某个具体模块的规则写“本模块统一使用单引号”，实际生效的是后者。

除了.cursor/rules，我建议你顺手看一眼项目里有没有别人留下的.cursorrules文件，这是一个老式的全局配置方式，如果你同时使用新旧两种配置，可能会遇到规则互相覆盖的迷惑情况，建议以项目rules目录为准。

5.2 一份可以直接抄走的项目规则示例

光说理论不够，我放一份我自己在项目里用的规则示例，你可以照葫芦画瓢。这个示例适合一个典型的TypeScript中后台项目：

你在回答时需要严格遵循以下约定： - 代码一律使用TypeScript编写，类型定义必须完整； - React组件只使用函数式写法，禁止使用类组件； - 所有API请求必须走@/api/apiClient封装，不得直接调用底层请求库； - 样式优先使用Tailwind工具类，复杂场景才允许写额外CSS文件； - 文件命名统一使用小驼峰，组件文件首字母大写； - 不要在代码中写入console.log调试语句，如需打印请改为项目封装的logger； - 如果你不确定某个API是否存在，请明确说明，不要编造方法名或参数； - 修改前先说明你的修改计划和涉及的文件列表。

这里面有几条很关键。第一是“不要编造API”，这一条能帮你避开AI一本正经胡说八道的坑；第二是“先说明修改计划和涉及文件”，这会强迫AI在动手前理清思路，效果远好于直接乱改；第三是团队规范的具体化，越具体越好，不要写“保持代码风格一致”这种空泛话。

5.3 写规则的两条核心原则

第一条原则：具体比抽象有效。你写“保持高质量代码”，AI无从下手；你写“所有异步函数必须包含try-catch或Promise.catch”，它就非常明确。规则文件是给模型看的，不是给人看的，所以请把每个团队约定翻译成可验证的指令。

第二条原则：规则要迭代。我自己的规则文件不是一次写成的，而是用着用着发现AI老犯某一个错误，就把对应约束补进去。比如有段时间它总喜欢给不需要异步的函数加上await，并在规则里写了“禁止给同步函数添加async”。加了这条之后，这个问题基本绝迹了。

所以，不要再把规则文件当成一次性工程。把它当成一块能持续打磨的“调教面板”，AI每次犯错都是在提醒你：该补一条规则了。

6. 高频坑位排查：这些事故我替你踩过了

6.1 AI一本正经生成不存在的API

这大概是所有AI编程工具的通病，在Cursor上也会遇到。最典型的是用过时的或臆造的方法名。我遇到过它给我生成一个fetchWithRetry的封装，但我们的项目里其实根本没有这个方法，它自己编了一个。

对策分两层。第一层是在规则文件里明确要求“不确定的API必须说明”，让它在生成之前带一个问号。第二层是自动化防御：每次AI改动涉及API调用，我至少会确认一遍调用的方法是否真的存在于当前项目的依赖里。验证方法很简单，Ctrl点击方法名能跳转到定义，跳不到就要警惕。

6.2 项目里的中文注释突然变乱码

有一次我在Windows机器上处理一个历史项目，项目的源文件是GBK编码，Cursor新建的文件默认用UTF-8，AI生成的中文注释落到文件里之后，整套编译都乱了。

这个问题非常隐蔽，因为大部分情况下你看文件内容觉得没问题，但一编译或者一提交，编码冲突就暴露出来。我的解决思路是：在项目根目录放一个编辑器配置文件，强制统一使用UTF-8编码，新文件和老文件一样。如果老项目确实必须用GBK，那就单独设置“不要给本项目添加中文注释”，至少在AI生成时避开编码雷区。

6.3 代码库索引慢导致搜索结果不准

刚打开一个比较大的仓库，马上用@Codebase问问题，经常得到“找不到这个函数”的回答。这并不是它蠢，而是语义索引还在后台跑，搜索的时候根本没搜到最新的内容。

我的判断方法是看右下角的索引状态图标。在索引没完成之前，尽量只用当前文件级别的功能，等索引完成了再问全库问题。如果你改动了很多文件而搜索结果明显滞后，可以在设置里手动触发重新索引，比干等高效。

6.4 快捷键冲突与误触

安装了很多扩展之后，Cmd+K这种全局快捷键很容易被别的插件抢走。有一次我按快捷键没反应，排查了半天才发现是一个代码格式化插件占用了同样的键位。

解决办法是打开快捷键配置文件，搜索被占用的组合，手动解除冲突。另外，Tab键在个别场景会跟代码片段展开冲突，导致你想接受补全却弹出了别的菜单。这时候可以检查一下“接受补全”的触发方式设置，有的版本支持改成Ctrl+→等备选键。

6.5 关于额度与降级的预案

免费额度用完后，整体体验会有明显回落，尤其是Chat和Agent类功能会受限。我的建议是不要把AI的深度功能当成默认配置，而是把它们当成“重要步骤中的放大器”。

实际经验是：在额度充裕的时候尽量把规则文件、项目上下文配置好，这样即使额度收紧，Tab补全这类轻量功能依然能提供不错的体验。你也可以按任务分级：随意探索用轻量模型，复杂重构留到额度宽裕时用旗舰模型。提前做好预案，就不会在关键时刻被额度问题卡住。

最后说几句实在话

写了这么多，其实我最想对新手说的是：别急着追求“用AI自动写整个项目”。先好好用一周Tab补全，让AI融入你的输入节奏；再开Chat，让它成为你的代码讲解员；然后才是Cmd+K和Agent，一步步把更多环节交给它。

这个由浅入深的过程，看起来慢，实则稳。我见过太多人一步到位让AI生成整个模块，结果出了问题根本看不明白。AI代码编辑器真正提升效率的逻辑，不是“AI替我写，我只看结果”，而是“我理解方向，AI填充细节”，这种协作是扎根在理解之上的。你先熟练了地基，再往上盖楼，每一层才稳。