从 0 到 1：我们在 NVIDIA DGX Spark™ 上做出第一个 AI 项目

一支 12–15 岁少年小组，如何从第一次部署本地模型开始，逐步掌握 Skills、跑通工作流，并把想法做成真正的产品网页。

作为一支由 12–15 岁学生组成的开发小组，我们在几天的项目实践中发现，自己能够完成的事情远比想象中更多。围绕一台 NVIDIA DGX Spark™，我们从本地模型部署开始，搭建智能体、编写 Skills、跑通应用工作流，并为自己的项目制作了可以对外展示的产品网页。

这段经历始于一次由 NVIDIA Elite Partner 在上海组织的青少年 AI 夏令营，但我们想记录的并不是营地本身，而是一群少年如何借助本地 AI 算力，把一个想法一步步变成能够运行、展示，也能被别人理解的产品。

一台放在桌面上的本地 AI 开发环境

过去我们使用 AI，大多是在浏览器里提问、生成文字或图片。真正开始做项目后，我们才发现：如果要不断修改提示词、测试不同 Skills、同时运行多个任务，AI 就不能只是一个“问答工具”，还需要一个稳定的开发环境。

DGX Spark 成了团队共用的本地算力底座。它搭载 GB10 Grace Blackwell 超级芯片、128GB 统一内存，并在 FP4 精度下提供最高 1 PFLOP 的 AI 性能。对我们最直接的意义并不是记住这些参数，而是可以把开放模型放在本地运行，让组员通过局域网共同使用同一个模型服务，修改之后立即测试，不必每一步都依赖外部 API。

本地算力带来的变化很简单：想法出现后，我们可以马上试；第一次失败后，也可以马上进入下一轮。

从模型服务到智能体，我们只抓住一条主线

我们的技术路径并不复杂，但每一步都需要自己真正跑通。我们先在 DGX Spark 上配置 CUDA® 环境、编译 llama.cpp，再加载经过量化的 Qwen 系列开放模型，通过 llama-server 启动本地模型服务。服务运行起来以后，小组成员可以从自己的电脑通过局域网访问同一个 OpenAI 兼容接口。第一次在另一台电脑上收到本地模型的回复时，我们才真正理解了“模型部署成功”意味着什么。

技术记录｜本次实际配置 CUDA 13.0，NVIDIA Driver 580.95.05；llama.cpp 按 GB10 的 sm_121 架构编译，完整构建约 5–10 分钟。主模型使用 Qwen3.6-35B-A3B-MTP-GGUF 的 UD-Q4_K_XL 量化版本，文件约 22.9GB，加载后约占 24–26GB 统一内存。

接下来，我们安装 OpenClaw，把它连接到本地模型服务，并开始为任务编写 Skills。一个 Skill 不只是一段提示词，它还包含使用场景、支持资料和工具调用规则。我们把它理解成给智能体准备的“任务说明书”：什么问题可以直接从资料中查找，什么时候需要使用网络工具，最后应该以怎样的结构返回结果。

技术记录｜智能体与 Skill 本次使用 OpenClaw 2026.7.1-2，通过 OpenAI 兼容接口连接本地 llama-server。导览 Skill 由场景说明、7 个支持文件和工具调用规则组成；区域、餐厅与设施信息优先读取本地资料，只有天气、当日活动等动态内容才触发网络查询。

这也是我们从 0 开始掌握的第一个完整 AI 开发技能。我们不是一上来就写复杂系统，而是沿着一条清楚的路径前进：启动本地模型服务 → 接入 OpenClaw → 写出第一个 Skill → 串联工具形成工作流 → 把结果接入网页。每完成一步，下一步才真正有了基础。

在 DGX Spark 上完成本地推理服务构建。我们不需要记住每一条命令，但需要理解每一步在解决什么问题。

网页不是最后的包装，而是项目真正被看见的地方

在所有成果中，我们投入最多的其实是产品网页。我们需要把项目做成一个可以打开、体验和介绍的页面，而不是只留下几张截图或一段演示视频。网页因此成为技术原型与真实用户之间的第一扇门。

我们先讨论网页应该让访客最先看见什么：项目解决的问题、适合谁使用、核心功能是什么，以及怎样让别人快速完成一次体验。随后，运行在 DGX Spark 上的编程智能体帮助我们梳理信息结构、修改文案、生成前端代码，并检查按钮、页面跳转和不同屏幕尺寸下的显示效果。遇到报错时，我们把日志交给智能体分析，再由团队判断建议是否合理、修改后有没有影响其他功能。

这个过程让我们第一次意识到，做网页并不是把文字和图片“放上去”。一张完整的产品网页需要同时回答三个问题：产品能不能运行，用户能不能理解，我们能不能把它讲清楚。网页也把小组原本分散的模型、Skills、工作流和路演内容，组织成了一个统一的产品入口。

