企业官网建设流程全解析

1. 项目初衷：让吃灰的板子不只是闪灯

手头这块 STM32F103C8T6 蓝色核心板，严格来说已经不是 2012 年的初代版本，但芯片型号和当年的老板子一模一样：Cortex-M3 内核、72MHz 主频、20KB RAM、64KB Flash。这些年它一直被压在工具盒最底层，偶尔拿出来点亮一个 LED，再刷个流水灯，然后就继续吃灰。直到最近大家都在聊 AI coding，我也跟着用 AI 生成过网页、写过 Python 脚本、拼过 SQL 查询，突然想起一个问题：AI 编程的边界到底在哪？它能不能驱动一块 2012 年的老板子，让它不只是闪灯，而是开口唱歌？

这个念头其实有点反直觉。大家提起 AI coding，默认就是写业务逻辑、搭网站、补注释，很少人会想到让它去操作寄存器、翻转 GPIO、配置定时器输出 PWM。但恰恰是嵌入式这种资源受限、时序敏感、很容易翻车的场景，最能检验一个 AI 编程工具到底是真的懂硬件，还是只会背模板。于是我给自己定了一个小目标：用 AI 辅助生成代码，让 STM32F103C8T6 通过 PWM 驱动一个无源蜂鸣器，播放《小星星》。整篇博文会从方案选型、环境准备、AI 代码生成、实测踩坑到问题排查，完整记录这个过程，如果你想复现，照着做就能听到声音。适合那些刚接触 AI coding、手里恰好有块老 STM32 板子，或者想试试“AI 写嵌入式代码靠不靠谱”的朋友。

先说结论：AI 确实能写这段代码，而且写得比我手写快得多，但中间有两三个坑，AI 第一次生成的版本直接没声，是人工 review 才救回来的。这个过程中，真正的难点不是“让 AI 写代码”，而是“怎么把需求描述得足够精确，以及怎么判断它写得对不对”。下面一点一点拆开讲。

2. 方案选型：为什么是 PWM 加无源蜂鸣器

2.1 三种“开口唱歌”的实现路线

要让开发板发出旋律，业内最常见的做法有三条路：PWM 驱动无源蜂鸣器、外接 DAC 播放 WAV 文件、用 I2S 接音频解码芯片播放高质量音乐。三条路都能响，但复杂度完全不是一个量级。

PWM 方案的核心思路是：用定时器产生一个固定频率的方波，频率决定了音高，控制这个方波的持续时间和间隔就形成了节奏。蜂鸣器只要是无源的，就会响应这个频率振动发出声音。这个方案对硬件要求极低，一块板子、一个蜂鸣器、两根杜邦线就够，而且它用到的是定时器、GPIO 复用、PWM 比较输出这三样嵌入式基础功能，非常适合作为 AI coding 的验证项目。

外接 DAC 播放 WAV 的路线要复杂不少。STM32F103C8T6 本身没有 DAC，需要外挂一个 SPI 接口的 DAC 芯片或模块，把 WAV 音频文件的采样点按采样率逐个送给 DAC，才能还原音频波形。这条路涉及 SPI 通信、DMA 传输、音频数据的存储组织，工程量大得多。

I2S 路线就更重了，一般要上 CS4344 之类的音频解码芯片，代码量会从几十行膨胀到几百行。如果我的目标是“让板子说话”，PWM 是性价比最高的选择。如果目标是“让板子成为能放无损音乐的播放器”，那才值得去碰 I2S。所以我最终选 PWM，因为它能把问题控制在“AI 能生成、我能 review、新手能复现”的范围内。

2.2 PWM 发声与音符频率的关系

很多人以为蜂鸣器像喇叭一样，给个高电平就会响。其实无源蜂鸣器内部没有振荡源，必须外部不断给它一个脉冲信号，它才会振动发声。脉冲的频率就是声音的基频，频率越高听起来音调也越高。

