企业官网建设流程全解析

1. 为什么我要把 Cursor 揉进 PStack 工作流

第一次听说 Cursor 是在一个做全栈的朋友群里，有人丢了一张截图，说“这玩意儿能直接读我整个项目的上下文，改代码不用来回切窗口”。我当时的第一反应是：又是一个套壳编辑器，热度过了就凉。结果自己上手用了两周，发现它跟之前那些“AI 补全插件”完全不是一个路数——它不是在你打字的时候猜下一行，而是能理解你整个仓库的结构，然后按你的意图去改多个文件。

PStack 是我自己攒的一套个人技术栈，说白了就是把日常开发、调试、部署、记笔记这几件事串成一条流水线。以前这条流水线上每个环节都是独立的工具：编辑器管写代码，终端管跑命令，浏览器管查文档，笔记软件管记坑。工具一多，切换成本就上来了，思路经常被打断。把 Cursor 塞进 PStack 之后，最大的变化不是“写代码变快了”，而是上下文不再丢失——我在编辑器里就能完成查、改、跑、记这一整套动作。

这篇文章适合两类人看：一类是已经装了 Cursor 但只把它当普通编辑器用的，另一类是想搭一套顺手的个人工作流、又不想被一堆工具割裂注意力的。我会把自己这两周踩过的坑、调过的配置、以及真正跑通的几个场景完整拆开讲，包括参数怎么设、提示词怎么写、哪些操作千万别做。内容基于我自己的实操记录，涉及具体项目的地方都用代称处理，你照着思路套到自己的项目上就行。

先说结论：Cursor 的核心价值不在于“AI 帮你写代码”，而在于它把 AI 能力嵌进了编辑器的每一个交互节点，让你在原本就要做的动作里顺手用上它。理解这一点，后面的所有配置和技巧才有意义。

2. Cursor 在 PStack 里的定位与整体设计思路

2.1 先搞清楚 Cursor 到底解决什么问题

很多人对 Cursor 的误解在于把它当成“更聪明的代码补全”。如果你只用它的 Tab 补全，那确实跟其他工具差别不大。Cursor 真正区别于传统编辑器的地方有三个：

第一，仓库级上下文。它能索引你整个项目的文件，你在对话框里问“这个函数在哪里被调用了”，它会去扫全仓库，而不是只看当前文件。这一点对维护老项目特别有用，因为老项目的调用关系往往散落在十几个文件里，人肉找起来很烦。

第二，多文件编辑能力。你可以在对话里描述一个改动需求，比如“把所有用到旧接口的地方换成新接口，并更新对应的类型定义”，它会生成一个跨多个文件的 diff，你确认后一次性应用。这个能力用好了，重构效率是数量级的提升。

第三，内联编辑。选中一段代码，按快捷键直接呼出输入框，用自然语言描述你要怎么改，它就地替换。这个动作不打断你的光标位置和思路，比切到侧边栏对话框再回来要顺得多。

把这三个能力对应到 PStack 的流水线上，我的定位是这样的：Cursor 负责“写”和“改”这两个环节，同时通过内置终端和笔记功能，把“跑”和“记”也收进来。查文档这件事我仍然用浏览器，但查完的结论会立刻以注释或笔记的形式落回 Cursor 里，避免下次再查一遍。

2.2 为什么不是“装个插件”而是“换掉编辑器”

有人会问：我现在的编辑器装个 AI 插件不就行了，为什么要换？我试过在原来的编辑器里装补全插件，体验上的差距主要在上下文深度。插件受限于宿主编辑器的 API，通常只能拿到当前文件或当前选区的内容，没法做仓库级索引。而 Cursor 是基于编辑器内核深度改造的，它能拿到整个工作区的文件树和内容，这是插件做不到的。

另一个原因是交互一致性。插件往往是“补全归补全，对话归对话”，两套逻辑。Cursor 把补全、内联编辑、侧边对话、终端命令生成统一在一套上下文里，你在任何一个入口做的操作，其他入口都能感知到。比如你在对话里让它改了一个函数，接着在内联编辑里让它加个测试，它知道刚才改了什么。

当然，换编辑器是有成本的。快捷键要重新适应，插件生态要重新配，主题和字体要重新调。我的建议是：如果你每天写代码超过三小时，这个迁移成本一周内就能回本；如果只是偶尔写写脚本，那确实没必要折腾。

2.3 PStack 流水线的整体结构

我把整条流水线分成四段，每段对应 Cursor 里的一个使用模式：

