企业官网建设流程全解析

1. 为什么我最终把主力编辑器换成了 Cursor

先说结论：我不是因为"AI 编程很火"才换的，恰恰相反，我是被日常开发里那些重复到让人烦躁的琐事逼过去的。写业务代码的人应该都有体会，一天里真正需要动脑子的时间可能只占三成，剩下七成都在干这些事：翻文件找某个函数在哪定义、照着已有模式再写一遍 CRUD、改一个字段名结果牵连十几个文件、对着报错信息一行行猜哪里传错了参数。这些活儿不难，但极其消耗耐心，而且打断心流之后重新进入状态又要花十几分钟。

Cursor 吸引我的地方，不是它能"自动写代码"这种宣传话术，而是它把代码库级别的上下文理解和对话式修改揉进了编辑器本身。注意这个区别：很多工具是"你复制一段代码给它，它给你改一段"，而 Cursor 是"它能看到你整个项目，你告诉它要做什么，它自己去定位、去改、去验证"。这个差别在实际项目里是质变。一个几千行的老项目，你让 AI 只看单个文件，它给出的建议经常是错的，因为它不知道这个函数在别处怎么被调用；但当它能索引整个仓库，情况就完全不一样了。

我主要用它做三类事情：一是跨文件重构，比如把某个数据模型从一种结构迁移到另一种；二是读陌生代码，接手别人写的模块时让它先给我讲一遍调用链；三是写测试和样板代码，这部分纯体力活，交给它性价比最高。至于从零写一个完整功能，我反而用得比较克制，原因后面会细说。

这篇文章我想聊的不是"Cursor 有哪些功能"这种说明书式的内容，而是我踩过坑之后总结出来的一套实际用法：怎么组织对话、怎么控制它的改动范围、什么时候该信它、什么时候必须自己上手。如果你已经在用或者正准备用，这些经验应该能帮你少走不少弯路。

2. 上手前必须搞清楚的几个认知误区

2.1 它不是"更聪明的自动补全"

很多人第一次打开 Cursor，第一反应是"这不就是个带 AI 的 VS Code 吗"，然后继续用 Tab 补全，觉得也就那样。这个理解偏差会导致你完全用不出它的价值。自动补全解决的是"这一行怎么写"，而 Cursor 真正强的是"这个需求怎么落地"。举个我自己的例子：我需要给一个已有的接口加一层缓存，涉及改三个文件、加一个配置项、处理缓存失效。如果只是补全，我得自己想清楚每一步；但在 Cursor 里，我直接描述需求，它会先告诉我它打算改哪几个文件、每个文件改什么，我确认之后再让它动手。这个"先规划再执行"的流程，才是它和普通补全工具的本质区别。

2.2 上下文不是越多越好

新手容易犯的错是把整个项目都塞给它，觉得信息越全越好。实际上上下文窗口是有限的，塞太多无关文件反而会稀释真正重要的信息，导致它抓不住重点。我的做法是按需喂上下文：改哪个模块就让它聚焦哪个目录，涉及跨模块调用时再手动把相关文件加进来。Cursor 有个@符号可以指定文件、文件夹、甚至整个代码库，用好了比无脑全选强太多。

2.3 它写的代码你必须能看懂

这一点我要重点强调。我见过有人让 AI 生成一大段代码，跑通了就提交，结果线上出问题排查半天找不到原因。AI 生成的代码有个特点：看起来对，但边界条件经常处理得含糊。比如空值判断、并发场景、异常分支，它可能只覆盖了主流程。所以我的原则是：它写的每一行，我都要能解释清楚为什么这么写。看不懂的就让它解释，解释完还不放心的就自己重写。这不是不信任工具，而是对自己负责。

2.4 模型选择要看任务类型

Cursor 支持切换不同的底层模型，不同模型擅长的方向不一样。我的经验是：需要深度推理的任务（比如复杂算法、架构设计）用推理能力强的模型；需要快速批量处理的任务（比如改一堆重复代码、写测试）用响应快的模型。这个没有绝对标准，你得根据自己的实际任务多试几次，找到手感。我一般会在一个任务开始前想一下：这个活儿是"想"的成分多还是"做"的成分多，然后据此选模型。

3. 我日常最常用的四种交互方式

3.1 用对话模式做需求拆解

这是我最常用的方式。具体操作是打开侧边栏对话，用自然语言描述我要做什么，但描述的时候有个技巧：说清楚"现状"和"目标"，而不是直接说"帮我写个函数"。比如我会这样写："现在order模块里有个calculateTotal函数，它只处理了普通商品。我需要让它支持折扣商品，折扣规则是满减和百分比二选一，优先级是满减优先。相关文件在src/order/目录下。"这样它就能准确定位，而不是瞎猜。