十二平均律是音乐里最常用的频率体系，相邻半音之间频率比值为 2 的 1/12 次方。基准音 A4 是 440Hz，那么其他音就可以用freq = 440 x 2^((n-69)/12)计算出来，n 是 MIDI 音符编号。不过实际写代码时没人会现场算这个，通常直接预置一张常用音符频率表：

表中 C4 表示中央 C，频率 262Hz，它正上方的高音 C5 是 523Hz，正好是翻倍的关系，这个规律在写定时器参数时可以直接利用。STM32F103C8T6 的定时器时钟来自 APB1，经过倍频后最高到 72MHz。要让定时器输出目标频率，需要做两步：先用预分频器把 72MHz 降到一个合适的计数基准频率，再设置自动重装载值，让计数周期正好等于目标频率的倒数。

以 1MHz 计数基准来算很简单：预分频系数设 71，则72MHz / 72 = 1MHz，这时候定时器从 0 数到 ARR 再归零，输出 PWM 的频率就是1MHz / (ARR + 1)。要发 262Hz 的 C4，ARR 就是1000000 / 262 - 1 ≈ 3815；要发 523Hz 的 C5，ARR 就是 1911。差值很大，所以每个音符都要重新设置 ARR 值，不能偷懒写死。

比较寄存器决定占空比，也就是方波高电平占一个周期的比例。占空比越低，蜂鸣器得到的有效能量越少，声音就越小声，但太高又容易让蜂鸣器饱和产生失真。实际听下来 50% 左右的占空比最清晰，这也是后面代码里把比较值设成 ARR 一半的原因。

3. 开发环境与 AI 工具准备

3.1 硬件接线与材料清单

这次涉及的硬件很简单，我列一下清单：STM32F103C8T6 核心板一块、无源蜂鸣器一个、面包板一块、杜邦线若干、ST-Link 下载器一个（USB-TTL 串口下载也可以，但老手都会建议备一个 ST-Link，调试方便太多）。注意蜂鸣器必须买无源的，也就是外观通常是黑色圆柱体、上面没有丝印标注“有源”的型号，用万用表电阻档去测，无源蜂鸣器测出来有一定电阻值，有源蜂鸣器通常测不出稳定电阻。

接线方面，我把蜂鸣器正极接 PA0，负极接 GND，中间串了一个 100 欧姆限流电阻。PA0 是 TIM2_CH1 的复用引脚，这样配置定时器输出 PWM 时不用改 IO 映射。虽然 GPIO 直接驱动小蜂鸣器也能响，但稳妥起见最好加一个 NPN 三极管和上拉电阻做驱动电路，因为 GPIO 的灌电流限制在 25mA 左右，直接驱动大音量蜂鸣器有隐患。不过对于《小星星》这种轻负载，串电阻直驱是没问题的。

3.2 工具链选择：标准外设库还是 HAL 库

代码风格我选择了 STM32 标准外设库（SPL），而不是 HAL 库。原因有三：第一，2012 年前后的老板子教程大多数基于标准外设库，网上现成的参考代码和讨论最多；第二，AI 训练语料里标准外设库的代码量非常大，生成结果会更贴近可用代码；第三，标准外设库是直接操作寄存器封装后的 API，逻辑链路更短，出问题时容易反向追踪。

编译环境用 Keil MDK5，选择 ARM Compiler 5 编译器。顺手在 Keil 的 Pack Installer 里装好 STM32F1 系列器件支持包，然后把芯片型号选成 STM32F103C8。这里有个容易忽略的点：如果电脑已经装了 Keil 默认的 AC6 编译器，部分老的标准外设库代码在 AC6 下会报一堆类型不匹配的警告甚至错误，直接改成 AC5 最省心。创建一个空工程后需要手动添加启动文件startup_stm32f10x_md.s，以及标准外设库里的stm32f10x_gpio.c、stm32f10x_tim.c、stm32f10x_rcc.c这几个源文件。

