旧知识库已经提出“模型升级后应重审临时规则”。这周两项工程复盘把问题推进了一步：不能只问某条规则还省不省token，还要问它是否阻断了模型发现新解法的机会。Skyvern 的预处理把网页变成元素列表，本意是帮助模型，却使“没有被抽取出来”变成“无法采取行动”；Content Studio 的固定组件降低了早期设计的不确定性，也限制了后来的表达空间。共同之处不是都删了代码，而是旧系统提前替模型缩小了可见信息或可选行动。
这里可以区分两种约束。第一种是能力补偿：因为旧模型看不清网页，工程师替它挑好元素；因为旧模型设计不稳定，团队替它预定组合。第二种来自任务本身：表单最终必须正确、素材授权必须可用、用户必须有机会在昂贵渲染前改变方向。模型变强可能让第一类过时，却不会自动取消第二类。LangChain 一边删设计规则，一边用代码锁住故事板到成片的阶段，恰好让这一区别可见。
机制还涉及成本怎样随过程改变。Skyvern 并没有用更少思考换速度：轮次和token增加，但重复图片减少、缓存前缀更稳定。回访 Asana 的早期实验也能看到另一条路径：保留较长历史并批量裁剪，使缓存有时间被重复读取。这两者都反驳了只看请求长度的优化直觉，却不能互相证明各自的倍数。Asana 每条件仅三至四次运行，而且跨模型的76倍与同模型的29倍应分开；Skyvern 则是生产架构整体改变。先测重复计算发生在哪里，比先决定“缩短”或“删掉”更有依据。
这不意味着上下文越多越好。按需获取要求模型能意识到缺什么，并有可用工具补齐；已有抽取器在固定网页上可能又快又稳，换成自由探索会增加无谓步骤。缓存也只节省重复前缀的处理，不保证上下文中的信息正确。因而一条规则是否退役，应该比较它保护的结果与它造成的机会损失：旧任务是否仍能完成，过去做不到的任务是否开始可行，失败是否更容易定位，人员返工有没有增加。
读者可迁移的方法是给重要补偿措施留下一份简短的“最初为什么需要它”：保存一个实际失败例、所保护的结果和当前适用模型。下一次升级时，选择代表任务比较保留与撤去，允许先让一小部分路径退出，而不必整套推倒。这个办法由本期材料推导，我们没有替读者做过对照实验。若改善只在演示任务上出现，或删去规则后靠人工补救才能维持交付，就应恢复或改造它。
因此，本周对旧判断的修订不是加一句“更少即更好”，而是把退出条件从成本扩大到能力空间和反馈位置：哪些预先决定应交还模型，哪些任务取舍必须继续让人看见。更强模型的价值可能体现为找到原流程没有预留的路径；要使这种价值进入工作，团队需要允许路径变化，同时仍能说明结果为什么值得信任。