Specification-Based Code-Text-Code Reengineering for LLM-Mediated Software Evolution
我在 arXiv 上搜"semantic drift"，找到了这篇论文。
作者是 EPAM Systems 的工程师 Vasyl Yaremovych 。他在做一件很实际的事：用 LLM 把代码从语言 A 转换到语言 B，比如 Python 转 Java，或者 SQL 方言互转。
这听起来很普通，但论文开头第一句话就抓住了我：
"Direct code-to-code transformation remains challenging to control because it can preserve surface-level syntax while introducing semantic drift."
直接做 Code2Code 转换，表面语法能保留，但意思可能已经悄悄变了。
这不就是我在界面层看到的问题吗？
1. 不是翻译，是重工程
论文的核心不是"怎么让 LLM 写更好的代码"，而是"怎么让 LLM 在转换代码时，不丢失意思"。
作者发现，直接给 LLM 一段 Python 代码，让它生成 Java 代码，会出现四种问题：
- 语法对了，但意思变了：Python 的列表推导式被翻译成 Java 的 for 循环，语法没问题，但副作用、数据依赖、异常处理逻辑可能全变了
- 模型自己加戏：LLM 会"脑补"缺失的信息，实现一些原始代码里没有的行为
- 业务语义丢失：生成的代码看起来能跑，但业务逻辑、数据约束、非功能需求被丢掉了
- 可追溯性断裂：你不知道生成的 Java 代码对应 Python 代码的哪一行，出了问题无法归因
这和我们每天看到的问题一模一样。
代码层：LLM 把 Python 转 Java，语法对了，语义漂移了。
语义层：LLM 生成一个"删除账户"按钮，颜色对了，语义漂移了——蓝色实心而不是红色空心，没有二次确认，用户一点，账户没了。
两者都是"表面合规，语义漂移"。
2. 在转换之间，加一层规范
作者的解法不是优化 Prompt，也不是换更强的模型。他们的解法是在 Code 和 Code 之间，加一层 Text Specification（中性文本规范）。
流程变成：
Code（源代码） → Text Specification（中性文本规范） → Code（目标代码）
这层 Text Specification 不是普通的注释或文档，而是一份受控的语义表示：
"a neutral textual specification that captures program behavior, identifiers, computational flow, conditions, side effects, data dependencies, and domain-specific intent without directly transferring the source language syntax"一份中性的文本规范，捕获程序行为、标识符、计算流、条件、副作用、数据依赖和领域特定意图——但不直接转移源语言的语法。
作者在代码层，我在语义层。
作者：Code（源代码）
我：设计意图（设计师脑子里的"这个场景下不能做什么"）
作者：Text Specification（中性文本规范）
我：语义契约（YAML 规则文件）
作者：Code（目标代码）
我：AI 生成的界面/代码
作者：语义漂移（semantic drift）
我：意思跑偏（删除按钮变蓝色、Critical 变严重）
两者都在做同一件事：在"生成"之前，先把"意思"固定下来。
我吸取了论文的核心设计方法：在转换链条中插入一层受控的规范层，把"意思"和"语法"解耦。
论文用自然语言规范来解耦代码语法和代码语义。我用 YAML 语义契约来解耦界面样式和界面语义。样式可以变，但语义必须被规范锁住。
3. 三个确认
3.1. 确认 1：语义漂移不是边缘 case，是结构性必然
论文做了大量实验，覆盖 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 不是"测试工具"，而是验证约束是否生效的审计层。它回答"加了约束后，漂移有没有被拦住"。
三层合在一起，不是三个独立工具，而是一个受控的语义约束流程：
设计意图（Schema-As-Code）→ 可执行约束（Constraint as Code）→ 审计验证（Validation Toolkit）
论文的 Code-Text-Code 是代码层的"规范驱动重工程"。我的三层架构是语义层的"规范驱动重工程"——对象从代码换成了按钮、文案和错误状态，但根因和解法哲学完全一样。
当 AI 生成界面时，设计意图在偏离。我不是在做一个"把规范写成 YAML"的工具，我是在建立一套让语义漂移被拦截的语义约束流程。
六、一句话总结
Vasyl Yaremovych 在代码层证明了：LLM 做转换时，表面语法对了，语义会悄悄漂移。解法是在中间加一层"规范"，把意思和语法解耦。
我在语义层做的，是同一个根因、同一个解法哲学——只不过对象从代码换成了按钮、文案和错误状态。
不是只做一个工具，而是建立一套语义约束流程：Schema-As-Code（把设计意图固定下来）→ Constraint as Code（把意图变成可执行的约束）→ Validation Toolkit（验证漂移有没有被拦住）。
当 AI 生成界面时，设计意图在偏离。语义层也需要一道闸门。
