AI改配置文件的变更账本：merge前的回滚保障机制

为什么要读这篇

用 diff 固然可以看到 AI 补丁改了什么，但 diff 回答不了的问题是：这次改动会不会把服务搞挂、需要在合并前跑哪个配置校验命令、以及凌晨两点打完补丁后发现不对劲时该怎么回滚。这篇指南把那些缺失的知识转化为一份"附注账本"（sidecar ledger）：一份可复现的产物，里面写明了每个被改的配置文件、预估的爆炸半径（blast radius）、必须执行的校验命令，以及精确的回滚命令。它的设计刻意追求"无聊"——因为依赖模型输出来做 review 自动化的前提，是这套流程必须是确定性的。

把 AI 编辑的服务器配置当文本来 review 有什么问题

你大概已经 review 过 AI 生成的 nginx 虚拟主机、systemd unit 或 crontab 的补丁。diff review 会诱导你问自己：每一行在语法上是否说得通？但配置文件并不是纯函数——一行改动就可以迁移数据目录、打开一个调试端口、或者改变服务运行的用户身份。正确的 review 问题不只是"这看起来对吗？"，还有"这个文件涉及哪些东西、哪个校验器能证明它仍然工作、以及我如何把它恢复回去？"文本 diff 只回答第一个问题。账本回答另外两个。

工作流：快照 → 暂存 → 校验 → 回滚

本地维护两个目录树：before/ 和 after/。在允许 AI 生成的配置改动接近真实主机之前，先把当前文件拷贝进 before/、把候选版本放进 after/、然后运行账本脚本。after/ 目录不是你的生产目录，它只是一个用于对比的 dry-run 副本。声明：本文是 MonkeyCode 产品推广的一部分。如果你用 MonkeyCode 的免费模型访问来起草配置补丁，请把候选版本放在一台闲置服务器上的 after/ 目录中，并在通过 gate 之前将其视为不可信的。

下面的脚本比较两个快照并输出一张 Markdown 表格。每一行记录一个被改的文件、其状态、新增和删除的行数、一个建议的校验器，以及回滚命令。

#!/usr/bin/env python3
'''Create a review ledger for before/after server config trees.'''
from __future__ import annotations

import argparse
import difflib
from datetime import datetime, timezone
from pathlib import Path

def count_lines(path: Path) -> int:
    try:
        return len(path.read_text(errors='replace').splitlines())
    except OSError:
        return 0

def suggested_validator(rel: Path) -> str:
    name = rel.name
    if 'nginx' in str(rel).lower():
        return 'nginx -t'
    if str(rel).endswith(('.service', '.socket', '.timer')):
        return f'systemd-analyze verify {rel}'
    if 'cron' in str(rel).lower():
        return f'crontab -T < {rel}'
    if rel.suffix in {'.env', '.sh'}:
        return f'sh -n {rel}'
    return f'diff -u before/{rel} after/{rel}'

def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument('before')
    parser.add_argument('after')
    parser.add_argument('--out', default='change-ledger.md')
    args = parser.parse_args()

    before = Path(args.before)
    after = Path(args.after)

    before_files = {p.relative_to(before) for p in before.rglob('*') if p.is_file()}
    after_files = {p.relative_to(after) for p in after.rglob('*') if p.is_file()}

    rows = []
    for rel in sorted(before_files | after_files):
        bp = before / rel
        ap = after / rel

        if not bp.exists():
            added, removed, state = count_lines(ap), 0, 'added'
        elif not ap.exists():
            added, removed, state = 0, count_lines(bp), 'deleted'
        else:
            seq = difflib.SequenceMatcher(
                None,
                bp.read_text(errors='replace').splitlines(),
                ap.read_text(errors='replace').splitlines(),
            )
            added = removed = 0
            for tag, i1, i2, j1, j2 in seq.get_opcodes():
                if tag in ('insert', 'replace'):
                    added += j2 - j1
                if tag in ('delete', 'replace'):
                    removed += i2 - i1
            state = 'modified'

        if state == 'deleted':
            rollback = f'cp -p {bp} {ap}'
        elif state == 'added':
            rollback = f'rm -f {ap}'
        else:
            rollback = f'cp -p {bp} {ap}'

        validator = 'verify no remaining references' if state == 'deleted' else suggested_validator(ap)

        rows.append((rel, state, added, removed, validator, rollback))

    now = datetime.now(timezone.utc).strftime('%Y-%m-%dT%H:%M:%SZ')
    with open(args.out, 'w', encoding='utf-8') as f:
        f.write('# Change ledger' + chr(10) + chr(10))
        f.write(f'Generated: {now}' + chr(10) + chr(10))
        f.write('| file | state | added | removed | validation | rollback |' + chr(10))
        f.write('| --- | --- | ---: | ---: | --- | --- |' + chr(10))
        for rel, state, added, removed, validation, rollback in rows:
            f.write(f'| `{rel}` | {state} | {added} | {removed} | `{validation}` | `{rollback}` |' + chr(10))

    print(f'Wrote {args.out} with {len(rows)} rows')

if __name__ == '__main__':
    main()

生成的一行账本看起来是这样的：

把账本当 merge gate 用，而不是当报告用

在合并之前，你要对每个被改的文件运行校验器。nginx 改动：候选版本就位后跑 nginx -t。systemd unit：跑 systemd-analyze verify after/example.service。crontab：跑 crontab -T < after/cron.d/backup。如果校验器返回非零退出码，就停下来并回滚。你不需要说服自己"模型不行"，命令本身已经证明了配置是无效的。这个 gate 把主观的"模型质量讨论"变成了一道是非题。

为什么这比纯 diff review 更强

你能看到 listen 80; 变成了 listen 8080;，但如果没有回滚列，你的恢复路径就是另一条由模型生成的建议。有了账本，回滚操作指向的是一个已知正常的副本。你还捕捉到了文件类别：新增一条 cron 条目需要的证明，与修改一个 .env 文件需要的证明不同。账本把这种证明和改动存在一起，而不是留在 review 者的脑子里。

局限性和不适合使用的场景

不要把这份账本当通用静态分析器用。它不会解析应用特定文件（如 php.ini 或 my.cnf）内部的语义，只会执行你分配给它们的校验器。它只比较本地快照，所以环境变量、挂载的 secrets 或远程 Kubernetes 资源里的改动不会出现在账本中——除非你把它们导出到目录树里。脚本把所有文件都当作文本处理，所以二进制资源的行数统计会误导人。如果路径里包含空格，生成的反滚命令需要 shell 引号。最重要的是，这套工作流只在"先暂存"的前提下才有用；如果你把 AI 输出直接拷贝到 /etc/ 里，你已经破坏了 before 状态，审计轨迹也就没了。这套工作流不适合已经有完整配置管理、服务端校验和版本化回滚的团队，那些团队应该继续用现有的 pipeline。它面向的是目前仍在文本编辑器里 review 生成补丁的个人运维者和小型服务器团队。

把账本放在 diff 旁边，你就不用再争论模型输出怎么样，而是把时间花在跑那条真正能证明服务还能启动的命令上。