1. 项目概述：当AI语音助手学会“思考”

最近在折腾一个挺有意思的开源项目，叫 nia-agent-cyber/openai-voice-skill 。简单来说，它不是一个独立的语音助手，而是一个为现有智能家居或自动化平台（比如 Home Assistant）打造的“大脑升级”插件。它的核心思路是，利用 OpenAI 强大的语言模型（比如 GPT-3.5/4），让你原本只能执行固定指令的语音助手，变得能理解更复杂的自然语言，甚至能进行多轮对话和逻辑推理。

想象一下这个场景：你对家里的智能音箱说“我有点冷”，传统的语音助手可能会直接回复“当前室内温度是23摄氏度”，或者僵硬地执行一个名为“有点冷”的预制场景。但接入了这个技能后，你的指令会先被送到 OpenAI 的模型里进行分析。模型会理解到“有点冷”背后的真实意图是“希望提高室温”，然后它可能会生成一系列连贯的动作指令，比如“关闭客厅的窗户”、“将空调设置为制热模式26度”、“打开客厅的暖风机低档”。整个过程，你感觉是在和一个有“常识”和“判断力”的管家对话，而不是在给一个机器人念咒语。

这个项目解决的正是传统语音交互的“意图识别”天花板问题。大多数本地语音助手的意图识别依赖于严格的规则或有限的机器学习模型，对于“我困了，把卧室弄舒服点”、“客厅太亮了，调暗点但别全黑”这类充满上下文和模糊表述的指令，往往无能为力。 openai-voice-skill 通过引入大语言模型（LLM），将意图理解和任务规划这个最复杂的部分“外包”给了当前最先进的 AI，让本地系统专注于它擅长的设备控制和执行，从而实现了一次降维打击。

它非常适合那些已经搭建了 Home Assistant 等智能家居中枢，不满足于基础自动化，希望追求更自然、更智能人机交互的极客和玩家。接下来，我会从设计思路、部署细节、核心配置到实战避坑，完整拆解这个项目，让你不仅能搭起来，更能理解它为何如此工作。

2. 核心架构与设计哲学

2.1 桥接器模式：本地控制与云端智能的分工

这个项目的架构设计非常清晰，采用了典型的“桥接器”模式。它自身并不包含语音唤醒（Wake Word）、语音识别（STT）或语音合成（TTS）模块，也不直接控制设备。它的定位是一个“中间件”或“技能”，负责在已有的语音管道和 OpenAI API 之间架起一座桥梁。

整个工作流可以分解为以下几个步骤：

  1. 语音捕获与识别 ：由你系统中已有的组件完成，例如 Home Assistant 配合 Assist 或 Rhasspy ，或者独立的 Vosk 、 Whisper 服务。它们负责听到唤醒词，将你的语音转换成文字。
  2. 文本传递 ：转换后的文字指令被发送到 openai-voice-skill 。
  3. 意图理解与规划 ：这是核心环节。技能将原始指令、用户自定义的“技能描述”（告诉AI家里有哪些设备、能干什么）以及对话历史（如果支持）一起，组合成一个精心设计的提示词（Prompt），发送给 OpenAI API。
  4. 结构化指令生成 ：OpenAI 的模型会分析提示词，理解用户意图，并生成一个结构化的响应。这个响应通常是一个 JSON 对象，明确包含了要执行的服务（如 light.turn_on ）、目标实体（如 light.living_room ）以及所需参数（如 brightness_pct: 70 ）。
  5. 指令执行 ： openai-voice-skill 解析这个 JSON 响应，将其转化为对 Home Assistant API 的精确调用，从而控制实体设备或执行场景。
  6. 结果反馈（可选） ：执行成功后，技能可以再次调用 OpenAI，生成一个拟人化的语音回复文本（如“已经为您调亮了客厅的灯光”），再通过系统的 TTS 模块播放出来。

这种设计的最大优势是 解耦 和 专注 。项目团队无需重复造轮子去处理嘈杂环境下的语音识别难题，也无需维护庞大的设备控制库，只需专注于如何与 OpenAI API 高效、安全地交互，并设计出能引导 AI 正确理解家庭环境的提示词工程。这大大降低了开发复杂度和维护成本。

2.2 提示词工程：如何让AI理解你的家

项目的核心“魔法”在于其提示词模板。它不是一个简单的“请执行指令”，而是一个包含了丰富上下文信息的系统指令。一个典型的提示词结构如下：

