OpenAI前员工造了个编译器：让AI写代码从摇奖变成流水线

去年有个数据在硅谷工程师群里传疯了：同一组提示词，GPT-4在周一和周五生成的代码，功能相似度只有73%。不是AI变笨了，是自然语言本身就是个漏勺——你说"用户资料页加验证"，AI听到的可能是6种不同的验证逻辑、4种状态管理方式、3种错误处理策略。这叫"模糊税"，工程师们正在为此支付大量返工成本。

前OpenAI技术成员Alex Komoroske最近扔了个方案：ISL（意图规范语言）。不是更好的提示词，是把AI从"老虎机"改造成编译器。这套系统已经在小范围测试，核心逻辑粗暴但有效——人类只写"要什么"，机器决定"怎么做"，且每次输出绝对一致。

老虎机困境：为什么提示工程是迷信

现在的LLM代码生成，本质是场赌博。你拉下拉杆（输入提示），可能 jackpot（完美代码），也可能再来一次（完全跑不通）。更糟的是，两天后用同样的话术、换了个模型版本，输出面目全非——变量名变了，设计模式换了，甚至埋了新 bug。

问题不在AI幻觉。自然语言天生含糊，"实现用户资料页加验证"这句话，对人类和AI都留了十几个坑：验证触发时机是实时还是提交时？错误提示放字段下方还是顶部弹窗？头像上传要不要压缩？这些决策交给LLM，等于把架构设计外包给概率分布。

行业热捧的"提示工程"，Komoroske 看得直摇头。「"你是个世界级开发者"这种前缀不是方法论，是迷信。」他说。如果你的构建流程依赖模型的"心情"，那不是流水线，是赌场。

根源在于：我们在教AI怎么做（通过示例、语气、角色扮演），而非正式定义必须发生什么。我们在和语言模型谈判，本该是在编译一份规格说明书。

ISL的五个齿轮：从谈判到编译

ISL 的核心是把"提示-生成"改造成"规格-编译-构建"。五个环节环环相扣，每个都针对传统LLM工作流的痛点。

第一步：写规格，不写提示。每个组件独立成 .isl.md 文件，定义行为、约束、验收标准——但不涉及实现细节。比如用户资料页的验证规则，写成"邮箱必须符合 RFC 5322，错误提示停留3秒后淡出"，而非"像 Gmail 那样检查邮箱格式"。

第二步：构建器解析项目图谱。它扫描所有规格文件，识别依赖关系，执行拓扑排序。传统做法是把"整个项目"扔给AI祈祷它理解上下文；ISL 构建器只提供当前组件恰好需要的信息，按正确顺序投喂。这叫"上下文手术"，不是文本垃圾倾倒。

第三步：编译器生成代码，不是猜测。构建器把精确限定的上下文传给 LLM，此时模型充当编译器后端：把确定性规格映射为目标语言的惯用语法。React、Vue、Python、Go——同一套规格，同一套行为，不同输出。

第四步：代码是只读产物。每个生成文件用加密签名锁定。代码不再是开发者的领地，而是构建产物。手改代码会破坏构建，强制要求文档（ISL）与代码永远对齐。这是"无文档遗留代码"的终结。

第五步：审计器验证行为，不止语法。它针对生成代码运行，检查状态转换是否符合规格——比如捕捉"加载标志永不重置"这类逻辑死胡同，在人类看到代码前就拦截。

编译思维 vs 提示思维：一张图看懂差异

Komoroske 画了张对比图。左侧是今天的 LLM 交互：提示词是一团自然语言，箭头指向"AI 黑箱"，输出是概率代码。右侧是 ISL 流程：规格文件进入构建器，拓扑排序后逐个编译，输出确定性产物。

关键差异在"确定性"三个字。传统方式里，"世界级开发者"前缀、示例代码的排列顺序、甚至提示里的换行符，都可能影响输出。ISL 把波动因素全部剔除——规格文件是声明式的，构建过程是函数式的，同一输入永远同一输出。

这对团队协作意味深长。现在两个工程师用同一提示词，可能因为各自"咒语"的细微差别得到不同代码，Code Review 变成"为什么你生成的比我好"。ISL 下，规格文件入版本控制，谁跑构建器都得到相同结果，争议焦点从"AI 听谁的"变成"规格定得对不对"。

从"怎么写"到"写什么"：工程师角色的迁移

ISL 最激进的暗示，是重新定义"编程"本身。传统编码里，工程师既决定做什么，也决定怎么做——选框架、设计 API、处理边界情况。ISL 把"怎么做"完全交给机器，人类只负责"要什么"的精确描述。

这像是从手写汇编跳转到高级语言，还是从高级语言跳转到配置驱动？Komoroske 的类比更直接：我们不再手写机器码，也不再需要关心编译器把 C 语言翻译成哪种汇编指令。ISL 是面向 AI 时代的"高级语言"，LLM 则是它的后端编译器。

但"精确描述要什么"比想象中难。Komoroske 承认，写好的 ISL 规格需要训练——工程师得学会像产品经理那样思考边界情况，像测试工程师那样定义验收标准。初期学习曲线陡峭，但一旦规格库建立，复用和迭代速度远超传统编码。

有个细节值得玩味：ISL 规格文件强制要求"验收标准"字段。这不是可选文档，是编译过程的必要输入。审计器靠它验证输出，构建器靠它决定何时停止优化。把测试前置到规格阶段，是 ISL 对传统 TDD（测试驱动开发）的激进改造。

开放提问：当代码变成只读，调试权在谁手里？

ISL 的"只读产物"设计引发了一个实操问题：生产环境出 bug 时，工程师怎么排查？Komoroske 的答案是"调试规格，而非代码"——通过审计器的追踪日志，定位是哪条规格约束被违反或遗漏。但这要求调试工具链完全重建，现有 IDE 的断点、单步执行都面临适配。

更深层的问题是：当"怎么做"完全黑箱化，工程师对系统的理解是否会退化？我们知道 C 语言会被编译成汇编，必要时能对照查看；ISL 生成的代码虽可读，却是"编译后优化"的结果，人类逆向推导的复杂度陡增。这是效率换可控性的交易，但交易价格尚未明码标价。

Komoroske 在系列文章的第一部分结尾留了钩子：ISL 目前处理的是相对标准化的 CRUD 场景，复杂算法和性能敏感型代码仍在探索区。他提到正在设计"逃逸舱口"机制——允许在规格中插入原生代码块，作为编译器的"内联汇编"。

这套机制怎么设计，才能既不破坏 ISL 的确定性承诺，又保留工程师的终极控制权？Komoroske 说答案在第二部分——但发布时间还没定。