企业官网建设流程全解析

1. 从零到一：AI 编程工作台的搭建思路

1.1 我理解的“工作台”是哪几块

如果只看标题，很多人会以为“AI 编程工作台”就是装一个插件、绑一个 API Key、然后在 IDE 里问问问题。我真正用起来之后发现，这套东西应该拆成四个模块：编辑接入层、模型层、上下文层、工程化辅助层。编辑接入层解决“在哪里跟 AI 对话”，模型层解决“让哪个模型来干活”，上下文层解决“AI 有没有足够信息理解我的项目”，工程化辅助层解决“代码写完之后怎么让 AI 帮忙收尾”。

这个拆分不是学术上的分类，而是我踩坑踩出来的。一开始我只有一个聊天窗口，代码写不出来就复制报错过去问，虽然能用，但每次都像在两个软件之间反复横跳。后来我把 AI 插件直接放进 VS Code，让它可以读取选中代码、当前文件和 Git diff，整个体验完全不一样。再往后我加了本地模型、统一环境变量、项目级提示词，才算把工具、模型与基础配置真正拼成一个完整工作台。

这套工作台能解决的核心问题，说白了就是三件事：降低从“想法”到“代码”的摩擦，减少查文档和复制报错的次数，以及让 AI 生成的代码更贴近你项目的真实写法。适合的人群也很明确：已经会用 ChatGPT 写点零散代码，但觉得不系统；或者在团队里想把 AI 编程固化成一整套流程。如果你目前只是偶尔玩一玩，不看这篇也能活，但一旦开始追求效率，这套配置思路能让你少走很多弯路。

1.2 选型原则：不追新，只求稳

我见过太多朋友一上来就装五六个 AI 插件，Cline、Continue、Codeium、GitHub Copilot 全塞进 VS Code，结果每个插件都扫描一遍索引，电脑风扇起飞，明明只想补全一行代码，结果弹出一堆重复建议。AI 编程工具的入口非常多，但真正的瓶颈不是工具数量，而是你有没有一个稳定的上下文和模型调用管道。

我自己定的选型原则是：每天必须用的主工具不超过三个，编辑器、补全插件、终端辅助各一个。模型层面核心模型固定一个，备用模型一个，本地模型按需再开。这个原则看起来很保守，但实际用下来效率最高。因为频繁切换工具的隐性成本非常大，你换一次插件，快捷键要重新适应，上下文要重新建立，连注释风格都可能不一致。与其追逐每天冒出来的新框架，不如先把一套组合用到顺手。

选择工具时我还有一个判断标准：是否支持自定义模型接入。有些商业插件很好用，但闭源、模型绑定、上下文黑盒，一旦你觉得它不行，迁移成本高得吓人。我更倾向开源或者至少有标准接口的工具，比如 VS Code 生态里的 Continue，标准 OpenAI 兼容接口，本地模型能接，云端模型也能接。这样今天用 Qwen，明天换 DeepSeek，只需要改配置，不用换工具。

1.3 先决条件：硬件、账号与数据安全

搭建之前必须想清楚一个现实问题：你的机器能跑什么，你的代码能不能出内网。

如果只是用云端 API，比如 DeepSeek、通义、Kimi、智谱这类服务，电脑 8GB 内存就可以很流畅。因为真正的计算都在云端，本地只负责编辑和请求。如果你打算跑本地模型，那硬件门槛就上来了。以 Qwen2.5-Coder 7B 为例，Q4 量化版本通常需要 6GB 左右显存，如果还要长上下文，内存 16GB 会比较稳。再想跑 32B 级别的模型，那就需要 24GB 以上显存，普通开发机基本吃不消。

数据安全是更容易被忽略的问题。如果你写的是公司内部代码，尤其涉及业务逻辑和敏感数据，把代码直接发给云端大模型是非常危险的事。我见过有同事用 AI 插件时不小心把整个项目索引发给外部接口，虽然没有出大事，但事后想想冷汗都出来了。现在我的处理方式是：普通开源项目和高敏项目分开，高敏项目只用本地模型，或者只让 AI 处理脱敏后的片段。这一条应该放在所有配置之前。

