企业官网建设流程全解析

家里那台天猫精灵吃灰多久了？我猜很多人买回来用了一个月，就只剩定闹钟和问天气这两个功能。我坦白说，我家这台也一度走到这个结局，直到我开始认真折腾本地大模型部署——突然意识到，这音箱硬件其实没毛病，缺的只是一颗属于自己的大脑。

这一篇是AI人工智能系列第五篇，也是“东方仙盟”项目的开篇之作。项目要解决的事很朴素：把天猫精灵的云端固定技能，替换成我自己部署的本地大模型服务，让音箱背后的大模型换成DeepSeek（也可以换成Qwen），跑通“天猫精灵 -> 云端技能平台 -> 自建后端服务 -> 本地大模型 -> 语音回复”这条完整链路。这一期叫“练气期”，意思是最基础的入门闭环能转起来，先打通任督二脉，不搞花活。

如果你会一点HTTP接口开发，能操作Linux命令行，手头有一台带显卡（哪怕8G显存）的机器，这篇可以直接照着抄。整个项目的工程代码量并不大，核心就是一个回调服务加一个模型调度，难的只是把每个环节的坑都填平。

1. 练气期目标拆解：一条语音背后要过几道门

1.1 官方技能与自建服务之间差的不是硬件

天猫精灵本身是一套完整的语音交互硬件：麦克风阵列做拾音，本地做唤醒，云端做ASR识别和NLU理解，然后是技能分发。普通用户接触到的“问天气、放歌、控制灯泡”，本质都是平台上预先定义好的技能服务。这些技能稳定，但对折腾型玩家来说太封闭了——你不能给它自定义system prompt，不能把私有知识库塞进去，不能让它调用你自己写的工具。

那绕开官方技能，直接用天猫精灵做一个“大模型语音入口”行不行？行，而且这是官方支持的合规路径。天猫精灵开放平台提供了自定义技能能力：平台负责把用户语音转成文本，再通过NLU解析出意图，然后把结构化请求POST到你自己的HTTP服务上。后续逻辑完全由你掌控——你是接云端大模型、本地大模型还是自己写的规则引擎，平台都不关心。差的只是：你要在自己服务器上把模型、服务、证书这些都支棱起来。

1.2 一条语音从嘴边到耳朵要过七道门

我花了一个下午把整条链路画出来，实测下来每一环都有明确分工：

1. 唤醒和拾音：你说“天猫精灵”，本地唤醒引擎响应，录制后续语音。
2. ASR语音识别：音频上传到天猫精灵云端，转成文本。
3. NLU意图解析：云端平台判断你在唤起哪个技能，解析槽位。
4. 回调分发：平台把结构化请求POST到我在服务器上配置的HTTPS地址。
5. 自建服务逻辑：解析请求、组装上下文、调用本地大模型。
6. 大模型生成：Ollama里跑的DeepSeek根据system prompt和对话历史生成回答。
7. NLG与TTS：自建服务把回答组装成技能响应格式，平台转成语音，音箱播报。

前三步是天猫精灵云端的活，我们管不了；但从第四步开始，就全是我们自己地盘。练气期项目的地界，就是从第四步到第七步这半程。

可能有人会问：为什么还要过云端，不能全部本地吗？难度不在自己这端，而在天猫精灵的固件和App本身是跟云端绑定的，硬件不开放自定义唤醒词和裸输入流。走官方技能通道是投入产出比最高的合规路径，也没有侵犯任何条款的问题。

1.3 为什么这一期叫练气期

修仙小说里练气期就是“能感知灵气、能运行功法，但谈不上术法神通”。放到这个项目里，练气期就是：先把主链路跑通，语音进来，文字出去，模型正常回复。不做知识库检索，不做复杂多轮记忆，不做多房间联动。目的是把每个环节都验证到位，给后面的筑基期打地基。

我也把后续阶段提前定了名：筑基期加RAG知识库和会话持久化；金丹期把Agent工具链铺开，让天猫精灵真能控制设备；元婴期再考虑多终端协同。这样一次只跨一个境界，每一期都有可演示的产物，不会陷入“什么都想做、什么都不成”的泥潭。

