一个物联网开发者的真实记录，关于 AI 辅助编程那些意料之外的事

---

写在前面

今年年初，我给团队提了个需求：做一个协议工具箱，把平时调试用得到的 HEX 转换、时间戳、DL/T645 加33减33、Base64 编解码这些都放一块儿，省得每次现搜现写。

我当时的想法很简单：“跟 AI 说一声，让它搞一个 Spring Boot 项目，页面用 Thymeaf，一两天应该能跑起来。”

结果这个项目断断续续做了快两周。不是 AI 慢，是我和它之间的"沟通成本"，比我自己写代码还高。

以下是真实记录。

---

坑一：AI 会过度满足你

我第一次跟 AI 说的是：“帮我们提升团队技术水平，重构这个 Gitee 上的开源项目，重新设计页面。”

AI 很卖力，给我生成了一个完整的 Spring Boot 后端：Controller、Service、Repository、Entity，甚至还有单元测试。

问题来了：我的项目是一个纯工具类网站，不需要数据库，不需要后端，打开浏览器就能用。AI 给我的是一个需要启动 Java 进程、连接数据库、配置 Nginx 反向代理的"企业级解决方案"。

我花了大概一天才意识到这个问题——不是 AI 错了，是我没有说清楚。

经验：跟 AI 提需求，越具体越好。“做一个纯前端页面，不需要后端，打开 index.html 就能用”，比 “做一个 Web 应用” 要强一百倍。

---

坑二：AI 不理解"感觉"

页面做出来以后，我觉得不太对。我跟 AI 说：“页面有点松散，参考一下 protocol-parser 那个项目的风格。”

AI 给我做了一个侧边栏导航的深色主题版本。

我看了看，说：“不是这个意思，要清新简洁。”

AI 改成了顶部横向标签页的白色主题。

我还是觉得不对，说：“功能多了排不下，交互简单些。”

最后我们迭代了四个版本，才落到现在这个"输入即结果"的即时转换模式。

这个过程让我明白了一件事：AI 能理解"simplify the interaction"，但不太能理解中文里*"操作步骤少一点，体验好一点"这种模糊的感觉。后来我学会了用具体的交互描述来替代感觉描述——“不要转换按钮，输入时自动计算并展示结果”*，AI 一次就做对了。

---

坑三：npm 打包时 AI 选了错误的工具

项目做了一多半，我说：“用 npm 打包吧，代码太乱了，模块化一下。”

AI 很自然地选了 terser 作为压缩工具，然后 npm run build 报错了——terser 没装，而且即使装了，在我的环境里也有兼容性问题。

AI 改用了 esbuild，一次通过。

这个坑不大，但挺典型：AI 会按照"最常见做法"给你建议，但不一定适合你的具体环境。后来我学会了在提技术需求时加上约束条件——“用 Vite 打包，minify 用 esbuild，不要用 terser”。

---

坑四：路径问题，AI 自己都找不到自己

打包后我打开 dist/index.html，页面是空白的。

查了一下，发现引用的资源路径是 /assets/index-xxxx.js——绝对路径。在本地用 file:// 协议打开时，浏览器会去根目录找，当然找不到。

AI 修改后的 vite.config.js 加了 base: './'，相对路径 ./assets/...，本地预览正常了。

这种问题属于"AI 知道正确做法，但默认配置不一定适合你的使用场景"。如果你也是本地双击打开 HTML 文件来用，记得跟 AI 强调这一点。

---

坑五：函数签名不一致，AI 自己调用自己都出错

这个项目里有个公共函数 setOutput(elementId, state, content)，用来在输出框里展示结果或错误提示。

Base64 模块里，AI 写成这样：

setOutput(outEl, content, false)  // outEl 是 DOM 对象，不是 ID 字符串

而 setOutput 的定义要求第一个参数是字符串 ID。结果就是：编码可以，解码时报错，而且报错信息跟 Base64 没关系，排查了半天才发现。

这种 bug 最烦——AI 生成的代码，AI 自己调用时都能写错参数顺序。后来我养成了一个习惯：每次 AI 写了新模块，我都会人工核对一下公共函数的调用方式是否一致。

---

坑六：CSS 内联样式覆盖了外部样式表

用户说：“文本输入框大些，方便输入更多内容。”

AI 很听话地把输入框的 min-height 改成了 180px，但改的方式是在 HTML 里加了 style="min-height:180px"。

