「活」的能力取决于增量机制，而不是生成质量

更新于 2026-09-22

# 「活」的能力取决于增量机制，而不是生成质量

派生知识（wiki、索引、向量、摘要、洞察、推荐）能不能「活」，不取决于它第一次生成得多好，而取决于它怎么跟着源变化。所以选型/设计这类能力时，先问的不是「生成质量如何」，而是三件事：谁触发更新？存量怎么补？旧结果怎么作废？

场合	只比「生成质量」会得到的结论	换成「增量机制」后的判据	出处
代码库知识工具的选型	几款工具都能生成漂亮的架构图 / 文档	谁是自动 reindex、谁要手动重生成；`.trellis/spec/` + `AGENTS.md` 本身就是已有的活机制，wiki 只是它的人读界面	@08-01 11:42
物化结果要按版本失效并增量刷新	「洞察是存一次还是实时算」	存成带版本的物化结果：标版本、按触发条件作废、后台增量刷新；且作废要精确到受影响的那几条，不能每加一篇就重算全部	@07-20 15:59 / 16:10
派生数据只在写入时入队旧数据要单独回填	「检索不到就是没有」	入队若只挂在新建/更新事件上，存量永远不被处理、失败任务永不复活；必须显式回答回填与重试入口	@07-28 17:20
首次导入与增量更新要用不同规则	「抓 N 条」是一条规则	首次导入与定时增量是两种任务，共用一条固定条数规则会让首次的截断设置被后续增量立刻抵消	@07-15 15:30 / 15:43

「生成一次」是廉价且可比的，「跟着变」才是分化点。 四处的共同形状是：候选方案在「生成」这一维上几乎无差别（都能生成、都挺好看），差异全部出现在增量这一维上 —— 而这一维默认不可见，只有把「改一次源」这个动作想一遍才会暴露。
增量机制由三个必答问题定义，缺一个就会出现「新数据正常、老数据永久缺失」的静默缺口：
- 触发：谁在什么事件后重算（写入事件？定时？全量重建？）
- 存量：上线这条逻辑之前已有的对象，谁把它们跑一遍（backfill / 迁移）
- 失效：源变了之后，旧结果靠什么被判定为过期、谁来重算，范围多大
可迁移的动作：评估任何「会随内容变化」的能力（知识库、索引、观测、推荐、缓存）时，把「它生成得多好」划掉，强制回答上面三问 + 一句 「改一次源，从触发到新结果可用要走几步、花多久？」 答不上来 → 这个能力只是快照，不是「活」的。
推论：能「跟着变」的既有资产，优先级高于新造一套。 代码库知识那一处的落法很典型 —— 项目里已经在被 agent 强加载的 spec + 规则文件，本身就是活的；新工具只有作为它的人读界面（而不是替代品）才值得引入。

存量不会自动跟上新逻辑 —— 那条是故障形状（改对了但只有新对象受益，属于 bug 侧）；本条是选型/设计判据（还没动手时，用增量机制筛方案）。同源但动作不同：一个用于复盘「为什么修了没用」，一个用于事前「该选哪个 / 该先设计哪一步」。
更新时序要由本地最新状态决定 —— 那条解决「谁最新」（乱序写入的仲裁）；本条解决「谁负责让结果追上源」。
可复用物与不可复用物分开 —— 派生结果的「版本 / 失效依据」正是按寿命分层的具体落法。
按实际规模选型而不是按方案先进性 —— 同族选型判据：那条按「规模与边界」选，本条按「增量机制」选。

单看每一页，都是某个具体场合的判断（选 wiki 工具、设计洞察的刷新、排查检索不到、定抓取条数）。并排之后才看得出它们共享同一条换维度的动作：从「生成得怎么样」换到「怎么跟着变」。