对话模式最大的价值在于来回确认。它给出方案后，我会追问："如果折扣金额超过商品总价怎么办？"这种边界问题它一开始往往不会主动考虑，但你一问它就能补上。这个互动过程其实也是在帮我自己理清需求。

3.2 用内联编辑做局部修改

选中一段代码，按快捷键唤出内联编辑框，直接说要怎么改。这个适合小范围、明确的修改，比如"把这个循环改成用 map"、"给这个函数加上参数校验"。它的好处是不打断你的编辑节奏，改完直接看 diff，不满意就撤销。我改 bug 的时候特别爱用这个：定位到出问题的那几行，选中，描述期望的行为，让它改。

这里有个细节：内联编辑的指令要具体到可验证。说"优化这段代码"它可能给你改得面目全非；说"把这个嵌套三层的 if 改成提前返回"它就改得很精准。指令越具体，结果越可控。

3.3 用代码库问答快速熟悉陌生模块

接手新项目或者回看自己半年前写的代码时，我会直接问它："payment模块的调用链是怎样的？从入口到落库经过哪些函数？"它会去索引里检索，然后给我一条相对完整的路径。这比我自己一个个文件翻快太多了。但要注意，它的回答可能遗漏某些动态调用或者反射场景，所以关键路径我还会自己再核对一遍。

3.4 用终端集成处理命令相关任务

Cursor 的终端和编辑器是打通的。当我遇到一个不熟悉的报错，可以直接把报错信息丢给它，它会结合项目上下文分析可能的原因，甚至给出修复命令。比如依赖版本冲突、构建脚本报错这类问题，它经常能直接指出是哪个配置项写错了。这个功能省去了我在搜索引擎和文档之间来回切换的时间。

4. 跨文件重构：最能体现价值的场景

4.1 一个真实的重构案例拆解

我之前做过一次数据模型迁移：原来订单状态用的是数字枚举（0 待支付、1 已支付、2 已发货……），后来因为要对接多个外部系统，数字含义对不上，决定改成字符串枚举。这个改动听起来简单，实际涉及：定义新的枚举类型、改所有赋值和比较的地方、改数据库读写映射、改接口返回格式、改前端对接的字段。粗算下来涉及二十多个文件。

我的操作流程是这样的：第一步，先让它扫描整个代码库，列出所有涉及订单状态的位置，我核对一遍确保没漏；第二步，让它先生成新的枚举定义和映射函数；第三步，分批让它改各个模块，每改完一批我就跑一次测试。整个过程大概花了两个小时，如果纯手工改，我估计得花一整天，而且很容易漏掉某个角落。

4.2 控制改动范围的关键技巧

跨文件重构最大的风险是改多了或者改错了。我的经验是：一次只让它改一个逻辑单元。比如上面那个例子，我不会说"把所有订单状态都改成字符串"，而是说"先改order模块下的状态赋值"。改完验证没问题，再改下一个模块。这样即使出错，影响范围也可控。

另外，改之前一定要确保有测试覆盖或者有回滚方案。我一般会先提交一次当前代码作为基线，这样改崩了可以直接回退。没有测试的老项目，我会让它先帮我补几个关键路径的测试，再动手重构。

4.3 重构后必须做的验证动作

AI 改完代码不代表就完事了。我固定会做三件事：一是看 diff，逐个文件确认改动符合预期，特别留意它有没有顺手改了不该改的地方；二是跑测试，单元测试、集成测试都跑一遍；三是手动验证关键路径，测试覆盖不到的地方自己点一遍。这三步做完，我才敢提交。

有个坑我踩过：有次它重构时把一个函数的返回值从null改成了undefined，测试没覆盖到这个分支，结果上线后前端判断=== null的地方全挂了。从那以后，我对这类"语义等价但行为不同"的改动特别敏感，看 diff 时会重点盯返回值、类型、默认值这些地方。

5. 让 AI 写出靠谱代码的提示词心得

5.1 描述需求时把约束条件说全

我发现很多人用不好 AI，问题出在描述太模糊。你说"写个登录功能"，它只能给你一个最通用的版本，但你的项目可能有特定的加密方式、特定的错误码规范、特定的日志格式。这些不说清楚，它写出来的东西你还得大改。

