2026年7月更新：ChatGPT、Codex、Pro、Plus 背后的 AI Determinism 问题（GPT-5.6 工程化技术分享）

很多人讨论 ChatGPT、Codex、Pro、Plus 时，注意力通常集中在模型能力上。

模型能否处理更长的上下文？

Codex 能否理解更大的代码库？

ChatGPT 能否完成更复杂的推理？

Pro 是否更适合高频工程任务？

Plus 是否足够支持日常开发工作？

这些问题都很重要。

但当 AI 真正进入软件工程流程以后，开发者很快会遇到一个比"模型够不够强"更棘手的问题：

同一个任务交给 AI 两次，为什么可能得到两套不同的结果？

这就是 AI Determinism。

也就是 AI 确定性问题。

传统软件工程建立在确定性之上。

同样的代码、同样的输入、同样的运行环境，原则上应该产生相同的输出。

但 ChatGPT、Codex 以及 GPT-5.6 这类生成式模型，并不是传统意义上的确定性函数。

同一个需求，在不同上下文、不同会话状态、不同工具调用顺序下，可能得到不同的任务计划、代码实现和分析结论。

这意味着，AI 工程面临一个新的底层矛盾：

text 复制代码

软件工程追求稳定复现
生成式模型天然允许结果变化

如何让这两种逻辑共存，将成为 LLM-Native 软件工程绕不开的问题。

一、传统程序为什么依赖确定性

传统程序可以抽象为：

text 复制代码

Output = Function(Input)

例如：

ts 复制代码

function calculateTotal(price: number, quantity: number): number {
  return price * quantity;
}

只要输入相同：

ts 复制代码

calculateTotal(100, 2);

结果就应该始终是：

text 复制代码

确定性让软件工程具备几个关键能力：

text 复制代码

可测试
可复现
可调试
可回归
可审计
可预测

如果一次单元测试今天通过，明天在相同环境下却随机失败，整个工程体系就会失去稳定基础。

因此传统软件开发不断消除不确定性。

比如：

text 复制代码

固定依赖版本
固定运行环境
固定输入格式
固定数据结构
固定测试条件
固定构建流程

Docker、Lock File、CI/CD、快照测试、基础设施即代码，本质上都在做一件事：

尽可能把系统状态固定下来。

但大模型进入以后，这种确定性开始被打破。

二、ChatGPT 的输出为什么不是普通函数返回值

ChatGPT 看起来像一个输入输出系统：

text 复制代码

用户输入 → 模型处理 → 文本输出

但它并不等价于传统函数。

更准确地说，ChatGPT 的输出受多个变量影响：

text 复制代码

Output = Model(
  Prompt,
  Context,
  Memory,
  Tools,
  System Rules,
  Conversation State,
  Sampling Strategy
)

只要其中一个变量发生变化，结果就可能变化。

例如同一句话：

text 复制代码

分析这个项目的架构问题。

在不同上下文中可能产生完全不同的结果。

如果上下文里包含前端代码，ChatGPT 可能重点分析组件耦合。

如果上下文里包含微服务配置，它可能重点分析服务边界。

如果上下文里包含错误日志，它可能重点分析运行时故障。

所以，自然语言输入并不是完整输入。

真正的输入是：

text 复制代码

自然语言
+
上下文状态
+
项目状态
+
历史决策
+
执行权限

这也是为什么 AI 工程不能只管理 Prompt。

它还必须管理完整运行状态。

三、Codex 的非确定性为什么比文本生成更危险

ChatGPT 写出两篇不同的文章，通常只是表达差异。

Codex 给同一个项目生成两套不同的修改方案，风险则完全不同。

例如用户提出：

text 复制代码

降低订单模块的复杂度，不改变现有业务逻辑。

Codex 第一次可能选择：

text 复制代码

提取重复函数
拆分过长 Service
保留原有接口
补充单元测试

第二次可能选择：

text 复制代码

引入新的领域模型
重新拆分目录
调整函数签名
重构数据访问层

两套方案都可能具有合理性，但它们的工程影响完全不同。

这意味着 Codex 的输出不能只看"代码是否正确"。

还要看：

text 复制代码

修改路径是否稳定
影响范围是否可控
是否符合原始架构
是否重复推翻历史决策
是否产生新的技术债务

所以 Codex 工程化的核心，不只是 Code Generation，而是 Change Determinism。

即：

如何让 AI 在相同约束下，稳定产生相近的修改路径。

四、Plus 与 Pro 的差异会放大确定性问题

