企业官网建设流程全解析

DeepSeek 涨价那天，我第一反应是去翻上个月的 API 账单。不看还好，一看就有点肉疼——同样一套编码辅助流程，月成本比之前翻了一倍多。做 AI 编码流水线的人都知道，这玩意儿调用频率高、上下文长，价格一波动，影响是成片的。我临时决定把方案调头：DeepSeek 负责“疑难杂症”，本地模型和自建网关处理 90% 的重复编码工作，用 WorkBuddy 把整个流程串成一条自动化的“零消耗”AI 编码流水线。

这里说的“零消耗”，不是零成本，而是对付费 API 的消耗趋近于零。整套流水线的核心就两件事：用 CNB 做模型网关，把本地开源模型包装成任意工具都能调用的标准接口；用 WorkBuddy 做工作流编排，把需求拆解、代码生成、测试、修复这些环节全部自动化。经过两周实测，效果比我想象中稳得多。这篇就完整记录一下我的搭建过程、参数选择，以及踩过的坑，给同样被 API 账单困扰的朋友一个可复制的参考方案。

1. DeepSeek 涨价之后，为什么我反而开始搭“零消耗”流水线

1.1 编码场景的成本压力，远比想象中来得猛

很多人对 DeepSeek API 的印象还停留在“便宜、大碗”。确实，单看定价，它的输入输出价格在同类模型里算良心。但编码辅助场景有个特殊之处：交互轮数极多、上下文极长。一次普通的代码修改，可能就要带上项目结构、相关文件内容、历史对话记录，轻松冲到 10k token 以上。我之前用 DeepSeek 跑一个“写测试用例”的任务，平均每轮消耗 8k 到 16k token，一天下来几十轮，一个月就奔着几十万 token 去了。

涨价之后，我重新算了笔账：一个独立开发者如果每天让 AI 辅助编码 4 到 6 小时，按之前的用量，月成本可能从几十块涨到两三百块。这还不算那些跑在 CI 里的自动化任务——它们 7×24 小时挂着，一旦触发就疯狂烧 token。说实话，对于个人和小团队来说，这个成本已经不能忽略不计了。

1.2 换个思路：让付费 API 只做“兜底”

面对涨价，我一开始也想过换更便宜的 API，但我很快就意识到问题不在 DeepSeek 本身，而在于我把所有请求都一股脑丢给了付费 API。实际上，编码流水线里的任务可以分成两类：

• 机械重复类：按模板生成代码、写单元测试、格式化、修 lint 报错、补注释。这类任务不需要多强的推理能力，7B 到 14B 的本地模型完全能胜任。
• 高难度推理类：跨模块重构、复杂 bug 定位、架构设计评审。这类任务才需要调用强模型，频率低，但质量要求高。

我之前的问题就是没有做这层分流，导致大量低价值请求也在消耗付费 token。“零消耗”流水线的核心思路就是：默认走本地模型，只有在本地模型搞不定的时候，才把请求转发到 DeepSeek 这类云端 API。而这个过程，需要两个工具配合：WorkBuddy 负责流程编排，CNB 负责模型路由和接口统一。

1.3 WorkBuddy + CNB 到底解决了什么问题

先说 WorkBuddy。它是一个 AI Agent 工作台，核心优势在于把编码任务拆解成可复用的“Skill”（技能）。你可以把一类任务（比如“根据需求写后端接口”）固化成一套指令流，包括提示词、文件读写规则、测试执行步骤。以后遇到同类任务，WorkBuddy 会自动按这套流程执行，不需要每次重新描述需求。

再说 CNB。它在这里承担的是模型网关角色，可以理解成一个“总机”——所有工具（WorkBuddy、VSCode 插件、命令行脚本）只需要对接 CNB 的统一 API 地址，CNB 再把请求转发给后端的实际模型。最重要的是，你可以随时切换后端模型，不用改任何工具配置。本地 Ollama 跑起来了就切本地，需要更强推理时一键切回 DeepSeek。

这两个工具并不是替代关系，而是互补关系：WorkBuddy 管“流程怎么走”，CNB 管“请求发给谁”。组合起来，就构成了一条独立于任何单一云厂商的编码流水线。

2. 选型与安装：WorkBuddy、CNB、本地模型怎么配

2.1 为什么选 WorkBuddy，而不是其他 AI 编程工具