2. 本地大模型这口“丹田灵气”：Ollama与DeepSeek的选型与部署

2.1 为什么不直接买云端API，非要本地部署

练气期的初衷是搞懂和掌控。商业API当然更方便，但有几个现实问题绕不过去：

• 数据隐私：家里日常对话，我不太想让第三方云服务拿去分析。
• 可定制性：API能调模型，但Prompt、函数调用、系统提示词的组合链路都锁在厂商的协议里。
• 成本：对话密集测试时，按token计费其实不便宜；本地部署是一次性硬件投入。

本地部署这条路上，可选方案不少：Ollama、vLLM、llama.cpp、LM Studio。排序下来，Ollama胜在“最省心”：安装一条命令，模型一条命令拉取，API风格接近OpenAI，社区生态成熟。vLLM适合追求吞吐的生产环境，但配置和学习成本高，筑基期再考虑。llama.cpp适合纯CPU环境或者要极致裁剪的场景。练气期，别纠结，上Ollama。

2.2 安装与拉模型实操

我用一台Ubuntu 22.04服务器，先更新系统，然后执行安装脚本：

curl -fsSL https://ollama.com/install.sh | sh

装完确认版本：

ollama --version

接着拉取模型。练气期推荐DeepSeek-R1的7B量化版，中文对话能力和推理表现都在线；如果你的显存只有6G，可以退到Qwen2.5:3b，只是回答深度会明显降一级。

ollama pull deepseek-r1:7b

拉取完成后，跑一个最简单的验证，确认模型能正常出字：

ollama run deepseek-r1:7b "用一句话介绍你自己"

这里有个新手常踩的坑：如果机器内存不足16G，模型加载阶段就可能被OOM杀进程。看到的报错五花八门，有的说连接被拒，有的直接没反应。先free -h看剩余内存，低于8G就老老实实换3B模型。另外注意，Ollama第一次加载模型会比较慢，要把模型完全载入显存后再发请求，不然响应时间会吓人。

2.3 让Ollama能被自建服务调用

模型在本地跑通了还不够，自建服务要通过HTTP调它。默认情况下Ollama只监听127.0.0.1，Docker容器或远程服务访问不到，需要设置环境变量再启动：

export OLLAMA_HOST=0.0.0.0 ollama serve

验证API是否可用：

curl http://localhost:11434/api/chat \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-r1:7b","messages":[{"role":"user","content":"你好"}],"stream":false}'

能拿到带message.content的JSON响应，这口丹田灵气就算激活了。注意OLLAMA_HOST=0.0.0.0意味着局域网内所有机器都能访问这个API，后面一定要用防火墙限制来源，只放行自建服务所在的机器或 Docker 网络。

2.4 用Docker把Ollama隔离起来

为了让后续整个项目干净，我建议一开始就把Ollama以容器方式跑，数据挂在本机目录：

sudo docker run -d \ --name ollama \ --gpus all \ -v /data/ollama:/root/.ollama \ -e OLLAMA_HOST=0.0.0.0 \ -p 11434:11434 \ ollama/ollama:latest

--gpus all是NVIDIA显卡的用法；纯CPU机器去掉这个参数，但要做好换小模型的心理准备。模型文件放在/data/ollama下面，以后重装容器不会丢模型。

进容器拉模型：

sudo docker exec -it ollama ollama pull deepseek-r1:7b

我在这里踩过一个很深的坑：宿主机直接跑Ollama时，模型缓存在~/.ollama；容器化之后默认不共享，导致容器里找不到模型，又硬生生重新下载一遍。把-v挂载目录固定好，这类问题一次避开。下面是几个模型在练气期阶段的选型对比，硬性条件直接对标：

3. 说话要过“仙门外门”：天猫精灵自定义技能创建与回调联调

3.1 在天猫精灵开放平台建技能

要让自己写的服务被天猫精灵唤起，需要在天猫精灵开放平台创建一个“自定义技能”。登录开发者控制台后，创建技能时选择“自定义技能”，填两个关键信息：技能名称和调用名称。

调用名称就是用户语音唤起你说的话，我填的是“东方仙盟”。填好后，用户对音箱说“天猫精灵，打开东方仙盟”，天猫精灵就会把后续语音解析到我们这个技能下面。命名尽量用口语化、短词，太长用户记不住，太生僻语音识别率会下降。

