AI 编程发展到今天，一个越来越明显的趋势是：代码生成正在变得廉价。

ChatGPT Plus 可以快速解释代码、生成初稿、补充常见逻辑；ChatGPT Pro 可以处理更复杂的架构推理、任务拆解与约束分析；Codex 则可以进一步进入真实代码仓库，理解上下文、修改文件、运行测试并输出变更说明。

过去需要开发者花费数小时完成的代码，现在可能在较短时间内生成。

但代码生成成本下降，并不等于软件可靠性成本下降。

相反，当生成速度越来越快，系统中可能出现更多“局部正确、整体错误”的实现：

代码可以编译
但业务语义错误

单元测试通过
但状态组合不完整

接口能够返回
但类型约束被弱化

功能可以运行
但错误路径没有被建模

因此，AI 编程真正进入工程深水区以后，问题不会再是：

ChatGPT Pro 和 Codex 能不能写出代码？

而会变成：

如何在代码进入系统之前，证明某些错误根本无法被表达？

这正是类型系统、契约设计和形式化约束重新变得重要的原因。

当 ChatGPT Plus、ChatGPT Pro 与 Codex 把代码产出速度提高以后，类型系统将不再只是语法检查工具，而会成为限制 AI 执行空间的第一道工程边界。

---

一、测试只能发现错误，类型系统可以禁止错误

很多团队面对 AI 生成代码时，第一反应是增加测试。

这个方向当然正确。

但测试存在一个天然限制：

测试只能证明某些场景没有失败，不能证明所有非法状态都不会出现。

例如，一个订单系统包含以下状态：

type OrderStatus =
  | "CREATED"
  | "PAID"
  | "SHIPPED"
  | "CANCELLED"

如果直接使用字符串表示状态，Codex 在修改业务逻辑时，可能生成这样的代码：

function updateOrderStatus(status: string) {
  // ...
}

updateOrderStatus("PAYED")

PAYED 并不是合法状态，但如果类型定义过于宽松，编译器无法阻止它。

测试可能碰巧覆盖不到这条路径。

更合理的设计是：

type OrderStatus =
  | "CREATED"
  | "PAID"
  | "SHIPPED"
  | "CANCELLED"

function updateOrderStatus(status: OrderStatus) {
  // ...
}

此时，无论代码由人编写还是由 Codex 生成，只要传入非法状态，类型检查就会直接失败。

测试的作用：
执行后发现错误

类型系统的作用：
执行前拒绝错误

这两种能力并不冲突。

但在 AI 生成速度越来越快的场景里，类型系统的价值会明显上升。

因为它能在 Codex 修改代码的瞬间，就限制一部分错误进入仓库。

---

二、ChatGPT Plus 适合解释类型，ChatGPT Pro 适合设计类型边界

ChatGPT Plus、ChatGPT Pro 和 Codex 在类型驱动开发中，可以承担不同角色。

ChatGPT Plus
├── 解释已有类型
├── 总结接口结构
├── 识别重复定义
└── 生成基础类型草稿

ChatGPT Pro
├── 分析领域状态
├── 设计类型边界
├── 识别非法状态
├── 推演状态转换
└── 生成约束模型

Codex
├── 将类型落到代码仓库
├── 替换宽泛类型
├── 修复调用方
├── 补充类型测试
└── 执行编译验证

这里最关键的是 ChatGPT Pro 的位置。

复杂类型设计并不是简单地把 string 改成联合类型。

它需要理解业务语义：

哪些状态是合法的？
哪些状态组合不应该存在？
哪些字段只在特定状态下出现？
哪些操作只能发生一次？
哪些转换必须经过中间状态？

这些问题本质上是领域建模问题。

ChatGPT Pro 更适合在 Codex 动手之前，先把业务约束转换成类型结构。

---

三、AI 最容易制造的是“非法状态可表示”

软件系统中有一个经典问题：

Make illegal states unrepresentable.

也就是：

尽量通过类型设计，让非法状态无法被代码表示。

例如，一个支付结果可以简单设计为：

type PaymentResult = {
  success: boolean
  transactionId?: string
  errorMessage?: string
}

