Z3.07.4Adaptation review设计研究
长期共同演化需要定期复核而非放任漂移
别名: 适配复核 · co-evolution · 共同演化漂移
概念解释
用户与系统互相适应的进程不会自动停在「正好」的位置——它会继续漂到某个稳定点，而稳定不等于正确：可能是用户长期迁就系统的缺陷、系统长期迁就用户的错误用法、或双方在某个平庸的中间态锁死。长期共同演化的系统需要定期复核这个漂移：当前的适配均衡，是不是双方真想要的。
复核的对象是适配关系本身——用户的哪些习惯是为迁就系统长出来的、系统的哪些假设是为拟合用户长出来的、这些适配该不该存在——而不是逐条检查某条规则是否过时。后者是生活变化后维护规则的主题，对象是规则；这里的对象是人机之间那层互相迁就的沉积。
机制
为什么漂移不会自动到达最优？两个适应者都没有全局目标：用户在局部优化「当下顺手」，系统在局部优化「拟合观察」。两个局部优化器互相追赶，停在哪里由初始条件与噪声决定——没有任何机制保证均衡点恰好是全局最优，事实上没有理由这么巧。
沉积是层层叠加的：每次适配都是对上一状态的微调；用户今天为绕开缺陷 A 养成的习惯，明天成为系统学习「用户习惯」的输入——适配的产物被当成适配的依据，历史一层压一层，早期的小误差被后期的适配掩埋而不是清除。
而且基本不可逆：用户侧的适配固化为身体记忆后，即使系统修好了缺陷 A，绕行的习惯还在——人还在绕那个已经不存在的弯。漂移的发生是自动的，纠正漂移需要专门的动作，两者速度差一个量级。放任的结果不是「维持现状」，是持续单向劣化。
怎么研究
- 长期居住研究：智能样板房与长期部署研究（数月随访）记录了使用惯例随时间的重组——「为了技术而调整生活」逐渐常态化，住户对自身迁就的察觉随时间下降。
- 方法：漂移审计——固定间隔重测同一组基线任务（完成某事的步骤数、绕行次数、变通动作数）与用户自述负担，与首次部署时的基线对比，得到净漂移的方向与幅度；配合适配访谈（请用户演示「现在怎么做 X」并与装机时对比），把无意识迁就显性化。
边界
- **复核本身有成本下限。**复核把技术推回注意中心，违背消隐的初衷——频次要卡在漂移速度与打扰之间：学习型系统漂得快，复核密；固定规则系统漂得慢，复核疏。没有普适频率，只有与漂移速度匹配的频率。
- **有些漂移是健康的。**用户技能增长、系统确实学到真偏好——复核要能分辨方向，不是逢变必纠；把健康适应也回滚，是另一种伤害。
- **复核主体通常不是「全体用户」。**家庭里往往是安装者/管理者成员实际承担复核（谁装的谁管），其他成员是被适配的。复核设计要面对这个分工现实——给管理者复核工具，同时让被适配者有否决通道。
怎么落地
- 把「适配体检」做成产品的周期功能：每季度（或大更新后）生成摘要——这半年系统学到了什么、你改了哪些设置、哪些时段你在反复手动干预——供人判断要不要拨回。
- 给漂移提供显式的回到出发点：每个学习模块带重置/回滚到某时点的能力；没有回滚的学习没有纠错手段，等于把漂移设为不可逆。
- 监测「用户绕行」信号：重复的手动干预模式（总在同一时段手动关掉某个自动化）是适配失衡的最早信号，产品侧应主动提示复核而不是等用户来问。
- 验证办法：对部署超过一年的系统，抽查「用户完成日常任务的动作链」与装机初期的差异清单，逐项标注：系统学到的 / 用户迁就的 / 两边都退化的——第三类非零就该复核。