很多人用ChatGPT、Codex一段时间以后，都会遇到一个特别让人困惑的问题。

昨天你写了一段Prompt。

效果非常好。

AI理解准确，回答稳定，甚至代码一次就改对了。

今天你把几乎同样的Prompt再用一遍，结果却开始变了。

有时候是回答风格不同。

有时候是方案不同。

有时候是代码改法完全不一样。

甚至同一个Bug，昨天AI判断问题在A，今天却认为问题在B。

于是很多人会怀疑：

“是模型变了吗？”

有时候确实可能和模型更新有关。

但更多时候，真正变化的不是那一句Prompt，而是：

Prompt进入了一个不同的状态。

这也是复杂AI任务里一个非常重要、但经常被忽略的问题：

同一句Prompt，不等于同一个任务。

因为AI真正处理的，从来不只是你最后输入的那句话。

---

一、真实场景：Prompt没变，结果为什么变了？

假设你昨天让Codex处理一个问题：

“修复用户登录后Session偶尔丢失的问题，不改变Public API。”

昨天AI先检查Session逻辑，然后定位到Token刷新，最后只改了几个文件。

结果很好。

今天同样的问题再次出现。

你把昨天那段Prompt直接复制过去。

但这次AI先去看缓存。

然后检查权限模块。

接着分析异常处理。

最后给出了另一套方案。

你会感觉：

“奇怪，明明Prompt一样。”

但如果仔细看，两个任务的环境可能已经完全不同。

昨天：

代码是Version A。

测试状态是A。

Context里只有登录相关文件。

今天：

项目已经有新的Commit。

某些文件已经修改。

Context里可能还有上一轮讨论。

测试返回信息也不同。

所以AI面对的实际上不是：

同一个Prompt。

而是：

同一个Prompt + 不同状态。

这两个任务自然可能得到不同结果。

---

二、为什么简单任务比较稳定，复杂任务波动更明显？

因为简单任务的输入变量很少。

例如：

“把这段Python改成异步。”

AI主要看：

当前代码。

你的要求。

任务空间比较小。

即使重复执行，结果通常差异有限。

但复杂Agent任务不一样。

它的最终结果可能同时受很多东西影响：

当前代码版本。

已有修改。

对话历史。

项目规则。

工具返回。

测试结果。

搜索顺序。

前面已经做出的判断。

也就是说，复杂任务实际上拥有一个很大的：

State Space，状态空间。

Prompt只是其中一个变量。

所以任务越复杂，结果越不应该被理解成：

Prompt → 固定答案

而更接近：

Prompt + Context + Environment + Tool Feedback + Current State → Result

这才是为什么复杂AI使用里，“昨天好用的Prompt”不一定能机械复制。

---

三、背后的机制：Prompt只是输入，State才决定AI当前看到的世界

很多人会把Prompt想成一条程序指令。

好像：

输入完全一样，输出应该完全一样。

但大模型和传统确定性程序不是一回事。

尤其是进入Agent工作流以后。

一个Agent任务开始时，会面对一个当前世界状态。

这个状态可能包含：

哪些文件存在。

哪些文件被修改过。

当前Git状态。

测试哪些失败。

工具读取到了什么。

对话里已经留下哪些假设。

所以AI并不是在真空里执行你的Prompt。

它是在：

一个已经有历史、有环境、有状态的系统里做判断。

同一句：

“继续修复登录问题。”

如果前面一次AI认为Root Cause是缓存。

和前面什么都没分析。

这句话的含义其实完全不同。

因为“继续”依赖前面的State。

---

四、为什么对话历史会让同一句Prompt产生不同效果？

这是ChatGPT用户尤其容易遇到的问题。

比如第一次你问：

“帮我分析这个方案。”

AI给出方向A。

后来你不断补充：

“不对，重点不是性能。”

“再考虑兼容性。”

“上一条忽略。”

“按第二个方案继续。”

