AI生成的补丁无法回滚就不算完成

每一条 AI 补丁都会测试它所走的正向路径，却从不测试它所遗留下来的逆向路径。CI 流水线应用补丁、运行探测、宣布完成，而回滚路径始终处于未测试状态，直到真正需要它的时刻才会暴露。这种不对称是 AI 辅助开发中最昂贵的盲区——因为模型在训练语境中从未见过回滚需求。在触碰真实数据之前，用一台临时服务器来验证补丁能否自我回滚，是成本最低的证明方式。

为什么 AI 补丁在回滚这件事上天然结构性地糟糕

AI 模型生成正向补丁的能力远强于生成回滚脚本的能力。训练数据被「添加功能、修复 bug、重构代码」的 Pull Request 所主导，而回滚提交不仅稀少，还通常是紧急情况下的产物。一个见过一万次「添加一列」的模型，可能只见过几百次「安全地删除一列」。结果是系统性的偏见：AI 生成的变更倾向于增量式的，因为增量是模型最熟悉的模式。

增量变更在合并时看起来很安全，在回滚时变得危险。添加一列只是一行迁移语句，但在新数据写入后再删除它，就成了一个可能导致数据丢失的决定。添加一个配置项是无害的，直到旧的二进制程序读取到包含未知键的配置文件。模型自信地生成正向路径，而回滚路径则是一个机械的逆向操作——忽略了在这之间写入的数据。

回滚契约包含三个条款

将回滚视为一份包含三个条款的契约，每个条款都必须单独验证。结构收敛是指回滚执行后 schema、配置和依赖版本与基线一致。数据收敛是指行、文件和状态标记与基线一致，或者仅以旧代码能够读取的方式不同。行为收敛是指系统回滚后通过与补丁应用前相同的探测用例。

大多数团队只验证第一个条款，因为「回滚脚本运行没有报错」实际上只能证明这个。第二个条款是 AI 补丁最容易出问题的地方，因为模型无法预测正向应用和回滚之间会写入什么样的数据。第三个条款是隐藏依赖浮出水面的地方，因为旧代码可能读取了新数据格式却不会崩溃，而是悄无声息地将其损坏。

往返工作流

在临时服务器上运行往返测试，而不是在 staging 环境上。目的不是模拟生产，而是给补丁一个廉价失败的机会。MonkeyCode 的免费模型可以生成补丁，你可以在同一会话中要求它生成回滚草案。它的免费服务器选项为你提供了一个可以运行往返测试的临时环境。披露：本文是 MonkeyCode 产品推广的一部分。

第一步：捕获基线。导出 schema 并记录每个表的行数。这是回滚必须恢复的参考状态。

第二步：应用正向补丁。运行迁移，然后用探测查询验证正向行为。如果正向路径失败，往返测试在此停止。

第三步：模拟补丁后写入。插入行、更新记录、更改配置——无论你的应用在补丁上线后会真实做什么。这一步是所有人都跳过的，但它恰恰是回滚存在的全部理由。

第四步：执行回滚。按照事故中实际运行的方式精确执行回滚脚本。

第五步：与基线对比。先检查结构收敛，再检查数据收敛。一个恢复了 schema 但丢失了行的回滚，已经违反了契约。

验证脚本

下面的脚本是一个模板，而非生产工具。它使用 SQLite，因为它在任何临时服务器上都可用，并且使收敛检查变得显式。

#!/usr/bin/env bash
# roundtrip_contract.sh — verify an AI patch's undo path on a disposable server
# Usage: ./roundtrip_contract.sh <db_file> <migration.sql> <rollback.sql> <probe.sql> [writes.sql]

set -euo pipefail

DB="${1:?database file required}"
MIGRATION="${2:?migration script required}"
ROLLBACK="${3:?rollback script required}"
PROBE="${4:?probe script required}"
WRITES="${5:-}"
BASELINE="baseline_$(date +%Y%m%d_%H%M%S)"

# Step 1: capture baseline schema and row counts
sqlite3 "$DB" ".schema" > "${BASELINE}.schema"
for table in $(sqlite3 "$DB" "SELECT name FROM sqlite_master WHERE type='table' AND name NOT LIKE 'sqlite_%';"); do
  echo "$table $(sqlite3 "$DB" "SELECT count(*) FROM $table;")" >> "${BASELINE}.counts"
done
echo "baseline captured"

# Step 2: apply the forward patch
sqlite3 "$DB" < "$MIGRATION"
echo "forward patch applied"

# Step 3: verify forward behavior
sqlite3 "$DB" < "$PROBE"
echo "forward probe passed"

# Step 4: simulate post-patch writes
if [ -n "$WRITES" ]; then
  sqlite3 "$DB" < "$WRITES"
  echo "post-patch writes simulated"
fi

# Step 5: execute the rollback
sqlite3 "$DB" < "$ROLLBACK"
echo "rollback executed"

# Step 6: compare schema convergence
if diff -u "${BASELINE}.schema" <(sqlite3 "$DB" ".schema") > /dev/null; then
  echo "structural=converged"
else
  echo "structural=diverged"
  diff -u "${BASELINE}.schema" <(sqlite3 "$DB" ".schema") | head -30
  exit 1
fi

# Step 7: compare row counts
for table in $(sqlite3 "$DB" "SELECT name FROM sqlite_master WHERE type='table' AND name NOT LIKE 'sqlite_%';"); do
  count=$(sqlite3 "$DB" "SELECT count(*) FROM $table;")
  baseline_count=$(grep "^$table " "${BASELINE}.counts" | awk '{print $2}')
  if [ "$count" != "$baseline_count" ]; then
    echo "data=diverged table=$table baseline=$baseline_count current=$count"
    exit 1
  fi
done
echo "data=converged"
echo "verdict=rollback_contract_holds"

一个具体的失败案例能让这个流程的价值显而易见。假设迁移添加了一个 status 列，写入文件插入了一行 status='active'，而回滚脚本删除了这一列。脚本报告 data=diverged，因为行数与基线不一致。解决方案不是跳过写入模拟，而是让回滚保留数据——比如在删除列之前先将列复制到影子表中。

局限性及适用人群

临时服务器无法复现生产环境的写入模式，因此模拟写入的质量完全取决于你的想象力。脚本比较的是行数，而非行内容，因此静默的数据损坏可能悄然通过。只写追加数据的团队、从不回滚的团队、以及从源码重建流程很简单的团队应该跳过这一步，因为回滚契约不是他们风险所在的地方。

AI 生成的回滚值得与 AI 生成的补丁同等的审视。模型可以生成一个看起来正确的回滚脚本，却仍然遗漏了应用和撤销之间写入的数据。往返测试不能替代理解数据生命周期的专业人员；它只是一种廉价的方式，迫使相关人员在事故发生之前就思考回滚路径。

如果你没有现成的临时环境，MonkeyCode 的免费服务器选项是运行这个往返测试的合理场所。生成补丁的同一免费模型会话可以起草回滚，但只有往返测试才能证明契约成立。