在 Plus 的日常使用场景中，任务通常较短。

例如：

text 复制代码

解释一段代码
生成一个函数
整理一份文档
分析一个错误

这类任务即使输出略有不同，影响也相对有限。

但 Pro 型使用往往包含：

text 复制代码

长上下文
多轮推理
多文件修改
持续任务推进
复杂工具调用
多阶段人工反馈

任务越长，状态变量越多。

可以用一个简单模型表示：

text 复制代码

Uncertainty ∝ Context × Steps × Tools × Decisions

也就是说：

text 复制代码

上下文越多
任务步骤越多
工具调用越多
中间决策越多
最终结果的不确定性越高

因此 Pro 级工作流并不意味着可以减少约束。

恰恰相反，它需要更严格的：

text 复制代码

任务协议
上下文快照
版本锁定
阶段检查
人工审批
结果验证

Plus 更像单次智能调用。

Pro 更接近长时间运行的智能系统。

后者必须解决确定性治理问题。

五、AI Determinism 可以分成四个层次

AI 确定性并不是一个单一问题。

可以拆成四层：

text 复制代码

1. 输入确定性
2. 上下文确定性
3. 执行确定性
4. 结果确定性

1. 输入确定性

输入是否结构化、完整、无歧义。

低确定性输入：

text 复制代码

帮我优化这个项目。

高确定性输入：

text 复制代码

目标：
降低订单查询模块的重复逻辑。

限制：
- 不修改接口返回结构；
- 不引入新依赖；
- 不修改数据库；
- 一次最多修改 3 个文件。

验收：
- 原有测试全部通过；
- 新增重复逻辑测试；
- 输出修改文件和风险说明。

输入越明确，模型的解空间越小。

2. 上下文确定性

模型是否每次读取同一组有效上下文。

例如第一次 Codex 读取：

text 复制代码

OrderList.tsx
orderApi.ts
orderService.ts

第二次却额外读取：

text 复制代码

orderExportService.ts
orderLegacyAdapter.ts

即使 Prompt 相同，方案也可能变化。

因此上下文必须支持快照：

ts 复制代码

interface ContextSnapshot {
  id: string;
  taskId: string;
  files: {
    path: string;
    hash: string;
  }[];
  rulesVersion: string;
  decisionVersion: string;
  createdAt: string;
}

同一个任务重试时，应该明确：

text 复制代码

是否复用原上下文快照
是否加载最新代码
是否允许引入新文件

3. 执行确定性

执行顺序是否稳定。

例如一个 Codex 任务可能有两种路径。

路径 A：

text 复制代码

读取代码
→ 分析依赖
→ 生成计划
→ 人工确认
→ 修改代码
→ 运行测试

路径 B：

text 复制代码

读取部分代码
→ 直接修改
→ 测试失败
→ 再读取其他文件
→ 二次修改

两种路径即使最终结果接近，风险和成本也不同。

所以需要 Workflow 固化。

ts 复制代码

interface WorkflowStep {
  id: string;
  type:
    | "read"
    | "analyze"
    | "plan"
    | "approve"
    | "patch"
    | "test"
    | "review";
  required: boolean;
  canSkip: boolean;
}

例如：

ts 复制代码

const codexWorkflow: WorkflowStep[] = [
  {
    id: "read-context",
    type: "read",
    required: true,
    canSkip: false
  },
  {
    id: "impact-analysis",
    type: "analyze",
    required: true,
    canSkip: false
  },
  {
    id: "human-approval",
    type: "approve",
    required: true,
    canSkip: false
  },
  {
    id: "generate-patch",
    type: "patch",
    required: true,
    canSkip: false
  },
  {
    id: "run-tests",
    type: "test",
    required: true,
    canSkip: false
  }
];

固定流程可以减少模型"临场发挥"造成的路径漂移。

4. 结果确定性

最终结果是否满足相同业务不变量。

代码具体写法可以不同，但核心行为必须一致。

例如订单筛选功能的结果不变量：

text 复制代码

筛选字段必须传到后端
后端必须正确过滤
导出逻辑必须保持同步
旧查询功能不能被破坏

可以定义：

ts 复制代码

interface ResultInvariant {
  id: string;
  description: string;
  verification:
    | "unit_test"
    | "integration_test"
    | "schema_check"
    | "manual_review";
  blocking: boolean;
}

只要这些不变量成立，允许代码实现存在合理差异。

这是一种"受约束的非确定性"。

