桌面机器人玩到一定程度后很容易陷入一个尴尬的循环该加的传感器都加了该接的大模型也接了但每次让机器人“变个造型”“换个情绪”还要打开 App、翻开菜单、滚动选项。这种交互方式本质上还是“手机遥控”不是“实体交互”。这篇文章想聊的是一个更好玩的方案给 StackChan 桌面机器人加一个 NFC 读写模块用几块钱一张的 NFC 标签做“实体换装卡”。当你想让它增加一项配饰、切换一种装扮或者进入某个角色状态时直接把对应的 NFC 卡片放到机器人身上机器人读取卡片信息后自动调用 AI 生成该装扮的外观描述、表情、问候语和动作参数并显示在屏幕上。这里真正的技术点不是“读 NFC”本身而是把 NFC 标签当成了一个物理触发器让 AI 来匹配和生成“配饰内容”。整套链路拆开来看涉及 NFC 标签存储结构、嵌入式读卡、数据结构设计、AI Prompt 工程、端到端联调非常适合用来练手硬件与 AI 的融合项目。读完这篇文章你可以独立完成一个“NFC 换装 AI 配饰匹配”的最小系统并且理解这套方案背后的设计思路而不是只对着别人的演示视频羡慕。1. 这篇文章真正要解决的问题先说结论这个方案真正降低的是“桌面机器人与物理世界交互”的接入成本。传统桌面机器人的自定义装扮通常靠两种方式在代码里硬编码几套方案然后通过按键、手机 App 或网页菜单切换。给机器人加摄像头让它识别用户手上拿的配饰颜色或形状再决定如何显示。第一种方式缺少“实体感”用户以为自己是在设置软件不是在给机器人搭配饰第二种方式对硬件和算力要求很高普通 ESP32 开发板很难稳定跑通实时视觉识别。NFC 方案卡在中间但位置非常好。它既有实体的“刷卡”动作又有数字化的数据交换能力。具体来说你可以把一张 NFC 标签想象成一个小型“身份证”里面写入了装扮 ID、场景描述、配色偏好等数据。当 StackChan 读取到这张卡时它不需要理解“什么是帽子”“什么是围巾”只需要把卡片里的数据交给 AI由 AI 输出一套完整的装扮方案。所以这个项目的核心答案是NFC 负责定义“你想让机器人进入什么状态”AI 负责把“状态”扩展成“具体的呈现内容”。两者配合后换装不再是菜单里的选项而是一种符合直觉的物理操作。什么样的读者最应该读这篇文章正在玩 StackChan、M5Stack、ESP32 桌面机器人的创客和嵌入式开发者。对 NFC 标签想深入了解但被“Page 0x00、0x10、0x20……”这些地址吓住的新手。想把大模型接入硬件项目但不确定 Prompt 应该怎么写、返回结果应该怎么解析的 AI 应用开发者。这篇文章默认你熟悉基础 C 或 Python但对 NFC 和 StackChan 没有经验也没关系我会把每一步拆开讲。2. 核心概念与整体架构2.1 StackChan 是什么StackChan 是一个开源桌面机器人项目常见形态是基于 M5Stack 或 ESP32 开发板配一块显示屏、扬声器和麦克风可以做表情显示、语音对话、头部/身体运动等。因为硬件开源、社区活跃很多开发者把它当作“桌面机器人入门的首选”。在本文的架构里StackChan 扮演的是“终端展示设备”。它负责读取 NFC 卡片数据把数据发送给 AI 服务然后把 AI 返回的装扮描述、表情参数、语音问候显示出来或播放出来。2.2 NFC 是什么NFCNear Field Communication近场通信是一种短距离高频无线通信技术工作距离通常在 10 厘米以内。这个距离限制并不是缺点反而让 NFC 天然适合“靠近即触发”的交互场景。常用的 NFC 标签分为不同类型其中 NTAG215 在 DIY 和游戏领域非常常见比如你一定见过有人用 NTAG215 芯片做“音乐墙”或“游戏手办”原理都一样每个标签内部有一个存储区域可以写入数据当手机或读卡器靠近时就能读到这部分数据。这里有一个容易误解的点很多人以为“读 NFC 标签”就是读一个 ID 号。ID 号确实存在但 NFC 标签的存储区域也可以存放自定义内容。比如一张 NTAG215 标签用户可写区域有 504 字节足够存一段短文本、URL 或二进制数据。所以你可以把一张完整的小 JSON 塞进去也可以在标签里只写一个 ID其余信息放在云端数据库或 AI 服务端。2.3 AI 自动匹配配饰的流程整个系统的运行流程可以拆成四步StackChan 上的 NFC 读卡模块检测到一张标签靠近。系统读取标签中的内容得到一个“装扮请求”例如{item: hat, scene: party}。将这个请求拼进 Prompt发送给大模型 API 或本地模型服务。大模型返回结构化 JSON包含装扮名称、颜色建议、表情、动作、问候语等字段。StackChan 解析后渲染到屏幕并播放语音。这个流程的好处是“逻辑与内容分离”。NFC 标签里只存“意图”AI 负责生成“细节”。你想新增一套装扮不需要改代码只需要写一张新卡片或者让模型重新生成一套方案即可。2.4 系统架构概览整个系统建议分成三个模块模块职责示例客户端读取 NFC、发送请求、展示结果StackChanESP32 显示屏 PN532 读卡器服务端接收装扮请求、调用 AI、返回结构化结果Python Flask / FastAPI 应用数据载体存储装扮意图NTAG215 NFC 标签这种“嵌入式设备 云端服务”的结构比全部逻辑压在 ESP32 上要灵活得多。ESP32 的内存和算力有限跑一个完整的大模型不现实但把一个几十字节的 Prompt 请求发出去完全没有压力。3. 硬件准备与环境搭建3.1 硬件清单在开始之前需要准备以下硬件StackChan 机器人本体建议选择基于 M5Stack Core 或 ESP32 的开发板确认有 I2C 引脚或 SPI 引脚可用。NFC 读卡模块市面上常见的是 PN532 和 RC522。PN532 支持 I2C、SPI、UART 三种接口性能稳定适合新手RC522 价格便宜但速度稍慢文档不如 PN532 丰富。本文示例以 PN532 为主。若干 NFC 标签推荐 NTAG215容量大、兼容性好。价格一般在几块钱到十几块钱一张。面包板与杜邦线方便前期接线调试。注意不同型号的 StackChan 套件引脚定义可能不同。购买套件时先确认屏幕是否占用了部分 I2C 地址避免读卡模块冲突。这里给不出一个万能接线表但大方向是PN532 的 I2C 引脚接到开发板的 SDA/SCL电源接 3.3V 或 5VGND 接 GND。3.2 软件环境本文示例的软件环境如下具体版本以你实际项目为准Arduino IDE 或 PlatformIO用于编写并烧录 ESP32 端程序。Arduino 库Adafruit PN532 库用于 NFC 读卡。Python 3.8 及以上用于编写 AI 服务端。一个兼容 OpenAI 协议的大模型 API或者本地运行的 Ollama 服务。我建议前期先把 AI 服务端跑通再接硬件。这样万一出问题你可以确定问题出在“AI 服务”还是“硬件链路”上。3.3 验证读卡模块在接 StackChan 之前我建议先做一个最小实验只连接 ESP32 和 PN532烧录一个读取 UID 的示例程序。如果读卡模块能打印出卡片 ID说明硬件链路正常再继续后面的步骤。4. NFC 标签的数据设计与写入4.1 理解 NTAG215 的存储结构很多人第一次接触 NFC 标签时会被“Page 0x00、0x10、0x20、0x30”这些地址搞懵。这里用一句话解释NFC 标签的存储区被分成了若干“页”每页通常 4 字节地址只是代表第几页。以 NTAG215 为例Page 0x00 到 0x03厂家锁定区包含 UID、厂商信息、校验字节等。这一区域用户不能随便修改修改可能导致标签永久损坏。Page 0x04 开始用户数据区可以写入 URL、文本或二进制数据。最后还有少量区用于写入保护、密码保护等功能。所以在读写时不要把精力放在 Page 0x00 这类地址上那是厂家出厂时写好的“身份信息”。你需要关注的是用户数据区。写卡片时数据不要超过标签容量NTAG215 的用户可用数据大约是 504 字节。4.2 推荐的数据格式NFC 标签里写什么会直接影响 AI 服务的稳定性。我建议不要写一长串自然语言而是写一个精简的 JSON 或带分隔符的文本。例如在标签中写入以下 JSON{ item: hat, scene: party, color: red }也可以更简短地写成hat:party:red让服务端自己解析。但 JSON 的好处是可扩展、可读性好。缺点是占用字节更多。对于只有几十字节的短数据两种方式都无所谓。如果希望 AI 匹配更自由可以让 AI 自行扩展。例如标签里只写style: cyberpunkAI 就会自己生成一套赛博朋克风格的配饰组合。这种“少写多生成”的方式是 AI 应用和传统硬编码最明显的区别。4.3 写入 NFC 标签Python 示例写标签的工具有很多比如手机上的 NFC Tools、NFC TagWriter或者用 Python 的nfcpy库。下面是一个基于nfcpy的简单示例目的是向标签写入前面提到的 JSON 文本。import nfc import json # 要写入的数据 payload { item: hat, scene: party, color: red } text_data json.dumps(payload, ensure_asciiFalse) def on_write(tag): print(检测到标签, tag) # 将 JSON 作为 NDEF 文本写入 from nfc.tag.tt3 import NDEFTextRecord text_record NDEFTextRecord() text_record.text text_data tag.ndef.records [text_record] print(写入完成, text_data) return False # 返回 False 表示写完一次后停止监听 # 打开 NFC 读卡设备 clf nfc.ContactlessFrontend(usb) try: clf.connect(rdwr{on-connect: on_write}) finally: clf.close()这段代码的逻辑并不复杂先构造一个 JSON 字符串然后程序监听 NFC 读卡器当你把一张空白标签放到读卡器上时on_write函数被触发把文本记录写进标签。写卡时要特别注意如果标签之前写入了内容建议先用手机 App 或工具做一次格式化再写入新数据。部分标签一旦写入了某种记录类型再次覆盖时可能出现“空间不足”或“格式冲突”的提示。4.4 写卡注意事项不要修改 Page 0x00 到 0x03 的内容。这是厂商锁定区损坏后标签可能无法被识别。写入前确认标签容量。NTAG215 有足够空间但如果是 NTAG213容量更小大文本会写不进去。批量制作换装卡时建议在数据里加一个version字段方便以后升级格式。5. StackChan 端读取 NFC 的示例代码5.1 读取与解析当 NFC 标签写入完成后下一步是让 StackChan 读取它。这里使用 ESP32 和 PN532 模块配合 Adafruit PN532 库。下面的示例程序会完成三件事初始化 I2C 接口。持续监听 NFC 标签。读到标签后读取 NDEF 文本记录并打印到串口。// 文件路径nfc_reader/nfc_reader.ino #include Wire.h #include Adafruit_PN532.h #define PN532_IRQ (4) #define PN532_RESET (5) Adafruit_PN532 nfc(PN532_IRQ, PN532_RESET); void setup(void) { Serial.begin(115200); nfc.begin(); uint32_t versiondata nfc.getFirmwareVersion(); if (!versiondata) { Serial.println(没有找到 PN532 模块请检查接线); while (1); } Serial.print(PN532 固件版本: ); Serial.println((versiondata 16) 0xFF, HEX); nfc.setPassiveActivationRetries(3); nfc.SAMConfig(); Serial.println(等待 NFC 标签靠近...); } void loop(void) { uint8_t uid[] { 0, 0, 0, 0, 0, 0, 0 }; uint8_t uidLength; if (nfc.readPassiveTargetID(PN532_MIFARE_ISO14443A, uid, uidLength, 1000)) { Serial.print(读到 UID: ); for (uint8_t i 0; i uidLength; i) { Serial.print(uid[i], HEX); Serial.print( ); } Serial.println(); // 继续读取 NDEF 数据这里实现可以单独封装 readNdefText(); delay(2000); } } void readNdefText() { uint8_t key[] { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF }; // 示例这里仅打印占位说明 // 实际需要按 PN532 的 NDEF 读取流程适配 Adafruit_PN532 示例中的 // readNDEF 函数并把 Text 记录提取出来。 Serial.println(读取 NDEF 文本完整流程请参考 PN532_NDEF 官方示例); }这段代码里readNdefText函数只是占位说明。完整的 NDEF 读取流程在 Adafruit PN532 自带的示例工程里有现成实现直接复制过来并解析文本记录即可。很多新手卡在这里是因为把 UID 读取和 NDEF 数据读取混在一起了UID 是卡片的硬件编号NDEF 才是我们写入的业务数据。5.2 将读取结果发送给 AI 服务读到 NDEF 文本后下一步是通过 HTTP 请求把数据发给 AI 服务端。ESP32 自带 WiFi 库和 HTTPClient 库可以这样发送#include HTTPClient.h #include WiFi.h void sendToAi(const String tagData) { HTTPClient http; http.begin(http://192.168.1.100:8000/wardrobe); http.addHeader(Content-Type, application/json); String body {\tagData\:\ tagData \}; int code http.POST(body); Serial.print(AI 服务返回状态码); Serial.println(code); if (code 0) { String response http.getString(); Serial.println(response); } http.end(); }这里把tagData原样传给了服务端。服务端收到后解析 JSON再决定如何调用大模型。由于每个 StackChan 项目的网络配置方式不一样这里只写出核心的 HTTP 请求部分WiFi 的初始化需要你根据实际网络环境填写 SSID 和密码。6. AI 自动匹配配饰的服务实现6.1 为什么需要一层 AI 服务有人可能会问为什么不直接在 ESP32 上调用大模型 API原因是多方面的ESP32 的内存有限处理大模型返回的长文本和复杂 JSON 不够稳定。大模型的 API Key 放在嵌入式设备里很容易被提取存在安全风险。在服务端可以做缓存、日志、限流和 Prompt 版本管理后续改进成本低。所以更好的做法是让 ESP32 只做简单转发真正的 AI 逻辑放到 Python 服务端。6.2 构建 PromptAI 匹配配饰的核心是 Prompt 设计。假设 NFC 标签里的数据是{item: hat, scene: party, color: red}我们希望模型返回一份适合 StackChan 屏幕展示的装扮方案。一个可用的系统提示词如下你是一个桌面机器人配饰设计师。你会收到一段从 NFC 标签读取的用户请求 例如用户想要一件配饰、一个场景或一种风格。 请根据请求生成一份简洁的装扮方案必须使用 JSON 格式返回字段如下 - name: 装扮/配饰名称 - color: 主色调 - expression: 机器人表情如 happy、cool、sleepy - greeting: 一句 15 字以内的中文问候语 - icon: 适合在 128x128 屏幕上显示的简单图标样式建议 不要输出 JSON 以外的任何内容。请求内容这个 Prompt 有两个关键设计明确要求输出结构化 JSON且只输出 JSON。限制greeting的长度避免模型生成一长段对话导致屏幕无法完整展示。6.3 Python Flask 服务示例下面写一个最小可用的 Python 服务使用 Flask 提供接口。模型调用部分使用兼容 OpenAI 协议的方式这样可以替换成不同类型的 API 服务。# 文件路径ai_server/app.py import json import os import requests from flask import Flask, request, jsonify app Flask(__name__) # 从环境变量读取不要把密钥写死在代码里 API_URL os.getenv(LLM_API_URL, http://localhost:11434/v1/chat/completions) API_KEY os.getenv(LLM_API_KEY, ollama) SYSTEM_PROMPT 你是一个桌面机器人配饰设计师。你会收到一段从 NFC 标签读取的用户请求 例如用户想要一件配饰、一个场景或一种风格。 请根据请求生成一份简洁的装扮方案必须使用 JSON 格式返回字段如下 - name: 装扮/配饰名称 - color: 主色调 - expression: 机器人表情如 happy、cool、sleepy - greeting: 一句 15 字以内的中文问候语 - icon: 适合在 128x128 屏幕上显示的简单图标样式建议 不要输出 JSON 以外的任何内容。 def call_llm(user_content: str) - dict: headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { model: qwen2.5:3b, messages: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_content} ], temperature: 0.7, stream: False } resp requests.post(API_URL, headersheaders, jsonpayload, timeout30) resp.raise_for_status() data resp.json() content data[choices][0][message][content] # 模型可能返回带 json 代码块的内容这里做一次清洗 content content.strip() if content.startswith(): content content.replace(json, ).replace(, ).strip() return json.loads(content) app.route(/wardrobe, methods[POST]) def wardrobe(): body request.get_json(forceTrue) tag_data body.get(tagData, ) if not tag_data: return jsonify({error: tagData is required}), 400 try: # 把 NFC 读取到的文本解析成字典也可以直接传给 LLM user_content f用户请求{tag_data} outfit call_llm(user_content) return jsonify(outfit) except Exception as e: return jsonify({error: str(e)}), 500 app.route(/health, methods[GET]) def health(): return jsonify({status: ok}) if __name__ __main__: app.run(host0.0.0.0, port8000)这个服务的核心逻辑是/wardrobe接口接收 POST 请求请求体里带tagData。调用大模型让模型根据 Prompt 返回 JSON。清洗模型可能输出的 Markdown 代码块再转成 JSON 返回。如果异常返回 500 错误方便排查。这里的LLM_API_URL和LLM_API_KEY来自环境变量。如果你使用本地 Ollama则不需要复杂的鉴权如果你使用云端大模型服务就把 API 地址和密钥配置到环境变量中。这样不会把密钥提交到代码仓库。6.4 安全与边界不要接收任意格式的tagData直接拼进系统级命令。本文只把数据作为 Prompt 的文本不执行任何本地命令。给服务加超时和异常捕获防止模型无响应导致机器人卡死。生产环境建议加一层调用频率限制防止恶意请求耗尽 API 配额。使用自己的 NFC 标签和机器人调试不要扫描、复制或破解他人的门禁卡、公交卡这既可能涉及法律风险也不是本项目的目标。7. 端到端联调与效果验证7.1 联调步骤当 AI 服务、NFC 标签和 StackChan 程序都准备好后按下面顺序联调启动 AI 服务。验证服务健康检查接口。用 curl 模拟 POST 请求确认返回结果。给 ESP32 烧录读取 NFC 并转发请求的程序。将 NFC 标签放到读卡模块上观察串口日志和机器人屏幕。7.2 用 curl 验证 AI 服务在连接硬件之前先用 curl 验证服务是否正常curl -X POST http://127.0.0.1:8000/wardrobe \ -H Content-Type: application/json \ -d {tagData:{\item\:\hat\,\scene\:\party\,\color\:\red\}}预期返回类似下面的 JSON{ name: 红色派对礼帽, color: red, expression: happy, greeting: 欢迎来到派对, icon: hat_icon }只要模型返回了上述字段说明 AI 服务链路是通的。接着再测试硬件链路把标签放到 PN532 上如果 ESP32 串口打印出了标签数据并且屏幕上出现了新的装扮图标和问候语说明端到端联通。7.3 如何判断成功判断标准不必太严格。最核心的是ESP32 串口日志里能看到读取到的 NDEF 文本。AI 服务返回了结构正确的 JSON。StackChan 屏幕上显示了对应的表情或图标。换另一张不同内容的 NFC 标签机器人会呈现不同的装扮和状态。如果失败第一步不是改代码而是先分别验证硬件和 AI 服务。硬件有问题看串口AI 服务有问题看 Flask 控制台日志。7.4 性能优化提示如果模型响应比较慢比如超过 3 秒体验会明显下降。可以选择更小的模型或者在服务端增加简单的缓存相同tagData短时间内直接返回上一次结果。这样即使频繁刷同一张卡也不会每次都请求大模型。8. 常见问题与排查思路先整理一份高频问题表方便你在踩坑时对照问题现象可能原因排查方式解决方案PN532 模块检测不到I2C 接线错误或电源不足检查 SDA/SCL 是否正确连接尝试外接电源更换接线确认模块电压无法读取 NFC 标签 UID标签类型不兼容或天线位置不对确认标签是 ISO14443A 协议调整卡片贴近位置换 NTAG215 标签或检查天线线圈能读 UID但读不到 NDEF 数据标签写入格式不正确或readNDEF流程缺失用手机 NFC 工具查看标签内容重新格式化标签并写入标准 NDEF 文本AI 服务返回 500模型接口配置错误或 Prompt 输出非 JSON查看 Flask 日志中异常堆栈检查 API Key、模型名称、超时时间模型返回 JSON 但解析失败输出包含多余内容或 Markdown 代码块打印原始返回内容增加清洗逻辑强制模型只输出 JSON屏幕显示乱码服务端返回中文出现编码问题检查 HTTP 响应编码和 ESP32 字体库统一使用 UTF-8确认屏幕字体支持中文刷同一张卡结果不稳定大模型随机性查看每次返回内容是否不同降低 temperature增加缓存网络连接不上 AI 服务WiFi 配置错误或服务地址不可达在 ESP32 串口打印连接日志确认服务端 IP 和端口在同一局域网新手最容易犯的一个错误是把“读 UID”和“读数据”混为一谈以为看到 UID 就等于读到了标签内容。实际上UID 只是硬件序列号你写入的 JSON 必须通过 NDEF 读取流程才能拿到。如果只打印 UID就误以为读卡程序写完了后面所有解析都会失败。另一个常见问题是大模型返回的 JSON 不稳定。虽然 Prompt 里写了“必须使用 JSON 返回”但模型偶尔还是会输出解释文字。这也是为什么服务端要做一层代码块清洗和异常捕获。在生产环境中还可以增加一个 JSON 二次修复函数比如自动截断或补齐括号但这已经属于工程优化范畴了。9. 最佳实践与工程建议9.1 给 NFC 标签内容加密或签名没那么复杂如果你只在自己家里使用标签内容不用加密。如果项目要展示给更多人或者允许用户自带卡片那么建议给标签内容加一个简单的签名或校验字段防止用户写入奇怪内容触发服务端异常。最简单的方式是加一个固定前缀例如SC:1:hat:party:red服务端只接收以SC:1:开头的请求其他一律丢弃。9.2 Prompt 设计要稳定可迭代AI 匹配配饰的效果很大程度上取决于 Prompt。建议把 Prompt 独立成文件不要写死在代码里。这样调整 Prompt 时只需要改文件不需要重启整个服务也方便做版本管理。Prompt 里可以留一个“风格空间”。例如标签里只写style: cyberpunk模型就可以自由发挥生成更多样化的配饰方案如果标签里写死了hat:red模型就只在限定范围内补全表情和问候语。两种模式各有适用场景前者适合探索后者适合精确控制。9.3 控制 AI 调用成本大模型按 Token 计费时单次调用成本很低但如果频繁刷卡累计费用会上升。建议做两层控制服务端缓存相同tagData在 10 分钟内直接返回缓存。本地先做一次“规则匹配”比如hat:red直接命中本地配置只有未命中的请求才走大模型。这样既保证 AI 的生成能力又不会因为高频率刷卡产生不必要的费用。9.4 嵌入式端注意日志与看门狗ESP32 程序在网络请求失败时很容易进入阻塞状态。建议加超时机制并在主循环里做状态机管理只有检测到新卡时才发起请求其他时间保持等待。如果你发现机器人刷卡后界面卡死大概率是http.POST没有设置超时。9.5 安全和合规提醒最后必须强调几点这个项目只应使用你自己购买的 NFC 标签或者已经获得授权的卡片。不要在公共场合测试扫描他人随身携带的门禁卡、银行卡、身份证等 NFC 设备。不要尝试复制、篡改、破解门禁卡或其他受保护卡片这属于违法行为而且可能导致标签损坏。将 NFC 读卡模块和标签内容相关的能力当作一种“用户可控输入”服务端要校验数据格式避免异常内容进入 AI 或系统流程。NFC 本身是一项开放、成熟的技术但它的安全边界取决于使用者。做技术实验一定要守好自己的边界。10. 总结与后续学习方向这篇文章没有停留在“读 NFC”这一步而是把整个链路打通NFC 标签作为物理输入StackChan 作为终端交互设备AI 服务负责把简单请求扩展成完整的配饰方案。这套架构的真正价值在于它让“换装”从软件菜单变成了一个可触摸、可分享的实体操作。你可以先按文中的步骤做一个最简版本写两张不同内容的 NFC 标签让 AI 服务返回不同的装扮 JSON然后观察 StackChan 的屏幕和语音变化。有了这个基础后再逐步加入更多标签、更复杂的角色状态、本地规则缓存甚至接入语音对话让机器人不仅能通过 NFC 换装还能在换装后和你聊天。如果你对这个方向感兴趣下一步可以重点研究三块内容NDEF 的高级格式不只是文本还可以写 URL、自定义 MIME 类型。本地小模型部署用 Ollama 在电脑上跑一个小模型完全离线完成配饰生成。状态机与事件驱动让机器人根据 NFC 标签进入不同的状态模式而不是每次只执行一个动作。技术组合的乐趣常常不在单个技术本身而在它们被连接起来的那一刻。NFC 负责连接物理世界AI 负责连接想象空间StackChan 则站在中间把这两件事变成你能看到、听到、摸到的作品。希望能看到你做出更有意思的换装效果。