承重代码 vs 石膏板代码：AI编程的可靠性分界线

AI辅助编程正在改变软件开发的节奏，但一个关键问题常被忽略：哪些代码可以随手让LLM生成，哪些必须经过严格审视？在一场技术对话中，两位开发者用“承重代码”和“石膏板代码”的比喻，划出了一条清晰的可靠性分界线。

什么是“石膏板代码”与“承重代码”

对话中提出的核心概念直白而锋利：石膏板代码（drywall code） 指一次性的、快速实验性质的代码——写完就扔，甚至不需要阅读，直接运行看结果。承重代码（load-bearing code） 则是要长期运行、构成系统骨架的部分，它不仅需要人类理解，还要求LLM在解释问题时不会因上下文限制而产生幻觉。

这个区分之所以重要，是因为AI编程工具让“写代码”的成本急剧下降，但“维护代码”的成本并未同步消失。把一次性脚本当成长期系统来对待，是过度工程；反过来，把核心系统当成实验代码来写，则是埋雷。

一个USB驱动的反面教材

对话中举了一个具体例子：USB驱动长期被当作石膏板代码对待。据对话中的说法，“这就是他们多年来的处理方式”——驱动层代码往往被视为可替换、可快速迭代的部分，缺乏承重级别的严谨性。

但对话者明确表达了不同立场：“不，我想让它变成承重代码。”这背后是一个现实判断：驱动代码一旦出问题，影响的是整个系统的稳定性，而LLM在解释驱动逻辑时恰恰容易触及上下文限制，产生错误推断。

把这类代码划入承重范畴，意味着人类必须真正读懂它，而不能依赖LLM的“解释”来蒙混过关。

为什么LLM的幻觉在承重场景下更危险

对话中有一个容易被忽略的细节：承重代码的定义里包含了“LLM在解释问题时不会因限制而幻觉”这一条件。这实际上点出了AI编程的软肋——LLM擅长生成看起来合理的代码和解释，但在长上下文、复杂依赖的场景下，它的解释可能流畅却错误。

石膏板代码的容错空间大：跑不通就重写，没人依赖它的内部逻辑。承重代码则不同，一次幻觉导致的理解偏差，可能在生产环境中潜伏数月。因此，承重代码的评审标准不能因为“AI写得快”而放松。

上下文窗口限制（Context Window Limitation） 是理解LLM幻觉风险的关键技术背景。LLM在生成回复时，只能“看到”有限的上下文窗口——即模型单次能处理的最大token数量（包括输入和输出）。当代码库或依赖链超出这个窗口时，模型无法获取完整信息，只能基于局部片段进行推断。这种推断在语法层面可能完全合理，但在语义层面却可能与实际系统行为不符，从而产生“流畅但错误”的解释。对于承重代码而言，这种局部性推断尤为危险，因为承重代码往往涉及跨模块的隐式契约和长调用链，恰恰最容易超出上下文窗口的覆盖范围。

从法国砖墙到美国石膏板：架构灵活性的隐喻

对话还延伸出一个有趣的类比。说话者来自法国，习惯了砖石结构的房屋，初到美国时对石膏板墙体颇为不适，后来却爱上了它——“你可以重新架构你的房间，直接打穿它。”

这个隐喻恰好对应了软件架构的取舍。石膏板代码的价值在于灵活性：快速试错、随时推倒重来。但一栋房子不能只有石膏板，承重墙决定了它能站多久。软件开发同样需要在两者之间分配比例，而不是用同一种态度对待所有代码。

技术债务（Technical Debt） 的概念与石膏板/承重墙的隐喻形成互补。技术债务指为了短期速度而选择次优方案，从而在未来产生额外维护成本。石膏板代码如果被意外复用并进入生产依赖链，就会从“一次性实验”转变为“隐性技术债务”——它的内部逻辑从未被严格审视，却开始被其他模块依赖。这与承重墙的隐喻呼应：石膏板隔墙可以随时打穿重排，但一旦有人把承重结构错误地当作隔墙拆除，整栋建筑就会面临坍塌风险。因此，划分石膏板与承重代码的本质，是在架构层面主动管理技术债务的边界。

如何在实际项目中划线

这个框架的实用价值在于它提供了一个可操作的判断标准。面对一段AI生成的代码，可以先问三个问题：它是一次性实验还是会长期存在？它是否被其他模块依赖？我是否愿意在不理解它的情况下让它上线？

答案指向石膏板，就放手让LLM快速产出；答案指向承重，就必须人工审读、测试覆盖、明确边界。对话中最核心的提醒或许是：不要把承重代码当石膏板来写，哪怕AI让它看起来毫不费力。

常见问题

石膏板代码是否意味着完全不需要测试？

对于真正一次性的实验代码，测试的投入产出比很低。但一旦这段代码被复用或进入共享分支，就应当重新评估其归属。

承重代码的标准是否适用于所有LLM生成的代码？

不适用。这个分类的意义恰恰在于避免“一刀切”——用承重标准要求所有代码会导致效率崩塌，用石膏板标准对待核心系统则会带来长期风险。

如何判断LLM对代码的解释是否可信？

关键看该代码是否处于LLM的上下文能力边界内。依赖链越长、领域知识越专，解释的可信度越低，越需要人工验证。