Understand-Anything Phase 2 实现计划为知识图谱构建“智能层”——Schema 校验、模糊搜索、过期检测与 /understand-chat【免费下载链接】Understand-AnythingGraphs that teach graphs that impress. Turn any code into an interactive knowledge graph you can explore, search, and ask questions about. Works with Claude Code, Codex, Cursor, Copilot, Gemini CLI, and more.项目地址: https://gitcode.com/GitHub_Trending/un/Understand-Anything本文基于 Understand-Anything 仓库中的 Phase 2Intelligence实施计划展开完整解析该计划的目标、架构与技术选型并逐一深入 10 个任务的上下文、代码设计与验证手段。读完后你将理解该项目如何从“能画出图”进化为“能回答问题的图”加载即校验的 Zod Schema、基于 Fuse.js 的模糊搜索引擎、基于 Git diff 的图谱过期检测与增量合并、启发式 LLM 双通道的架构分层推断以及驱动终端问答的/understand-chatSkill 与上下文构建器。所有关键结论均可在仓库源码与测试中复核。1. 计划总览目标、架构与技术栈Phase 2 的官方目标Goal是为系统添加Intelligence层包含五大能力增强搜索enhanced search图谱过期检测staleness detection架构分层自动推断layer auto-detection/understand-chatSkill 命令具备上下文感知问答能力的 Dashboard 聊天面板。架构上计划声明在现有 monorepopackages/core、packages/dashboard基础上新增packages/skill包Core 获得搜索引擎、过期检测、分层检测Dashboard 获得自动布局、增强搜索体验与聊天面板Skill 包提供/understand-chatClaude Code 命令。技术栈在既有基础上增加三个依赖fuse.js模糊搜索、zodSchema 校验、dagrejs/dagre图布局。值得注意的是计划开篇要求实现方使用superpowers:executing-plans子技能逐任务执行即每个任务都遵循写失败测试 → 验证失败 → 实现 → 验证通过 → 提交的 TDD 节奏。下文按任务顺序展开并结合仓库当前源码说明每个任务落地的实际形态注意源码位于 understand-anything-plugin/ 插件目录下的对应 workspace 包中。2. Task 1Zod Schema 校验——加载即验证的知识图谱2.1 问题背景计划指出改造前loadGraph只做JSON.parse()、不做任何校验损坏或不兼容的图谱文件会静默地产出坏数据。该任务被标记为基础性任务——Phase 2 所有功能都依赖正确的图谱数据。2.2 测试先行五类校验场景计划要求先写失败测试schema.test.ts 即由此演化而来覆盖合法图谱通过校验versionprojectnodesedgeslayerstour完整结构缺少必填字段被拒绝且result.errors非空节点类型非法如invalid_type被拒绝边类型非法如fake_edge被拒绝weight超出[0, 1]范围时校验失败。2.3 Schema 设计计划中的KnowledgeGraphSchema由六个子 Schema 组成全部基于 zodEdgeTypeSchemaz.enum([...])计划版本枚举了 18 种边类型imports、exports、contains、inherits、implements、calls、subscribes、publishes、middleware、reads_from、writes_to、transforms、validates、depends_on、tested_by、configures、related、similar_toGraphNodeSchemaid、typefile/function/class/module/concept 五种、name、summary、tags必填filePath、lineRange二元组、complexitysimple/moderate/complex、languageNotes可选GraphEdgeSchemasource/target、类型枚举、directionforward/backward/bidirectional、weight限定min(0).max(1)LayerSchema、TourStepSchema、ProjectMetaSchemaname、languages、frameworks、description、analyzedAt、gitCommitHash。核心 API 为validateGraph(data: unknown): ValidationResult内部使用KnowledgeGraphSchema.safeParse(data)失败时把 zod issues 映射为path: message字符串数组。2.4 接入持久化层计划要求修改loadGraph增加可选参数validate默认trueexport function loadGraph( baseDir: string, options?: { validate?: boolean } ): KnowledgeGraph | null { const graphPath path.join(baseDir, .understand-anything, knowledge-graph.json); if (!fs.existsSync(graphPath)) return null; const data JSON.parse(fs.readFileSync(graphPath, utf-8)); if (options?.validate ! false) { const result validateGraph(data); if (!result.success) { throw new Error(Invalid knowledge graph: ${result.errors?.join(; )}); } return result.data as KnowledgeGraph; } return data as KnowledgeGraph; }这个设计的取舍值得注意默认开启校验、保留关闭开关既防止坏数据流入下游功能又为调试或迁移场景留了后门。2.5 源码演进从拒绝到分层修复查看当前 schema.ts 可以看到落地实现远比计划版本复杂——这正体现了计划是骨架、实现长出了血肉。几个关键演进边类型从 18 种扩展到 38 种覆盖 9 大类Structural、Behavioral、Data flow、Dependencies、Semantic、Infrastructure、Schema/Data、Domain、Knowledge以支持非代码节点服务、表、流水线、领域流、知识库条目等引入别名归一化NODE_TYPE_ALIASES如func/method→function、interface→class、EDGE_TYPE_ALIASES如extends→inherits、COMPLEXITY_ALIASESlow→simple、DIRECTION_ALIASESto→forward——这些都是 LLM 生成图谱时的高频漂移写法四级容错流水线见validateGraph实现schema.ts#L563-L727Tier 1sanitizeGraph空值归一null→ 空数组/删除可选字段、枚举字段小写化Tier 2autoFixGraph缺失字段自动补默认值并记录 issue如缺type补file、缺weight补0.5、越界 weight 夹紧到[0,1]Tier 3 逐条校验 nodes/edges/layers/tour坏条目丢弃并记录而非整体失败同时做引用完整性检查边的 source/target 必须存在于 nodes 中Tier 4 致命错误输入非对象、必备集合非数组、project元数据缺失、无有效节点。返回结构升级为ValidationResult { success, data?, issues, fatal?, errors? }其中issues携带level: auto-corrected | dropped | fatal分级信息。这种能修则修、该丢则丢、致命才拒的策略与计划中weight 越界直接 fail的严格取向明显不同——从源码结构看这是后续接入 LLM 生成图谱非确定性输出后的务实妥协。loadGraph的接线也确已落地persistence/index.ts 第 5 行导入validateGraph第 110 行与第 187 行分别在加载路径上调用它。3. Task 2基于 Fuse.js 的增强搜索引擎3.1 从子串匹配到模糊匹配计划指出原 Dashboard store 只有大小写不敏感子串搜索name/summary/tags而 Phase 2 需要模糊匹配 相关性打分。方案是把可复用的SearchEngine放进 coredashboard 和 skill 共用底层用 Fuse.js 驱动。3.2 测试矩阵计划给出了 9 个用例覆盖空查询返回空、精确名匹配、模糊名匹配auth contrl命中AuthenticationController、summary 字段搜索、tags 搜索、名称匹配优先于摘要匹配auth查询时auth.ts排在utils.ts其 summary 含 auth之前、返回带score数值的结果、updateNodes重建索引、按节点类型过滤。这些用例即 search.test.ts 的来源。3.3 索引配置与评分权重计划中的SearchEngine核心是 Fuse 选项与搜索流程private createIndex(nodes: GraphNode[]): FuseGraphNode { return new Fuse(nodes, { keys: [ { name: name, weight: 0.4 }, { name: tags, weight: 0.3 }, { name: summary, weight: 0.2 }, { name: languageNotes, weight: 0.1 }, ], threshold: 0.4, includeScore: true, ignoreLocation: true, }); }权重分配name 0.4 tags 0.3 summary 0.2 languageNotes 0.1正是名称匹配优先测试用例能通过的机制原因threshold: 0.4控制模糊度0 精确、1 最模糊score语义为0 完美匹配1 最差匹配见SearchResult接口的注释search(query, options?)支持types按节点类型过滤与limit默认 50updateNodes整体重建索引服务图谱刷新场景。3.4 源码现状扩展搜索与 OR 分词当前 search.ts 保持了计划的接口形态SearchResult、SearchOptions、SearchEngine类、相同的键权重与threshold: 0.4但有两处增强开启useExtendedSearch: true查询预处理为空格分词后用|连接——auth contrl变成auth | contrl语义为任一 token 命中即可// 源码 search.ts const extendedQuery trimmed.split(/\s/).join( | ); const rawResults this.fuse.search(extendedQuery);这使得多词口语化查询如验证计划里输入auth contrl应能命中AuthController的验收项的召回率显著提高。4. Task 3Dagre 自动布局——告别网格排布4.1 问题与方案计划描述原 GraphView 用(index % 3) * 300的简单网格定位节点对真实项目会产生混乱的图。方案是引入 dagre 分层布局hierarchical layout节点自上而下流动层级由边方向决定。4.2 布局工具设计计划给出的applyDagreLayout(nodes, edges, direction TB)关键点固定节点尺寸NODE_WIDTH 280、NODE_HEIGHT 120对应 layout.ts 中的导出常量dagre 图参数nodesep: 60同层间距、ranksep: 80层间间距、marginx/marginy: 20布局完成后把 dagre 返回的中心坐标换算为 React Flow 需要的左上角坐标x: pos.x - NODE_WIDTH / 2, y: pos.y - NODE_HEIGHT / 2GraphView 接入四步导入applyDagreLayout→ 从图谱数据构建无位置信息的 flow 节点/边 → 过一遍布局函数 → 用useMemo确保仅在图谱/搜索变化时重算。自定义节点、搜索高亮、选择、控件、minimap 等既有能力全部保留。4.3 源码演进从 dagre 到 ELK 的过渡期当前 layout.ts 中applyDagreLayout已被标记为deprecated注释说明dashboard 的结构视图已全部改用 ELKapplyElkLayout此 helper 保留一个发布周期作为 ELK 回归时的快速回退。同时可见布局参数也做了规模化调整节点数超过 50 时自动放大间距nodesep: 80 / ranksep: 120并支持nodeDimensions按节点传尺寸。同一文件还沉淀了 ELK 的默认布局选项elk.direction: DOWN、elk.layered.crossingMinimization.strategy: LAYER_SWEEP、正交布线elk.edgeRouting: ORTHOGONAL等。从源码结构看Phase 2 的 dagre 布局是布局可配置化的第一步后续被更强大的 ELK 分层布局取代——这与仓库中 graph-layout-scaling 设计文档 的主题相呼应。5. Task 4过期检测与增量图谱合并5.1 设计边界计划明确划分了职责本任务只构建积木——检测变更文件、把新节点/边合并进现有图谱不调用 LLM 和 tree-sitter那是 skill 层的编排工作。自动同步流程为读meta.json→ 与上次 hash 做 git diff → 仅重新分析变更文件 → 合并进现有图谱。5.2 三个核心函数getChangedFiles(projectDir, lastCommitHash)执行git diff hash..HEAD --name-onlycwd: projectDir按行拆分git 出错时返回空数组容错优先。测试用例验证了命令形态git diff abc123..HEAD --name-only、无变更返回空、异常返回空三种情况。isStale(projectDir, lastCommitHash)封装为{ stale: changedFiles.length 0, changedFiles }。mergeGraphUpdate(existingGraph, changedFilePaths, newNodes, newEdges, newCommitHash)的合并规则按filePath移除属于变更文件的旧节点移除source 属于变更文件的旧边追加新节点与新边更新project.gitCommitHash与project.analyzedAt当前时间 ISO 串。测试覆盖了变更文件节点被替换旧foo函数消失、新bar出现、b.ts不变、hash 更新、旧 contains 边被移除且新 imports 边权重为 0.9、analyzedAt时间戳刷新。5.3 源码演进同步 → 异步新鲜度状态机当前 staleness.ts 完整保留了计划的getChangedFiles/isStale/mergeGraphUpdate三个同步 API测试 staleness.test.ts 对应验证并在此之上新增了一套异步getGraphFreshness体系把二值 stale升级为四态结果export type GraphFreshnessResult | { status: fresh; changedFiles: []; commitsBehind: 0; commitsAhead: 0; ... } | { status: dirty; changedFiles: string[]; ... } // 仅工作区有未提交变更 | { status: stale; relation: behind | ahead | diverged; commitsBehind: number; commitsAhead: number; ... } | { status: unknown; reason: GraphFreshnessUnknownReason; ... };工程细节值得细读git 调用全部异步化execFile封装的runGit5 秒超时、4MB 缓冲区staleness.ts#L70-L117失败映射到明确的unknown原因git-head-unavailable、graph-commit-unavailable、git-command-timeout等monorepo 感知所有 diff 都带 pathspec-- . :(exclude).understand-anything /** :(exclude).ua /**排除兄弟项目改动与图谱产物本身关系判定用git merge-base --is-ancestor双向探测区分图谱落后behind、领先ahead与分叉diverged并给出commitsBehind/commitsAhead计数git rev-list --left-right --count源码注释明确表态unknown 与 fresh 刻意区分读不到 Git 元数据时应温和告警而非宣称图谱是最新的。mergeGraphUpdate的实现也有一处关键修正保留边的条件从仅看 source改为source 或 target 任一落在被删节点集即移除staleness.ts#L472-L508避免悬挂边。6. Task 5分层自动推断——启发式与 LLM 双通道6.1 启发式通道目录模式匹配计划定义LAYER_PATTERNS目录路径子串 → 分层信息的有序映射首个匹配胜出first match wins未匹配文件归入 Core 层仅type file的节点参与分层。计划中的分层包括 API Layerroute/controller/handler/endpoint、Service Layerservice/usecase/business、Data Layermodel/entity/schema/database/migration/repository、UI Layercomponent/view/page/screen/layout、Middleware Layer、Utility Layer、Test Layer、Configuration Layer。对应测试断言src/routes/users.ts归入 API 层、src/models/user.ts归入 Data 层、无匹配文件落入通用层、层 ID 唯一、函数节点不出现在任何层里。当前实现 layer-detector.ts 保留了整体思路但匹配策略更严谨matchFileToLayer把路径按/拆段后做段级等值或复数匹配segment pattern || segment pattern s避免子串误伤如文件名里恰好含 api 字母序列分层也扩展到了 External Services、Background Tasks 等 10 类。detectLayers还优化为单遍扫描无路径的 file 节点在主循环中先行收集最后并入 Core保持插入顺序。6.2 LLM 增强通道prompt 构建与响应解析计划给出三个配套函数buildLayerDetectionPrompt(graph)收集全部文件路径要求 LLM 只返回 JSON{ layers: [ { name: Layer Name, description: What this layer does, filePatterns: [path/prefix/] } ] }规则识别 3–7 个逻辑层、每层有清晰架构职责、filePatterns用路径前缀表达。parseLayerDetectionResponse(response)做防御性解析剥离 markdown 代码围栏、JSON.parse、校验layers数组、逐项类型归一任何异常返回null。applyLLMLayers(graph, llmLayers)把 LLM 结果物化为Layer[]按filePatterns前缀匹配 file 节点一个节点只归一个层、未分配的落入 Other 层、过滤空层。当前实现与计划高度一致且解析器更宽容既支持{layers: [...]}对象也支持裸 JSON 数组/\[[\s\S]*\]/提取逐项校验name必须是字符串。这组启发式保底 LLM 增强的双通道设计是有 LLM 更好、无 LLM 也能用的典型工程取舍。7. Task 6Skill 包与 /understand-chat 命令7.1 包脚手架计划创建packages/skillunderstand-anything/skillESM tsc vitest依赖 workspace 内的 core这是首个 Claude Code skill 命令的载体。/understand-chat的定位是终端内问答skill 读取持久化的.understand-anything/knowledge-graph.json用当前 Claude 会话作为 LLM——不发起独立 API 调用零额外成本。7.2 context-builder检索 一跳扩展 格式化buildChatContext(graph, query, maxNodes 15)的算法四步走用 core 的SearchEngine检索前maxNodes个相关节点沿边一跳扩展命中节点的邻接节点全部纳入收集两端都在相关集合内的边收集包含相关节点的层。返回ChatContext { projectName, projectDescription, languages, frameworks, relevantNodes, relevantEdges, relevantLayers, query }。formatContextForPrompt把上下文渲染为 Markdown项目头名称/描述/语言/框架→## Relevant Layers每层### 名称 描述→## Relevant Code Components每节点名称、类型、复杂度、文件路径、摘要、tags、languageNotes→## Relationships- 源 --[边类型]-- 目标 (描述)的边列表。计划中的测试context-builder.test.ts 即其来源用了一个 4 节点、2 边、2 层的样例图谱断言查询 how does authentication work? 能找到 auth 节点、上下文包含连接节点db/connection、routes/api、携带项目元数据、包含相关层格式化文本包含login.ts、authentication与边类型imports。当前实现 context-builder.ts 与计划几乎逐行对应用nodeMap按扩展后 ID 有序收集节点是微小的工程优化maxNodes默认 15 保持不变。7.3 提示词模板buildChatPrompt(graph, query)将系统指令与上下文拼接指令要点引用具体文件与函数架构类问题要描述层级与关系不确定就明说、不要猜。当前 understand-chat.ts 保留了同构的五条指令输出格式改为以---分隔指令 / 上下文 / 用户问题三段结尾以**User question:** ${query}收尾。7.4 Skill 定义文件计划中的 skill markdownfrontmatter 声明name: understand-chat、arguments: query指令链读图谱文件 → 不存在则提示先跑/understand→ 用图谱上下文回答${ARGUMENTS}→ 引用具体文件/函数/关系 → 有层则解释相关层 → 简洁但完整。仓库中的正式落地是 skills/understand-chat/SKILL.md在计划骨架上大幅扩充为可操作的工作流声明图谱 JSON 的完整结构参考project/nodes/edges/layers/tour 及各节点类型体系、高效读取准则先 Grep 再读、别把整个图谱倒进上下文、数据目录解析.ua/新目录与.understand-anything/遗留目录二选一、以及与 Task 4 新鲜度逻辑同构的 Git 校验序列GRAPH_COMMIT$(git rev-parse --verify --end-of-options ${GRAPH_COMMIT_RAW}^{commit} 2/dev/null) git rev-parse HEAD git diff --name-only $GRAPH_COMMIT HEAD -- . git diff --cached --name-only -- . git diff --name-only -- . git ls-files --others --exclude-standard -- .其中-- .pathspec 是 monorepo 防误报的关键hash 不一致但项目内 diff 为空不算过期——这与staleness.ts中PROJECT_PATHSPEC的排除策略一脉相承。8. Task 7Dashboard 搜索接入与 Store 集成8.1 Store 改造计划要求把 Zustand store 中的子串过滤替换为 core 的SearchEnginesetGraph时构造引擎并随 graph 一起存入 storesetSearchQuery时空查询清空结果否则调用engine.search(query)得到带分数的SearchResult[]store 中searchResults的类型从string[]升级为SearchResult[]。当前 store.ts 确认了这一接线第 2 行import { SearchEngine } from understand-anything/core/searchsetGraph内new SearchEngine(graph.nodes)L367查询时engine.search(query)写入searchResultsL543。源码注释还透露了后续方向当嵌入向量可用时semantic 模式将改用SemanticSearchEngine。8.2 UI 侧增强SearchBar显示带 fuzzy 标签的结果计数前 5 名以下拉形式展示名称 类型 分数点击结果选中节点并滚动定位GraphView 分数高亮高亮强度随分数变化——分数越低匹配越好高亮越亮亮黄色环弱匹配则更暗分数作为 data 传入 CustomNode 调整外观。9. Task 8Dashboard 聊天面板9.1 设计要点独立 Dashboard无 Claude Code 会话场景下用户自备 Claude API key。聊天为上下文感知自动带上当前选中节点的上下文与邻近图关系。计划要求安装anthropic-ai/sdk并流式渲染响应。store 新增状态apiKey、chatMessages: ChatMessage[]role: user | assistant、chatLoading及setApiKey/sendChatMessage/clearChat。sendChatMessage的六步流程取 store 中的 graph/selectedNodeId/apiKey → 用buildChatContextformatContextForPrompt构建上下文 → 组装系统提示词 → 调用 Claude API → 流式更新消息列表 → 全程维护chatLoading。9.2 组件规格ChatPanel七大特性API key 输入一次性显示、存 zustand 并持久化到 localStorage、user/assistant 分色的消息列表、输入框 发送按钮、选中节点时的 Context: 节点名 指示器、调用中 loading 动画、自动滚动到最新消息、assistant 消息的基础 Markdown 渲染粗体/代码块/列表。布局示意图中展示了选中auth/login.ts后提问 How does auth work?助手回答可顺藤摸到routes/api.ts的调用链的完整对话闭环验收步骤即填 key → 选节点 → 问 what does this do? 验证上下文回答 → 追问验证会话历史保持。10. Task 9分层可视化计划要求图谱含layers时按层分组渲染store 增加showLayers: boolean与toggleLayersGraphView 开启分组时为每层创建 React Flow 的 group 节点大号半透明背景矩形层成员以parentId挂为子节点各层配色可区分层名作为 group 标签showLayers关闭时正常渲染LayerLegend组件Show/Hide Layers 切换按钮、带色点/名称/节点数的层列表、点击层名可过滤图谱到该层图例挂在 App.tsx 头部 SearchBar 旁验收依赖把packages/dashboard/public/knowledge-graph.json样例更新为含 layers 的数据。11. Task 10集成打磨——样例数据、构建验证与文档11.1 富样例图谱计划要求把knowledge-graph.json升级为能压测全部 Phase 2 特性的样例15–20 个节点覆盖全部 5 种类型file/function/class/module/concept、20 条多类型边、4–5 个层API/Service/Data/UI/Utility、复杂度分布有变化、摘要与标签拟真——同时充当演示数据与手工测试夹具。仓库中现存的 knowledge-graph.json 即是该任务的产物。11.2 全量构建验证命令pnpm install pnpm --filter understand-anything/core build pnpm --filter understand-anything/skill build pnpm --filter understand-anything/core test pnpm --filter understand-anything/skill test pnpm dev:dashboard并要求更新CLAUDE.md补充 skill 包 build/test 命令与 Phase 2 特性清单和README.md特性描述与截图占位。12. 验证清单与任务依赖关系12.1 十条验收清单计划末尾给出端到端验证清单Schema 校验加载损坏 JSON → 应以清晰错误信息抛出模糊搜索输入auth contrl→ 应命中AuthController类目标自动布局打开 dashboard → 节点应呈层级排布而非网格过期检测调用isStale(/project, oldHash)→ 应检出变更分层推断对含 routes/models/services 的项目调用detectLayers(graph)→ 应填充 layers/understand-chat确认 skill 文件存在于packages/skill/.claude/skills/understand-chat.md计划口径当前仓库中对应物为understand-anything-plugin/skills/understand-chat/SKILL.md聊天面板填 key、选节点、提问 → 验证上下文感知回答分层可视化开启分层开关 → 应出现彩色 group 节点全量测试pnpm --filter understand-anything/core test pnpm --filter understand-anything/skill test全量构建pnpm -r build成功。12.2 依赖图与可并行分组Task 1 (zod schema) ─────────────────────────────┐ Task 2 (search engine) ──┬── Task 7 (dashboard │ Task 3 (dagre layout) ───┤ search store) │ │ │ Task 4 (staleness) ──────┤ │ │ │ Task 5 (layers) ─────────┼── Task 9 (layer viz) ─┤ │ ├── Task 10 (polish) Task 6 (skill pkg) ──────┼── Task 8 (chat panel) ─┤ │ │ Task 7 ──────────────────┘ │ Task 8 ──────────────────────────────────────────┘ Task 9 ──────────────────────────────────────────┘Task 1、2、3、4、5、6 相互独立按 subagent-driven-dev 惯例仍串行执行Task 7 依赖 Task 2 3Task 8 依赖 Task 6Task 9 依赖 Task 3 5Task 10 依赖全部。13. 小结从计划到源码的落地轨迹对照计划文档与当前仓库源码可以梳理出一条清晰的演进轨迹计划任务计划中的 API当前源码状态Task 1 Schema 校验KnowledgeGraphSchema/validateGraph越界即失败schema.ts 扩展为 38 种边类型 四级容错sanitize → autoFix → 逐条丢弃 → fatalloadGraph默认校验已接线Task 2 搜索引擎Fuse.js四键加权threshold 0.4search.ts 接口不变新增 extended search 的 OR 分词多词模糊召回更强Task 3 自动布局dagreTB布局280×120 节点layout.ts 保留 dagre标记 deprecated 作回退主布局迁移至 ELK间距随规模自适应Task 4 过期检测getChangedFiles/isStale/mergeGraphUpdatestaleness.ts 三函数保留另增四态getGraphFreshnessfresh/dirty/stale/unknown monorepo pathspec 超时保护Task 5 分层推断8 类目录模式 LLM 三函数layer-detector.ts 10 类模式、段级精确匹配、prompt/解析/apply 三件套齐备Task 6 skill 包context-builder buildChatPrompt skill mdcontext-builder.ts、understand-chat.ts 落地SKILL.md 扩展为含新鲜度校验的完整工作流Task 7 store 集成SearchEngine进 Zustandstore.ts 已接线并预留语义检索模式Task 8–9 面板与分层可视化ChatPanel、LayerLegend、group 节点对应组件已存在于 dashboard 组件目录如 LayerLegend.tsxTask 10 打磨富样例、文档更新knowledge-graph.json 已含 layers 等完整结构这份计划文档的价值不止于任务清单它明确了每个功能的职责边界core 出算法积木、skill 负责 LLM 编排、dashboard 消费 API、测试先行的实现节奏以及依赖图驱动的并行策略——这三点解释了为何 Phase 2 的八大特性模糊搜索、Schema 校验、过期检测、分层推断、/understand-chat、聊天面板、自动布局、分层可视化能作为一组一致的能力落入同一个 monorepo。对后续维护者而言docs/superpowers/plans/2026-03-14-phase2-implementation.md 与其上游设计文档 2026-03-14-understand-anything-design.md 是理解这些模块为什么这样设计的最佳入口。【免费下载链接】Understand-AnythingGraphs that teach graphs that impress. Turn any code into an interactive knowledge graph you can explore, search, and ask questions about. Works with Claude Code, Codex, Cursor, Copilot, Gemini CLI, and more.项目地址: https://gitcode.com/GitHub_Trending/un/Understand-Anything创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考