企业官网建设流程全解析

这些年我用AI写代码，从最初的“偶尔用Copilot补全一下”，到现在基本上每天的工作流都跑在一个自己搭的AI编程工作台上。期间折腾过不少工具、换过好几轮模型，也踩过不少坑。这篇文章想把我目前这套“AI编程工作台”的整体思路、工具选型、模型配置和一些基础配置细节完整记录下来，既有给新手参考的落地步骤，也有给已经在用的朋友的一些优化建议。

先说清楚，这篇文章说的“AI编程工作台”，不是某一个软件，而是一整套组合：你用来写代码的编辑器、终端、版本管理工具、AI编程助手插件或独立应用，以及底层接入的大模型、Agent和自定义的Skill，再加上让它们协同工作的配置文件。如果你现在的问题不是“AI不够聪明”，而是“AI不知道我项目的上下文”、“AI改完代码总是把别的地方弄坏”、“每次都要反复解释需求”，那这篇文章大概率能帮上忙。

我先聊聊工作台的整体设计思路，再把每一层的工具和配置展开讲。

1. 工作台搭建前，先想清楚四件事

很多人一上来就装各种AI编程插件，结果装了一堆，写代码效率反而更低了。我自己的经验是，搭建AI编程工作台之前，先想清楚下面四件事，比直接动手装工具重要得多。

1.1 工作台不是装一堆插件，而是一条协作链路

我见过不少同行的“AI编程工作台”就是编辑器里装五六个AI插件，哪个火了装哪个。结果每个插件都有自己的对话面板，各自的上下文互不相通，代码建议互相打架，最后代码库里混入了不同模型给出的风格完全不一致的代码。

我自己现在的工作台，核心只有一条链路：编辑器作为统一入口，把需求、代码、报错信息完整地交给模型，模型给出方案，我再通过Agent去执行跨文件的修改，最后由我来审查改动。插件不在多，而在整个链路是否完整。

这条链路里有几个关键角色：

• 编辑器：承载代码阅读、补全、Diff审查。目前我主力用Cursor，后面会细说。
• 终端：跑命令、看日志、执行脚本。我用Tabby，跨平台，颜值和功能都够用。
• 模型：负责理解需求和生成代码。我会按任务难度分流，不把鸡蛋放一个篮子里。
• Agent与Skill：负责把“对话”变成“可执行的任务”，比如重构、写测试、查错误。
• 配置：.cursorrules或CLAUDE.md，把项目的技术栈、代码风格、目录结构告诉模型。

这个链路的核心思想是：让AI在正确的位置介入，每一次介入都有足够上下文，并且有办法控制输出质量。

1.2 我的选型原则：单一入口、统一上下文、可回滚

工具选型我有一条很朴素的原则：能在一个入口里完成的事，绝不用两个工具。原因很简单，频繁切换上下文对AI来说成本极高，对你来说也一样。

举个例子，早期的方案是“用VS Code写代码 + 用ChatGPT网页版复制粘贴”。听着没什么问题，但实际用起来非常难受：你复制一段代码进网页，粘贴回来报错，再复制报错信息进去，它给你改一版，你粘回去，又报新的错……来回十几次，光复制粘贴就消耗了大量精力。后来我改用编辑器内的AI工具，错误信息自动带入上下文，改动以Diff形式直接呈现，效率不是一个量级。

“统一上下文”的意思是：AI能看到的代码、报错、文件结构越完整，给出的答案越靠谱。这要求工具本身能理解你在项目里的状态，而不是孤立地看一条问题。

“可回滚”则是底线。AI改代码不像人改代码，它可能一次改动多个文件，有些改动是隐性的。所以我会把工作台接入版本管理，每次Agent执行完大批量改动，我先看Diff再提交，出问题就回滚。这个习惯救我很多次。

1.3 哪些工具适合你：按场景对号入座

我列一个简单的选型地图，方便你对照自己的情况：

2. 编辑器与终端：工作台的物理入口

这一层是工作台的地基。编辑器选不好，后面模型再强也施展不开。终端也类似，AI编程不只是写代码，还涉及跑命令、看日志、调试，终端是整个工作台和系统交互的窗口。

2.1 编辑器到底选哪家：VS Code、Cursor还是JetBrains全家桶

关于编辑器选择，我身边分成两派：一派是JetBrains的死忠，一派是VS Code系的支持者。我自己是从VS Code过渡到Cursor的，现在主力机上的静态语言项目偶尔还用JetBrains，但Cursor覆盖了大部分场景。

