LLM调参玄学破除：3500星Skill告诉你定理证明和代码生成的参数根本不是一回事

LLM 用不好，未必是模型选错了——可能是你参数设错了。

我之前也觉得调参是个玄学，直到看到 APOLLO 和 Godel-Prover 的研究数据才发现：不同任务对 temperature、max_tokens 的敏感程度差异巨大，乱调参数能让模型性能腰斩。今天介绍一个 GitHub 上 3500+ 星的 Skill，专门把这个研究结论封装成了可复用的配置模板——llm-tuning-patterns。

三个任务类型，三套配置逻辑

这个 Skill 把 LLM 调参分成三条赛道，每条都有硬编码的最优参数和理由：

① 定理证明 / 形式推理

代表场景：数学证明、Lean 4 编程、复杂逻辑推导。

• max_tokens → 4096（证明需要足够的 chain-of-thought 空间，512 会被截断）
• temperature → 0.6（需要创意探索不同证明路径，低于 0.2 会错失创新策略）
• top_p → 0.95（允许多样化的证明路径）
• 前置 Prompt：用 Proof Plan 模式，让模型先写出高层证明计划再开始写 tactics

② 代码生成

代表场景：自动补全、函数实现、代码翻译。

• max_tokens → 2048（大多数函数体足够用）
• temperature → 0.2–0.4（确定性输出，减少随机 hallucination）

③ 创意 / 探索任务

代表场景：头脑风暴、多方案探索、开放性写作。

• max_tokens → 4096（留足探索空间）
• temperature → 0.8–1.0（最大创意自由度）

一个反直觉的结论

研究里最反直觉的一条：代码生成不需要高 temperature，推理证明反而不能太低。直觉上我们都怕模型”瞎编”，所以代码生成时倾向于保守，但定理证明任务里，偏低 temperature 会让模型执着于常见策略而错过创造性的证明路径。

Proof Plan 的前置模式也很有意思——让模型先”说出计划”再执行，chain-of-thought 的质量提升显著，相当于把推理过程外化，降低遗忘中间步骤的风险。

怎么用

把 llm-tuning-patterns 加入 Claude Code 的 Skills 目录，在执行对应任务前切换到该 Skill，它会自动注入最优参数配置和 Prompt 模板。配合 Parallel Sampling（一次生成 8–32 个候选再用 best-of-N 选最优），复杂证明的成功率能再上一个台阶。

项目在 GitHub 上是 parcadei/Continuous-Claude-v3 的子模块，整个仓库是一套持续学习的 Claude Code 开发环境，Skills 目录里有 109 个可复用 Skill，llm-tuning-patterns 是其中之一。

如果你经常在代码和推理任务之间切换，或者想让自己的 Claude Code 输出更稳定——这个 Skill 值得加进日常工作流。

GitHub: https://github.com/parcadei/Continuous-Claude-v3