这四段不是严格线性的，实际使用中会来回跳。比如“跑”的时候发现报错，直接切到“改”去修，修完再“跑”。Cursor 的好处是这些切换都在同一个窗口里完成，不用 Alt+Tab 换来换去。

提示：不要一上来就把四段全用上。先挑你最痛的那一段切入，用顺了再加下一段。我当初是先只用“改”，因为重构老代码最烦，用了一周才把“写”和“跑”也迁进来。

3. 核心配置与实操要点拆解

3.1 模型选择：不是越贵越好

Cursor 支持切换底层模型，不同模型在速度、质量、成本上差异很大。我的实测经验是这样的：

• 日常补全：用最快的那个小模型就够了。补全这个动作对延迟极其敏感，超过 300 毫秒你就会觉得卡顿，思路就断了。小模型在补全场景下的准确率和大模型差距不大，因为补全的上下文通常很短。
• 内联编辑：用中等模型。这个场景需要理解你的意图并生成一段完整代码，对质量要求比补全高，但又不至于要动用最强的模型。
• 侧边对话做重构：用最强的模型。重构涉及多文件、长上下文、复杂逻辑，这时候质量比速度重要得多，慢几秒可以接受。

具体怎么切？在设置里可以给不同场景配不同的模型。我一开始图省事全用最强的，结果补全卡得没法用；后来全用最快的，重构出来的代码又经常有逻辑漏洞。分开配之后体验才正常。

注意：模型选择没有标准答案，跟你的项目语言、代码风格、网络状况都有关。建议花半天时间，拿同一个任务在几个模型上各跑一遍，对比结果再定。

3.2 上下文范围：给得太多反而更差

Cursor 的对话质量高度依赖你给它多少上下文。给少了它不知道背景，给多了它会抓不住重点。我的经验是：

• 单文件问题：只把当前文件加进上下文，不要整个仓库。比如“这个函数为什么死循环”，当前文件就够了。
• 跨文件问题：用 @ 符号手动指定相关文件，而不是让它自己扫全仓库。比如“A 文件调用了 B 文件的接口，现在接口改了，帮我更新 A”，就手动 @A 和 @B。
• 全仓库问题：只有做全局搜索类任务时才让它扫全仓库，比如“找出所有硬编码的密钥”。

这里有个坑：Cursor 默认会把最近打开的文件自动加进上下文，有时候你问的是 A 文件的问题，它却把 B 文件的内容也带进去了，导致回答跑偏。我的做法是每次开新对话前，先清空上下文，然后手动加需要的文件。多花十秒，省下的是来回纠正的时间。

3.3 规则文件：让 AI 记住你的代码规范

Cursor 支持一个规则文件，你可以在里面写项目约定，它会自动应用到所有对话里。这个功能很多人不知道，但用好了能省大量重复解释。

我的规则文件里写了这几条：

• 缩进用 2 空格，不用 Tab
• 变量命名用驼峰，常量用全大写下划线
• 所有异步函数必须处理错误，不允许裸 await
• 注释用中文，写在函数上方
• 不要生成 console.log，用项目里的日志工具

写进去之后，它生成的代码基本符合规范，不用每次手动改。规则文件的位置和格式在官方文档里有说明，这里不展开，重点是你得持续维护它——每次发现它犯了同样的错，就把对应的规则补进去。

提示：规则文件不要写太长，超过一屏它可能就记不住了。挑最常犯的错写进去，十条以内效果最好。

3.4 快捷键：把高频动作压到肌肉记忆里

Cursor 的默认快捷键跟主流编辑器接近，但有几个 AI 相关的动作需要自己配。我改过的几个：

• 内联编辑：默认是 Cmd+K，我改成了 Cmd+Enter，因为 K 离手指太远。
• 接受补全：默认是 Tab，这个保留，因为符合直觉。
• 拒绝补全：默认是 Esc，保留。
• 打开侧边对话：默认是 Cmd+L，我改成了 Cmd+Shift+L，避免跟其他快捷键冲突。

改快捷键的原则是：高频动作用最顺手的位置，低频动作可以放远一点。内联编辑我一天用几十次，必须顺手；侧边对话一天用几次，远一点无所谓。

4. 完整实操流程与关键环节实现

4.1 场景一：接手一个陌生模块，快速摸清结构

这是我最常用的场景。假设你被拉进一个项目，要改一个你从没看过的模块。传统做法是打开文件一个个读，读半天还不知道调用关系。用 Cursor 的流程是这样的：

