基于规范的代码-文本-代码重工程方法，助力大语言模型实现软件演化
这篇论文的发现，可能比它表面的技术细节更具冲击力。它来自EPAM Systems的工程师Vasyl Yaremovych，研究的是一个非常实际的问题：利用大语言模型（LLM）将代码从一种编程语言翻译成另一种，例如从Python转换为Java，或者在多种SQL方言之间切换。听起来很普通？但论文开篇就揭示了一个令人不安的观察：
"直接进行代码到代码的转换，很难控制——它可能保留了表面的语法，却悄悄引入了语义漂移。"
表面上，语法完全正确，但核心含义已经“跑偏”。这不正是我们每天在界面层面临的困境吗？
1. 不是翻译，而是重工程
这篇论文的核心，不在于“如何让LLM写出更好的代码”，而在于“如何让LLM在转换代码时，不丢失原有的业务含义”。作者发现，如果你只是丢给LLM一段Python代码，让它生成Java，典型的问题有四种：
- 语法正确，但语义改变：Python的列表推导式被翻译成Java的for循环，语法完全正确，但副作用、数据依赖、异常处理逻辑可能都发生了变化。
- 模型自行“加戏”：LLM会“脑补”缺失的信息，实现出一些原始代码中完全没有的行为。
- 业务语义丢失：生成的代码看起来能运行，但业务逻辑、数据约束、非功能需求被丢弃了。
- 可追溯性断裂：你不知道生成的Java代码对应Python的哪一行，出现问题根本无法归因。
这不就是我们每天看到的问题吗？在代码层，LLM把Python转Java，语法对了，语义却漂移了。在语义层，LLM生成一个“删除账户”按钮，颜色对了，但语义也漂移了——黑色实心而非红色空心，没有二次确认，用户一点下去，账户直接没了。两者都是“表面合规，内部跑偏”。
2. 在转换之间，增加一层规范
作者给出的解法，不是去优化提示词（Prompt），也不是换一个更强的模型。他们的思路是在源代码和目标代码之间，插入一层中性文本规范（Text Specification）。
流程变成了这样：
这层规范，不是普通的注释或文档，而是一份严谨的语义表示：“一份中性的文本规范，捕获程序的行为、标识符、计算流、条件、副作用、数据依赖和领域特定的意图——但不直接复刻源语言的语法。”
如果把作者在代码层的做法，与我们在语义层的做法进行对比，会看到惊人的平行关系：
- 作者的起点：源代码 → 我们的起点：设计意图（设计师脑子里“这个场景下不能做什么”）
- 作者的中间层：中性文本规范 → 我们的中间层：语义契约（YAML规则文件）
- 作者的终点：目标代码 → 我们的终点：AI生成的界面/代码
- 作者要解决的：语义漂移 → 我们要解决的：意思跑偏（删除按钮变蓝色、Critical状态变严重）
虽然是两个不同的领域，但做的其实是同一件事：在AI“生成”之前，先把“意思”固定下来。作者用自然语言规范来解耦代码语法和代码语义，我们用YAML语义契约来解耦界面样式和界面语义。样式可以变，但语义必须被规范锁住。
3. 三个确认
3.1. 确认 1：语义漂移不是边缘情况，而是结构性必然
论文做了大量实验，覆盖Java、C、Python、SQL等多种语言和方言。结果非常明确：任何的Code2Code转换，都会引入语义漂移。这说明，漂移不是某个特定模型的Bug，而是LLM在做“转换”这件事时内生的属性。概率采样机制决定了，LLM天生就习惯“变着花样说”，表面上的语法可以完全正确，但语义悄悄跑偏是无法避免的。
我们在日常工作中看到的“Critical→严重”、“删除按钮变蓝色”，和论文在代码层看到的“副作用丢失”、“数据依赖断裂”，根因其实一模一样。
确认 2：“中间规范层”是学术界认可的解法方向
论文并没有说“用更好的Prompt来消除漂移”，而是建议加一层规范，把“意思”和“语法”解耦。这和我们放弃“用更好的Prompt来约束AI”、转而做语义契约的思路完全一致。Prompt是请求，不是约束。规范层才是约束。
论文还做了对比实验：直接转换 vs. 伪代码中间层 vs. 自然语言中间层 vs. 图中间层 vs. 编译器中间层。结果很清楚：对于LLM来做转换，自然语言中间层是最优选择。这也进一步印证了我们的选择：YAML作为自然语言与结构化数据的混合体，是语义层最合适的中间规范格式。
确认 3：验证必须是闭环的，不能只有生成没有检查
论文提出的框架包含：Code2Text生成 → 迭代验证 → Text2Code生成 → 目标代码验证 → 转换损失估计。这和我们那四个环节（看组件识别状况 → 找原因确定模式 → 写规矩让机器能懂 → 做测试证明有效）在结构上完全一致。两者都在强调：不能只有“生成”，必须有“验证”，而且验证要能量化损失。
4. “规范驱动重工程”在不同领域被验证
论文的Code-Text-Code架构，本质上是一种“规范驱动重工程”的设计方法。这种方法并不局限于代码迁移，它已经在不同领域得到了验证：
- 代码层（EPAM Systems）：在Python和Java之间做迁移，用中性文本规范锁住业务语义，防止语法转换时意思跑偏。
- 数据层（阿里云）：在《构建可审计、可进化的AI Agent底座》中，用约束基建（Constraint Infrastructure）锁住数据定义和业务流程，防止数据Schema漂移。
- 语义层（我们）：在AI生成界面时，把设计规范写成代码格式（Schema-As-Code），锁住设计意图，防止按钮颜色、文案、错误状态的意思跑偏。
三者是同一套设计方法在不同层级的实现：
- 代码层：规范锁住代码语义
- 数据层：规范锁住业务规则
- 语义层：规范锁住设计意图
关键洞察已经显现：规范层不是某个领域的特例，而是AI时代的通用基础设施。当AI参与生成内容时，无论是代码、数据、界面还是文案，都需要一层规范来防止“表面合规，内部跑偏”。
5. 从论文到认知跃迁
在读这篇论文之前，关于自身工作的定位相当朴素：Schema-As-Code是一个工具，用来把设计规范写成机器可读的格式，就像把语雀文档翻译成YAML，让机器能看懂。
读完之后，这个定位显然窄了。作者把LLM辅助的代码转换，从“直接生成”重新定义为“受控的重工程过程”。他们不是在优化一个翻译工具，而是让转换过程中的语义漂移被规范层拦截。
把这个思路搬到语义层，可以重新理解正在做的三件事：
- Schema-As-Code不是一个“把文档写成代码格式”的活儿，而是在AI生成之前，先把设计意图固定下来。它是规范层，回答“这个场景下意味着什么”。
- Constraint as Code不是“写规则文件”，而是把意图变成可执行的约束。它是契约层，回答“绝对不能做什么、必须做什么”。
- Validation Toolkit不是“测试工具”，而是验证约束是否生效的审计层。它回答“加了约束后，漂移有没有被拦住”。
三层合在一起，不是一个独立工具，而是一个受控的语义约束流程：
论文的Code-Text-Code是代码层的“规范驱动重工程”，这三层架构则是语义层的“规范驱动重工程”——对象从代码换成了按钮、文案和错误状态，但根因和解法哲学完全一样。当AI生成界面时，设计意图正在偏离。这不是在做一个“把规范写成YAML”的工具，而是在建立一套让语义漂移被拦截的语义约束流程。
6. 一句话总结
Vasyl Yaremovych在代码层证明了：LLM做转换时，表面语法对了，语义会悄悄漂移。解法是在中间加一层“规范”，把意思和语法解耦。
在语义层做的，是同一个根因、同一个解法哲学——只不过对象从代码换成了按钮、文案和错误状态。
不是只做一个工具，而是建立一套语义约束流程：Schema-As-Code（把设计意图固定下来）→ Constraint as Code（把意图变成可执行的约束）→ Validation Toolkit（验证漂移有没有被拦住）。
当AI生成界面时，设计意图在偏离。语义层也需要一道闸门。