很多人在选工具时，会把 WorkBuddy 和 CodeBuddy 混在一起比较。两者都叫“Buddy”，定位却完全不同。CodeBuddy 更像一个结对编程助手，适合在编辑器里做小步交互；WorkBuddy 则是一个任务编排平台，适合把“从需求到代码到测试”整条链路自动化。

我的使用场景是流水线化，所以 WorkBuddy 更合适。它有几个点让我觉得特别顺手：

• Skill 机制：可以把一套成熟的编码流程固化成配置文件，团队共享时只需要同步配置文件，不用重复“人肉教学”。
• 灵活的模型接入：WorkBuddy 本身并不绑定某个模型，它支持通过 OpenAI 兼容接口或者自定义网关接入各类模型，这就给了 CNB 很大的发挥空间。
• 跨平台：Windows、macOS、Linux 都能跑，命令行和图形界面都有。我日常在 Linux 服务器上跑自动化任务，在本地 macOS 上做交互式开发，一套配置两边通用。

2.2 CNB 的角色：一个能插拔模型的“总机”

CNB 这个名字，我在这里把它理解成“Coding Native Bridge”，也就是“编码原生桥接层”。它并不负责生成代码，它只做一件事：把不同来源的模型请求，统一成一个标准接口。

打个比方，CNB 就像公司前台的总机。你打电话（发请求）不需要知道对方在哪个分机（后端是本地模型还是云端 API），只需要拨总机号码。CNB 内部维护了一套路由规则，比如：

• 默认请求转发到本地 Ollama 上的qwen2.5-coder:14b
• 如果本地模型连续拒绝生成（或检测到低置信度），自动转到 DeepSeek API
• 深夜 CI 任务高峰期，一律走本地，避免 API 限流

这个能力极大降低了流水线的维护成本。以前我如果想切换模型，得去改 WorkBuddy 的配置、改 VSCode 插件的配置、改脚本里的 base_url，现在只需要在 CNB 的配置里改一个字段，所有下游工具立刻生效。

2.3 本地模型选型：按硬件条件选，别盲目追大

既然要做到“零消耗”，本地模型就必须能扛起主力。但本地模型不是越大越好，关键看硬件。我整理了当前比较适合做编码辅助的几款开源模型，供大家参考：

我个人的建议是：如果你只有一张消费级显卡（8GB 到 12GB 显存），首选 Qwen2.5-Coder-7B；如果显存有 16GB，直接上 Qwen2.5-Coder-14B，体验会上一个台阶。我自己主力就是 14B，配了一个量化版本，显存占用控制在 10GB 左右，单次请求延迟大概 2 到 4 秒，完全能接受。

2.4 安装步骤与首轮启动

安装过程其实不复杂，我把步骤拆出来，照着做就行。以我的 Linux 服务器（Ubuntu 22.04，NVIDIA 显卡）为例：

第一步：安装 Ollama 并拉取模型

curl -fsSL https://ollama.com/install.sh | sh ollama pull qwen2.5-coder:14b ollama run qwen2.5-coder:14b

首次启动会自动加载模型，看到Send a message提示就说明成功了。如果显存不够，可以改用量化版本：

ollama pull qwen2.5-coder:14b-q4_K_M

第二步：安装 WorkBuddy

WorkBuddy 提供跨平台安装包，Linux 下用包管理器安装，macOS 下用 Homebrew 安装，Windows 下直接下安装包就行。安装完成后，先执行初始化命令：

workbuddy init

这一步会生成一个.workbuddy/目录，里面存放你的全局配置、Skill 定义和日志。初始化完成后，先不要急着配置模型，等 CNB 搭好，再让 WorkBuddy 指向 CNB 的地址。

第三步：部署 CNB

CNB 是个轻量级服务，我通过 Docker 启动：

docker run -d -p 8080:8080 \ -v /path/to/cnb/config.yaml:/app/config.yaml \ cnb:latest

启动后，访问http://localhost:8080/health能看到健康检查通过，就说明 CNB 已经准备好了。

3. 5分钟跑通首条“零消耗”编码任务

3.1 用 Ollama + CNB 把本地模型变成标准 API

CNB 最重要的作用，就是把 Ollama 的本地模型包装成 OpenAI 兼容接口。这样下游所有工具都以为自己在调gpt-4o，实际上请求全部落在本地。

