大模型：用科学实验的方式使用

工程习惯里，人们常把大模型近似成确定性函数：输入 Prompt，输出 Answer。这个近似有用，但不完整。

一次调用真正依赖的，通常是 Prompt、Context、Model、History，以及解码时的采样设置。即使把温度调到很低，输出仍可能随上下文组织、示例选择、工具描述与历史截断而漂移；温度高于零时，同输入多次采样还会叠加随机性。

更稳妥的对照是：

传统软件（常见工程假设）
Input → Deterministic Logic → Output

大模型调用（更贴近现实的描述）
Prompt + Context + Model + History + Decoding
        → Conditional Distribution
        → One Sample / One Trajectory

因此，高价值问题往往不是「为什么这一次错了」，而是「在哪些可陈述的条件下，正确率、稳定性与成本更优」。目标从「找到一句神奇 Prompt」，转向「估计并改善一组条件」。

说明边界：并非每次聊天都要上完整实验协议。代价高、可复用、要上线或要多人协作时，实验思维才真正划算。

把使用过程做成可对照的实验

承认条件敏感之后，用法就靠近实验科学，而不是靠感觉连改 Prompt：

1. 提出假设（Hypothesis）
2. 设计实验（Design）
3. 控制变量（Control Variables）
4. 运行足够样本（Run）
5. 记录结果（Record）
6. 对照比较（Compare）
7. 得出有范围的结论（Conclude）
8. 迭代改进（Iterate）

以「规则放置位置」为例。同一规则分别放在系统指令顶部、用户消息中段、输出前最后一句，或拆成多轮约束，记为实验 A–D。每次尽量只改位置这一类变量，并固定：模型版本、解码参数、评测集、成功判定。若解码仍有随机性，同一条件应重复采样，报告的是分布或区间，而不是单次运气。

建议至少记录：

• Success Rate（相对明确的成功判定）
• Error Type（失败如何分型）
• Cost / Latency
• Consistency（同条件多次采样的离散程度）

这时结论应写成：「在数据集 D、模型 M、参数 Θ 下，条件 A 的成功率为 x±…，相对基线 B 的增益为 …」——而不是「这条 Prompt 永远更好」。Prompt Engineering 由此长成 Experiment Engineering：可陈述、可对照、可复现（在供应商与模型版本不变的前提下尽可能复现）。

还要注意两类常见混淆：

• 解码随机性：同输入多次采样不同。
• 条件敏感性：换位置、示例或工具描述后分布平移。

二者都会造成「不稳定」，机制不同，对策也不同。

桥接到复杂系统：优化的是条件，不是单次答案

这与另一篇 Diverse Lab 笔记——物理学 × 生态学——是同一条弧。偏物理的工程直觉喜欢「给定 A，得到 B」；偏生态与复杂系统的直觉更接近：A 提高 B 出现的概率。

单个 Chat 调用，还谈不上完整「生态系统」；但一旦把工具、记忆、多步轨迹、环境反馈叠上去，系统行为就更接近条件依赖的概率过程。此时优化对象通常不是某一次 Answer B，而是在约束、成本与延迟下的表现分布——可用 P(success | conditions) 来记，其中 success 必须被事先定义，且往往是多维的（正确、安全、成本、时延）。

把一次漂亮回答当成终局，等于用单次采样冒充稳定规律。

Proxy Metric ≠ Real Outcome

实验还有第二个陷阱：代理指标不等于真实结果。

测试集全绿，用户问题仍可能未解决；格式校验通过，业务目标未必推进；模型自评很高，Held-out 可能一塌糊涂。可用的评测至少要意识到三条线：

• User / Task Outcome：真实任务是否完成
• Held-out：未参与调参与选型的样本
• Ground Truth / Executable Checks：可核对事实或可执行断言（若存在）

现实里 Ground Truth 常常缺失。这时仍可用 Proxy，但必须显式记录 gap：proxy_success 与 perceived_real_outcome 是否一致。否则系统会优化「看起来像对」的分布，甚至学会 Reward Hacking。

从单次回答到 Loop Engineering

当系统开始带着目标行动，单轮 Prompt → Answer 往往不够。更完整的闭环是：

Goal → Action → Observation → Gap → Adjustment

这就是 Loop Engineering：把反馈写进运行时，而不是只写进一次性措辞。Gap 不是耻辱，而是下一轮策略的输入。

一个自然延伸是外层策略优化（Agent / Policy Optimizer）：不必然先改模型权重，而是用轨迹（trajectory）与真实结果，调整何时检索、何时调用工具、何时停止、如何改写下一轮假设。权重可以固定；变的是策略、记忆、评测与环境交互协议。这是否有效，仍要用对照实验证明，而不是用叙事证明。

五层方法论

把上面压缩成可迁移的五层（第 5 层是尺度放大后的工程对象，不是每条任务的必经之路）：

1. 先承认条件依赖与概率性。 LLM 不宜默认成确定性函数。
2. Prompt Engineering → Experiment Engineering。 假设、对照、记录、有范围的结论。
3. Output → Evaluation → Real Outcome。 Proxy 必须能解释与真实结果的差距。
4. Execute → Feedback → Gap → Improve → Execute Again。 闭环优先于单次调用。
5. Model → Agent → Runtime → Multi-Agent → Environment → Feedback → Evolution。 参与者与反馈变多后，才更接近 Complex System Engineering。

一份可复用的实验模板

对高风险、可复用或要上线的任务，先写短模板：

• 问题：要解决什么
• 目标：成功长什么样（可判定）
• 已知 / 未知：边界与前提
• 假设：改变什么可能改善目标分布
• 基线：当前最好方案（必须先有）
• 实验：变量、对照、样本量、是否只改一个因素
• 工具：检索、代码、评测器、日志、回放
• 指标：Success / Error / Cost / Latency / Consistency + 真实结果（或 proxy + gap）
• 反例：故意找会翻车的输入
• 复现：模型版本、解码参数、上下文快照、数据版本
• 沉淀：结论写回策略库，而不是散落在聊天记录里

工具与角色分工往往比「再写一句更妙的 Prompt」更能压偏差：假设提出者、执行者、评测器、反方审稿人分开，可降低自我证明。

在需要可靠结果的场景里，使用大模型更接近做一种概率性的科学实验：提出假设、控制变量、观察结果、验证反馈，然后在可陈述的条件下迭代——而不是把一次采样当成确定性函数的返回值。

当系统开始具备目标、行动、记忆与反馈，工程对象就容易从 Prompt Engineering 扩展到 Loop Engineering；参与者与环境互动足够复杂时，才会逼近 Complex System Engineering。