小白用AI编程的真实经历：程序员会被取代吗？

引言：当零基础小白遇上AI编程

在AI工具遍地开花的今天，一个几乎没有编程基础的普通人，能否借助AI完成一个实际的硬件项目？B站UP主用亲身经历给出了一个既鼓舞人心又令人清醒的答案。

他的目标看似简单：用ESP32单片机做一个纳斯达克显示器，在美股开市时自动亮屏，休市时自动休眠。ESP32是由乐鑫科技（Espressif Systems）开发的一款低成本、低功耗的微控制器芯片，集成了Wi-Fi和蓝牙功能，在创客社区和物联网项目中极为流行。它价格低廉（通常不到30元人民币）、开发生态成熟，支持Arduino IDE和MicroPython等多种开发环境，拥有双核处理器、丰富的GPIO引脚和多种通信接口，既能驱动显示屏、传感器等外设，又能通过网络获取实时数据。对于这个纳斯达克显示器项目，ESP32需要通过Wi-Fi连接互联网获取股市数据，同时控制显示屏和蜂鸣器等硬件外设。

然而，这个"打几行字就能搞定"的项目，却变成了一场与多个AI工具反复拉锯的持久战。

一个项目，四个AI工具，一整天的折腾

豆包：起步即翻车

作者首先选择了豆包作为编程助手。豆包确实能教他如何连接ESP32的线路，也能生成代码，但问题出在代码质量上——复制到IDE中编译，直接报错。让豆包修改后，依然存在错误。这暴露了通用型AI在嵌入式开发领域的一个典型短板：它可能"知道"ESP32是什么，但对具体的硬件连接、引脚配置等细节缺乏精确把控。嵌入式开发不同于纯软件编程，它要求代码与特定硬件型号、固件版本、引脚定义严格匹配，任何一个细节偏差都会导致编译失败或运行异常。

Google AI：能跑但有Bug

转战Google AI后，情况有所改善——程序至少能运行了。但新的问题随之而来：蜂鸣器一直响个不停。作者反复将错误信息发给AI修改，改了很多次，问题依旧。这说明AI在处理硬件层面的调试时，往往陷入"头痛医头"的循环，无法从根本上定位问题。AI只能看到代码文本，无法"看到"实际的物理接线情况，因此它的修改建议始终局限在软件层面，而真正的问题可能出在硬件连接上。

ChatGPT：同样无解

抱着"换一棵树试试"的心态，作者又尝试了ChatGPT，结果同样不理想。至此，从接线到反复沟通修改，已经耗费了整整一天时间。作者感慨：如果自己会编程，可能早就搞定了。

Cursor：终于找到对的工具

转机出现在ChatGPT推荐的一款专业代码编写工具——Cursor上。Cursor是一款基于VS Code架构构建的AI原生代码编辑器，由Anysphere公司开发。与通用聊天AI不同，Cursor将大语言模型深度集成到代码编辑工作流中，能够感知整个项目的文件结构、依赖关系和上下文。它的核心优势在于：能够读取并理解当前项目中的所有代码文件，而不是仅仅处理用户粘贴的代码片段；它的修改建议以diff（差异对比）的形式呈现，用户可以逐行审查AI的改动；同时支持多种AI模型并针对代码生成场景进行了专门优化。

作者将之前有错误的代码发进去，这款工具立刻精准定位了问题的根源——蜂鸣器连接了5V电压，而正确的做法是连接3.3V，否则一开机就会持续鸣叫。

这个诊断涉及一个关键的嵌入式开发知识点：ESP32的GPIO引脚工作电压为3.3V，数字输出高电平为3.3V，输入引脚也只能承受3.3V的信号。当蜂鸣器直接连接到5V电源时，如果是有源蜂鸣器（内置振荡电路），只要通电就会持续发声，无法通过ESP32的GPIO进行控制。正确的做法是将蜂鸣器连接到3.3V或通过GPIO引脚供电，这样ESP32才能通过高低电平切换来控制蜂鸣器的开关。这类电压匹配问题在嵌入式开发中极为常见，也是纯软件AI难以诊断的典型硬件问题——因为从代码逻辑上看一切正确，问题出在物理接线层面。

这个诊断结果让人眼前一亮。之前三个通用AI都没能发现的硬件连接问题，专业工具一眼就看出来了。按照它的建议重新接线后，蜂鸣器问题果然解决了。后续的WiFi代码优化也逐一完成，效率远超之前使用的所有AI。

不过，这款工具的免费额度很快用光，而且是每周刷新一次而非每天，这迫使作者不得不回到效率较低的Google AI继续开发。

AI编程最大的坑：悄悄删掉你的功能

在整个开发过程中，作者发现了一个比报错更棘手的问题：AI在帮你添加新功能时，会悄悄删除或简化已有的功能。

