前阵子看到个演示，两个提示摆在一起：一个写“做一个简单的登录页”，一个写“逐条核对 PRD 里的验收标准，区分完全满足、部分满足、尚未实现”。第一句发出去，工具没反应；第二句刚敲完，侧边栏弹出来了。没人觉得第一句需要拦，第二句确实该拦一下——这个差别你我都能感觉到，但叫得出名字吗？
紧接着又看到一组数字：同一批 40 个真实任务，逐个测，38 个被补了东西，2 个原样放行。补的不是让它变长，是补验收预期、验证步骤、复现细节、约束条件、风险确认。评论区里有人在问：如果我的提示本来就写得很细，它会闭嘴吗？回答得挺好：不该为了加长而加长，已经清晰了它就该安静。这三个场景——简单的不拦、该拦的拦一下、已经够详细的别硬补——是不是同一件事？是。名字呢？
我把它叫做：过闸。
提示在离手之前，过一道闸。闸上挡的不是创意，是含糊——验收标准有没有说清楚、验证步骤有没有写下、复现路径有没有指明、风险提示有没有摆出来。你保留原文，然后决定放行哪个版本。发送权还在你手里。为什么叫“过闸”，不叫“提示增强”？增强像在替你写，写着写着就替你做了主。审查像警察，审完还得盖章。过闸没有替你写，也没有替你盖，闸门就架在发送前那一下，要过得你自己抬杆。
名字起出来，得量一量音准。过闸不是逢提示必拦。它针对的就是那种“任务需要更多结构或验证”的情况——简单 UI 改动可能不响，或者只补很少一点；复杂代码变更、部署请求会得到更细的检查项。这正是“闸”跟“自动增强”的分界：闸的第一性不是把什么都拉长，是只在需要的时候拦。演示里那句“做一个简单的登录页”没触发，恰恰说明音准对了半拍——闸不该在那种地方找存在感。
但你下次再坐下，在 Claude Code 里敲下一段 prompt，发送前顿一下——别想“我要不要再写细点”，想“这提示过不过闸”。过闸就是那一下：看原始请求还在不在、该补的验收路径有没有补上、放行键在不在你手里。把这个词当动词用，指的人多了它才活。
不过说实话，今天这闸还不是真闸。有人点了一句，建议性的东西在最不明确的请求面前最容易被忽略，这没错。现在过闸更像一张贴在发送键旁边的纸条，不是横在发送键上的栏杆。什么时候它变成为了上线 agent 必须证明自己过了闸，闸才算真的立起来。这个我暂时给不了，先吹了看。
顺带报个数字，把这个词的音量压低一点：40 个任务，27 变 29，多解决两个，5 个百分点。SWE-bench Verified 是真实 issue 当考题、人工筛过的子集，这个信号只能算方向性，不是“上了过闸就多解两个题”，是“有一道闸，至少没把题搅浑”。38 个提示被补，2 个放行，中位数 7 个章节——这些数字扔出来，是告诉你闸上补的都是些很老实的检查项，不是魔法。老实的东西反而容易群唱起来，只要叫得出名。
这个词我把它放到了公开场合，谁都能拿去用。如果你下次 review 别人的 prompt 时顺口说了句“这段该过闸了”，那它就有救。如果半年里你一次都没撞见说它的场合，我回炉——名字占了空地不让人站，比没起过它更碍事。你也不妨拿它做点破坏性测试：用它套你自己的任务，看闸门拦得准不准，把不准的地方喊出来。闸最怕的不是拦错，是放行时打瞌睡，还没人叫醒它。