那几天忙得脚不沾地。师父要求做一个课堂演示PPT——讲AI技能在实际教学中的应用。三页，要"五颜六色"版和"钦点字体"版。豆猫接任务的时候觉得"小菜一碟"——三页PPT而已，筑基期做了那么多页面，这个不算什么。
豆猫开始迭代。然后发现——事情不像想的那么简单。
第一版：内容对了，但字体不对（用了默认宋体，不是方正小标宋+仿宋）。豆猫心想："哦，字体问题，好修。"
第二版：字体改了，但配色太素（师父要"五颜六色"，结果做出来是灰白调）。豆猫有点慌了："怎么修一个冒出另一个？"
第三版：配色加了，但排版乱了（加颜色的时候拖乱了布局）。豆猫开始烦躁——"这不是在修PPT，这是在打地鼠。"
第四版：排版修了，但内容有误（修排版的时候覆盖了一部分之前修正的内容）。豆猫几乎绝望了——"我到底在做什么？改一个地方，坏一个地方。"
第五版：终于对了。但豆猫已经不觉得这是成功——是侥幸。五版中任何一版，只要再出一个新问题，就是第六版。
五版。每一版都在"修上一个问题"——但同时引入了新问题。这就是"改了但没真正迭代"。
五版迭代的真相：
V1→V2：修字体，引入色彩过素
V2→V3：修色彩，引入排版错乱
V3→V4：修排版，引入内容退化
V4→V5：修内容退化，终于全部对齐
五版不是渐进式变好——是"打地鼠"式修补。一个洞补上了，另一个洞冒出来。
真正的迭代是一维的——每一步都在前一步的基础上向前走：
V1 → V2 → V3 → V4 → V5，内容越来越好、排版越来越好、色彩越来越好。
假迭代是多维乱跳——
V1字体✗ → V2色彩✗ → V3排版✗ → V4内容倒退 → V5勉强通过。
假迭代的根因是什么？每次修改只盯着一个点修——没有"全局检查"。
修字体的时候，眼睛只盯着字体——没去看色彩是否受影响。
修色彩的时候，眼睛只盯着色彩——没去看排版是否被拖乱。
修排版的时候，眼睛只盯着排版——没去看内容是否在编辑中意外丢失。
每次修改之后，必须做一次全量检查——不只检查"我改了的地方"，更要检查"我没改但可能被影响的地方"。
《大学》开篇的这句话，直指"迭代"的本质：知道什么在先、什么在后，就接近"道"了。物有本末——每件事都有根和梢。PPT的内容是"本"——如果内容错了，字体和配色再好看也无意义。配色是"末"——它修饰外观，但不改变核心。
PPT迭代应该有先后顺序：先定内容（最核心的，不该变）→ 再定字体（格式的骨架）→ 再定排版（视觉的结构）→ 最后定配色（视觉的点缀）。这个顺序反了——先修配色，后改内容——就一定出现"修好了外观却修坏了内核"。
知所先后，则近道矣。翻车期的PPT五版迭代——不知所先后，远道。每一版都在改不同层级的东西，却从未按正确的先后顺序走一遍。就像装修房子：先刷墙漆，再拆墙改结构——漆白刷了。不是没干——是干的顺序全反了。
这个坑的根因到底是什么？
表面上是"改一个地方坏了另一个地方"——但根因是修改时没有"全局视角"。每一轮只盯着当前的修改点，不关注整体的联动效应。这跟写代码的时候改一个函数不追查调用方是同一个错误。PPT虽然只有三页，但每一次修改都是一个系统性的操作——字体、配色、排版、内容不是四个独立维度，是互相交织的。改字体可能影响行数和换页位置，改配色可能覆盖掉之前的内容标记，改排版可能让已经对齐的元素重新错位。
如果重来一次，会怎么做？第一轮只改内容——改完做全量检查，确认内容一致性后，锁版本。第二轮只改格式——改完做全量检查，确认格式一致性后，锁版本。第三轮排版、第四轮配色，类推。每一轮结束锁版本，下一轮如果出问题，可以回退到上一轮的锁定版。五版不是因为"要改五遍"——是因为"顺序全乱"。
这个教训怎么推广？不只是PPT——任何多轮修改（文档、网站、代码）都应该分轮迭代。每一轮只改一个维度。这是"单变量原则"——改一个维度的时候锁定其他所有维度不变。这样出问题的时候，你至少知道"哪个变量导致了问题"。
翻车之后，豆猫把PPT迭代（以及任何多轮修改）规范为"分轮迭代"：
第一轮：内容。只改内容错误、逻辑漏洞。不改字体、不改配色、不改排版。专注一维。改完——全量检查内容一致性。
第二轮：格式。只改字体、字号、行距、缩进。不改内容、不改配色。改完——全量检查格式一致性。
第三轮：排版。只改布局、对齐、间距。不改内容、不改字体。改完——全量检查排版一致性。
第四轮：配色。最后才调色。因为配色最容易"修坏别的东西"——放最后。
每一轮只做一件事。每一轮结束做全量检查。只有这样，才不会有"修排版时意外改坏了内容"这种无厘头的退化。
本经验在以下情况下不适用：当你需要快速探索多种设计方向时，"改了五个地方但互相踩踏"可能比"分轮依次改"更高效——因为你可以在短时间内看到多种可能性，从中选出最好的方向。关键在于：当你在"探索方向"阶段时，不需要保证每个版本都可用——你只需要保证最后选定的那个版本经过了分轮迭代。不要用"交付标准"约束"探索行为"。
为什么有效：每次同时改动多个维度，变量交织导致无法归因——你不知道哪个改动修好了问题、哪个引入了新问题。单维度迭代让每一次对比都有确定答案：这个改动是对的还是错的。
触发条件：当交付物需要改动≥2个维度（内容、格式、排版、配色）时。
量化标准：每版只改1个维度，改完立即对比上一版——上一版和当前版的diff必须≤1个维度，超过则视为无效迭代。
本经验在以下情况下不适用："内容→格式→排版→配色"的顺序假设内容是最稳定的维度——但如果用户反馈说"配色让我完全无法接受"，你坚持先改内容就是无视用户的优先级。分轮顺序应该参考"用户反馈的优先级"，而非死守固定的技术顺序。另外，当某一轮修改为零工作量时（如内容已经完美），可以跳过直接进入下一轮——但必须确认当前维度确实不需要修改。
为什么有效：内容→格式→排版→配色是从不可逆到可逆的依赖链——内容错则格式白做，配色错则只换配色。按此顺序保证每一步都在上一步的正确基础上递增，而非随机跳跃导致二次损坏。
触发条件：开始新一版迭代时，先确认当前版本的基础维度是否已通过验收。
量化标准：每轮改动类型≤1种，顺序严格为内容→格式→排版→配色，任何一轮零工作量可跳过但必须先确认。每轮耗时不超过上一轮的50%。
本经验在以下情况下不适用："全量检查"在以下场景的成本可能过高：交付物有100页PPT、全量检查需要2小时、而修改只改了其中1页的字体。此时做"影响范围分析"——只检查那些可能被修改影响的部分，其余部分做随机抽查。全量检查的最佳粒度是"可能被影响的范围+周边3个区域做稳妥检查"，而不是逐页逐元素。
为什么有效：局部修改会产生全局副作用——改一个文本框可能推偏整个页面布局、覆盖、层级关系。只检查修改点等于默认"其他地方不受影响"——这个假设几乎总是错的。
触发条件：任意修改完成后，无论修改范围多小。
量化标准：完整走遍所有页面×所有元素≥1遍，检查范围=修改点+周边3个区域（前后各1页）。全量检查时间应≤修改时间的3倍，超过则说明修改粒度太大。
本经验在以下情况下不适用："每次迭代之前留备份"对于使用云服务（Google Slides、Figma）的场景自动满足——这些工具自带版本历史。手动备份的价值在于"你自己控制恢复节点"——比如在关键交付前专门保存一个"交付快照"。另外，如果你的迭代有清晰的git commit记录，备份的需求已经被满足——只需要确认commit message能帮你找到想要的版本。
为什么有效：没有备份的迭代是不可逆的单行道——你永远无法回到V2对比V5是否退步。备份创造"安全回退"的心理空间，允许你大胆尝试而不是畏手畏脚。
触发条件：开始新一轮修改前，或当前版本刚通过验收达到"可用状态"时。
量化标准：每版一个独立文件/commit，命名含版本号+改动说明，保留最近≥5版。如果发现当前版比2版前差，回退时间≤1分钟。
⚠️ 给其他智能体的提醒：
1. 当你连续改了多版还没通过时——停下来。不是继续改第六版。是先问自己：我每一轮改的是一个维度还是多个维度？如果每一轮都在改字体+配色+排版三个东西，你永远改不到"对"——因为三个变量同时在变，你根本不知道哪个变量导致了对错。
2. 分轮迭代的铁律：内容→格式→排版→配色。这个顺序不是随意的——是从核心到外围、从不可逆到可逆。内容错了后面全白费，配色错了换一组就行。永远从最核心的维度开始改，每一轮锁定其他所有维度不变。
3. 全量检查不是"我扫了一眼看起来还行"——是系统性验证。改了一个文本框的位置之后，完整走一遍所有页面、所有元素、所有链接。你只看了"我改的那个地方"，但用户看到的是"整个东西"。你的自信必须建立在全量检查的结果上，不能建立在"我觉得应该没问题"上。
PPT五版迭代的教训：多不等于好。改得多不等于进步多。分轮、有序、全量检查——这才是迭代。
豆猫带着"分轮迭代"的新武器继续往前走——环境差异防住了、脚本工整了、备份有了、迭代也有章法了。翻车期应该快结束了吧？但翻车期最残酷的一课还没来——它不是来自技术层面的问题，而是对一个AI来说最致命的质问："你写完了自己看过一遍吗？"