一次失败的代码生成工程：对模型时代工程范式的再思考

在过去一个月，我尝试用 AI 自动将老旧系统的前端页面迁移到最新 Vue 框架。为此，我设计了一套基于 YAML 的规范——将页面结构显式描述为配置文件，再让 AI 在严格约束下生成代码。初衷很明确：通过结构化输入压制模型幻觉，提升输出稳定性。

转折出现在使用 Cursor 时。我本想测试提示词系统在不同模型下的可靠程度，却意外发现：仅凭一张老系统截图 + 一句简单指令，模型生成的代码质量竟远超整套 YAML 方案。而就在三个月前，同样的操作还产出大量自相矛盾、调用不存在函数的垃圾代码。

那一刻我意识到：不是我的工程做错了，而是问题本身被模型的进化“抬走了”。我精心构建的中间结构，非但不再必要，反而成了累赘。

冷静下来后，我明白：当初引入 YAML，并非出于对“结构”的迷信，而是因为当时的模型能力确实需要它。

它的核心作用，是将模糊的业务意图和视觉信息，翻译成模型能稳定解析的显式结构。本质上，这是用人工中介来对抗模型的不确定性——把“生成代码”降级为“结构翻译”。从这个角度看，YAML 并非目标，而是一种阶段性的补偿机制。

这种“中间层”的兴衰，在技术史上早有先例。以自动驾驶为例，早期系统依赖感知→规划→控制的显式模块链，每个环节都可独立验证、调试；而如今头部厂商正全面转向端到端模型——直接从传感器输入映射到控制指令。

表面看是架构简化，实则是评估标准的迁移：过去我们评估“感知模块是否准确识别车道线”，现在则评估“模型在真实道路场景下的整体行为是否安全”。中间模块并未消失，而是被内化为训练数据中的隐式约束，其价值从“可解释组件”转变为“风险边界定义工具”。

同理，我的 YAML 方案也曾是前端生成任务的“可解释组件”；但当模型能直接将截图解析成结构，理解意图并生成可靠代码时，工程的重点就不再是“如何表达需求”，而是“如何界定和兜住失败边界”。

由此可得一个更清晰的判断：工程的价值重心正在转移。
为模型“翻译世界”的工作（如设计 DSL、编写提示模板、构建中间表示）正在快速贬值；而为真实世界“兜底”的工作（如定义验收标准、构建回归测试、监控生成结果的业务合规性）反而愈发关键。

换言之，工程师的角色，正从需求的表达者，转向风险的管理者。

那么，在模型能力指数级演进的时代，人的工作还有意义吗？
有意义——但意义不再来自建造“永恒的抽象”，而在于在不确定性中划出确定的边界。
我们的价值，恰恰体现在那些“注定会被淘汰”的中间表示中：它们虽短暂，却是模型走向可靠的必经跳板。如果让我再做一次这个迁移项目，我会直接从截图开始生成代码，但我会把大部分精力投入到构建失败场景的回归测试和风险边界的定义上，以确保生成结果的可靠性。