企业官网建设流程全解析

AI编程这两年迭代太快了，工具链、模型、配置方法几乎是周更，我自己的开发机和工作流程也跟着调了好几轮。今天不聊虚的，就把我目前这套“AI 编程工作台”从头到尾拆一遍，从工具选型、模型取舍到底层配置，把每一步的思考逻辑和踩过的坑都写出来，给正在折腾或者准备入坑的朋友一个直接能抄作业的参考。

先说我这个工作台到底解决什么问题。日常开发里大量时间其实花在“找到正确的代码”、“写胶水逻辑”、“查文档试错”、“为重复性样板代码按回车”这些事情上。AI编程工具帮我压缩的就是这部分时间，但前提是环境要搭得顺手。那这个问题拆开看，无非三大块：用哪些工具承载 AI 编程流程、接哪些模型来干不同类型的话、以及最容易被忽略的基础配置怎么梳理。这篇文章就是围绕这三块展开，适合已经用过一两款 AI 编程工具但觉得工作机制不顺、以及刚开始想系统搭建 AI 编程环境的新手阅读。

1. 工作台整体思路：先拆需求再选型

我见过不少朋友一上来就装一堆插件、接一堆模型，结果整个 IDE 卡成幻灯片，上下文互相打架，最后得出的结论是“AI 编程都是噱头”。这类问题基本不是 AI 本身不行，而是工作台没有结构。

1.1 把自己的需求分层拆解

我习惯把 AI 编程工作台分成三层来思考。最底层是模型层，负责真正理解需求、生成代码，像是 ChatGPT、Claude 这类背后的大语言模型，或者本地跑的量化小模型；中间是工具层，负责把模型和编辑器、终端、代码仓库串联起来，像 Cursor、Continue 插件、Copilot，还有 Aider、Claude Code 这样的命令行工具；最上层是配置层，包括 API Key 管理、模型路由、提示词模板、代码库索引这些。三层各自独立演进，又互相配合。

这么拆有两个好处。第一，模型迭代太快了，今天觉得好用的模型，下周可能就被另一个超越，只要工具层把模型接口标准化，换模型就只是改一行配置的事，而不是推倒整个环境重来。第二，不同任务对模型的要求差异很大，补全用轻量模型就够，重构和写测试则需要更强推理的模型，分层之后可以按任务路由，成本和效果都能兼顾。

1.2 工具选型的三个原则

这半年我反复试错下来，总结出三个选型原则：可替换、可组合、可观测。

可替换意味着所有关键组件尽量用开放标准去接入，避免被某个厂商的闭源生态锁死，比如我不用 IDE 内置的 AI 功能，而是用支持多模型的插件，这样哪天出了更强的模型，接入成本很低。可组合强调工具之间数据能打通，编辑器和终端里的 AI 助手共用同一套代码上下文，而不是各记各的。可观测就更实际了，每次 AI 调用花了多少 token、用了哪个模型、耗时多久，都要有日志可查，不然月底账单来了才发现某次批量操作烧掉一大笔费用。

这三个原则直接决定了我后面所有的选型决策。接下来我按工具、模型、配置三大块具体讲讲自己是怎么落地的。

2. 工具链拆解：编辑器、终端与工作流

工具链这块水很深，不同岗位、不同开发语言适合的工具组合其实不太一样，但底层逻辑是一致的：AI 必须出现在你写代码的每个高频操作节点上，而不是要你用额外的动作去“召唤”它。

2.1 编辑器内嵌 AI：主力 IDE 的选择

我在主力 IDE 上折腾过 Visual Studio Code、JetBrains 系和 Cursor。最终方案是 VS Code 加 Continue 插件作为主力，JetBrains 系留作前端和部分 Java 场景，Cursor 用来做快速原型验证。

Continue 插件我觉得是个被很多国产教程低估的宝藏。它支持自定义模型接入，也支持在代码库内做问答，最关键的是它的 prompt 和模型选择完全透明，能在同一个对话里同时路由到不同的后端模型。举个例子，我在 Continue 的配置里同时配了 OpenAI 兼容接口和本地 Ollama 服务，日常补全走本地小模型，涉及跨文件重构的问题走云端强推理模型，切换只靠一个下拉框。

而很多人刚开始时容易犯的错是同时装了一堆 AI 插件，Copilot、Continue、通义灵码、CodeGeeX 全开着，彼此之间还会抢 Tab 补全和快捷键。我现在只保留一个 Tab 补全来源，其余全部禁用，这样才不会出现按下 Tab 键都不知道是哪家 AI 在响应的情况。