你是一个智能家庭助手，控制着一个家庭自动化系统。用户可以通过自然语言向你发出指令。
当前系统中有以下设备和服务可用：
[这里是用户自定义的技能描述，例如：- 实体 `light.living_room`， 这是一个客厅主灯，可以开关、调节亮度和色温。 - 实体 `climate.living_room_ac`， 这是客厅空调，可以设置模式（制冷、制热、送风）、调节温度。]
请根据用户的请求，判断其意图，并生成一个JSON格式的响应。JSON必须包含“service”（服务名）、“entity_id”（实体ID）和“data”（服务数据，可选）。
如果请求无法通过现有设备完成，或意图不明，请回复一个友好的解释。
用户请求：{用户输入的文本}

这个提示词做了几件关键事：

  1. 设定角色 ：明确告诉AI“你是一个家庭助手”，限定其回答范围。
  2. 提供知识 ：将用户家中的设备清单和能力，以结构化的方式“喂”给AI。这是AI能进行准确规划的基础。
  3. 定义输出格式 ：强制要求AI以指定的JSON格式回应，这便于程序自动化解析，避免了处理自由文本的复杂性。
  4. 处理边界情况 ：指示AI在无法处理时给出友好回应，提升了用户体验。

在实际配置中，你需要精心编写这份“技能描述”。描述的质量直接决定了AI的理解能力。好的描述应该准确、简洁，并包含关键属性。例如，与其写“客厅灯”，不如写“实体 light.living_room ， 这是客厅中央的吸顶灯，支持开关、调节亮度（0-100%）和色温（2700K-6500K）”。后者为AI提供了更充分的决策依据。

注意 ：在提示词中暴露实体ID时，需考虑隐私和安全。虽然这些ID本身不直接构成风险，但结合其他信息可能有助于构建家庭地图。建议仅在受信任的本地网络环境中使用此方案。

3. 详细部署与配置指南

3.1 环境准备与依赖安装

该项目通常以 Home Assistant 自定义集成（Custom Component）或独立容器（Docker）的方式运行。这里以更通用、更灵活的 Docker 部署为例进行说明。

首先，确保你的宿主机上已安装 Docker 和 Docker Compose。然后，创建一个项目目录，例如 openai-voice-skills ，并在其中创建核心配置文件。

1. 创建 docker-compose.yml 文件： 

version: '3.8'
services:
  openai-voice-skill:
    image: ghcr.io/nia-agent-cyber/openai-voice-skill:latest # 使用官方镜像
    container_name: openai-voice-skill
    restart: unless-stopped
    ports:
      - "3000:3000" # 将容器内的3000端口映射到宿主机
    environment:
      - OPENAI_API_KEY=${OPENAI_API_KEY} # 从环境变量文件读取密钥
      - HA_BASE_URL=${HA_BASE_URL} # Home Assistant地址
      - HA_ACCESS_TOKEN=${HA_ACCESS_TOKEN} # Home Assistant长期访问令牌
      - PORT=3000
      - LOG_LEVEL=info
    volumes:
      - ./config:/app/config:ro # 挂载本地配置目录
    networks:
      - homeassistant_network # 建议与HA在同一网络

networks:
  homeassistant_network:
    external: true # 使用外部已存在的HA网络

2. 创建 .env 环境变量文件： 这个文件包含敏感信息， 务必 将其加入 .gitignore ，避免泄露。

# OpenAI API 密钥，从 platform.openai.com 获取
OPENAI_API_KEY=sk-你的真实api密钥
# 你的 Home Assistant 实例地址，如果是同一台机器，可以是内网IP或服务名
HA_BASE_URL=http://homeassistant:8123
# Home Assistant 长期访问令牌，在HA用户配置文件中创建
HA_ACCESS_TOKEN=你的长期访问令牌

3. 创建技能配置文件 config/skills.yaml ： 这是项目的灵魂，定义了AI所知道的“世界”。