不同时期的平台界面可能改版，但“自定义技能”这个概念一直保留，字段找类似的填就行。这步不涉及代码，但有两个前置条件要注意：开发者账号要提前实名认证，技能涉及隐私政策时也要如实填写，不然后台上传服务地址会被卡住。

3.2 意图设计：练气期只做一个“聊天意图”

技能的核心是意图配置。天猫精灵云端会做NLU解析，把用户的话映射到某个意图上，再把解析结果POST给你的服务。

练气期不要把意图设计得太复杂，一个就够了：叫“chat”或者“闲聊”，只做一件事——把用户原始文本完整透传给你的后端。配置意图时，提供几个典型用户表达作为语料，比如“你好”“讲个笑话”“你知道什么是修仙吗”。

平台会拿这些语料训练NLU模型，但实际用户说的话千奇百怪，所以一定要留兜底逻辑：如果意图识别为None或识别错误，也把整句话透传下去。这样哪怕意图没匹配上，你的大模型也能接住，不会让用户听到生硬的“暂不支持”。

我在配置时还加了几个槽位，比如城市、时间，用于后面扩展工具调用。练气期不真正解析槽位，但先定义好字段，后面接天气、时间工具时就不用再改技能结构，这一步省下来的时间在联调阶段特别值。

3.3 回调协议的最小实现

技能配置的最后两步：填写后端服务地址，上传签名公钥。服务地址必须是公网HTTPS，自建服务收到POST后需要校验请求签名，防止别人伪造请求。

从平台到自建服务的请求体大致是这种结构（字段以你账号下平台文档为准，我按主链路简化）：

{ "token": "平台生成的身份令牌", "userId": "openid_xxx", "query": { "intentName": "chat", "utterance": "你好" }, "session": { "sessionId": "6f6a6d2e-8f3b-4ddb-9c1b-2e7a1b3c4d5e", "attributes": {} } }

自建服务需要返回的结果结构大致是这样：

{ "returnCode": "0", "result": { "toSay": "道友你好，我是东方仙盟练气期的守山弟子。", "nlg": { "type": "text", "value": "道友你好，我是东方仙盟练气期的守山弟子。" } } }

returnCode为0表示成功，result.toSay是播报文本，nlg里放结构化展示内容。练气期只要保证toSay和nlg.value一致，音箱就能正常播报。如果想在App端展示卡片，nlg里还有别的类型字段，但那是后话了。

3.4 联调阶段绕不过的三个坎

第一个坎是HTTPS。平台要求公网可访问的HTTPS服务。我的做法是Nginx反向代理，服务器上申请Let's Encrypt证书，自动续期，443端口转发到Spring Boot的8080。不要用自签名证书去试，平台不会认。

第二个坎是签名校验。平台允许你上传一个签名公钥，回调请求头里带签名，服务端要用公钥验签。这步不能省，一旦服务地址泄露，任何人都可以直接POST你的接口，白嫖你的GPU算力。

第三个坎是响应超时。天猫精灵对技能服务的响应时间卡得很死，从云端发起回调到你返回结果，通常只有几秒窗口。本地7B模型在GPU上生成一句话一般1到3秒，勉强够用；但要是让模型思考太久，或者网络抖动，平台就会向用户播报“技能开了小差”。练气期的兜底方案很粗暴：设置2.5秒的模型请求超时，超时就返回一句“道友稍等，我正在凝聚灵气，请再问一次”。真正的异步长任务处理，留到筑基期再做。

4. 把“丹田”和“外门”接起来：核心服务端开发

4.1 技术栈选择：Java还是Python，为什么是Spring Boot

回调服务就是普通HTTP Web服务，选型空间很大。我的纠结在Java Spring Boot和Python FastAPI之间。

FastAPI的优势是写起来飞快、异步原生、Python生态跟AI贴合紧密。Spring Boot的优势是工程化成熟，适合对接平台回调这类URL到URL的简单调用；后面如果想用LangChain4j做Agent，Java生态也有完整支持。考虑到筑基期、金丹期要在这个服务上叠加工具链和稳定运维，我最终选了Java 17 + Spring Boot 3.x。这不是说FastAPI不行，如果你更熟Python，完全可以用它，HTTP接口逻辑是一样的。

