2.5 属性依赖：让两个变量牵手
2.5 属性依赖：让两个变量牵手
本节摘要：属性依赖（Attribute Dependency）是五模板中统计命中率最高的一个：把系统里两个原本互不相关的变量挂钩，让一个随另一个变化。变色镜片、缓释胶囊、按需调光的屏幕，背后都是它。本节给出变量配对的矩阵方法与三种挂钩形态。
口令：找两个陌生变量，介绍它们认识
其他模板动的是对象，这个模板动的是变量之间的关系。操作分两步：
属性依赖操作步骤： 1. 列变量：对封闭世界的每个对象，列出它身上可变的属性 例：奶瓶 -> 奶液流量、瓶身角度、温度 环境 -> 时段、光线、用户年龄 2. 查空白：两两配对，问"这两个变量现在有关吗？能不能挂钩？" 奶瓶案例：流量 x 角度 -> 原本无关，挂钩后：角度控流速
第二步产出一个二维矩阵（对象属性 × 环境变量），矩阵里绝大多数格子已被占用——那些是已存在的关系。空格就是创新矿。SIT 研究者对大量成功产品的统计显示，属性依赖类方案在高价值创新中占比最高，原因很简单：世界上对象有限，属性配对的空间却近乎无限。
三种挂钩形态
变量牵手不止一种牵法，常见的有三种：
函数型：一个变量随另一个连续变化。变色镜片（透光率随紫外线强度）、感应夜灯（亮度随环境光）、运动鞋缓震（回弹随冲击力）。适合对冲型矛盾里两侧都是连续量的场合。
阈值/条件型：越过某个条件才改变。缓释胶囊（释放速率随体内酸碱度）、温度保险丝（导通随温度阈值断开）。适合需要"平时不动、临界才动"的保护场景。
分段查表型：按离散档位对应。高峰限时柜（权限随时段档位）、阶梯电价（单价随用量档位）。适合管理与定价类问题，工程精度要求低。
图2.5-1 奶瓶案例的配对矩阵示意
案例展开：写字楼的空调战争
背景：一栋写字楼里，物业与租户常年打仗：总有人嫌冷有人嫌热，中央空调按整层统一供冷，能耗与投诉双高。标准方案是每工位装独立的温控末端——大改造，出圈。
操作：矛盾陈述："我们想按人的需求供冷，但冷量只能按区域统一分配。"对冲型，属性依赖直接对号。列变量：系统侧有送风温度、风量、送风时段；环境与人的侧有工位占用状态、楼层位置、室外温度、时段。查空白找到三对：送风量 × 工位占用状态（有人供、无人停）；设定温度 × 室外温度（过渡季放宽回差）；预冷时长 × 楼层朝向（西晒层提前启动）。
结果：只改控制逻辑与少量传感器（传感器本就在封闭世界的楼宇系统清单里——门禁与工位登记系统早就有占用数据，做了一次联合连招），能耗降两成，投诉减半。
解读：注意占用量这个变量不是新造的——门禁系统一直在采集它，只是从未与空调系统"牵手"。属性依赖常常不是制造新数据，而是接通两座数据孤岛。
变式：同样的骨架搬到在线教育——题目难度 × 学生正确率历史；搬到电商——首页内容 × 当地天气；搬到维修——备件库存 × 故障季节曲线。
⚠️ 常见坑：挂钩了不相关或伪相关的变量。变量之间要有物理或业务上的因果通路可解释，否则上线后就是玄学调参。另一个坑是挂钩过密：每个属性都随三个变量变，系统将无法调试——一次引入一到两个依赖为宜。
💡 关键直觉：看到一个"静态设计"（无论何时都一样的行为），条件反射地想"它能不能随某个上下文变"。静态即浪费，是属性依赖的座右铭。
本节要点回顾
- 两步操作：列变量、查配对矩阵空白；
- 三种形态：函数型、阈值型、分段查表型；
- 统计地位：高价值创新中命中率最高的模板；
- 常见本质：接通两座本就存在的数据孤岛，而非制造新数据；
- 纪律：变量间须有可解释因果，一次引入一到两个依赖。
延伸问答
属性依赖和自动化是一回事吗
不是。自动化是把人做的换成机器做，变量关系不变；属性依赖是改变变量之间有没有关系。自动调光灯的重点不在"自动"，在"亮度与照度挂钩"这个新关系——手动旋钮接光敏电阻同样成立。把两者混谈是选型讨论里最常见的概念滑动。
怎么判断两个变量适不适合挂钩
三问：有没有物理或业务上的因果通路（可解释）；关系是否稳定（会不会随季节或用户群体漂移）；挂钩后人是否还能理解与预测系统行为（可学习性）。三问都过，才是合格的依赖对。
属性依赖做出来的产品会不会让用户觉得失控
有这个风险，尤其阈值型依赖在触发时显得"系统自作主张"。设计对策是给依赖留一个人工覆盖入口，并在触发前后给出轻量解释——用户不需要知道规则细节，但需要知道是哪个变量变了。这条经验来自大量智能温控类产品的返修归因。
顺手练一题
打开你家任何一个有固定档位的设备——热水器温度、冰箱高度、椅子高度——问一句：这个档位能不能随某个上下文变？比如热水器目标温度随季节、椅子高度随使用者习惯。多数答案会是可以有代价，把代价写下来。这个练习训练的是对静态设计的敏感度，而代价清单会告诉你哪些依赖值得做、哪些只是炫技。
依赖关系的失效模式
属性依赖方案运行一段时间后的典型失效有三种：漂移（季节或人群变了，函数关系还停在标定值）、震荡（两个变量互相影响形成回路，系统开始振荡）、依赖空转（挂钩的触发条件几乎不再出现，功能名存实亡）。三种失效对应的维护动作分别是定期重标定、加阻尼或去耦、以及重新审查变量选择。把这三条写进方案的运维说明，属性依赖类产品的事故率会明显下降。
从依赖到反依赖
挂钩方向也可以反过来设计：让通常被视为结果的变量去驱动通常被视为原因的变量。让室内人数驱动新风量是常规依赖；让新风系统的预热时段反过来由历史人数曲线驱动，就是反依赖的运用。推演时把配对矩阵的两列互换再查一遍空白，能多出一批候选——这个动作的成本几乎为零，收益却常出乎意料。