几十轮以后，你再次输入最开始那句话：

“帮我分析这个方案。”

它已经不是第一次的任务了。

因为Context里现在存在大量：

历史判断。

修正。

否定。

偏好。

局部结论。

所以模型会基于整个对话理解你真正想要什么。

这会提高连续协作能力。

但同时也意味着：

同一句Prompt在不同对话状态里，本身不是同一个输入。

---

五、为什么Codex里的波动会更明显？

因为Codex除了语言Context，还会受到真实工程环境影响。

比如它可能读取：

Repository当前代码。

测试输出。

构建状态。

依赖。

Git Diff。

日志。

这些东西都可能变化。

昨天某个测试通过。

今天同一个测试失败。

AI下一步决策自然不同。

昨天搜索到的调用链很短。

今天项目新加了一个模块。

AI可能发现新的关联。

所以Codex结果波动，有时候不是“不稳定”。

反而是：

它正在对不同环境做出不同反应。

真正需要判断的是：

这种变化是合理适应，还是无意义漂移。

---

六、还有一个原因：AI任务本身不是完全确定性的

即使Context和环境非常接近，大模型的生成过程也不一定严格重复。

复杂问题通常存在多个合理路径。

例如一个Bug可能有两种修法：

局部补丁。

或者调整调用逻辑。

两种都能解决。

AI第一次走路径A。

第二次可能走路径B。

这不一定代表其中一个错误。

真正的问题是：

你的任务有没有给出足够明确的约束，帮助它判断：

哪种方案更符合你的工程目标。

如果没有，那么模型在多个合理方案之间产生不同结果，其实很正常。

---

七、为什么“结果不同”不一定是问题？

这点非常重要。

有些用户追求：

每次答案完全一样。

但复杂AI任务真正需要的不是绝对一致。

而是：

结果在关键约束上保持一致。

比如两次Codex给出的实现不同。

但都满足：

问题被修复。

Public API没变。

测试通过。

没有无关重构。

那两种方案都可能是有效结果。

真正危险的是：

第一次满足这些条件。

第二次突然：

扩大Scope。

改接口。

重构无关模块。

这才属于有意义的结果波动。

所以我们真正应该测的不是：

“文本一样不一样。”

而是：

工程结果稳定不稳定。

---

八、可以用“结果波动率”判断自己的AI任务是否稳定

这里可以建立一个自测指标：

结果波动率

它不是看每次回答文字是否完全一样。

而是看：

同类任务重复执行时，关键结果发生多大变化。

可以观察四个维度。

第一，方案方向是否频繁变化？

例如昨天局部修复，今天直接重构整个模块。

第二，修改范围是否变化很大？

同一个任务，一次改2个文件，一次改15个文件。

第三，Done Criteria是否稳定满足？

不管方案怎么变，最终是否都满足核心验收条件。

第四，返工率是否明显变化？

同类任务有时候一次成功，有时候需要5轮纠正。

如果这些波动很大，说明你的AI工作流稳定性还不够。

---

九、怎么降低结果波动？

第一，不要只保存Prompt，要保存任务结构。

很多人觉得昨天Prompt好用，于是只保存那句话。

真正应该保存的是：

Goal。

Context。

Constraint。

Non-goal。

Done Criteria。

因为真正决定结果稳定性的，往往是这一整套结构。

第二，尽量保持Baseline一致。

特别是Codex任务。

开始执行前先确认：

当前分支。

代码版本。

已有Diff。

测试状态。

如果Baseline不同，就不要期待结果完全一致。

第三，把关键约束固定下来。

例如：

不改变Public API。

不做无关重构。

只修改指定模块。

必须通过哪些测试。

这样即使内部推理路径变化，最终边界仍然稳定。

第四，复杂任务不要依赖模糊的“继续”。

如果任务中断以后重新开始，最好重新总结当前State，而不是简单说：

“继续。”

让AI知道：

