一个初二学生在无代码编辑器里做自行车小游戏，他想要的规则只有一句：“谁先超过对手三次就赢。”如果把这句话交给一位游戏程序员，程序员脑子里会立刻出现一串结构：需要一个触发器，在名次发生变化时触发；需要一个变量，记录每名车手的超车次数；需要一个状态判断，只有比赛处于进行中时才计数；需要一条规则，当某人的超车次数达到3时，比赛切换到结束状态并判定他获胜。
学生不会这样想，也没有必要这样想。他说的那一句话已经包含了全部意图，缺的只是有人把它准确地翻成机器能执行的结构。无代码平台如果只是把代码换成一堆下拉菜单，让学生去选“触发器类型”“变量作用域”，那不过是把编程换了一种更繁琐的写法。乐鱼体育对无代码的理解是：它首先是一层翻译。
两套语言：开发者的四个词，玩家的四句话
开发者描述游戏逻辑时，常用的是四个基础概念：
- Trigger（触发器）：某件事发生的那一刻，比如碰到终点线、球进篮筐、计时归零。
- State（状态）：游戏当前处于哪个阶段，比如准备、进行中、暂停、结束。
- Variable（变量）：需要被记住和计算的数字，比如得分、圈数、超车次数、剩余时间。
- Rule（规则）：把前三者连起来的判断，比如“当得分变量达到10，且状态为进行中，则切换到结束状态”。
普通玩家描述同一件事，用的是完全不同的句子：到达终点、超过对手、得到10分、比赛结束。这些句子里没有一个技术词，但它们各自对应着上面某几个概念的组合。翻译层的工作，就是在这两套语言之间建立稳定、可核对的对应关系。
对照表：把技术结构翻成四类说法
为了让普通创作者有一个稳定的心理模型，翻译层把所有规则归为四类：条件（什么时候）、事件（发生了什么）、规则（那就怎样）、目标（怎样算赢）。下面是几句常见说法的对照：
| 玩家说的话 | 技术上的结构 | 归入哪一类 | 编辑器里显示为 |
|---|---|---|---|
| 到达终点 | Trigger：车手进入终点区域；Variable：记录冲线顺序 | 事件 | 当【车手】【冲过终点线】 |
| 超过对手 | Trigger：名次数值变小；Variable：超车次数加1 | 事件 | 当【车手】【名次上升一位】 |
| 得到10分 | Variable：得分；Rule：得分大于等于10 | 目标 | 【任一队伍】【得分达到10分】即获胜 |
| 比赛结束 | State：从进行中切换到结束 | 规则的结果 | 那么【比赛结束】 |
| 只有比赛开始后才算分 | State：进行中时才允许计分 | 条件 | 仅在【比赛进行中】时 |
| 最后一分钟进球算双倍 | Variable：剩余时间；Rule：剩余时间小于60秒时得分乘2 | 规则 | 当【剩余时间少于1分钟】，【得分翻倍】 |
| 摔车后从上一个检查点重来 | Trigger：摔车；State：复位中；Variable：最近检查点 | 规则 | 当【车手摔倒】，【回到上一个检查点】 |
表格最右列是关键。编辑器里显示的不是变量名，而是用方括号标出可替换部分的中文句子。用户点击任何一个方括号，就能从一组同类说法里换一个，比如把【冲过终点线】换成【完成第3圈】，把【得分达到10分】换成【领先对手5分】。句子结构不变，用户就始终知道自己在改的是事件、条件还是目标。
翻译必须是双向的
很多工具只做了一半翻译：用户用自然语言描述，系统生成逻辑，然后就结束了。问题在于，用户无法确认系统翻得对不对。那个学生说“超过对手三次就赢”，系统也许理解成“名次上升三次”，也许理解成“超过同一名对手三次”，从表面上看不出区别，直到试玩时才发现不对。
所以翻译层必须能把逻辑再翻回来。系统生成规则后，会在规则卡片上用完整句子复述：“当任一车手的名次累计上升3次时，比赛结束，该车手获胜。被反超后再次超过，也计为一次。”最后一句是系统主动补上的细节，因为它是这条规则最容易产生误解的地方。用户读完卡片，如果发现和自己想的不一样，直接在卡片上改，而不需要去理解背后的变量。
模糊词要追问，不能替用户决定
日常语言天然有歧义，体育游戏里的常用词尤其如此。翻译层需要识别出这些词，并在生成时追问：
- “超过对手”：是名次上升就算，还是必须超过前面那一个具体的人？被反超后再超回来算不算新的一次？
- “比赛结束”：是第一名冲线就结束，还是所有人冲线才结束，还是时间到了就结束？如果第一名冲线就结束，其余车手的名次怎么定？
- “得到10分”：是累计10分，还是一次得分动作得到10分？两队同时达到10分怎么办？
- “撞到障碍就输”：是整场比赛输，还是这一回合输，还是扣一条命？
追问的方式也属于翻译层设计的一部分。好的追问给选项，不问开放式问题。比如针对“比赛结束”，系统给出三个选项并各配一句后果说明：“第一名冲线即结束，其余车手按当时位置排名”“所有人冲线才结束，最多再等60秒”“10分钟时间到即结束”。用户点一下就行，不需要组织语言回答。
同一句话，在不同运动里要翻成不同结构
翻译层还有一个容易被低估的难点：同一句日常说法，放在不同运动里对应的技术结构并不一样。“出界”在篮球里意味着球权交换，触发器是球或持球人接触边线外区域；在自行车竞速里，“冲出赛道”通常意味着减速或复位到赛道上，不涉及球权；在高尔夫里，打出界外要按规则罚杆并重新击球。“领先”在篮球里是比分差，在竞速里是名次和时间差，在高尔夫比杆赛里则是杆数更少。
所以翻译层不能只有一张通用词典，而是每种运动各有一套词表，并且和运动类型绑定。在乐鱼体育的编辑器里，用户在篮球项目里点开【出界】，看到的后续选项是“交换球权”“界外发球”；在竞速项目里点开同一个词，看到的是“减速”“回到赛道”“罚时”。用户感觉自己一直在用同一种语言说话，系统则在背后按运动类型选用了不同的翻译规则。
翻译层不是把细节藏起来
有一种常见担心：翻译成普通话之后，是不是就只能做简单游戏了？事实上，翻译层改变的是表达方式，而不是表达能力。一条“最后一分钟进球算双倍，但只在比分落后时生效”的规则，技术上需要同时读取剩余时间、双方比分和当前状态，但在编辑器里它仍然是一句可读的话：当【剩余时间少于1分钟】并且【本队比分落后】，【得分翻倍】。条件可以叠加，规则可以串联，复杂度并没有被砍掉，只是换成了句子的形式。
对于想深入的用户，编辑器提供高级视图，可以直接看到每张规则卡片背后的触发器、状态和变量，甚至看到比赛的状态流转：准备、倒计时、进行中、暂停、结束、结算。一个学生可能一开始只用句子，做到第三个游戏时开始好奇“为什么暂停时计分不会动”，这时候打开高级视图，就会看到“仅在进行中时计分”这条条件。翻译层在这里也起了一点教学作用：它让用户从自己熟悉的语言出发，慢慢看到游戏逻辑的真实结构。
规则之间怎样互相牵制、冲突怎样被发现，是另一层问题，可以参考无代码平台如何呈现规则关系；如果想比较句子式编辑和拖拽式编辑各自适合什么场景，可以看拖拽制作与自然语言生成的区别。
回到那句“超过对手三次就赢”
那个初二学生最后得到的是一张规则卡片，上面写着：“当任一车手的名次累计上升3次时，比赛结束，该车手获胜。被反超后再次超过，也计为一次。”他读了一遍，把最后一句改成了“只有超过不同的对手才计数”，因为他发现按原来的规则，两个人来回互超就能很快结束比赛。这个修改背后，系统新增了一个记录“已超过哪些对手”的变量，并调整了计数规则，但学生看到的只是一句话的变化。无代码的意义就在这里：用户用自己的语言思考游戏，系统负责让这些语言在机器那一端同样精确。
