在传统编译器中，源代码通常不会直接变成机器指令。

编译器会先把源代码转换成一种中间表示，也就是 Intermediate Representation，简称 IR。

高级语言 ↓ 语法树 ↓ 中间表示 ↓ 优化 ↓ 机器代码

中间表示的价值，是把“人类容易编写的语言”和“机器容易执行的指令”分离开。

前端编译器负责理解源语言。

后端编译器负责生成目标代码。

中间表示负责连接两端。

当 ChatGPT Plus、ChatGPT Pro 与 Codex 进入软件开发之后，一个类似的问题正在出现：

自然语言需求，是否也需要先转化成一种工程中间表示，再交给 Codex 执行？

很多人现在使用 AI 编程，仍然采用一种非常直接的方式：

自然语言需求 ↓ Codex 修改代码

例如：

帮我优化订单模块。

或者：

给登录系统增加验证码。

这种方式的问题在于，自然语言天然模糊，而代码执行必须精确。

如果中间缺少一层结构化表达，Codex 就只能自己猜测任务边界、业务规则、影响范围和验收条件。

这会让 AI 编程高度依赖模型临时推理。

更成熟的方式，应该是：

自然语言意图 ↓ ChatGPT Plus 整理背景 ↓ ChatGPT Pro 生成工程中间表示 ↓ Codex 映射到代码仓库 ↓ 测试和审查验证

这层工程中间表示，可以被称为：

Engineering Intermediate Representation

简称 EIR。

它可能成为未来 AI 软件工程中非常重要的一层。

一、为什么自然语言不能直接作为执行语言

自然语言的优点是表达能力强。

一个人可以用一句话描述复杂目标：

把订单取消流程做得更安全，避免库存重复恢复。

但这句话存在大量未定义信息：

什么叫“更安全”？ 哪些订单允许取消？ 重复恢复发生在哪一层？ 是否涉及支付状态？ 是否要求幂等？ 哪些接口必须保持不变？ 如何验证修复有效？

人类工程师会根据经验补全这些信息。

Codex 也会尝试补全。

但补全本身就意味着推测。

在软件工程中，推测越多，风险越高。

自然语言适合描述目标，却不适合直接描述完整执行约束。

可以把两种语言的特点对比一下：

自然语言： - 语义丰富 - 表达灵活 - 容易存在歧义 - 边界经常隐含 程序代码： - 语义精确 - 可执行 - 可验证 - 必须处理细节

ChatGPT Pro 和 Codex 之间，需要一种介于两者之间的表达。

它既要保留业务意图，又要增加工程约束。

这就是 EIR 的意义。

二、什么是工程中间表示

工程中间表示不是代码，也不是普通需求文档。

它是一种面向 AI Agent 执行的结构化任务模型。

一个最基础的 EIR 可以包含：

Engineering IR ├── Goal ├── Scope ├── Constraints ├── State Model ├── Invariants ├── Dependencies ├── Verification ├── Risk └── Stop Conditions

例如，一个订单取消任务可以表示为：

goal:description:"修复订单取消时库存重复恢复的问题"scope:allowed_modules:-order-inventoryforbidden_modules:-payment-authenticationconstraints:-不改变订单接口返回结构-不修改数据库 schema-不影响已完成订单-必须保证重复请求幂等state_model:valid_states:-CREATED-PAID-CANCELLED-COMPLETEDinvariants:-同一个订单只能恢复一次库存-COMPLETED 状态不能进入 CANCELLED-CANCELLED 状态重复取消不得产生新副作用verification:-原有订单测试通过-新增重复取消测试-新增并发取消测试-输出行为差异报告stop_conditions:-需要修改支付模块-需要修改数据库结构-影响文件超过 6 个

这已经比普通 Prompt 更接近工程执行协议。

Codex 不再需要自己猜测所有条件。

它只需要把 EIR 映射到代码仓库。

三、ChatGPT Plus 负责语义清洗

在 EIR 生成之前，往往存在大量原始材料：