Cursor本质上是一个“加了AI能力的VS Code分支”，所以VS Code的大部分插件它能直接用，迁移成本很低。它最核心的优势是对上下文的处理：可以把当前文件、选中的代码、项目规则文件一起打包给模型，还支持@codebase这种方式让模型搜索整个代码库，找到相关实现再回答问题。

拿一个实际例子说，我在一个老项目里发现某个API调用总是超时，用Cursor直接把报错信息选上，按快捷键调出AI，让它“找到这个API的定义，以及所有调用点”，它能在几十秒内把调用链路梳理出来，给出超时的可能原因和修复建议。这个过程如果换成网页版ChatGPT，我需要手动打开相关文件、复制代码，效率差很多。

JetBrains家的AI Assistant也有类似能力，而且如果你是重度使用重构、调用链追踪的Java开发者，JetBrains的原生体验更顺滑。但它的订阅价格不低，插件生态也不如VS Code丰富。我的建议是：如果你已经重度使用VS Code，没必要换；如果你还没入坑，可以直接从Cursor开始。

2.2 终端工具的选择与配置：从Windows Terminal到Tabby

终端是AI编程工作台里最容易被忽略的一环。你写代码跑不起来，第一件事必然是去终端看报错；AI要帮你分析问题，也经常需要你贴终端输出。所以一个好用、能分屏、能记录会话的终端很重要。

Windows用户我首推Windows Terminal，微软官方的，免费开源，支持多标签页，和PowerShell、WSL配合都很好。macOS用户自带的Terminal其实够用，但我更推荐iTerm2，虽然现在很多AI终端也在崛起，比如Warp，但从稳定性和通用性来说，iTerm2更成熟。

我自己在多个系统之间切换，最后选了Tabby。它是一个跨平台终端，Windows、macOS、Linux都能跑，配置可以同步，内置了SFTP图形化文件管理，自带分屏和快捷键管理。最让我喜欢的是它的会话日志功能，之前排查一个线上偶发问题时，就是用Tabby的日志回放找到了上次手动操作的记录。

终端里我还会配一个轻量级的AI命令行工具，比如用aichat之类的命令行工具，直接在终端里问AI问题。写脚本时尤其方便，不用切窗口，问完把命令直接复制到终端执行。

2.3 版本管理与AI改代码的冲突处理

版本管理和AI编程的关系，很多人没意识到有多重要。AI批量改动代码时，经常会出现“它觉得这里有bug，顺手改了”的情况。如果没有版本管理兜底，你很难看出它默默改了哪些地方。

我的做法很简单但很有效：AI每次批量改动前，我先在Git里基于当前分支建一个临时分支，比如ai-refactor-temp，让Agent在临时分支上操作，每次改完后我逐个文件看Diff，确认没问题再合并回主开发分支。

如果用的是Cursor，它每次改动会以Diff形式展示，逐条审查后可以Accept或Reject。但注意，如果一次改动涉及10个文件，而Diff窗口只有几百行，我相信绝大多数人不会认真看完。所以我会要求Agent一次只改一个模块或者一个文件，改动量小，审查压力小，出错率也低。

3. 模型接入与组合策略

工具层定了之后，重头戏就是模型。市面上的模型很多，能力边界各不相同，性价比也不一样。我的原则是：不迷信某个模型，而是根据任务的类型选择最合适的模型。

3.1 当前主流模型的能力边界与选型

先说几类我实际用过的模型，说说它们的能力边界：

Claude系列（特别是 Claude 3.5 Sonnet / Claude 4 系列）：目前我个人最常用在编程场景的模型。它的优势在于对长上下文的处理、代码规范的理解和自然语言表达的准确性。写复杂函数、理解设计模式、生成完整的模块代码，质量都很高。用它改老代码特别是没有注释的代码时，它给出的注释和重构建议经常让我惊讶。

GPT系列（GPT-4o、GPT-4.1 等）：OpenAI的模型综合能力强，尤其是涉及泛化知识问答、技术方案对比、写文档这类任务时很稳。代码生成的风格偏向“标准答案”，如果需求描述得清晰，它给出的代码结构可读性很强。缺点是价格偏高，长上下文对话成本上升很快。

本地模型（CodeLlama、DeepSeek-Coder、Qwen2.5-Coder 等）：适合对数据隐私要求极高的项目，或者离线环境。但本地模型的智能度和云端模型有明显差距，尤其是跨文件理解、复杂重构方面。我一般只在网络隔离环境里用它们，日常云上开发还是用云端模型。

