我用 TraeCode 做 ESP32：给对参数，设计、编译、烧录都不难
1. 我是谁，以及我遇到了什么问题
作为一个老登程序员，和代码打了20多年的交道，精通于古法编程。在快要退休前，又碰上了ＡＩ，于是命运的齿轮又开始了转动，我的工作有和ａｉ绑在了一起。。
为了参加 创造大赛，我选了一个硬件赛道，为esp32s3的设备进行开发。
买来的硬件，它们都有板子说明、demo代码和各种文档，但第一次打开时，还是很容易被一串问题劝退：这块板到底能接什么？屏幕怎么点亮？要用哪个版本？编译命令在哪？最后又该怎么烧进去？
ESP32 不是资料少，反而是资料太多、分在不同地方：官方框架文档讲工具链，板卡说明讲连接方式，项目说明又会写它能用的版本。对不熟悉硬件的人来说，要在这几份说明之间来回找答案，很容易不知道第一步该看哪一份。再加上 USB 串口、驱动和端口识别，环境配置往往比写第一段代码更消耗精力。
我这次想验证的，不是“AI 能不能替我做硬件”，而是：给齐板子参数和项目入口后，TraeCode 能不能把设计、改代码、编译和烧录准备接成一条比较顺的路。
2. 我是怎么用 TraeCode 解决这件事的
这次我主要使用的是 traeCode。我没有一上来就让 TraeCode 写代码，而是让它先把板子和项目看明白。
第一步：先让它理解项目和板子。 我先把项目目录交给它，让它梳理开发应用所需的硬件事实、稳定接口、资源边界、参考实现和验收方法，再确认目标功能和构建入口。这样做的原因很简单：它先知道我手上有什么，后面的建议才不会变成“猜着写”。
请先阅读当前项目的硬件资料和相关代码；按“产品规格/实测 → 引脚定义 → BSP 实现 → 硬件指南 → README”的优先级核对。
请说明开发应用所需的硬件事实、稳定接口、资源边界、参考实现和验收方法；每项标明来源。
查不到的内容请写“待确认”，不要猜测；验收请区分 Build、Host tests、Device tests 和 Unverified。
我想实现 <一个具体小功能>。请先告诉我做这个功能会用到哪些稳定接口、受限资源、构建入口和烧录前检查项；先不要设计和改代码。
第二步：先把工具链对齐，别急着改功能。 我先让 TraeCode 找出项目规定的开发环境版本、目标板和自带的构建脚本。网上教程里的“最新版本”不一定适配你手里的项目，所以这里要先以项目说明为准。
然后先用这套环境做一次不改代码的“基线构建”。开发环境、编译工具和 Python 运行环境要成套使用；如果之前换过版本或板型，就先清掉旧的构建缓存。先确认电脑能把原项目编过去，后面改功能时，报错就容易分清：到底是环境问题，还是刚改的代码有问题。
请先完善当前项目的工具链，暂不改功能：
- 从项目说明和构建脚本确认它要求的开发环境版本、目标板和实际构建入口；
- 确认配套编译工具与 Python 环境来自同一套已激活环境，不要直接套网上的“最新版本”；
- 如果之前切换过版本或板型，判断是否需要清理旧构建缓存；
- 按项目自带的构建入口做一次基线构建。
请输出：当前环境、实际构建命令、基线构建结果和待确认项。
第三步：先在电脑上把界面调顺。 在这个项目里，界面开发反而最花时间。以前改一点字的大小、间距或按钮位置，都得重新编译、烧录，再对着板子看效果；不满意就再来一轮。为了看个界面反复刷机，节奏很容易被打断。
所以我让 TraeCode 在电脑上先实现了一个简化版 UI 模拟器。它可以先让我看布局、文字会不会挤、按钮点起来顺不顺。大多数界面调整都能先在电脑上完成，不用一有改动就把板子拿出来刷一遍。
界面看顺之后，真正的功能开发和上板确认，就进入下一步的小循环。这样模拟器负责快一点调界面，开发板负责最后确认硬件上的效果。
请基于现有项目做一个轻量的 UI 模拟器，让它能在电脑上运行。
优先复用现有的界面代码和布局，用来检查文字、间距、按钮和主要交互。
请明确哪些能在电脑上验证，哪些仍要上板确认，并给出运行和截图方式。
它只负责帮我调界面，不替代真机。屏幕显示效果、触摸手感和硬件性能，最后还是要上板确认。
第四步：让需求、实现、烧录和测试跑成一个小循环。 后面每追加一个小需求，我都让 TraeCode 按同一个顺序往前走：先把这轮要做什么说清楚，再拆成要改的文件和代码，编译通过后准备烧录。
到写入设备前，最后的确认还是我来做：连着的是不是目标板；选的板型对不对；这次写入会不会覆盖设备里的数据。确认完才烧录，然后在真机上测试屏幕、按键和实际交互。
测试也不是看见能启动就结束。哪里不对、下一步想加什么，都变成下一轮的需求。这样每次只解决一个小问题，TraeCode 负责把过程串起来，我负责确认设备和看真机结果。
把板子和功能说清楚
↓
对齐工具链，先做基线构建
↓
TraeCode 做 UI 模拟器，先在电脑上调界面
↓
需求 → 实现/编译 → 确认后烧录 → 真机测试
↓
测试结果回到下一轮需求
3. 成果展示
这次最终做出了，并且最终参加了比赛
https://forum.trae.cn/t/topic/174871
4. 效率对比
以前，我会先在文档、例程和项目文件里来回找：【实际花费时间 / 需要找哪些资料】。这次用 TraeCode 先读项目、列参数，再在电脑上的模拟器里把界面调得差不多，最后按“需求—实现—烧录—测试”往前跑。
更大的变化不只是省了多少时间，而是把能参与开发的人变多了。只要手上是资料齐全的现成开发板，即使以前几乎没接触过硬件，也能把板子参数和想做的小功能说清楚，跟着 TraeCode 完成一次开发闭环；不用先把所有硬件术语和命令背下来。
这次从开始到 【构建通过 / 真机验证】 用了 【真实耗时】；和以前的 【真实耗时】 相比，最大的变化是 【例如：少了几次只为调布局而重复烧录，或能更快把真机测试结果变成下一轮需求】。
没有真实时间数据时，这一段宁可先空着，也不要编一个“效率提升百分比”。上面说的是适用条件下的开发体验，不代表 AI 能替代硬件验证。
5. 经验和技巧总结
- 先给参数，再让 AI 写。 板型、外设、目标功能、项目版本、构建入口和烧录入口，越清楚越好。
- 先跑通工具链，别急着写功能。 先按项目要求的版本、板型和构建入口做一次基线编译。环境不稳时，后面每一次报错都很难看懂。
- 界面先在电脑上调。 能在模拟器里看出来的字、间距和交互，就别每改一次都急着烧录。
- 一个循环只做一个小需求。 显示一行字、按键翻页、读一个传感器，都比一上来做完整产品更适合作为第一次尝试。
- 烧录和测试不能省。 TraeCode 能准备命令和排查步骤，但新 PCB、供电、充电、射频、未知引脚，以及烧录的数据覆盖风险，仍然需要看原理图、资料和真机结果。
你手上那块 ESP32，最想让 TraeCode 帮你做出什么？