AI写代码3年踩坑：47%的bug来自同一句提示词

2024年Stack Overflow调研显示，76%的开发者每周用AI生成代码，但同一团队里47%的代码审查争议源于"AI这次给的和上次不一样"。

这不是幻觉问题。是我们在用自然语言指挥精确工程——像用菜谱描述造火箭。

老虎机的隐喻：为什么提示工程是伪命题

作者把当前LLM工作流比作老虎机：拉杆，出结果，换个人或换个模型，同一句话吐出完全不同的代码。变量命名风格突变、错误处理逻辑分叉、甚至架构模式都换了一套。

软件工程给这种代价起了名字：模糊税（Ambiguity Tax）。

举个例子。"实现一个带验证的用户资料页"——这句话对人类和AI都留了十几个黑洞：表单提交用REST还是GraphQL？验证失败是即时反馈还是批量报错？头像上传走预签名URL还是Base64？状态管理选Redux还是Zustand？

把这些决策扔给LLM，不是工程，是赌博。

行业热捧的"提示工程"呢？作者直言：在请求里加一句"你是世界级开发者"属于迷信，不是方法论。如果你的构建流程依赖概率模型的"心情"，你搭的不是流水线，是赌场。

核心矛盾在于：我们用自然语言描述怎么做（通过示例、语气、角色扮演），却从未正式定义必须发生什么。

我们在和语言模型谈判，本该是在编译一份规格说明书。

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

Intent Specification Language（意图规格语言）的设计，是把AI从创意搭档降级为编译器后端。不是更好的提示，是新的构建系统。

第一步，写规格而非提示。每个组件独占一个.isl.md文件，定义行为、约束、验收标准——但不碰实现细节。这相当于把"做什么"和"怎么做"彻底解耦。

第二步，Builder解析项目图谱。它扫描所有规格文件，识别依赖关系，执行拓扑排序。不再是把整个项目塞给AI祈祷它能理解，而是精确投喂当前组件所需的最小上下文，按正确顺序组装。作者称之为"上下文手术"，而非文本倾泻。

第三步，Compiler生成代码而非猜测。它将精确限定的上下文传给LLM，此时模型只负责一件事：把确定性规格映射到目标语言的惯用语法。React、Vue、Python、Go——同一套规格，同一套行为，不同输出。

第四步，代码设为只读产物。每个生成文件带加密签名，开发者手动修改会直接破坏构建。这强制建立纪律：文档（ISL）与代码永远对齐，"无文档遗留代码"成为历史。

第五步，Auditor验证行为而非语法。它在生成代码上运行，检查状态转换是否符合规格——比如一个加载标志在 human 看到代码前就陷入永不重置的死局，会被提前拦截。

从"差不多"到"必须如此"

传统提示工程的隐性假设是：AI会"理解"我的意思。ISL的假设相反：自然语言天生模糊，必须用形式化规格消除歧义。

这种转变的代价是前置工作量。写.isl.md比写一句"帮我做个登录页"慢得多。但收益在第三、第四次迭代时显现：需求变更只需改规格，重新编译，输出确定性地更新。

作者团队内部数据显示，采用ISL后，同一需求的跨模型复现率从23%提升至97%。这不是因为GPT-4变稳定了，是因为输入从"请"变成了"当且仅当"。

一个细节值得玩味：ISL刻意禁止在规格里写实现提示。你不能写"用useEffect处理副作用"，只能写"组件挂载时获取用户数据，卸载时取消未完成的请求"。AI选择具体技术方案，但边界被锁死。

这相当于给编译器立规矩：你可以优化，不能创造性发挥。

代码生成领域正在经历一场静默的范式转移。从"让AI更像人"到"让AI更像编译器"，后者听起来乏味，却是工程化的必经之路。

当AI写代码的确定性追上传统编译器，开发者会把创造力花在哪儿？规格设计，还是下一个更难的抽象层？