六、完全确定并不是 AI 工程的目标

很多人可能会问：

能不能让 ChatGPT 和 Codex 每次都输出完全一样的结果？

从工程角度看，这未必是正确目标。

因为生成式模型的价值之一，就是探索不同方案。

如果强制每次完全相同，就可能失去：

text 复制代码

方案多样性
创造性
替代路径
局部优化能力
异常情况适应能力

真正合理的目标不是 Absolute Determinism，而是 Bounded Determinism。

也就是有限确定性。

允许变化的部分：

text 复制代码

代码局部写法
变量命名
文章表达
候选方案
实现细节

必须稳定的部分：

text 复制代码

任务目标
安全边界
接口契约
业务不变量
验收标准
人工决策

可以定义为：

ts 复制代码

interface DeterminismPolicy {
  strict: string[];
  flexible: string[];
}

例如：

ts 复制代码

const policy: DeterminismPolicy = {
  strict: [
    "goal",
    "constraints",
    "business_invariants",
    "forbidden_scopes",
    "acceptance_criteria"
  ],
  flexible: [
    "implementation_details",
    "code_style_within_project_rules",
    "explanation_wording",
    "candidate_solutions"
  ]
};

这才是 AI 系统合理的确定性边界。

七、如何让 ChatGPT 输出更稳定

ChatGPT 的输出稳定性，可以从五个方面提升。

1. 固定任务结构

不要只输入自然语言段落，而要使用统一结构。

markdown 复制代码

## Goal

## Context

## Constraints

## Required Output

## Acceptance Criteria

例如：

markdown 复制代码

## Goal

写一篇适合 CSDN 的 AI 工程技术文章。

## Context

主题围绕 ChatGPT、Codex、Pro、Plus。

## Constraints

- 使用 Markdown；
- 不写普通体验内容；
- 必须包含程序结构；
- 技术角度不能和前文重复。

## Required Output

一篇完整技术文章。

## Acceptance Criteria

- 有明确工程命题；
- 有 TypeScript 示例；
- 有架构分析；
- 有总结性判断。

2. 固定输出 Schema

让模型按固定结构输出。

ts 复制代码

interface TechnicalArticle {
  title: string;
  thesis: string;
  sections: {
    heading: string;
    content: string;
  }[];
  codeExamples: string[];
  conclusion: string;
}

结构越明确，输出波动越小。

3. 保存上下文摘要

每轮任务前提供稳定摘要，而不是完全依赖历史对话。

json 复制代码

{
  "series": "ChatGPT Codex CSDN技术文章",
  "required_keywords": [
    "ChatGPT",
    "Codex",
    "Pro",
    "Plus"
  ],
  "used_topics": [
    "AI Observability",
    "AI Testability",
    "AI State Management",
    "AI Consistency"
  ],
  "current_topic": "AI Determinism"
}

4. 增加自检阶段

生成后要求自检：

text 复制代码

检查：
1. 是否包含全部关键词；
2. 是否和前文角度重复；
3. 是否存在浅层描述；
4. 是否包含代码结构；
5. 是否形成明确技术结论。

5. 将人工修改转成规则

如果用户反复修改同一类问题，应把反馈沉淀为固定规则。

例如：

text 复制代码

失败模式：文章前半部分反复介绍 ChatGPT 是什么。
新增规则：开头不得使用基础产品介绍，直接进入工程问题。

这样下一轮输出会更稳定。

八、如何让 Codex 修改路径更稳定

Codex 的稳定性需要更强的工程约束。

1. 锁定基线版本

任务开始时记录：

text 复制代码

Branch
Base Commit
Dependency Lock
Context Snapshot

ts 复制代码

interface CodexBaseline {
  branch: string;
  commit: string;
  dependencyLockHash: string;
  contextSnapshotId: string;
}

如果基线不同，同一个任务就不能算真正重试。

2. 限制修改范围

ts 复制代码

interface ChangeBoundary {
  allowedFiles: string[];
  forbiddenFiles: string[];
  maxChangedFiles: number;
  allowNewDependencies: boolean;
  allowSchemaChanges: boolean;
}

例如：

ts 复制代码

const boundary: ChangeBoundary = {
  allowedFiles: [
    "src/pages/orders/**",
    "src/services/orderApi.ts",
    "tests/orders/**"
  ],
  forbiddenFiles: [
    "src/auth/**",
    "src/payment/**",
    "database/migrations/**"
  ],
  maxChangedFiles: 5,
  allowNewDependencies: false,
  allowSchemaChanges: false
};