这个类型看起来很方便，但它允许很多非法组合：

const result1: PaymentResult = {
  success: true,
  errorMessage: "支付失败"
}

或者：

const result2: PaymentResult = {
  success: false,
  transactionId: "TX-10001"
}

从类型角度看，这些对象完全合法。

但从业务角度看，它们是矛盾的。

更合理的建模方式是使用可辨识联合类型：

type PaymentResult =
  | {
      status: "SUCCESS"
      transactionId: string
      paidAt: Date
    }
  | {
      status: "FAILED"
      errorCode: string
      errorMessage: string
    }

此时，成功结果必须包含交易编号，失败结果必须包含错误信息。

非法组合无法通过类型检查。

宽松对象类型：
允许错误状态存在，再依赖测试发现

可辨识联合类型：
从语言层阻止错误状态出现

对于 Codex 来说，这种类型结构非常重要。

因为 Codex 会根据已有类型生成代码。

如果类型本身模糊，AI 也容易生成模糊逻辑。

如果类型表达清晰，AI 的执行空间就会被自然压缩。

---

四、类型系统是给 Codex 的机器可读业务文档

过去，类型系统主要被理解为开发工具。

但在 ChatGPT Pro 和 Codex 进入工程之后，类型还有一个新的作用：

类型是 AI 可以直接读取的业务约束。

例如：

type User =
  | {
      role: "ADMIN"
      permissions: AdminPermission[]
    }
  | {
      role: "CUSTOMER"
      membershipLevel: MembershipLevel
    }

这个定义已经在告诉 Codex：

管理员拥有 permissions
普通用户拥有 membershipLevel
两类用户的数据结构不同
不能把两种角色当成完全相同对象处理

相比一段自然语言文档，类型有几个优势：

类型可以被编译器检查
类型与代码同步
类型可以约束调用方
类型可以被 IDE 和 Codex 直接读取

所以，类型系统可以被理解成一种机器可执行文档。

README：
描述系统应该如何工作

Type System：
限制系统可以如何工作

这两者的强度完全不同。

文档可以被忽略。

类型约束无法轻易绕过。

---

五、从 DTO 类型到领域类型

很多项目虽然使用 TypeScript、Java、Kotlin 等强类型语言，但仍然没有真正利用类型系统。

常见写法是：

type CreateUserRequest = {
  email: string
  phone: string
  age: number
}

表面上看有类型。

实际上 email、phone 和 age 仍然只是基础类型。

这意味着：

const request: CreateUserRequest = {
  email: "not-an-email",
  phone: "abc",
  age: -100
}

编译器仍然会接受。

类型只是表达数据形状，没有表达业务语义。

更进一步的做法，是建立领域类型。

type Email = string & {
  readonly __brand: "Email"
}

type PhoneNumber = string & {
  readonly __brand: "PhoneNumber"
}

type Age = number & {
  readonly __brand: "Age"
}

再通过构造函数创建：

function createEmail(value: string): Email {
  if (!value.includes("@")) {
    throw new Error("Invalid email")
  }

  return value as Email
}

function createAge(value: number): Age {
  if (!Number.isInteger(value) || value < 0 || value > 150) {
    throw new Error("Invalid age")
  }

  return value as Age
}

最终 DTO 可以写成：

type CreateUserRequest = {
  email: Email
  phone: PhoneNumber
  age: Age
}

这种结构的价值在于：

验证不再分散在各个业务函数里
非法值无法随意进入领域层
Codex 更容易识别数据边界
调用方必须经过合法构造过程

ChatGPT Pro 可以帮助团队识别哪些基础类型应该升级为领域类型。

Codex 则可以负责在代码仓库内逐步迁移。

---

六、不要让 Codex 到处写 if，要让类型承载约束

AI 生成业务代码时，一个常见倾向是不断增加条件判断。

例如：

function handleUser(user: User) {
  if (user.role === "ADMIN") {
    if (user.permissions) {
      // ...
    }
  }

  if (user.role === "CUSTOMER") {
    if (user.membershipLevel) {
      // ...
    }
  }
}