2.2 终端里的 AI：从 Aider 到 Claude Code

编辑器内的 AI 适合逐行补全和单文件修改，但一旦任务变成“跨 20 个文件做一次大规模重构”，或者“把这个 Python 脚本迁移成 Go 服务”，我建议放到终端里的 AI 编程工具来做。

这类工具的代表是 Aider 和 Claude Code，它们本质上是让你通过自然语言下达任务，然后 AI 直接修改代码库文件、运行测试并迭代修复。相比 IDE 插件，终端 AI 工具有个巨大优势：它能看到完整的 git diff，并且每个改动都有独立的提交记录，出了问题直接回滚，对版本控制非常友好。

说说我自己的工作流。接到一个任务后，先在终端里把需求描述给 AI，例如“把这个模块的错误处理从返回码改成异常捕获，并更新所有调用方”，AI 会列出改动清单，我确认后才开始批量修改。整个过程并不是放手不管，而是像带一个执行能力很强但需要明确边界的新人，把大任务拆成小步骤逐步验证。

2.3 用 git worktree 隔离 AI 实验

AI 生成的代码有一个特点：看着能把功能跑通，但很可能带了不该有的依赖或者影响现有逻辑。直接在主线分支上让 AI 反复试错，很容易把仓库搞脏。我用了一个非常简单但好用的技巧：git worktree。

具体操作是在项目目录旁边单独建一个 AI 实验工作区，签出同一个仓库的独立分支。所有 AI 修改先落在这个 worktree 里，我在里面跑测试、做代码审查，确认没有问题了才合并回主分支。这个思路本质上是用 git 天然的隔离能力给 AI 生成代码一个“缓冲区”，成本几乎为零，但是安全边际非常高。

工作流大概是这样的：

# 在项目仓库旁边建一个 AI 实验区，基于当前主线创建新分支 git worktree add ../project-ai-agent -b feat/ai-candidate # 在 project-ai-agent 目录里启动终端 AI 工具 cd ../project-ai-agent claude-code # AI 完成改动后，审查 diff git diff main...feat/ai-candidate # 确认没问题回到主仓库合并 cd ../project git merge feat/ai-candidate

这套玩法在多人协作的团队里尤其好用，AI 生成的代码不会污染别人的工作区，自己审查起来也很清晰。我强烈建议每个用 AI 编程工具的人把这个流程建立起来。

2.4 工具链组合的推荐搭配

用表格总结一下我当前的主力工具组合和适用场景，方便你对照自己的情况来选：

我特别想强调一点，工具不是越多越好，每个工具最好只承担一个核心角色。把所有功能往一个工具里塞，表面上省了切换成本，实际上是牺牲了灵活性和稳定性。

3. 模型选型：开源与商业模型怎么搭配

工具定好了，接下来就是最核心的一层——模型。很多人问“哪家模型写代码最强”，这个问题其实没有标准答案，因为“写代码”本身是个宽泛的任务，补全、解释、重构、测试、修 bug 对模型能力的要求各不相同。

3.1 模型竞技场：用真实任务评估，别只看跑分

在选模型这件事上，我建议大家不要只看基准测试榜单，要自己搭一个“模型竞技场”，用真实项目片段去测。我的方法很简单：从自己的代码库里抽出 10 个典型任务，包括一个跨文件重构、一个写单元测试、一个解释遗留代码、一个性能优化、一个正则编写、一个代码审查，然后用同一套提示词分别发给候选模型，对比输出质量和风格。

实测下来，商业模型和开源模型的差距在普通任务上已经很小了，差距主要体现在长上下文的连贯性和复杂架构设计的把控上。但开源的本地模型有一个无可替代的优势：代码不会离开你的机器。对于一些还没上市的项目、金融或医疗相关的代码，把源码发给第三方 API 本身就是合规风险，这时候本地模型即使效果稍差，也仍然是最稳妥的选择。

3.2 开源模型与本地部署的取舍

本地部署这块，我一直在用 Ollama 跑模型。它支持的模型很多，像 CodeLlama、Qwen2.5-Coder、DeepSeek-Coder 都有对应的量化版本。笔记本电脑上跑 7B 到 14B 模型基本流畅，如果机器有 64G 内存或者一块 24G 显存的显卡，可以上到 32B 级别的量化模型。

这里需要提醒一个新概念：transformer 的参数规模不等于效果，但上下文长度是实打实影响使用体验的。模型架构决定了它能记住多长的上下文，如果你的任务涉及多文件代码库，上下文窗口短了，AI 就会“顾头不顾尾”。选本地模型时要特别关注上下文长度，至少要能容纳整个目标文件或者一组相关函数。