修改空间越小，方案越稳定。

3. 先生成 Change Plan

Codex 不应直接生成 Patch。

先输出：

text 复制代码

涉及文件
修改原因
修改顺序
风险等级
测试方式
待确认问题

只有计划被确认，才能进入执行。

4. 使用业务不变量约束结果

例如：

ts 复制代码

const businessInvariants = [
  "订单列表和导出筛选必须保持一致",
  "原接口返回结构不能改变",
  "旧订单查询逻辑必须继续可用"
];

Codex 可以采用不同实现，但不能破坏这些规则。

5. 强制 Diff Review

每次修改必须解释：

text 复制代码

为什么改这个文件
对应哪个需求
是否影响其他模块
如何验证

这可以抑制无关重构。

九、AI Determinism 与测试的关系

传统测试通常验证一个输入是否得到预期输出。

AI 系统的测试不能只比较文本完全相同。

因为两个不同输出可能都正确。

更合适的是属性测试。

例如文章测试：

ts 复制代码

interface ArticleProperties {
  containsRequiredKeywords: boolean;
  followsMarkdown: boolean;
  hasTechnicalStructure: boolean;
  avoidsUsedTopic: boolean;
}

Codex Patch 测试：

ts 复制代码

interface PatchProperties {
  testsPassed: boolean;
  forbiddenScopeUntouched: boolean;
  dependenciesUnchanged: boolean;
  businessInvariantsPreserved: boolean;
}

也就是说，AI 测试应该从 Snapshot Matching 转向 Property Validation。

不是问：

text 复制代码

输出是否和上次一模一样？

而是问：

text 复制代码

关键属性是否仍然成立？

这更符合生成式系统特点。

十、AI Determinism 与缓存机制

确定性还影响缓存。

传统缓存通常使用输入作为 Key：

text 复制代码

CacheKey = hash(input)

但 AI 任务的真实输入远不止 Prompt。

更合理的 Key 应该包括：

text 复制代码

CacheKey = hash(
  modelVersion
  + prompt
  + contextSnapshot
  + toolVersion
  + workflowVersion
  + policyVersion
)

可以定义：

ts 复制代码

interface AICacheIdentity {
  modelVersion: string;
  promptHash: string;
  contextSnapshotId: string;
  workflowVersion: string;
  policyVersion: string;
  toolVersions: Record<string, string>;
}

只要其中一个版本变化，旧缓存就可能失效。

这说明 AI 缓存比传统接口缓存复杂得多。

它缓存的不是一个函数结果，而是一组运行条件下的智能结果。

十一、GPT-5.6 级模型越强，确定性治理越重要

模型能力增强后，可以处理更复杂任务。

但复杂任务意味着更大的决策空间。

例如一个简单函数只有少数实现方式。

一个完整模块重构可能有几十种合理路径。

模型能力越强，它越能提出不同方案。

这是一种优势，也是一种风险。

因此，GPT-5.6 这类能力进入工程工作流后，不能只提升模型层。

还必须同步提升：

text 复制代码

任务层
状态层
策略层
验证层
审计层

可以表示为：

text 复制代码

Strong Model
  +
Weak Engineering Control
  =
High-Variance Output

而：

text 复制代码

Strong Model
  +
Strong Determinism Boundary
  =
Controlled Intelligence

真正成熟的系统不是让模型变得机械，而是让智能在明确边界内变化。

十二、AI Determinism 的工程分级

不同任务需要不同确定性等级。

可以定义：

ts 复制代码

type DeterminismLevel =
  | "creative"
  | "bounded"
  | "strict";

Creative

适合：

text 复制代码

头脑风暴
标题生成
创意文案
方案探索

允许较大差异。

Bounded

适合：

text 复制代码

技术文章
架构分析
普通功能开发
代码审查

允许实现差异，但要求遵守核心契约。

Strict

适合：

text 复制代码

支付逻辑
权限系统
数据库迁移
生产配置
安全规则

要求强约束、强测试和人工审批。

可以定义：

ts 复制代码

interface TaskDeterminismConfig {
  taskType: string;
  level: DeterminismLevel;
  requiresApproval: boolean;
  requiredChecks: string[];
}

例如：

ts 复制代码

