企业官网建设流程全解析

大概是从一年前，我把日常主力编辑器从用了多年的传统 IDE 换成了 Cursor。说实话，刚开始我是抱着“试试看”的心态用的，毕竟当时 AI 编程助手也只是补全代码、写点小工具的水平。但用到现在，Cursor 已经成为我每天离不开的工作台，而且我越来越觉得它不是一个“会写代码的编辑器”，更像是一个和我并肩工作的结对程序员——虽然偶尔也会翻车，但整体效率提升是非常明显的。

这篇博文不打算讲“Cursor 是什么”这种基础科普，也不打算列一堆快捷键。我想分享的是我实际怎么用它、怎么把它放进真实的项目工作流，以及踩过的坑和走通的路。如果你已经装了 Cursor 但总觉得“就是带 AI 的 VS Code”，或者刚开始想系统性地用一个 AI 编辑器来提升开发效率，这篇应该对你有用。

适合谁看？大概两类人：一类是已经有 Cursor 基础使用经验、想进一步提升效率的开发者；另一类是还在观望、想搞清楚“这东西到底能怎么帮我干活”的技术管理者。文章里会涉及一些实操细节，也尽量把每个操作背后的考虑讲清楚，这样就算你用的是其他 AI 编程工具，思路也一样能迁移。

1. 我对 Cursor 的整体判断：它改的不是输入方式，而是工作流

1.1 为什么说它不是“套壳编辑器”

很多人把 Cursor 看成“VS Code 换皮 + ChatGPT 插件”，我在用之前也是这么想的。但实际深度使用之后，我的结论变了：它确实基于 VS Code 的架构和操作习惯，但 AI 能力是深入编辑器底层的，不是挂在旁边的聊天框。

举一个最直观的例子：Tab 补全。传统编辑器的自动补全，是基于语言服务去补变量名、函数名；Cursor 的 Tab 补全能做到的是“预测你的下一步操作，直接把一大段代码补出来”。它不是根据语法猜，而是根据整个项目上下文去推理。我用它写过一个分页查询接口，光标停在方法签名处按下 Tab，它直接把我接下来要写的参数校验、分页处理、空结果返回，甚至连日志都补得八九不离十。这种体验不是普通补全能做到的。

所以我在心里把它定位为：一个能深度读取项目上下文、参与代码修改与重构、并且能执行多步骤任务的“结对编程助手”。有了这层定位，你才会想清楚哪些事应该交给它、哪些事不交给它，而不是无脑复制粘贴。

1.2 什么任务交给它，什么任务不交给它

使用 AI 编程工具最忌讳的就是“什么都让它干”。我自己总结了一套分工原则，用了一年多基本没踩过大的雷：

• 适合交给 Cursor 的任务：样板代码生成（CRUD 接口、DTO、配置类）、跨文件的机械性修改（改名、调整参数顺序、补充注释）、单元测试的批量生成、复杂正则/字符串处理、日志分析、根据报错信息定位问题。
• 不太适合的任务：需要全局架构决策的设计（比如“这个系统要不要上微服务”“缓存一致性问题怎么解决”）、涉及多团队协作的接口变更、需要业务人员配合确认的复杂逻辑。这些更适合用来做“讨论工具”而不是“生成工具”。

我见过有人让 AI 直接生成一整个模块，回头看代码时发现架构边界全是乱的，最后重写成本比手写还高。我的体会是：Cursor 是最适合在“你已经想清楚怎么做”的时候帮你省时间，而不是在“你还没想清楚”的时候替你思考。

1.3 使用 Cursor 的一个关键认知：写代码快感不等于代码质量

刚上手 Cursor 的一个危险信号是：代码生成速度快了，但 bug 也变多了，而且 bug 看起来都很合理，不看测试根本发现不了。这个后面踩坑部分我会展开讲。现在先说结论：用 Cursor 之后，代码审查的工作量不降反升，你省下的是打字时间和查文档时间，但该花的思考时间一点都不能少。

我自己现在的工作习惯是：AI 生成代码后，我会像 review 一个同事代码一样过一遍，特别是看边界条件、资源释放、异常处理这几个地方。AI 生成的代码在“正常路径”上往往很好，在“异常路径”上经常偷懒。

2. 开工前的三项准备：配置、规则与模型选择

2.1 基础配置：这几个开关值得先打开

Cursor 的默认配置已经不错，但有几个地方我会建议一开始就调整，能让后续使用顺很多：

自动补全区域：把 Tab 补全、内联补全都打开。很多人不知道 Cursor 的设置项里有 “Auto Scroll”、“Auto Save” 这些，保底把自动保存打开，避免 Cursor 在生成代码过程中文件状态不一致。

