企业官网建设流程全解析

上周三下午，我把屏幕切成两半：左边 Cursor 在给我补一个刚聊出来的导出模块，右边终端里的 Claude Code 正一行行读一个五年没人敢碰的订单结算类。两个工具同时在跑，风扇呼呼转，但那天我干了平时两天的活。这就是我现在固定的双 IDE 工作流——Cursor 负责写新功能，Claude Code 负责啃老代码。这套东西不是什么玄学配置，就是把自己当项目经理，把两个 AI 助手当两个性格完全不同的下属：一个手快、爱表现、敢想敢写；另一个话少、耐心、翻遍整个仓库才肯开口。你要做的，就是把活儿分对。

这篇分享主要讲三件事：为什么要把新功能和老代码拆给两个不同的工具、两边各自的实操步骤和配置细节、以及并行跑的时候那些必然会踩的坑。适合已经在用 AI 写代码但总感觉"效率没提上来"的人，也适合刚装好工具、还不知道怎么下嘴的新手。全文不讲概念，只讲我怎么干的。

1. 双 IDE 工作流的底层逻辑：把"创造"和"考古"拆开

1.1 新代码和老代码，压根是两种活儿

我带的项目里，活儿的性质差别特别大。一种是"新增"：新接口、新页面、新的数据处理流程，需求是上面刚聊出来的，代码库里根本没有对应实现，你需要的是一份能跑、结构看得过去、能被同事 review 通过的初稿。另一种是"改造"：一个 2019 年写的模块，当年的人早走了，注释只有一句"临时方案，后续优化"，现在要加一个字段、换一个计算口径，或者干脆把它从同步改成异步。这两种活儿的脑力消耗结构完全不同。

写新代码，难在"想清楚要什么"。你脑子里的画面一旦清晰，代码其实很快。所以这种活儿适合让一个上下文感知强、补全速度快、能跟你来回对话的工具来干——它看着你当前打开的文件、看着你光标附近的内容，猜你下一步要写什么。写老代码改造，难在"搞清楚现在是什么"。你需要的不是快，是耐心：把十几个文件串起来读一遍，搞清楚这个字段是谁写的、谁读的、什么时候被清空、有没有地方靠它的空值做判断，然后才敢动第一刀。这种活儿需要一个能自己满仓库乱逛、主动去 grep、去读文件、去追调用链的工具。

把这两种活儿塞给同一个工具，结果就是两边都拉胯。用对话式工具去啃老代码，你得手动把十几个文件贴进上下文，贴到最后自己都乱了；用终端智能体去从零写新功能，它会过度思考，动不动就给你来个重构，写出来的东西比你想要的复杂三倍。

1.2 我的分工原则与工具选型理由

我的原则一句话能说清：手边有明确目标、要产出新文件的活儿，交给 Cursor；目标模糊、要理解存量代码的活儿，交给 Claude Code。

选这两个工具不是随便挑的。Cursor 本质上是编辑器，它的优势是"贴着你的手"——补全、Tab 跳转、选中一段然后按快捷键让它改、多文件同时改。它跟你的编辑动作是融为一体的，你改一行它立刻知道，你打开一个文件它立刻读。这种紧耦合，天生适合"边想边写"。而且它的界面就是 IDE，你原有的插件、主题、快捷键、终端、调试器都在，迁移成本几乎为零。

Claude Code 是终端里的智能体，它的优势是"自己有手脚"。你给它一句话，它会自己去列目录、自己去搜关键词、自己去读十几个文件、自己跑测试命令，然后回来告诉你结论。它不需要你把文件一个个拖进来，也不需要你告诉它"这个类在哪个目录"。这个特性在存量代码里价值巨大，因为老代码最大的问题就是"你不知道你不知道什么"——你连要读哪些文件都不清楚，怎么可能手动喂给它。

一句话总结选型逻辑：谁掌握的信息多，谁就干那部分活。Cursor 掌握的是你当前视野里的信息，适合局部深挖；Claude Code 能主动获取全仓库信息，适合全局扫描。