第一步，把整个模块的文件夹拖进工作区。它会自动索引，索引完成后侧边栏会显示文件树。

第二步，打开模块的入口文件，在侧边对话里问：“这个模块的整体职责是什么？各个文件之间是什么关系？”它会扫一遍相关文件，给你一个结构化的回答。

第三步，针对你不理解的具体函数，选中它，用内联编辑问：“这个函数做了什么？它的输入输出是什么？”它会就地给你解释，不用切窗口。

第四步，让它画出调用链：“从入口到这个函数，中间经过了哪些调用？”它会列出路径，你顺着看一遍就清楚了。

这套流程走下来，摸清一个中等复杂度的模块大概需要二十分钟，比人肉读快得多。关键是每一步的结论都要自己验证，它有时候会漏掉一些间接调用，你得对着代码确认一遍。

4.2 场景二：跨文件重构，一次改到位

重构是 Cursor 最能体现价值的地方。我拿一个真实案例来说：项目里有个旧的日期处理工具函数，散落在十几个文件里被调用，现在要统一换成一个新的工具库。

传统做法是全局搜索旧函数名，一个个文件改，改完还要跑测试看有没有漏。用 Cursor 的流程：

第一步，在侧边对话里描述需求：“项目里所有调用 oldDateUtil 的地方，换成 newDateLib 的对应方法，注意参数顺序变了，旧的是 (date, format)，新的是 (format, date)。”

第二步，它会生成一个跨文件的 diff，列出每个文件的改动。你逐个 review，确认没问题就应用。

第三步，应用后跑一遍测试。如果有漏改的，它会报错，你再把报错信息丢回对话里让它修。

这里的关键是参数顺序变化这种细节一定要在描述里说清楚。我第一次做类似重构时没说参数顺序，结果它按旧顺序生成了新调用，跑起来全是 bug。后来学乖了，凡是接口签名有变化的，都在描述里列出来。

注意：跨文件重构前一定要先提交一次代码，或者确保有版本控制。万一改崩了，能一键回滚。我吃过这个亏，改到一半发现方向错了，又没存快照，只能手动一个个改回来。

4.3 场景三：写测试，把边界情况补全

写测试是个体力活，尤其是边界情况，人脑很容易漏。我现在的做法是：先自己写主流程的测试，然后把函数签名和业务描述丢给 Cursor，让它补充边界情况。

具体操作：选中要测试的函数，内联编辑输入“为这个函数写单元测试，覆盖空输入、超长输入、特殊字符、并发调用这几种情况”。它会生成一组测试用例，你挑有用的留下，没用的删掉。

实测下来，它补充的边界情况大概有七成是有效的，剩下三成要么重复要么不适用。但就是这三成里，经常有一两个是你自己没想到的。比如有一次它生成了一个“输入为负数”的用例，我才想起来这个函数确实没处理负数。

写测试的提示词有个技巧：明确列出你要覆盖的维度。只说“写测试”它会给你一堆常规用例，说了“空输入、超长、特殊字符、并发”它才会针对性生成。

4.4 场景四：调试报错，从堆栈到修复

报错调试是日常最高频的动作。传统流程是：看报错、猜原因、改代码、重跑、还报错、再猜。用 Cursor 可以把这个循环压缩。

我的流程是：把报错堆栈复制到侧边对话里，加上一句“这是运行时的报错，帮我定位原因”。它会结合当前打开的代码分析，给出几个可能的原因和对应的检查点。

然后我按它说的检查点逐个验证，找到真正的原因后，用内联编辑修。修完直接在 Cursor 的内置终端里重跑，不用切窗口。

这里有个细节：报错信息要完整复制，包括堆栈的每一行。只复制最后一行“TypeError: xxx”它很难定位，因为缺少调用路径。完整堆栈能让它准确找到出错的代码位置。

4.5 场景五：用内置终端把“跑”也收进来

Cursor 内置了终端，可以直接在里面跑命令。我一开始觉得这没啥稀奇，哪个编辑器没终端。但用久了发现两个好处：

一是命令生成。我不记得某个命令的参数时，直接在终端上方输入自然语言描述，比如“找出当前目录下所有超过 10MB 的文件”，它会生成命令，我确认后执行。这比查手册快。

二是输出联动。终端里的输出可以直接被对话引用。比如跑测试失败了，我选中失败信息，右键“发送到对话”，它就能基于这个输出分析。不用手动复制粘贴。

内置终端的 shell 配置跟系统终端是独立的，第一次用要设置一下默认 shell。我设成了跟系统一致的，这样环境变量和别名都能用。