还有一个隐形理由：Java服务在处理“请求-响应”这种转发逻辑时，心智负担很低。回调进来的字段、出去的字段，用DTO定义清楚，后面自己复用也清晰。

4.2 核心接口代码：接收回调、转发模型、组织返回

我建了一个Spring Boot工程，核心就一个Controller，代码很短，但每行都有讲究：

@RestController @RequestMapping("/genie") public class GenieCallbackController { private final OllamaChatService ollamaChatService; public GenieCallbackController(OllamaChatService ollamaChatService) { this.ollamaChatService = ollamaChatService; } @PostMapping("/skill/chat") public Map<String, Object> handle(@RequestBody GenieRequest req) { String utterance = req.getQuery().getUtterance(); String sessionId = req.getSession().getSessionId(); String reply; try { reply = ollamaChatService.chat(sessionId, utterance); } catch (Exception e) { reply = "道友稍等，我正在凝聚灵气，请再问一次。"; } Map<String, Object> nlg = new HashMap<>(); nlg.put("type", "text"); nlg.put("value", reply); Map<String, Object> result = new HashMap<>(); result.put("toSay", reply); result.put("nlg", nlg); Map<String, Object> response = new HashMap<>(); response.put("returnCode", "0"); response.put("result", result); return response; } }

关键点在于：整个方法被try-catch包住，任何异常都不能让平台收到5xx。天猫精灵端用户只会听到“技能开了小差”，那是体验灾难。宁可返回兜底文案，也要保证returnCode恒为0。

4.3 调用Ollama：消息历史与超时设置

OllamaChatService的核心逻辑是调Ollama的/api/chat接口。练气期我把会话历史放在内存里，用sessionId做key，最多保留最近6条消息，防止上下文太长拖慢推理：

@Service public class OllamaChatService { private final RestTemplate restTemplate = new RestTemplate(); private final Map<String, Deque<ChatMessage>> sessions = new ConcurrentHashMap<>(); private static final String OLLAMA_URL = "http://127.0.0.1:11434/api/chat"; public String chat(String sessionId, String userText) { Deque<ChatMessage> history = sessions.computeIfAbsent(sessionId, k -> new ArrayDeque<>()); history.addLast(new ChatMessage("user", userText)); while (history.size() > 6) { history.removeFirst(); } Map<String, Object> reqBody = new HashMap<>(); reqBody.put("model", "deepseek-r1:7b"); reqBody.put("stream", false); reqBody.put("messages", new ArrayList<>(history)); HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); HttpEntity<Map<String, Object>> entity = new HttpEntity<>(reqBody, headers); ResponseEntity<Map> resp = restTemplate.postForEntity(OLLAMA_URL, entity, Map.class); Map data = resp.getBody(); String reply = (String) ((Map) data.get("message")).get("content"); history.addLast(new ChatMessage("assistant", reply)); return reply.trim(); } }

内存存储意味着服务重启后会话全丢，练气期可以接受，因为目的是验证链路。但有两个细节要注意：ConcurrentHashMap只保证基本线程安全，ArrayDeque在并发场景其实不严格安全，后面真要扛并发时要换成Redis。这里不展开，知道边界在哪就行。

超时设置很重要。我给RestTemplate配了连接超时和读取超时：

SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory(); factory.setConnectTimeout(2000); factory.setReadTimeout(3000); RestTemplate restTemplate = new RestTemplate(factory);

读取超时3秒，配合前面的兜底文案，基本能保证平台端的响应窗口不炸。实际调优中，我用4090跑deepseek-r1:7b，生成一句20字以内的回答大约1.5秒；但如果用户连环追问复杂问题，token数上去之后很容易超3秒。模型超时时间宁可保守，也不能让平台先报错。

4.4 服务配置与工程杂项

服务本身的配置不复杂，但有一个容易被忽略的点：回调服务一定要把端口固定好，配置到Nginx转发里。application.yml中：

server: port: 8080