1.3 这套工作流适合谁、不适合谁

先说适合的。第一种，手上有一定规模的存量项目，同时在迭代新功能的人。你的仓库大到你自己都记不清所有模块，这时候双工具收益最明显。第二种，接手别人项目的人。你要快速搞清楚一个陌生仓库的结构，Claude Code 那一套"先画地图再动刀"的流程能省你几天时间。第三种，独立开发者或者小团队。没人跟你结对编程，AI 就是你的结对伙伴，两个不同性格的伙伴刚好互补。

再说不太适合的。如果你的项目就是几百行脚本，或者你每天都在写完全独立的小工具，那单开一个工具就够了，双开纯属给自己找麻烦。还有一种情况要先缓一缓：如果你的代码里有大量不能外传的核心资产，或者团队对代码外发有严格规定，那在配置和使用之前，先跟你们负责人把边界聊清楚，这个前提比什么技巧都重要。

注意：这套工作流的价值来自"分工"，不来自"同时开两个窗口"。如果你两个窗口干同一件事，那只是把成本翻倍。

2. 环境搭建：Cursor 与 Claude Code 的安装与中文配置

2.1 Cursor 下载安装与界面汉化的完整步骤

Cursor 的安装没什么门槛，去官网下对应系统的安装包，Windows 是 exe，macOS 是 dmg，Linux 有 AppImage 和 deb。装完之后第一次打开会让你导入 VS Code 的配置——这一步很关键，一定要选导入，它会把你原来的插件、主题、快捷键、代码片段一起搬过来，省掉一两个小时的重新配置。如果你之前用的是别的 IDE，比如 Java 生态那套，导入不了也没关系，核心插件重新装一遍就行。

界面汉化这块我被问过太多次。Cursor 是 VS Code 的分支，所以汉化方式跟 VS Code 一样，两步搞定：

1. 按Ctrl+Shift+P（macOS 是Cmd+Shift+P）打开命令面板，输入Configure Display Language，回车。
2. 在列表里选中文(简体)。如果列表里没有中文，会提示你安装语言包，点确认，它会自动装好简体中文语言包，装完重启一下就是中文界面了。

如果你在命令面板里找不到那个选项，还有一条备用路径：左侧扩展面板搜索Chinese (Simplified)，找到微软官方那个中文语言包，点安装，然后重启。这个方法更直观，适合不想记命令的人。

提示：装完中文界面之后，建议把几个 AI 相关功能的快捷键先过一遍，在设置里搜索快捷键，把"接受建议""拒绝建议""触发内联编辑"这几个改成你顺手的组合。这一步花五分钟，后面每天省很多次手部动作。

装好之后还有一个设置我强烈建议打开：在设置里搜format on save，打开保存时自动格式化；再搜auto save，改成失焦自动保存。AI 生成的代码经常有缩进和空行的小瑕疵，自动格式化能帮你抹掉一大半，评审的时候不至于因为格式问题被退回。

2.2 Claude Code 的安装、登录与终端接入

Claude Code 是命令行工具，装法很直接。前提是你的机器上有 Node.js，版本不要太老，18 以上基本没问题。装之前先确认：

node -v npm -v

两个命令都能正常输出版本号，就可以装了：

npm install -g @anthropic-ai/claude-code

装完之后在任意项目目录下敲claude，第一次会走一遍登录或者配置凭证的流程，跟着提示走完就行。凭证配置好之后，它会把配置存在用户目录下，后续不用重复登录。