我自己在本地跑的是 Qwen2.5-Coder 32B 的量化版，配合 64G 内存，复杂任务它也能给出不错的思路。不过实话实说，在极其复杂的架构设计上，本地 32B 模型和商业旗舰模型还是有肉眼可见的差距，所以我的分工是：本地模型负责快而廉价的代码补全和简单解释，商业模型负责真正烧脑的重构和设计任务。

3.3 商业模型：怎么选择与切换策略

商业模型这边，我目前主要用 Claude 系列和 GPT 系列。Claude 在长上下文的保持力和代码生成的“自然度”上更舒服，GPT 系列在工具调用和结构化输出上更稳定。至于一些国产商业模型，看具体场景，部分场景性价比很高，尤其中文注释和文档生成，但遇到复杂逻辑推演时表现有时不稳定。我的建议是不要对任何一家产生忠诚度，始终用“任务路由”的思路去选择最优模型。

具体切换我是靠统一的 API 网关层实现的，这一步我会在下一节详细讲。这里先给个结论：把模型选择从业务代码中剥离出去，让工具层始终面对同一个接口，你在背后怎么切换模型都是自由的。

3.4 从“人写提示词”到“工程化提示词”

模型选好之后，你还需要一套稳定的提示词模板。很多人以为提示词就是“帮我写个排序算法”，但在 AI 编程工具里，提示词更像是在给一个经验不错但容易自作聪明的新同事派活，需要明确四件事：背景信息、目标输出、约束条件、验收标准。

我常用的一个通用模板是：

背景：这是一个用 Python FastAPI 写的微服务，主要处理用户订单状态流转。 任务：帮我新增一个接口，支持按订单ID和状态列表进行过滤查询。 约束：遵循项目现有的分层结构，不要引入新的第三方依赖，使用项目已有的日志和异常处理方式。 验收：提供接口代码、对应的单元测试，并更新 OpenAPI 文档。

把提示词当成代码来维护，而不是随手打的自然语言，效果差距非常明显。我会把高频使用的提示词模板保存为 Markdown 文件，放在项目的.ai/prompts/目录下，这样团队里所有人都能复用，也方便版本管理。

4. 基础配置实战：把环境打磨顺手的关键细节

工具和模型都定了，但真正决定工作台好不好用的，是那些看起来不起眼的配置。配置做得好，AI 工具就像是长在项目里的；配置做得糙，每次用都像在跟工具搏斗。

4.1 用统一网关管理 API 与模型路由

我强烈建议不要在每个工具里直接填各自模型的 API Key，而是搭建一个轻量的“模型网关”服务。这个网关本质是一个符合 OpenAI 接口规范的反向代理，统一管理 API Key、模型路由、重试与降级策略。

这样做的好处太明显了。首先安全，API Key 只存在服务器环境变量里，前端工具永远不会直接接触到密钥；其次灵活，当任务需要从模型 A 切换到模型 B 时，只需要在网关配置里改一行规则，所有下游工具自动感知；最后省钱，可以在网关层做预算限制和调用统计，清楚知道每个月每个模型烧了多少钱。

一个简化的网关配置示例（使用 Node.js + Express）：