代码中存在大量防御性判断，通常说明类型没有正确表达业务关系。

如果 ADMIN 一定有 permissions，类型就应该保证这一点。

type AdminUser = {
  role: "ADMIN"
  permissions: AdminPermission[]
}

type CustomerUser = {
  role: "CUSTOMER"
  membershipLevel: MembershipLevel
}

type User = AdminUser | CustomerUser

之后：

function handleUser(user: User) {
  switch (user.role) {
    case "ADMIN":
      processAdminPermissions(user.permissions)
      return

    case "CUSTOMER":
      processMembership(user.membershipLevel)
      return
  }
}

类型收窄会自动完成。

这说明一个很重要的问题：

低质量 AI 代码：
通过大量 if 修补不确定性

高质量类型设计：
在进入业务逻辑前消除不确定性

ChatGPT Pro 和 Codex 真正高阶的配合，不是让 Codex 更快增加判断，而是让 Pro 先重构领域模型，再让 Codex 按类型边界执行。

---

七、状态机比布尔字段更适合 AI 理解

很多系统喜欢使用多个布尔字段表示状态。

例如：

type Order = {
  paid: boolean
  cancelled: boolean
  shipped: boolean
  refunded: boolean
}

这种结构允许大量矛盾状态：

paid = false
shipped = true

cancelled = true
shipped = true

refunded = true
paid = false

如果四个布尔字段自由组合，共有：

2⁴ = 16 种状态

但业务上可能只有五六种状态真正合法。

这种设计会显著增加 ChatGPT Pro 和 Codex 的推理难度。

更合理的方法是显式状态机：

type OrderState =
  | {
      type: "CREATED"
      createdAt: Date
    }
  | {
      type: "PAID"
      transactionId: string
      paidAt: Date
    }
  | {
      type: "SHIPPED"
      trackingNumber: string
      shippedAt: Date
    }
  | {
      type: "CANCELLED"
      reason: string
      cancelledAt: Date
    }
  | {
      type: "REFUNDED"
      refundId: string
      refundedAt: Date
    }

状态转换可以明确建模：

type OrderEvent =
  | {
      type: "PAY"
      transactionId: string
    }
  | {
      type: "SHIP"
      trackingNumber: string
    }
  | {
      type: "CANCEL"
      reason: string
    }
  | {
      type: "REFUND"
      refundId: string
    }

再由状态转换函数控制：

function transition(
  state: OrderState,
  event: OrderEvent
): OrderState {
  switch (state.type) {
    case "CREATED":
      if (event.type === "PAY") {
        return {
          type: "PAID",
          transactionId: event.transactionId,
          paidAt: new Date()
        }
      }

      if (event.type === "CANCEL") {
        return {
          type: "CANCELLED",
          reason: event.reason,
          cancelledAt: new Date()
        }
      }

      throw new Error(
        `Event ${event.type} is not allowed from CREATED`
      )

    case "PAID":
      if (event.type === "SHIP") {
        return {
          type: "SHIPPED",
          trackingNumber: event.trackingNumber,
          shippedAt: new Date()
        }
      }

      if (event.type === "REFUND") {
        return {
          type: "REFUNDED",
          refundId: event.refundId,
          refundedAt: new Date()
        }
      }

      throw new Error(
        `Event ${event.type} is not allowed from PAID`
      )

    default:
      throw new Error(
        `No transition allowed from ${state.type}`
      )
  }
}

相比多个布尔字段，显式状态机更适合 AI Agent 理解。

因为状态空间是可枚举、可验证、可测试的。

---

八、穷尽性检查可以防止 Codex 遗漏新增状态

假设未来新增一个订单状态：

type OrderState =
  | { type: "CREATED" }
  | { type: "PAID" }
  | { type: "SHIPPED" }
  | { type: "CANCELLED" }
  | { type: "REFUNDED" }
  | { type: "PARTIALLY_REFUNDED" }

如果业务代码中的 switch 没有处理新状态，就可能产生遗漏。

可以通过 never 类型实现穷尽性检查：