2. 工具链配置：把编辑器、终端和 Agent 串起来

2.1 编辑器与插件：VS Code + Continue

编辑器我选 VS Code，不是因为它最新，而是因为生态最成熟。最关键的插件我用 Continue，它的核心能力是：允许你在编辑器里直接跟多个模型对话，可以读取选中代码、当前文件、终端输出，也支持自定义模型供应商。Continue 的优势是配置透明，你可以在 JSON 配置里看清楚它到底把请求发给了谁，不用猜。

我建议在 VS Code 插件市场安装 Continue 后，先不要急着加一堆模型，而是把最常用的两个模型配置好。一个留给日常对话和代码生成，一个留给本地补全。示例如下：

{ "models": [ { "title": "qwen2.5-coder:7b", "provider": "ollama", "model": "qwen2.5-coder:7b" }, { "title": "deepseek-chat", "provider": "openai", "model": "deepseek-chat", "apiBase": "https://api.deepseek.com/v1", "apiKey": "${DEEPSEEK_API_KEY}" } ] }

这里有两个关键点。第一，本地模型走 Ollama 的 provider，不需要 API Key；云端模型走 OpenAI 兼容协议，在 apiBase 里填供应商地址。第二，apiKey 不要直接写成明文，我习惯写成环境变量${DEEPSEEK_API_KEY}，这样即使配置目录泄露，也不会把密钥带走。配置完重启 VS Code，在 Continue 面板右上角就能切换模型。

2.2 终端与 Shell 配置：让 AI 能“看懂”报错

编辑区搞定了，终端也不能空着。AI 编程工作台里，终端是最容易被低估的一环，因为很多报错只在终端出现，而你复制给 AI 的文本往往被截断、转义或者丢失了关键前缀。

我习惯用 tmux 把我的一整套开发环境拆成多个窗口，一个窗口开编辑器，一个窗口跑程序，一个窗口放日志。这样即使 AI 补全出了问题，我也不会因为终端任务挂掉而手忙脚乱。更重要的是，我会在运行命令后面加一个“导出日志”的动作，比如把输出重定向到文件：

python train.py 2>&1 | tee train.log

这样做的目的很直接：AI 对话上下文有限，一段超长报错塞进去，模型很容易丢失重点。把日志写到文件后，我可以让 AI 只读文件尾部的错误段，先定位 Traceback，再分析是环境问题还是代码问题。对于经常跑的构建命令，我也写了几个简短的 shell 函数，比如runpy、runnode，让 AI 在帮我生成命令时更贴近我的习惯。

如果你在终端里也想用 AI，推荐尝试 Aider 这类开源终端结对编程工具。它的核心思路是基于 Git diff 工作，AI 改完代码后你可以逐个 hunk 确认，然后由 Aider 自动提交。对于大范围重构，我一直觉得终端 Agent 比编辑器内对话更好用，因为它会把整个仓库的 Git 历史当成上下文，而不是只盯着你打开的那一个文件。

2.3 版本控制与自动化：AI 辅助提交和 Code Review

很多 AI 工作台配置都漏掉了一个重要模块：提交信息生成和 Code Review。其实这个环节最适合用 AI，因为它的输入输出都很标准化。我会准备一套固定提示词，把git diff交给模型，要求它生成 Conventional Commits 格式的提交信息。例如：

根据以下 git diff 生成 commit message，使用 conventional commits 格式，必须包含 type 和 scope，控制在 50 个字符以内，用中文描述。

把这套提示词固化成一个命令后，基本不用每次手写。关键是不要让模型只看到单个文件的 diff，要让整个 commit 的上下文一起给进去。不同文件的改动可能存在逻辑关联，只给一个文件会让提交信息支离破碎。