产品需求 用户反馈 会议记录 Issue 历史文档 代码注释 错误日志 测试失败信息

这些材料可能互相冲突，也可能包含重复内容。

ChatGPT Plus 可以承担语义清洗层。

Raw Context ↓ ChatGPT Plus ↓ Normalized Context

例如，原始材料中可能出现：

需求文档： 取消订单必须恢复库存。 会议记录： 已支付订单需要先退款再恢复库存。 历史 Issue： 重复取消会导致库存增加两次。 代码注释： 订单取消操作可能被消息队列重复触发。

ChatGPT Plus 可以将它们整理成：

confirmed_facts:-未完成订单取消后需要恢复库存-取消操作可能被重复触发business_rules:-已支付订单需要先完成退款流程-已完成订单不允许取消known_risks:-重复取消导致库存重复增加-消息重试可能重复执行补偿逻辑unknowns:-并发取消是否有锁-库存服务是否支持幂等键

这一步的重点不是做最终决策，而是减少上下文噪声。

Plus 将碎片信息转化成可分析材料。

Pro 再基于这些材料生成工程 IR。

四、ChatGPT Pro 负责从语义模型生成工程 IR

ChatGPT Pro 更适合承担 IR Builder。

它需要把业务语义转换成工程结构。

可以抽象成：

typeNormalizedContext={confirmedFacts:string[]businessRules:string[]knownRisks:string[]unknowns:string[]}typeEngineeringIR={goal:Goal scope:Scope constraints:Constraint[]stateModel:StateModel invariants:Invariant[]dependencies:Dependency[]verification:VerificationRule[]risks:Risk[]stopConditions:StopCondition[]}

生成过程可以写成：

asyncfunctionbuildEngineeringIR(context:NormalizedContext):Promise<EngineeringIR>{returnchatgptPro.transform({context,objectives:["消除语义歧义","明确执行范围","提取不可破坏约束","定义验证方式","识别停止条件"]})}

这里的关键不是让 ChatGPT Pro 直接给出代码。

而是让它先完成工程建模。

就像编译器不会直接从高级语言跳到机器指令一样，AI 软件工程也不应该直接从一句自然语言跳到代码变更。

五、Codex 负责把工程 IR 映射到仓库

当 EIR 已经生成后，Codex 的任务会更清晰。

Codex 需要回答的是：

哪些文件实现了这些状态？ 哪些函数负责库存恢复？ 哪些测试对应这些不变量？ 哪些依赖会受影响？

可以定义一个仓库映射结果：

typeRepositoryMapping={affectedFiles:string[]affectedSymbols:string[]dependentModules:string[]relatedTests:string[]missingContext:string[]riskLevel:"low"|"medium"|"high"}

映射流程：

Engineering IR ↓ Symbol Search ↓ Dependency Analysis ↓ Repository Mapping ↓ Execution Plan

示例：

{"affectedFiles":["src/order/order.service.ts","src/inventory/inventory.service.ts","tests/order/order-cancel.test.ts"],"affectedSymbols":["cancelOrder","restoreInventory","OrderStatus"],"dependentModules":["message-consumer"],"relatedTests":["order-cancel.test.ts"],"missingContext":["inventory service idempotency policy"],"riskLevel":"medium"}

如果存在关键上下文缺失，Codex 不应该直接执行。

它应该进入阻塞状态：

MISSING_CONTEXT

这比模型自行猜测更加可靠。

六、EIR 可以将业务不变量显式化

真实系统中，很多关键规则并不直接写在需求里。

例如：

库存不能为负数。 支付成功订单不能直接删除。 权限校验不能依赖前端参数。 同一个事件不能重复产生副作用。

这些规则属于不变量。

Invariant = 在所有合法系统状态中都必须成立的条件

传统开发中，不变量往往分散在代码、测试和人的经验里。

ChatGPT Pro 生成 EIR 时，可以把这些规则提取出来。

typeInvariant={id:stringstatement:stringsource:stringseverity:"critical"|"high"|"normal"verificationMethod:string}

例如：