import express from "express"; import { createProxyMiddleware } from "http-proxy-middleware"; const app = express(); const modelRoutes = { "fast": "http://localhost:11434/v1", // Ollama 本地 "powerful": "https://api.example.com/v1", // 云端旗舰 "cheap": "https://api.example2.com/v1" // 云端经济款 }; // 根据请求体里的 model 前缀动态转发 app.use("/v1", (req, res, next) => { const model = req.body?.model || "fast"; if (model.startsWith("local-")) { req.url = "/v1/chat/completions"; req.headers["x-api-key"] = process.env.LOCAL_KEY; return createProxyMiddleware({ target: modelRoutes.fast, changeOrigin: true })(req, res, next); } // 其他模型类似处理 }); app.listen(8080);

核心思想是：工具永远只配一个 base URL 指向网关，具体用哪个模型由网关根据请求内容自动决定。比如你在 Continue 插件里设置模型为local-qwen，网关识别前缀local-就转发到本地 Ollama；设置为cloud-claude则转发到云端的 Claude 接口。

4.2 令牌上下文管理：避免 AI 失忆

AI 对话的天然限制是上下文窗口，不管模型号称多大，代码文件、依赖说明、历史对话都会迅速把窗口塞满。一旦超过窗口，模型要么直接报错，要么“忘记”最早的内容，导致前后逻辑不一致。

我的经验是在配置里开启自动摘要功能。以 Continue 和 Claude Code 为例，工具支持在上下文快满时先把之前的对话压缩成摘要，但这需要你在提示词里明确推动它，不能让 AI 自己决定。我通常在任务描述最前面加一句：“请先记录当前需求的核心目标和已完成步骤，在后续对话中始终优先回顾这条摘要。”

另外，手动控制提交给 AI 的代码范围也很重要。不要一股脑把整个项目目录都塞进上下文，多数工具支持.aiignore或.continueignore文件，把node_modules、dist、.git、build这些目录排除掉，这样既能提高响应速度，也能减少模型的干扰信息。

4.3 自定义模型接入的完整步骤

说到“自定义模型”，很多人被这个词吓到了，觉得是不是得懂模型训练。其实在大多数 AI 编程工具里，自定义模型指的是“接入一个自己配置的在线或本地模型服务”，完全不需要训练。

以 Continue 插件为例，接入本地 Ollama 模型的基本流程是这样的：

1. 安装并启动 Ollama，拉取一个代码模型，比如ollama pull qwen2.5-coder:7b。
2. 在 VS Code 的 Continue 插件设置中添加一个新 provider，类型选择Ollama，地址填http://localhost:11434，模型名填qwen2.5-coder:7b。
3. 在 Continue 的模型下拉框里选中这个模型，测试一下补全和对话是否正常。
4. 如果要接入一个兼容 OpenAI 规范的第三方 API，同样添加 provider，类型选择OpenAI，把 base URL 换成网关地址，填入对应的模型名即可。

整个过程最多十分钟，但要注意一个很容易踩的坑：本地模型的上下文长度和工具默认配置不一致时，容易出现截断或报错。解决办法是在模型配置里显式设定上下文长度，比如 Ollama 的num_ctx参数，或者在 Continue 的模型配置里把max_length调整为模型实际支持的窗口大小。

4.4 环境变量与密钥管理

最后说一个虽然基础但极其重要的部分：密钥管理。很多人图省事，直接把 API Key 硬编码在配置文件里，甚至一键上传到 GitHub 公共仓库，这等于把自家钥匙挂在门口。这类泄漏事故在网络上一搜一大把，造成的经济损失和信誉损失都相当大。

我个人的规范是这样：所有密钥都放在项目根目录的.env文件里，.env文件不提交到 git，在.gitignore中显式排除。工具运行时通过dotenv库或 shell 环境变量读取。更严格一点，CI/CD 流水线的密钥应该使用云服务商提供的密钥管理服务，比如 AWS Secrets Manager 等，这些内容这里不展开，但基本逻辑是：代码库里的任何文件都不得出现明文密钥。

顺带一个不成熟的建议：团队协作时可以在项目里放一个.env.example，把变量名和注释写好，但不填真实值，这样同事拉代码后复制一份.env.example为.env再填入自己的密钥即可，兼顾安全与协作效率。

4.5 让代理人更懂你的项目：代码库索引与规则文件

配置的进阶操作，是给 AI 工具一份“项目地图”。目前多数主流 AI 编程工具都支持通过配置文件告诉它项目的结构、技术栈和编码规范。比如在项目根目录放一个AGENTS.md或CLAUDE.md，内容可以写清楚：

• 项目用的是什么语言和框架，构建和测试命令是什么；
• 代码目录分别存放什么模块，新增代码应该放在哪里；
• 项目的命名规范、错误处理规范、日志规范；
• 哪些目录是自动生成的，AI 不应修改。

这类规则文件比你在每次对话里反复说明要高效得多。AI 工具会自动读取并把它作为系统提示词的一部分，让项目上下文从“每次重新解释”变成“一次配置，持续生效”。这也是很多人觉得自己在用 AI 和别人的差距所在：别人家的 AI 像项目组老人，自己家的 AI 像每句话都要解释一遍的实习生。

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

配置这套工作台的过程中，我遇到过不少问题，有些是工具文档里不会写的，有些是特定组合才会出现的。我把最有代表性的几个整理出来，按症状、原因、解决方案三个维度讲。

5.1 对话到一半模型突然“失忆”

这不是玄学，基本是上下文窗口撞顶了。工具只能把最近的对话和文件发给模型，最早的指令被丢弃了。

排查方法：看这次调用的输入 token 数量，如果接近模型上限，那就是被截断了。解决方案有两个方向，一是用摘要功能压缩历史，二是把关键约束条件从历史对话中移出来，放到系统提示词或规则文件里，保证它们永远在上下文中占用稳定的位置。我发现后者比前者更可靠，所以现在重要的项目约束都会写在AGENTS.md里。

5.2 补全结果不稳定，一个风格一个样

原本 AI 补全的风格还可以，结果某一天突然变了个样子，代码缩进、引号、命名习惯全变了。这种情况多半是切换了模型，不同模型在风格跟随上的能力差异很大。

解决办法是显式指定风格要求。在配置里加入一段风格说明，例如“字符串使用单引号，变量命名使用 camelCase，函数前必须有 docstring”，如果模型支持 stylus 或类似机制，也可以一并打开。不要指望模型自己从代码库里学，除非它明确表明自己有仓库级的学习能力，否则请把风格要求写进规则文件。

5.3 本地模型运行占满内存，机器卡死

本地跑大模型对硬件的要求远超大家的直觉。一个 7B 的模型，FP16 精度光权重就要 14G 内存，加上 KV cache 和运行时开销，16G 内存的机器跑起来已经很吃力了，32B 的模型没有 64G 内存基本别想流畅。

解决思路是合理使用量化模型。量化可以理解为把模型参数从高精度压缩到低精度，换取更小的内存占用和更快的推理速度，代价是效果的轻微下降。实测 4-bit 量化在代码生成任务上损失很小，但内存占用直接少了一半多。另一个思路是按需加载模型，不用的时候把模型从内存卸载，而不是常驻。Ollama 默认会保持模型加载一段时间，可以通过环境变量OLLAMA_KEEP_ALIVE调整驻留时间。

5.4 多个任务同时跑，API 被限流

当你在终端 AI 工具里批量跑任务时，云端 API 很容易触发限流。限流的表象是突然报 429 错误。我最初以为是代码问题，查了很久才发现是请求太密集。

解决方案是给网关加上请求排队和指数退避重试。所谓指数退避，就是第一次失败后等 1 秒再试，再失败等 2 秒，4 秒、8 秒，逐步拉大重试间隔，而不是疯狂重试把接口打爆。另外，充分利用模型的流式输出，让它逐块返回内容，而不是等整段生成完再一次性接收，也能显著降低超时概率。

5.5 问题排查速查表

6. 一些提高日常使用效率的进阶经验

配置做顺了之后，AI 编程工具才真正进入“生产力”阶段。这个阶段拼的不是某个单独技巧，而是把 AI 嵌入到工作节奏里的能力。

6.1 用 AI 写测试，再让测试反过来约束 AI

我现在养成一个习惯：写业务代码之前，先让 AI 根据需求写一轮单元测试，然后让 AI 实现功能去让测试变绿。这个过程把“测试驱动开发”和“AI 驱动开发”结合起来了，效果出乎意料地好。

原因是测试本身就是需求的可执行描述，它比自然语言提示词精确很多。AI 写实现代码时，测试文件就等于一份带校验逻辑的规格说明书，模型生成时就有了明确的验收标准，而不是靠猜。这比修完再回头看“哎呀这不对”要便宜得多。

6.2 建立个人“AI 提示词片段库”

我在实际开发中积累了一堆小而高频的提示词片段，比如“评估这段代码的性能瓶颈并给出优化建议”、“为这个函数补充边界条件测试”、“把这个代码改成异步并发实现，并说明改动理由”。这些片段不同于规则文件，它们是即时发挥作用的具体指令。

我会把它们保存为一个轻量的 Markdown 和脚本片段文件，需要用的时候直接复制，或者绑定成编辑器里的快捷命令。这个库越攒越多，实际就是一份属于自己工作习惯的小型知识库，任何 AI 工具换进来，都能靠这套片段快速对齐到自己的预期。

6.3 通过日志和会话记录做复盘

最后我想说，AI 编程工作台也需要“复盘”。很多工具会自动保存历史会话记录，我会定期翻一翻，不是看 AI 写得对不对，而是观察自己提问的方式有没有问题。比如某个任务反复让 AI 修改了很多次才通过，那通常是因为最初的上下文没给够，下一次我会把背景描述得更充分，而不是抱怨模型不够聪明。

查看每次会话的 token 消耗和耗时，也能帮自己总结出哪些任务适合交给本地模型省成本，哪些任务完全可以交给云端模型减少沟通时间，时间长了，整个工作流会越来越顺手。

这些经验是我这两年实践下来最有价值的部分。工具和模型会不断更替，但分层架构的思路、任务路由的取舍、把配置当成代码来管理的习惯，这些底层方法不会过时。希望这篇文章能让你少走一些弯路，尽快搭建出一套真正属于你自己的 AI 编程工作台。