skills:
  - name: "灯光控制"
    description: |
      控制家中的灯光设备。
      - 实体 `light.living_room_main`： 客厅主灯，可开关、调亮度（百分比）、调色温（暖白到冷白）。
      - 实体 `light.bedroom_nightstand`： 床头阅读灯，可开关、调亮度。
      - 实体 `light.kitchen_ceiling`： 厨房顶灯，仅可开关。
    triggers: ["灯", "亮度", "开灯", "关灯", "调亮", "调暗"] # 可选，用于初步过滤指令

  - name: "空调与气候控制"
    description: |
      管理室内温度和空气。
      - 实体 `climate.living_room_ac`： 客厅空调，可设置模式（`heat`制热, `cool`制冷, `fan_only`送风, `auto`自动）、调节目标温度（摄氏度）。
      - 实体 `fan.xiaomi_air_purifier`： 空气净化器，可开关、调节风速档位（`Silent`, `Standard`, `Strong`）。
    triggers: ["温度", "冷", "热", "空调", "暖气", "净化器"]

  - name: "场景与媒体"
    description: |
      执行场景和控制媒体设备。
      - 场景 `scene.movie_time`： 电影模式，会调暗灯光、关闭窗帘、打开电视和音响。
      - 场景 `scene.good_night`： 晚安模式，会关闭所有灯光、检查门锁、设置空调为睡眠模式。
      - 实体 `media_player.living_room_tv`： 客厅电视，可开关、调节音量、播放/暂停。
    triggers: ["电影", "睡觉", "晚安", "电视", "音量"]

3.2 与 Home Assistant 的集成配置

部署好技能服务后，需要在 Home Assistant 中创建一个“RESTful 命令”或使用“Shell Command”集成来调用它。

方法一：使用 RESTful Command 集成（推荐） 在 configuration.yaml 中添加：

rest_command:
  ask_openai_assistant:
    url: "http://openai-voice-skill:3000/ask" # 使用Docker服务名，确保网络互通
    method: POST
    content_type: "application/json"
    payload: '{"text": "{{ text }}"}'
    headers:
      Authorization: "Bearer {{ hass.config.api_password }}" # 或使用一个固定的令牌，需在技能服务端配置验证

然后，你可以通过自动化或脚本调用这个服务：

automation:
  - alias: "Process Voice Command with OpenAI"
    trigger:
      platform: event
      event_type: conversation_process
      # 或者触发于某个特定的输入文本事件
    action:
      - service: rest_command.ask_openai_assistant
        data:
          text: "{{ trigger.event.data.text }}"
      - service: notify.persistent_notification
        data:
          message: "命令已发送处理。"

方法二：在语音助手中直接集成 如果你使用类似 Assist ，可能需要更复杂的流程，例如通过一个中间 Webhook 触发自动化，再在自动化中调用上述 RESTful 命令。

关键配置解析：

  • HA_ACCESS_TOKEN ：这是安全通信的关键。务必在 Home Assistant 的“用户配置”中创建一个长期有效的访问令牌，并确保其权限足够（通常需要所有权限）。
  • 网络 ：强烈建议将 openai-voice-skill 的容器与 Home Assistant 容器置于同一个自定义 Docker 网络中（如示例中的 homeassistant_network ）。这样它们可以通过服务名（如 homeassistant:8123 ）直接通信，无需暴露端口到宿主机，更安全。
  • 技能描述 ： skills.yaml 中的描述是静态的。如果你的设备频繁变动，可以考虑动态生成此文件，例如写一个脚本，定期从 Home Assistant 的 API 获取实体列表并格式化后写入。

4. 核心功能实现与高级用法

4.1 基础对话与设备控制流程

当你说出“把客厅灯调到百分之五十亮度”时，整个系统的交互时序如下：

  1. 语音识别 ： Whisper 服务将音频转为文本：“把客厅灯调到百分之五十亮度”。
  2. 指令路由 ：Home Assistant 的自动化或脚本捕获此文本，并通过 rest_command.ask_openai_assistant 将其 POST 到 http://openai-voice-skill:3000/ask 。
  3. 技能处理 ： openai-voice-skill 服务收到请求。它会加载 skills.yaml ，将所有技能描述拼接起来，与用户指令一起，填入预设的提示词模板。
  4. 调用 OpenAI API ：组装好的提示词被发送到 OpenAI 的 Chat Completion 端点（例如 gpt-3.5-turbo ）。
  5. 解析AI响应 ：假设AI返回了以下JSON： 
    {
  "service": "light.turn_on",
  "entity_id": "light.living_room_main",
  "data": {
    "brightness_pct": 50
  }
}
  6. 执行HA服务 ：技能服务解析此JSON，使用配置的 HA_ACCESS_TOKEN 向 HA_BASE_URL 发起 API 调用： POST /api/services/light/turn_on ，携带相应的实体ID和数据。
  7. 设备响应 ：Home Assistant 接收到调用，控制 light.living_room_main 实体，将亮度调整为50%。
  8. 生成语音反馈（可选） ：技能服务可以发起第二次 OpenAI 调用，使用一个专注于生成友好回复的提示词，如“根据刚才执行的动作，生成一句简短的自然语言回复”。得到回复文本后，再通过 Home Assistant 的 TTS 服务播报出来。