Code Review 也一样。我每次写完一个 feature 分支，会让 AI 扮演无情的 reviewer，按照“可读性、边界条件、错误处理、测试覆盖”四个维度提意见。再把建议和 diff 放到本地模型里做一轮“脱敏审查”，确认不存在明显问题后再给人做正式评审。这样做的收益不是 AI 真能替代人，而是它能把低级问题提前拦下来，让人把精力花在架构和业务逻辑上。

3. 模型选择：云端 API、本地模型与混合策略

3.1 主要场景下的模型怎么搭配

模型选择这一块，很多人会陷入“哪个模型最强”的焦虑。我的经验是，AI 编程工作台里不存在万能模型，只有“场景匹配”的模型。要按任务类型来搭，而不是按排行榜来搭。我目前的搭配如下：

这个表格背后有一个原则：延迟敏感、低价值的任务尽量本地化，高价值、需要深度理解的任务放在云端。本地模型哪怕只有 7B，做补全也足够快，而且不产生额外费用。云端大模型适合处理一次性的复杂问题，比如重新设计一个模块，或者解释一段完全陌生的代码。

还有一个备用原则。云端 API 偶尔会抖动，一家接口超时，另一家不一定超时。所以我会在 Continue 里至少配两个云端模型，主模型响应不了时一键切换，不用改代码。这里要注意，两个模型尽量不要都吃同一路接口，避免单点故障。

3.2 本地模型部署的基础配置

本地模型我目前用 Ollama 管理，配置最简单，社区模型也齐。安装 Ollama 之后，拉模型只需要两条命令：

ollama pull qwen2.5-coder:7b ollama run qwen2.5-coder:7b

拉完模型后，Ollama 默认会在本机启动一个服务，地址是http://localhost:11434。Continue 里如果配置了provider: "ollama"，它会自动找到这个服务，不需要额外启动。如果你在别的电脑上跑 Ollama，也可以在配置里填具体的 URL，但要记得把监听地址从 localhost 改成局域网地址。

这里有几个参数需要认真调。第一是量化版本，常见的有q4_K_M、q8_0等。对代码补全来说，q4_K_M效果足够好，显存占用低；对代码生成和重构场景，q8_0会更稳，但显存需求会高不少。第二是上下文长度，默认值往往只有 4096，对代码项目远远不够。可以在运行模型时手动指定：

OLLAMA_CONTEXT_LENGTH=16384 ollama run qwen2.5-coder:7b

第三是温度参数。代码生成我习惯把温度调低到 0.2 左右，太高容易产出结构奇怪、变量命名不稳定的代码。Ollama 默认温度不低，如果你发现本地模型输出“飘”，先去查温度设置，而不是急着换更大的模型。

3.3 提示词与系统提示固化

模型再强，没有稳定的提示词也会浪费。我参考了社区里的做法，把“人设 + 输出约束 + 项目背景”三层结构写进系统提示里。基础层提示词大概是这样：

你是一位资深全栈工程师，擅长 Python、TypeScript 和 DevOps。回答时要给出可运行的具体代码，不要只讲思路。优先考虑可读性、边界条件和测试覆盖。如果信息不足，明确说不确定，不要编造 API 或函数。

在 Continue 里，可以用 slash command 或项目级AGENTS.md把它固化下来。我在仓库根部放了一个AGENTS.md，里面写清楚当前项目的目录结构、构建命令、测试命令、代码风格约定，以及禁止事项。这样每次打开项目，AI 都能从项目文件里读到背景信息，而不是靠用户手动粘贴。

上下文管理还有一个很重要的细节：不要只有“项目背景”，还要有“任务背景”。我每次让 AI 改代码前，会先告诉它“这个模块是做什么的”“为什么要有这次改动”“你只需要改哪个文件”。这些信息不一定全部进 AGENTS.md，因为它们随着任务变化。但把不变的部分和变化的部分分开管理，是 AI 编程工作台稳定运行的关键。

4. 基础配置里的关键细节：从零搭一个可用环境

4.1 版本管理：先解决 Python 和 Node 的环境隔离