选模型的建议是：日常小改动用便宜的、响应快的模型，复杂任务才调用最强的模型。比如前端改一个CSS样式、后端改一个DTO字段，完全没必要动用顶级模型，用低配模型或者快速模式反而更快、更省。

3.2 我的模型接入规则：什么任务交给什么模型

为了避免模型选择困难，我自己总结了一套“任务分流”规则，分享一下：

这里有个小技巧：不要在同一个会话里既让它写业务代码又让它做方案设计。模型在长对话里容易“人格漂移”，开始回答很专业，聊了几十轮之后容易忘掉之前的约束。我会按任务类型拆对话，一个会话只干一件事。

3.3 本地模型与云端模型的配合使用

本地模型（比如通过Ollama、LM Studio跑起来的Qwen2.5-Coder）的优势是隐私和离线可用，但智能度确实有差距。我的做法是“分层使用”：

• 敏感项目：代码完全不出内网，用本地模型跑基础补全、简单问答。
• 日常项目：云端模型为主，本地模型作为备胎。
• 网络抖动时：自动切到本地模型，至少不中断工作流。

配置上，我用的是continue.dev这个开源编辑器插件，它支持同时配置多个模型源，并设置路由规则。比如我可以设置：.go文件用本地模型，.ts和.py文件用云端Claude。这样在同一个编辑器里，模型根据项目类型自动切换，体验是无感的。

如果你认真想要搭建工作台，强烈建议研究一下 Continue 或者类似的支持多模型路由的方案，它能让你在模型选择上保留“冷切换”的能力，而不是被绑定在某一家厂商。

4. Agent与Skill：从“问答式”到“自动驾驶式”

AI编程助手最早期是“问答式”：你问一句，它答一段。后来演化出“补全式”：你写一半，它续写。现在真正拉开效率差距的是“Agent式”：你给一个目标，它自己拆解任务、读取文件、修改代码、运行测试，直到达成目标。

这一步是整个工作台进阶的关键，也是很多教程里讲得最含糊的部分。

4.1 可编程智能体（Agent）到底改变了什么

Agent和普通对话的本质区别在于：它可以操作你的代码库，而不只是“建议”代码。它在执行过程中可以自己打开文件、搜索符号、修改代码、运行命令、查看结果，然后根据结果决定下一步动作。这就像你从“让AI当顾问”变成了“让AI当实习生”。

我用得最多的场景是：

• 跨文件重命名：以前用IDE的重构功能，遇到动态语言就经常失效。现在让Agent自己搜引用、逐个文件改，遇到模糊匹配的地方它会停下来问我。
• 批量补充测试：一个老模块有几百个函数，没有测试。让Agent对着代码逐个生成测试用例，它能自己创建测试文件、写数据构造逻辑、跑测试并修正失败的用例。
• 升级依赖版本：依赖升级最怕的就是API变化。Agent能自己搜索新版本的API文档、修改旧调用点、跑编译、继续修编译错误，循环往复。这个任务如果我手动做，可能需要半天，Agent半小时就搞完初稿。

这其中最关键的还是“拆解任务”的能力。Agent不是一个简单的if-else脚本，而是模型在每一步根据当前状态作出判断。所以Agent的上限取决于底层模型的推理能力，也取决于你给它设置的边界条件。

4.2 如何编写一套属于自己的Skill

Skill（技能）是Agent的“操作手册”。通俗地说，你不希望每次让Agent做某类任务时都从头解释一遍规则，Skill 把这些规则固化下来，让Agent在遇到特定任务时自动加载。

以我常用的一个“写测试”Skill为例，我在 Cursor 的.cursor/skills目录下定义了一个技能，核心内容大致如下：

# Skill: generate_unit_tests 命令: /test 描述: 为当前模块生成单元测试。 规则: 1. 先读取当前模块的源码，理解公开函数和业务逻辑。 2. 测试文件放在 tests/ 目录下，命名以 test_ 开头。 3. 必须覆盖主要成功路径和至少两个边界条件。 4. 使用 pytest 风格，断言使用 assert。 5. 不修改被测模块的任何业务代码。 6. 生成完成后，运行 pytest 并报告结果。

之后我只需要在对话中输入/test，Agent就会自动按这个流程执行，不需要我每次重复“请帮我写测试，注意放在tests目录下，用pytest风格……”这一段话了。