{"id":"INV-INVENTORY-001","statement":"同一个取消事件最多恢复一次库存","source":"order-domain-rule","severity":"critical","verificationMethod":"idempotency integration test"}

Codex 修改代码时，必须为每条关键不变量提供验证映射。

Invariant ↓ Code Location ↓ Test Evidence

这样，代码变更就不再只是“实现功能”，而是“维护不变量”。

七、工程 IR 可以充当多 Agent 的公共语言

当系统中不止一个 Agent 时，EIR 的价值会更明显。

例如：

ChatGPT Plus Agent ChatGPT Pro Agent Codex Agent Test Agent Review Agent Documentation Agent

如果每个 Agent 都直接处理自然语言，很容易出现不同理解。

EIR 可以成为它们之间的公共协议。

Engineering IR / | \ Codex Test Agent Review Agent

Codex 读取：

目标 修改范围 依赖关系 停止条件

Test Agent 读取：

不变量 边界场景 验收规则

Review Agent 读取：

风险等级 不可破坏约束 行为差异

Documentation Agent 读取：

业务规则 架构影响 接口变化

这类似编译器中的 IR：

不同后端都基于同一种中间表示工作。

八、EIR 需要版本化

工程任务在执行过程中可能变化。

例如：

v1： 修复重复取消。 v2： 增加并发取消场景。 v3： 明确已支付订单不能直接恢复库存。

如果 Codex 使用 v1，测试 Agent 使用 v3，就会产生不一致。

因此，EIR 必须版本化。

typeVersionedEngineeringIR={id:stringversion:numberparentVersion?:numberrepositoryBaseline:stringcreatedAt:stringchanges:string[]payload:EngineeringIR}

例如：

eir:id:ORDER-CANCEL-102version:3repository_baseline:a91f3e8changes:-新增并发取消不变量-增加已支付订单限制

Codex 执行前必须验证：

当前仓库版本 = EIR 基线版本

否则需要重新映射。

九、EIR 可以降低 Prompt 漂移

长时间使用 ChatGPT Pro 和 Codex 时，任务很容易逐渐偏离最初目标。

例如：

初始目标： 修复库存重复恢复。 中途发现： 订单状态逻辑重复。 继续扩展： 顺便重构状态机。 最终结果： 修改了整个订单模块。

这就是任务漂移。

有了 EIR，可以进行范围检查。

functiondetectScopeDrift(ir:EngineeringIR,proposedChanges:ProposedChange[]):ScopeViolation[]{returnproposedChanges.filter(change=>!ir.scope.allowedFiles.includes(change.file)).map(change=>({file:change.file,reason:"outside allowed scope"}))}

如果 Codex 想修改 EIR 范围外的内容，必须先生成变更申请。

Scope Extension Request ├── 为什么必须扩大范围 ├── 需要新增哪些文件 ├── 新增风险 ├── 是否需要重新规划 └── 是否需要人工批准

这能显著降低 AI Agent 越改越大的问题。

十、工程 IR 应该区分声明和实现

EIR 不应该包含过多具体代码细节。

否则它会变成另一份代码。

更合理的做法是区分：

Declarative IR Implementation Plan

声明式 IR 描述：

要满足什么 不能破坏什么 如何验证

实现计划描述：

具体改哪些文件 增加哪些函数 调整哪些调用

例如：

declarative_ir:invariant:-重复取消不能重复恢复库存implementation_plan:-在 cancelOrder 中增加幂等键-在 restoreInventory 中检查事件 ID-增加重复事件测试

ChatGPT Pro 负责声明层。

Codex 负责实现计划和代码层。

这样能避免 ChatGPT Pro 过早绑定具体实现。

十一、EIR 可以支持多种代码后端

一个高层任务可能需要在不同技术栈中实现。

例如：

目标： 为接口增加幂等性保护。

在 Node.js 项目中，可能使用 Redis。

在 Java 项目中，可能使用数据库唯一键。

在 Go 项目中，可能使用分布式锁或事件去重表。

如果 EIR 是声明式的：