我的习惯是描述需求时带上这几样：输入输出是什么、边界条件有哪些、要遵循项目里哪个已有模式、有什么性能或安全要求。比如："写一个用户注册接口，入参是手机号和密码，密码要用项目里utils/crypto的hashPassword处理，手机号要校验格式，重复注册返回业务错误码 1001，参考login接口的写法。"这样它写出来的东西基本能直接用。

5.2 用"参考已有代码"代替长篇解释

与其花大段文字解释你想要什么风格，不如直接指一个已有的例子："照着userService的写法给productService加一个查询方法。"AI 模仿能力很强，给它一个模板，它就能举一反三。这个技巧在保持代码风格一致性上特别有用，尤其是团队有自己的一套约定时。

5.3 分步骤下指令而不是一次性说完

复杂任务我从来不一次性描述完，而是拆成几步。第一步让它理解现状，第二步让它给方案，第三步让它执行，第四步让它自检。这样每一步都有确认的机会，出错也能及时纠正。一次性说完的结果往往是它理解偏了，你还得从头再来。

5.4 遇到不满意时怎么调整指令

它第一次给出的结果不满意，别急着重新描述一遍，而是针对性地指出问题。比如"这个实现没有处理并发情况，加上锁"、"这个查询没有走索引，改成先按时间过滤"。这种增量式的反馈比推倒重来效率高得多，而且它能在原有基础上改进，不会丢掉已经对的部分。

6. 那些让我踩坑的边界情况

6.1 它可能"自信地写错"

这是最危险的情况。AI 有时候会用非常肯定的语气给出一个错误的实现，尤其是涉及特定库的 API 用法时，它可能记混了版本或者编造了一个不存在的方法。我的应对方式是：涉及第三方库的调用，一定去官方文档核对一遍。别嫌麻烦，这个习惯能帮你避免很多低级错误。

6.2 大文件处理容易丢上下文

当一个文件超过一定行数，它在处理时可能会丢失部分上下文，导致改动不完整或者前后不一致。我的做法是主动拆分大文件，或者明确告诉它"只看第 100 到 200 行"。项目里如果有那种几千行的巨型文件，建议先做拆分再让 AI 介入。

6.3 涉及敏感逻辑时要格外谨慎

加密、鉴权、支付这类逻辑，我基本不让 AI 主导，最多让它帮我写测试或者做代码审查。原因是这些地方一旦出错后果严重，而且 AI 对安全边界的理解不一定到位。这类代码我坚持自己写，写完可以让它帮忙看看有没有明显漏洞，但决策权在我手里。

6.4 别让它碰你不理解的配置

构建配置、部署脚本、CI 流程这些，如果 AI 改错了，可能导致整个流程挂掉，而且排查起来很麻烦。我一般只让它在明确知道要改什么的情况下动这些文件，改完必须本地验证一遍完整流程。

7. 把 Cursor 融进日常工作流的几个习惯

7.1 每天开工先让它梳理任务

我现在养成了一个习惯：早上开工前，把今天要做的事情用自然语言列给它，让它帮我拆成具体步骤，并指出可能涉及的文件。这个过程花不了几分钟，但能帮我把思路理清楚，避免做到一半发现漏了什么。

7.2 提交前让它做一次自查

写完一个功能准备提交前，我会让它检查一遍："这段改动有没有遗漏的边界情况？有没有和项目其他地方冲突？"它经常能发现一些我忽略的点，比如某个地方忘了加空值判断，或者某个常量定义重复了。

7.3 用它维护项目文档

项目里的 README、接口文档、注释，我经常让它根据代码自动生成或更新。代码改了文档没改是通病，让它来做这件事能省不少心。当然生成完我会过一遍，确保描述准确。

7.4 定期回顾它的建议质量

我会时不时回看它之前给的建议，哪些采纳了效果好，哪些采纳了出问题，哪些没采纳后来发现是对的。这个复盘能帮我摸清它的能力边界，知道什么任务可以放心交给它，什么任务得自己把关。用久了你会发现，它就像一个能力不错但需要监督的初级同事，用对了能帮你省大量时间，用错了反而添乱。

8. 关于效率提升的一点个人体会

用了大半年下来，我最深的感受是：AI 工具放大的是你原本的能力，而不是替代你的能力。如果你本身对代码结构、设计模式、边界条件有清晰的认知，它能帮你把这些想法快速落地，效率提升非常明显；但如果你自己都没想清楚要做什么，指望它给你一个完美方案，大概率会失望。

我现在的工作节奏是：想清楚的部分交给它执行，想不清楚的部分自己先想明白再交给它。这个分工让我既享受到了效率红利，又没有失去对代码的掌控。工具终究是工具，用得好不好，还是取决于用它的人。