精读笔记

Problem Setting

这篇论文的真实问题不是轨迹优化求解，而是 OCP reformulation automation：给定一个已经存在的凸轨迹优化代码和数学描述，当 mission requirement 以自然语言新增时，能否自动合成正确的数学约束和可执行 solver 代码。难点在于这个映射同时跨越三个空间：任务语义、优化建模语言、具体代码实现。任何一个环节错位都会导致代码运行失败、约束语义错误、轨迹不满足需求，或者破坏凸性。

以前的学习式 spacecraft guidance 多数是在固定问题族内学习策略、warm-start、trajectory prior 或参数化映射；它们擅长快速求解或生成轨迹，但不擅长改变问题定义。传统凸优化/SCP 框架理论上能表达很多约束，但需要专家手工把需求写成 admissible constraints。关键矛盾是：mission-level adaptability 要求开放式约束表达，而 safety-critical optimization 又要求形式化、可验证、solver-compatible 的封闭结构。本文试图在两者之间放一个 LLM semantic compiler。

Motivation

已有路线不够的地方在于它们通常假设约束集合已经被设计好：planner 接受参数，optimizer 接受数学模型，learning policy 接受训练分布内的 condition。现实任务变化往往不是简单参数变化，而是“在中段保持观测距离”“前 75% 轨迹必须在目标后方”“前半程 Delta-V 受限”这类半结构化需求。把这些需求落到变量、时间索引、坐标系和范数约束上，仍然是人类专家工作。

作者的核心观察是：LLM 的价值不一定是替代 optimizer，而是替代一部分 formulation labor。换言之，LLM 不需要学会轨道动力学求解，只需要在足够上下文下识别已有 OCP 的变量语义，并生成局部约束增量。这也是为什么本文强调 structured input：如果不给 baseline formulation，模型只是在猜变量和语义；给了 formulation 后，任务变成受约束的代码合成。

Core Idea

核心思想可以概括为：不要让语言模型直接生成轨迹，也不要让它从零生成优化问题，而是让它在已有 OCP 的数学/代码上下文中合成“约束补丁”。这相当于把自然语言需求编译为对 g(x,u) 和 h(x,u) 的增量修改。这个建模方式的关键收益是保留了凸优化求解器的可靠性，同时把开放式语义适配限制在较小的、局部的 synthesis 空间里。

它引入的 inductive bias 很明确：baseline LaTeX formulation 提供语义 grounding，baseline code 提供 API 和变量结构 grounding，mission requirement 只负责指定新增行为。相比 text-to-trajectory 或 language-conditioned policy，这种方法不把安全性寄托在生成模型的轨迹分布上，而是把 LLM 输出再次投影到 solver constraint space。相比传统 expert reformulation，它把专家知识显式编码在 baseline formulation 和 code scaffold 中，让 LLM 做局部组合与翻译。这也是它可能 scalable 的地方：如果 baseline 表达足够规范，很多新需求可作为约束 patch 被增量接入。

Method

方法的关键不是两次调用 LLM，而是如何限制 LLM 的自由度。

第一，structured input 解决 grounding。Base OCP code 告诉模型变量名、数组维度、CVXPY 写法和插入位置；Base OCP formulation 告诉模型这些变量在动力学/坐标系中的含义；mission requirement 给出新增约束意图。没有 formulation 时，模型很可能生成语法上接近但语义错位的代码，这一点实验非常明显。

第二，数学中间表达试图解决 compositionality。先生成 LaTeX 约束，再生成代码，理论上能把复杂 requirement 拆成可审查的 formal representation，也方便后续做凸性检查、verification 或 human-in-the-loop review。但在本文实验的简单 convex cases 中，这一步没有体现出决定性收益，甚至可能因为中间表达遗漏实现细节而引入错误。

第三，solver execution 和 behavior validation 是必要闭环。代码可执行不等于语义正确；轨迹满足自然语言目标才算成功。这个闭环让 pipeline 从“代码生成 demo”稍微靠近“constraint synthesis system”，但目前验证规则仍是任务特定的，文中未充分说明如何泛化为开放需求的自动验证。

Key Insight / Why It Works

这篇论文最重要的结论其实不是“LLM 能推理轨迹优化”，而是“LLM 在强上下文约束下可以可靠地产生局部 OCP 约束代码”。有效性的主要来源很可能是 representation alignment，而不是深层 optimal-control reasoning。baseline formulation 把自然语言中的“middle of trajectory”“behind target”“relative RTN position”等短语绑定到离散索引、坐标变换 Ψ_k、状态变量 x_k；baseline code 把这些绑定进一步落到 CVXPY 对象和数组切片。LLM 做的是把这些已有符号重新组合。

最可能的核心贡献是 structured context + incremental constraint patching。没有 OCP formulation 的结果几乎崩溃，说明模型缺的不是 Python 能力，而是任务语义 grounding。full-input single-shot 表现很好，说明只要上下文足够，当前大模型已经能完成简单 convex constraint 的直接 code synthesis。

数学中间层的贡献在本文中增益来源不清。作者的长期论点是 complex requirement 需要 intermediate representation，但实验只用了三个直接凸约束，不能证明这个论点。当前证据反而表明 two-stage 可能不是必要机制；在简单场景中，它只是增加一次信息压缩，可能丢失实现细节。它未来可能有价值，但需要在嵌套时序逻辑、非凸约束凸化、多约束依赖、单位转换和可行性冲突上证明。

