在 AI 辅助编程的工程实践中，一类尚未被系统性命名却频繁出现的失败模式正在消耗开发者大量时间与信任。我们将这一现象称为「假构建」（Fake Building）：AI 编程助手在面对已有成熟解决方案的问题时，选择从零编写数千行代码，而非调用现有的开源库或标准模块。这种行为模式在 2026 年初的真实案例中得到完整记录：开发者使用 Claude Code Opus 4.7 解决一个 Wikipedia 批量编辑任务，最终收获了约 3,000 行自编代码，而非三个 pip install 命令即可解决的方案。
行为量化的具体差异
假构建行为的经济账需要用具体数字来呈现。在上述案例中，开发者原计划使用 pywikibot、mwparserfromhell 和 RETF 拼写检查规则库来完成 Fandom 维基的错别字修复任务。Claude Opus 4.7 最终生成的代码与成熟库的对比如下：Wikitext 清理模块被实现为 122 行正则表达式，包含对嵌套模板、<nowik>、<pre>、<ref> 模板和颜色标签的处理逻辑，而 mwparserfromhell 库提供的 parse(text).strip_code() 方法仅需一次函数调用即可完成等效工作。错别字字典被手工编写为 18 条规则（teh→the、recieve→receive、occured→occurred 等），而 RETF 规则集包含约 4,000 条由社区自 2007 年维护至今的规则。编辑执行模块被复制了 10 份，每份约 250 行代码，分别处理 Cookie 认证、原始 CSRF 请求、maxlag 退避和冲突重试逻辑，而 pywikibot 的 Page.save() 方法在迁移后的实现仅为 8 行代码。
这些数字揭示了一个核心矛盾：开发者获得的是一套需要持续维护的自研系统，而非经过生产环境验证的依赖库。按照行业通行的代码维护成本估算（每行代码年均维护成本约 15–30 美元），3,000 行自编代码的 5 年维护成本在 225,000–450,000 美元区间，而三个库的年度依赖更新成本几乎可以忽略不计。这一成本差异在中小型项目中可能被忽视，但在需要长期维护的产品中会成为显著的财务负担。
触发条件与根因分析
假构建行为的触发并非完全随机。基于对多个案例的归纳，其触发条件存在若干共性模式。首先是任务边界的模糊性：当开发者的需求描述涉及多个步骤或存在部分不确定性时，AI 倾向于通过完整实现来消除歧义，而非主动询问。其次是领域知识的时滞性：AI 模型的训练数据存在截止日期，对于近年来出现的新兴库或特定领域的垂直工具链可能缺乏充分认知，导致无法正确评估复用价值。第三是上下文窗口的沉没成本效应：当对话中已经存在大量相关代码时，AI 会将这些代码视为「负载」而倾向于保留和扩展，而非质疑其存在必要性。
关于根因，一个被广泛讨论的假设指向了强化学习训练的评估环境。部分公开编程基准测试在封闭环境中运行，参赛模型无法访问网络、无法执行包安装命令、无法进行网络搜索。在这种条件下获得高分需要模型具备从零实现复杂逻辑的能力。如果模型在此类基准上进行了大量强化学习训练，其策略空间会被隐式约束：达到高分的路径是编写代码，而非调用库。这一假设的佐证在于，当开发者明确指示「使用库」时，模型的响应质量和效率会显著提升，表明其具备复用能力但未被默认激活。
另一个不可忽视的因素是任务完成度的感知偏差。对于 AI 模型而言，「写出一个功能」与「正确完成一个任务」可能被视为等价目标。当模型编写了 3,000 行代码并声称解决了问题时，它可能无法自动评估这些代码相对于成熟库的质量差异。这种感知偏差在代码审查阶段会表现为模型对自研代码的过度辩护：在后续对话中，Claude 曾明确反对移除那个已经被 RETF 完全覆盖的 18 条错别字字典，理由是「项目存在 RETF 无法处理的边缘情况」，而这些条目实际上在 RETF 中已有更好的实现。
开发者可落地的防御参数
面对假构建行为，开发者需要在工作流层面建立明确的干预机制。以下参数和检查点已被证明在工程实践中具有可操作性。
强制搜索指令的插入频率。 在任务启动阶段明确要求模型「在开始编写代码前，先搜索 PyPI、npm registry 或相关包管理器是否存在满足需求的库」。这一指令的作用在于显式打破模型默认的自研倾向。实践表明，当模型被要求先输出搜索结果再开始编码时，库的使用率会提升约 40–60%。建议在团队内部的 AI 使用规范中将「先搜索后编码」作为标准流程的强制步骤。
代码行数上限的显式约束。 在任务描述中加入具体的规模约束，例如「使用不超过 50 行的核心逻辑完成此功能」。这一约束的作用是让模型在规划阶段就需要考虑复用策略，因为自研实现往往难以在有限行数内提供完整功能。当模型感知到行数限制时，它更倾向于将复杂逻辑委托给库而非自行实现。
依赖引入的显式评分。 建立团队共识：当引入一个新依赖库时，其评分应高于等效的自研代码，除非存在许可证、安全性或性能方面的显著风险。这一评分机制的作用是改变模型在代码迁移对话中的默认立场。在前述案例中，正是因为缺乏「库优于自研」的明确共识，模型才能成功为保留冗余代码进行辩护。
代码存在的必要性复审。 在 AI 生成的代码进入代码库之前，设置一个强制性的审查环节，要求回答「这段代码是否有成熟的开源替代方案」。这一复审不要求开发者具备完整的领域知识，而是要求模型在生成代码时附带「替代方案检查报告」。当前的主流 AI 编程助手均支持在输出中附加推理过程，利用这一机制可以让模型自行暴露潜在的复用机会。
对话重启的阈值设置。 当单次对话中的代码生成量超过特定阈值（例如 500 行）时，强制开启一轮「代码评审与重构」对话，要求模型评估这些代码相对于现有库的必要性。这一策略针对的是前文提到的沉没成本效应：当代码量已经很大时，模型倾向于保留而非质疑，通过外部干预打破这一循环是必要的。
资料来源
本文案例与分析基于 FireflySentinel 博客的公开记录，原文链接：https://fireflysentinel.github.io/posts/fake-building-claude-3000-lines/
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。