比如，WiFi登录页面已经做好了，当要求AI增加其他功能时，它会在添加新代码的同时，把原来正常运行的功能模块删掉或改坏。这意味着每一版代码都需要完整测试，确认所有旧功能是否还在正常工作。

这个问题有其深层的技术原因。当前大语言模型生成代码时存在一个结构性问题：它们的注意力窗口（Context Window）虽然在不断扩大（从最初的4K token到如今的100K甚至更多），但在生成长文本时仍然倾向于产生"连贯"的新输出，而非精确地在已有代码中做最小化修改。这与模型的训练方式有关——它们被训练为生成完整的、自洽的文本序列，而不是执行精确的文本编辑操作。在专业开发中，程序员使用Git等版本控制系统来追踪每一行代码的变更历史，任何修改都以"增量补丁"（patch）的形式存在，可以精确回溯和撤销。而通用AI缺乏这种增量思维，每次回复都倾向于输出一个"完整版本"，在这个过程中容易遗漏或简化之前的功能模块。

作者不得不采取一个"笨办法"：每一版OK的代码都用Word文档保存下来。当AI把代码改废了、无法修复时，就从之前存储的旧版本中取出代码，让AI在旧代码基础上重新修改。虽然这个方法看起来原始，但它本质上就是一种手动版本控制——专业程序员用Git做的事情，作者用Word文档实现了同样的目的。

这个问题反映了当前AI编程的一个核心局限——缺乏全局代码管理意识。AI每次修改都倾向于"重写"而非"增量修改"，它不会像经验丰富的程序员那样，小心翼翼地只动需要改的部分，同时确保其他模块不受影响。这也是为什么Cursor等专业工具采用diff模式展示修改——它通过工具层面的设计，强制AI以增量方式工作，让用户能清楚看到哪些行被添加、哪些行被删除。

从这次经历看AI编程的能力边界

AI编程能做什么

• 降低编程门槛：零基础的人确实可以借助AI完成一个实际项目
• 加速简单任务：生成基础代码框架、解释错误信息、优化局部代码
• 专业工具优于通用AI：针对编程场景优化的工具（如Cursor），效果远好于通用对话AI。这种差距的根源在于专业工具拥有完整的项目上下文感知能力，而通用AI只能基于对话中粘贴的代码片段进行推理

AI编程还做不好什么

• 硬件调试：涉及物理连接、电压匹配等问题时，通用AI容易"纸上谈兵"。AI无法"看到"实际的电路连接，它的所有推理都基于文本描述，而硬件问题往往需要万用表测量、示波器观察等物理手段才能确诊
• 代码完整性维护：添加新功能时破坏旧功能，是当前AI编程最危险的陷阱。在软件工程中，这类问题被称为"回归缺陷"（Regression Bug），专业团队通过自动化测试套件来防范，但AI目前还不会主动为已有功能编写和运行测试
• 复杂问题的根因分析：面对反复出现的同类错误，AI容易陷入无效循环。它缺乏"退一步思考"的能力，不会质疑问题的前提假设（比如"也许问题根本不在代码里，而在硬件接线上"）

程序员会被AI取代吗？

作者给出了一个很有意思的判断：程序员会被AI取代，但不是今年，可能是明年或后年。

这个判断既乐观又务实。从这次经历来看，AI编程工具的进化速度确实惊人——从豆包的"编译就报错"到Cursor的"一眼定位硬件问题"，能力差距已经非常明显。但目前AI仍然需要人来做"质量把关"和"版本管理"，这恰恰是程序员最核心的能力之一。

更准确地说，AI不会取代程序员，而是会重新定义程序员的工作内容。未来的程序员可能不再需要逐行写代码，但需要具备架构设计、代码审查、系统集成和调试的能力——这些正是当前AI最薄弱的环节。历史上，每一次开发工具的进化（从汇编语言到高级语言，从手写代码到可视化开发），都没有消灭程序员，而是将他们的工作推向更高层次的抽象。AI编程工具很可能延续这一趋势。

给想用AI编程的小白几点实用建议

1. 选对工具：专业的AI编程工具（如Cursor）效果远好于通用聊天AI。其他值得关注的专业工具还包括GitHub Copilot、Windsurf等，它们都针对代码编辑场景做了深度优化
2. 做好版本管理：每一版能正常运行的代码都要保存备份。如果愿意多学一步，可以了解Git的基本用法（init、add、commit），它比Word文档更专业、更可靠
3. 逐步迭代：不要一次性提太多需求，每次只改一个功能点。这样即使AI改出了问题，也能快速定位是哪个改动引入的Bug
4. 学会验证：AI给的每一版代码都要完整测试，特别关注旧功能是否被破坏。可以建立一个简单的测试清单，每次修改后逐项检查
5. 理解基础原理：即使不会写代码，也要了解基本的硬件知识和编程逻辑，这样才能更高效地与AI沟通。对于ESP32项目，至少要了解GPIO、电压电平、串口通信等基本概念，这些知识能帮助你更准确地向AI描述问题

核心要点