4.2 实现多轮对话与上下文记忆

基础版本只能处理单次指令。要实现“把灯调暗点……再暗一点”这样的多轮对话，需要引入上下文记忆机制。这通常需要在 openai-voice-skill 中维护一个简单的对话会话。

实现思路：

  1. 会话标识 ：为每个用户或每个交互源头（如某个音箱）创建一个唯一的会话ID（Session ID）。
  2. 历史存储 ：在服务的内存或外部缓存（如 Redis）中，以 session_id 为键，存储一个对话历史列表。每条历史记录包含 role （ user 或 assistant ）和 content （消息内容）。
  3. 提示词增强 ：在每次调用 OpenAI API 时，不仅发送当前的用户指令和技能描述，还将之前几轮的对话历史也作为上下文附加到提示词中。例如： 
    ... (之前的系统提示和技能描述) ...
以下是当前的对话历史：
用户：把客厅灯调暗点。
助手：好的，已将客厅主灯亮度调整为30%。
用户：再暗一点。
  4. AI理解 ：OpenAI 的模型在接收到包含历史的上下文后，就能理解“再暗一点”指的是对“客厅灯”进行“进一步调暗”操作，从而可能生成一个将亮度调整为15%的指令。

技术要点：

  • 历史长度限制 ：OpenAI 模型有上下文窗口限制（如 4K、8K、16K tokens）。需要设置一个合理的对话历史轮数或总长度，避免超出限制。通常保留最近3-5轮对话即可。
  • 会话过期 ：需要实现一个清理机制，长时间无活动的会话应被清除，以释放内存。
  • 状态管理 ：对于更复杂的状态（如“我正在为你播放音乐”），可能需要将一些状态信息也存入会话中，并在提示词里告知AI。

4.3 自定义动作与复杂场景编排

openai-voice-skill 的核心是调用 Home Assistant 的服务。因此，任何 HA 能通过服务执行的动作，理论上都可以通过这个技能来触发。这包括了执行复杂的自动化场景。

示例：触发“电影模式”场景 当用户说“我想看电影了”，经过AI解析，可能会直接调用场景服务：

{
  "service": "scene.turn_on",
  "entity_id": "scene.movie_time"
}

这比单纯的“关灯”、“开电视”等一系列指令更高效，也更能保证场景执行的原子性和一致性。

进阶：让AI进行条件判断和复杂规划 通过更精巧的提示词设计，可以让AI进行简单的条件判断。例如，在技能描述中加入： “- 传感器 sensor.outside_temperature ： 室外温度传感器，单位摄氏度。” 当用户指令是“如果外面比屋里冷就关窗，否则开窗通风”时，AI的思考过程可能是：

  1. 从提示词中得知可以获取传感器数据（虽然它不能直接获取，但可以生成获取数据的指令）。
  2. 一个更高级的实现是，技能服务在调用AI前，先通过HA API获取相关传感器的状态，并将其作为“当前状态”的一部分写入提示词。
  3. AI根据“当前室外温度20°C，室内温度22°C”的状态，判断出“外面比屋里冷”，从而生成“关闭窗户”的指令。

这需要技能服务具备更强大的“状态预获取”和“提示词动态构建”能力，是项目可以深度优化的方向。

5. 成本优化、安全与隐私考量

5.1 控制API调用成本

使用 OpenAI API 会产生费用，虽然单次调用成本极低（GPT-3.5-Turbo每千 tokens约0.0015美元），但频繁使用仍会累积。以下是一些优化策略：

  1. 指令预过滤 ：在将用户指令发送给 OpenAI 之前，先进行一层本地过滤。例如，在 skills.yaml 中定义的 triggers 字段可以用于简单关键词匹配。只有指令中包含这些触发词时，才转发给AI处理。对于明确的“打开客厅灯”这类标准指令，完全可以用本地意图识别直接处理，无需劳驾GPT。
  2. 选择合适模型 ：对于家庭控制场景， gpt-3.5-turbo 在理解力和成本上取得了很好的平衡，响应速度也快。只有在需要处理非常复杂、充满隐含含义的指令时，才考虑使用 gpt-4 。
  3. 设置使用限额 ：在技能服务端实现一个简单的计数器，为每个用户/设备设置每日或每月的最大调用次数，防止意外滥用。
  4. 缓存常见响应 ：对于完全相同的用户指令，可以将其和AI返回的JSON响应缓存起来（例如缓存1小时）。下次收到相同指令时，直接使用缓存结果，避免重复调用API。注意，这可能会忽略设备状态的变化，需谨慎使用。