后来我觉得 180px 还不够大，让 AI 改成 220px，AI 去改了 style.css 里的 .instant-input 规则。

但问题来了——HTML 里的 style="min-height:180px" 优先级比外部 CSS 高，所以改了 CSS 文件，页面上根本没变化。

最后发现是 HTML 里有一处 style="min-height:auto; resize:none" 的内联样式，把 CSS 的 min-height:180px 覆盖掉了。

经验：让 AI 改样式时，最好明确说*“改 CSS 文件，不要加内联样式”*。内联样式的优先级陷阱，AI 和人类都容易踩。

---

坑七：树形视图的展开/收缩，AI 写了个"能跑但逻辑是错的"版本

JSON 和 XML 格式化工具里，我让 AI 做了可折叠的树形视图。第一版做出来，功能是有的——点击可以展开/收缩。

但仔细用下来，发现几个问题：

1. 收缩时，左花括号 { 和右花括号 } 没有一起隐藏，看着很怪
2. 展开/收缩的三角图标（▶/▼）跟实际状态是反的——显示 ▶ 的时候，子节点其实是展开的
3. 用 nextElementSibling?.nextElementSibling 来定位子节点容器，但这个偏移量算错了，实际指向了别的元素

AI 修了两轮才修对。最后我们用"给每个可折叠节点生成唯一 ID"的方式替代了"兄弟节点遍历"，彻底解决了这个问题。

这个坑的启示：AI 擅长写"看起来能跑"的代码，但不擅长处理 DOM 节点关系的边界情况。涉及 DOM 操作的复杂交互，最好人工 review 一下逻辑。

---

坑八：部署到服务器，AI 选的工具在沙箱里用不了

项目做完了，要部署到腾讯云服务器。AI 很自然地选了 sshpass 工具来做免密登录。

但运行环境里没有 sshpass。

AI 又换了 expect 脚本，通过交互式输入密码来绕过这个限制。这里又碰到一个新问题：密码里有一个反引号 `，在 expect 脚本里需要转义，否则会被当成命令替换。

这类"环境差异"的坑，在 AI 辅助编程时特别常见。AI 默认按照"标准 Linux 环境"来给你方案，但你的实际环境可能有各种限制（沙箱、权限、缺失的包）。遇到部署类任务，最好提前告诉 AI 你的环境约束。

---

一些正向的经验

踩了这么多坑，但也有很多出乎意料的收获：

1. AI 做重复性代码很快

10 个工具的页面结构其实是差不多的，AI 复制粘贴改一改，几分钟就能把框架搭好。人工做这个事情挺枯燥的。

2. AI 擅长写正则表达式

HEX 校验、DL/T645 数据帧解析、XML 标签匹配，这些正则都是 AI 写的，我看了下，没问题。

3. 让 AI 写文档比写代码更值

这个项目最让我满意的交付物，反而不是代码，而是 README 和这篇分享文章——都是 AI 帮我写的。代码我自己也能写，但整理文档一直是我的短板。

4. 多轮迭代比一次做对更现实

我最初的需求文档，现在回头看，有很多我自己都没想清楚的地方。跟 AI 一轮一轮地改，改到第四版才真正变成我想要的样子。这个过程，其实也是在帮我理清需求。

---

项目地址

如果这篇文章让你想起了自己跟 AI 协作时的类似经历，可以来看看这个项目：

Gitee：https://gitee.com/road0329/iot_protocol_toolbox

在线体验：https://www.zfh-iot.cn/toolbox

目前内置了 9 个工具：HEX↔ASCII、时间戳转换、Base64 多格式编解码、DL/T645 协议、字符串处理、进制转换、JSON/XML 格式化、AES 加解密。

纯前端，下载下来双击 index.html 就能用。代码也简单，想加新工具的话，照着 src/js/modules/ 里任意一个文件抄一个，半小时就能搞定。

---

写在最后

AI 辅助编程这个方向，我目前的感觉是：它不会替代你，但会用 AI 的人会替代不会用 AI 的人。

区别在于，用 AI 的人踩坑以后会总结，不会用的人踩了坑还不知道为什么。

以上，希望能帮到同样在探索 AI 辅助开发的你。

---

如果觉得这个项目有用，欢迎去 Gitee 点个 Star ⭐，或者提个 Issue 告诉我你还想要什么工具。