function assertNever(value: never): never {
  throw new Error(
    `Unexpected value: ${JSON.stringify(value)}`
  )
}

function getOrderLabel(state: OrderState): string {
  switch (state.type) {
    case "CREATED":
      return "待付款"

    case "PAID":
      return "已付款"

    case "SHIPPED":
      return "已发货"

    case "CANCELLED":
      return "已取消"

    case "REFUNDED":
      return "已退款"

    case "PARTIALLY_REFUNDED":
      return "部分退款"

    default:
      return assertNever(state)
  }
}

当新增状态却没有补充分支时，编译器会报错。

这对 Codex 特别有价值。

因为 Codex 修改一个核心联合类型后，类型系统会自动提示所有遗漏的调用方。

类型传播能力：
修改一个核心类型
编译器暴露所有受影响区域
Codex 根据错误逐步修复

这比依赖人工搜索更可靠。

---

九、ChatGPT Pro 可以先设计代数数据类型，再让 Codex 实现

复杂业务状态适合使用代数数据类型，也就是通过和类型与积类型组合数据。

例如，一个异步请求状态经常被写成：

type RequestState = {
  loading: boolean
  data?: User
  error?: Error
}

这个定义允许：

loading = true
同时存在 data 和 error
loading = false
data 和 error 都为空

更合理的定义是：

type RequestState<T> =
  | {
      type: "IDLE"
    }
  | {
      type: "LOADING"
    }
  | {
      type: "SUCCESS"
      data: T
    }
  | {
      type: "FAILURE"
      error: Error
    }

这就是一种代数数据类型。

其合法状态被明确枚举。

ChatGPT Pro 可以在设计阶段识别：

当前对象存在多少非法组合？
哪些字段实际上互斥？
哪些字段依赖特定状态？
是否适合改成联合类型？

然后生成迁移方案：

第一阶段：
定义新状态类型

第二阶段：
增加适配层

第三阶段：
迁移核心调用方

第四阶段：
迁移 UI 状态判断

第五阶段：
删除旧布尔字段

Codex 再根据任务规格逐步执行。

这比让 Codex 一次性“优化状态管理”更加安全。

---

十、类型系统无法表达所有业务规则

类型系统很强，但不能解决所有问题。

例如：

订单总金额必须等于所有商品金额之和
退款金额不能超过实付金额
优惠券有效期必须晚于创建时间
库存扣减必须保持并发一致性

这些规则通常涉及运行时数据。

仅靠静态类型难以完全证明。

因此，AI 原生工程需要多层约束：

Static Type
    ↓
Runtime Validation
    ↓
Domain Invariant
    ↓
Automated Test
    ↓
Production Monitoring

例如：

type Money = {
  currency: "CNY"
  amountInCents: number
}

function assertValidRefund(
  paidAmount: Money,
  refundAmount: Money
): void {
  if (refundAmount.currency !== paidAmount.currency) {
    throw new Error("Currency mismatch")
  }

  if (refundAmount.amountInCents <= 0) {
    throw new Error("Refund amount must be positive")
  }

  if (
    refundAmount.amountInCents >
    paidAmount.amountInCents
  ) {
    throw new Error(
      "Refund amount cannot exceed paid amount"
    )
  }
}

类型保证币种字段存在。

运行时校验保证金额关系合法。

测试保证常见路径不回归。

监控发现生产环境中的异常。

不存在单一安全机制
只有多层防线

ChatGPT Pro 可以帮助设计这些防线。

Codex 可以负责把不同防线落到具体代码。

---

十一、契约应该成为 ChatGPT Pro 与 Codex 的共享接口

类型主要约束单个代码库内部。

当系统跨越多个服务时，还需要契约。

例如订单服务调用支付服务：

type CreatePaymentRequest = {
  orderId: string
  amountInCents: number
  idempotencyKey: string
}

type CreatePaymentResponse =
  | {
      status: "SUCCESS"
      transactionId: string
    }
  | {
      status: "REJECTED"
      reasonCode: string
    }

但如果不同服务各自复制一份类型，仍然可能逐渐漂移。

更合理的是使用契约源：