5. 常见问题与排查技巧实录

5.1 补全不触发或触发太慢

这是最常见的问题。排查顺序如下：

我遇到过一次补全完全失效，排查半天发现是项目根目录有个巨大的日志文件被索引了，导致索引进程一直卡着。把日志目录加到忽略列表后就正常了。所以索引忽略配置一定要配，把构建产物、依赖目录、日志目录都排除掉。

5.2 对话回答跑偏，答非所问

这个问题九成是上下文污染导致的。排查思路：

先看当前对话里挂了哪些文件。如果挂了一堆不相关的文件，清掉重开。然后确认你的问题描述是否具体。问“这个代码有什么问题”太模糊，问“这个函数在输入为空时会不会崩溃”就具体得多。

还有一个隐蔽的原因：规则文件里有冲突的规则。比如你写了“用 2 空格缩进”，又写了“遵循项目现有风格”，如果项目现有风格是 4 空格，它就不知道该听谁的。规则文件要保证内部一致。

5.3 多文件改动应用后编译不过

这个我踩过好几次。原因通常是它只改了调用方，没改被调用方，或者改了类型定义没改实现。排查方法：

应用 diff 后先别急着跑，先看一遍改动列表，确认涉及的文件是否完整。然后跑一次类型检查或编译，把报错丢回对话让它补。如果报错太多，说明这次改动范围太大，应该拆成几次小的改动，每次改一个维度。

提示：大重构拆成小步骤，每步都编译通过再进下一步。一次性改二十个文件，出错了很难定位是哪里引起的。

5.4 生成的代码有安全隐患

AI 生成的代码有时候会引入安全问题，比如拼接 SQL、硬编码密钥、不校验输入。我的做法是在规则文件里明确写几条安全红线：

• 所有数据库查询必须用参数化，不允许字符串拼接
• 不允许硬编码任何密钥或令牌
• 所有外部输入必须校验

然后每次应用改动前，扫一眼有没有触碰这些红线。规则文件不能百分百拦住，但能大幅降低概率。

5.5 笔记功能怎么用才不鸡肋

Cursor 的笔记功能我一开始觉得多余，后来发现用对了场景很香。我的用法是：把排查问题的结论记成笔记，而不是记过程。比如“这个报错是因为缓存没清，清缓存的命令是 xxx”，这种结论性内容记下来，下次遇到直接搜。

不要记流水账，比如“今天改了 A 文件，明天改了 B 文件”，这种记了也不会看。笔记的价值在于下次遇到同样问题时能秒查，所以只记可复用的结论。

6. 我踩过的坑和几条实在建议

先说几个我实际踩过的坑，都是文档里不会写的。

第一个坑：不要让它一次改太多。我试过让它“把这个模块重构成面向对象风格”，结果它生成了几百行 diff，我 review 了半小时还没看完，最后发现方向不对全废了。后来改成一次只改一个类、一个函数，每次改动控制在五十行以内，review 快，出错也好回滚。

第二个坑：补全的代码要过脑子。它补全的代码看起来往往很合理，但有时候会调用不存在的方法，或者用错参数。我有一次没细看就接受了补全，跑起来才发现调了一个根本没定义的函数。现在的习惯是：补全超过三行的，一定停下来看一眼。

第三个坑：别在没提交的情况下做大改动。这个前面提过，但值得再说一遍。AI 改动的不确定性比人手改要高，因为它可能理解错你的意图。有版本控制兜底，你才敢大胆试。

再说几条实在建议。

关于提示词：具体比礼貌重要。不用写“请帮我”“麻烦你”，直接说“把这个函数改成异步的，错误用 try-catch 包起来”。描述里包含三要素：改什么、改成什么样、有什么约束。

关于工作流：先跑通一个场景再扩展。别一上来就把所有功能都用上，那样只会手忙脚乱。挑一个你最痛的点，用顺了再加下一个。

关于心态：把它当实习生，不是当专家。它能干很多活，但需要你把关。你越清楚自己要什么，它干得越好。你自己都说不清楚的需求，它更说不清楚。

最后分享一个我最近在用的技巧：让它先给方案再动手。对于复杂改动，我会先问“你打算怎么改，列个步骤”，确认方案没问题再让它生成代码。这样能避免它闷头改一堆然后发现方向错了。多花一轮对话，省下的是大量返工时间。

这个工作流我还在持续调，后面如果发现新的好用法再补。你要是也在用类似的工具，欢迎交流你的配置和踩坑记录。