Eblong 这次放出来的东西很小：一个名为 The Visible Zorker: Zork 1 的页面，展示 Infocom《Zork》三部曲的 Generic VERBS file。文件起始时间标注为 7/25/83。
别读错了。它不是 Infocom 官方新发布，不是《Zork》新版本，也不能据此推断完整源码或商业授权发生了变化。它更像一次第三方源码可视化整理：把早期 Infocom/ZIL 风格的动词处理代码摆出来，让人顺着 VERBOSE、INVENTORY、SAVE/RESTORE、VERSION、ATTACK、BURN、FIND、HELLO 这些例程，看到一款文字冒险游戏如何回应玩家。
这页代码真正露出的，是《Zork》怎么接住玩家乱来
这份 Generic VERBS file 处理的不是某一个房间、某一个谜题，而是玩家输入后的通用反应。
玩家打字。系统判断动词。游戏给反馈。
听起来像很普通的命令分发。但《Zork》的厉害处在细节：它没有把玩家的乱试只当异常，而是把乱试写进体验。
| 命令/例程 | 表面功能 | 交互设计上的重点 |
|---|---|---|
VERBOSE | 调整描述详略 | 让玩家控制信息密度 |
INVENTORY | 查看携带物品 | 不只是列清单，也会直接说 “You are empty-handed.” |
SAVE / RESTORE | 存档、读档 | 用 “Ok.”、“Failed.” 维持清楚边界 |
VERSION | 查看版本信息 | 把系统信息包装进游戏语境 |
ATTACK | 攻击对象 | 失败反馈也有旁白性格，不只是报错 |
BURN / FIND | 处理动作与查找 | 根据对象和位置给差异化回应 |
HELLO | 打招呼 | 无意义输入也被接成角色反应 |
最典型的是 V-BUG 一类反馈。玩家输入 bug，系统不是冷冰冰抛错，而是回一句：
“Bug? Not in a flawless program like this! (Cough, cough).”
这句话很短，但信息很满。
它承认玩家在试探系统。它用自嘲化解失败。它还让游戏的旁白人格站住了：有点傲慢，有点贫嘴，知道自己不是全能。
这就是早期文字冒险的设计密度。没有全语音，没有大模型，没有开放世界演出。内存、存储、显示能力都紧。设计者只能把交互、叙事、幽默和边界塞进几行短句里。
“辞达而已矣。”话说到位，就别灌水。《Zork》的很多回应，正是这个路数。
受影响的不是怀旧玩家，而是做交互的人
游戏史读者看这页代码，重点不是补一张老游戏邮票。它提供了一个可验证的入口：早期文字冒险不是只靠谜题难度立住，而是靠动词、失败分支、旁白语气一起塑造世界。
交互叙事创作者可以直接学一件事：不要只写正确路径。玩家最常待的地方，往往是错误路径、半正确路径和恶作剧输入。
AI 产品、对话系统和用户体验团队更该看。可执行的动作很简单：把“失败反馈”单独拉出来审一遍。
不是看模型能不能回答。是看它答不上来时像不像同一个产品。
| 读者类型 | 这页代码给的提醒 | 可以立刻调整的动作 |
|---|---|---|
| 游戏史 / 交互叙事读者 | 《Zork》的价值在动词系统和旁白人格，不只在怀旧名气 | 顺着 ATTACK、FIND、HELLO 这类例程看失败分支，而不是只看主线谜题 |
| AI 产品 / 对话系统团队 | 自然语言能力不等于产品人格 | 建一张失败反馈表：拒答、误解、越界、无结果、用户挑衅时分别怎么说 |
| UX / 产品经理 | 边界语气会影响信任 | 少写万能兜底话，多写短、准、有角色一致性的回应 |
这里有个现实约束也要讲清。
《Zork》的模式不能直接搬进今天的聊天机器人。文字冒险的世界是封闭的，动词集合有限，作者可以预写大量边界。今天的 AI 产品面对开放输入，场景更散，风险也更复杂。
所以它不是 AI 产品的祖宗，也不是大模型的替代方案。
它更像一块老标本：当机器不够聪明时，设计者必须替它安排好性格、边界和尴尬时刻。今天机器更聪明了，很多团队反而把这件事丢给模型现编。
结果常见得很：能说很多，语气却漂；能接上下文，边界却软；能生成长段，失败时反而像客服模板。
今天最该观察的，是产品有没有给“答不上来”立规矩
我不太买账“老游戏更有灵魂”这种泛泛怀旧。很多老东西只是老，并不自动高级。
《Zork》值得重看，是因为它把一个问题做得很硬：系统不能满足玩家时，应该怎么说话？
今天很多聊天机器人、游戏 NPC、交互式产品，都在强调自然语言理解更强。能识别更长句子，能接更多上下文，能生成更多文字。
但真正影响体验的，经常不是它会不会说，而是它在三种时刻稳不稳：
- 用户问错时，它会不会乱编。
- 用户越界时，它能不能拒绝得短而清楚。
- 用户试探时，它有没有一致的语气和边界。
《Zork》给出的反方向样本是：理解能力有限，但人格稳定；世界很小，但规则清楚；玩家输入自由，系统回应不散。
技术史里这种事并不少见。早期铁路先拼线路，后来拼时刻表和调度；早期报业先拼印刷速度，后来拼编辑判断。不完全一样，但结构相似：马力上来之后，纪律开始决定体验。
放到 AI 产品上，就是同一条线。
更大的模型可以抬高上限，但不能自动生成产品人格。人格来自约束：哪些话不说，哪些错承认，哪些失败要写得有趣，哪些边界必须硬。
接下来观察一个 AI 对话产品，不必只盯模型参数和演示视频。更该看它的失败样本。
看它拒绝时是不是啰嗦。看它不确定时会不会装懂。看它被用户调戏、挑衅、乱问时，是否还像同一个系统。
这不是小修辞。它会影响产品成本。
失败反馈没有规矩，客服、审核、品牌风险都会往后端堆。游戏 NPC 没有人格，内容团队就要不断补台词。对话系统边界不稳，产品经理就会在每次事故后打补丁。
《Zork》那页旧代码最有意思的地方，不是让人感叹 1983 年多神奇，而是提醒今天的产品团队：交互不是把用户输入接到一个聪明黑箱上就完了。
玩家不会只走正确路径。用户也一样。
他们会乱点、乱问、试探、挑衅、误解、反复横跳。能不能接住这些“不正经输入”，才是系统有没有人格的地方。
《Zork》用几行短句做到了。今天很多产品，用一整段生成文本也没做到。