API Schema
    ↓
生成客户端类型
    ↓
生成服务端类型
    ↓
生成契约测试

例如 OpenAPI、Protocol Buffers、GraphQL Schema 或内部 IDL。

可以抽象为：

Single Contract Source
├── Request Schema
├── Response Schema
├── Error Schema
├── Compatibility Policy
└── Version Policy

ChatGPT Pro 在规划跨服务任务时，应优先读取契约。

Codex 修改实现前，应检查是否需要改变契约。

如果任务要求保持兼容，则 Codex 不应该直接更改公共响应结构。

---

十二、类型驱动可以降低上下文需求

大模型处理复杂代码仓库时，一个现实限制是上下文有限。

项目越大，Codex 越不可能一次读取所有文件。

良好的类型设计可以降低上下文需求。

例如，一个函数签名：

function refundOrder(
  order: PaidOrder,
  amount: RefundableAmount
): Promise<RefundResult>

即使没有读取函数内部，Codex 也可以从类型判断：

只能退款已支付订单
退款金额必须经过合法构造
结果包含明确成功或失败状态

相比：

function refundOrder(
  order: any,
  amount: number
): Promise<any>

前者提供了更高密度的工程语义。

可以理解为：

类型质量越高
每个 Token 携带的业务信息越多
AI 所需上下文越少

因此，类型系统不仅提高安全性，也提高 AI 对代码仓库的理解效率。

---

十三、Any 会扩大 Codex 的错误空间

在 TypeScript 项目中，any 是一个危险信号。

它相当于告诉编译器：

停止检查这里的一切

对于 AI 生成代码来说，any 还会产生另一个问题：

停止向 Codex 提供语义约束

例如：

function processOrder(order: any) {
  return order.user.profile.name
}

Codex 无法确定：

order 是否一定有 user？
user 是否一定有 profile？
profile 是否一定有 name？
name 是否可能为空？

更合理的是：

type OrderUserProfile = {
  user: {
    profile: {
      name: string
    }
  }
}

function processOrder(
  order: OrderUserProfile
): string {
  return order.user.profile.name
}

如果数据本身不可信，应在边界层使用 unknown：

function parseOrder(input: unknown): Order {
  return orderSchema.parse(input)
}

关键区别是：

any：
放弃检查

unknown：
要求先验证，再使用

在 ChatGPT Pro 与 Codex 的工作流中，应该尽量减少 any，优先使用 unknown 和明确验证。

---

十四、边界验证比内部防御更重要

来自外部的数据天然不可信：

HTTP 请求
数据库旧数据
消息队列
第三方接口
配置文件
用户输入

这些数据进入系统时，需要经过验证边界。

例如使用 Schema：

import { z } from "zod"

const CreateOrderSchema = z.object({
  userId: z.string().uuid(),
  productId: z.string().uuid(),
  quantity: z.number().int().positive()
})

type CreateOrderInput =
  z.infer<typeof CreateOrderSchema>

入口处验证：

function handleCreateOrder(
  rawInput: unknown
): CreateOrderInput {
  return CreateOrderSchema.parse(rawInput)
}

一旦通过验证，内部代码可以使用可信类型。

外部世界：
unknown

验证边界：
schema.parse

领域内部：
trusted type

这种结构对 Codex 很友好。

因为 Codex 不需要在每个函数里反复生成防御代码。

它只需要遵守边界：

所有不可信数据在入口验证
所有领域内部数据默认可信

---

十五、形式化约束可以分级推进

不是所有团队都需要直接使用复杂形式化验证。

更现实的方式是建立约束成熟度等级。

Level 0：弱类型或大量 any
Level 1：基础静态类型
Level 2：领域类型与联合类型
Level 3：运行时 Schema 与契约测试
Level 4：状态机、属性测试、不变量验证
Level 5：形式化规格与模型检查

ChatGPT Plus 适合协助 Level 1 到 Level 2 的理解与迁移。

ChatGPT Pro 适合设计 Level 2 到 Level 4 的领域约束。

Codex 适合在明确任务边界下执行代码迁移和测试补充。