const configs: TaskDeterminismConfig[] = [
  {
    taskType: "article_brainstorm",
    level: "creative",
    requiresApproval: false,
    requiredChecks: ["keyword_check"]
  },
  {
    taskType: "codex_feature",
    level: "bounded",
    requiresApproval: true,
    requiredChecks: [
      "scope_check",
      "unit_test",
      "manual_review"
    ]
  },
  {
    taskType: "payment_change",
    level: "strict",
    requiresApproval: true,
    requiredChecks: [
      "security_review",
      "integration_test",
      "rollback_plan",
      "human_approval"
    ]
  }
];

不同任务使用不同确定性策略，才是合理的工程设计。

十三、未来 AI-Ready Repository 需要 Determinism Manifest

未来适合 Codex 参与的项目，可能需要专门描述确定性边界。

text 复制代码

.ai/
  determinism/
    policy.json
    invariants.json
    workflow-lock.json
    context-lock.json

例如 policy.json：

json 复制代码

{
  "default_level": "bounded",
  "strict_modules": [
    "payment",
    "auth",
    "database"
  ],
  "creative_tasks": [
    "documentation_draft",
    "test_idea_generation"
  ],
  "rules": {
    "max_files_changed": 5,
    "new_dependencies": false,
    "database_migration": false,
    "human_approval_required": true
  }
}

invariants.json：

json 复制代码

{
  "invariants": [
    {
      "id": "ORDER_EXPORT_SYNC",
      "description": "订单列表与导出功能必须使用相同筛选条件",
      "blocking": true
    },
    {
      "id": "AUTH_PERMISSION_STABLE",
      "description": "任何角色权限修改必须经过人工审批",
      "blocking": true
    }
  ]
}

Codex 在执行前读取这些配置，就能知道项目允许多大变化。

十四、确定性治理会改变程序员角色

过去程序员主要控制代码。

未来程序员还要控制 AI 的解空间。

所谓解空间，就是 AI 可以选择的可能方案范围。

如果任务描述很模糊：

text 复制代码

重构系统。

解空间非常大。

如果任务明确：

text 复制代码

只提取订单 Service 中的两个重复函数，
不修改接口，不改变业务行为，
一次最多修改三个文件。

解空间就被压缩。

所以未来程序员的重要能力之一是：

text 复制代码

Solution Space Design

即解空间设计。

包括：

text 复制代码

定义目标
限制范围
锁定上下文
规定不变量
设置验证条件
划分可变和不可变区域

这比简单 Prompt Engineering 更接近真正的软件工程。

十五、ChatGPT、Codex、Pro、Plus 的确定性分工

可以将四者放进一套确定性治理结构中：

text 复制代码

ChatGPT
  负责意图结构化
  负责将模糊目标转为明确任务

Codex
  负责在受限代码范围内生成工程修改

Plus
  适合日常中等确定性任务

Pro
  适合复杂长任务，但必须加强状态和版本治理

Human
  定义不变量
  审批高风险变化
  判断不同方案的长期影响

完整流程：

text 复制代码

用户目标
  ↓
ChatGPT 编译结构化任务
  ↓
锁定上下文快照
  ↓
加载 Determinism Policy
  ↓
Codex 生成 Change Plan
  ↓
人工审批
  ↓
受限执行
  ↓
属性测试
  ↓
结果审查

这就是可控生成的基本闭环。

十六、结语：AI 工程不是消灭随机性，而是管理随机性

ChatGPT、Codex、Pro、Plus 让软件系统拥有了更强的生成能力。

但生成能力越强，结果空间越大。

如果没有确定性治理，系统会出现：

text 复制代码

同一任务重复得到不同方案
多轮任务不断推翻历史决策
Codex 修改路径持续漂移
测试和代码逐渐失去同步
人工难以复现 AI 行为

因此，AI 工程的目标不是让模型完全变成传统函数。

而是建立有限确定性：

text 复制代码

允许表达变化
允许方案探索
允许局部优化

但不允许目标漂移
不允许边界失效
不允许契约冲突
不允许业务不变量被破坏

ChatGPT 需要保持认知边界稳定。

Codex 需要保持工程修改范围稳定。

Plus 需要保证日常任务质量下限。

Pro 需要保证长任务中的状态和决策连续。

GPT-5.6 级模型的价值，不只是能生成更复杂结果。

真正的工程价值在于：

能否把更强的生成能力放进一个可重复、可验证、可审计的系统里。

实验型 AI 追求每次都给人惊喜。

工程型 AI 追求即使结果不同，也始终不越过系统底线。

这就是 AI Determinism 的核心。

未来的软件工程不会消除 AI 的不确定性。

它会为不确定性设计边界。