已经确认什么。

哪些假设被排除。

当前目标是什么。

---

十、还有一个很有效的方法：先比较“结果”，不要比较“过程”

AI第一次：

先查缓存，再查Token。

第二次：

先查Token，再查缓存。

这并不重要。

真正应该比较：

最终Root Cause是不是有证据。

修改范围是否合理。

测试是否充分。

风险是否可接受。

如果过程不同但结果质量一致，说明AI只是用了不同路径。

如果关键质量指标波动很大，才需要优化Workflow。

---

十一、为什么未来“稳定性”会比“单次惊艳”更重要？

AI刚开始普及时，大家很容易被某一次特别好的结果吸引。

“这次AI一次写对了。”

“这个Prompt太神了。”

但真正进入生产以后，团队需要的不是偶尔惊艳。

而是：

可重复。

今天能完成。

明天也能完成。

换一个类似任务，仍然能维持相近质量。

因为软件工程依赖的是稳定流程。

不是抽奖。

所以未来AI Coding竞争的一个核心指标，很可能不只是：

最强结果能有多强。

还包括：

结果分布能不能收窄。

也就是：

好结果出现得是不是更稳定。

---

十二、结果波动率低：Plus通常已经够用

如果你的日常任务：

比较明确。

Context规模适中。

AI输出虽然偶尔有差异，但关键结果基本稳定。

你不需要频繁重跑或者返工。

那么你的核心需求仍然是：

日常效率提升。

Plus通常已经能够覆盖很多场景。

因为你并没有真正遇到持续、高强度的复杂Agent工作负载。

---

十三、结果波动率高，也不要先想到Pro

如果同一个任务：

今天成功。

明天失败。

一次改3个文件。

另一次改20个。

经常需要重新解释。

这时候第一反应不应该是：

“需要更强套餐。”

因为很多波动可能来自：

Baseline不同。

Context污染。

约束不稳定。

Done Criteria模糊。

任务结构不固定。

这些问题如果不解决，更高的AI容量只会让你更快重复不稳定过程。

应该先提高：

任务模板化。

Context管理。

状态重置。

验证标准。

---

十四、什么时候Pro才真正开始匹配？

更接近Pro的状态是：

你的任务结构已经成熟。

关键Prompt不是孤立的一句话，而是一整套稳定任务定义。

Context经过管理。

Baseline明确。

Done Criteria固定。

同类任务结果波动已经比较低。

但是你的真实工作中仍然持续存在：

大量复杂Codex任务。

长时间Agent执行。

大型Repository。

高Context分析。

多个复杂任务并行。

这时候AI侧的能力和容量才更可能成为真正瓶颈。

也就是说：

不是：

“AI结果不稳定，所以我要Pro。”

而是：

“我的Workflow已经足够稳定，现在需要更高AI吞吐。”

---

最后：真正可复用的从来不是一句Prompt，而是一套稳定的任务状态

很多人喜欢收藏：

“神Prompt。”

但进入复杂AI工作以后，会越来越发现：

真正能够复用的，不是一句话。

而是：

目标怎么定义。

Context怎么准备。

Baseline是什么。

边界在哪里。

什么算完成。

失败以后怎么重置。

因为同一句Prompt放进不同State里，本来就可能产生不同结果。

所以以后如果昨天某个Prompt很好用，今天突然变差了，不要第一时间怀疑：

“AI是不是变笨了？”

先看：

今天的任务状态，真的和昨天一样吗？

如果同类任务的结果波动率低：

Plus通常已经够用。

如果你已经把任务状态和Workflow控制得很稳定，而每天仍然需要大量复杂Agent任务：

Pro才开始真正匹配。

未来真正高水平的AI使用，不是追求：

“找到一句永远有效的Prompt。”

而是建立：

即使环境不断变化，AI仍然能稳定产出可靠结果的工作方式。

持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的AI会员订阅渠道，有需要可自取！