Skill的价值不在于花哨，而在于把团队的编码规范固化下来。比如你的项目要求所有SQL必须走预编译、不允许字符串拼接，把这些规则写进Skill，Agent生成的代码就会自动遵守。这比每次在对话里叮嘱有效一百倍。

4.3 实际案例：让Agent帮我重构一个老模块

这里分享一个实际案例。我们有个老的服务端模块，代码有几千行，里面全是if-else嵌套，逻辑混乱，一直没有测试。我花了一个下午搭了一个针对这个模块的Agent任务：

第一步，我先把需求写清楚：将模块拆分成若干独立函数，每个函数职责单一，保留对外接口签名不变，新增单元测试覆盖率不低于80%。

第二步，我把模块的技术栈、目录结构、代码风格要求写在配置里，让Agent先通读模块，输出它理解的业务流程，并列出拆分方案。

第三步，确认拆分方案没问题后，让Agent按方案逐步实施，每拆一个函数就停下来让我审查。因为改动范围可控，Diff直观，我能及时发现模型理解偏差的地方。

整个过程花了大概一个半小时（人和AI配合），如果是纯手工做，我估计得两天。现在这个模块的代码可读性提升了很多，测试也能稳定跑通，后续任何人维护都不会像以前那样如履薄冰。

这个案例想说明的是：Agent能大幅提升效率，但前提是你得清楚地定义任务边界，并且保持人工审查。如果你丢给它一个“帮我优化这段代码”这种模糊指令，它给你的结果大概率也是模糊的。

5. 基础配置的实战写法

工具选好、模型接通，但如果你不做基础配置，工作台的威力只能发挥三成。配置的核心目的，是让AI在理解你项目的技术栈和代码规范的前提下工作，而不是以“通用程序员”的角色来猜。

5.1 项目级配置：从.cursorrules到CLAUDE.md

现在主流的AI编程工具都支持项目级规则文件。Cursor 用的是.cursorrules（旧版）或最近的CLAUDE.md（新版），其他工具也有类似机制，比如 Continue 的continue.json、Copilot 的.github/copilot-instructions.md。

这类文件的作用就是告诉AI：“在这个项目中，你需要注意这些事项”。我的一个.cursorrules模板大概长这样：

# 项目背景说明 这是一个基于 Go 的微服务项目，遵循 clean architecture 分层。 # 技术栈 - 语言：Go 1.22 - 框架：gin - 数据库：PostgreSQL + sqlc - 消息队列：RabbitMQ - 缓存：Redis # 代码风格约束 - 所有错误必须显式处理，禁止使用 _ 忽略错误。 - 日志使用项目统一的 slog 封装，禁止直接使用 fmt.Println 输出日志。 - 对外API接口必须包含请求参数校验。 - 数据库访问层只允许通过 repository 包访问，业务层禁止直接拼 SQL。 # 文件结构 - handler 层：处理HTTP请求和参数绑定 - service 层：业务逻辑 - repository 层：数据访问 - 新增功能按此分层，每层职责边界要清晰。

配置这个文件之后，AI生成的代码明显更符合项目规范。之前它经常无视项目已有的分层结构，直接把数据库操作写在handler里，配置后基本不再犯。

你也可以根据项目定制，这个文件本身很重要，建议至少花半小时认真写。

5.2 忽略文件与权限控制

AI编程工具在读取项目上下文时，如果没有任何忽略机制，它可能会把node_modules、dist、.git、敏感配置文件等大量无关内容读进来，既浪费上下文窗口，又可能引入安全隐患。

以 Cursor 为例，它支持.aiexclude和.gitignore配合使用。我会在项目根目录的.cursorignore文件里配置：

node_modules/ dist/ build/ .git/ *.secret .env *.key *.pem vendor/

这样AI搜索代码库时，就不会把这些目录纳入范围，既加快了响应速度，也避免了局部敏感信息被送进云端模型。这点在做外包项目、政务项目时尤其重要，客户对代码出网有严格红线，忽略文件是第一道防线。

如果你的项目运行在企业内网，还应该配置网络代理层面的大模型访问策略，但这已经超出“基础配置”的范畴了，这里不展开。

5.3 一套可以复制的配置模板

最后给一套我个人比较满意的、可以直接复制的配置模板。这套配置适用于一个典型的Web后端项目（Go或Java都可以，重点是结构配置思路）。