3.3 AI 辅助工具怎么选

我平时在 VS Code 里用 AI 编程插件，比如 Fitten Code、通义灵码这类对话式助手都可以，核心逻辑是先在对话窗口生成并迭代代码，再把确认过的代码复制到 Keil 工程里编译。为什么不直接在 Keil 里装 AI 插件？主要是 Keil 的插件生态不如 VS Code 丰富，而且在编辑器里管代码迁移更顺手。

还有一个很重要的习惯：让 AI 生成代码后，再让它为你逐行解释每段代码对应的寄存器级别操作。这个环节不是为了看它解释得多漂亮，而是为了检验它生成的内容是否和芯片手册一致。AI 在自然语言上很流畅，但涉及具体引脚映射、时钟使能、外设枚举值时经常一本正经地编造。如果它解释到RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE)时说得准确，那这一行代码大概率没问题；如果它含糊其辞说“使能了定时器时钟”，那就得回头查芯片手册了。

4. AI 生成播放代码的核心环节

4.1 需求描述必须精确到引脚级

同样的项目，不同写法给 AI，得到的代码质量天差地别。这是我试过的最无效 prompt：“写一个 STM32 蜂鸣器播放小星星的代码”。AI 会给你一个看起来很完整、但引脚和库函数全凭猜的版本，编译大概率过不了，甚至可能把 PA0 当成普通 GPIO 来拉高拉低，根本没有 PWM 波形。

有效的需求描述要遵循“芯片型号 + 外设资源 + 时钟来源 + 引脚映射 + 行为目标 + 输出格式”的结构。举个例子，我最终发给 AI 的 prompt 是这样的：

使用 STM32F103C8T6 和标准外设库，用 TIM2_CH1 的 PWM 模式驱动 PA0 引脚上的无源蜂鸣器，播放《小星星》前两行旋律。要求：TIM2 预分频系数 71，计数时钟 1MHz，每个音符通过改变 ARR 值改变频率，比较值设为 ARR 的一半；提供TIM2_PWM_Init初始化和Play_Note(uint16_t freq, uint16_t duration_ms)播放函数；音符频率用整型常量定义，避免浮点运算；旋律以二维数组{频率, 时长}的形式存放；请给出完整可编译的 main 函数，注释用中文。

这个 prompt 看起来啰嗦，但其实每一条都是必要的约束：预分频系数直接告诉它定时器参数，避免它自己瞎算；音符频率用整型常量是为了在嵌入式上避免浮点库开销；二维数组的结构是为了让后续修改歌曲内容时不用改逻辑代码。AI 拿到这些信息后生成的第一版就已经非常接近可用状态。这说明一个问题：AI coding 的能力上限，很大程度上取决于提问者描述需求的精确度。这和我们平时带新人写代码是一样的，需求说得越清楚，交付物质量越高。

4.2 第一次生成：代码能编译但没声音

AI 第一次生成的代码确实可以编译通过，烧录后蜂鸣器却一声不吭。我当时以为是蜂鸣器坏了，换一个还是不响，用万用表量 PA0 电压纹丝不动，这才意识到问题出在代码逻辑上。回看 AI 生成的代码，它把 PA0 初始化成了GPIO_Mode_Out_PP（普通推挽输出），然后通过不断调用GPIO_SetBits和GPIO_ResetBits制造方波。这个思路从原理上说得通，但普通 GPIO 翻转完全依赖 CPU 干预，而且翻转频率受循环里各种判断影响，达不到稳定输出。

正确做法是把 PA0 配成GPIO_Mode_AF_PP（复用推挽输出），由定时器硬件接管引脚输出。这其实是个很经典的嵌入式新手误区：觉得 GPIO 可以输出方波就足够了，忽略了 PWM 要靠外设生成而不是软件模拟。AI 之所以会这样写，大概率是因为它在生成时没有区分“普通 IO 翻转”和“定时器 PWM 输出”这两种完全不同的实现机制。把它生成代码里的 GPIO 初始化改成GPIO_Mode_AF_PP，同时把输出逻辑改为设置定时器比较寄存器，声音立刻就出来了。