invariant:-同一 idempotency_key 只能产生一次业务副作用

不同 Codex 执行后端可以生成不同实现。

Engineering IR ├── TypeScript Backend ├── Java Backend ├── Go Backend └── Python Backend

这类似编译器中同一个 IR 可以生成不同目标平台代码。

十二、ChatGPT Plus、Pro 与 Codex 的推荐分工

在这种架构下，三者可以这样分工：

ChatGPT Plus ├── 读取与整理原始需求 ├── 归一化术语 ├── 提取事实和冲突 └── 生成上下文摘要 ChatGPT Pro ├── 构建领域模型 ├── 提取不变量 ├── 生成工程 IR ├── 设计验证规则 └── 分析任务风险 Codex ├── 将 IR 映射到仓库 ├── 生成执行计划 ├── 修改代码 ├── 补充测试 └── 输出证据包

人类则负责：

确认业务意图 批准高风险 EIR 判断架构方案 审查最终结果 承担上线责任

十三、一个完整的 EIR 工作流

可以用 TypeScript 抽象整个过程：

typeRawRequirement={text:stringattachments:string[]}typeNormalizedRequirement={facts:string[]rules:string[]conflicts:string[]unknowns:string[]}typeEngineeringIR={goal:stringscope:{allowedModules:string[]forbiddenModules:string[]}invariants:string[]constraints:string[]verification:string[]stopConditions:string[]}classAICompilerPipeline{asynccompile(requirement:RawRequirement){constnormalized=awaitchatgptPlus.normalize(requirement)constir=awaitchatgptPro.generateIR(normalized)constrepositoryMapping=awaitcodex.mapToRepository(ir)if(repositoryMapping.missingContext.length>0){return{status:"MISSING_CONTEXT",missingContext:repositoryMapping.missingContext}}constexecutionPlan=awaitcodex.createExecutionPlan({ir,repositoryMapping})constapproval=awaithumanApprove({ir,executionPlan})if(!approval.accepted){return{status:"REJECTED"}}constresult=awaitcodex.execute(executionPlan)constverification=awaitrunVerification({invariants:ir.invariants,rules:ir.verification,changedFiles:result.changedFiles})return{status:verification.passed?"READY_FOR_REVIEW":"VERIFICATION_FAILED",ir,executionPlan,result,verification}}}

这个流程和编译器非常相似：

需求是源语言 EIR 是中间表示 Codex 是代码生成后端 测试系统是验证器 人工审查是最终链接与发布阶段

十四、EIR 不能完全由 AI 决定

需要注意的是，工程 IR 不是绝对真理。

ChatGPT Pro 生成的状态模型、不变量和风险判断，也可能有误。

因此，EIR 应该被看成可审查的工程提案。

Raw Intent ↓ AI-generated IR ↓ Human Review ↓ Approved IR

高风险领域尤其需要人工确认：

支付 认证 权限 库存 数据迁移 安全策略 公共 API

AI 可以帮助提取和结构化约束。

但不能替代业务责任和架构决策。

十五、未来的 Pull Request 可能附带 EIR

传统 Pull Request 主要包含代码 Diff。

未来由 Codex 产生的 PR，可以附带对应的工程 IR。

## Engineering IR ### Goal 防止订单重复取消导致库存重复恢复。 ### Invariants - 一个取消事件最多恢复一次库存 - 已完成订单不能取消 - 重复请求不得产生新副作用 ### Scope 允许修改： - order - inventory - order tests 禁止修改： - payment - authentication - database schema ### Verification - 单元测试 - 幂等性集成测试 - 并发取消测试 ### Codex Mapping - `cancelOrder` - `restoreInventory` - `order-cancel.test.ts` ### Remaining Risks - 消息队列真实重试场景尚未压测

审查者可以先看 EIR，再看代码。

这样比直接进入复杂 Diff 更容易判断方向是否正确。

十六、未来代码评审可能先评审 IR

当代码生成速度越来越快，代码审查压力会不断上升。

更高效的方法可能是先评审 EIR。

