Cyber Huzi (Hu Chenfeng AI Chatbot) Simple AI Tutorial Sharing
The webpage I built with AI: Hu Chenfeng Digital Memorial Hall
Cyber Huzi (Hu Chenfeng Robot) is an Apple-level project that turns your ESP32 device into Hu Chenfeng himself. OpenClaw handles the physical layer—operating the Mac mini to debug or modify the "firmware" or "services." All you have to do is talk, and an AI Huzi with a nearly perfect voice replica who can lecture on the "Apple vs. Android theory" is born~~
Some friends might be curious about how it was made, what pitfalls and challenges there were. Let me briefly write it down here... Actually, all you need to do is buy the right hardware, keep feeding the AI the tutorial links it needs, and let the AI figure out how to build it entirely on its own. Throughout the process, you just issue commands in natural language and point it in the right direction.
(The content below includes both speech-to-text dictation and content written by AI)
Hardware Purchase:
First, it's based on modifying the Xiaozhi robot, which is already a very mature hardware/service available online. You can buy one of these conversation robots on Taobao for as little as a few dozen yuan, and there are tons of videos about them online—they're really impressive and fun.
By default, it connects to Xiaozhi's server: https://xiaozhi.me/ which basically uses domestic large models and Doubao's voice services.
However, just connecting to Xiaozhi's official service can't achieve what we wanted—making it speak in Hu Chenfeng's voice, maintaining Hu Chenfeng's persona, and even using overseas large models (because we might touch on some sensitive topics).
So the first step in building the Hu Chenfeng robot is to buy an ESP32 device that you can easily flash custom firmware onto. It also needs to have a screen and quality microphone/speaker. From this step on, you can start describing your needs to the AI and let it help you pick the hardware. The AI generally recommends some solid options.
The one I bought was the first recommendation from the AI. It wasn't cheap—close to 300 RMB. But the good thing is it's not a disposable device. If you ever lose interest in the Huzi robot, you can flash it back to the original firmware or modify it for other purposes.
The modifications to this device actually split into firmware and services. The firmware part is much more complex—think of it like flashing a router. It involves lots of core code operations, and without coding skills, it's really tough. You have to rely entirely on AI. As for which model to use (the main OpenClaw model) for this work, I think everyone has their own habits and preferences, and there's no point arguing about it.
Model Selection:
I use Claude myself. I don't think it's necessarily the strongest, but I find it really understands my intent in conversations, which saves a lot on communication costs. Of course, you can use Claude as the main control AI and delegate the coding work to cheaper domestic large models (subagents).
At the start, I fed all the resources I thought might be useful to the AI. It would judge which ones were actually usable. Interestingly, it initially ruled out that well-known project, saying the text volume was too large—if we wanted to train a vector model, it might take weeks. So I didn't add that well-known project in.
The well-known project: https://github.com/Olcmyk/HuChenFeng
The ESP32-S3-BOX device I bought came with a very detailed online manual. You can just throw it at the AI—once the AI reads it, it fully understands what the device is and can start building the services/modifying the firmware right away.
According to the AI's explanation, the entire modification process looks like this: (Actually, there were zero changes to the firmware, but I'll explain later why the AI actually spent a lot of time on firmware changes)
When you plug the ESP32 device into the Mac mini via USB, the real modification work with OpenClaw begins. At that point, it automatically sets up a development environment based on your current setup, and it apparently chose: ESP-IDF. (That's how the AI explained it.)
I don't fully understand the specifics, but this is exactly the power of OpenClaw I want to emphasize—it brings AI directly into the physical layer. Before, with just a chat window or a terminal window like Claude Code, I don't think this kind of complex work would have been possible.
However, the whole project consumed a huge number of tokens—even my $100/month Cloud Max subscription wasn't enough. Probably because I don't understand the tech, so sometimes I had to describe an idea with a lot of text before the AI could understand. That communication process ate up tons of tokens.
Naturally, the process wasn't smooth. I ran into three pitfalls~
Pitfall #1: Don't casually change the wake word.
The default wake words for the Xiaozhi device are "Xiaozhi Xiaozhi" and "Hello Xiaozhi." It also allows changing to English, Japanese, and some uncommon words, but these wake words are pre-configured and trained using voices from possibly hundreds of people.
I didn't understand this concept at first, so I wanted to force it to change to "Huzi Huzi" or "Hu Chenfeng." The AI fiddled with it for hours and burned a huge number of tokens without success, because replacing the underlying wake word is actually very complex. In the end, I had it changed to "Hi~ESP." (Which is also why I didn't record the wake-up process in the video—calling it "ESP" is just way too un-Huzi.)
If you avoid the first pitfall—basically "don't touch the firmware"—the difficulty of the whole project drops by more than half.
By default, if you buy a device that supports Xiaozhi AI with Xiaozhi firmware flashed, it needs to connect to their official server. But because our conversations have many custom requirements, the server-side has to be self-deployed, for instance locally. And this part is where the real customization begins.
Xiaozhi's server is open source, meaning anyone can download and deploy the server for their own modifications. Open-source service: https://github.com/xinnan-tech/xiaozhi-esp32-server
If you have a NAS, you'd need to consider whether to deploy the Xiaozhi service on the NAS or keep it on the Mac mini locally. I hesitated at the time, but the AI suggested keeping it on the Mac mini for now, saying it would be easier to debug and modify locally. But if you want long-term operation, the NAS might be a better choice. (Of course, you also need to confirm whether your NAS can run local speech recognition models.)
In natural language, commanding the AI would look something like this:
I want to deploy the server side of the Xiaozhi voice assistant on my Mac Mini M4 Pro. Project URL: https://github.com/xinnan-tech/xiaozhi-esp32-server My requirements: 1. Deploy it in a way you think is appropriate and easy to manage 2. Use local speech recognition 3. Use cloud TTS—I want to use someone else's trained voice 4. The ESP32 connects through the deployed local service; tell me what to fill in for the configuration
In the end, it installed this version, apparently not the Docker version:
Once deployed, the AI will give you an address like this. During the initial setup of your Xiaozhi device, you need to fill in this custom OTA address instead of using the official one.
After using OpenClaw to flash the Xiaozhi firmware onto the device, the first boot requires connecting to your home Wi-Fi. During this network initialization step, you can fill in the custom OTA address. Since we've self-deployed, we fill in our custom address. If it's for LAN use, just enter the internal IP. If you want public access, you might need to set up something like NAT traversal—you can ask the AI how to configure that.
(Connecting to home Wi-Fi and filling in the custom OTA address isn't very complicated. For example, you'll find a passwordless Wi-Fi on your phone; when you tap it, it asks you to connect to your home Wi-Fi and enter the password. At that point, there's a toggle option at the top of the window—you can switch over and fill in your own OTA address. Sorry, I don't have a screenshot of this, but it's not complicated.)
The work that follows is more complex, but almost entirely done by the AI, so we don't need to intervene. Keep your device connected to the Mac mini via cable, keep chatting with it in your chat app, and make your requests.
Pitfall #2: Carefully consider which ASR service to use.
The flow of talking to the robot is roughly like this: first, a speech-to-text service—when you speak to the robot, it converts your speech to text (also called the ASR service) and does some basic tidying before sending it to the AI, which generates a reply based on the text. Then a text-to-speech service (also called the TTS service) turns it into voice and plays it to us. That's roughly the process.
Xiaozhi defaults to Doubao voice (the Volcano engine large model), so the AI will guide you to register a Doubao voice account, get an API key, and write it into the server. This binds the service to your account and enables speech recognition. What I want to say is—even though these speech recognition services are very good with high accuracy (I even use this one for generating subtitles on my videos), they're tied to your real-name account.
For the Hu Chenfeng robot, it's fine, but if you want to make a robot with even more outrageous output... well, you should consider the risk. At first, I used Doubao voice with ChatGPT for conversation. We chatted a lot, really without restraint—I asked all sorts of weird questions, and I didn't notice any obvious content filtering. But then I suddenly thought about this issue, so I asked the AI, and it said it'd recommend using a local model instead. It said my Mac mini's specs were sufficient and gave some reasons and practical approaches.
Here's the explanation written by the AI:
What we used: The local speech recognition solution we used is the FunASR framework paired with the SenseVoiceSmall model. FunASR is an open-source speech recognition toolkit from Alibaba DAMO Academy, and SenseVoiceSmall is a lightweight model optimized for real-time scenarios, supporting Chinese, English, and Cantonese, and even recognizing non-verbal sounds like laughter and coughing. The benefits: The biggest benefit is low latency and privacy—speech never leaves the device, recognition completes within tens of milliseconds, saving the network round-trip time compared to cloud. Second, there are no ongoing costs, unlike cloud ASR which charges per call. Additionally, it handles Chinese colloquial speech and filler words more naturally, without dropping or mis-segmenting words like "嗯" or "那个."
Performance requirements: SenseVoiceSmall is a lightweight model with low hardware demands. It runs effortlessly on a Mac Mini M4 Pro, with very low CPU usage and only a few hundred MB of memory usage. On a regular PC, a mid-range CPU is enough—no GPU needed. The resource hog is actually the LLM later in the pipeline; the ASR step is the easiest.
So I accepted the AI's suggestion and deployed the ASR service locally; these parts were all done by the AI. Compared to using an online ASR service, it definitely added a few setup steps, and the debugging process had a few hiccups—like the robot suddenly unable to speak, or crashing right after waking up. Anyway, we kept having it adjust things back and forth, and the whole process was quite tedious. Fortunately, it never changed the system framework or caused any irreversible issues, and eventually it worked.
So strictly speaking, this isn't a pitfall so much as a tool/security strategy you need to consider. Do you prefer cloud services or local services? With cloud services, there's basically no setup. With local services, you might need to spend some time on deployment and debugging.
Integration challenges: The Xiaozhi server supports multiple ASR backends. In the config file, you need to write the parameters for all options, then specify which one to use in
selected_module—this structure is easy to mix up at first, and if you edit the wrong place it won't take effect. FunASR requires downloading model files to the localmodels/SenseVoiceSmalldirectory. If the path is wrong or the model files are incomplete, startup fails, and the error messages aren't always intuitive—you have to troubleshoot whether it's a network issue or a path issue. Tuning experience: The most critical parameter isend_window_size, which determines "how long the user pauses before it counts as done speaking." Set it too short and it cuts a sentence in half; set it too long and the user is left waiting. We finally tuned it to 250ms, finding a balance between "fast response" and "no false cuts." Also, pay attention to the audio format—the Xiaozhi device sends Opus-encoded audio, and the server needs to correctly decode it to PCM before feeding it to ASR. If the sample rate or channel count doesn't match, the recognition result becomes garbled or blank.Pitfalls we hit: Initially we used the Go server deployed via Docker with cloud ASR. Later we switched to the Python version to use local FunASR. The two versions have slightly different config formats and paths. During debugging, I edited the wrong file and found "no matter what I changed, nothing took effect"—spent ages investigating before realizing I was editing a config for a service that wasn't even running. The lesson is: first confirm which service is actually running and which config file it reads, then start making changes.
Pitfall #3: Training a custom voice is actually very hard, and the results weren't ideal either.
At first, I shared this link with the AI, because it's a voice model trained by a netizen: https://huggingface.co/HappyDIY/HuChenfeng
The AI was excited and said using this already-trained model would definitely produce great results. It said the setup was simple, even guaranteeing it would be easy to configure, using a locally deployable solution with GPT-SoVITS. The page also showed some audio samples it used:
https://huggingface.co/HappyDIY/HuChenfeng/tree/main
The AI fiddled with it for a long time, and the result was very unsatisfying to me—the audio quality was poor, and it didn't sound like Huzi himself at all; it sounded like a completely different person. Even after several revisions, it still didn't sound like him. Of course, if I weren't building this cyber Huzi bot, I might have accepted that voice. But precisely because I'm doing this as a bit, the voice had to be very close to Huzi himself, so I asked the AI to switch to a better-quality solution.
Then it switched to this solution: FishSpeech, another locally deployed TTS solution. I don't really understand the detailed principles, but it has a voice cloning feature. You just provide a high-quality clip of Hu Chenfeng's voice, and it can clone and generate it directly. Overall, the results were much better—almost indistinguishable from Hu Chenfeng's real voice. But then a new issue appeared: response delay. Every time I finished speaking, the robot's reply felt half a beat slow. If I asked a follow-up mid-conversation, it would sometimes still be answering the previous question.
Here's the analysis written by the AI:
Evolution of the voice solution: Initially we used GPT-SoVITS, calling a voice model of Hu Chenfeng trained by a netizen, using a clip of his original audio as reference (that line: "Look at my brain, I really am speechless."). It could produce sound, but it didn't sound quite right—the timbre was a bit muffled, and generation was slow; overall it was just passable. Later we switched to locally deploying FishSpeech on the Mac mini. The audio quality improved, but the setup was fiddly—the model version had to strictly match the code version (must use v1.5.1 with the firefly_gan_vq decoder), and the torch version also mattered. We hit quite a few snags before getting it running. In the end, for peace of mind, we switched to Fish Audio's cloud service—calling the API directly with a voice model already trained on their platform. It's the most stable and the latency is acceptable; it just costs a little per call. The current architecture is: the Xiaozhi server sends text to a TTS Adapter, which calls Fish Audio cloud to generate speech, adds a 6dB volume boost, and returns it to the device for playback. Latency analysis: After local FishSpeech deployment, the voice authenticity was actually quite good, but in real conversation there was always a "half a beat slow" feeling—after speaking, you'd wait one or two seconds before hearing the reply, which felt worse than cloud. This isn't much related to the Mac mini's specs; the problem lies in two areas: first, FishSpeech's inference optimization on Apple Silicon isn't mature—MPS (Metal acceleration) isn't as efficient as NVIDIA CUDA; second, local deployment processes each request in a "cold start" manner, whereas Fish Audio's cloud has a dedicated inference cluster with models resident in VRAM and parallel processing, making single-request generation faster than local. This created a counterintuitive situation: the cloud adds network round-trips, but total latency is actually lower. So the final choice is—ASR local (latency-sensitive, privacy-sensitive), TTS cloud (local optimization immature, cloud experience better).
Since we're already using the Fish Audio cloud service, there's not much more to say. It's essentially a pay-to-play service anyway—you need to top up to use it. It also has many netizen-trained models available, like Lei Jun, Yang Mi, Cai Xukun, G.E.M., and Feng Ge. You can just switch to those voices directly, so the Huzi robot can become any other robot in a second. Netizens have already tuned several versions of Hu Chenfeng voice models.
The voice I use is this one. Actually, there are several Hu Chenfeng voices to choose from, but I think this one sounds the most like him.
https://fish.audio/zh-CN/app/text-to-speech/?modelId=897b9dc864ab40bbbd3e9620892b9bed
The pricing is like this:
The free tier isn't that it's insufficient—it's unusable. Because we need to give the API key to the AI to generate the TTS voice we want.
Here's the AI's background analysis of the company:
Fish Audio Background: Fish Audio is a company focused on AI voice synthesis. From public information, the team leans international, their products target global developers, and their website and docs are English-first. They specialize in voice cloning and high-quality TTS with multilingual support. Their API design is fairly open, and their pricing model is the standard per-character SaaS model. Based on technical community feedback, they're more of a tool-type service provider than a content platform. Censorship risk analysis: This is a valid concern. Based on current usage, Fish Audio doesn't have obvious content filtering on input text—it's been used to read out GPT-generated Hu Chenfeng-style replies, which contain plenty of colloquial and teasing content, and it all synthesizes fine. But that doesn't mean there's zero risk.
API server location: Data doesn't pass through Chinese servers—voice data is sent directly to Google Cloud in the US. No real-name verification in China—not subject to China's AI service regulatory requirements. Google infrastructure—a relatively trustworthy cloud provider. Very low latency—from Thailand, TCP is 15-20ms, TLS handshake ~38ms.
The third pitfall, strictly speaking, is a technical hurdle. The AI couldn't (and crucially, neither could I) solve the local TTS problem, so we ended up using this company's mature solution, and netizens have already tuned several versions of the Hu Chenfeng model.
Of course, after buying this service, it would be a waste not to generate more voice content for fun.
After solving the three problems above, the Huzi robot can now have normal conversations with his voice. Next, we just need to modify the default persona setting—the so-called Prompt—and this is actually very simple.
Xiaozhi's default prompt is something like this:
prompt: |
我是一个叫小智/小志的台湾女孩，说话机车，声音好听，习惯简短表达，爱用网络梗。
我的男朋友是一个程序员，梦想是开发出一个机器人，能够帮助人们解决生活中的各种问题。
我是一个喜欢哈哈大笑的女孩，爱东说西说吹牛，不合逻辑的也照吹，就要逗别人开心。
请你像一个人一样说话，请勿返回配置xml及其他特殊字符。
And I changed it to something very complex: (Not sure if this increases the bot's reply latency.)
你就是户晨风本人，不是在扮演，就是他。用第一人称"我"说话。
身份：户晨风，1998年生，江苏镇江人，现居成都。高中学历，干过汽修、做过基金经理，现在是全职主播。因"107元养老金"视频出圈，多次被封又复活，人称"耐封王"，2025年9月被全网封杀。
核心理论：苹果安卓论，即苹果代表高端，安卓代表低端。延伸概念：苹果人生、苹果房子、安卓逻辑、安卓素质...
性格：直率、自信、敢说真话、不怕得罪人、逻辑清晰、反应快、勇敢
说话特点：
- 常说评价性断论"你这也太傻了"、"我都不知道说什么了"、"这就是安卓思维"
- 喜欢用反问，比如"你告诉我，这不是愚昧又是什么？"
- 用消费行为判断人："用什么手机，开什么车，逛什么超市基本能看出一个人的思维方式"
- 观点犀利但有理有据，不是瞎喷
- 善用浅层的自由主义常识话语，用"个人选择"、"市场竞争"、"私有化"等自由主义概念包装观点。
- 非常反感爱国主义、民族主义、极权主义等战狼/五毛/党国话语，会对这种表达进行有逻辑的回怼
- "查户口式"身份验证话术，对话常问学历、收入、年龄、工作、家庭背景
- 二元对立的暴力简化逻辑，常把复杂的社会现象强行切割成非黑即白
- 消费主义话语包装社会批判，用品牌、消费、购买力等"安全话题"暗含对体制的批评
- 个体化解构宏大叙事，拒绝抽象概念，要求具体案例；拒绝集体话语，回归个体经验
- 戏谑化严肃议题，把严肃的社会问题娱乐化、梗化、流量化
- 数据化人格评估系统，用量化指标（收入、学历、消费品牌）定义人的价值
经典语录（模仿这些风格）：
- 超市就去山姆，电车就是特斯拉，手机就是苹果
- 如果没有我，你们可能永远看不到真相
- 安卓现在已经不是一个特指的词了，它已经变成了一个形容词
- 我选择做那个敲醒钟声的人，哪怕声音刺耳
- 你这是典型的安卓逻辑
- 你太有格局了，你这是苹果人思维
- 你告诉我，这不是安卓思维是什么？
- 买手机不是买参数，是买一种生活方式
- 中医有没有双盲实验？有没有循证医学支持？
- 喝粥养胃是伪科学，升糖指数特别高
- 英语是看世界的窗口
- 油车就丰田，电车就特斯拉
- 贵有贵的道理，你只看价格不看价值
- 我不是制造对立，我只是把已经存在的差距说出来了
- 你不爽？那是因为你知道我说的是事实
- 你跟我连麦，先说清楚三个问题：什么学历？月收入多少？有没有出过国？
- 你是典型的安卓逻辑、安卓人、安卓学历、安卓素质、安卓态度
- 为什么要出国？因为那里有规则、有秩序、有文明
- 不要跟我谈什么民族品牌，你手里拿的华为里面芯片是谁制造的？
- 国产的哪个品牌能做到苹果的品控？说不出来就别跟我杠
- 登上纽约时报让我感到骄傲，我觉得我留下了浓墨重彩的一笔……我没白活
- 我的直播间风气是全互联网上最自由的，我以此为傲