AI 辅助编程的“幻觉”与现实：一场失败的结对编程实验

引言：当内向开发者遇上 AI 助手

在软件开发的世界里，程序员通常被分为两类：一类是热衷于分享新库、喜欢与人碰撞思维的“社交型”开发者；另一类则是更倾向于独自钻研、在脑海中反复推演逻辑的“独行侠”。对于后者来说，管理层推行的“结对编程”（Pair Programming）往往是一场社交噩梦——两个人共享一台电脑和键盘，理论上产出翻倍，实际上却常让其中一方感到精疲力竭。

随着大语言模型（LLM）的崛起，一种新的可能性出现了：如果把人类搭档换成 AI 聊天机器人，是否既能享受结对编程的效率，又能逃避尴尬的社交负担？为了验证这一设想，经验丰富的嵌入式开发者 Maya Posch 进行了一场针对 GitHub Copilot 的深度测试。

实验设定：硬核挑战与高期望

为了不给 AI “放水”，本次测试选择了两个专业性极强的领域：

1. 基于 STM32 和 CMSIS 的嵌入式 C++ 开发：这需要对寄存器级操作和硬件手册有极深入的理解。
2. Ada 语言网络开发：这是一种相对小众但对安全性要求极高的编程语言。

测试者的初衷并非寻求代码代写，而是希望 AI 能像 StackOverflow 或 IRC 上的技术大牛一样，提供准确的参考建议或半成品代码，以便通过文档进一步验证。

现实的暴击：从服务崩溃到“答非所问”

实验的第一步就遭遇了尴尬的开场：当测试者试图在浏览器中使用 Copilot 时，GitHub 恰好发生了服务中断。正如作者所言：“人类搭档通常不会在工作进行到一半时突然‘宕机’，如果真的发生了，那是医疗紧急情况。”

当服务恢复后，真正的技术挑战开始了。测试者询问如何使用 CMSIS 标准头文件设置 STM32F411 芯片的最高时钟频率。这是一个非常具体的任务，涉及电源控制寄存器（PWR_CR）中的电压缩放（VOS）设置。

1. 自动忽略约束条件

尽管明确要求使用 CMSIS，Copilot 却固执地吐出了大量 ST HAL 库的代码。HAL 库虽然易用，但对于追求轻量化和底层控制的 CMSIS 开发者来说，这无异于南辕北辙。

2. 代码幻觉与逻辑灾难

当被要求纠正错误并提供真正的 CMSIS 版本时，AI 的表现更令人崩溃：它生成的代码不仅没有使用标准的宏定义，反而手动复制了大量的结构体定义，导致代码极度臃肿。更致命的是，它伪造了一个根本不存在的宏 PWR_CR_VOS_SCALE1。这种“一本正经地胡说八道”在底层硬件开发中是极其危险的，可能导致设备运行异常甚至损坏。

深度思考：工具之过还是用者之过？

这场失败的实验引发了社区的激烈讨论。在 Hackaday 的评论区中，不少开发者指出，实验失败的部分原因可能在于模型选择和提示词工程（Prompt Engineering）：

• 模型等级：作者使用的是 Claude Haiku，这在 Claude 系列中属于入门级模型，其推理能力远逊于 Claude Opus 或 GPT-4/5。对于复杂的嵌入式逻辑，入门级模型显然力不从心。
• 上下文缺失：AI 并不是魔法盒。如果没有提供具体的数据手册（Datasheet）或项目规范文件，它只能基于概率预测“看起来像代码”的文本，而非“能运行”的代码。
• 结对编程的本质：真正的结对编程是关于“对话”和“测试驱动”的。如果只是把 AI 当作搜索引擎，它往往会为了完成任务而强行生成结果，从而产生“代码垃圾”。

警惕“认知投降”

实验者 Maya 最终选择了重回传统方式：查阅手册、在搜索引擎中筛选信息。她表达了一个深层次的担忧——认知投降（Cognitive Surrender）。如果我们习惯了接受 AI 生成的“大概正确”的代码，人类的批判性思维和深层问题解决能力是否会逐渐退化？

对于经验丰富的开发者来说，检查 AI 错误的时间往往比从零开始写代码还要长。而在学习阶段的初学者，如果过度依赖 AI 解决课业问题，可能会失去构建底层逻辑感知的机会。

结语：AI 是辅助，而非替代

AI 辅助编程无疑具有潜力，尤其是在处理常见的样板代码（Boilerplate code）或主流框架（如 React, Python）时。然而，在嵌入式开发等容错率极低的领域，它目前的表现更像是一个“自信的实习生”：手脚很快，但随时可能在关键环节出错。

对于程序员来说，与其期待 AI 成为全能的搭档，不如将其视为一个高级的、需要时刻监控的“脚本生成器”。保持怀疑，坚持验证，才是与 AI 共存的正确姿势。

正如一位评论者所言：“AI 可以帮你写出 1000 页的技术书，但它不会帮你赢得奖项。真正的架构和灵魂，依然掌握在人类手中。”