今年 5 月，Claude Code 团队的 Thariq 写了一篇文章，说 HTML is the new markdown。他几乎不再写 Markdown 了，计划、方案、报告都让 Claude Code 直接生成 HTML，因为超过一百行的 Markdown 他自己都读不下去。

到了刚刚过去的国庆节，Karpathy 也发帖说了类似的观点：与其让模型写一大段文字，不如让它画图，或者直接输出 HTML 网页。

不过这些都还是提示词技巧，你得记得每次跟模型说一句“用 HTML 输出”。这次 GPT-6 推给 ChatGPT 所有用户，同时带来了一个叫 Intelligent UI 的功能，又往前走了一步。ChatGPT 回答里直接就能生成图表、按钮、表单，甚至一个能玩的小游戏，模型会根据问题自己判断要不要出界面，不再需要特殊的提示词。

我试了一些场景，也踩了个坑：专门让它“用 Intelligent UI”，它反而还是会像以往那样输出大段文字。所以，今天的内容就来聊聊这个 Intelligent UI。

Intelligent UI 是什么？

按 OpenAI 博客的说法，Intelligent UI 背后是两样东西：一个是原生的界面组件库，支持流式输出，模型从里面挑组件拼出回答；另一个是编译器，模型一边生成，界面一边渲染，不用等整段回答写完。

这跟 Thariq 那种用法不太一样。在 Claude Code 里让模型输出 HTML，是从一张白纸开始写代码，想要什么效果都行，但每次都得从头写一遍样式和交互逻辑。Intelligent UI 的积木是 OpenAI 提前做好的，是内置在 ChatGPT 界面中的一部分，模型只管挑合适的积木来搭。

OpenAI 设计师 Andrew Chen 提到，模型早就能写出好看的 HTML 了。生成式 UI 难的是另外两件事：让界面看起来本来就属于 ChatGPT，以及让模型判断什么时候真的需要界面，什么时候一段文字就够了。

拿 OpenAI 官方博客的复古游戏为例，提示词就一句“Create a retro interactive gaming console that I can play”，出来的是一台 1989 年风格的掌机。屏幕上能切换贪吃蛇、打砖块和乒乓三个游戏，方向键、A/B 键也都可以正常操控。

这句提示词一个字没提 Intelligent UI，但要什么风格、要个什么东西、要能玩，都说清楚了。

那我开头踩的那个坑，问题出在哪儿呢？

怎么触发界面

刚尝试这个功能的时候，我想让它讲讲 Transformer 的工作原理，提示词写的是“用 Intelligent UI 帮我理解 Transformer 的工作原理”。结果它还是照常给了一大段文字。

我把提示词换成“用可视化交互界面帮我理解 Transformer 的工作原理”，只改了这几个字，界面就直接出来了：

它把 Transformer 拆成了四步：Token 变向量、Self-Attention、FFN 加多层、预测下一个词，每一步都能点开查看更详细的图示界面。比如在 Self-Attention 这一步，点一下“我爱吃苹果”里的“吃”，右边的注意力矩阵就会显示它对其他词的权重，下面还配了 Q、K、V 各管什么，以及注意力的计算公式。

其实帮助文档里写了，Intelligent UI 不需要特殊提示词，出不出界面是模型根据问题自己判断的。你只说“用 Intelligent UI”，它也不知道你到底想要什么样的界面。

那怎么写才管用呢？把界面本身描述出来：要一个什么东西，上面有什么控件，改了之后什么跟着变。比如，下面几个例子效果都不错：

轨道力学那条提示词很短，但后半句很关键。这类问题模型很容易直接甩一段模拟代码给你，我猜加上“不要代码”，就等于把这条路堵死了。

想让它平时多出界面的话，也可以在 ChatGPT 自定义指令（Custom Instructions）里写上偏好。不过官方也说了，偏好只是引导，具体布局每次都可能不一样。

还有哪些坑？

除了触发问题，使用中还有几个地方要注意。

第一个是 Pro 档反而用不了。Intelligent UI 只支持 Instant 到 Extra High 这几档，最高的 Pro 档用的是 GPT-6 Astra，并不支持。另外，Work 标签页、语音模式和旧版桌面客户端也都用不了，建议直接用网页版。

