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

模型能否处理更长的上下文？
Codex 能否理解更大的代码库？
ChatGPT 能否完成更复杂的推理？
Pro 是否更适合高频工程任务？
Plus 是否足够支持日常开发工作？

这些问题都很重要。

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

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

这就是 AI Determinism。

也就是 AI 确定性问题。

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

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

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

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

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

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

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

---

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

传统程序可以抽象为：

Output = Function(Input)

例如：

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

只要输入相同：

calculateTotal(100, 2);

结果就应该始终是：

200

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

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

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

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

比如：

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

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

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

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

---

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

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

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

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

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

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

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

例如同一句话：

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

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

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

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

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

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

真正的输入是：

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

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

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

---

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

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

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

例如用户提出：

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

Codex 第一次可能选择：

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

第二次可能选择：

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

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

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

还要看：

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

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

即：

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

---

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

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

例如：

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

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

但 Pro 型使用往往包含：

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

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

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

Uncertainty ∝ Context × Steps × Tools × Decisions

也就是说：

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

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

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

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

Plus 更像单次智能调用。

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

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

---

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

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

可以拆成四层：

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

1. 输入确定性

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

低确定性输入：

帮我优化这个项目。

高确定性输入：

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

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

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

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

---

2. 上下文确定性

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

例如第一次 Codex 读取：

OrderList.tsx
orderApi.ts
orderService.ts

第二次却额外读取：

orderExportService.ts
orderLegacyAdapter.ts

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

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

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

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

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

---

3. 执行确定性

执行顺序是否稳定。

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

路径 A：

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

路径 B：

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

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

所以需要 Workflow 固化。

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

例如：

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. 结果确定性

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

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

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

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

可以定义：

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

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

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

---

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

很多人可能会问：

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

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

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

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

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

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

也就是有限确定性。

允许变化的部分：

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

必须稳定的部分：

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

可以定义为：

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

例如：

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. 固定任务结构

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

## Goal

## Context

## Constraints

## Required Output

## Acceptance Criteria

例如：

## Goal

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

## Context

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

## Constraints

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

## Required Output

一篇完整技术文章。

## Acceptance Criteria

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

---

2. 固定输出 Schema

让模型按固定结构输出。

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

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

---

3. 保存上下文摘要

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

{
  "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. 增加自检阶段

生成后要求自检：

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

---

5. 将人工修改转成规则

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

例如：

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

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

---

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

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

1. 锁定基线版本

任务开始时记录：

Branch
Base Commit
Dependency Lock
Context Snapshot

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

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

---

2. 限制修改范围

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

例如：

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。

先输出：

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

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

---

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

例如：

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

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

---

5. 强制 Diff Review

每次修改必须解释：

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

这可以抑制无关重构。

---

九、AI Determinism 与测试的关系

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

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

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

更合适的是属性测试。

例如文章测试：

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

Codex Patch 测试：

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

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

不是问：

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

而是问：

关键属性是否仍然成立？

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

---

十、AI Determinism 与缓存机制

确定性还影响缓存。

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

CacheKey = hash(input)

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

更合理的 Key 应该包括：

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

可以定义：

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

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

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

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

---

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

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

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

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

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

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

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

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

还必须同步提升：

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

可以表示为：

Strong Model
  +
Weak Engineering Control
  =
High-Variance Output

而：

Strong Model
  +
Strong Determinism Boundary
  =
Controlled Intelligence

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

---

十二、AI Determinism 的工程分级

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

可以定义：

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

Creative

适合：

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

允许较大差异。

Bounded

适合：

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

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

Strict

适合：

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

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

可以定义：

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

例如：

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 参与的项目，可能需要专门描述确定性边界。

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

例如 policy.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：

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

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

---

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

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

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

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

如果任务描述很模糊：

重构系统。

解空间非常大。

如果任务明确：

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

解空间就被压缩。

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

Solution Space Design

即解空间设计。

包括：

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

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

---

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

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

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

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

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

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

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

完整流程：

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

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

---

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

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

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

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

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

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

而是建立有限确定性：

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

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

ChatGPT 需要保持认知边界稳定。
Codex 需要保持工程修改范围稳定。
Plus 需要保证日常任务质量下限。
Pro 需要保证长任务中的状态和决策连续。

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

真正的工程价值在于：

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

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

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

这就是 AI Determinism 的核心。

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

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