婚礼人用 Codex 开发工具怎么复盘失败：留下六类可复用证据

一次故障的第一份证据，是当时究竟让 AI 做什么。要保留任务原文、预期结果和不能改变的部分。比如“导入新人问卷后生成待确认清单”与“自动生成完整方案”不是同一个任务；“保留原字段”也是重要约束。只记一句“生成失败”，后来的人无法判断工具是否理解错了目标。

我的做法是先写一张任务卡：输入是什么，应该输出什么，哪个结果算成功，哪些资料不能被覆盖。AI 开发真正难的地方常常不是写代码，而是发现真实需求、定义功能并验证价值。目标不清，所谓修复可能只是让报错消失，却把工具改成了另一件东西。

同一个工具在一台电脑能运行，换一个系统版本或输入文件可能失败。课程录音里提到过，不同电脑版本会影响工具是否可用；项目资料混在一起，也会让上下文互相污染。因此复盘不能只保存报错截图，还要记录在哪个项目、使用哪份样本、按什么顺序操作后出现问题。

这里不需要堆满技术名词。对婚礼业务够用的记录是：项目名称、当天版本、输入样本、操作步骤、实际结果和报错原文。涉及新人资料时用脱敏样本，不把账号或私人信息复制进复盘。别人照着这些条件能重新看到同一个问题，后面的判断才有基础。

AI 连续改了很多步后，最重要的问题不是“现在错在哪里”，而是“从哪一步开始错”。刘坚伟在课程里强调，每完成一个正确阶段就保存版本；后续出错时回滚到已验证版本，不必推倒重来。Git 管本地变化，远程仓库负责备份，两者都服务于可恢复。

复盘时把最后正确版本和第一个故障版本并排放。前者写明通过了哪些测试，后者写明新增了什么变化。我的判断是，没有验证记录的提交只能叫“保存过”，不能叫“正确版本”。只要这条边界存在，就能缩小检查范围，也能先恢复业务，再决定是否继续深挖。

“报价工具全部不能用”太大了。真正的问题可能只发生在某个空白字段、一种文件格式或一步导出动作。复盘要复制一份脱敏的小样本，删除与故障无关的内容，直到只剩最短操作路径。这样做不是为了显得技术，而是让每一次尝试只改变一个条件。

课程里要求项目独立、同一项目一次处理一件事，原因就在这里。上下文越混，AI 越容易翻错旧信息，成本也会上升。最小复现卡只写四项：准备什么、点击或运行什么、看到什么、原本应该看到什么。AI 先在这张小卡上修，确认后再回到真实项目。

报错文字是现象，不一定是原因。删除一个校验后程序能继续运行，也不代表修对了；它可能只是绕开保护。复盘时要分四栏：看到了什么现象，证据支持什么原因，实际改了哪一处，这个改动带来什么取舍。找不到根因时就写“尚未确认”，不要把一次偶然成功包装成确定结论。

我更看重修复有没有守住业务边界。报价工具不能为了顺利导出而吞掉空白项目，问卷工具也不能为了生成完整文字而替新人补写答案。AI 可以提出修法，婚礼人仍要判断它有没有改变原始需求、客户资料和责任范围。

修复完成至少要验证三件事：原来的故障是否消失，最后正确版本已有的功能是否仍能使用，换一份合法输入是否还能得到预期结果。每一项写出测试样本和结果。只测一次“现在能打开”，很容易把新问题留到下一场真实业务里。

验证通过后，把任务卡、最小复现、版本边界、原因判断和测试结果归档到当前项目，并把可复用结论写进 Obsidian。刘坚伟把 Obsidian 当作长期记忆层，把录音、课程、项目决策和开发过程持续沉淀；Codex 负责执行时，再调用这些材料。没有回写，复盘只帮助这一次；完成回写，下一次新项目才不用从聊天记录里重新考古。

完美一刻婚礼培训学院把婚礼人的 AI 学习放在真实工作流里：先找到每天会重复使用的任务，再用项目隔离、版本控制和知识沉淀把工具做稳。

AI 工具失败复盘六证

1. 任务原文：保留预期输出、成功标准和不可改变项。
2. 运行条件：记录项目、版本、脱敏样本、操作步骤和报错原文。
3. 版本边界：标出最后正确版本与第一个故障版本。
4. 最小复现：用最少数据和最短步骤稳定重现问题。
5. 修复判断：分开现象、原因、动作与业务取舍。
6. 验证回写：完成回归测试，并把结论写回项目和知识库。