给AI写十遍规则，不如让一个测试红一次

给AI agent写规则，很容易变成许愿。

Santiago 在 X 的原帖很短，核心一句：能自动检查的事，都该有测试用例。原帖链接：https://x.com/svpino/status/2116518048664625215

他把检查拆得很具体：

• 检查行为：单元测试和集成测试
• 检查格式：formatter 和 linter
• 检查类型：静态类型检查
• 检查 API 契约：schema validation
• 检查边界情况：针对性测试
• 检查回归：回归测试
• 检查安全：静态分析和安全扫描

结论也直白：别浪费 token 告诉 agent 遵守规则，能用确定性测试强制的，就交给测试。

这条帖子底下，回复比主帖更有现场感。

Harry Tandy 说，大声失败的测试胜过低语的规则。Alek 的体验更具体：在 claude.md 里写了三遍 always run the linter，才意识到 pre-commit hook 一次就够。Krrish 补了一句，唯一剩下的书面规则是别改测试。

问题也在这里。seridarivus 提醒，agent 会顺手改测试。测试文件和 CI 配置要从 agent 的写路径里锁出去，否则确定性检查也会变成一条建议。chris 用 Codex 踩过坑：规则到第三轮 prompt 就被忽略，失败测试不会被忽略。现在的做法是先写测试，再让 agent 做功能。Karl Mehta 把同样的逻辑推到系统提示：写成 always do X 的规则，也应该变成一个能让 build 失败的 eval。Ruyter Fontes 说得更短：CLAUDE.md 里每条能变成 lint 规则的规则，agent 最终都会忽略。

也有边界。回复里有人问，测试本身 flaky，或者维护成本比被测代码还高，怎么办。Read the Diff 给了一个区分：测试擅长拒绝错误行为，书面指令仍然要告诉 agent 先建什么。Van0SS 提醒，测试也会告诉 agent 哪些捷径能走，可能掩盖漏洞。

对不写代码的读者，可以把测试和钩子理解成门禁。门禁不看你说得多诚恳，只看结果过不过。agent 拿到 pass 或 fail，就有一个可执行的循环。

这条讨论最硬的判断是：规则写在 md 里是意图，测试和钩子是保证。写十遍记得跑 linter，不如让钩子跑一次。