可复用物与不可复用物分开

更新于 2026-09-21

可复用物与不可复用物分开

# 可复用物与不可复用物分开

你反复问的其实一直是同一个问题：「这东西下次还能不能用？」 而你踩的坑也一直是同一个：把会过期的和不会过期的混在一起放。 解法统一是先按「寿命 / 复用性」分层，再决定谁放哪、谁信谁。

场合	混在一起的两类东西	分开之后的规则
入库前先分层清洗	机械过滤（寒暄/工具回显） vs 判断（哪轮成知识）	清洗层可批量、可丢弃；提炼层昂贵、面向人
上下文按信任等级分层	长期身份与原则 vs 每轮的时间/页面/可用 skill	动态内容不进历史；压缩后要重新生成
计数闸门不等于上下文管理	会话状态（刷新即失） vs 需要跨刷新的状态	生命周期不同 → 落盘位置不同
仓库残留会误导对现状的判断	「曾经这样」（prototypes/旧文档） vs 「运行时用什么」（DB row）	判断现状只查运行时真源
通用脚本要靠工具适配器接入	中立逻辑（跨 agent 通用） vs 某端的格式要求	格式差异留在适配器，不进通用件
跨源取数据要靠自建代理	数据获取 vs 展示	拿不到数据时，别在展示层打补丁

分层的依据是「寿命」，不是「内容类型」。 会过期的（寒暄、当前页面、当前进度、原型文件、某端格式）和不会过期的（判断原则、通用逻辑、可复用知识）放在同一层，结果一定是过期的那部分把没过期的污染掉。
「放错层」几乎总是表现为「静默」而不是「报错」。 旧原型被当成现状、过期动态上下文被压进 summary、某个 agent 的格式写进通用脚本 —— 没有一个会报错，只会让人在错误的前提上继续工作。
可迁移的动作：拿到任何一个东西要归位前，先问两句 —— 「它多久会变一次？」「下次需要它的，还是同一批人/同一场景吗？」 两个答案决定它该进哪一层，以及该不该被信任（对照知识入库的筛选标准：只有 confirmed 的边界才能当依据）。
这条骨架同时解释了为什么「先分层」比「先处理」便宜：分层是一次性的、机械的；处理是重复的、昂贵的。先分层 = 把昂贵的那步喂干净 —— 与先定位归属层再动手是同一枚硬币的两面（一个分「归属层」，一个分「寿命层」）。

单看每一页，都是某个领域的一条具体规则（清洗顺序、上下文分层、仓库残留、脚本适配）。并排之后才看得出它们共享同一个结构：先按寿命分层，再谈处理与信任。这个结构独立于任何一个项目，可以带走。