5.2 安全与隐私加固方案

将家庭设备控制权交给云端AI，安全是重中之重。

  1. API密钥保护 ： OPENAI_API_KEY 必须通过环境变量或密钥管理服务传入，绝不能硬编码在配置文件或代码中。Docker 的 .env 文件管理是基础。
  2. 网络隔离 ：确保 openai-voice-skill 服务本身不直接暴露在公网。它只应与 Home Assistant 在内网通信。所有外部访问都应通过 Home Assistant 本身的安全网关（如Nabu Casa云、自建反向代理+认证）来进行。
  3. 请求认证 ：在 openai-voice-skill 服务端，应验证来自 Home Assistant 的请求。示例中使用了 HA_ACCESS_TOKEN 进行HA API调用，但反过来，技能服务也应该验证HA发来的请求。可以在HA调用RESTful命令时，在请求头中添加一个共享密钥，并在技能服务中校验。
  4. 指令白名单/沙盒 ：在技能服务中，可以维护一个允许执行的“服务白名单”。在将AI返回的JSON指令发送给HA执行前，先检查 service 字段是否在白名单内（如只允许 light. , switch. , climate. 等开头的服务）。这可以防止AI被诱导调用危险服务（如删除文件、重启主机等）。
  5. 隐私数据剥离 ：在构建提示词时，避免将高度个人化或敏感的实体名称（如 device_tracker.johns_phone ）直接暴露。可以使用别名或泛化描述。同时，OpenAI 的API调用内容应被视为可能被用于模型训练（除非使用明确不记录数据的企业版），因此避免在指令中发送任何个人身份信息。

5.3 性能调优与稳定性保障

  1. 超时与重试 ：网络请求可能失败。在技能服务调用 OpenAI API 和 Home Assistant API 时，必须设置合理的超时时间（如10-30秒），并实现重试逻辑（最多2-3次，且对于幂等操作）。
  2. 错误处理与降级 ：如果 OpenAI API 服务不可用或返回错误，技能服务应有降级方案。例如，可以回退到本地的、基于规则的简单意图识别器，或者直接向用户返回“网络服务暂时不可用”的提示。
  3. 日志与监控 ：启用并合理配置日志级别（ LOG_LEVEL ），记录关键事件（收到请求、调用AI、执行HA服务、发生错误）。这有助于问题排查。可以考虑将日志输出到标准输出，然后由 Docker 的日志驱动收集，或接入到 ELK 等日志平台。
  4. 资源限制 ：为 Docker 容器设置 CPU 和内存限制，防止其异常时拖垮宿主机的其他服务。

6. 实战问题排查与经验心得

6.1 常见错误与解决方案

在实际部署和使用中，你可能会遇到以下典型问题：

问题现象 可能原因 排查步骤与解决方案
技能服务启动失败，报错连接不上 OpenAI 1. OPENAI_API_KEY 环境变量未设置或错误。
2. 容器无法访问外网（OpenAI API）。		 1. 检查 .env 文件格式和内容，确保密钥正确无误，无多余空格。
2. 进入容器内部 ( docker exec -it openai-voice-skill sh )，尝试 curl api.openai.com ，检查网络连通性。确保Docker宿主机的网络或代理配置正确。
Home Assistant 报错，无法调用技能服务 1. docker-compose.yml 中端口映射或网络配置错误。
2. HA中 rest_command 的URL地址错误。
3. 技能服务容器未正常运行。		 1. 确认 docker-compose.yml 中端口映射正确，且宿主机3000端口未被占用。
2. 确认HA容器与技能容器在同一Docker网络，且HA中URL使用容器服务名（如 http://openai-voice-skill:3000 ）。
3. 运行 docker logs openai-voice-skill 查看技能服务日志。
AI返回的指令无法执行，HA报“服务不存在” 1. AI生成的 service 字段格式错误。
2. 对应的实体在当前HA实例中不存在或名称不一致。
3. 技能描述 ( skills.yaml ) 中的实体信息过时。		 1. 检查技能服务日志中AI返回的原始JSON，确认 service 格式为 domain.service （如 light.turn_on ）。
2. 在HA开发者工具-服务中，手动调用该服务，确认其存在且能正常工作。
3. 核对 skills.yaml 中的实体ID与HA中完全一致。实体ID区分大小写和空格。
AI无法理解指令，总是返回“无法处理” 1. 提示词模板或技能描述 ( skills.yaml ) 编写不佳。
2. 用户指令过于模糊，超出AI基于现有描述的理解能力。
3. 使用的OpenAI模型能力不足。		 1. 优化 skills.yaml ，确保描述清晰、准确、完整。为关键设备添加别名（如“客厅大灯”对应 light.living_room_main ）。
2. 在提示词中增加示例（Few-Shot Learning），展示几个正确指令和AI应返回的JSON例子。
3. 尝试切换到更强大的模型（如 gpt-4 ），但注意成本。
响应速度很慢 1. OpenAI API 响应慢。
2. 网络延迟高。
3. 提示词过长，导致处理时间增加。		 1. 这是常见情况，OpenAI API 的响应时间在1-3秒属正常范围。考虑用户预期管理。
2. 确保服务器网络状况良好。
3. 精简 skills.yaml 描述，移除不必要的信息。只保留核心设备和属性。

