dailyprog 谜题安全网

# dailyprog 谜题安全网 · Ata Kuyumcu 的博客 来源：https://blog.lvmbdv.dev/posts/the-puzzle-safety-net/ [dailyprog](https://dailyprog.club/) 每天都需要一个新谜题。最开始我手工写了前几版草稿，然后构建了一个[生成器](https://blog.lvmbdv.dev/posts/generating-coding-puzzles-with-llms/)，用 LLM 生成谜题，并通过真实的沙盒执行来验证输出。生成器能正常工作，但仍然需要有人来运行它：选一个模式，启动脚本，检查结果，提交。顺利的时候十五分钟搞定。如果模型陷入修复循环、需要我推一把，那就要更久。有些天我连十五分钟都挤不出来，有些天干脆就忘了。 上周之前，只要出现上述情况，站点就会在午夜 UTC 时变黑，一直黑到我醒来修复它。现在不会了。每晚 UTC 22:00，也就是谜题日切换前两小时，Forgejo runner 上会执行一个 CI 任务。它检查明天的谜题是否已经存在于目录中。如果存在，什么都不做；如果不存在，就生成一个，验证，提交，然后部署。站点再也不会变黑了。 这个任务就是一个工作流文件。检查步骤只有四行 bash： ``` TOMORROW=$(date -u -d '+1 day' +%Y-%m-%d) if [ -f "workspaces/app/content/puzzles/$TOMORROW.json" ]; then echo "puzzle for $TOMORROW is already authored — nothing to do" fi ``` 如果文件缺失，任务的剩余部分就会执行：安装工具链，安装依赖，调用我自己手工运行的那个 `gen:puzzle` 脚本。模型默认使用 DeepSeek v4 Flash，难度中等，没有模式提示。多样性约束（扫描最近 7 道谜题的技术标签，阻止重复）防止模型连续生成三个二分搜索谜题。通常两次尝试就能完成。 生成部分很简单。有趣的是之后的事情。生成器脚本只有在通过所有关卡时才会将文件写入磁盘：模式验证、参考解法通过所有测试用例、暴力破解归约证明、技术多样性。这是第一道安全网。但 CI 任务无论如何还会运行第二道。生成器完成后，它会触发整个目录的测试套件： ``` pnpm run check:ci pnpm --filter @dailyprog/app exec vitest run lib/puzzles.test.ts lib/puzzle-quality.test.ts ``` `puzzles.test.ts` 加载目录中每个 `.solution.ts` 文件，并针对所有可见和隐藏测试用例运行参考解法。如果生成器产生的解法通不过自己的测试，这里就能发现。`puzzle-quality.test.ts` 运行各种保护措施：近期窗口内没有重复技术标签、没有连续两天困难模式、每种语言的输出在运行预算内。这些测试与每次推送到 main 时运行的测试完全相同。生成的谜题会经过两次测试。 如果测试通过，任务会以 puzzle-bot 的身份提交并直接推送到 main： ``` feat: add puzzle 47 - staggered delivery Auto-generated by the nightly safety-net workflow. Co-Authored-By: DeepSeek V4 Flash ``` Forgejo 会跳过使用任务自身令牌进行的推送所触发的 CI（标准循环预防），因此这次提交不会触发另一个构建。谜题已经进入 git，但还没有上线。还有一步：任务向 Forgejo 的 API 发送 POST 请求，触发部署工作流。部署工作流通过 SSH 登录 VPS，拉取新提交，使用 `--no-cache` 重建容器镜像，然后启动。新谜题大约在生成开始后 10 分钟上线。 两小时的提前量很重要。我大多数晚上会检查一下站点。如果模型生成了奇怪的东西（比如英文提示语法正确但故事讲不通的谜题，或者虽然通过了所有关卡但感觉敷衍的谜题），我还有两小时可以写一个替换品。安全网不是人类审核的替代品。它保证最坏的情况是“一道不是我写的谜题”，而不是“根本没有谜题”。 应用本身不知道这一切的存在。它只从 `content/puzzles/` 读取 JSON 文件。CI runner 和站点运行在同一台 VPS 上，是一个没有特殊权限的非特权用户。Deepseek API 密钥是限定于工作流的仓库密钥。如果 runner 宕机，站点仍然可以服务于目录中已有的谜题。 手工路径和自动路径收敛于相同的检查。我手工写一道谜题，运行测试，提交，部署。CI 生成一道谜题，运行相同的测试，提交，部署。测试不在乎 JSON 是谁写的。如果 CI 通不过测试，谜题就不会上线。如果通过了，谜题就可以放心地提供给用户。没有交接过程，没有独立的“自动生成”代码路径带有较弱的验证，也没有标记谜题为机器撰写并允许它跳过某个关卡的标志。安全网只不过是让手工工作流在无人值守时自动运行。 大多数天，我仍然自己写谜题。但那些我做不到的日子里，没人会注意到 :^)