代码索引（Indexing）：一定要让它把当前项目的索引建立完整。Cursor 的 Codebase 语义检索依赖这个索引，如果没建好，你在 Chat 里问“这个模块哪里调用了某函数”，它就会答非所问或找不到代码。项目大、文件多的话，第一次索引会花几分钟，耐心等它跑完，不要随手关掉。

提交信息生成：我习惯在 Git 面板里用 Cursor 自动生成提交信息。它会根据 diff 生成模式，不过生成的信息偏“完整”，我一般会手动精简成一句话。

2.2 Rules 文件：我用规则把 Cursor “调教”成团队风格

Cursor 支持两类规则：全局规则（放在用户目录下）和项目规则（放在项目.cursor/rules目录下）。这个机制很多人没用起来，其实它比任何提示词技巧都值钱。

我的做法是建立一个.cursor/rules/developer.md文件，内容不仅包括技术约束，还包括团队沟通习惯。举个具体的示例：

# 项目开发规则 ## 技术边界 - 后端使用 Python FastAPI，路由使用 APIRouter 方式注册。 - 数据库访问通过仓库层（Repository）统一处理，禁止在业务逻辑里直接写 SQL。 - 所有时间字段统一存储 UTC 时间戳，输出时转本地时间格式。 ## 代码风格 - 函数命名使用动词开头，变量命名使用名词，禁用含糊名称如 data、tmp。 - 每个公共函数必须有 Docstring，说明参数含义、返回值、异常情况。 - 所有对外接口的返回结构统一为 { "code": 0, "data": ..., "message": "success" }，错误时 code 非零。 ## 测试规范 - 新增业务方法必须配套单元测试，先写测试再写实现。 - 测试数据一律用工厂函数生成，不用固定 JSON 文件。 ## 沟通偏好 - 改写代码前先简要说明修改计划，除非我明确要求直接给出修改结果。 - 遇到不确定的业务规则，在回复里明确列出假设，不要自作主张。

写这个文件之后，Cursor 在 Chat、Tab 补全、Cmd+K 里的生成风格都会明显向这个规则靠拢。有一次我让它加一个新接口，它自动用了仓库层模式、带了返回结构、补了单元测试框架——这在没写规则之前是做不到的。

2.3 模型怎么选：我常用的几种搭配

Cursor 现在已经支持多个模型，既有自家模型也有其他主流模型。我实际使用的选择逻辑如下表：

我的经验是不要迷信“最强模型”。有些最强模型在单次生成质量上确实高，但在快速迭代试错场景下，响应慢反而打断心流。我会在配置里让不同场景走不同模型，比如日常 Tab 补全走快速模型，重构时手动切到强推理模型。

另外，本地模型我也试过，主要是为了数据安全考虑，但在代码理解深度上确实和云端模型有差距。所以我的默认选择是云端模型，但涉及敏感项目时会切换到本地模式或直接关闭 AI 功能。

3. 日常编码中的实际用法：从对话到生成再到审查

3.1 Tab 补全：不是自动补全，而是“预判式编程”

Tab 补全是我使用频率最高的功能，几乎每个文件都在用。我观察到很多新手会把它当成高级版 IntelliSense，其实它的能力远远不止于此。

它能做什么：

• 根据函数名加签名，自动补出方法体和返回逻辑；
• 根据当前变量类型，自动补出链式调用的后续操作；
• 在循环或条件语句中，自动生成重复性分支。

我建议的姿势：写一个函数时，先写函数签名和关键的注释，然后让 Tab 补全顺着这个“意图”往下推。比如我写一个get_user_profile(user_id)，注释里写明“需要返回用户基本信息、最近订单数和会员等级”，Tab 往往能直接把查询逻辑、聚合并返回完整结构。如果你只写一个空函数名让它猜，它补出来的东西经常不对。

一个很关键的技巧是：Tab 补全生成的内容如果要改，用“Tab”键接受、用“Esc”拒绝，但更多时候我会改掉局部，而不是全盘接受或拒绝。比如它补出的逻辑对，但变量命名不符合我习惯，我会手调变量名，这会教会模型下次注意。

3.2 Chat 对话：上下文范围管理是核心

Chat 面板看起来是个聊天框，但它真正的核心能力是“能精准引用你项目里的代码”。这里最关键的操作是@和/：

• @文件名：把某个文件加入当前对话上下文，适合局部问题讨论。
• @文件夹路径：把一个目录加入上下文，适合梳理模块流程。
• @Codebase：让模型做全项目检索，但要注意索引是否完整。
• /命令菜单：我常用/explain（解释代码）、/fix（修复选中的报错）、/tests（对选中代码生成测试）。