很多 AI 生成的代码依赖不同的 Python 或 Node 版本，如果基础环境一团糟，AI 再聪明也白搭。我推荐用pyenv管理 Python 版本，用nvm管理 Node 版本，然后用direnv让不同项目自动加载不同的环境变量。

具体来说，每个项目根目录放一个.envrc文件：

export PYENV_VERSION=3.12.4 export NODE_VERSION=20.11.1 export DEEPSEEK_API_KEY=sk-xxxx

配合 direnv，进入项目目录时这些变量会自动加载，离开目录自动清空。这样做的好处是：AI 生成代码时，我可以在提示词里直接说“当前 Python 是 3.12，环境变量都在项目内”，它就不用再纠结版本兼容问题。对我来说，这也是一种给 AI 的“隐藏上下文”。

4.2 密钥与环境变量：避免把 API Key 写进代码

这是我踩过最痛的坑。早期为了让 Continue 能连上云端模型，我直接在配置文件里写了明文 API Key，结果项目不小心被同步到仓库，密钥就泄露了。后来我统一改成环境变量读取，凡是要写 API Key 的地方都用${变量名}替代。

如果是团队使用，我更建议用.env文件配合 direnv 管理，同时把.env加入.gitignore。配置模板可以提交到仓库，但真实密钥绝不进入 Git。这样做还有一个好处：同一套配置在不同的电脑上都能跑，只要各自环境变量不同，不需要反复改代码。

这里多说一句，很多云平台自带密钥轮换和用量监控，日常开发最好定期检查 API 调用记录，发现异常消耗时要立刻生成新 Key，并禁用旧 Key。看似基础，但这是 AI 编程工作台能长期稳定使用的底线。

4.3 最少必要配置清单

如果你现在开始搭建，我建议按下面这个清单执行，优先级从高到低。

这个清单不是越多越好。每新增一个配置，你都要支付维护成本。我见过有人把所有插件全部装齐，结果为了调一条补全路径花了一个下午。真正稳定的是那几条核心路径，而不是工具的数量。

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

5.1 补全结果“跑偏”：先查上下文和温度

AI 补全跑偏是最常见的现象。明明上一个函数写得好好的，下一个补全突然风格全变，甚至出现不存在的库。我排查这类问题时有三个顺序。

第一，上下文长度是否足够。很多模型默认只看当前文件的一部分，如果你的项目有大量跨文件类型定义，它很可能看不到关键信息。我通常会把相关的类型定义放在同一个文件里，或者在当前文件顶部提前写一段注释说明数据模型。第二，温度是不是太高。补全任务讲究确定性，温度设为 0.2 能大幅减少“发挥过度”。第三，插件是不是同时开了多个补全源。如果 VS Code 里装了不止一个 AI 插件，它们会抢占 Tab 键，导致补全结果忽高忽低，直接停用其中一个通常能解决。

如果这三步都排查过还是飘，那就考虑换一个更大的模型。补全场景下，7B 到 14B 是一个明显的台阶。不要指望小模型解决所有问题，它适合处理“短、快、简单”片段。

5.2 本地模型占显存或推理太慢：量化、分层、减上下文

本地模型最容易遇到的问题就是显存不够，启动时报CUDA out of memory。遇到这种情况，第一步是检查 Ollama 当前加载的模型是否太多，用ollama ps查看，然后通过ollama stop释放不用的模型。第二步是换成更低的量化版本，比如从q8_0降到q4_K_M，显存占用能明显下降，补全质量损失不一定感知得到。

如果显存足够但推理太慢，问题往往出在上下文长度设得太大。上下文 16384 和 4096 的推理速度差距很大，尤其是大参数模型。我的做法是分层处理：补全用 3B 或 7B 小模型，短上下文；对话和重构才用 14B 以上大模型，长上下文。不要指望一台普通开发机同时跑多个大模型，那是服务器该做的事。

另一个实用技巧是 GPU 显存不足时，可以限制 Ollama 的并发请求数，在启动时加上OLLAMA_NUM_PARALLEL=1，避免多个请求抢占显存导致频繁换出。对于长时间跑的本地服务，我还会写一个简单监控脚本，定时检查显存和推理延迟，一旦指标异常就重启模型服务。