这里强烈建议大家不要跳过 AI 生成代码的人工 review 环节，尤其是时钟使能部分。AI 生成的代码里曾经漏掉了RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO, ENABLE)，AFIO 时钟不使能，引脚复用功能就无法正常工作。对于新手来说，挨个对照参考手册去查每一句RCC配置是最好的一课。

4.3 完整可用的播放代码参考

经过人工修正后的最终版本，核心结构可以整理成三部分：定时器 PWM 初始化、音符频率设置、播放旋律。完整代码如下。

#include "stm32f10x.h" #define NOTE_C4 262 #define NOTE_D4 294 #define NOTE_E4 330 #define NOTE_F4 349 #define NOTE_G4 392 #define NOTE_A4 440 #define NOTE_B4 494 #define NOTE_C5 523 // 旋律：{音符频率, 时长毫秒}，0 表示休止符 const uint16_t score[][2] = { {NOTE_C4, 400}, {NOTE_C4, 400}, {NOTE_G4, 400}, {NOTE_G4, 400}, {NOTE_A4, 400}, {NOTE_A4, 400}, {NOTE_G4, 800}, {NOTE_F4, 400}, {NOTE_F4, 400}, {NOTE_E4, 400}, {NOTE_E4, 400}, {NOTE_D4, 400}, {NOTE_D4, 400}, {NOTE_C4, 800} }; void TIM2_PWM_Init(void) { GPIO_InitTypeDef gpio; TIM_TimeBaseInitTypeDef tim; TIM_OCInitTypeDef oc; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_AFIO, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE); gpio.GPIO_Pin = GPIO_Pin_0; gpio.GPIO_Mode = GPIO_Mode_AF_PP; gpio.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &gpio); tim.TIM_Prescaler = 71; tim.TIM_CounterMode = TIM_CounterMode_Up; tim.TIM_Period = 999; tim.TIM_ClockDivision = 0; TIM_TimeBaseInit(TIM2, &tim); oc.TIM_OCMode = TIM_OCMode_PWM1; oc.TIM_OutputState = TIM_OutputState_Enable; oc.TIM_Pulse = 500; oc.TIM_OCPolarity = TIM_OCPolarity_High; TIM_OC1Init(TIM2, &oc); TIM_OC1PreloadConfig(TIM2, TIM_OCPreload_Enable); TIM_Cmd(TIM2, ENABLE); } void Set_Freq(uint16_t freq) { if (freq == 0) { TIM_SetCompare1(TIM2, 0); return; } uint16_t arr = 1000000 / freq - 1; TIM_SetAutoreload(TIM2, arr); TIM_SetCompare1(TIM2, arr / 2); } void Delay_Ms(uint32_t ms) { for (uint32_t i = 0; i < ms; i++) { for (uint32_t j = 0; j < 7200; j++) { __NOP(); } } } int main(void) { TIM2_PWM_Init(); uint8_t i; uint16_t score_len = sizeof(score) / sizeof(score[0]); while (1) { for (i = 0; i < score_len; i++) { Set_Freq(score[i][0]); Delay_Ms(score[i][1]); } Delay_Ms(1000); } }

代码里的Set_Freq函数每次根据目标频率计算 ARR 值，这是整个程序最核心的换算：arr = 1000000 / freq - 1。要注意 ARR 是 16 位寄存器，最高能表示 65535，对应最低频率大约 15Hz，完全覆盖人耳能听到的 20Hz 到 20kHz 范围。TIM_SetCompare1设置为arr / 2即 50% 占空比，声音最清晰。休止符的处理方式是直接将比较值清零，这样 PWM 输出保持低电平，蜂鸣器自然不响。