对于支付、权限、库存、认证等高风险模块，可以逐步提高约束等级。

对于内部工具和低风险页面，不必过度形式化。

关键不是追求最复杂的类型，而是让约束强度与业务风险匹配。

---

十六、属性测试比示例测试更适合复杂状态空间

普通单元测试通常使用几个具体示例。

it("should reject negative refund", () => {
  expect(() =>
    refund({
      paid: 100,
      amount: -1
    })
  ).toThrow()
})

但复杂业务可能有大量输入组合。

属性测试关注的是所有输入都应该满足的性质。

例如：

任何退款金额都不能大于实付金额
任何取消操作都不能增加订单总额
任何状态转换都不能跳过必要阶段

可以抽象为：

function refundInvariant(
  paidAmount: number,
  refundAmount: number
): boolean {
  if (
    paidAmount <= 0 ||
    refundAmount <= 0 ||
    refundAmount > paidAmount
  ) {
    return false
  }

  const remaining = paidAmount - refundAmount

  return remaining >= 0
}

ChatGPT Pro 可以帮助识别领域不变量。

Codex 可以根据不变量生成属性测试。

这比只补几个示例测试更接近业务本质。

---

十七、AI 生成代码的正确顺序应该改变

很多人使用 Codex 的顺序是：

先生成实现
再补类型
再补测试

这会导致实现先决定结构，类型和测试只能被动追赶。

更合理的顺序是：

ChatGPT Pro 分析领域
    ↓
定义状态和不变量
    ↓
设计类型与契约
    ↓
编写测试或属性
    ↓
Codex 生成实现
    ↓
编译器与测试验证

也就是：

Spec First
Type First
Test First
Implementation Later

示例流程：

type TaskPlan = {
  domainModel: string
  invariants: string[]
  typesToCreate: string[]
  testsToCreate: string[]
  implementationTasks: string[]
}

ChatGPT Pro 先生成 TaskPlan。

Codex 按阶段执行。

如果类型和测试还没有建立，就不允许进入核心实现。

这能显著降低 AI 自由发挥的空间。

---

十八、一个类型驱动的 Pro + Codex 工作流

可以设计如下流程：

type DomainSpecification = {
  entities: DomainEntity[]
  states: DomainState[]
  invariants: DomainInvariant[]
  transitions: DomainTransition[]
}

type CodexTypeTask = {
  specification: DomainSpecification
  allowedFiles: string[]
  forbiddenFiles: string[]
  requiredChecks: string[]
}

class TypeDrivenAIWorkflow {
  async run(requirement: string) {
    const context =
      await chatgptPlus.summarizeRequirement(
        requirement
      )

    const specification =
      await chatgptPro.designDomainModel(
        context
      )

    const typeTask: CodexTypeTask = {
      specification,
      allowedFiles: [
        "src/domain/**",
        "src/types/**",
        "tests/domain/**"
      ],
      forbiddenFiles: [
        "database/migrations/**",
        "src/payment/**"
      ],
      requiredChecks: [
        "typecheck",
        "unit-test",
        "contract-test"
      ]
    }

    const typeResult =
      await codex.implementTypes(typeTask)

    const typeCheck =
      await runTypeCheck()

    if (!typeCheck.passed) {
      return {
        status: "TYPE_CHECK_FAILED",
        errors: typeCheck.errors
      }
    }

    const implementationResult =
      await codex.implementBehavior({
        specification,
        typeResult
      })

    const verification =
      await runVerification()

    return {
      specification,
      typeResult,
      implementationResult,
      verification,
      requiresHumanReview: true
    }
  }
}

这段结构的重点是：

Codex 不是先写业务逻辑
而是先接受领域模型约束

---

十九、类型错误是低成本错误，生产错误是高成本错误

软件错误的修复成本与发现时间密切相关。

编写阶段发现
成本最低

代码审查发现
成本增加

测试阶段发现
成本继续增加

生产环境发现
成本最高

类型系统的作用，是尽可能把错误提前。

例如：

字段不存在
状态分支遗漏
返回类型错误
非法参数组合
不兼容接口修改