CNB 的配置大概是这样的：

models: - name: local-coder provider: ollama model: qwen2.5-coder:14b base_url: http://localhost:11434 api_key: "" - name: deepseek-api provider: openai model: deepseek-chat base_url: https://api.deepseek.com/v1 api_key: ${DEEPSEEK_API_KEY} router: default: local-coder fallback: - deepseek-api

这里有两个关键点。第一，local-coder的api_key留空就行，因为 Ollama 本地服务不校验 key。第二，router.fallback配置了兜底策略——当本地模型请求失败或超时，CNB 会自动把请求转发给deepseek-api，确保流程不中断。这个兜底机制是整个系统的安全网，强烈建议配置，否则本地模型抽风时流水线就会卡死。

3.2 在 WorkBuddy 里写第一个 Skill

一切就绪后，就可以在 WorkBuddy 里创建 Skill 了。这里我以“根据需求实现一个 Python 函数”为例，带你走一遍完整流程。

在.workbuddy/skills/目录下新建一个文件夹python-function/，里面放一个SKILL.md文件：

# Python 函数实现器 ## 适用场景 用户描述一个函数需求，包括输入、输出、边界条件，Skill 自动生成可运行的 Python 函数。 ## 执行步骤 1. 解析用户需求，提取函数名、参数、返回值和边界条件。 2. 调用代码生成模型，生成初始实现，输出到指定文件。 3. 对该文件执行 `python -m py_compile` 做语法检查。 4. 若语法检查失败，收集错误信息，重新让模型修复。 5. 生成 `.md` 文档，记录函数签名和用法。 6. 默认不执行单元测试，仅当用户显式要求时运行。

然后还需要一个workflow.yaml，告诉 WorkBuddy 每个步骤具体怎么执行：

name: python-function on: user_request steps: - type: agent model: local-coder prompt: | 你是一个 Python 专家。请根据以下需求实现一个函数，要求包含完整 docstring 和类型注解。 需求：{{input}} output_file: output/function.py - type: shell command: python -m py_compile output/function.py on_fail: fix_with <agent>

现在，我在 WorkBuddy 的交互界面里输入一段需求：“实现一个函数calculate_discount(price, discount_rate)，当价格小于等于 0 或折扣率不在 0 到 1 之间时抛出异常。”

WorkBuddy 会按照 workflow 自动执行：调用本地模型生成代码 → 写入文件 → 用py_compile做语法检查 → 如果失败自动反馈给模型修复。整个过程中，所有模型推理都跑在本地，DeepSeek 的 token 消耗为零。我实测从输入需求到生成完整 Python 函数，大概 20 到 30 秒，绝大部分时间花在模型推理上。

3.3 和 VSCode 集成：日常编码直接调用

流水线跑通了，但日常写代码还是要在编辑器里顺手用。方法是让 VSCode 的 AI 插件指向 CNB 的地址。以 Continue 插件为例，在配置里填：

{ "models": [ { "title": "Local Coder (via CNB)", "provider": "openai", "model": "local-coder", "apiBase": "http://localhost:8080/v1", "apiKey": "cnb-local" } ] }

这样，在 VSCode 里选中代码、按快捷键唤起 AI 补全或解释时，请求会先到 CNB，再由 CNB 转给本地 Ollama。体验和用云端 API 几乎无差别，延迟甚至更低——因为请求只在本地网络里转一圈，不走公网。

3.4 我把流水线拆成了哪几个环节

整套流水线，我的设计大致是这样：

1. 需求输入：在 WorkBuddy 交互界面输入需求，或在 VSCode 里选中代码片段发起指令。
2. 任务拆解：WorkBuddy 根据 Skill 定义，把需求拆成多个子任务，按依赖关系排列。
3. 代码生成：调用 CNB 路由到的本地模型，生成代码文件。
4. 静态检查：执行语法编译、lint 检查，失败则自动进入修复循环。
5. 测试执行：如果任务涉及测试，WorkBuddy 会自动编写并运行单元测试。
6. 人工 review：最后一步永远是人来确认，AI 不直接推送代码到主分支。

这个流程最核心的价值不是“AI 完全替代人”，而是把 AI 能干的动作全部标准化、自动化，把人的精力留给真正的决策环节。