第二个是界面关不干净。ChatGPT 网页版设置里可以把 Layout and visuals 调成简洁，但只会减少视觉元素，不会切回纯文本。偶尔不想要界面的话，直接在对话里说“只用文字回答”更省事。

第三个是做出来的工具留不住。组件状态换一个对话就没了，也没法单独分享给别人。这也是它跟 HTML 文件差距最大的地方，HTML 发个链接其他人就能打开。

第四个是错误答案更难发现。一个排版漂亮的计算器摆在面前，很少有人会去检查背后的公式。涉及钱的计算，最好让它把公式和假设一起列出来，自己核对一遍。

写在最后

模型越来越强大，写代码的成本也越来越低，以前根本不值得专门做的小工具，现在可以随手生成，用完就扔了。Intelligent UI 把这件事变成了 ChatGPT 的默认能力，只要把想要的界面说清楚，就能拿到一个能点能拖的交互式界面。

不过做出来的东西留不下来。想弄懂一个技术原理、临时要个小工具，交给 Intelligent UI 很合适；要保存、要分享、要反复改的方案和报告，我还是更建议在 Claude Code 或 Codex 里让 Agent 直接生成 HTML 更容易共享。

相关链接：

• OpenAI 博客 GPT-6 and Intelligent UI for everyone：https://openai.com/index/gpt-6-for-everyone/
• 帮助中心 Intelligent UI in ChatGPT：https://help.openai.com/en/articles/20001598-intelligent-ui-in-chatgpt
• Thariq《The Unreasonable Effectiveness of HTML》：https://claude.com/blog/using-claude-code-the-unreasonable-effectiveness-of-html
• Karpathy 关于输出格式的帖子：https://x.com/karpathy/status/2105819303471976479

最近这个月，我把日常干活的工具从 Claude Code 整体迁到了 Codex。一开始用 GPT-5.6 Sol，等 GPT-6 Astra 发布之后又换了过去。迁移之前，我也经常使用 Codex 做代码审核和部分开发任务，GPT-6 各项 benchmark 又很强，所以本来以为带着在 Claude Code 上积累的 Skills 和各种记忆迁过去，应该会很顺利。

结果完全出乎意料，各种问题接连冒出来：修改范围失控、子 Agent 失败后假装完成、模型失败不重试等等。

让 Codex 帮我扫了一下最近的会话历史，结合 OpenAI 官方的指南，今天就来分享一下这里面的经验教训。

1. GPT-6 对最后的指令非常敏感，如果没有限定范围，它可能会做超出这个指令的工作，导致方向走偏。

我让它改一份设计文档里的一句话，交回来整个文档的句式全变了。一开始我以为是模型把局部反馈当成了全局指令，扫完会话历史才发现更微妙：那份文档里的祈使句本来就散落在各个章节，我让它做局部修订的时候，它把“简洁清晰”这个要求理解成了整篇的写作方向，顺手把其他段落也改了。改完之后回复里写的是“读者视角核对完成”，实际上只处理了局部的理解障碍，全文的文体一致性根本没检查。

这条对 Astra 尤其明显。如果你没有显式写清楚“只改这里、其他不动”，它就会按自己的理解扩大执行范围。

2. 子 Agent 失败后不会自动重试，也不会读取之前的进度。

子 Agent 撞上 429 限流之后，父 Agent 有时候会发定向重试，但更多时候是直接跳过。更夸张的情况是：子 Agent 状态标着completed，返回内容只有一句“我会先读取规则，再检查……”，实际审查结果一个字都没有。父 Agent 看到completed 就以为这步做完了，接着往下走。

3. 429 失败后配置的重试根本不生效，Codex 会直接退出任务。

Agentic 会话的 token 消耗跟普通聊天完全不是一个量级，特别是我的日常工作还经常需要调度多个子 Agent 完成一些复杂任务，所以也经常碰到限流错误。为了让 Goal 能够在我不在的时候正常执行下去，我甚至把重试次数增大到了 30，结果还是经常碰到“正在重新连接 1/30，exceeded retry limit, last status: 429 Too Many Requests”这样的错误。查了源码才发现，Codex 压根就不重试 429 错误，碰到之后直接中止任务。

能做的事情不复杂：限制并发子 Agent 的数量，不让它一下子启动过多的并行任务，日常任务把 reasoning effort 从 max 降到 high，大部分任务也都足够用了。

4. 模型变强之后，旧规则的代价反而变大了。