我最常犯的错以前是：不限定上下文，上来就问“这个报错怎么解决”，结果模型给出的是通用答案。后来我养成了习惯，先在编辑器里选中报错代码，再打开 Chat 并@相关文件，然后才提问。精确上下文下的回答质量，和瞎聊不是一个量级。

关于长对话，我还有一个切身体会：同一个对话窗口用太久，模型会越来越“飘”。因为上下文越长，前面的信息越是干扰，尤其当模型尝试在早期错误假设上继续推理时。所以我的策略是：一个任务一个窗口，任务结束了就新开对话，重新加载相关文件。

3.3 Cmd+K 修改代码：局部修改的正确姿势

Cmd+K（按平台不同，也可以是 Ctrl+K）是我改代码效率提升最明显的功能。它可以在不打开 Chat 的情况下，对选中的代码块直接发出修改指令。

我的常用姿势是：

1. 选中一段要改的函数；
2. 按下 Cmd+K，输入修改指令，比如“增加参数校验”“改成异步实现”“提取公共方法”；
3. 看 diff，接受或微调。

这个功能特别适合处理“局部重构”。比如你接手的项目里有个函数写了 200 行，你想拆成几个小函数，鼠标选中那 200 行，输入“把这个函数按职责拆分为三个独立函数，保持对外行为不变”，它通常能给出不错的结果。

但要注意，Cmd+K 有个隐藏风险：它只看到选中区域和当前文件，看不到全局依赖。如果你让它改一个被很多地方调用的公共函数，它可能改变返回值结构或抛错方式，导致其他地方编译不通过。这种时候我会先搜索这个函数的所有调用点，确认改动能影响的范围，再动手。

4. 重构与跨文件修改：我的一套实操流程

4.1 让 AI 先“读代码”再动手

跨文件重构是 Cursor 相比普通 AI 插件最能展示能力的场景。但想用好，必须遵循一个原则：先让 AI 读懂再动手，不要上来就改。

我之前接了一个老模块的活，里面有个数据同步服务的代码，循环嵌套、重复逻辑很多。我当时的操作是：

1. 在 Chat 里@这个服务的主目录，让它先说明这个模块的调用链和核心流程；
2. 等它输出的结构梳理和我理解的核对无误后，再让它“在不改变对外接口的前提下，把同步流程抽成三步：数据拉取、数据转换、数据写入”；
3. 等它给出改动方案和涉及文件清单之后，才让它逐文件修改。

你会发现，如果跳过第 1 步，AI 的修改经常在结构上跑偏。比如它会顺手改变对象字段名、合并多个方法，虽然逻辑上没问题，但风格上和你项目其他模块明显不一致。让 AI 先梳理一遍，它后面动手时会更理解上下文。

4.2 小步提交：一次重构只做一件事

很多教程都会说“用 Cursor 做大规模重构”，但我实际经验是：重构范围越大，翻车概率越高。哪怕 AI 很聪明，一旦改动涉及三个以上文件、涉及公共接口调整，很容易出现“改 A 的时候不知道 B 也依赖它”的问题。

我的做法是把大任务拆成多个小任务，每个小任务一次只做一件事：

• 第一步：只给一个类新增字段和 getter/setter，不改业务逻辑；
• 第二步：把某个方法的实现换掉，保留方法签名；
• 第三步：把调用方适配新方法；
• 第四步：删除旧代码并更新相关测试。

每完成一步，我会跑一次编译和测试，确认没问题再提交一次。这样做的好处是，出了问题能快速定位是 AI 生成的哪段代码引入的，不需要在一个巨大的 diff 里大海捞针。

4.3 测试先行：用测试兜底生成代码

我在前面说过 AI 生成代码的 bug “看起来都很合理”，尤其是重构时，它可能会默默地改变边缘行为。所以我给自己的规则是：重构之前，必须先把测试跑绿。

具体做法是：

1. 重构前，先运行一遍现有测试套件，记录基线；
2. 让 Cursor 在修改代码的同时，给每个变更点补充或更新单元测试；
3. 运行测试，比较结果。

有一次我要让 Cursor 把一套旧 API 从同步改成异步。我下午让它生成了一版异步实现，跑测试发现所有用例原理上都不适配套件，于是我先重写了测试用例，再用 Cmd+K 让它在不破坏这些测试的前提下改造，最后才好。没有测试兜底，用 AI 重构就像在没有护栏的悬崖边开车。

5. 踩坑实录与排查技巧

5.1 AI 生成“看着非常对，但其实有 bug”的代码

这是最坑的事。AI 生成代码的语法往往完全正确，风格也统一，但逻辑上可能存在隐蔽问题：忘处理空列表、没判空指针、类型标错了、循环边界差一。尤其是长时间和 AI 对话后，模型会产生“惯性”，沿用对话早期错误的前提。