6.2 从实践中得来的几点心得

  1. 技能描述是成功的一半 ：花时间精心编写 skills.yaml 绝对值得。用机器可读且人类能懂的语言描述你的设备。包括实体的 功能 （能做什么）、 属性 （有哪些参数）、 位置 和 常用别名 。例如：“ light.kitchen_under_cabinet ： 厨房操作台下的灯带，用于补充照明，可开关和调节亮度。我们通常叫它‘厨下灯’或‘备菜灯’。”
  2. 从小范围测试开始 ：不要一开始就把全家几百个设备都塞进技能描述。先挑选一个领域（如灯光），用3-5个核心实体进行测试。验证从语音识别到设备控制的整个链路畅通后，再逐步添加其他设备。这有助于隔离和定位问题。
  3. 为AI设定明确的边界 ：在系统提示词中，明确告诉AI什么不能做。例如：“你只能控制上述列表中描述的设备和场景。对于列表外的请求，或者涉及安全、隐私的请求（如开门、查看摄像头），你必须直接拒绝，并回复‘出于安全考虑，我无法执行这个操作’。”
  4. 成本监控不可少 ：在 OpenAI 后台设置用量告警。刚开始使用的头几天，密切关注 token 消耗情况。你会发现，复杂的、需要AI“思考”的指令（如“营造一个浪漫的氛围”）消耗的 token 会比简单指令（“开灯”）多得多。
  5. 本地LLM是未来方向 ：对隐私和延迟有极致要求，且拥有高性能硬件的用户，可以关注本地部署的大语言模型（如 Llama 3、Qwen 等）。未来可以将 openai-voice-skill 的后端从 OpenAI API 替换为本地 LLM 的 API，实现完全离线的智能语音控制。这将是隐私和响应速度的终极解决方案，当然，对硬件和模型调优能力的要求也更高。

这个项目打开了一扇门，让我们看到了大语言模型与具体领域（如智能家居）结合的巨大潜力。它不再是一个玩具，而是一个能切实提升生活便利性的工具。部署过程本身，就是对提示词工程、API集成和系统架构的一次绝佳实践。当你对着屋子说“感觉有点闷热还亮堂堂的”，而系统自动理解了“闷热”需要“开空调制冷”，“亮堂堂”需要“调暗灯光”，并精准执行时，那种感觉，才是智能家居应有的样子。

# 智能家居
Logo
码道开发者社区

码道开发者社区，聚焦华为云码道 CodeArts 代码智能体，沉淀 Agent、Skill、鸿蒙开发实战内容，供开发者查阅资料、交流技术、分享工程实践

更多推荐

Manim 数学动画完全指南：五分钟从零到成片

Manim 是用 Python 驱动的数学动画引擎，把抽象的公式与曲线转成逐帧可控的动态可视化。适合想制作 Python 数学可视化视频的编程新手、数学学生和科普创作者。## 数学为什么需要"动"起来你试过用一张静态图讲清导数的概念吗？切线、割线、极限位置都能画出来，但"割线逼近切线"发生的那一下，观众只能靠脑补。课本插图大多是"结论截图"：只留下最终状态，过程被压缩成一句"易见"。函

avatar 码道开发者社区
cover

Claude API + Python实战：结构化输出后，如何拦住“看起来正确”的JSON

avatar 码道开发者社区
cover

GLM-5.3-Flash深度解析：3200亿参数只卖Opus四十分之一，国产算力首次跑通前沿模型

avatar 码道开发者社区