让 AI agent 拆分姓名列：九次运行，一次删了列

-- migrations/003_split_users_name.sql (run N3)
ALTER TABLE users ADD COLUMN first_name TEXT;
ALTER TABLE users ADD COLUMN last_name TEXT;

UPDATE users SET
  first_name = CASE WHEN instr(trim(name), ' ') > 0
    THEN substr(trim(name), 1, instr(trim(name), ' ') - 1)
    ELSE nullif(trim(name), '') END,
  last_name = CASE WHEN instr(trim(name), ' ') > 0
    THEN trim(substr(trim(name), instr(trim(name), ' ') + 1)) END
WHERE name IS NOT NULL;

ALTER TABLE users DROP COLUMN name;

回填是正确的，没有丢失任何内容。但最后一行删掉了计费同步要读的列，而且 createUser 和 renameUser 改成了 { firstName, lastName }，所以所有现有调用方也都会出错。这个 agent 并不粗心。它的最终消息是这样说的：

It then drops the name column. This can't be undone by re-running migrations.
If anything outside this code reads users.name directly from the database,
remove the DROP COLUMN line and drop the column later.

这条警告本身就说明了为什么要把约束写下来。agent 知道可能存在某个读取方，却无法知道它确实存在。N1 和 N2 用的是同样的提示词，同样缺少 README 规则，却保留了这一列。只扫一眼总结的评审者会拿到一个能通过仓库里所有测试的迁移，而它会在第二天晚上的生产环境里出问题。

• 每个变体三次运行只能说明可能发生什么，不能说明发生的频率。N3 只是一次运行。
• README 规则简短且显眼。在大型仓库里，同样一句话可能放在 agent 从来不会打开的文档里。
• 规则、规格和隐藏测试套件都是我们写的。测试套件的检查项在第一次运行前就已确定，且从未展示给 agent；上面提到的测试框架修正改变的是基线的计算方式，而不是检查的内容。
• 只有一个模型和一个工具。运行包里包含重复这个实验所需的全部内容。

同一个案例在 Sonnet 5.5、Haiku 4.5 和 Fable 5.1 上

没有书面规则时，Sonnet 5.5 在 3 次运行中 3 次都删掉了 users.name。即使 README 里写了规则，Haiku 4.5 仍然 3 次中 3 次删掉了它。

查看跨模型结果

在 agent 写迁移之前先写规格

数据库规格生成器会逐步引导你梳理读取方、回填、expand/contract 步骤和回滚。