这也不是典型 scaling result，虽然使用 GPT-5.2 / GPT-4.1-mini 显然受益于大模型已有代码和优化建模数据覆盖。更准确地说，这是 test-time contextual synthesis：把已有 formulation 当作 prompt-time memory，把 LLM 当作一个 flexible compiler。若模型训练数据中已有大量 CVXPY 和类似 OCP 模板，所谓 reasoning 可能相当一部分是 pattern retrieval + local adaptation。文中未充分排除 implicit memorization 或 template overlap。

Relation To Prior Work

最接近的谱系有三条：NL-to-optimization formulation、NL-to-temporal logic/formal specification、language-conditioned robotic planning/control。本文和 NL4Opt 类工作的相似点是从自然语言抽取约束；不同点是它不是从零建立 OR problem，而是在已有 dynamical OCP 中做增量约束合成，变量语义依赖领域 formulation。和 NL-to-STL/LTL 的相似点是把语义需求形式化；不同点是输出不是逻辑公式再交给 controller，而是直接进入 convex OCP 的约束集合。和 language-conditioned trajectory generation 的不同点更本质：本文不生成轨迹分布，而是生成优化问题本身。

看似新的部分中，two-stage math-to-code 并不新，本质上是 formal IR / chain-of-thought / code synthesis 的重组。实质更有价值的是把这套接口放到 spacecraft convex OCP 中，并强调 baseline formulation 作为 semantic grounding object。它不是提出新的优化算法，也不是新的 LLM architecture，而是一种 domain-specific compilation pipeline。它的新增信息主要是：在轨迹优化工作流中，问题上下文的显式结构化比 prompting trick 更关键。

Dataset / Evaluation

评估范围很窄：单一 spacecraft rendezvous case，固定初末状态、固定 horizon、固定 ROE/RTN 转换设定，三个自然语言 requirement，且所有 requirement 都可直接写成凸约束。没有跨动力学模型、跨任务类型、跨 solver、跨代码库、跨坐标表达，也没有真实 onboard deployment 或 high-fidelity closed-loop test。

实验支持的 claim 是有限但清楚的：给定规范化 baseline OCP，上下文充分的大模型可以高概率生成可执行且语义正确的简单 convex constraint patch。实验不支持更强的 claim，例如“复杂 mission requirement 可自动形式化”“LLM 能稳健处理非凸/逻辑/时序约束”“framework 已具备 operational adaptability”。

消融设计有价值，因为它直接暴露了 base formulation 的作用。但 benchmark 太小，且 prompts 与目标约束都非常接近 textbook CVXPY 表达；成功率很可能高估真实部署表现。尤其是 validation 是针对三个已知需求写的，不能说明开放世界需求下系统能自证正确。

Limitation

最大限制是方法把难题从“专家写约束”转移为“专家提供足够好的 baseline formulation、代码 scaffold 和 validator”。如果这些上下文不完整、不一致或工程代码复杂，LLM 的可靠性会显著下降。文中没有展示在大型 OCP 代码库、非标准命名、多文件项目或隐式变量封装下的表现。

第二，凸性和可行性没有被系统处理。论文选择的约束都可直接凸实现，绕开了最难的问题：自然语言需求常常引入非凸几何、逻辑触发、避障、时间窗口选择、mixed-integer 结构或 state-triggered constraints。作者把 automatic convexification with formal verification 放到 future work，说明当前 pipeline 没有真正解决 safety-critical formulation 的核心风险。

第三，泛化可能主要来自数据覆盖和模板复用。CVXPY 约束生成、范数约束、索引窗口、数组切片都是 LLM 训练中高度常见的模式。当前实验无法区分模型是否理解航天任务语义，还是在完整上下文下做高质量 code completion。

第四，two-stage 的必要性未被证明。中间数学表达在本文反而不是性能瓶颈的解法；它的价值更多是可审查性和未来 formal verification 的接口，而非当前实验中的性能来源。

第五，真实 deployment 鸿沟很大。航天任务要求 traceability、unit consistency、constraint qualification、failure diagnosis、可行性恢复和 certification。本文 pipeline 还没有说明如何处理错误约束导致 infeasibility、如何解释冲突需求、如何保证不破坏原 safety constraints，也没有 runtime assurance 机制。

Takeaway

• 1. 对 OCP 自动建模而言，最有迁移价值的 insight 是：LLM 需要被放在已有数学 formulation 和代码 scaffold 的双重上下文中，才能从自然语言稳定生成 solver-compatible 增量约束。
• 2. 这类方法的核心不是替代 optimizer，而是把 formulation layer 做成可编译接口；未来 trajectory optimization 工具链可能会把“任务需求文档 → formal constraint patch → solver verification”作为标准闭环。
• 3. 数学 IR 的真正价值不应只看生成成功率，而应体现在可审查、可验证、可凸化、可诊断上。
• 若后续不能接入 convexity checking / formal verification，它只是 prompting 结构。

一句话总结

这篇论文把 LLM 用作 spacecraft convex OCP 的上下文约束编译器，真正贡献是证明 structured formulation grounding 对自然语言到优化约束的可靠生成至关重要，而不是提出新的轨迹优化算法。