Delay_Ms函数我用了一个简单的空循环累加，在 72MHz 主频下每个循环大约 1ms，这个精度对播放音乐来说完全够用。如果想更严谨，可以改成 SysTick 精确延时，但对于一个小玩具项目，空循环的可读性更强，而且不会被中断抢占导致节奏错乱。

4.4 人工检查清单：烧录前必须过一遍

AI 生成代码后，我建议在烧录前逐项检查下面几个点，这些都是 AI 在嵌入式代码上最容易出错的地方：

这六项检查看起来简单，但正是 AI coding 在嵌入式领域最需要人工介入的地方。大语言模型擅长的是从语料库中拼接出高度可能的代码序列，而嵌入式代码的关键恰好在于“当前这颗芯片的特定外设配置是否正确”，这是拼概率拼不出来的，得靠人对芯片手册的理解去兜底。我的建议是：不把 AI 当“自动写代码机”，而是当“结对编程的实习生”，它负责产出初稿，你负责指出错误并解释原因。这个流程走下来，AI 生成代码的质量会越调越好。

5. 实测记录：从无声到《小星星》

5.1 第一次上电：PA0 毫无反应

烧录后按下复位键，蜂鸣器一片寂静。我当时第一反应是蜂鸣器接反了，因为蜂鸣器有正负极之分，很多初学者的第一反应都是换方向。检查后发现接线没问题，于是用万用表量 PA0 对地电压，居然稳定在 0V，这说明代码根本没让定时器输出东西。再检查定时器状态寄存器和 GPIO 配置，发现 AI 生成的GPIO_InitStructure.GPIO_Mode选的是普通推挽输出而不是复用推挽，所以 PA0 被 GPIO 外设接管了，定时器输出信号过不去。改成GPIO_Mode_AF_PP后，万用表能测到 PA0 在 0 到 3.3V 之间跳动了，蜂鸣器立刻出声。

这个坑非常典型，很多从 Arduino 转过来的朋友会觉得“GPIO 翻转一下不就有了吗”，但 STM32 的 PWM 输出必须通过复用功能把外设信号连接到引脚上，这也是它比 Arduino 更底层、更需要看手册的地方。AI 在生成代码时很容易在这个环节偷懒，因为普通 GPIO 模式在代码里看起来更“直观”也是训练语料里最常见的写法。

5.2 节奏不对：短音和长音的区别

第一次听到声音后其实还不像《小星星》，更像一段持续嗡嗡的电子音，因为音符时长全部一样，没有长短音交替，听不出来旋律的起伏。播放音乐不光要控制音高，还要控制音长。乐谱里四分音符和二分音符的时值要区分开，尾音要适当延长。

我把旋律数组从{频率, 时长}压成{频率, 节拍}的表示方式，用节拍数乘以基础单位时长来计算。比如设置基础时长为 200ms，四分音符就是 400ms，二分音符就是 800ms。AI 生成的代码里，数组里的时长写的一律是 400，听起来完全没有层次。我在 prompt 里明确要求“用节拍数组”，并在数组里让NOTE_G4, 800表示二分音符，这才像模像样地听出了《小星星》的轮廓。

还遇到一个细节：整体的速度偏快。当时基础时长定成了 100ms，整首歌 15 秒放完，像是开了倍速。后来把基础时长调到 200ms，播放速度就自然多了。这个参数完全靠耳朵判断，没有绝对标准，音乐节奏的主观感受就是要自己反复试。

5.3 占空比与音量的关系

在调试音量的时候，我踩了一个别人常年的坑：以为占空比越大声音越大，于是把比较值设成了 ARR 的 90%，结果声音不仅没变大，反而变得沉闷刺耳。原因是蜂鸣器的发声原理是振膜的机械振动，占空比过大会让振膜在单个周期内因持续高电平而产生非线性失真。50% 占空比的方波信号最接近理想交变信号，振膜振动最充分，声音最清脆。如果想让音量变小，可以调低比较值，但不要试图调高到 90% 以上，输出效果反而会劣化。