我的排查套路是：

1. 不要信任“编译通过”，编译正确不等于逻辑正确；
2. 重点看条件分支：if、else、try-catch里经常藏着问题；
3. 审视边界值：如果涉及循环和数组索引，手动在边界数据上走一遍；
4. 让 AI 自己找错：把 bug 复现步骤贴进 Chat，让它先解释它认为的代码行为，再对照实际行为。

有一次我让它写一个时间区间合并工具。它生成的代码逻辑很干净，但在处理跨天的时间段时错了。我第一反应是问它“这段代码在跨天场景下会怎样”，它分析了之后立刻承认了自己漏掉日期部分——这一刻我发现，让 AI 检查自己的代码不一定靠谱，但让它解释代码行为、由人来比对，往往能快速暴露问题。

5.2 上下文太长导致越改越乱

用得久了，聊天窗口里塞了一堆文件和消息，这时候你再发一个“把刚才那个函数再改一下”，它可能把前面某个已经不相关的实现当成最新版本来改。这就是上下文膨胀带来的问题。

我的解决方法是：

• 建立“重新开始”的仪式：任务超过 20 轮对话就新开窗口，重新@关键文件；
• 使用“给人看的笔记”：在项目里维护一个AI_NOTES.md，记录当前重构进度、已完成事项、遗留问题。每次新开对话时让 Cursor 先读这个文件，再开始干活；
• 把需求写进规则文件：凡是跨会话依旧生效的约束，都写进.cursor/rules，而不是依赖对话记忆。

这个习惯的改变，让我和 AI 合作的稳定性明显提升。很多时候你以为 AI 变笨了，其实是因为它的上下文已经被污染了。

5.3 安全问题：不能把生产代码无脑交给大模型

用云端 AI 编辑器，数据会上传到第三方服务，这是所有团队都必须正视的问题。Cursor 本身有隐私模式（隐私模式下默认不上传代码做模型训练），但我遇到的实际问题是：很多公司允许用 AI 编码，却要求内部代码不出内网。

这种情况下我建议：

• 项目分级：可以随便用 AI 的 Demo 项目，和关键业务项目分开；
• 敏感信息守卫：永远不要让 AI 接触密钥、连接串、个人数据样本，可以在.cursorignore里排除敏感文件，不让它被索引；
• 代码审查加倍：如果项目代码要交给 AI 生成，审查必须更严格，不仅看逻辑，还要看是否泄漏内部命名和规则。

我听某位同行说过一句话：AI 写代码本身不是风险，风险和风险控制都在流程里。我非常认同。

5.4 性能问题：索引卡顿、补全变慢

Cursor 在超大项目（几十万行代码）里，索引和补全偶尔会变慢。我的应对经验：

• 划分工作空间：不要把一个巨型 monorepo 整个打开，用工作区折叠或单独打开相关子项目；
• 维护 .cursorignore：把node_modules、dist、build、vendor等目录加进去，不仅加快索引，还减少无关代码对 AI 回答的干扰；
• 重启大法：如果补全延迟高到明显影响手速，直接重启 Cursor 而不是等它，很多时候重启后索引状态会刷新。

还有一个冷门技巧：如果你发现某个文件总是补全不理想，检查它是否被.cursorignore误排除了。我遇到过因为把build目录排除，结果某个源码文件不知怎么被带进去导致不索引的情况。

6. 我的私人配置与习惯清单

6.1 一份可以直接抄的配置摘要

这里是我目前使用的偏好设置摘要，未必适合所有人，但可以作为一个参考起点：

6.2 我对“人类 + AI”协作模式的一点心得

用了一年 Cursor，我最大的改变不是打字更快，而是养成了更强的代码判断力。以前写代码靠记忆和查找，现在写代码靠“验证 AI 的判断”，所以对代码逻辑、架构边界、测试覆盖的理解反而更深了。

如果你也想真正用好它，我建议从一个小模块开始，强制自己用“AI 生成 + 人工重构”的模式走完整个开发流程，而不是只在卡壳时问一句。等你习惯了这种协作节奏，会明显感觉到自己从“写每一行代码”变成了“把控每一块代码”。这也是我目前理解的 AI 辅助开发的真正姿势。

6.3 后续还可以这样扩展

Cursor 在团队协作和公司级使用上还有不少空间，比如共享项目规则、统一模型配置、接入内部知识库。我自己已经在团队里推广了统一的 Rules 文件，效果相当好。下一步我想试试让 Cursor 参与代码评审流程，看看它能不能从测试覆盖率和异常处理的角度提前拦截问题。如果你也在用，欢迎交流你的工作流。