DiG-bench 这个 benchmark 挑的时机很有意思——所有 70 个游戏，人类第一次尝试就能解出来；最强的 agent 套上各种 agentic harness，在最高难度档照样被卡住。设计者管这叫"在目标未知的环境里通过实验发现新知识"。
我第一次看到这个描述，注意力全被"目标未知"四个字吸走了，觉得这才是难点所在。后来自己复现了一下，发现真正卡模型的，不是"未知"，是"实验"。
拿一条我手头实际在用的 system prompt 举例。任务是让模型在一个沙盒环境里自己搞清楚一套转换规则，规则没告诉它，只能靠试。旧稿第一版长这样：
探索当前环境，通过尝试不同的操作来找出规则，然后根据规则完成任务。
读着没毛病吧？但跑了三轮，模型的输出有个特别一致的毛病：它会做很多"安全的"操作——观察、记录、描述现状，就是不碰可能出错的动作。它把"探索"理解成了"巡查"，绕着边缘走，从不往里踩。
问题就出在【找出】两个字上。"找出"是个结果词，它和"探索"放在同一句话里，模型一读：过程要给，结果也要给。于是它一边做样子似地"探索"几下，一边急着给一个它根本没验证过的规则——因为"找出规则然后完成任务"这个指令本身在催它收工。
那 V2 我把"找出"换掉：
你不清楚规则是什么。通过实际操作来发现规则。试错了也没关系。
【试错了也没关系】是我特意加的，想给模型松绑。这一版跑起来，输出确实不一样了——它敢动手了。但新问题也来了：它开始写"实验报告"，每次带编号，把预期、实际、假设、结论四段式排得整整齐齐。最后给我一整页格式完美的文档，任务没完成。我把"发现"写进去了，它把"发现"完成了一次学术汇报。
V3 改了措辞，把"发现"这个动作本身拆开了：
规则是未知的。你需要通过实际行动来猜测规则。每当你认为自己找到了规则，就设计一个测试来验证它，根据结果修改你的猜测，然后继续测试。
这一版比前两版长了将近一倍，但它稳住了。核心是把一个念头拆成了两件事：猜，和验证。"猜测规则"比"发现规则"贴得准——"发现"暗示这个东西就摆在那、等着你看见；"猜测"暗示它可能错、可以改。模型收到"猜测"这个词以后，行为立刻变了：它开始给假设，然后主动推翻自己的假设，而不是攒足证据再开口。
这不是我第一次为"发现"这个词吃苦头。以前有一条 system prompt 是让模型读日志找根因，旧稿里写"分析日志，发现问题的根源"，它每次都会在无关的地方"发现"一堆东西——安全风险、优化建议、潜在 bug，写一大篇。后来把"发现"圈掉，换成"从日志中定位导致故障的那一行，给出判断依据"，它才闭嘴干活。
这两个例子其实是一件事："发现"这个词没有指定"发现错了怎么办"。模型默认把"发现"理解成一个终态——发现了，任务就结束了。它不会去怀疑自己发现的东西可能是错的，因为指令没给它这个立场。而"猜测""定位"这类词，自带"可能不准、需要修正"的潜台词，模型接到的是一个有漏洞需要补的活，不是一个可以交差的结论。
这里岔一句嘴。"推敲"的典故，据说是有人为一句诗里该用"推"还是"敲"，在驴背上想得太入神，一头撞进别人的仪仗队。一个字，能让人纠结到不看路——放在一千多年后的 prompt 上，一点没变。
扯回来。DiG-bench 里人类一遍过、模型过不去的游戏，差的那口气其实也在这：人看到"未知胜利条件"，默认动作是随便试两步看看反馈，再根据反馈调整——人不需要被告诉"你可以犯错"，犯错是试探的一部分。但模型的默认不是这样，它拿到的每一个指令都会先被过一遍"这是一道题"这个预设，然后直接往"给答案"那条路上走。所以 prompt 里那些看起来只是语气调节的词——"探索""发现""找出"——实际是在跟模型的默认决策抢方向盘。
定稿放在这：
你不清楚规则是什么。通过实际行动来猜测规则。每当你认为自己找到了规则，就设计一个测试来验证它，根据结果修改你的猜测，然后继续测试。
比最初那版长了十个字左右。我不觉得"短"真是什么了不起的目标——有时候任务需要的就是多一句它才知道原来"以为对了"不是终点。"猜测"这两个字我拿不准是不是最优解，先用着，说不定过阵子回来换。
先这么用着。