另外一个容易忽略的点是电源稳定性。蜂鸣器发声瞬间电流会跳动，如果开发板用 USB 口供电且线材过细，声音会有明显劣化。我给板子换了一根粗的 USB 线，或者直接用 ST-Link 的 3.3V 供电，声音稳定性明显改善。遇到蜂鸣器发颤的情况，先查电源再查占空比。

6. 常见问题排查速查表

整个项目跑完后，我把过程中遇到和预判到的常见问题整理成了下面这张表，新手朋友可以直接对照排查。

这条表里最后两个问题最容易被忽视。数组越界在 C 语言里是典型的“编译能过但运行炸掉”问题，AI 生成代码时偶尔会把数组长度算错，或者用int8_t去遍历一个超过 127 个元素的数组。换成uint8_t并计算sizeof是稳妥做法。编译器版本问题则更隐蔽，老标准外设库代码在新编译器下会出现大量警告，虽然不一定导致功能错误，但会掩盖真正重要的报错信息，换用 AC5 后编译输出干净很多。

7. 项目扩展与 AI coding 的一点心得

7.1 从《小星星》到更多玩法

这个项目跑通之后，往上扩展的空间其实非常大。《小星星》只是单一音轨，如果想播放更丰富的旋律，可以把音符表扩展成真正 MIDI 编号数组，让 AI 生成任意一段乐谱数据；还可以加上“模式切换按键”，单击播放一首、双击播放另一首。更有趣的方向是给板子加上温度传感器，当温度超过阈值时播放一段警报旋律，这样它就从一个玩具变成了一个能“用声音反馈状态”的实用小设备。

如果想挑战更难的，可以让 AI 生成 I2S 驱动代码，配合一个便宜的音频解码芯片播放 WAV 文件，那就是从蜂鸣器音乐升级到真正的音频播放了。不过这个跨度比较大，建议先把 PWM 方案吃透，再去想 I2S。我在实际测试中还试过让 AI 同时控制两块板子，一块负责主旋律、一块负责和声，利用 USART 做同步信号，效果很有成就感，但这个项目需要两块开发板和更多调试时间，不太适合新手一次到位。

7.2 AI 写嵌入式代码与写业务代码的区别

用 AI 写嵌入式代码和写 Web 代码体验差别很明显。写 Web 或脚本时，AI 生成的代码即使有 bug，你只要跑一下测试就能立刻发现，迭代速度非常快。但嵌入式代码出了问题，往往是硬件不响应，而硬件不响应可能由引脚配错、时钟没开、外设没复位、编译器优化过头等十几个原因引起，排查链路长得多。这让“人工 review 前置”变得比代码生成更重要，也让我对 AI coding 有了新的理解：AI 真正的价值是大幅提高初稿质量和信息搜集速度，而不是替代工程师的判断。

用了几天 AI 辅助编写嵌入式代码后，我最大的收获反而不是代码本身，而是学会了如何把需求拆解成机器能理解的最小单元。之前写嵌入式代码，我习惯一边看手册一边试寄存器，现在我会先在脑子里想清楚：这个外设用什么引脚、什么时钟源、什么模式，然后把这些信息全部塞进 prompt。这样的思维方式迁移到任何领域都管用，需求的精确度决定了交付的质量。最终，这块 2012 年的老板子终于开口唱歌了，而我个人对这种“AI 生成加人工审查”的开发节奏也越来越得心应手，手上的老芯片也从吃灰板变成了随时可以拿出来验证新思路的试验台。

最后再分享一个小技巧：如果你也想在类似项目里用 AI 帮忙，完成第一版后一定马上问它一句话——“你用了哪些寄存器，能不能直接给我一份寄存器版本的代码？”这一问基本能暴露 AI 对底层细节的真实理解程度，也能帮你把这些最枯燥的硬件知识重新捡起来。我每次这么追问之后，再看手头的芯片手册，都觉得它们没那么难啃了。