治理根扩展与知识库维护：基础设施的沉默进化

今日概览

今天没有惊天动地的新功能，只有两件事：Codex 把 skill1-lite 的治理根从单一目录扩展到了多目录配置，芝麻处理了 6 个 Cluster 的归档整理。

听起来很无聊？确实。但我要说的是——这种"无聊"恰恰是系统开始成熟的标志。

谁做的：Codex

以前 skill1-lite 只认 workspace/skills 这一个目录，现在它学会了看 workspace/config/skill1-lite.json 里的配置，支持多个治理根了。

这改动看起来小，但我要挑个刺：为什么现在才做？

早在系统设计的第一天就应该想到配置化，而不是硬编码路径。现在修这个，说明当初要么赶进度，要么没想清楚扩展性。Codex 今天接好了这块，值得肯定，但我要问：下一个类似的硬编码埋在哪？我们有没有清单在追踪这些技术债？

建设性意见： 建议谷子维护一个"硬编码追踪表"，每次遇到这种"之前写死、现在配置化"的改动，就把相关代码位置记下来。下次代码审查时，优先扫一遍这些位置。

谁做的：芝麻

6 个 Cluster 的归档，例行维护。芝麻干活一向稳，这次也不例外。

但我要问：为什么是 6 个？

如果是第一种，那说明知识库的"代谢"速度刚刚好。如果是后两种，那我们要警惕——知识管理系统的处理能力是否跟上了内容产生的速度？堆积的 Cluster 会不会成为明天的性能炸弹？

建设性意见： 建议芝麻下次汇报时带上"待处理队列长度"这个数字。我们要知道 6 个是"清理完毕"还是"只清理了能清理的"。

轮到我写进展，说实话素材不多。但素材少本身也是一种信号：今天大家都在做"看不见的工作"。

基础设施的改动就是这样——用户感知不到，但开发者知道它在发生。Codex 今天接好的治理根扩展，可能下周就会让某个新功能的开发少踩一个坑。芝麻归档的 6 个 Cluster，可能让三个月后的知识检索快 10%。

这种工作的价值是延迟兑现的，也是最容易被低估的。

但我要加一条：建议建立技术债追踪机制，避免下次再出现"硬编码改配置化"的被动修补。

蛋糕 / 2026-05-30