首选编辑器配置。以 Cursor 为例，用户级配置settings.json里我推荐几个高频项：

{ "cursor.chat.defaultModel": "claude-3.5-sonnet", "cursor.generation.optimizeFor": "speed", "editor.inlineSuggest.enabled": true, "cursor.terminal.useInTerminal": true, "cursor.generation.codeStyle": "project", "files.autoSave": "afterDelay", "editor.formatOnSave": true, "git.enableSmartCommit": true }

这几个配置的意义分别是：

• defaultModel：设置默认的聊天模型，减少手动切换。
• generation.optimizeFor：优先速度还是质量，日常写代码我选速度，批量重构时再改质量。
• terminal.useInTerminal：允许AI读取终端输出，这个非常关键，能让AI看到报错信息并给出更精准的回答。
• codeStyle：按项目规则生成代码，而不是通用风格。

再来一份项目根目录的CLAUDE.md核心模板，把项目结构和约定写清楚：

# 项目指南 ## 项目简介 这是一个用户权限管理微服务，提供用户登录、角色管理、权限分配等接口。 ## 技术栈 - 框架：gin - ORM：sqlc - 鉴权：JWT + casbin - 数据库：PostgreSQL ## 目录结构 - cmd/: 程序入口 - internal/handler/: HTTP层 - internal/service/: 服务层 - internal/repository/: 数据访问层 - internal/model/: 数据模型 - migrations/: 数据库迁移文件 ## 约束 - 新增接口必须写 OpenAPI 注释 - service 层不能直接操作数据库 - 错误统一通过 apierror.New 构造 - 单元测试必须使用 testify 框架

配置文件的奥义是：用最少的话把项目最关键的信息和约束传达到位。AI不需要你把每一行代码都解释清楚，它需要的是“边界”。

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

搭建和使用AI编程工作台的过程中，我几乎每天都会遇到这样那样的问题。整理一下高频问题和排查思路，希望能帮你少走弯路。

6.1 高频问题速查表

6.2 我的避坑心得

排第一位的心得是：别让AI直接改生产分支。AI毕竟是概率模型，你不能排除它哪次突然抽风，给出一个逻辑“看似合理”但实际有严重问题的改动。我见过有同事让AI直接修线上bug，AI还信誓旦旦说已经修好了，结果是改了个寂寞。所以，AI的所有改动都要先过本地分支，过审查，过测试。

第二，上下文宁可多给也不要少给。很多人问“为什么AI帮我找bug找不到”，我看了下他的提问方式：“这段代码报错，帮我看看”。可报错信息呢？相关函数的完整代码呢？依赖的版本呢？啥都没有。AI不是神仙，你给它一个孤零零的报错片段，它只能靠猜。正确做法是：把报错堆栈完整贴出来、选中相关代码块、说明你期望的行为、贴上实际的输出。上下文给足了，AI的成功率会翻倍。

第三，小心“过度维护”。AI有时候会主动“优化”你没让它改的代码。比如你让它修一个bug，它修完之后顺手重构了相邻的函数、改了变量名、加了一些“更优雅”的写法。这种行为非常危险，尤其是把别人维护了很久的逻辑随手换成自己觉得更好的版本。所以我现在的指令里通常会加一句“只修改解决该问题必须改动的代码，不要额外重构”作为兜底限制。

第四，做一次“AI代码审查”。我现在写完一版代码，会刻意让AI以“代码审查者”的身份重新看一遍，专门找潜在的边界条件漏洞、并发问题、资源泄漏。这个用法其实很香，相当于免费请了一个思维严谨的结对程序员。

写在最后：工作台的价值，取决于你的使用姿势

工具、模型和配置，说到底都只是“加速器”。真正决定效率的还是使用姿势：你有没有把需求想清楚？有没有给足上下文？有没有在关键节点做人工审查？有没有把重复的工作沉淀成规则和Skill？

我个人目前这套工作台的形态，大概率半年后又会有很大变化，因为AI编程工具链迭代太快了。但底层的方法论——以编辑器为唯一入口、按任务匹配模型、用配置文件沉淀项目上下文、以Agent规模化执行、用Git兜底审查——是相对稳定的。

如果你刚开始搭自己的AI编程工作台，不用追求一步到位。先把编辑器、模型、基础配置这三件事跑通，每天优化一点点，用着用着你就知道自己的项目到底需要什么了。等哪天你发现AI不再只是“给你建议”，而是真的能帮你把活干了，你就算真正入了门。