Part 3: 我的踩坑故事 (15-20 min)

作者观点

本章内容完全基于我的个人经历，分享我在 AI 编程中的踩坑教训。每个人的情况不同，请结合自身实际参考。

核心思路：用亲身经历验证 Part 2 的概念，让听众有代入感

3.1 Home Assistant 项目：三个阶段

最近，我在开发一个新项目，目标是将公司的物联网网关接入 Home Assistant 平台。这对我和公司来说都是全新的领域，同事们缺乏相关经验，我只能自己上网跟着文档进行实践。

阶段	时间	状态	我的角色	对应概念
第一阶段	4.21-4.25	文档看不懂，无头苍蝇	困惑	85% 法则
第二阶段	4.27-5.10	功能跑起来，90% AI 写的	产品经理	Vibe Coding
第三阶段	5.12-5.16	代码量减半，结构清晰	真正的开发者	理解后重写

第一阶段：我打算从官方文档入手，但文档内容晦涩难懂。Home Assistant 平台涉及的概念和知识点繁多，我并不清楚自己需要掌握哪些知识才能实现目标，像是无头苍蝇一样四处摸索。这种状况持续了一周。事后发现，这其实是不符合学习的 85% 法则——当学习材料太难、正确率低于 85% 时，学习过程会异常痛苦。

第二阶段：本着「再发散下去五一就要到了」的心理，我开始 Vibe Coding。五一前后共两周，我在 AI 编写的代码基础上，调试出了一个功能上基本可用的版本。此时大概 90% 的代码都是 AI 写的，我不过是协助 AI 进行测试、不断精细化项目需求的那个人。此时我作为「代码产品经理」的角色，已经搞清楚需求实现的方向，但代码对于我仍然是一个黑盒。

第三阶段：我终于承认 Vibe Coding 的产物我已经无法控制了。功能是实现了，但其实有很多 BUG，只要稍微一用就能发现。此时已经改不动了——因为 AI 的代码是我多次交流得出来的结果，估计每一次交流所产生的代码，都会在某种程度上引入一定程度的 BUG。

于是我从零开始重写。这一次，我惊喜地发现之前看不懂的文档知识点，现在大多都能理解。重写后，进度已达 80%，但代码量不到之前的 50%，结构也更加简洁、更好维护。

反思：我并非在检讨或后悔，若没有第二阶段放手让 AI 协助，我可能寸步难行。但我感到庆幸，也有些后怕——幸好项目并未紧急到让我在功能刚实现时就草率交付。坦白说，大规模 Vibe Coding 导致的不可维护性还是出乎我的意料。

核心观点：AI 让我跳过了基础知识积累，直接进入实践——这是危险的

[!TODO] 素材准备

• [ ] 三个阶段的代码量/commit 数对比
• [ ] 「失控代码」截图示例

3.2 PR 重构反思：Vibe Coding 的三大副作用

最近将自己写了几个月的代码，挑了一部分逻辑往大项目提了 PR。在经历了 Conversation 100+、Commit 90+、Time 50d+ 之后，总算是将 1400 行的代码改好。

背景补充一下：这是我第一次在工作上写 Python 项目，且是单兵作战，且该大项目的要求确实挺多的。

这周将 PR 中的反馈整理成文档，并重构原有仓库。接近少了一千行。问题主要集中在三个方面：

1. 过度设计：有的功能明显是想多了，用 200% 的复杂度实现了 105% 的功能，以至于维护起来像是穿着重甲在水中行走。因为 PR 中要给人说清楚，就索性直接删掉了。

2. 没有遵守 Best Practice：有很多逻辑既可以「这样写」也可以「那样写」，但这种视角一般是入门者才会有的。若是经验丰富的开发者，他们眼中的方案或许就会收缩到少有的一两种，然后再根据项目的「惯例」来确定唯一的方案。而一般这样做的话，很自然就会发现有不少趁手的工具可以直接复用，从而减少代码。其实这些在他们的文档中都有提到，但我全程依赖大模型总结开发文档，只有在进度受阻时才查阅原文。

3. 遗留问题：删除过多的 log 以及混乱的 try-catch。这是处理各种无法控制的 BUG 频发的代码所遗留下来的痕迹。

四舍五入，这些都是 Vibe Coding 的副作用。因为言出法随，动动嘴皮子就能写好功能，自然多了许多无法掌控且不必要的功能。

[!TODO] 素材准备

• [ ] PR conversation 数、commit 数、代码行数变化截图
• [ ] 重构前后代码对比

3.3 教训总结

问题在于「AI 让我跳过了基础知识的积累，直接进入实践阶段」。我们往往因此轻易得到答案，可一旦问题稍有变化，答案就可能从正确变为大错特错。这种行为如同用竹竿撑起高楼，过于冒险，难以做到举一反三。

实践是学习的重要环节，早期实践能让人迅速利用知识达成目标，并加深理解。然而，我们必须意识到，这种实践的结果往往潜藏风险。我们还是要沿着走过来的路，将一路上的螺丝拧紧。

我挺怀疑有没有更好更快速的成长方法？不过多看文档原文、多看别人的实现方案，这总归没错的。

参考：The Programmer Identity Crisis

---