一个具体案例：让导览建议更快、更可靠

我们小组选择做一个游乐场导览应用，这也是文章中所有测试和优化都来自的真实项目。最初，我们让智能体每次回答都重新搜索网络，从提问到生成完整建议往往需要 45 秒以上，而且偶尔会混入过期信息。后来，我们把区域、餐厅和设施等相对稳定的内容整理进 Skill 的支持文件，只在查询天气和当日活动时调用网络工具。

调整之后，多数常见问题可以在 5 秒内返回结果。网页则把这条工作流变成了真正可用的界面：用户提出需求后，可以看到路线、时间安排、餐饮信息和天气建议，而不需要理解背后的模型与工具调用。对我们来说，这比“模型回答成功了”更重要——数据经过模型、Skills 和工具流转之后，最终变成了用户看得懂、用得上的内容。

导览工作流测试：智能体结合支持文件与实时天气，生成可直接呈现在产品网页中的行程建议。

从一个 Skill，慢慢长成一个完整项目

导览只是入口。围绕同一个项目，我们继续加入 FAQ、天气推荐、内容整理和页面生成等工作流，并让智能体协助我们完成路演 PPT、产品文案和团队介绍。在主要功能跑通后，我们还把智能体轻量连接到 Reachy Mini，尝试让软件侧的回答与判断延伸到实体机器人；但这只是一次具身智能验证，项目的核心仍然是 DGX Spark 上运行的本地模型、Skills 和应用工作流。

技术记录｜一次真实调试 接入 Reachy Mini 时，我们遇到 DGX Spark ARM64 环境下 MediaPipe 版本兼容，以及 OpenClaw Gateway 协议不匹配的问题。在技术人员指导下，我们用 Python 3.12 重建环境，并调整桥接脚本的协议范围。这里保留结果与思路，不展开全部报错日志。

几天时间当然不足以让我们成为成熟工程师。配置环境、处理接口兼容问题时，我们仍然需要老师和技术人员帮助。但从编译完成后读懂终端提示，到根据日志判断模型、Skill 还是网页接口出了问题，再到修改后重新测试，我们已经不再只是照着步骤操作。项目中大部分可以被看见的成果——Skills 的组织、应用流程、产品网页和路演表达——都来自我们一次次讨论与迭代。

完整技术路径总结

回头看，我们并不是同时掌握了所有工具，而是把一个完整项目拆成可以逐步验证的七个阶段。前一步跑通，才进入下一步：

阶段	我们完成的关键动作
1｜本地环境	以 DGX Spark 为算力底座，确认 DGX OS™、CUDA、Driver 与 GB10 ARM64 环境可用。
2｜模型服务	编译 llama.cpp，加载量化后的 Qwen 模型，通过 llama-server 提供 OpenAI 兼容 API，并开放局域网访问。
3｜智能体框架	安装 OpenClaw，连接本地模型服务，确认模型对话与工具调用能够在本地稳定运行。
4｜Skills 设计	为导览任务定义使用场景、支持文件与工具规则：稳定信息优先本地检索，动态信息再调用网络工具。
5｜应用工作流	完成意图判断、本地资料读取、天气与活动查询、结果整合和结构化输出，将常见问题响应从 45 秒以上缩短到 5 秒内。
6｜产品网页	借助编程智能体梳理信息结构、生成与修改前端代码，完成按钮、跳转、适配和接口调试，把工作流变成用户可体验的产品入口。
7｜具身延伸	通过桥接层把智能体轻量接入 Reachy Mini，并处理 ARM64 依赖与协议兼容问题，验证软件能力向实体设备延伸。

开发者的起点，可能正在提前

以前我们以为，成为开发者意味着先掌握很多语言、框架和复杂代码。现在我们更愿意把它理解为一种解决问题的方式：先从一个自己感兴趣的问题开始，再组织模型、智能体、工具和界面；遇到失败时查看原因，修改之后重新验证；最后把成果交给别人使用。

DGX Spark 没有替我们完成所有工作，但它让本地模型和持续迭代真正进入了团队的日常。我们不再只是向 AI 索取答案，而是开始决定 AI 应该怎样工作，并通过网页和应用把这种能力交给真实用户。

我们完成的还不是成熟的商业产品，但已经走完了一次从想法、本地部署、智能体工作流到产品网页的完整循环。

一次项目的尝试也让我们真正意识到，如果对 AI 感兴趣，不必等到已经会写很多代码再开始。我们可以先让一个本地模型运行起来，再为它写出第一个 Skill，然后尝试让它解决一个身边的真实问题。当越来越多和我们一样的年轻人可以在 DGX Spark 这样的桌面级本地算力上完成自己的第一个智能体、第一张产品网页和第一个 AI 应用，开发者的道路也许不再从某个固定年龄开始。它可能就开始于一个问题：我能不能把这个想法真正做出来？