GPT-6 之前的提示词，大部分在做一件事：补模型能力。“记得跑测试”“先想清楚再动手”“不要擅自扩大范围”，本质上都是在提醒模型做它自己想不到的事。Astra 不需要这种提醒了，这些行为它已经内建了。

反过来也有问题。之前为了防模型乱来写的硬边界，比如“未经许可不要修改其他文件”，Astra 会当真。它比 Sol 更倾向于完成初步实现就停下来等你审查，而不是一口气干到底。如果你的 AGENTS.md 里还有“每步都停下来确认”，它会比你想象的更频繁地停下来。

提示词的职责变了，从“补能力”变成“划边界、定完成标准”。所以，我们该做的不是加规则，是减规则。

5. Skill 描述越宽泛，越容易加载错误的上下文。

Skill 多了之后，Codex 会压缩描述来腾空间，模型看到的信息反而更少，更容易选错 Skill。

比如 OpenAI 官方文档列了一个典型的反模式：Use when working with databases, queries, models, or persistence，这种描述太宽了，任何沾数据库的任务都会触发。正确写法是：Use when adding or changing a migration, or reviewing its rollout，只在真正需要的时候才加载。

6. AGENTS.md 应该做路由器，不是百科全书。

不要写“每次编辑前先读 architecture.md、database.md 和 deployment.md”，应该改成按需索引：改 schema 的时候才读 database.md，准备部署的时候才读 deployment.md。每次都全量加载就是在烧上下文，跟当前任务无关的指导就越容易干扰结果。

以前很多 Skill 写得像详细的菜谱，每一步都写死。GPT-6 Astra 对细微差别和模糊性的理解比之前好很多，过于具体的指导反而会限制它的能力。

7. Astra 偏保守，需要你明确授权安全的工作流。

Sol 接到任务之后一口气干很久，Astra 不一样，它更倾向于完成初步实现就回来让你审查，哪怕后面还有活没干完。官方的建议是在任务开始之前就把“完成”的标准写清楚。如果你希望它做完之后自己跑测试、检查结果、修复问题，就在请求里把这些步骤明确写出来。

对于那些你确认安全的操作，可以在 AGENTS.md 里明确授权，比如：

The local tests use disposable fixtures and have no production access. Run them, fix failures caused by the requested change, and rerun affected tests without asking for approval at each step.

这样模型就不会每跑一次测试都停下来问你了。

8. 写作质量差不是措辞问题，是没给好样本。

这是在写文档时碰到最多的问题。GPT-6 把“解释完整、结构整齐、边界周全”当成写得好，但你要的往往是准确表达一个观点，让读者知道它为什么重要。在 AGENTS.md 里加一条“不要有 AI 味”没什么用，模型不知道什么算 AI 味。

有效的做法是先给它一个你认可的样稿，让它对齐调性，确认之后再往下写。如果是长文，先让它写一小段样稿给你看，调性对了再扩展全文，省得整篇推倒。另外一个经验是把“观点是否正确”和“表达是否自然”分开检查，不要用润色掩盖主题跑偏。

9. 不用自己逐条排查 AGENTS.md，让模型审计自己的规则。

AGENTS.md 和 Skills 越积越多，哪些过时了、哪些互相冲突、哪些触发范围太宽，自己一条条排查很痛苦。直接让 GPT-6 Astra 做一次只读审计就行，重点让它检查这几类问题：相互矛盾的要求、适用范围错位的 Skill 描述、无条件加载的文档、固定多轮审查流程，以及把临时环境问题写成永久规则的情况。

让它按“保留、收窄、移到专用流程、改成脚本检查、待验证后删除”这几个级别给建议。注意一点：不要因为新模型更强就默认删除权限和安全相关的约束，这些该留还是得留。

10. 跨模型兼容性：你的 Skills 会被不同模型调用。

这条容易忽略。如果你的 Skills 会被多个模型甚至多个 Agent 同时调用，比如经常在 Codex 和 Claude Code 之间切换，一定要注意验证不同模型上的行为。比如，就像我碰到的，给 Claude Code 写的 Skills 直接挪到 GPT-6 上会过度约束模型的能力，导致质量大幅下降。

如果 Skills 中某条规则是针对特定模型的行为写的，标注清楚它的适用范围，或者拆成条件加载：只在用某个模型的时候才生效。不要假设所有模型的行为都一样。