Understand Anything /understand-diff 实战指南把 Git Diff 变成知识图谱上的结构化影响分析【免费下载链接】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 插件中的understand-diff技能展开讲解如何以项目数据目录中的知识图谱.ua/knowledge-graph.json或旧版.understand-anything/knowledge-graph.json为基准对当前未提交改动、功能分支或指定 PR 的 diff 做变更组件 / 受影响组件 / 受影响架构层 / 风险等级四维分析并产出可供 Dashboard 可视化的高亮覆盖层diff-overlay.json。读完并掌握文中的八步流程、新鲜度检查的 Git 命令细节与 diff 分析器的实现原理后你可以直接在自己的项目里复现整套改了什么、会波及什么、风险有多大的工程化审查流程。技能定位与前置条件/understand-diff的技能定义位于 understand-anything-plugin/skills/understand-diff/SKILL.md其 frontmatter 描述为Use when you need to analyze git diffs or pull requests to understand what changed, affected components, and risks。它不是替代git diff的阅读工具而是把文件级变更映射到知识图谱的节点与边上回答两个传统 diff 回答不了的问题影响面哪些组件通过 imports / calls 等边与本次变更相连1-hop 波及范围架构风险变更触碰了哪些架构层是否跨层、是否命中高复杂度节点。数据目录解析Step 1 前置技能第一步要求先解析数据目录$UA_DIR且旧目录优先UA_DIR$([ -d .understand-anything ] echo .understand-anything || echo .ua)即若项目中已存在旧版.understand-anything/目录则沿用旧目录否则使用新版.ua/。随后必须确认$UA_DIR/knowledge-graph.json存在否则应提示用户先运行/understand生成图谱——没有图谱后续的节点映射与边追踪全部无从谈起。Dashboard 技能understand-anything-plugin/skills/understand-dashboard/SKILL.md中采用完全相同的目录判定逻辑两处保持一致。知识图谱结构参考Graph Structure Reference技能文档给出了完整的图谱 JSON 结构约定做任何 diff 分析前必须熟悉。图谱顶层由五个部分构成project项目元数据{name, description, languages, frameworks, analyzedAt, gitCommitHash}。其中gitCommitHash是新鲜度检查的关键——它记录图谱是在哪个提交上生成的。从源码看这一字段由 ProjectMetaSchema 定义为必填字段缺失会导致整个图谱校验失败。nodes[]节点每个节点包含{id, type, name, filePath?, summary, tags[], complexity, languageNotes?}节点类型分三大类类别类型代码节点file,function,class,module,concept非代码节点config,document,service,table,endpoint,pipeline,schema,resource领域/知识节点domain,flow,step,article,entity,topic,claim,source节点 ID 以类型前缀开头例如file:path、function:path:name、config:path、article:path。源码中 GraphNodeSchema 进一步约束了字段细节complexity只允许simple/moderate/complex三档low、high等别名会在 normalizeGraph 阶段被自动映射为规范值summary与tags是必填的缺失时 autoFixGraph 会用name兜底并记录 auto-corrected 问题lineRange为可选的[start, end]二元组用于函数/类级节点的定位。edges[]边每条边为{source, target, type, direction, weight}。技能文档列出与 diff 分析最相关的边类型imports,contains,calls,depends_on,configures,documents,deploys,triggers,contains_flow,flow_step,related,cites。完整的边类型枚举定义在 EdgeTypeSchema共 38 种边类型按结构structural、行为behavioral、数据流data flow、依赖dependencies、语义semantic、基础设施infrastructure、Schema/数据、领域domain、知识knowledge、设计design九类组织。direction取forward/backward/bidirectionalweight是[0, 1]区间的数字越界会被 clamp。layers[] 与 tour[]layers[]每项为{id, name, description, nodeIds[]}表示架构分层tour[]每项为{order, title, description, nodeIds[]}是项目的导览步骤。diff 分析主要用到layers——判断变更落在哪些架构层。高效读取策略技能文档对如何读图谱给出四条明确纪律本质是控制 LLM 上下文成本先 Grep 后 Read在完整读取 JSON 之前先用 Grep 在其中检索相关条目只读需要的片段不要将整个图谱一次性倾倒进上下文name与summary是最有价值的字段理解组件语义优先看这两个字段顺着边找依赖链edges 描述组件如何相连沿imports与calls边即可追踪依赖链。这与后文 Step 4–6 的Grep 节点 → Grep 边 → Grep 层三步检索法完全对应。八步工作流详解Step 2获取变更文件列表先不要读图谱技能强调do NOT read the graph yet三种场景对应三种取法# 当前分支有未提交改动 git diff --name-only # 功能分支相对基线分支如 main git diff main...HEAD --name-only # 用户指定 PR 号时取该 PR 的 diff先拿到纯净的文件路径列表再进入图谱检索可以避免在确定变更范围之前被大文件内容干扰。Step 3读取 project 元数据并检查图谱新鲜度最关键的守卫步骤用 Grep 或限制行数的 Read 提取图谱中的project段把gitCommitHash记为GRAPH_COMMIT_RAW然后执行以下命令组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 -- .这条命令组里有几个容易做错、但技能文档明确强调的细节先 resolve 再使用GRAPH_COMMIT_RAW必须先通过git rev-parse --verify --end-of-options ${GRAPH_COMMIT_RAW}^{commit}解析为规范 commit 才能进入 diff。--end-of-options防止以-开头的异常输入被当作选项^{commit}强制要求它是一个 commit 对象。-- .pathspec 是必需的git diff $GRAPH_COMMIT HEAD -- .中结尾的-- .把 diff 限定在当前项目目录内。其动机是 monorepo 场景只改动了兄弟子项目的提交不应让本项目图谱被判为过期。文档原话A hash mismatch alone is not stale when the project diff is empty.——仅哈希不一致而项目内无 diff 时不算 stale。数据目录要排除所有命令输出中必须忽略.ua/或.understand-anything/因为它们存放的是生成的图谱产物不是项目源码漂移。源码中的新鲜度模块 staleness.ts 用 Git 的 pathspec 排除语法实现了同一语义const PROJECT_PATHSPEC [ --, ., :(exclude).understand-anything, :(exclude).understand-anything/**, :(exclude).ua, :(exclude).ua/**, ] as const;stale 时先警告再分析若 committed diff 或任何 working-tree 命令报告了项目文件必须在影响分析之前发出警告图谱可能缺失这些变更并建议运行/understand刷新图谱。元数据缺失不阻塞只在GRAPH_COMMIT_RAW解析成功时才执行 commit diff若图谱 commit 缺失、非法或不可用给出一条简短的 best-effort 警告后继续不中断整个分析流程。从源码结构看这套宽松但不含糊的判定逻辑与 getGraphFreshness 的实现一致新鲜度结果是一个四态判别联合——fresh无漂移、dirtycommit 相同但有工作区改动、stale带behind/ahead/diverged关系并有commitsBehind/commitsAhead计数、unknownGit 元数据不可读。源码注释特别指出Unknown is intentionally distinct from fresh: if Git metadata cannot be read, callers should warn softly rather than imply the graph is current.——unknown与fresh刻意区分Git 读不到时只能软警告绝不能暗示图谱是最新的。Step 4为每个变更文件定位图谱节点对每个变更文件路径用 Grep 在知识图谱中搜索匹配的filePath值grep changed/file/path $UA_DIR/knowledge-graph.json这一步同时命中两类节点文件级节点包括非代码类型如config:、document:前缀节点定义在该文件内的函数/类节点如function:path:name。把全部命中节点的id记录下来它们就是变更组件的集合。Step 5沿边做 1-hop 扩展找出受影响组件对每个命中的节点 IDGrep 边数组中 source 或 target 等于该 ID 的边区分两个方向上游调用者谁 import / depends on 了变更节点——这些组件可能需要同步更新下游依赖变更节点 import / calls 了什么——这些依赖的签名或行为变化会传导下去。两个方向合并即受影响组件也就是可能损坏或需要更新的部分。注意只扩展 1-hop不无限递归——这是技能刻意选择的精度与成本平衡点。Step 6识别受影响的架构层把 Step 4 命中的节点 ID 在layers段中检索确定哪些架构层被触碰。跨多个层出现的变更通常意味着需要额外关注层间契约如 API 变更波及 Service 层与数据层。Step 7输出结构化分析分析结果按四个板块组织Changed Components变更组件直接修改的内容附命中节点的 summaryAffected Components受影响组件来自 1-hop 边扩展Affected Layers受影响层触碰了哪些架构层、是否涉及跨层关注点Risk Assessment风险评估基于节点complexity值、跨层边数量与 blast radius受影响组件数量。最后给出应重点审查什么以及潜在问题的建议。风险判定不是拍脑袋diff-analyzer.ts 的 formatDiffAnalysis 给出了可复核的阈值变更节点中存在complexity complex→ 报High complexity受影响架构层数 1 → 报Cross-layer impact受影响组件数 5 → 报Wide blast radius存在未映射进图谱的文件 → 单独提示New/unmapped files可能需要重新分析以上条件均不满足 → 输出Low risk: Changes are localized with limited downstream impact.Step 8写出 diff overlay交给 Dashboard 可视化分析产出之后把 diff 数据写入$UA_DIR/diff-overlay.json供 Dashboard 高亮变更与受影响组件。文件结构为{ version: 1.0.0, baseBranch: the base branch used, generatedAt: ISO timestamp, changedFiles: [list of changed file paths], changedNodeIds: [node IDs from step 4], affectedNodeIds: [node IDs from step 5, excluding changedNodeIds] }写完后应提示用户可以运行/understand-anything:understand-dashboard可视化查看。Dashboard 端的消费逻辑可以在 App.tsx 中逐行印证启动时fetch(dataUrl(diff-overlay.json, accessToken))并对响应做严格形状校验——必须同时存在changedNodeIds与affectedNodeIds两个数组字段且changedNodeIds非空时才会调用 store.ts 中的setDiffOverlay(changed, affected)写入状态。UI 上由 DiffToggle.tsx 提供 Diff ON/OFF 开关开启后图例会按 changed / affected 两种颜色区分节点并在图例旁展示两类节点的计数没有 overlay 数据时按钮置灰不可点。这条链路解释了为什么affectedNodeIds要excluding changedNodeIds——两类集合在前端是分开着色、分开计数的重复 ID 会污染 affected 侧的统计。源码级实现对照buildDiffContext 与测试用例技能文档描述的是让 LLM 用 Grep 手动完成的流程而插件在 understand-anything-plugin/src/diff-analyzer.ts 中提供了同一套算法的程序化实现 buildDiffContext可作为流程正确性的参照实现文件到节点的映射遍历nodes凡node.filePath file即计入changedNodeIds未命中的文件进入unmappedFilescontains 子节点扩展对type contains且 source 是变更节点的边把 target文件内的函数/类节点也并入变更集合——对应 Step 4 中文件节点及其内部函数/类节点一并命中的语义1-hop 扩展遍历所有边source 或 target 在变更集合中的边记为impactedEdges另一端不在变更集合的节点记为 affected天然去重affected 与 changed 不相交层判定layers中nodeIds与变更 ∪ 受影响集合有交集的层即为受影响层。测试文件 diff-analyzer.test.ts 用一个五节点三层的迷你图谱把每条规则都钉住了改src/service.ts后断言变更集合包含文件节点与其contains子节点function:src/service.ts:processL43-L46断言 affected 通过calls/reads_from边扩展到file:src/routes.ts与file:src/db.tsL48-L52断言 affected 与 changed 无交集的去重不变量L76-L82断言未入图文件落入unmappedFiles且优雅降级L64-L68断言空 diff 不产生任何结果L70-L74。这些用例与 SKILL.md 的 Step 4–7 一一对应是验证自己手工 Grep 流程是否漏判的直接参照。适用前提与限制图谱必须先存在且可读$UA_DIR/knowledge-graph.json缺失时整个技能退化为提示先运行 /understand依赖 Git新鲜度检查、变更文件列表都来自 Git 命令在 Git 元数据不可用的仓库浅克隆、被剥离历史的检出等按 Step 3 的 best-effort 约定只应给出简短警告并继续不能把unknown当作fresh1-hop 是上限本技能刻意只扩展一层边二跳及以上的间接影响不会出现在 affected 集合中审查长依赖链时仍需人工沿边继续追踪未映射文件不在分析范围内新增文件若尚未被/understand收进图谱只会出现在unmapped提示中其真实影响需要刷新图谱后重跑monorepo 场景务必保留-- .pathspec 与数据目录排除否则会因兄弟项目提交或图谱产物文件的变动误判过期。综合来看/understand-diff把读 diff升级为在知识图谱上读 diffStep 3 的新鲜度守卫保证分析基准可信Step 4–6 的三次 Grep 检索把文件变更翻译成节点、边与层Step 7 按可复核的阈值给出风险分级Step 8 再把结果沉淀为 Dashboard 可渲染的 overlay。配合 understand-dashboard 技能启动的可视化界面一次变更审查从命令行一路贯通到图形化复盘。【免费下载链接】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），仅供参考 Understand Anything /understand-diff 实战指南：把 Git Diff 变成知识图谱上的结构化影响分析
Understand Anything /understand-diff 实战指南把 Git Diff 变成知识图谱上的结构化影响分析【免费下载链接】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 插件中的understand-diff技能展开讲解如何以项目数据目录中的知识图谱.ua/knowledge-graph.json或旧版.understand-anything/knowledge-graph.json为基准对当前未提交改动、功能分支或指定 PR 的 diff 做变更组件 / 受影响组件 / 受影响架构层 / 风险等级四维分析并产出可供 Dashboard 可视化的高亮覆盖层diff-overlay.json。读完并掌握文中的八步流程、新鲜度检查的 Git 命令细节与 diff 分析器的实现原理后你可以直接在自己的项目里复现整套改了什么、会波及什么、风险有多大的工程化审查流程。技能定位与前置条件/understand-diff的技能定义位于 understand-anything-plugin/skills/understand-diff/SKILL.md其 frontmatter 描述为Use when you need to analyze git diffs or pull requests to understand what changed, affected components, and risks。它不是替代git diff的阅读工具而是把文件级变更映射到知识图谱的节点与边上回答两个传统 diff 回答不了的问题影响面哪些组件通过 imports / calls 等边与本次变更相连1-hop 波及范围架构风险变更触碰了哪些架构层是否跨层、是否命中高复杂度节点。数据目录解析Step 1 前置技能第一步要求先解析数据目录$UA_DIR且旧目录优先UA_DIR$([ -d .understand-anything ] echo .understand-anything || echo .ua)即若项目中已存在旧版.understand-anything/目录则沿用旧目录否则使用新版.ua/。随后必须确认$UA_DIR/knowledge-graph.json存在否则应提示用户先运行/understand生成图谱——没有图谱后续的节点映射与边追踪全部无从谈起。Dashboard 技能understand-anything-plugin/skills/understand-dashboard/SKILL.md中采用完全相同的目录判定逻辑两处保持一致。知识图谱结构参考Graph Structure Reference技能文档给出了完整的图谱 JSON 结构约定做任何 diff 分析前必须熟悉。图谱顶层由五个部分构成project项目元数据{name, description, languages, frameworks, analyzedAt, gitCommitHash}。其中gitCommitHash是新鲜度检查的关键——它记录图谱是在哪个提交上生成的。从源码看这一字段由 ProjectMetaSchema 定义为必填字段缺失会导致整个图谱校验失败。nodes[]节点每个节点包含{id, type, name, filePath?, summary, tags[], complexity, languageNotes?}节点类型分三大类类别类型代码节点file,function,class,module,concept非代码节点config,document,service,table,endpoint,pipeline,schema,resource领域/知识节点domain,flow,step,article,entity,topic,claim,source节点 ID 以类型前缀开头例如file:path、function:path:name、config:path、article:path。源码中 GraphNodeSchema 进一步约束了字段细节complexity只允许simple/moderate/complex三档low、high等别名会在 normalizeGraph 阶段被自动映射为规范值summary与tags是必填的缺失时 autoFixGraph 会用name兜底并记录 auto-corrected 问题lineRange为可选的[start, end]二元组用于函数/类级节点的定位。edges[]边每条边为{source, target, type, direction, weight}。技能文档列出与 diff 分析最相关的边类型imports,contains,calls,depends_on,configures,documents,deploys,triggers,contains_flow,flow_step,related,cites。完整的边类型枚举定义在 EdgeTypeSchema共 38 种边类型按结构structural、行为behavioral、数据流data flow、依赖dependencies、语义semantic、基础设施infrastructure、Schema/数据、领域domain、知识knowledge、设计design九类组织。direction取forward/backward/bidirectionalweight是[0, 1]区间的数字越界会被 clamp。layers[] 与 tour[]layers[]每项为{id, name, description, nodeIds[]}表示架构分层tour[]每项为{order, title, description, nodeIds[]}是项目的导览步骤。diff 分析主要用到layers——判断变更落在哪些架构层。高效读取策略技能文档对如何读图谱给出四条明确纪律本质是控制 LLM 上下文成本先 Grep 后 Read在完整读取 JSON 之前先用 Grep 在其中检索相关条目只读需要的片段不要将整个图谱一次性倾倒进上下文name与summary是最有价值的字段理解组件语义优先看这两个字段顺着边找依赖链edges 描述组件如何相连沿imports与calls边即可追踪依赖链。这与后文 Step 4–6 的Grep 节点 → Grep 边 → Grep 层三步检索法完全对应。八步工作流详解Step 2获取变更文件列表先不要读图谱技能强调do NOT read the graph yet三种场景对应三种取法# 当前分支有未提交改动 git diff --name-only # 功能分支相对基线分支如 main git diff main...HEAD --name-only # 用户指定 PR 号时取该 PR 的 diff先拿到纯净的文件路径列表再进入图谱检索可以避免在确定变更范围之前被大文件内容干扰。Step 3读取 project 元数据并检查图谱新鲜度最关键的守卫步骤用 Grep 或限制行数的 Read 提取图谱中的project段把gitCommitHash记为GRAPH_COMMIT_RAW然后执行以下命令组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 -- .这条命令组里有几个容易做错、但技能文档明确强调的细节先 resolve 再使用GRAPH_COMMIT_RAW必须先通过git rev-parse --verify --end-of-options ${GRAPH_COMMIT_RAW}^{commit}解析为规范 commit 才能进入 diff。--end-of-options防止以-开头的异常输入被当作选项^{commit}强制要求它是一个 commit 对象。-- .pathspec 是必需的git diff $GRAPH_COMMIT HEAD -- .中结尾的-- .把 diff 限定在当前项目目录内。其动机是 monorepo 场景只改动了兄弟子项目的提交不应让本项目图谱被判为过期。文档原话A hash mismatch alone is not stale when the project diff is empty.——仅哈希不一致而项目内无 diff 时不算 stale。数据目录要排除所有命令输出中必须忽略.ua/或.understand-anything/因为它们存放的是生成的图谱产物不是项目源码漂移。源码中的新鲜度模块 staleness.ts 用 Git 的 pathspec 排除语法实现了同一语义const PROJECT_PATHSPEC [ --, ., :(exclude).understand-anything, :(exclude).understand-anything/**, :(exclude).ua, :(exclude).ua/**, ] as const;stale 时先警告再分析若 committed diff 或任何 working-tree 命令报告了项目文件必须在影响分析之前发出警告图谱可能缺失这些变更并建议运行/understand刷新图谱。元数据缺失不阻塞只在GRAPH_COMMIT_RAW解析成功时才执行 commit diff若图谱 commit 缺失、非法或不可用给出一条简短的 best-effort 警告后继续不中断整个分析流程。从源码结构看这套宽松但不含糊的判定逻辑与 getGraphFreshness 的实现一致新鲜度结果是一个四态判别联合——fresh无漂移、dirtycommit 相同但有工作区改动、stale带behind/ahead/diverged关系并有commitsBehind/commitsAhead计数、unknownGit 元数据不可读。源码注释特别指出Unknown is intentionally distinct from fresh: if Git metadata cannot be read, callers should warn softly rather than imply the graph is current.——unknown与fresh刻意区分Git 读不到时只能软警告绝不能暗示图谱是最新的。Step 4为每个变更文件定位图谱节点对每个变更文件路径用 Grep 在知识图谱中搜索匹配的filePath值grep changed/file/path $UA_DIR/knowledge-graph.json这一步同时命中两类节点文件级节点包括非代码类型如config:、document:前缀节点定义在该文件内的函数/类节点如function:path:name。把全部命中节点的id记录下来它们就是变更组件的集合。Step 5沿边做 1-hop 扩展找出受影响组件对每个命中的节点 IDGrep 边数组中 source 或 target 等于该 ID 的边区分两个方向上游调用者谁 import / depends on 了变更节点——这些组件可能需要同步更新下游依赖变更节点 import / calls 了什么——这些依赖的签名或行为变化会传导下去。两个方向合并即受影响组件也就是可能损坏或需要更新的部分。注意只扩展 1-hop不无限递归——这是技能刻意选择的精度与成本平衡点。Step 6识别受影响的架构层把 Step 4 命中的节点 ID 在layers段中检索确定哪些架构层被触碰。跨多个层出现的变更通常意味着需要额外关注层间契约如 API 变更波及 Service 层与数据层。Step 7输出结构化分析分析结果按四个板块组织Changed Components变更组件直接修改的内容附命中节点的 summaryAffected Components受影响组件来自 1-hop 边扩展Affected Layers受影响层触碰了哪些架构层、是否涉及跨层关注点Risk Assessment风险评估基于节点complexity值、跨层边数量与 blast radius受影响组件数量。最后给出应重点审查什么以及潜在问题的建议。风险判定不是拍脑袋diff-analyzer.ts 的 formatDiffAnalysis 给出了可复核的阈值变更节点中存在complexity complex→ 报High complexity受影响架构层数 1 → 报Cross-layer impact受影响组件数 5 → 报Wide blast radius存在未映射进图谱的文件 → 单独提示New/unmapped files可能需要重新分析以上条件均不满足 → 输出Low risk: Changes are localized with limited downstream impact.Step 8写出 diff overlay交给 Dashboard 可视化分析产出之后把 diff 数据写入$UA_DIR/diff-overlay.json供 Dashboard 高亮变更与受影响组件。文件结构为{ version: 1.0.0, baseBranch: the base branch used, generatedAt: ISO timestamp, changedFiles: [list of changed file paths], changedNodeIds: [node IDs from step 4], affectedNodeIds: [node IDs from step 5, excluding changedNodeIds] }写完后应提示用户可以运行/understand-anything:understand-dashboard可视化查看。Dashboard 端的消费逻辑可以在 App.tsx 中逐行印证启动时fetch(dataUrl(diff-overlay.json, accessToken))并对响应做严格形状校验——必须同时存在changedNodeIds与affectedNodeIds两个数组字段且changedNodeIds非空时才会调用 store.ts 中的setDiffOverlay(changed, affected)写入状态。UI 上由 DiffToggle.tsx 提供 Diff ON/OFF 开关开启后图例会按 changed / affected 两种颜色区分节点并在图例旁展示两类节点的计数没有 overlay 数据时按钮置灰不可点。这条链路解释了为什么affectedNodeIds要excluding changedNodeIds——两类集合在前端是分开着色、分开计数的重复 ID 会污染 affected 侧的统计。源码级实现对照buildDiffContext 与测试用例技能文档描述的是让 LLM 用 Grep 手动完成的流程而插件在 understand-anything-plugin/src/diff-analyzer.ts 中提供了同一套算法的程序化实现 buildDiffContext可作为流程正确性的参照实现文件到节点的映射遍历nodes凡node.filePath file即计入changedNodeIds未命中的文件进入unmappedFilescontains 子节点扩展对type contains且 source 是变更节点的边把 target文件内的函数/类节点也并入变更集合——对应 Step 4 中文件节点及其内部函数/类节点一并命中的语义1-hop 扩展遍历所有边source 或 target 在变更集合中的边记为impactedEdges另一端不在变更集合的节点记为 affected天然去重affected 与 changed 不相交层判定layers中nodeIds与变更 ∪ 受影响集合有交集的层即为受影响层。测试文件 diff-analyzer.test.ts 用一个五节点三层的迷你图谱把每条规则都钉住了改src/service.ts后断言变更集合包含文件节点与其contains子节点function:src/service.ts:processL43-L46断言 affected 通过calls/reads_from边扩展到file:src/routes.ts与file:src/db.tsL48-L52断言 affected 与 changed 无交集的去重不变量L76-L82断言未入图文件落入unmappedFiles且优雅降级L64-L68断言空 diff 不产生任何结果L70-L74。这些用例与 SKILL.md 的 Step 4–7 一一对应是验证自己手工 Grep 流程是否漏判的直接参照。适用前提与限制图谱必须先存在且可读$UA_DIR/knowledge-graph.json缺失时整个技能退化为提示先运行 /understand依赖 Git新鲜度检查、变更文件列表都来自 Git 命令在 Git 元数据不可用的仓库浅克隆、被剥离历史的检出等按 Step 3 的 best-effort 约定只应给出简短警告并继续不能把unknown当作fresh1-hop 是上限本技能刻意只扩展一层边二跳及以上的间接影响不会出现在 affected 集合中审查长依赖链时仍需人工沿边继续追踪未映射文件不在分析范围内新增文件若尚未被/understand收进图谱只会出现在unmapped提示中其真实影响需要刷新图谱后重跑monorepo 场景务必保留-- .pathspec 与数据目录排除否则会因兄弟项目提交或图谱产物文件的变动误判过期。综合来看/understand-diff把读 diff升级为在知识图谱上读 diffStep 3 的新鲜度守卫保证分析基准可信Step 4–6 的三次 Grep 检索把文件变更翻译成节点、边与层Step 7 按可复核的阈值给出风险分级Step 8 再把结果沉淀为 Dashboard 可渲染的 overlay。配合 understand-dashboard 技能启动的可视化界面一次变更审查从命令行一路贯通到图形化复盘。【免费下载链接】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），仅供参考