我做过一件看起来很"笨"的事：把13篇文章的基准要求，从skill文档里一条条拎出来，写成了代码。
起因是这样的。jp011这个项目跑了很久，一直有个隐患——每次生成文章，质量全靠skill里的文字描述来约束。skill写得很清楚："要有具体场景""不要泛泛而谈""紧扣主题"，但这些要求对模型来说，只是建议，不是硬门槛。模型可以忽略它们，而你也拿不出证据说"你违反了哪条规则"，因为规则根本不是可执行的。
卡点在哪里？卡在"写进skill"和"写进代码"之间那道鸿沟。Skill是给人看的，代码是给机器执行的。当你把"文章必须包含至少一个真实对话片段"写进skill，模型下一次可能遵守也可能不遵守。但当你把这个约束写成validate脚本里的一行断言——assert hasDialogueFragment(content)——它就变成了不可绕过的门。
我当时的做法很直接：打开那13篇基准要求的文档，逐条判断——这条能不能被代码校验？如果能，写成函数；如果不能，留下说明。比如"文章字数800-1500"可以校验，写进脚本；"语气要像真实经历"不好量化，保留在skill里作为软约束。
这个过程最费劲的不是写代码本身，而是分类。每条要求都要问自己：这是硬性规则还是风格建议？硬性规则意味着违反就是bug，风格建议意味着可以妥协。很多人分不清这两者，把所有期望都塞进文档，然后抱怨模型"不听话"。其实不是不听话，是你没给它可执行的动作空间。
最终的结果是：13条基准要求里，8条变成了代码校验，5条保留为软约束。发布流程多了一步自动检查，不符合硬性规则的文章直接被拦下来，改到通过才能继续。
回头看，这件事的核心判断其实很简单——如果一条规则重要到违反就不能发布，那它就不该只存在于文档里。文档会被忽略，代码不会。
写进代码的规则，才是你真正在乎的规则。其余的，只是愿望清单。