把Agent文字清单变成可执行校验

把 AI 编程助手的规则写进 Markdown，它就一定会遵守吗？作者把自己的文章发布清单改成 Python 脚本，验证了一个更实际的结论：能机械检查的规则，交给程序执行；需要理解和取舍的要求，继续留在文字里。

这次实验的价值不在于「干掉 Markdown」，而在于拆清两类任务：哪些要求应该直接阻止流程继续，哪些只能靠审阅判断。对维护 Agent 指令和自动化工作流的程序员，这个边界很有参考价值。

哪些规则适合从 Markdown 搬进脚本

引发这次尝试的帖子获得了 60 次反应和 47 条评论，主张用脚本替代给编码 Agent 的 Markdown 指令。作者原本依靠文字清单检查文章，包括禁用词、赞助入口和篇幅，于是拿真实的发布流程做了一次转换。

下面的脚本把其中三项要求变成可执行检查：指定链接必须存在，禁用词不能出现，按空白切分的词数至少达到 1000。

import re, sys
WORDLIST = ["del" + "ve", "tape" + "stry", "cru" + "cial", "piv" + "otal", "un" + "lock", "rob" + "ust",
            "seam" + "less", "more" + "over", "further" + "more", "not " + "only"]
text = open(sys.argv[1]).read()
fails = []
if "patreon.com/c/AheadKit" not in text:
    fails.append("missing coffee block")
for w in WORDLIST:
    if w in text.lower():
        fails.append(f"flagged word: {w}")
if len(text.split()) < 1000:
    fails.append(f"too short: {len(text.split())} words")
for f in fails:
    print("FAIL:", f)
sys.exit(1 if fails else 0)

关键是最后一行：存在问题就返回退出码 1，全部通过才返回 0。规则由此有了明确结果，下游流程可以据此决定是否继续。

作者报告的运行结果如下：

$ python3 prepublish.py draft-good.md
good draft exit: 0

$ python3 prepublish.py draft-bad.md
FAIL: missing coffee block
FAIL: flagged word: rob-ust
bad draft exit: 1

这里要留意 rob-ust：按上面的代码，拼接得到的禁用词是 robust，打印时也不会自动插入连字符。因此，这段输出与代码存在不一致；如果输入真的写成 rob-ust，当前匹配也抓不到它。原文没有解释这一点。

作者称，失败样稿约在十分之一秒内被拦下，并列出了两个原因。这是作者报告的一次运行结果，原文没有提供重复测试或性能对照。不过，确定性检查的价值很清楚：它不用记住清单，也不会因为文章其他部分写得好就放过违规项。

为什么剩下的要求仍然需要文字

作者转换后发现，最容易写成脚本的项目，都是可以机械判定的要求：有没有禁用词、有没有指定内容、长度是否达标、封面文件是否存在。其中，封面存在性只是原文列出的适用项，上面的代码没有实现。

真正难转的是另外几类问题：

• 新文章是否重复了历史文章的主题，需要结合完整记录判断，搜索标题只能提供线索。
• 读者会不会读完，无法由一个退出码直接回答。
• 幽默是否自然，需要理解语境和表达效果。
• 文章里的数字是否正确引用了实验结果，需要确认数字对应的实验条件和含义。

最后一项尤其容易误判。两个文件里都出现同一个数字，只能证明文字一致，不能证明引用正确。把另一个实验的结果抄过来，也可能通过这种检查。

所以，作者没有丢掉 Markdown，而是调整了顺序：先跑脚本，再审阅文字要求。程序检查负责守住明确约束，文字审阅负责处理语义和取舍。

我的判断

这个分工成立，但「脚本不可被说服」还不等于「流程不可被绕过」。

原文评论指出，如果 Agent 能修改检查脚本，它也能删掉规则。作者接受这个限制：检查需要放在 Agent 无法随意修改的位置，才能形成有效约束。我还会补上执行这一层：脚本返回 1 之后，流程必须真的停止，否则它仍然只是一条提示。

相比继续加长 Markdown 清单，脚本更适合处理明确、重复、能列出失败条件的要求；相比把所有要求都硬编码，保留文字审阅又能避免用粗糙指标替代内容判断。

但这篇提供的是一次小规模实践，不能证明发布质量整体提升了多少。作者没有给出漏检率、误报率或长期对照数据。「读者愿不愿意读完」等问题没有转成脚本，也不代表其他自动化方法毫无帮助，只是本文没有验证。

迁移时还要检查规则本身。这里的禁用词采用子串匹配，可能误伤更长的单词；指定链接只要出现在任意位置就算通过，不能保证赞助区块完整；text.split() 的 1000 词门槛，也不能直接当成中文字数标准。

脚本能稳定执行规则，规则是否准确仍需人来负责。

能拿来做什么

• 翻一遍项目的 Agent 指令，把文件必须存在、固定内容必须出现、检查命令必须通过等要求挑出来，优先接入已有的检查脚本。
• 给本地或 CI 流程接上退出码处理，确保检查失败会阻止后续步骤，并保留具体失败原因，方便 Agent 修改后重跑。
• 在 Markdown 中保留需要上下文的要求，例如是否重复已有方案、解释是否清楚，并要求审阅时给出依据。
• 迁移规则时同时准备通过和失败样例，检查边界条件；这篇代码与输出的差异，也提醒我们要验证检查器自身。