同一个提示词，两次结果差很远？AI 任务可复现的 5 个固定项

同一提示词得到不同结果，可能与随机采样、输入上下文、模型与服务环境等因素有关。记录输入、参数、版本、步骤和验收，有助于比较差异，但不能保证完全复现。

这不是模型"抽风"。生成式模型每次都在重新采样，除非你主动把变量按住，否则它每次都在做一道新题。区别只在于：有些变化你能接受，有些不能。

先分清哪种「不一样」可以接受

不是所有差异都叫不稳定。先划一条线：

• 可以接受：措辞变了、同义表达换了、段落顺序微调，信息没丢。
• 不可以接受：字段少了、结论反了、数字错了、结构散了。

这条线要在跑之前划好，不是跑完再判断。跑完再判断，人会不自觉地把这次的结果解释成"也行"。

判断标准很简单：把这次输出交给一个不知情的人，他能不能完成你原本要做的事。能，就是可接受；不能，说明本次未达到用途要求；是否可复现还要另看相同条件下的重复结果。

固定项一：输入

同一段提示词，输入换一版，结果就没有可比性。

要固定的是：原始素材本身（同一份文件、同一张图，不是"差不多的另一张"）、素材的尺寸与裁切、以及你贴进对话的上下文长度。长文档被截断这件事很常见，前五千字和后五千字是两个任务。

一个容易被忽略的点：图片的压缩。同一张图重新导出一次，尺寸和压缩率变了，生成结果的细节也会跟着变。

怎么做：把输入单独存一个文件夹，命名带版本号，例如 input-v1。跑之前确认这次用的还是它。换输入后应重新检查结论的适用范围，不能把旧样本结果直接当作新样本的通过证据。

固定项二：参数

文本生成里最常调的是 temperature 和 top_p，图像、视频生成里最常调的是随机种子（seed）和画面尺寸。它们的作用方向不同：

• temperature / top_p：部分模型提供的采样控制，两者机制与支持范围不同。并非所有界面都允许修改，也不是所有模型的取值和响应一致。记录实际可设置项；不支持的写“不提供”，不要虚构参数。降低随机性也不保证事实正确或输出完全一致。
• seed：固定"这一次"的随机起点。同样输入、同样模型版本下，同 seed 可能减少部分随机差异，但是否接近还取决于工具实现、运行环境和其他设置，不应直接作出保证。
• 尺寸 / 比例：会改变构图。同一提示词，横图和竖图不是同一张画。

判断标准：如果你说不出这次改了哪个参数，那这次结果就不能拿来和上一次比。

顺带一句：seed 不是万能的。服务端换了硬件、模型做了小版本更新，同 seed 也可能变。它能减少波动，不能承诺逐像素一致。

固定项三：版本

有明确模型版本时记录版本；服务不暴露版本时，记录显示名称、提供方、使用日期和无法控制的条件。项目依赖可通过锁文件保留版本。

这件事在代码类任务上尤其明显：同一个提示词，换一个模型版本，代码风格和出错方式都会变。今天跑通的方案，下周不一定还能跑。

判断标准：三个月后，你能不能照着记录把环境还原出来。还原不出来，这条经验就不能交给别人用。

版本升级之后，把内容状态改成「需要重新验证」。四段式构建记录里把这套状态写得很清楚：这不是退步，是准确。

固定项四：步骤

一次只改一个变量。这是实验设计里最老的一句话，也是最常被违反的一句。

常见场景：结果不对，于是同时改了提示词、换了模型、加了两个例子。结果变好了，但你不知道是哪一处起了作用。下次再出问题，还是从零开始猜。

另外两件事：

• 保留中间产物。每一步的输出都存下来，不要只留最后一版。
• 先做小样本重复检查。例如同一输入运行三次，可以发现部分波动，但三次通过不能证明稳定；仍需检查不同输入、边界、失败和服务变化。

判断标准：你能不能指出"是这一步让它变好的"。指不出来，就是没控制变量。

固定项五：验收

先写验收标准，再跑。顺序反过来，人就会围着结果找理由。

把"看起来不错"换成能勾选的条目。比如整理会议记录这个任务，验收项不是"总结得挺好"，而是：

• 每条待办都有负责人
• 每条待办都有截止时间，没有的标"未定"
• 每条待办能追到原文第几行
• 没有把讨论中的假设写成已决定事项

