代码看起来没问题，但它真的能跑吗？
最常见的隐性成本是：生成的代码在视觉设计上很到位，却忽略了底层行为。在目前规模最大的一项研究中，DeclarUI系统——它利用计算机视觉和大语言模型从UI设计稿生成移动应用代码——发现最先进的多模态大语言模型（如GPT-4V）仅覆盖了页面转换图（PTG）的约44%，而PTG描述的是用户在各屏幕之间的导航方式[1]。这意味着超过一半的导航流程缺失或出错，你需要手动补充或修正。即便经过DeclarUI的迭代优化，覆盖率提升到了96.8%，但这依赖的是定制化流程，并非开箱即用的功能[1]。
这不仅仅是移动端的问题。一项关于从图像生成CAD（计算机辅助设计）代码的研究发现，虽然他们微调后的模型实现了100%的语法有效性，但3D实体相似度的准确性——即生成模型与预期形状的匹配程度——才是关键指标，而且它仍然不够完美[3]。要点在于：语法错误容易发现，但语义错误（代码能运行却做了错误的事情）才是真正耗费时间的地方。
你花在调试上的时间会比生成代码更多
第二个隐性成本在于需要迭代反馈循环。DeclarUI研究明确采用了“迭代式编译器驱动优化”——也就是说，系统生成代码、编译、发现错误，然后循环修复[1]。这固然很好，但意味着你需要一个可用的构建环境，并且要有耐心等待多轮迭代。同样，一项关于机器人代码生成的研究发现，为了让LLM生成的代码可靠，他们不得不增加一个校正步骤，即模拟代码执行并将结果反馈给模型[2]。他们通过基于文本的模拟来避免使用实体机器人，但这仍然需要构建一个自定义模拟层——这是一笔不小的前期投入。
人在回路这一角度甚至更为直接。一项针对规范驱动代码生成进行实证测试设计的研究发现，开发者必须经历三个阶段——规范、测试和功能——而最终代码的质量在很大程度上取决于人类如何精细地完善测试[5]。这意味着你不能只是输入“给我做个应用”然后就走开；你必须主动引导工具，而这本身就是实实在在的工作。
生成的代码可能不符合您项目的架构
第三个成本是集成。生成的代码往往是一段独立的代码块，但实际项目已有既定的模式、状态管理和API。GIS仪表盘研究通过构建软件工程最佳实践知识库，并采用MVVM（模型-视图-视图模型）等设计模式来生成符合行业标准的代码，从而解决了这一问题[4]。这需要大量额外的机制——检索增强生成、上下文感知提示——仅仅是为了让输出结果可维护。如果没有这些，你可能不得不重构生成的代码，以匹配团队的约定。
CAD研究还指出，他们的模型能够为“微调过程中未见过的操作”生成代码，这很有前景，但也意味着模型的训练数据限制了其能力范围[3]。如果你的设计使用了小众组件或自定义交互，该工具可能会生成其训练集中不存在的代码，这时你就得自己动手编写了。
关于这些来源
本回答基于5项同行评审研究——发表于2025年至2026年，其中5项为2024年或之后发表，合计被引用86次——这些研究是从5项通过质量筛选的研究中选出的最具相关性的成果，而这些研究又源自从超过5亿篇论文的数据库中检索到的41篇文献。
本文引用的文献
DeclarUI：以自动化声明式UI代码生成弥合设计与开发之间的鸿沟
DeclarUI这一结合计算机视觉与大语言模型的系统，将页面转换覆盖率从约44%（当前最先进的多模态大语言模型的水平）提升至96.8%，编译成功率也提高到了98%，但这一成果仅在经过迭代式编译器驱动优化后才得以实现——这表明原始生成结果远未达到生产级可用水平。
基于LLM的纠错机器人操作代码生成与静态文本仿真
LLM驱动的机器人代码生成需要借助基于静态文本仿真的纠正性反馈回路，才能达到与物理实验相当的可靠性，这凸显了执行/仿真环境在捕捉错误方面的必要性。
CAD-Coder：用于计算机辅助设计代码生成的开源视觉语言模型
CAD-Coder是一款经过微调的视觉语言模型，在3D实体相似性方面实现了100%的语法有效性，并超越了GPT-4.5，但对语法有效性的关注也凸显出语义准确性仍是更艰巨的挑战。
从PowerPoint界面草图到Web应用：基于知识增强大语言模型、上下文感知视觉提示与React框架的GIS仪表盘模式驱动代码生成
一种用于从PowerPoint线框生成GIS仪表盘的知识增强框架，采用了检索增强生成和MVVM模式来生成可维护的代码，表明在复杂应用中整合领域知识与软件工程原则是必要的。
理解基于规范的代码生成与大语言模型：一项实证研究设计
一项针对规范驱动代码生成的实证研究设计发现，人类在规范制定和测试细化中的干预显著影响了大语言模型生成代码的质量，这意味着人机协同中的投入是一项隐性成本。