关于"在 IDE 里用"，有两条路。第一条是纯终端：在 Cursor 里按Ctrl+`打开内置终端，直接在项目根目录敲claude。这样做的好处是上下文统一，你 Cursor 里打开的就是 Claude Code 要读的那个目录，不容易搞错仓库。第二条是装 IDE 插件，把 Claude Code 的能力挂到编辑器面板里。我个人更推荐第一条，原因下面会讲。

有一类报错新手特别容易遇到：敲claude提示命令找不到。九成情况是全局安装的 bin 目录没进 PATH。解决办法是先跑：

npm config get prefix

拿到那个路径，把它的bin子目录加进系统环境变量，重开终端再试。Windows 上还有一种情况是权限问题，用管理员身份的终端装一次就好。

2.3 让两个工具共享同一份项目上下文

这一步是很多人忽略的，但直接影响输出质量。两个工具如果读的是不同的目录，或者读到的项目说明不一致，写出来的代码风格会打架。

我的做法是在项目根目录放两个文件：

• README.md：给人看的，讲项目是干什么的、怎么启动、目录结构大概什么样。
• CLAUDE.md（或者你喜欢的任何名字，在 Claude Code 里指定）：给 AI 看的，写清楚技术栈、代码规范、命名约定、不要碰的目录、常用命令。

这份给 AI 看的说明文件，内容要写得像给新同事的交接文档，不要写套话。举个例子，我会写清楚："接口层统一返回{code, message, data}三段结构"、"数据库访问一律走repository层，不要在 service 里直接写 SQL"、"legacy/目录是历史遗留，改动前必须先确认引用方"。这三句话能挡掉大量返工。

Cursor 那边也有类似机制，就是项目规则文件。你可以在项目根目录建一个规则目录，里面放几条明确约束，比如"这个项目用 TypeScript 严格模式"、"组件一律用函数式写法"。规则不要写太多，超过十几条它就开始忽略后面的了。我的经验是控制在 5 到 8 条，每条一句话，只写最容易出错的那几条。

注意：两个工具的规则文件内容要尽量一致。我踩过的坑是 Cursor 用两空格缩进、Claude Code 读到的说明里没写，结果它按四空格改了一批文件，diff 里全是格式噪音，review 的时候根本看不清真实改动。

3. Cursor 侧的实操：新功能怎么从需求变成可提交的代码

3.1 需求拆解与前 30 分钟的准备工作

很多人一有新需求就直接对着 Cursor 说"帮我写个 XX 功能"，然后拿到一坨东西，改了半天发现方向不对。我的做法是先花二三十分钟做三件事。

第一件，把需求写成一段给同事看的话。不是写给自己看的备忘，是写给一个完全不了解背景的人看的那种。你得说清楚：输入是什么、输出是什么、什么情况算异常、有没有边界条件。这段话说清楚了，提示词的质量自然就上去了。

第二件，把要碰的文件先打开。Cursor 对"当前打开的文件"感知最强，你打开的文件越多、越相关，它生成的代码越贴合项目。我会把接口定义文件、数据模型文件、一个写法类似的既有实现，三个文件并排打开，再去提需求。

第三件，找一个"抄作业的对象"。项目里如果已经有一个结构类似的模块，我会直接告诉它："参考xxx模块的组织方式，按同样的分层来写。"这一句能解决 80% 的风格不一致问题。AI 很喜欢自创结构，你不给它参照物，它就自由发挥。

3.2 提示词怎么写才不返工

我写过很多次提示词，总结下来有效的写法是分三段：先讲现状，再讲目标，最后讲约束。

现状部分写清楚："现在有一个ExportService，只有一个导出全部数据的方法，返回数组。"目标部分写清楚："我要加一个按条件导出的方法，支持时间范围和状态两个筛选参数，返回同样格式的数组，并且要给已有方法加上参数校验。"约束部分写清楚："不要改动已有方法的签名"、"新增逻辑放在同一个类里"、"不要引入新的依赖"。

这三段写下来，通常一次就能拿到七八成能用的东西。反过来，如果你只说"帮我加个筛选导出"，它会顺手帮你重构成一个策略模式，多出四个文件，你反而要多花时间删。

还有几个实用的操作习惯：

• 一次只让它干一件事。加方法、写测试、改文档分开提，别一句话塞三个任务，它做完第一个就开始飘。
• 用小范围选中来提需求。选中一个函数再提需求，比在文件末尾提需求精准得多。
• 它给的代码先看 diff 再接受。Cursor 会有变更预览，别习惯性按接受。我见过太多人一路回车下去，最后提交了一个把原有逻辑删掉的版本。

3.3 生成结果的验收清单

代码生成完，我有一套固定的验收动作，大概五分钟：

这张表是我从无数次被打回中学来的。其中最坑的是"顺手优化老代码"——AI 特别喜欢在你没要求的情况下调整周边代码，而这类改动往往没有测试覆盖，上线才发现问题。我的应对方法是每次接受改动前，先扫一眼 diff 里跟需求无关的文件，只要出现的，一律撤销。

4. Claude Code 侧的实操：老代码怎么啃才不翻车

4.1 第一步永远是画地图，不是改代码

我在老代码上翻过最大的车，就是拿到需求直接让工具改。第二次学乖了，现在固定先做"画地图"这一步。

具体怎么下指令？我会让它先做四件事：列出这个模块涉及的所有文件；找出目标函数被哪些地方调用；列出这个函数读写的数据表或者外部接口；把这个函数的业务规则用中文逐条写出来。做完这四件事，它给我的东西就是一张地图。我要的是这张地图，不是代码。

地图拿到手之后，我会做一次人工核对。这一步不能省。因为 AI 读代码是按文本理解，它对"这个分支永远不会走到"这种业务常识是没有概念的。我会重点核几件事：有没有它漏掉的调用入口（比如通过反射、配置、定时任务触发的）；有没有靠约定而不是显式代码连接的逻辑（比如同名约定、日志解析）；有没有它理解反了的状态含义。

这一步花的时间通常在半小时到一小时，但它能挡住后面几天的返工。我的经验是：在存量代码里，读代码的时间本来就该比写代码多三倍，AI 只是把这个比例还给你了。

4.2 小步改造与回归验证的节奏

地图确认之后，改代码我固定按这个节奏走：

1. 先加测试，再改逻辑。让它先针对现有行为写一批测试，跑通，确认测试是通过的。这批测试就是你后面的安全网。
2. 一次只改一个点。比如先把字段重命名，跑测试；再改计算口径，再跑测试。不要一次提"重命名 + 改算法 + 顺带优化性能"。
3. 每步都保留可回退的提交。我会在每一步之后单独提交一次，信息写清楚改了什么。哪怕后面发现方向错了，回退成本也就一分钟。
4. 让它自己复述改动。改完之后我习惯问一句"你刚才改了哪些文件、每个文件改了什么、有什么风险"。它复述的过程经常会暴露它自己都忘了的改动。

关于测试这一步，我要多说一句。让 AI 给老代码补测试，不要追求覆盖率，追求的是特征刻画：把这批代码现在实际的行为固定下来，哪怕行为看起来是 bug。老代码里很多"奇怪"的地方是业务需要，你顺手"修好"了反而出事。测试是拿来防你手滑的，不是拿来评判代码好坏的。

4.3 大仓库里的上下文控制技巧

仓库一大，最头疼的就是上下文被塞满，效果反而下降。我踩过的坑包括：让它扫全仓库，它读了三百个文件然后开始胡说；让它改一个模块，它把不相关的模块也读了一遍。

有效的几条做法：

• 在合适深度的目录启动。别总在仓库根目录启动，直接进到你要改的那个模块的目录再启动，它的搜索范围天然就小了。
• 先让它产出文件清单再动手。让它先列出"你认为需要读的文件"，你看一眼，把明显不相关的删掉，再让它按这个清单去读。
• 明确告诉它不要碰哪些目录。node_modules、构建产物、第三方源码，这些一定要在项目说明文件里写清楚排除。它有时候会去读生成的压缩文件，纯浪费。
• 让它先写结论再展开。我习惯让它先说三句话结论，我确认方向对了再让它写细节。

提示：如果你要改的逻辑散落在多个模块，不要一次全塞给它。拆成"每个模块一次会话"，最后你自己做整合。整合这件事人做得比 AI 好。

5. 双工具并行时的冲突、报错与成本控制

5.1 代码冲突与重复劳动的预防

两个工具同时改一个仓库，最容易出的问题是互相覆盖。我遇到过两次：左边的 Cursor 在改一个工具类，右边的 Claude Code 觉得这个类需要顺手重构，两边同时写盘，最后靠 git 才发现一半改动没了。

预防办法其实很简单，就是用 git 分支做物理隔离。我在同一个仓库里开两个分支，feature/xxx放新功能，legacy/xxx放改造，两边各自提交，最后自己合并。因为工作目录只有一份，所以实操上我会用 git 的 worktree 能力，把两个分支 checkout 到两个不同目录，这样两个工具各自盯着自己的目录，物理上不可能冲突。

git worktree add ../project-legacy legacy/order-refactor

这条命令执行完之后，../project-legacy就是另一份独立的工作目录，跟主目录共享同一个 git 仓库，但文件互不干扰。我一般让 Cursor 开主目录，Claude Code 的终端切到那个 worktree 目录里跑。

还有一个隐形的重复劳动：两个工具给出两套不同风格的实现，你最后要花时间统一。我的应对是在动手前先定一个"目标形态"——比如接口签名、返回结构、错误码，先写下来贴在项目说明里。这两个工具都照着这个目标形态来，返工就少很多。

5.2 常见问题速查表

下面这张表是我这大半年攒下来的，遇到问题先查这里，能省不少时间。

这几条里，我最想强调的还是"无关文件出现在 diff 里"这一条。它不是工具的问题，是使用习惯的问题。养成看 diff 的习惯，能挡掉一大半低级事故。

5.3 额度、成本与节奏管理

最后说钱和节奏，这两件事直接决定你能不能长期用下去。

额度和用量方面，我现在的分配原则是：Cursor 用在"写"，Claude Code 用在"读和查"。写代码的会话短、来回快，消耗相对可控；读老代码动辄读几十个文件，消耗大得多，所以要挑重点会话，不要把整个仓库的探索都扔给它。当你发现某次会话它开始反复读同一个文件、结论也含含糊糊，直接中断，重新开一个更聚焦的会话，这比让它硬扛省得多。

节奏方面，我的时间分配大概是这样：上午用 Claude Code 做理解和规划，因为这类活儿需要连续思考，被打断代价大；下午用 Cursor 写代码，因为写代码可以被打断，切回来还能接上。晚上我会花二十分钟把当天两边的改动过一遍，写清楚提交信息。这二十分钟是我整个流程里性价比最高的部分——它让你第二天打开电脑时，知道自己在哪。

还有个小习惯值得分享：我给两个工具各建了一个"待办清单"文件，Cursor 那边记"要写但没写的东西"，Claude Code 那边记"要理解清楚但还没搞清楚的东西"。每天收工前把这份清单更新一遍，第二天开工直接照着做，不用重新回忆。这个习惯看起来笨，但确实是我坚持最久的一个。

如果你是团队里第一个用这套工作流的人，还有一个非技术的坑要提醒你：别在评审里说"这是 AI 写的"。你就正常讲你的设计思路、你的取舍、你的验证方式。评审关注的是代码能不能维护，不是谁敲的键盘。你越把 AI 当普通的输入工具，别人越容易接受这件事。

我自己用下来最大的感受是，这套工作流真正省下的不是打字时间，是"切换成本"。以前我改老代码改到一半又想去写新功能，脑子要在两种状态之间来回切，切一次损耗十几分钟。现在两块屏幕各管一摊，我只需要决定这一小时站在哪一边。对独立开发者来说，这种"不用换脑子"的连续性，比任何单个工具都值钱。