另外，平台回调的Content-Type是application/json，Spring Boot默认能处理。如果遇到“Unsupported Media Type”这类错误，先检查Controller是不是写了错误映射。Java版本建议17以上，Spring Boot 3.x不再支持JDK 8，新建工程时就要盯住。

如果你的服务端技术栈是Python，逻辑完全一样，FastAPI只要在Post接口里做同样的字段解析和模型调用即可，唯一的差异在于异步写法。练气期，怎么顺手怎么来。

5. 从“会说话”到“会做事”：给练气期弟子装上工具

5.1 为什么练气期就要提Agent

天猫精灵如果只会闲聊，那跟一个会说话的摆件有什么区别？真正有价值的是让它能执行动作、查询数据。这就是Agent要解决的问题：大模型本身不感知外部世界，但它可以通过工具调用（Function Calling）来决定调用什么函数、传什么参数，然后把工具返回结果组织成用户能听懂的话。

练气期不需要把Agent框架完整铺开，但我会让链路从一开始就预留工具位。这样到筑基期，接RAG、接智能家居，都不用推翻重来。

5.2 Function Calling的最小链路

大模型Agent的基础模式是：

1. 在system prompt里描述有哪些工具，每个工具的参数格式是什么。
2. 用户提问后，模型输出的不一定是最终回答，而是一个结构化的“函数调用请求”。
3. 服务端解析这个请求，执行真正的工具代码。
4. 把工具执行结果回填给模型，模型再生成面向用户的最终回答。

在Ollama里，模型是否原生支持function calling，取决于模型本身。DeepSeek-R1在指令跟随和工具调用上的表现尚可，Qwen2.5系列对工具调用的支持则更稳定一些。练气期可以先用Qwen2.5:7b来做Agent验证。

给一个简单的system prompt片段：

你是东方仙盟的练气期守山弟子，说话要带一点修仙者气质，但要简洁。 当你需要查询天气时，输出： {"tool":"query_weather","arguments":{"city":"杭州"}} 如果不需要工具，直接正常回答。

服务端拿到模型输出后，先判断字符串里是否包含tool结构，包含就提取JSON、执行工具、把结果拼进对话上下文再问一次模型。这套逻辑很土，但原理跟正式Function Calling一致，适合练气期吃透机制。

5.3 一个可以直接抄的“查天气”工具

我写了一个最简工具，不依赖任何第三方SDK，用高德或和风天气的免费接口都能实现。核心是暴露一个可被调用的Java方法：

@Component public class WeatherTool { private final RestTemplate restTemplate = new RestTemplate(); public String queryWeather(String city) { String url = "https://example-weather-api.com/now?city=" + URLEncoder.encode(city, StandardCharsets.UTF_8) + "&key=" + System.getenv("WEATHER_API_KEY"); Map resp = restTemplate.getForObject(url, Map.class); return "{用户问题: " + city + " 天气, 结果: " + resp.get("text") + "}"; } }

方法返回的字符串会被拼回上下文，让模型最终说出：“道友，杭州现在多云，气温26度，适合御剑飞行。”重点是：工具返回值要尽量结构化，别把无关文本塞进去，否则模型容易被带偏。

5.4 MCP和Dify在练气期的定位

MCP（Model Context Protocol）是最近热度很高的模型上下文协议，简单理解就是给Agent工具调用制定了一套统一标准。Dify这类平台也已经支持MCP工具接入，可以把工具注册到可视化工作流里。练气期我没有直接上MCP，因为引入它等于多一层抽象和调试负担。但我在服务里预留了MCP客户端依赖，等筑基期工具多了，再按标准协议把现有工具包装成MCP服务，是水到渠成的事。

对只想跑通整体流程的读者，我的建议也是：先自己写两三个工具方法，理解调度循环，再上MCP。反过来学，容易在抽象层迷路。

6. 上线部署与踩坑实录

6.1 Docker Compose编排整条服务链

练气期的部署目标：一条docker compose up命令，把Ollama、自建服务、Nginx全部拉起来。我写了这样的编排文件：

