迭代：版本、反馈、重构
第一版只是起点：收反馈、改版本、敢重构——作品是长出来的。
学习证据 学完后，怎么核对？
把学习结果留在一个可以回看、可以复做的动作里；这一区只写学生能自己检查的证据。
如何核对
- 参与同意与可退出说明
- 去标识反馈与原始记录删除确认
适用边界
测试须自愿且参与者可随时退出；未成年人按学校与监护要求取得必要许可。事前说明收集项、用途、保存位置与删除时间。录音录像需单独征得同意，只留必要的去标识化结论，并按约定删除原始记录。
最后复核
这是内容复核日期，不是学习截止日期。
讲
例子自己觉得完美的 v1，班群里十分钟无人问津
小晴的值日提醒页 v1 做完那晚，她自己反复看了七八遍：配色讲究、名单整齐，完美。贴到班群，十分钟没动静；第二天问同桌，得到一句「我不知道该看哪一行啊」。她把「今天」那一行加了高亮，v2 发出去，开始有人用了；又有人说「手机上字太小」，v3 调了字号……第五版和第一版并排一比，几乎换了个页面——但每一版她只改了一两件事。这节课讲的就是这条路：像样的作品不是憋出来的，是这样一版一版长出来的。
名词迭代＝交付一个可测试版本 → 收反馈 → 改进 → 再测试的循环，每圈形成一个版本（v1、v2、v3……，靠 2.1c 的 git 快照留档）。面向真实用户发布前，仍要先过隐私、安全和基本功能检查。重构＝不改变对外可见行为，主要把内部结构理顺的改动——是否真的「功能不变」，要靠验收确认。
定义迭代环：一轮只验证少量改动
迭代环四步转一圈：交付测试版——把可用且经过基本安全检查的 vN 交给目标用户试用；看用并听说——停顿、误点等行为与用户解释互相补充，不能只取其中一种；记反馈——先确认自己听懂，不急着为设计辩解；挑重点——反馈是线索，取舍是判断：按「跟真问题相关吗」过滤。一轮只改一两件事是便于比较效果的起步策略，不是所有项目的硬规则。
环上每一步都重要；反馈不是命令，是否采纳要结合目标、风险和更多证据判断。
转了几圈之后，常会撞上另一种墙：不是缺功能，是加不动了——代码乱得下不去手。这时先停下加功能，做一次重构。三个重构信号：往里加东西越来越费劲；同一段代码复制到了第三处；上个月自己写的看不懂了。敢动手的底气来自两张安全网：git 快照（改砸了能回滚）＋验收清单（重构完把 spec.md 里的验收逐条跑一遍——功能一条没丢，重构才算成）。口诀：先跑通，再理顺。
| 重构信号 | 动作 |
|---|---|
| 加一个小功能要改五个地方 | 先拆结构，再加功能——磨刀不误砍柴工 |
| 同一段代码已复制第三处 | 抽成一个函数，三处共用 |
| 看不懂自己上月写的代码 | 改名字、加注释、拆小块——给半年后的自己留路 |
泛化换个角度：改稿、复盘，全是迭代环
作文改稿走的就是这个环：初稿（交付）→ 找愿意帮忙的同学读（目标读者）→ 标出没看懂的段（记反馈）→ 优先重写最影响理解的部分（挑重点）。运动员看录像复盘、店家按客人反应调菜单，同理。两个常见失败是：迟迟不测——闭门把 v1 磨到「完美」，错过早期发现问题；全盘听——反馈来什么改什么，作品失去边界。测试版可以粗糙，但涉及隐私、安全、付费或不可逆操作时，不能拿「以后会改」跳过基本检查。
依据与边界：ISO 9241-210:2019（以人为中心的交互系统设计）与 Nielsen (1993), Usability Engineering。少量用户测试适合尽早发现可用性问题，但不能代表所有用户；观察行为、访谈反馈和任务结果应互相补充。最后核查：2026-07-12。
例
补充三例——两个常见用法，一个易错。
阿哲的活动报名页收到反馈「找不到报名按钮」。他第一反应是「就在右上角啊，挺明显的」——话到嘴边咽了回去，先追问对方刚才在找什么。第二天又有两人在同一任务中停住。这个重复信号值得优先调查；v2 他调整了按钮位置与字号，再让相近用户完成同一任务，成功率有所上升。问题重复出现时先查设计，不给用户贴「不会用」的标签；三个样本仍不能代表所有用户。
小北想给自己 fork 的画布加个「暂停」按钮，一看代码：所有逻辑挤在一个函数里，插哪都怕碰坏别处。她先 git 拍快照，然后只做重构：拆成「画曲线」「读参数」「响应点击」三个函数，跑一遍验收——画面和交互跟原来分毫不差。这才动手加按钮，十分钟搞定。重构那一步「什么功能都没加」，却是这次加功能最值的一步。
阿凯的值日页 v1 发出去收到十二条反馈：加课表、换深色皮肤、放班歌、接入天气……他连夜全改。v2 变成一个八个方向的缝合怪——首页塞满，加载变慢，而最初那个「三秒看到今天谁值日」反而要翻半天。错在哪：把「用户要什么就给什么」当成了敬业，判断权拱手让出；十二条里其实只有两条跟真问题相关。修法：每条反馈先过一遍需求单——跟真问题相关的进本版，好想法但越界的记入待办，跟边界冲突的礼貌说不；一版仍然只改一两件事。
做
v1 发布后收到十二条反馈，靠谱的下一步是？
- 把 2.4a 立项的最小可用版做出来（或拿你手头任何一个作品当 v1），git 快照，说明写「v1」。
- 找两位符合目标用户特征、愿意参加测试的人，先说明测试对象是页面而不是人，并说明收集项、用途、保存位置、删除时间和可随时退出；未成年人按学校与监护要求取得必要许可，再征得参与者同意。使用虚构或去标识化数据，录音录像需另获明确同意。
- 给两人同一个代表性任务。先少解释，观察停顿与误点，再请对方说出原因；反馈先确认理解、不急着辩解。按「跟真问题相关吗」过滤，挑一两条改出 v2，git 快照「v2：改了什么」。
- 用 git 对比 v1 和 v2 的差异，看看这一圈到底动了哪几行；提炼匿名结论后，按约定删除原始笔记或录音录像。
怎么算过关：有两次以上 git 快照且说明可读；反馈清单里至少有一条你决定「不改」并说得出理由；v2 只改了一两件事。
卡
迭代环四步是什么？敢重构的两张安全网是什么？
交付经过基本检查的测试版 → 目标用户试用（看行为也听解释）→ 记录并确认反馈 → 挑重点验证。安全网：git 快照（改砸能回滚）＋验收清单（重构后逐条跑）。
- 测试版不必完美，但隐私、安全和不可逆风险必须先检查。
- 反馈先确认理解、不急着辩解；改哪条不改哪条，是你的设计判断。
- 加不动了先重构：先跑通，再理顺——重构前先拍 git 快照。