夜雨聆风前几天晚上，我太太坐在书桌前赶一份报告，第二天一早就要交。
她听我念叨过很多次 AI，便打开对话框，把需求输进去。文字一行行出来，她看了十几秒，觉得方向不对，又换了一种问法。第二次生成的内容仍然差点意思。
她看了一眼时间，关掉窗口。
“算了，来不及了，我还是自己写吧。”
一个半小时后，报告写完了。她头也没抬，又补了一句。
“你那个 AI，关键时候靠不住。”
这句话让我想了很久。她已经愿意试 AI，拦住她的是交付风险。报告明早要用，方向错了要返工，数据写错了还得由她负责。手工虽然慢，结果大致可预期。AI 快不快，在这个时候反倒排在后面。
我做了十几年软件开发，工程师遇到这种风险，很少靠劝大家大胆一点来解决。一个新系统值不值得信任，也不会只看演示时表现有多好。我们会先把它放进一套受约束的流程，让错误看得见，让旧系统随时能接管，再逐步扩大它负责的范围。
这套办法可以用来处理 AI。
重构有一个前提，外部结果不能坏
软件工程里的重构有很严格的含义。程序员调整代码内部结构，软件对外表现仍要保持不变。用户原来能完成的事，改完以后还得完成。原来算对的账，不能因为代码漂亮了就算错。
所以，真正的重构从来不只是“每次改一点”。每次改动之后都要验证。自动化测试、代码审查和运行监控各管一段，目的很朴素，尽快发现哪一步把原有功能弄坏了。
普通人把一部分工作交给 AI，也要先找出自己的“外部结果”。对我太太的报告来说，明早按时交付是硬约束，数据不能写错，格式还得符合单位的习惯。文采好一点可以加分，前面几项出了问题，报告就不能用。
很多人使用 AI 时，先写一大段提示词，随后凭感觉判断结果“好像还行”。这个验收方式太松。AI 能不能进入工作流程，取决于你能否说清成品怎样才算合格。
有些任务容易验收。把一张表转成文字，可以逐项对数字。把会议记录整理成待办，可以回到原记录核对负责人和日期。让 AI 判断一件你自己也拿不准的专业问题，验收成本可能比亲自完成还高。这样的任务暂时留在人手里，更稳。
软件测试并不保证程序永远没有错误，它让一部分错误更早暴露。给 AI 设验收标准也是这个作用。安心来自错误能够被发现。
先找到接缝，再切下一小块
老系统很少适合整体重写。它可能难看，里面却积着许多没人说得清的业务规则。程序员会先找系统里的接缝，在边界清楚的地方接入新模块，让新旧两套东西共存。这种渐进替换常被称为绞杀者模式。
人的工作流程也有接缝。一份报告从收集材料开始，随后整理结构、处理数据，再写成正文。最后还要核对和提交。这些步骤连在一起，却不必由同一个人或同一种工具完成。
我没有再让太太把整篇报告交给 AI。我让她挑一块输入清楚、输出也容易检查的工作。可以根据已经确认的表格写一段数据说明，也可以在正文写完后拟几个标题。AI 只碰这一块，其他步骤照旧。
这里有个容易忽略的工程判断。切得小还不够，边界必须清楚。让 AI “帮我把报告写好”没有清楚的边界。让它“只根据这张表写二百字，不增加原因判断，所有数字必须保留原单位”，输入、输出和限制都能看见，出了错也知道该从哪里查。
这就是模块化带来的好处。一个模块坏了，可以单独拿掉。它没有机会把整条工作流程一起拖走。
新旧流程并行，先观察，暂不接管
新系统上线之前，工程团队常会让它进入影子模式。新旧系统接收相同的数据，新系统也计算结果，但它的结果暂时不对用户生效。团队把两边的输出放在一起比较，看差异发生在哪里。
我给太太的办法也是双线并行。她继续按熟悉的方式写，保证报告能够按时交。AI 在旁边处理同一小段内容，写完以后先作为候选稿，不直接放进最终文件。
这一步会多做一点工作。工程上愿意付这笔成本，因为它买来的是观察机会。AI 擅长什么，不能只靠产品介绍来判断。连续看过几次真实输出以后，你才会知道它会在哪些地方省时间，又会在哪些地方一本正经地写错。
影子模式还有一个作用，它把“AI 靠不靠谱”这个大问题拆成了可以记录的差异。数字有没有抄错，语气需不需要重写，删掉了哪些必要信息。每次只记真正影响使用的错误。积累几次以后，你会得到一份很具体的失败清单。
下一次再交任务，就把这份清单写进要求，也把它变成验收时要检查的项目。软件团队修复缺陷以后会补一条测试，防止同样的错误再次出现。人和 AI 的合作也可以留下这种记忆。
回滚能力比一次成功更能让人安心
工程师改老系统时，总会考虑回滚。新版本出了问题，流量切回旧版本，服务先恢复，原因可以以后再查。没有回滚路径，再小的修改也会让人紧张。
手工流程就是普通人的回滚路径。刚开始使用 AI 时，不要急着删掉旧模板，也别把原始材料处理成无法恢复的样子。AI 输出始终作为副本，确认无误以后再合进正式文件。截止时间快到了，结果仍不能用，就回到手工流程，把任务交出去。
时间盒在这里承担触发回滚的作用。比如只给 AI 十五分钟，时间到了仍需反复纠正，就停止尝试。人不会掉进无休止的调试里，原来的交付计划也不会被吃光。
我太太听到这里，觉得这套办法可以接受。她不用先相信 AI。她只要相信，即使 AI 这次做坏了，自己仍有办法按时交付。
软件系统里的稳定，很大一部分也来自这里。组件会坏，网络会断，程序会有遗漏。系统提前准备了降级和恢复办法，单次故障才不会变成整场事故。
达到切换条件以后，再多交一点
影子模式不能永远跑下去。新系统连续通过检查，团队才会逐步切换真实流量。先给一小部分，再慢慢增加。每次增加以后继续观察，指标变坏就退回来。
把工作交给 AI 也需要切换条件。条件应该在尝试前想清楚。连续几次都没有事实错误，修改所花的时间确实少于自己重写，遇到失败时也能很快看出来。满足这些条件，下一次可以让 AI 的草稿直接进入编辑环节，由人审完后提交。
责任大的任务要把切换点放得更靠后。对外发布的数据、合同和专业判断，人工复核不能因为 AI 连续答对几次就省掉。内部摘要、标题备选和格式整理，风险低，交接可以快一些。工程上的权限设计也是这个道理，一个组件只拿到完成任务所需的权限，出错范围才可控制。
我太太后来又做了一次报告。按过去的速度，手工写完需要九十分钟。那次她先花三分钟给 AI 交代任务，随后继续写自己的版本。六十分钟后，她打开 AI 的结果，核对以后取了两段数据描述和一个小标题，放进正式报告。前后总共用了六十三分钟。
她没有把整份报告交出去。AI 也没有取代她的判断。可这次运行留下了有用的证据，那两类内容已经可以由 AI 先做，她负责验收。
下一次，她可以少写一份重复的草稿，把省下来的时间用在核对和判断上。再往后交多少，要看后面的结果。
信任是一段迁移过程
我们常把使用 AI 想成一个人的选择。愿意用，就把工作交出去。不愿意用，就继续手工完成。软件工程给了我另一种处理方式。新工具进入真实工作，需要经过测试、观察和小范围切换，期间一直保留回滚路径。
这几件事合在一起，才叫重构思维。它承认旧流程仍有价值，也承认新工具会犯错。人不必在第一天作出一个很大的决定，只需把流程改出一条接缝，让 AI 先承担一块能够验收的工作。
它做完以后，别急着问自己信不信 AI。核对结果，记下差异，再决定下一次给它多大的权限。
工程师很少等待一个永不出错的系统。
我们把系统设计成即使出错，也能继续工作。