services: ollama: image: ollama/ollama:latest container_name: ollama restart: always volumes: - ./data/ollama:/root/.ollama environment: - OLLAMA_HOST=0.0.0.0 ports: - "127.0.0.1:11434:11434" deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] skill-server: build: ./skill-server container_name: skill-server restart: always depends_on: - ollama environment: - OLLAMA_URL=http://ollama:11434 - SERVER_PORT=8080 ports: - "8080:8080" nginx: image: nginx:1.27-alpine container_name: genie-nginx restart: always depends_on: - skill-server volumes: - ./nginx/conf.d:/etc/nginx/conf.d:ro - ./nginx/ssl:/etc/nginx/ssl:ro ports: - "80:80" - "443:443"

一个细节：Ollama端口我映射到127.0.0.1:11434，而不是0.0.0.0。这样宿主机和Docker网络都能访问，但不会把Ollama直接暴露到公网。自建服务容器内通过http://ollama:11434访问，走的是Docker内部网络。安全上，宁可多绕一道，也不要让模型接口裸奔。

6.2 部署过程中最容易翻车的三个点

第一个是Docker的GPU支持。NVIDIA机器要在宿主机装好nvidia-container-toolkit，否则compose里写再漂亮的device配置也起不来。验证方式是docker exec进容器跑nvidia-smi，确认能看到显卡。

第二个是Nginx证书路径和权限。Let's Encrypt证书文件权限不对，Nginx容器会拒绝启动。我习惯把证书目录以只读方式挂载，文件属主设为root，Nginx master进程能读就行。

第三个是自建服务里OLLAMA_URL的坑。本地调试时我用http://127.0.0.1:11434，容器化之后必须改成http://ollama:11434，否则容器里访问的是自身，永远连不上模型。这个问题我修了半小时，最后是docker exec进容器里curl排查出来的。遇到容器网络问题，先进容器敲命令，别在宿主机对着配置文件猜。

6.3 延迟实测与调优手段

我整理了一次完整请求的耗时分布，单位毫秒。

总耗时大约2.1到4.3秒。用户体感是说话后有一两秒停顿，属于可接受范围，但还有挤压空间。我做了三个优化：

• 把模型换成量化版本，q4_K_M比默认版本推理更快，显存占用更小。
• 在system prompt里要求“回答不超过50字”，token数少了，推理时间直接降三分之一。
• 把Nginx的gzip打开，回调请求和响应都做压缩，公网传输那几十毫秒也能省。

这些优化做完，多数请求能压到3秒以内，语音交互的紧张感少了很多。不过要注意，别为了压时长把回答质量砍得太狠，用户听太敷衍的AI一样会腻。

6.4 避免被薅算力：签名校验与限流

服务一旦公网可访问，就要面对被扫描和刷接口的风险。我做三层防护：

• 平台签名校验：只接受带合法签名的回调请求。
• IP白名单：如果平台方提供固定回调IP段，在Nginx的allow配置里加上，非白名单直接拒绝。
• 简单限流：用Spring Boot的拦截器按userId做每分钟调用次数限制，超过就返回兜底文案，防止某个账号死循环把模型拖垮。

这层防护在练气期做到这个程度足够，也不会花太多时间。真正的高并发防护到了金丹期再折腾。

7. 练气期之后，筑基期再战

这一篇写到这里，链路已经完整：天猫精灵自定义技能、本地Ollama模型、Spring Boot回调节点、Agent工具雏形、Docker Compose部署，全部串起来了。我自己的体感是，经过这一轮，再看到“某设备接入大模型”的项目，不会再觉得高深，本质都是这条主链路的不同变形。

筑基期我准备做三件事：一是把会话历史从内存迁到Redis，支持更长上下文和服务重启不丢记忆；二是加一个RAG知识库，把手头资料变成可检索的仙术典籍，让模型回答有凭有据；三是把MCP工具标准化，把天气、定时任务、智能家居设备都接进来，让天猫精灵真正变成一个能执行命令的门派弟子。

练气期这段路我踩过最大的坑，其实不是技术问题，而是“什么都想做”。一开始我打算同时接知识库、做多轮记忆、调音色，结果链路都没跑通就陷进细节里。后来老老实实拆成最小闭环，反而一个周末就跑完了。如果你也在做类似的事，建议先从“能用”开始，让一句话能从你的音箱进到你的模型，再从模型里出来变成语音，这就是巨大的胜利。剩下的境界，一层一层破。