【7个月AI编程失败教训：AI只会写功能，不懂做架构】

快速阅读：作者通过七个月“氛围感编程”（Vibe Coding）构建 Kubernetes TUI 工具的失败经验，揭示了 AI 在处理复杂逻辑时的致命缺陷：它能快速实现功能，却无法维持架构。如果不通过人工设计架构并设置严格的指令约束，项目会迅速沦为不可维护的“代码泥潭”。

只有那些从不读代码的人，才会觉得 AI 生成的代码没问题。

最近我尝试了一种很危险的开发模式：完全交给 AI 驱动，只看功能实现，只看差异对比（diff），只要能跑通就直接合并。这种“氛围感编程”在项目初期像魔法一样，速度快得惊人。但七个月后，当我想切换一个视图时，整个系统竟然崩溃了。

我不得不去读那 1690 行被 AI 填满的代码。那一刻我才发现，我亲手制造了一个“上帝对象”（God Object）。

AI 的逻辑是极其功利且短视的。当你要求它“增加一个功能”时，它会选择阻力最小的路径。如果现有的结构不合理，它不会停下来思考如何重构，而是会直接在现有的混乱上打补丁。它会把所有状态塞进一个巨大的结构体里，会在通用的逻辑里塞满针对特定功能的 `if-else` 分支，还会用极其危险的硬编码索引来处理数据。

它在帮你实现功能，却在不知不觉中吞噬你的架构。

这种现象可以用“认知债”来形容。AI 降低了写代码的成本，却极大地提高了理解代码的成本。当你不再亲手构建每一个模块、每一个接口时，你对系统的直觉就在萎缩。你以为自己在驾驭工具，其实你只是在玩一场概率游戏，赌它这次不会留下定时炸弹。

有网友提到，AI 就像一个极其热情的初级工程师，它会为了完成任务而不惜违反所有的架构准则。

我现在的策略变了。我不再让 AI 替我做决策，而是把决策权收回来。在写下第一行 Prompt 之前，我会先用手写好接口、消息类型和所有权规则。我会把这些“架构不变性”写进 `CLAUDE.md`，像给机器下达严苛的法律指令一样，强制它在既定的轨道内运行。

AI 可以是极佳的实现者，但它永远无法成为架构师。如果你想让软件在两年后还能演进，而不是在两年后彻底崩塌，你必须重新夺回对代码的控制权。

毕竟，如果你无法追踪代码的逻辑，那么编译器也无法为你追踪。

blog.k10s.dev/im-going-back-to-writing-code-by-hand/