AI编程错误：Claude破坏代码库的4种方式

AI编程错误不会用崩溃的代码来破坏你的代码库。它们用“能用”的代码来破坏——大约能用六个月。Claude经常自信地出错，而危险的版本不是明显出错的时候，而是看似合理地出错：代码能编译、能运行、看起来没问题，却建立在对你的数据或业务逻辑的错误假设之上。

在构建FIKR Space的十一个月里，AI反复冒出同样四种糟糕的模式。如果我接受了它们，每一种都会在六个月后造成不同的、特定的痛苦。下面用大白话讲讲——Claude提议了什么，为什么看起来合理，以及它日后究竟会让你付出什么代价。

为什么AI默认写出平庸的代码

Claude在数百万个代码库上训练过，而其中大多数都很平庸。当你不指定想要什么时，你得到的是中位数代码库的输出——充满经验丰富的工程师绝不会接受的捷径和妥协。这些捷径今天都不会失败。它们全都会在日后失败，这正是它们能通过创始人审查的原因，因为创始人只检查功能现在能不能用。

你的工作不是写代码。你的工作是在这段合作中扮演资深的那个声音——当某样东西闻起来不对劲时顶回去，即使你一时说不出为什么。

错误1：JSON大杂烩——是杂物抽屉，而不是文件柜

Claude会建议把结构化数据存成一个JSON大杂烩——一个什么都装的灵活字段——而不是带有正确列的正规表。就像把文件扔进杂物抽屉，而不是文件柜。抽屉里只有十份文件时，它运转得很好。

这在第三周就出现在我身上。Claude提议把用户的战略目标数据——季度目标、OKR状态、对齐指标——作为users表上的一个JSON列来存储。它本来可以用。大约用三个月。然后我需要回答一个基本的业务问题：给我看第三季度目标完成率低于百分之六十的所有用户。面对JSON大杂烩，回答这个问题意味着要打开每个用户的杂物抽屉，把里面所有东西读一遍才能筛选——这种做法在五十个用户时勉强可行，到五百个时就会彻底崩溃。日后修复将意味着迁移六个月的客户数据并重写十二个服务。在第三周顶回去，只多花了一小时的设计讨论。到第六个月再重建，则要花三周。

错误2：枚举——把今天的选项刻在石头上

枚举是一个允许值提前固定好的字段——就像把餐厅菜单印刷出来，而不是写在白板上。对于任何取值集合小而已知的字段——订阅等级、用户角色、通知类型——Claude都强烈默认使用枚举。每一个在当下看来都显然是固定的。

我的每一个枚举，在一年之内都需要新增取值——新的订阅等级、新的角色、新的通知类别。而在数据库中修改枚举需要一套多步骤的仪式：删除约束、重建类型、更新每一行。查找表——白板版本——是一张普通的表，增加一行就能扩展。枚举把列锁定在今天的现实上；查找表则容纳明天的现实。同样的模式，不同的默认。顶回去。要求使用查找表。

12 周企业职业生涯从来都不是计划申请加入 Solopreneur Accelerator。立即申请 →

错误3：any类型——关掉烟雾报警器

TypeScript的全部任务，就是通过检查每一份数据是否是代码所期望的形状，在用户看到之前抓住一整类bug。当这种检查在某个复杂的东西上失败时，Claude有时会提议把数据标记为any——意思是“别再检查这个了”。错误消失了。构建成功了。功能上线了。你刚刚关掉了一个烟雾报警器，在出现烟雾之前什么都不会发生。

这是最阴险的模式，因为症状是看不见的。六个月后，你修改了产品其他地方的某样东西，本该抓住破坏的类型错误却没有出现——因为上游某处有个any在悄悄吞掉信号。bug发布到了生产环境。你是从客户的反馈中得知的。你现在接受的每一个any，都是未来某个周二下午花在调试类型系统本该预防的问题上的时间。

错误4：静默吞掉错误——没人听见的失败

四个里最糟的一个。Claude有时会写出相当于try { ... } catch (e) { return null }的代码——“如果出了任何问题，什么都不说，返回一个空结果”——并称之为优雅的错误处理。这样的代码能通过你写的每一个测试，因为你的测试不会刻意触发那种失败模式。

在生产环境中，当真正的失败发生时，函数什么也不返回。悄无声息。系统的其余部分不知道出了任何问题。用户看到一片空白的屏幕。错误没有被记录在任何地方。你要等到客户投诉才会知道——即便那时你也无法追溯发生了什么，因为从未抛出过任何错误。每一次都要与此对抗：具体的失败，具体处理，大声记录。多写的那五行代码，能帮你避免下一次宕机。

四种AI编程错误背后的共同模式

好消息是：Claude对被挑战的反应很好。当你说“不，我要把它做成独立的表，而不是JSON大杂烩——原因如下”时，它会从容地重构代码，而且往往比它最初提议的更好。这个模型是合作型的。你只需要做那个资深的声音。

有两个习惯能让顶回去变得系统化，而不是靠运气。在AI构建任何东西之前，先把任务交代清楚——这就是PRP方法。绝不让速度取代结构——这就是氛围编程陷阱的全部教训。明确指定。顶回去。要求正确的结构。每个功能会多花一点时间，但换来的是一个在第十二个月仍能继续演进的代码库，而不是一个必须推倒重建的。

本书The Solopreneur RevolutionLuis Gonçalves 讲述如何在不辞职的情况下用 AI 打造独立创业者事业。获取本书 →

常见问题

为什么AI生成的代码会在几个月后引发问题？

因为AI优化的是让今天的请求跑通，而不是代码如何演进。它在数百万个大多平庸的代码库上训练，默认采用各种捷径——灵活的大杂烩、固定的取值列表、被关闭的检查、被吞掉的错误——这些捷径现在能通过每一个测试，只有当产品成长或变化时才暴露出代价。

如果我看不懂代码，如何识别糟糕的AI代码？

审问变化和失败，而不是语法。问AI：当我们需要在这里新增一个取值时会怎样？当数据量增加十倍时，我们怎么搜索这些数据？当这个操作失败时会怎样——错误去了哪里？如果答案涉及迁移、重写，或者“它什么也不返回”，就顶回去。

我应该让Claude做架构决策吗？

不应该。Claude是出色的实现者，却是平庸的架构师。问它某样东西应该做成独立的表还是JSON列，答案通常还行，有时很糟，偶尔很棒——除非你培养出了自己的架构品味，否则你分辨不出是哪种。架构决策归你；实现决策归Claude。

对AI顶回去不会拖慢构建吗？

每个功能会稍微慢一点——而这是你能做的最划算的交易。在第三周顶回JSON大杂烩，只多花了我一小时的设计讨论。接受它，则会在第六个月花掉三周重建，外加迁移六个月的客户数据。