第一阶段： 评审目标、范围、不变量和风险 第二阶段： 批准 Codex 执行 第三阶段： 评审代码与验证证据

如果 EIR 本身就错误，就没有必要让 Codex 继续生成代码。

这相当于把问题提前发现。

错误需求 → 在 IR 阶段发现 错误范围 → 在规划阶段发现 错误实现 → 在编译和测试阶段发现

发现越早，修复成本越低。

十七、EIR 会让软件开发更接近“意图编译”

传统软件开发是：

程序员手动把需求翻译成代码

EIR 模式则是：

人类确认意图 ChatGPT Pro 编译成工程 IR Codex 编译成代码变更 测试系统验证语义保持

可以用一个公式表示：

Human Intent → Engineering IR → Repository Patch → Verified Behavior

这是一种新的编译链。

自然语言不再直接控制代码。

它先经过工程 IR 约束。

这让 AI 编程从自由生成走向结构化编译。

十八、工程 IR 可能成为新的软件资产

过去，软件资产主要包括：

源代码 测试 文档 架构图 部署配置

未来，EIR 也可能成为重要资产。

它记录：

为什么修改 哪些约束必须保持 当时的业务不变量 Codex 如何映射到代码 哪些风险仍未解决

这对于未来维护非常有价值。

半年后，团队不只可以查看 Git Diff，还能查看当时的工程意图。

Git 记录代码历史 EIR 记录意图历史

两者结合，才能更完整地解释系统演进。

十九、工程 IR 会提高代码仓库的可迁移性

当任务语义只存在于某种技术实现中时，系统迁移非常困难。

例如从 Node.js 迁移到 Java，团队需要重新理解大量历史代码。

如果核心业务规则、不变量和状态模型已经沉淀在 EIR 中，那么迁移过程会更容易。

旧代码仓库 ↓ 提取 EIR ↓ 新技术栈 Codex Backend ↓ 新代码仓库

当然，这并不意味着可以自动完成大型迁移。

但至少业务语义不再完全被旧代码绑定。

二十、结语：ChatGPT Pro、Plus 与 Codex 之间，缺少的可能不是更强模型，而是更好的中间表示

ChatGPT Plus、ChatGPT Pro 与 Codex 正在让自然语言更接近软件执行。

但从自然语言直接跳到代码，始终存在巨大的语义风险。

自然语言过于模糊。

代码执行过于具体。

二者之间需要一层新的工程抽象。

ChatGPT Plus： 整理和归一化语义 ChatGPT Pro： 生成工程中间表示 Codex： 将中间表示映射到代码仓库 测试系统： 验证执行是否满足不变量 人类： 确认意图和承担最终责任

这层 Engineering IR 可以包含：

目标 范围 状态 不变量 约束 依赖 风险 验证 停止条件

它不是代码。

也不是普通需求文档。

它是专门为 AI Agent 执行设计的工程协议。

未来成熟的 AI 软件开发，可能不会再是：

一句 Prompt ↓ 一堆代码

而会变成：

自然语言需求 ↓ ChatGPT Plus 清洗上下文 ↓ ChatGPT Pro 生成 EIR ↓ 人工确认 ↓ Codex 生成代码变更 ↓ 测试验证 ↓ 人工合并

可以用一个公式概括：

AI Engineering Reliability = Intent Quality × IR Precision × Codex Execution Quality × Verification Strength

如果没有工程 IR，ChatGPT Pro 和 Codex 之间只能依赖自然语言传递复杂任务。

模型越强，虽然能处理更多内容，但也可能更自信地解释错误上下文。

真正稳定的方式，不是让 Codex 猜得更准，而是减少它必须猜测的内容。

这也许是 ChatGPT Plus、ChatGPT Pro 与 Codex 进入下一阶段后，软件工程最值得探索的方向：

为自然语言意图和代码执行之间，建立一种可版本化、可审查、可验证的工程中间表示。

当这层中间表示成熟之后，AI 编程才可能真正从“生成代码”走向“编译工程意图”。