14 附录：AI时代的开发路线
14.1 简介
AI以旱地拔葱的速度提高了所有人的“智商”，尤其是在编程方面。在可预见的未来数年，大部分程序员会退化为项目经理，AI能够解决大部分标准和非标需求。本文我们主要讨论几种适合AI开发的框架，虽然AI有能力去做筛选和开发，但目前它对于长远规划的能力还弱于人类，需要项目经理进行导向和规划。
目前主要在平面设计、嵌入式开发、程序编写等方面AI已经超越了大部分人类，而三维建模、长远规划、关键算法仍逊色于人类。我们需要区分哪些工作应该让AI来做，哪些工作自己做。AI是员工，是帮手，甚至可以是上级，但不是聊天工具，应尽量避免同一问题的多轮沟通（除了酒馆）。
14.2 平面设计
虽然现有的平面设计平台如可画、Figma，都在拼命往AI方向发展，也确实涌现了一些很好用的工具和插件，但我认为智商远比工具重要，Opus花十分钟做出来的效果DeepSeek一周也不一定做得出来。但是，对于没做过平面设计的人来说，我们还是要给AI导向。我们应当：
- 尽可能用 HTML 来进行初期的布局、预览，后期可以转为 SVG 再到 PNG。
- 尽可能利用开源库、组件、图标和字体。
我们不应：
- 生成 JPG、PNG 并在其基础上修改。
- 直接生成 SVG，或直接生成整体项目。
对于长文档，建议以 Markdown 撰写、由 Pandoc 生成生产环境的 PDF 文稿。这套流程很好用，唯一的缺点是配置较为麻烦，不过也可以交给 AI 来完成。
14.3 嵌入式开发
单片机和电路的设计阶段推荐用 KiCad，它开源，各类 AI 工具对它都有支持。但边界条件还是要人工审查，并且一定要多个 AI 交叉审查。调试可以用 VSCode 配 GDB/OpenOCD，甚至直接跑 CMD 命令，大多数时候通过串口调试是最方便快捷的，只有少数必须下断的时候才需要使用 GDB 调试。你甚至已经不需要自己去装 OpenOCD 插件、配置，只要规划好，全部交给 AI 实施即可。
界面上，传统做法是 LVGL、TouchGFX 配点阵屏，手动算像素，开发很慢。AI 时代不是说抛弃 LVGL，很多场景仍然需要本地显示甚至裸机带屏，但我们不必再跟代码和布局死磕，可以交给 AI 来做。
真正带来质变的是 WebUI：只要设备有网口或 WiFi，把打包好的 Vue/React 页面或静态 HTML 存进闪存，用户用手机或电脑连上局域网浏览器访问即可。原本在单片机上卡成 PPT 的动态仪表盘、实时曲线，在浏览器里就能丝滑运行，而且不需要为每种屏幕适配一遍 UI。
对于 STM32 这类传统单片机、甚至没有网口的场景，可以用 Web Serial 做免安装上位机：浏览器直接访问串口，读写数据并绘制波形，用户不用装驱动、不用装软件。理想形态可以参考 Mongoose Device Dashboard。
需要注意的是：Flash 与 RAM 依然是硬约束。必要时可以外置 FLASH 或 SD 卡，并且不要把 UI 刷新放进实时控制循环，应交给独立的后台任务或独立的网络任务去处理。
14.4 通用程序
本节讨论 Windows 与 Linux 上的通用程序，即上位机、桌面工具与配置软件这一类应用。最推荐 Tauri 打包，前端使用 Vue 或 React，打包产物仅十几兆，并支持热重载调试。若无需安装包形态，也可将前端构建为静态资源，由后端兼做 HTTP 服务器，浏览器直接访问。
若需精细控制窗口、菜单、多屏显示或 GPU 绘图，Tauri 的能力有限，可用 Rust 搭配 GPUI。其性能与内存占用均优于 WebView 方案，代价是生态尚小。后端语言方面，新应用不再推荐 C#，部分场景仍可考虑 C++，例如复用既有 Qt 资产、对接厂商 SDK，或对延迟与内存有硬性要求时。科研与小工具则可直接使用 Python。
架构上仍应先统计需求，确认有无成熟开源组件可以复用。UI 库可由 AI 推荐后自行选定，主流选择为 Vuetify、Element Plus、Ant Design Vue 等。前期架构务必使用优质模型确定，框架选择失误会造成大量返工。
14.5 实时控制
实时控制实际上只有 C++ 一种选择。控制周期通常在 100 µs 到 4 ms 之间，一次 GC 停顿或解释器抖动就足以丢帧，这里比的是最坏情况，而不是平均值；可预测的内存行为、可显式控制的指令顺序与内存可见性、成熟的实时环境支持（PREEMPT_RT、CPU 亲和性、实时调度策略），主流语言里只有 C++ 同时具备。
14.6 总结
近一年来，我用 AI 做了几个嵌入式相关的项目，总结下来还是那几条经验。
- 文件要拆散。单个文件不宜过大，按文件夹归类，头文件尽量加注释，注释尽量用英文。
- 对话超过四五轮就换模型。避免在一个问题上纠缠太久。
- 不明确的改动先要方案。让 AI 先给思路，不要直接动代码，确认之后再实施。改动越大越要如此，必要时可以用插件做规划。
- 使用 Git 进行版本管理。AI 的修改是批量的，没有 Git 兜底，一次误改就可能丢掉半天的工作。
截至编写本文时，规划与复杂问题的调试适合用 Claude 或 Codex，细节功能的实施适合用 DeepSeek。如果预算充足，也可以只用最高端的模型。插件和技能我认为并不重要，文档是必要的，但也可以让 AI 来写。
当前的 AI 仍然需要人工审查和导向，它擅长实现，不擅长判断。但发展极快，我相信不久的将来可以做到“许愿式”编程，也或许这个“将来”已经到来了。