4. 流水线不翻车：测试、审查与踩坑实录

4.1 让 AI 写完代码自己跑测试

很多 AI 编码工具最大的问题是：生成代码一时爽，跑测试火葬场。所以我在流水线里强制加入“自测”环节。具体做法是，Skill 里定义测试生成步骤，要求模型为每个函数生成对应的pytest测试用例，然后自动执行：

pytest output/test_function.py -q --tb=short

如果测试失败，WorkBuddy 会把 pytest 的输出反馈给模型，要求它根据错误信息修复函数实现。我设置的最大修复轮数是 3 轮，超过 3 轮就停止，转人工介入，避免模型死循环。

实际跑下来，这个机制非常有效。本地 14B 模型生成函数的一次通过率在 60% 左右，加上自测修复循环后，最终通过率能到 90% 以上。剩下的 10%，基本都是需求理解出现偏差，这类问题模型再怎么修也没用，必须人来判断。

4.2 AI 代码审查怎么用才不鸡肋

审查是另一个容易翻车的环节。我早期让模型“审代码”，它给出的意见永远是不痛不痒的“建议增加类型注解”“建议提取公共方法”，没有实际价值。后来我的 prompt 做了三个调整：

• 明确审查维度：要求模型按“正确性、性能、可维护性、安全”四个维度分别输出，不许混在一起。
• 强制给具体改法：每条意见必须附带修改后的代码片段，不许只给建议。
• 设定置信度门槛：模型只有在自己很确定时才提意见，不确定的不写。

调整之后，AI 式审查的质量明显提升。比如它能在一次 Python 函数审查中发现“循环里重复计算了len(items)，当 items 很大时影响性能”，并且给出改用局部变量或迭代器的具体改法。虽然单看也不是什么精妙洞察，但放在流水线里，积少成多，能省下不少人工 review 时间。

4.3 常见问题排查速查表

在搭这套流水线的过程中，我遇到过不少问题，整理成一张表，方便你直接对照排查：

4.4 几个我踩过的坑

第一个坑是“万能模型”迷信。我一开始图省事，所有任务都让一个本地模型处理，结果复杂任务它搞不定，简单任务它又嫌慢。后来我把任务分区分级，简单补全走 7B 小模型，中等级别走 14B，只有确实搞不定的才走云端 API，整体效率立刻上来了。

第二个坑是忽略上下文窗口限制。本地模型和云端模型的上下文窗口不是一个量级。DeepSeek 能轻松吃下 64k 上下文，但 Qwen2.5-Coder-14B 默认只有 32k（实际可用可能更少）。我曾经试图把整个项目文件一次性喂给本地模型，结果它直接“忘记”了文件开头的内容。解决办法是让 WorkBuddy 在喂给模型前做文件切片，只保留与任务最相关的代码片段。

第三个坑是没有给 WorkBuddy 写足够清晰的 Skill 文档。早期我把 Skill 写得含糊，比如“生成一个接口”，模型就自由发挥，每次产出的结构都不一样。后来我把 Skill 里的输入输出、文件命名规范、异常处理要求全部写死，质量才稳定下来。Skill 文档本质上是给模型的约束，越具体，越不容易出错。

5. 这套流水线，我实际用了两周的感受

最后聊点真心话。说实话，我没有把 DeepSeek 完全踢出局。它依然作为兜底模型存在，专门处理那些本地模型搞不定的复杂重构和疑难 bug 定位。但经过这两周的流量观察，大概有八成到九成的编码请求都落在本地模型上，DeepSeek API 的消耗几乎是断崖式下降。月末看账单，基本可以忽略不计。

我最大的体会是，AI 编码流水线的核心不在于“用多强的模型”，而在于“把最合适的任务分给最合适的模型”。真正成熟的做法，不是把某一个工具用到极致，而是把工具组合成系统。WorkBuddy 管流程编排，CNB 管模型路由，本地模型管日常生成，云端 API 管疑难杂症——各司其职，才是一条真正省心又省钱的流水线。

如果你也想搭一套类似的方案，我的建议是：先从最小闭环开始，不必一上来就把所有环节自动化。先把“本地模型 + CNB + VSCode 补全”跑通，感受一下本地模型的质量和速度，再逐步加任务、加 Skill、加测试环节。等流水线慢慢顺了，你自然会知道下一步该优化哪里。