| title | ResiCache Wiki 维护规范 | ||||
|---|---|---|---|---|---|
| type | meta | ||||
| tags |
|
||||
| related |
|
||||
| status | stable | ||||
| created | 2026-06-21 | ||||
| updated | 2026-07-09 |
ResiCache 项目的 LLM 维护知识库。本文件是 schema——告诉后续 LLM 会话:wiki 是什么、如何组织、如何维护。
ResiCache 架构散落在 ~90 个 Java 文件里。本 wiki 把这些知识编译一次、持续保鲜:架构 / 机制 / 数据流整理成结构化、可交叉引用的页面。
知识不是每次查询时 RAG 重算,而是增量积累成持久产物。LLM 写并维护全部 wiki;人类提问、审核、定方向。
铁律:源码变了 → 更新对应 wiki 页 → 更新 [[index]];源码没变 → wiki 视为可信,直接引用,不重新推导。
wiki 目录结构与源码 Project Structure 见
CLAUDE.md(单一真理源)。
---
title: 页面标题
type: architecture | mechanisms | modules | concepts | how-to | meta
tags: # 首个为 type 锚,其余自由
- architecture
related: [chain-of-responsibility, cache-avalanche] # wikilink slug 列表
source-files: # 引用的源码(相对仓库根)
- src/main/java/.../HandlerOrder.java
status: stable
created: 2026-06-21
updated: 2026-06-21
---- 一句话定位 —— 讲什么、对应哪个源码包。
- 职责 / 要点 —— 解决什么问题、核心机制。
- 核心源码引用 —— 符号引用(
Class#method)优先;file:line易漂移慎用。配 1–2 段精选代码,不贴整文件。 - 关键设计 / 数据流 —— 为什么这么做、数据怎么流动。
- 配置项 / 注解属性 —— 若涉及
resi-cache.*或注解,列出。 - 交叉引用 —— 用
[[slug]]链向相关页。
- Obsidian wikilink:
[[page-name]](无.md,slug = 文件名)。 - liberal 链接:提到另一页覆盖的概念即加链接。
- 优先符号引用
Class#method—— 行号交给 codebase-memory 即时解析,规避 stalefile:line。 - 代码块只贴关键片段(10–30 行),不复制整类。
- 文件名 kebab-case,与 wikilink slug 完全一致。
- 目录名复数小写。
源码改动 → 读源码理解变化 → 更新受影响 wiki 页(常 2–5 页)→ 必要时建新页 → 更新 [[index]]。
被问架构 / 机制 / 流程:先读 [[index]] 定位 → 下钻细读(不直接 grep 源码)→ 综合 wiki 作答带 [[slug]] → 答案有沉淀价值就写回 wiki。
定期查:断链、孤儿页、过期声明(wiki 说 A 源码已改 B)、缺失页、缺失交叉引用。
- [[index]] —— 内容导向。全量页面按类别分组,每条一句话定位。
- 变更历史由
git log承载(commit body 是 SOURCE OF TRUTH),不再维护独立 log 文档。
- 入口:从 [[overview]] 或 [[index]] 开始。
- 源码地图:
CLAUDE.md的「Project Structure」与「Where to Look」表。 - 结构化查询:优先用 codebase-memory 工具(
search_graph/trace_path/get_code_snippet)查符号关系,再用本 wiki 理解「为什么」。 - 改 wiki 前:确认源码未变(变了先 ingest);所有源码引用必须真实存在——符号优先,行号次之。
本 wiki 衍生自 ResiCache 源码(git 仓库一部分)。源码以项目根 LICENSE 为准。