[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-82101":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":9,"language":10,"languages":9,"totalLinesOfCode":9,"stars":11,"forks":12,"watchers":11,"openIssues":13,"contributorsCount":13,"subscribersCount":13,"size":13,"stars1d":13,"stars7d":13,"stars30d":13,"stars90d":13,"forks30d":13,"starsTrendScore":13,"compositeScore":14,"rankGlobal":9,"rankLanguage":9,"license":15,"archived":16,"fork":16,"defaultBranch":17,"hasWiki":18,"hasPages":16,"topics":19,"createdAt":9,"pushedAt":9,"updatedAt":20,"readmeContent":21,"aiSummary":22,"trendingCount":13,"starSnapshotCount":13,"syncStatus":23,"lastSyncTime":24,"discoverSource":25},82101,"repowise","szw321127\u002Frepowise","szw321127","为llm服务的代码片段知识库",null,"JavaScript",21,1,0,0.9,"MIT License",false,"main",true,[],"2026-06-12 02:04:23","# LLM Wiki for Code\n\n面向 Codex 与 Claude Code 的持久代码库 wiki。\n\nLLM Wiki for Code 是一套本地代码库 wiki 和知识图谱工具。它把长期项目里的代码实践、推荐方案、任务决策、会话记录和证据关系保存到项目自己的 `.project-knowledge\u002F` 目录中，让后续 AI 编码对话可以先查已有约定，再决定是否扫描项目代码。\n\n\u003Cp align=\"center\">\n  \u003Ca href=\"#验证\">\u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Ftests-node%20test-0f766e\" alt=\"Tests\">\u003C\u002Fa>\n  \u003Ca href=\"LICENSE\">\u003Cimg src=\"https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Flicense-MIT-blue\" alt=\"License\">\u003C\u002Fa>\n\u003C\u002Fp>\n\u003Cp align=\"center\">\n  中文文档 | [英文文档](README_EN.md)\n\u003C\u002Fp>\n\n仓库名和包名是 `llm-wiki-for-code`。助手插件保留短名 `pk`。\n\n## 30 秒看懂\n\n```bash\nnpm run pk:init -- \u003Cproject-root>\nnpm run pk:preflight -- \u003Cproject-root> \"实现 HTTP 调用\"\nnpm run pk:auto-crystallize -- \u003Cproject-root> \u003Cauto-crystallize-input.json>\nnpm run pk:serve -- \u003Cproject-root> 8124\n```\n\n执行后：\n\n- `pk-init` 创建 `.project-knowledge\u002F`，作为 Markdown 知识库。\n- `pk-preflight` 在 AI 编码任务开始前返回匹配实践、推荐池和 evidence 预览。\n- `pk-auto-crystallize` 在任务结束后记录 session，并推断已采纳或待孵化知识。\n- `pk-serve` 打开本地图谱，查看 practice、option、rule、context、constraint、session 和 source evidence。\n\n## 适合谁\n\n- 在长期代码仓库中使用 Codex、Claude Code 或类似 coding agent 的开发者。\n- 希望把 agent 决策沉淀为可审查项目知识，而不是留在聊天记录里的团队。\n- 偏好本地 Markdown、显式 evidence 和可逆治理，而不是黑盒记忆存储的维护者。\n\n## 为什么不只用 `AGENTS.md` 或 `CLAUDE.md`？\n\n`AGENTS.md` 和 `CLAUDE.md` 很适合保存当前指令。LLM Wiki for Code 则是它们旁边的结构化记忆层：\n\n| 需求 | 指令文件 | LLM Wiki for Code |\n| --- | --- | --- |\n| 告诉 agent 当前规则 | 支持 | 支持 |\n| 记录候选实践和替代方案 | 手动维护 | 内置 |\n| 把推荐方案关联到稳定源码 evidence | 手动维护 | 内置 |\n| 跨 session 记录采纳历史 | 不支持 | 内置 |\n| 控制推荐池大小并治理 | 不支持 | 内置 |\n| 用 Obsidian vault 或图谱浏览关系 | 不支持 | 内置 |\n\n指令文件适合保存当前操作规则。LLM Wiki for Code 适合保存会随时间演进的实践、方案、证据和决策。\n\n## 解决的问题\n\n长期项目里，AI 协作常见几个问题：\n\n- 每次新对话都像第一次看项目，重复读取同一批文件。\n- 同一类实现会逐渐分叉成多个不一致方案。\n- 任务结束后的关键决策没有沉淀，下次无法复用。\n- 知识库变大后，如果整库塞进上下文，会浪费 token。\n- 临时计划、worktree 文件和生成文档容易污染长期证据。\n\nLLM Wiki for Code 的做法是：\n\n- 任务开始前用 `pk-preflight` 查询已有实践和推荐方案。\n- 任务结束后用 `pk-auto-crystallize` 记录已采纳或待孵化知识。\n- 用采纳次数、分数和治理规则维护推荐池。\n- 每个实践最多保留 3 个推荐方案。\n- 只返回 Top-K 实践和 evidence 预览，避免把整个知识库放进上下文。\n\n## 核心模型\n\n`.project-knowledge\u002F` 是项目级知识库，也是 Markdown 事实源。图谱、索引、Obsidian 视图和浏览器图谱页面都从这些 Markdown 文件生成。\n\n主要节点类型：\n\n- `project_profile`：项目画像，记录技术栈、默认规则和偏好方案。\n- `practice`：可复用实践，例如“HTTP 调用应统一走共享 client”。\n- `option`：实践下的候选实现方案。\n- `rule`：约束性规则或强偏好规则。\n- `context` \u002F `constraint`：适用场景和限制条件。\n- `session`：一次任务或对话的记录。\n\n知识生命周期：\n\n- 新知识通常先进入 `incubating`。\n- 多次被采纳后成为转正候选。\n- 每个实践的推荐池最多保留 3 个方案。\n- 被淘汰、打回或判定重复的方案不会被物理删除，而是退回孵化区并标记状态。\n\n## 证据规则\n\n`source_evidence` 应指向长期存在的项目相对路径，例如：\n\n```text\nsrc\u002Fapi\u002Fclient.ts\nsrc\u002Fruntime\u002Fscheduler.ts\n```\n\n也可以逐步升级为结构化 evidence record；旧的字符串路径仍然兼容：\n\n```yaml\nsource_evidence:\n  - src\u002Fapi\u002Fclient.ts\n  - path: src\u002Fruntime\u002Fscheduler.ts\n    symbol: createScheduler\n    reason: Demonstrates project-wide scheduler boundary.\n    observed_pattern: Scheduler starts after login\u002Fuser readiness.\n    stability: stable\n    last_verified_at: 2026-05-15\n```\n\n图谱会继续把 `source_evidence` 归一化为路径数组，同时在 `evidence_records` 中保留 `symbol`、`reason`、`observed_pattern`、`stability` 和 `last_verified_at`。稳定节点里的结构化证据应填写 `reason`，否则 `pk-lint` 会报告 `wiki-evidence-record-missing-reason`。\n\n默认策略会过滤常见的临时文件、工具状态、生成物和过程文档；它不是写死在 README 里的完整清单。每个知识库都可以通过 `.project-knowledge\u002Fevidence-policy.json` 调整：\n\n```json\n{\n  \"useDefaultIgnores\": true,\n  \"ignoredPrefixes\": [\"generated\u002F\"],\n  \"ignoredBasenames\": [\"local-note.md\"],\n  \"allowedPrefixes\": [\"docs\u002Fadr\u002F\"],\n  \"allowAbsolutePaths\": false\n}\n```\n\n字段含义：\n\n- `useDefaultIgnores`：是否启用内置默认过滤规则。\n- `ignoredPrefixes`：追加按路径前缀过滤的目录或文件。\n- `ignoredBasenames`：追加按文件名过滤的临时文件。\n- `allowedPrefixes`：从默认过滤规则中放行稳定子路径，例如 `docs\u002Fadr\u002F`。\n- `allowAbsolutePaths`：默认禁止绝对路径，避免把本机路径写进项目知识。\n\n这些规则会同时影响 `pk-preflight` 的 evidence 预览、`pk-auto-crystallize` 的 touched files、`pk-crystallize` 写入的 `source_evidence`，以及 `pk-lint` 的 volatile evidence 检查。\n\n`pk-lint` 也会检查非临时的 `source_evidence` 是否仍存在于项目中。断链路径会报告为 `node-missing-evidence-path`，并在能找到同名文件时给出 `repair_candidates`。`pk-preflight` 不会把不存在的 evidence 路径返回给 AI；`verifyKnowledgeNode` 默认也不会给证据断链的节点刷新 `last_verified_at`。\n\n项目不把完整代码片段作为主证据保存。推荐的证据形态是：\n\n- 稳定源码相对路径\n- 实践摘要\n- 方案摘要\n- 采纳次数\n- 必要时扩展 symbol、reason、observed pattern、hash 或短摘要等元数据\n\n## 环境要求\n\n- 支持原生 ESM 的 Node.js。\n- 用于运行脚本的 npm。\n- 只有在需要把 `pk` 技能安装进 Codex 或 Claude Code 时，才需要对应 AI 编程助手。\n\n当前仓库主要依赖 Node 内置 test runner 和本地脚本。\n\n## 安装\n\n### 1. 克隆仓库\n\n```bash\ngit clone \u003Crepository-url>\ncd \u003Crepository-directory>\n```\n\n运行测试确认本地环境可用：\n\n```bash\nnpm test\n```\n\n### 2. 作为普通 CLI 使用\n\n不安装任何助手插件，也可以直接通过 npm 脚本使用：\n\n```bash\nnpm run pk:init -- \u003Cproject-root>\nnpm run pk:preflight -- \u003Cproject-root> \"实现 HTTP 调用\"\nnpm run pk:auto-crystallize -- \u003Cproject-root> \u003Cauto-crystallize-input.json>\n```\n\n这种方式适合手动执行、CI 或其它自动化流程。\n\n### 3. 安装到 Codex\n\n如果希望在 Codex 对话中直接使用 `pk:*` 技能：\n\n```bash\nnpm run codex:install\n```\n\n安装脚本会：\n\n- 从当前仓库的 `plugins\u002Fpk\u002F` 创建本地插件链接。\n- 在用户目录的 `.agents\u002Fplugins\u002Fmarketplace.json` 写入 `local-project-knowledge` marketplace 条目。\n- 将插件策略标记为 `INSTALLED_BY_DEFAULT`。\n\n安装后需要完全重启 Codex。重启后技能列表中应该能看到：\n\n```text\npk-init\npk-preflight\npk-status\npk-graph\npk-crystallize\npk-auto-crystallize\npk-lint\npk-govern\npk-serve\n```\n\n升级当前仓库后，重新执行安装命令并完全重启 Codex。本地安装可能会让 `~\u002Fplugins\u002Fpk` 指向当前仓库，但运行中的客户端仍可能使用启动时读取的 plugin 缓存：\n\n```bash\nnpm run codex:install\n```\n\n卸载：\n\n```bash\nnpm run codex:uninstall\n```\n\n### 4. 安装到 Claude Code\n\n使用 Claude Code 的标准插件命令：\n\n```bash\n\u002Fplugin marketplace add \u003Crepository-root>\n\u002Fplugin install pk@local-project-knowledge\n```\n\n例如：\n\n```bash\n\u002Fplugin marketplace add \u002Fpath\u002Fto\u002Funiversal-practice-knowledge-graph\n\u002Fplugin install pk@local-project-knowledge\n```\n\n这会注册 `local-project-knowledge` marketplace，并从 `plugins\u002Fpk\u002F` 安装 `pk` 插件。\n\n安装后需要完全重启 Claude Code。重启后技能列表中应该能看到：\n\n```text\npk-init\npk-preflight\npk-status\npk-graph\npk-crystallize\npk-auto-crystallize\npk-lint\npk-govern\npk-serve\n```\n\n修改或拉取当前仓库后，更新这个插件并完全重启 Claude Code。Claude Code 会把插件复制到 `.claude\u002Fplugins\u002Fcache\u002F...`，所以已经安装的插件不会自动反映仓库里的新改动：\n\n```bash\n\u002Fplugin update pk@local-project-knowledge\n```\n\n卸载：\n\n```bash\n\u002Fplugin uninstall pk@local-project-knowledge\n```\n\n### 5. 初始化目标项目\n\n安装或克隆工具后，还需要让目标项目进入知识库流程：\n\n```bash\nnpm run pk:init -- \u003Cproject-root>\n```\n\n或者在 Codex 中使用：\n\n```text\npk-init\n```\n\n初始化后，目标项目根目录会出现 `.project-knowledge\u002F`。没有这个目录的项目会返回 `mode: no-knowledge`，并跳过项目知识流程。\n\n## 快速开始\n\n```bash\nnpm test\nnpm run pk:init -- \u003Cproject-root>\nnpm run pk:status -- \u003Cproject-root>\nnpm run pk:preflight -- \u003Cproject-root> \"实现 HTTP 调用\"\nnpm run pk:auto-crystallize -- \u003Cproject-root> \u003Cauto-crystallize-input.json>\nnpm run pk:lint -- \u003Cproject-root>\nnpm run pk:govern -- \u003Cproject-root>\nnpm run pk:graph -- \u003Cproject-root>\nnpm run pk:serve -- \u003Cproject-root> 8124\n```\n\n如果不传 `\u003Cproject-root>`，脚本会使用当前工作目录。\n\n## 技能入口\n\n仓库同时内置 Codex 插件和 Claude Code 插件。\n\nCodex 技能名：\n\n```text\npk-init\npk-preflight\npk-status\npk-graph\npk-crystallize\npk-auto-crystallize\npk-lint\npk-govern\npk-serve\n```\n\nClaude Code 技能名：\n\n```text\npk-init\npk-preflight\npk-status\npk-graph\npk-crystallize\npk-auto-crystallize\npk-lint\npk-govern\npk-serve\n```\n\n## 常用流程\n\n### 初始化知识库\n\n```bash\nnpm run pk:init -- \u003Cproject-root>\n```\n\n会在目标项目中创建 `.project-knowledge\u002F`，包括：\n\n- `project-profile.md`\n- `practices\u002F`\n- `options\u002F`\n- `rules\u002F`\n- `contexts\u002F`\n- `constraints\u002F`\n- `incubating\u002F`\n- `sessions\u002F`\n- `state\u002F`\n- `graph\u002F`\n- `_views\u002F`\n- `.obsidian\u002F`\n- `open-graph.cmd`\n\n如果项目没有初始化，`pk:preflight` 和 `pk:auto-crystallize` 会返回 `mode: no-knowledge`，不会扫描代码，也不会创建知识库。\n\n### 查看当前状态\n\n```bash\nnpm run pk:status -- \u003Cproject-root>\n```\n\n状态报告会汇总当前 `.project-knowledge\u002F` 的节点数量和健康信号。\n\n### 任务开始前预检\n\n```bash\nnpm run pk:preflight -- \u003Cproject-root> \"实现 HTTP 调用\"\n```\n\n预检会优先读取 `.project-knowledge\u002F`：\n\n- 命中已有实践时返回 `mode: knowledge-hit`。\n- 项目已初始化但知识不足时返回 `mode: needs-project-scan`。\n- 项目未初始化时返回 `mode: no-knowledge`。\n\n为了控制上下文大小，默认只返回：\n\n- Top 5 practices\n- 每个节点最多 5 条 evidence 预览\n- 每类扫描 hint 最多 5 条\n\n除了关键词、标题和摘要，预检还会从任务文本中提取本地 intent：\n\n- `taskKinds`：如 `frontend-page`、`crud-list`、`api-client`、`config`、`test`、`governance`。\n- `technologies`：如 `vue`、`react`、`node`、`typescript`。\n- `pathHints`：如 `src\u002Fviews\u002Fusers\u002FUserList.vue` 会命中 `src\u002Fviews` 前缀。\n- `operationHints`：如 `create`、`modify`、`review`、`debug`。\n\n知识节点可以用 `applies_when` 和 `does_not_apply_when` 调整适用范围，命中结果会返回 `matchReasons`，例如 `task-kind:frontend-page` 或 `path-prefix:src\u002Fviews`。\n\n默认 `pk-preflight` 是只读的。需要把命中写入 `state\u002Fusage-index.json` 时，显式运行 `npm run pk:preflight -- \u003Cproject-root> --record-hits \"实现 HTTP 调用\"`；这会增加 `preflight_hits` 并更新 `last_hit_at`。\n\n### 模拟评测 PK 是否帮到 AI\n\n```bash\nnpm run pk:benchmark -- \u003Cproject-root> \u003Cbenchmark-samples.json> --k 3\n```\n\nbenchmark 不调用 AI。它用一组带标注的任务样本反复运行 `pk-preflight`，计算：\n\n- `recallAtK`：期望命中的知识是否出现在前 K 个结果中。\n- `precisionAtK`：前 K 个结果中有多少是期望或允许的相关知识。\n- `falsePositiveRate`：标注为 `expectedNoMatches: true` 的负例任务中，有多少被误召回知识。\n- `noiseRate`：前 K 个结果中无关知识的比例。\n- `pass`：是否达到样本文件里的阈值。\n\n样本格式可参考 `tests\u002Ffixtures\u002Fpk-benchmark\u002Fpreflight-samples.json`。这能先验证检索层是否可信；真正的 AI 帮助效果还应再用 A\u002FB 任务执行评估。\n\n### 任务结束后自动沉淀\n\n```bash\nnpm run pk:auto-crystallize -- \u003Cproject-root> \u003Cauto-crystallize-input.json>\n```\n\n输入示例：\n\n```json\n{\n  \"sessionId\": \"session-YYYY-MM-DD-topic\",\n  \"title\": \"本轮任务标题\",\n  \"topic\": \"本轮任务主题\",\n  \"taskText\": \"本轮任务描述\",\n  \"decisionSummary\": \"一句话总结本轮关键决策。\",\n  \"touchedFiles\": [\"src\u002Fexample.ts\"]\n}\n```\n\n行为：\n\n- 命中已有实践时，自动记录推荐方案被采纳。\n- 未命中且存在有效源码变更时，可能生成孵化中的 practice 和 option。\n- 只有临时文件、文档或 worktree 变更时，只记录 session。\n- 显式传入 `adoptedNodeIds`、`rejectedNodeIds`、`incubatingNodes` 或 `stableUpdates` 时，优先使用显式输入。\n- 可传入 `taskId` 或 `taskDir` 读取通用任务\u002F流程上下文；默认支持 `.tasks\u002F\u003CtaskId>` 和 `tasks\u002F\u003CtaskId>`，并兼容 `.trellis\u002Ftasks\u002F\u003CtaskId>` 这类外部流程布局。过程文件只作为 `processSources` 和任务文本，不会默认写入长期 `source_evidence`；PK 不依赖 Trellis。\n- 默认不会读取 dirty git status 作为证据；只有 `allowGitStatusFallback: true` 时才会以低置信度使用 git status。\n\n### 手动结晶\n\n```bash\nnpm run pk:crystallize -- \u003Cproject-root> \u003Ccrystallize-input.json>\n```\n\n当你已经明确知道要采纳哪个节点、拒绝哪个预检推荐、创建哪个候选节点或更新哪条稳定知识时，使用手动结晶。`rejectedNodeIds` 会增加 `rejected_after_hit_count`，用于后续发现“经常命中但被拒绝”的知识。\n\n模板位于：\n\n```text\ntemplates\u002Fcrystallize-input-template.json\ntemplates\u002Fauto-crystallize-input-template.json\n```\n\n### 检查知识库健康\n\n```bash\nnpm run pk:lint -- \u003Cproject-root>\n```\n\nlint 会报告：\n\n- `node-missing-evidence`：节点缺少证据。\n- `node-volatile-evidence`：节点引用了临时或不稳定 evidence。\n- `node-missing-evidence-path`：节点引用的 evidence 路径已经不存在，报告里会尽量给出同名文件候选。\n- `option-missing-practice`：方案没有有效实践归属。\n- `practice-empty-recommendation-pool`：实践没有可推荐方案。\n- `incubating-promotion-candidate`：孵化节点达到转正阈值。\n- `recommendation-pool-eviction-candidate`：推荐池超过 3 个方案。\n- `possible-duplicate-node`：疑似重复知识节点。\n- `wiki-thin-page` \u002F `wiki-oversized-page`：知识页过薄或过长。\n- `wiki-missing-summary` \u002F `wiki-missing-required-section`：稳定知识缺少显式摘要或必要章节。\n- `wiki-bad-title` \u002F `wiki-bad-id` \u002F `wiki-wrong-directory`：节点标题、id 或目录位置不符合 wiki 约定。\n- `wiki-broken-node-link` \u002F `wiki-orphan-node`：wiki 链接断裂，或节点缺少图谱连接、session ref 和 evidence。\n- `wiki-no-preflight-surface`：节点缺少 keywords，后续 `pk-preflight` 难以命中。\n- `wiki-missing-session-ref` \u002F `wiki-missing-decision-reason`：稳定 option 缺少来源会话或采用理由。\n- `wiki-stale-node` \u002F `wiki-stale-evidence`：节点或证据超过 `stale_after_days` 未验证。\n- `wiki-high-rank-stale-recommendation`：仍在推荐池中的高排名 option 已过期。\n- `wiki-missing-owner-for-strong-rule` \u002F `wiki-missing-verification-date` \u002F `wiki-invalid-verification-date`：强规则缺少 owner 或验证日期不可用。\n- `wiki-never-hit` \u002F `wiki-hit-but-never-adopted` \u002F `wiki-frequently-rejected-after-hit`：知识从未被预检命中、多次命中但未采纳，或命中后经常被拒绝。\n- `wiki-active-conflicting-rules` \u002F `wiki-superseded-node-still-recommended` \u002F `wiki-duplicate-practice-scope`：active 规则互相冲突、已 superseded 节点仍残留在推荐面，或多个 practice 声明同一 scope。\n\n### 执行可逆治理\n\n```bash\nnpm run pk:govern -- \u003Cproject-root>\n```\n\n默认只预览治理动作；需要写入时运行 `npm run pk:govern -- \u003Cproject-root> --apply`。治理只做可逆操作：\n\n- 提升达到条件的孵化节点。\n- 将推荐池 Top 3 之外的方案退回孵化区。\n- 将强重复节点标记为 rejected 并移入孵化区。\n- 不会物理删除知识文件。\n\n### 构建或查看图谱\n\n```bash\nnpm run pk:graph -- \u003Cproject-root>\nnpm run pk:serve -- \u003Cproject-root> 8124\n```\n\n在 Windows 上，初始化后的项目也可以运行：\n\n```text\n.project-knowledge\u002Fopen-graph.cmd\n```\n\n图谱页支持：\n\n- 查看 practice、option、rule、context、constraint 之间的关系。\n- 查看推荐池和 evidence。\n- 从图谱界面打回不合适的孵化节点。\n\n## Obsidian 兼容\n\n`.project-knowledge\u002F` 可以直接作为 Obsidian vault 打开。系统会维护：\n\n- `index.md`：知识库入口。\n- `log.md`：操作日志。\n- `_views\u002Fpractices.md`：按实践聚合推荐池。\n- `_views\u002Fincubating.md`：孵化知识入口。\n- `_views\u002Fsessions.md`：会话记录入口。\n- `.obsidian\u002Fapp.json`\n- `.obsidian\u002Fgraph.json`\n\n知识节点会生成 `Links` 区，使用 `[[node-id]]` 连接相关 practice、option、rule、context 和 constraint。\n\n## 仓库结构\n\n```text\n.\n|-- .agents\u002F                       # Codex 本地 marketplace 元数据\n|-- .github\u002F                       # GitHub issue 和 PR 模板\n|-- .claude-plugin\u002F                # Claude Code marketplace 元数据\n|-- assets\u002F                        # 项目图谱前端资产\n|-- docs\u002F                          # 设计和实现计划\n|-- knowledge\u002F                     # 通用图谱原型和回归验证资产\n|-- plugins\u002Fpk\u002F                    # Codex 和 Claude Code 插件包\n|   |-- .codex-plugin\u002F             # Codex plugin 配置\n|   |-- .claude-plugin\u002F            # Claude Code plugin 配置\n|   |-- assets\u002F                    # 插件图谱资产\n|   |-- scripts\u002F                   # 插件命令包装和共享脚本\n|   `-- skills\u002F                    # 技能定义\n|-- scripts\u002F                       # npm 脚本实现\n|-- seed\u002F                          # 初始化基线知识\n|-- templates\u002F                     # Markdown 和 JSON 模板\n|-- tests\u002F                         # Node 测试套件\n|-- CONTRIBUTING.md                # 贡献指南\n|-- README.md                      # 中文文档\n`-- README_EN.md                   # 英文文档\n```\n\n## 验证\n\n运行完整测试：\n\n```bash\nnpm test\n```\n\n当前测试覆盖初始化、预检上下文预算、结晶、自动结晶、证据过滤、推荐池治理、Obsidian 输出、图谱生成、图谱运行时行为、插件命令外壳，以及 Codex 本地插件安装。\n\n发布前建议执行：\n\n```bash\nnpm test\n```\n\n\n","LLM Wiki for Code 是一个面向 Codex 和 Claude Code 等 AI 编码助手的本地代码库知识管理工具。它通过将长期项目中的代码实践、推荐方案、任务决策和会话记录保存到 `.project-knowledge\u002F` 目录中，帮助开发者在后续编码对话时能够快速参考已有约定，减少重复工作。该项目使用 JavaScript 开发，支持初始化知识库、预处理查询、自动归档会话以及本地图谱服务等功能。适用于需要在长期维护的代码仓库中利用 AI 辅助开发，并希望以结构化方式保存和复用关键决策与最佳实践的团队。",2,"2026-06-11 04:07:44","CREATED_QUERY"]