5.3 多模型切换后上下文不连续：统一密钥注入与场景固化

多模型切换最烦人的问题是“换了一个模型，它好像忘了我们刚才在聊什么”。这不是错觉，不同模型服务之间的上下文的确不共享。我解决这个问题的方法，是把上下文写在项目文件里，而不是依赖聊天窗口的记忆。

具体来说，我会在修改代码前，要求 AI 先输出“计划”，把要改哪些文件、每一处改什么原因写出来。然后我把这份计划粘贴到项目文档里，即使切到另一个模型，也能通过读取文档恢复上下文。这看起来多了一步，但能避免二次解释带来的时间浪费。

密钥注入不统一也会影响多模型体验。如果每个模型都在不同配置面板里填 API Key，一旦 Key 轮换，你得挨个去改。统一用环境变量注入之后，切换模型只是改一个变量名，所有配置都从同一个环境变量池读取，不会出现“这个模型能用，那个模型突然 401”的情况。

5.4 AI 生成的代码在本地一运行就报错：必须建立验证闭环

AI 生成代码最大的问题是“看起来对，跑起来错”。常见原因有：用了不存在的 API、依赖版本不匹配、缺少初始化步骤。我现在的习惯是，每次 AI 生成完代码，不直接粘贴，而是让它先提供运行命令和预期输出。然后在终端里执行一遍，如果出错，把完整 Traceback 再次喂回给模型。

这个闭环看起来简单，但非常重要。很多人只做“生成”和“复制”，省略了“验证”，于是错误一轮一轮堆积，最后 debug 的时间比手写还长。把验证纳入工作台后，AI 才真正从“工具”变成“结对程序员”。我个人会把这套流程固化在 AGENTS.md 里：AI 生成代码之后，默认要附上最小可运行的测试或运行步骤，否则视为未完成。

6. 一些实操中沉淀下来的小技巧

6.1 让 AI 先复述需求再动手

这是我从实际项目里总结出的最有效的小技巧。遇到复杂任务时，不要直接说“帮我写登录模块”，而是先给 AI 一小段项目背景，然后问它“你现在对这次任务的理解是什么”。让它复述需求，能提前筛掉大量因为理解偏差导致的返工。

比如我想让它改一个支付回调函数，我不会只把函数贴给它，而是先写清楚原来的回调流程、哪一步出了问题、期望改成什么。然后问它：“请先用三句话描述你准备怎么改，说明会动到哪些文件。”等它给出计划，我再让它写代码。这个过程看似多花了 1 分钟，却能避免 AI 把整个流程重写一遍。

6.2 给 AI 设置明确的输出边界

很多人对 AI 编程的期待是“全自动”，但现实中大部分任务都是半自动更可靠。我给 AI 设置的边界是：不允许擅自修改与当前任务无关的文件，不允许安装新的依赖包，除非在计划中明确说明，不允许在不确定 API 的情况下硬写。

这些边界不是限制 AI，而是保护项目结构。AI 很容易为了完成一个需求，顺手给你重构了另一个模块，或者在项目里引入了新依赖。如果这些变更没有经过 review，代码库存债的速度会非常快。我一般会要求 AI 在输出中专门列出“本次改动的文件和风险点”，我确认之后再落盘。

6.3 每天开工前的固定检查

最后再说一个每天开工前的小习惯。我会把 AI 编程工作台的检查项压缩成一条命令：检查 Ollama 服务是否正常、Continue 配置里的模型是否能连通、磁盘有没有被模型文件塞满、日志文件是否还在增长。检查一遍大约两三分钟，但能避免整天都在跟“环境坏了”作斗争。

工具和模型永远在变，但这个检查习惯不变。我的感受是，AI 编程工作台不是一个“装完就完”的东西，它更像一个需要持续维护的开发环境。你今天多花十分钟调稳定一个配置，后面每天都能省出至少半小时，这笔账怎么算都划算。