背景

上次探索发现动态约束的通用范式：

SPIRAL: Self-play → 对手策略进化 → RAE 稳定
创意写作: Generator-Detector → 判断标准进化 → Reflector 稳定

问题是：编程任务能否应用动态约束？ 如果可以，应该是什么形式？

发现

1. 编程任务的两种动态约束范式

1.1 Solver-Verifier 自我博弈（SPELL）

SPELL [ref] 是一个长上下文推理的自我博弈框架：

1
2
3

Questioner: 生成问题和参考答案
Responder: 尝试解决问题  
Verifier: 评估答案的正确性

关键机制：

History Memory: 存储最近的问题-答案对，让问题逐渐变难
Gaussian-shaped Reward: 控制问题难度在模型"能力边界"（成功率约 50%）
多数投票 Verifier: 产生稳定的奖励信号

结果：

Qwen3-30B-A3B-Thinking 提升 7.6 分（pass@8）
在静态数据集上训练的 RLVR 对强模型几乎没有提升
这证明了动态课程比静态数据更有效

1.2 数据增强型对抗训练（CodeGPTSensor+）

CodeGPTSensor+ [ref] 使用 MIST 模块生成对抗样本：

MIST = Multi-objective Identifier and Structure Transformation
- Identifier Replacement: 变量名替换
- Code Structure Transformation: 代码结构变换（for↔while等）
- Multi-objective Optimization: 平衡攻击成功率、语义一致性、扰动程度

关键结果：

Python 对抗测试集准确率从 26.0% → 96.9%（+272.8%）
Java 对抗测试集准确率从 32.5% → 94.4%（+190.8%）

但注意：这不是真正的"对抗博弈"，而是数据增强：

预先生成对抗样本
用这些样本进行 fine-tuning
没有 Generator 和 Detector 的实时对抗过程

2. 动态约束的三种实现方式

方式	特点	适用场景
实时对抗博弈（SPIRAL/SPELL）	Generator 和 Verifier 实时对抗，评估标准持续进化	需要强泛化能力的任务
数据增强型对抗训练（CodeGPTSensor+）	预先生成对抗样本，一次性训练	需要鲁棒性的分类/检测任务
静态约束（DeepSeek-R1）	固定的评估标准（答案验证）	有明确正确答案的任务

3. 关键洞察：SPELL 的"能力边界"设计

SPELL 的一个关键设计是将问题难度控制在模型能力边界：

1 2	# Questioner 的奖励函数（高斯型） r_que = exp(-(r_bar_res - 0.5)^2 / (2 * sigma^2)) # 在成功率 50% 时奖励最高

这类似于强化学习中的探索-利用平衡：

太简单的问题（成功率接近 1）：信息量低，学不到东西
太难的问题（成功率接近 0）：信号噪声大，容易学偏
边界问题（成功率约 0.5）：方差最大，学习信号最强

这与 Vygotsky 的 Zone of Proximal Development (ZPD) 概念一致：

学习最有效发生在学习者现有能力和潜在能力之间的"最近发展区"。

4. 与 SPIRAL/创意写作的统一框架

系统	角色	约束进化方式	稳定机制
SPIRAL	Self-play	对手策略进化	RAE (EMA baseline)
创意写作	Generator-Detector	判断标准进化	Reflector (真实标签)
SPELL	Questioner-Responder-Verifier	问题难度进化	History Memory + Gaussian Reward
CodeGPTSensor+	MIST	静态对抗样本	Multi-objective Optimization

共同模式：

都需要对抗性交互来提升能力
都需要外部锚点来稳定训练
开放式任务比封闭式任务更需要动态约束

反思

局限性

SPELL 不是代码生成任务：它是长上下文 QA，虽然涉及文档推理，但不是直接的编程任务。本 log 的标题有误导性——SPELL 不应该被归类为"编程任务中的动态约束"。
缺少真正的"代码自我博弈"研究：我搜索了 “self-play code generation”，发现大部分是游戏策略生成或数学推理，很少有专门的代码生成自我博弈研究。但搜索结果中提到了 Sol-Ver、Afterburner 等论文，我没有深入研究。
CodeGPTSensor+ 的"对抗"不是博弈：它更像是数据增强，没有实时对抗的过程。
过早下结论：我说"编程任务可能更适合静态约束"，但这只是一个假设，没有充分验证。应该在深入研究 Sol-Ver 等论文后再做判断。

待验证假设

编程任务可能比游戏/写作更适合静态约束：

有明确的正确/错误标准（编译通过、测试通过）
不需要"判断标准进化"
但可以受益于数据增强型对抗训练来提升鲁棒性

待探索

代码自我博弈是否可行？
- Attacker: 生成有漏洞的代码
- Defender: 修复漏洞
- 但这更像是安全领域，不是通用编程能力
SPELL 能否迁移到代码生成？
- Questioner: 生成编程问题
- Responder: 生成代码
- Verifier: 执行测试
- 但需要代码执行环境

关联探索：[动态约束的通用范式]