这些错误如果能在 Codex 生成后立即通过类型检查发现，就不需要等到测试甚至生产环境。

可以用一个简化公式表示：

Error Cost
≈
Detection Delay
×
Affected Scope
×
Recovery Complexity

ChatGPT Pro 和 Codex 提高了变更速度。

类型系统则负责降低错误延迟。

两者必须一起使用。

---

二十、类型不能替代人的领域判断

需要注意的是，类型系统表达什么，本身也是一种设计决策。

如果领域模型理解错误，类型越严格，错误模型反而越难修改。

例如错误地假设：

一个订单只能有一次退款

于是定义：

type RefundedOrder = {
  refundId: string
}

但真实业务支持多次部分退款。

正确模型可能应该是：

type RefundRecord = {
  refundId: string
  amountInCents: number
  refundedAt: Date
}

type RefundedOrder = {
  refunds: RefundRecord[]
}

因此，ChatGPT Pro 可以辅助领域分析，但最终仍需要业务和技术人员判断。

类型系统能保证模型一致
不能保证模型本身正确

这也是人类审查仍然不可替代的原因。

---

二十一、未来代码仓库会更像“约束网络”

过去代码仓库主要由实现组成。

未来适合 ChatGPT Pro 和 Codex 协作的代码仓库，会包含更多约束元素：

Repository
├── Domain Types
├── API Contracts
├── Runtime Schemas
├── State Machines
├── Invariants
├── Property Tests
├── Contract Tests
├── Architecture Rules
└── Code Implementation

实现只是约束网络中的一个部分。

Codex 在修改代码时，会同时受到多种限制：

类型限制字段组合
Schema 限制外部输入
状态机限制转换路径
契约限制接口变化
测试限制行为回归
架构规则限制依赖方向

AI 的执行空间越明确，输出越稳定。

---

二十二、结语：AI 时代，真正高级的代码不是生成得快，而是错误难以表达

ChatGPT Plus、ChatGPT Pro 与 Codex 正在快速降低代码生成成本。

但软件工程的目标从来不是生成更多代码。

目标是建立可维护、可验证、可演进的系统。

当代码生成不再稀缺，真正稀缺的是约束。

ChatGPT Plus：
整理需求和现有类型

ChatGPT Pro：
分析领域、状态与不变量

Codex：
在类型边界内执行代码变更

编译器：
拒绝非法结构

测试系统：
验证运行时行为

人类：
判断领域模型是否正确

这套结构可以表示为：

Human Intent
    ↓
ChatGPT Pro Domain Modeling
    ↓
Type System
    ↓
Codex Implementation
    ↓
Compiler Verification
    ↓
Runtime Test
    ↓
Human Review

未来成熟的 AI 编程，不应该只是：

让 Codex 帮我写出功能

而应该是：

先用 ChatGPT Pro 明确业务状态和不变量
再通过类型系统限制合法实现空间
最后让 Codex 在约束内完成代码

类型系统不会阻止所有错误。

但它可以把一部分错误从运行时提前到编译时，把一部分模糊规则变成机器可检查约束，把一部分业务文档变成 Codex 可以直接理解的工程结构。

可以用一个公式概括：

AI Code Reliability
=
Model Capability
× Type Constraint Strength
× Runtime Verification
× Human Domain Judgment

如果只有 ChatGPT Pro 和 Codex 的生成能力，没有类型约束，AI 可能更快地产生大量表面正确的代码。

如果只有类型，没有正确领域模型，系统只会更加严格地实现错误需求。

真正可靠的方式，是让人类定义业务事实，让 ChatGPT Pro 帮助抽象领域，让类型系统表达合法状态，让 Codex 在边界内实现，让测试和审查完成最终验证。

当代码生成越来越容易，优秀的软件工程不会以“写了多少代码”作为标准。

而会以另一个更严格的标准衡量：

这个系统是否通过类型、契约和不变量，让错误代码越来越难被表达？

这才是 ChatGPT Pro、Plus 与 Codex 进入严肃软件工程之后，类型系统重新成为核心基础设施的原因。