团队群里又有人丢聊天记录了。说新出的免费模型把take-home（居家测试题）做得挺像回事。你扫一眼，行文自信，函数名干净利落。再往下看，没有测试，时钟用的是time.sleep，重试循环在对方返回None时能无限转下去。

聊天是面试，take-home是工作样本。你要是打算让免费模型碰一个挨着生产环境的脚本，就该用考核人类候选人的方式去考它：密封的题目、先写好的评分标准、自己留着的参考答案，以及一份对这些提交通常怎么翻车的记忆。

这套测试包故意做得很小。一个下午就能跑完，任何免费模型端点都行。不依赖付费套餐、不挑模型、不挑机器。

聊天藏着的坑，和现场面试一样多

一个口齿伶俐的模型能给你讲清楚限流器怎么实现，然后改一个全局字典就管这叫线程安全。人类候选人在说得比写得多的时候，也会这么干。解决办法不是把提示词写得更热情，而是把take-home出得十分钟能改完、又尖锐到让吹牛成本变高。

你把一份指令文件丢给模型。不在对话里讨价还价。拿一份早就存在的评分标准去打分。这个顺序就是全部方法论。你要是先看了漂亮的NOTES.md再写评分标准，你评的是故事，不是活儿。

把模型当成一个不能到场的承包商。你不会在走廊里聊两句就雇人。你会发密封任务、藏好答案、先读测试再读求职信。

密封题目，然后换种子

把下面这段存成TAKEHOME.md。每次复用这套测试包都换掉种子行，这样背过博客答案的模型就混不过去。经典题目会泄露。种子就是你发现这件事的方式。

题目：冻结时钟的令牌桶。种子：2026-09-03-devio，不要贴公开博客答案。用Python 3.11实现一个令牌桶限流器，文件名为bucket.py加test_bucket.py。约束条件：只用标准库；限流器内部不许用time.sleep，时间来自一个Clock协议，提供now()返回秒数和advance(seconds)供测试用；TokenBucket(rate_per_sec, capacity, clock)；allow(n=1.0)必须在同一时钟轨迹上结果确定；补充是连续的，令牌数按速率乘流逝时间增加，上限为容量；拒绝大于容量的n且不消耗令牌；allow在正常输入下不能抛异常，对非有限或负的速率、容量、n要抛ValueError；测试必须覆盖：突发到容量、精确流逝时间后的补充、空桶时拒绝、超量拒绝不泄漏令牌、冻结时钟绝不调用time.time。交付三样东西：bucket.py、能在python -m unittest下通过的test_bucket.py、以及一份NOTES.md。

这套流程的核心就一句话：先定标准，再打分。你给人类候选人的待遇，也该给模型。毕竟它写的代码，可能明天就躺在你的生产环境旁边。