四条都满足，才能记为这个样本通过。失败时先核对输入、处理过程和输出，再决定是否需要修改提示词。

一张能直接抄的固定项清单

可以按以下项目逐项填写：

• 输入：素材文件名与版本、尺寸、上下文长度 — 换人拿这份输入，能得到同一道题
• 参数：temperature / top_p / seed / 尺寸 — 能说出这次改了哪一个
• 版本：模型名带版本号、依赖锁版本 — 三个月后能还原环境
• 步骤：每次只改一个变量、保留中间产物 — 能指出是哪一步起的作用
• 验收：可勾选的条目，不是形容词 — 四条里过了几条，一眼能看到

可以先从输入和验收两项开始记录，缺失项明确标注。记录本身不改变模型能力，其作用是让比较和排查更有依据。

案例：把 30 行会议记录整理成待办表

下面这个案例可以当场照做。它的重点不是"AI 能不能整理会议记录"，而是“如何判断这次结果是否符合要求”。以下是练习设计，不是已经运行通过的案例。

第 0 步：先把输入固定下来。 准备一份 30 行左右的会议记录，存成 meeting-v1.txt。不要用聊天窗口里边聊边改的版本，那已经不是同一份输入了。

第 1 步：写验收项。 四条：负责人、事项、截止时间、来源行号。缺一项就算不通过。

第 2 步：把输出结构写进提示词。 不要写"整理成待办"，要写清楚字段和缺省规则：

把下面的会议记录整理成待办表，只输出表格，不要解释。
字段：负责人 / 事项 / 截止时间 / 来源行号。
规则：
1. 负责人没提到就写"未指定"，不要猜。
2. 截止时间没提到就写"未定"，不要补。
3. 来源行号写原文的行号，不要写段落大意。
4. 一条待办只对应一件事，不要把两件事合并。

第 3 步：固定模型和参数。 记下模型名和版本，只记录界面实际提供的参数；需要调参时先比较样本，不预设某个档位一定最稳。

第 4 步：跑第一遍。 把 meeting-v1.txt 全文贴进去，不要截取。跑完逐条对照原文检查内容，再记录各项是否通过。

第 5 步：只改一处。 如果"截止时间"这一列大量是"未定"，先回去看原文里到底有没有写时间。原文有时间但输出遗漏，可能来自输入截断、识别或检索失败、指令不清或模型错误；原文没有却编造时间，也不能只归因于约束不够。先确认模型实际收到的原文，再逐项排查，并用人工核对或结构校验发现错误。

第 6 步：跑第二遍和第三遍。 同样的输入、同样的提示词、同样的参数。三遍都过，只能记为“这个样本重复三次通过”。再用不同长度、缺字段和含歧义的样本检查泛化表现；出现失败时保留输入与结果，逐项排查。

第 7 步：记录。 把输入文件名、提示词原文、模型版本、参数、三遍的验收结果写进构建记录。这一步比结果本身有用——下次换一份会议记录，你可以直接复用这套设置。

一个提醒：不要用"这次总结得比上次好"作为判断。好是感受，过没过是事实。

什么情况下不必追求复现

复现有成本。下面三种情况，强行固定反而是浪费：

• 低影响的一次性任务：可以简化记录；若涉及数据写入、对外发送或重要判断，即使只执行一次，也应保留必要的输入、核对和恢复信息。
• 探索阶段：你在试哪种风格可行，这时候需要的是发散，不是收敛。先把范围打开，再固定。
• 创意类产出：文案的多种写法、构图的多个方案，本来就该有差异。这时候要固定的是"不能出现什么"，不是"必须长成什么样"。

判断标准：这件事会不会做第二次、要不要交给别人做。两个答案都是“否”且影响较低时，可以简化记录；重要结果仍需核对。

把结果留下来

固定项表填完，只是你自己知道。要让别人也能复现，得把它写下来。

四段式构建记录里的四段式够用：问题、工具、结果、下一步，再把固定项表作为附件贴上去。发到发布页时，验证状态按实际情况选——验证状态应依据站点规则和真实证据填写，说明验证范围、样本与限制；不能仅凭“三遍通过”推定整体可靠。

一个常见的偷懒：把"跑通了"当成"验证过了"。跑通只说明主路径能走，验证要说明边界在哪、哪一段还不稳。

如果你只记一件事，记这个：可复现不是把提示词存下来，是把当时的所有条件存下来。 提示词只是其中一项。