Dockerfile 如何被解析进知识图谱Understand-Anything 的 Dockerfile 语言提示片段全解【免费下载链接】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本文围绕 dockerfile.md 展开——这是 Understand-Anything 的/understand技能在分析容器化项目时注入给 LLM 的 Dockerfile 语言提示片段Prompt Snippet。文章将逐节解读片段中的核心概念、文件模式、边edge模式与摘要风格四部分设计并结合仓库源码说明系统如何识别 Dockerfile 文件、如何将片段注入分析流水线、以及 Dockerfile 最终在知识图谱中以何种节点与边形态呈现。读完你可以掌握该提示片段的完整内容与技术意图、它与 core 包语言配置之间的分工关系以及在实际项目中验证 Dockerfile 图谱产出的方法。一、dockerfile.md 的定位分析流水线中的语言上下文注入件Understand-Anything 通过/understand技能把代码库转化为knowledge-graph.json知识图谱整个流程分为 7 个 Phase。Dockerfile、YAML、SQL、Terraform 这类非代码语言虽然没有 AST 可解析但仍然需要被理解、被归类、被连成关系边。understand-anything-plugin/skills/understand/languages/目录下的 25 个 Markdown 片段dockerfile.md、yaml.md、sql.md、terraform.md等正是为此而设的语言上下文文件。注入时机在 SKILL.md 的 Phase 4ARCHITECTURE架构分层识别中明确规定对 Phase 1 检测到的每种语言例如python、markdown、dockerfile、yaml、sql、terraform……读取./languages/language-id.md例如./languages/dockerfile.md并将其内容追加到基础模板之后放在## Language Context标题下。若某语言没有对应文件则静默跳过。这些文件位于与本 SKILL.md 同级的languages/子目录中。必须包含非代码语言片段——它们为非代码文件提供边模式edge patterns与摘要风格summary styles。也就是说dockerfile.md不是给人看的文档而是给 LLM 看的行为规范它约束架构分析子代理architecture-analyzer在识别分层时如何理解 Dockerfile 文件的语义、如何为它连线、如何为它写摘要。二、片段内容逐节解读2.1 Key Concepts九大 Dockerfile 核心概念片段的第一节列出了 9 个概念它们共同构成 LLM 阅读 Dockerfile 时的知识背景概念原文要点多阶段构建Multi-Stage Builds多个FROM语句划分构建阶段与运行阶段用于缩小最终镜像体积层缓存Layer Caching每条指令生成一个层应按从最不变到最易变的顺序编排指令以提升缓存效率基础镜像Base ImagesFROM image:tag选择起始镜像优先选择 slim/alpine 变体以获得更小镜像COPY vs ADDCOPY用于本地文件首选ADD用于 URL 与 tar 包解压缩构建参数Build ArgumentsARG是构建期变量ENV是运行时环境变量健康检查Health ChecksHEALTHCHECK指令供容器编排器做就绪探测入口点与命令Entry Point vs CMDENTRYPOINT设置可执行体CMD提供默认参数用户权限User Permissions用USER指令以非 root 用户运行提升安全性忽略模式Ignore Patterns.dockerignore从构建上下文中排除文件类似.gitignore这些概念与 core 包中机器可读的语言配置互为补充。dockerfile.ts 中dockerfileConfig.concepts的取值是concepts: [multi-stage builds, layers, base images, COPY/ADD, EXPOSE, ENTRYPOINT, CMD, ARG, ENV],对照可见EXPOSE只出现在机器配置侧而HEALTHCHECK、USER、.dockerignore只出现在提示片段侧。从源码结构看两者的分工是机器配置侧的concepts服务于图谱节点的概念检测见 language-lesson.ts 的buildConceptPatterns它把配置中的 concepts 逐一转成关键词模式用于从节点的 tags/summary 中识别语言特有概念并生成languageLesson提示片段侧的 Key Concepts 则服务于架构分析时的语义理解。2.2 Notable File Patterns五类容器相关文件第二节枚举了项目中典型的容器化文件形态文件角色Dockerfile主容器镜像定义通常位于项目根目录Dockerfile.dev/Dockerfile.prod环境专属的 Dockerfile开发/生产docker-compose.yml多容器应用的编排定义docker-compose.override.yml本地开发环境覆盖配置.dockerignore构建上下文排除模式这份清单与 core 包的两份机器配置一一对应dockerfile.ts 的filenames为[Dockerfile, Dockerfile.dev, Dockerfile.prod, Dockerfile.test]——比提示片段多列了一个Dockerfile.testdocker-compose.ts 的filenames为[docker-compose.yml, docker-compose.yaml, compose.yml, compose.yaml]。值得注意docker-compose.override.yml并不在docker-compose.ts的filenames白名单中。从源码结构看可以推断它依赖.yml扩展名回退到yaml语言识别从而进入扫描流程而非以docker-compose语言 ID 出现。2.3 Edge Patterns容器文件如何连线第三节是片段中最具图谱特色的部分——它直接规定了容器化文件之间应产生的关系边Dockerfiledeploys它打包的应用入口点即COPY/CMD的目标docker-composedepends_on它引用以构建镜像的 DockerfileDockerfiledepends_on它拷贝进来的包清单文件如package.json、requirements.txt用于安装依赖docker-compose中共同部署的各 service 之间创建related边。这四条边恰好落在/understand图谱 Schema 定义的 26 种边类型之中见 SKILL.md 的 Edge Types 与 Edge Weight Conventions 表边类型Schema 分类约定权重对应片段中的场景deploysInfrastructure基础设施0.7Dockerfile → 它打包的入口文件depends_onDependencies依赖0.6compose → DockerfileDockerfile → 包清单relatedSemantic语义0.5默认compose 内共同部署的服务之间这段设计解释了知识图谱里基础设施如何被理解Dockerfile 不再是一个孤立的配置文件节点而是通过deploys边指向被打包的应用代码、通过depends_on边挂到依赖清单、通过 compose 的related边把并行的服务关联起来形成完整的部署语义网络。2.4 Summary Style摘要风格模板第四节给出三条示例摘要指导 LLM 为容器文件生成的summary字段保持信息密度与结构一致性Multi-stage Docker build producing a minimal Node.js production image with N build stages.Docker Compose configuration orchestrating N services with shared networking and persistent volumes.Development Dockerfile with hot-reload support and mounted source volumes.三条样例分别覆盖多阶段生产镜像、多服务编排、开发镜像三种典型形态均以定性短语 关键数量/特性的结构呈现。配合/understand --language zh等语言指令见 SKILL.md这些摘要会按目标语言本地化但建议保持技术术语无标准译名时保留英文的约定。三、Dockerfile 文件如何被识别三层检测机制提示片段要发挥作用前提是 Phase 1 扫描时该文件被正确识别为dockerfile语言。源码中共有三层机制保证这一点。3.1 脚本层scan-project.mjs 的语言与分类检测扫描脚本 scan-project.mjs 的detectLanguage()函数采用扩展名小写匹配 文件名大小写敏感匹配的双路策略。注释明确说明文件名Dockerfile、Makefile 等按大小写敏感方式匹配因为实际项目普遍使用规范的大写拼写。Dockerfile 的识别不依赖Dockerfile→dockerfile的静态映射表该表仅收录精确文件名而是在函数开头直接短路处理变体形式// Dockerfile.dev, Dockerfile.prod, etc. — common variant form. if (base Dockerfile || base.startsWith(Dockerfile.)) return dockerfile;一行startsWith检查覆盖了任意后缀的变体Dockerfile.dev、Dockerfile.prod、Dockerfile.test……无需在映射表中逐一枚举。分类路由scan-project.mjs 的 Rule 2infra by filename同样使用相同的判断if (base Dockerfile || base.startsWith(Dockerfile.)) return infra;因此 Dockerfile 在scan-result.json中的fileCategory为infra与文档、配置、代码区分开为后续分层与摘要提供元数据。3.2 注册表层LanguageRegistry 的文件名优先查找core 包的 LanguageRegistry 按id、extension、filename三个索引维护语言配置。getForFile()的查找顺序刻意先文件名、后扩展名注释写明原因文件名查找更具体docker-compose.yml、Makefile 等getForFile(filePath: string): LanguageConfig | null { // Try filename-based lookup first (more specific: docker-compose.yml, Makefile, etc.) const basename filePath.split(/).pop() ?? filePath; const filenameMatch this.byFilename.get(basename.toLowerCase()); if (filenameMatch) return filenameMatch; // Fall back to extension-based lookup ... }这与 Dockerfile 配置的形态完全契合dockerfileConfig.extensions是空数组[]只靠filenames白名单命中而docker-compose虽然带.yml扩展名也走文件名分支优先避免与泛化yaml配置混淆。配置合法性由 types.ts 的StrictLanguageConfigSchema校验——至少必须提供扩展名或文件名之一才能被注册表检测Dockerfile 恰好满足文件名非空这一条件。3.3 配置层dockerfileConfig 的完整字段完整配置见 dockerfile.tsexport const dockerfileConfig { id: dockerfile, displayName: Dockerfile, extensions: [], filenames: [Dockerfile, Dockerfile.dev, Dockerfile.prod, Dockerfile.test], concepts: [multi-stage builds, layers, base images, COPY/ADD, EXPOSE, ENTRYPOINT, CMD, ARG, ENV], filePatterns: { entryPoints: [Dockerfile], barrels: [], tests: [], config: [], }, } satisfies LanguageConfig;该配置由 configs/index.ts 纳入builtinLanguageConfigs非代码语言段经LanguageRegistry.createDefault()预注册。filePatterns.entryPoints: [Dockerfile]声明了根Dockerfile在该语言的入口点地位——在分层分析中入口点文件通常是层级归属的强证据。四、Dockerfile 在知识图谱中的最终形态综合以上机制一个含Dockerfile与docker-compose.yml的项目其.ua/knowledge-graph.json中的典型产出为节点类型。按 SKILL.md 的 Node Types 表共 13 类Deployable service definition (Dockerfile, K8s) 对应service类型ID 约定为service:relative-path。分层归一化逻辑同样将service:列为合法的节点 ID 前缀与file:、config:、document:、pipeline:等并列因此 Dockerfile 节点可以进入layers.json的nodeIds。摘要与概念。节点summary按片段 Summary Style 一节生成如多阶段构建产出最小化 Node.js 生产镜像共 N 个构建阶段languageNotes/languageLesson则可能基于 2.1 节的概念检测结果生成其中EXPOSE、layers等仅存在于机器配置侧的概念会参与该检测。关系边。按 2.3 节 Edge Patterns 产出deploys权重 0.7、depends_on权重 0.6、related权重 0.5三类边使 Dockerfile 节点与打包目标、依赖清单、编排服务之间形成连通子图。五、实战验证在含 Dockerfile 的项目中观察全流程适用前提项目已安装 Understand-Anything 插件Node.js ≥ 22、pnpm ≥ 10且仓库中存在Dockerfile或其变体。步骤如下触发分析。在项目中运行/understand可选--language zh以中文生成全部文本内容。若只想重跑架构分析而非全量重建可配合--full强制全量或依赖 commit hash 的增量判断。检查扫描结果。Phase 1 结束后查看$UA_DIR/intermediate/scan-result.json$UA_DIR为项目根的.ua/或已存在时的旧版.understand-anything/。Dockerfile条目应呈现language: dockerfile、fileCategory: infraDockerfile.dev等变体同样命中dockerfile。检查最终图谱。分析完成后查看$UA_DIR/knowledge-graph.jsonnodes中查找type: service且filePath指向 Dockerfile 的节点其summary风格应符合 2.4 节样例edges中查找该节点的deploys/depends_on出边以及 compose 服务间的related边layers中确认该节点被归入某层例如基础设施/部署层。增量更新。修改 Dockerfile 后再次运行/understand变更文件列表git diff lastCommitHash..HEAD --name-only会包含该 Dockerfile仅重新分析受影响批次——这是验证depends_on 包清单这类边随COPY指令变化而更新的便捷方式。一个边界提示语言片段仅在 Phase 1 检测到对应语言时于 Phase 4 注入若某次分析因--exclude模式或.understandignore规则把Dockerfile排除在扫描之外则dockerfile.md片段不会被加载图谱中也不会有service节点与deploys边。排查此类缺边问题时应先回到scan-result.json确认文件是否被扫描到。小结dockerfile.md 虽然只有 30 余行却完整承担了三重职责以 Key Concepts 赋予 LLM 阅读 Dockerfile 的领域知识、以 Notable File Patterns 圈定分析对象、以 Edge Patterns 和 Summary Style 规定图谱产出的形态。它与 core 包的 dockerfile.ts / docker-compose.ts 机器配置、scan-project.mjs 的检测逻辑、LanguageRegistry 的文件名优先查找共同构成了一条从磁盘上的 Dockerfile 文件到知识图谱中的 service 节点与 deploys 边的完整链路——这也是 Understand-Anything 能把非代码基础设施文件纳入会教人的图谱的关键设计。【免费下载链接】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），仅供参考 Dockerfile 如何被解析进知识图谱：Understand-Anything 的 Dockerfile 语言提示片段全解
Dockerfile 如何被解析进知识图谱Understand-Anything 的 Dockerfile 语言提示片段全解【免费下载链接】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本文围绕 dockerfile.md 展开——这是 Understand-Anything 的/understand技能在分析容器化项目时注入给 LLM 的 Dockerfile 语言提示片段Prompt Snippet。文章将逐节解读片段中的核心概念、文件模式、边edge模式与摘要风格四部分设计并结合仓库源码说明系统如何识别 Dockerfile 文件、如何将片段注入分析流水线、以及 Dockerfile 最终在知识图谱中以何种节点与边形态呈现。读完你可以掌握该提示片段的完整内容与技术意图、它与 core 包语言配置之间的分工关系以及在实际项目中验证 Dockerfile 图谱产出的方法。一、dockerfile.md 的定位分析流水线中的语言上下文注入件Understand-Anything 通过/understand技能把代码库转化为knowledge-graph.json知识图谱整个流程分为 7 个 Phase。Dockerfile、YAML、SQL、Terraform 这类非代码语言虽然没有 AST 可解析但仍然需要被理解、被归类、被连成关系边。understand-anything-plugin/skills/understand/languages/目录下的 25 个 Markdown 片段dockerfile.md、yaml.md、sql.md、terraform.md等正是为此而设的语言上下文文件。注入时机在 SKILL.md 的 Phase 4ARCHITECTURE架构分层识别中明确规定对 Phase 1 检测到的每种语言例如python、markdown、dockerfile、yaml、sql、terraform……读取./languages/language-id.md例如./languages/dockerfile.md并将其内容追加到基础模板之后放在## Language Context标题下。若某语言没有对应文件则静默跳过。这些文件位于与本 SKILL.md 同级的languages/子目录中。必须包含非代码语言片段——它们为非代码文件提供边模式edge patterns与摘要风格summary styles。也就是说dockerfile.md不是给人看的文档而是给 LLM 看的行为规范它约束架构分析子代理architecture-analyzer在识别分层时如何理解 Dockerfile 文件的语义、如何为它连线、如何为它写摘要。二、片段内容逐节解读2.1 Key Concepts九大 Dockerfile 核心概念片段的第一节列出了 9 个概念它们共同构成 LLM 阅读 Dockerfile 时的知识背景概念原文要点多阶段构建Multi-Stage Builds多个FROM语句划分构建阶段与运行阶段用于缩小最终镜像体积层缓存Layer Caching每条指令生成一个层应按从最不变到最易变的顺序编排指令以提升缓存效率基础镜像Base ImagesFROM image:tag选择起始镜像优先选择 slim/alpine 变体以获得更小镜像COPY vs ADDCOPY用于本地文件首选ADD用于 URL 与 tar 包解压缩构建参数Build ArgumentsARG是构建期变量ENV是运行时环境变量健康检查Health ChecksHEALTHCHECK指令供容器编排器做就绪探测入口点与命令Entry Point vs CMDENTRYPOINT设置可执行体CMD提供默认参数用户权限User Permissions用USER指令以非 root 用户运行提升安全性忽略模式Ignore Patterns.dockerignore从构建上下文中排除文件类似.gitignore这些概念与 core 包中机器可读的语言配置互为补充。dockerfile.ts 中dockerfileConfig.concepts的取值是concepts: [multi-stage builds, layers, base images, COPY/ADD, EXPOSE, ENTRYPOINT, CMD, ARG, ENV],对照可见EXPOSE只出现在机器配置侧而HEALTHCHECK、USER、.dockerignore只出现在提示片段侧。从源码结构看两者的分工是机器配置侧的concepts服务于图谱节点的概念检测见 language-lesson.ts 的buildConceptPatterns它把配置中的 concepts 逐一转成关键词模式用于从节点的 tags/summary 中识别语言特有概念并生成languageLesson提示片段侧的 Key Concepts 则服务于架构分析时的语义理解。2.2 Notable File Patterns五类容器相关文件第二节枚举了项目中典型的容器化文件形态文件角色Dockerfile主容器镜像定义通常位于项目根目录Dockerfile.dev/Dockerfile.prod环境专属的 Dockerfile开发/生产docker-compose.yml多容器应用的编排定义docker-compose.override.yml本地开发环境覆盖配置.dockerignore构建上下文排除模式这份清单与 core 包的两份机器配置一一对应dockerfile.ts 的filenames为[Dockerfile, Dockerfile.dev, Dockerfile.prod, Dockerfile.test]——比提示片段多列了一个Dockerfile.testdocker-compose.ts 的filenames为[docker-compose.yml, docker-compose.yaml, compose.yml, compose.yaml]。值得注意docker-compose.override.yml并不在docker-compose.ts的filenames白名单中。从源码结构看可以推断它依赖.yml扩展名回退到yaml语言识别从而进入扫描流程而非以docker-compose语言 ID 出现。2.3 Edge Patterns容器文件如何连线第三节是片段中最具图谱特色的部分——它直接规定了容器化文件之间应产生的关系边Dockerfiledeploys它打包的应用入口点即COPY/CMD的目标docker-composedepends_on它引用以构建镜像的 DockerfileDockerfiledepends_on它拷贝进来的包清单文件如package.json、requirements.txt用于安装依赖docker-compose中共同部署的各 service 之间创建related边。这四条边恰好落在/understand图谱 Schema 定义的 26 种边类型之中见 SKILL.md 的 Edge Types 与 Edge Weight Conventions 表边类型Schema 分类约定权重对应片段中的场景deploysInfrastructure基础设施0.7Dockerfile → 它打包的入口文件depends_onDependencies依赖0.6compose → DockerfileDockerfile → 包清单relatedSemantic语义0.5默认compose 内共同部署的服务之间这段设计解释了知识图谱里基础设施如何被理解Dockerfile 不再是一个孤立的配置文件节点而是通过deploys边指向被打包的应用代码、通过depends_on边挂到依赖清单、通过 compose 的related边把并行的服务关联起来形成完整的部署语义网络。2.4 Summary Style摘要风格模板第四节给出三条示例摘要指导 LLM 为容器文件生成的summary字段保持信息密度与结构一致性Multi-stage Docker build producing a minimal Node.js production image with N build stages.Docker Compose configuration orchestrating N services with shared networking and persistent volumes.Development Dockerfile with hot-reload support and mounted source volumes.三条样例分别覆盖多阶段生产镜像、多服务编排、开发镜像三种典型形态均以定性短语 关键数量/特性的结构呈现。配合/understand --language zh等语言指令见 SKILL.md这些摘要会按目标语言本地化但建议保持技术术语无标准译名时保留英文的约定。三、Dockerfile 文件如何被识别三层检测机制提示片段要发挥作用前提是 Phase 1 扫描时该文件被正确识别为dockerfile语言。源码中共有三层机制保证这一点。3.1 脚本层scan-project.mjs 的语言与分类检测扫描脚本 scan-project.mjs 的detectLanguage()函数采用扩展名小写匹配 文件名大小写敏感匹配的双路策略。注释明确说明文件名Dockerfile、Makefile 等按大小写敏感方式匹配因为实际项目普遍使用规范的大写拼写。Dockerfile 的识别不依赖Dockerfile→dockerfile的静态映射表该表仅收录精确文件名而是在函数开头直接短路处理变体形式// Dockerfile.dev, Dockerfile.prod, etc. — common variant form. if (base Dockerfile || base.startsWith(Dockerfile.)) return dockerfile;一行startsWith检查覆盖了任意后缀的变体Dockerfile.dev、Dockerfile.prod、Dockerfile.test……无需在映射表中逐一枚举。分类路由scan-project.mjs 的 Rule 2infra by filename同样使用相同的判断if (base Dockerfile || base.startsWith(Dockerfile.)) return infra;因此 Dockerfile 在scan-result.json中的fileCategory为infra与文档、配置、代码区分开为后续分层与摘要提供元数据。3.2 注册表层LanguageRegistry 的文件名优先查找core 包的 LanguageRegistry 按id、extension、filename三个索引维护语言配置。getForFile()的查找顺序刻意先文件名、后扩展名注释写明原因文件名查找更具体docker-compose.yml、Makefile 等getForFile(filePath: string): LanguageConfig | null { // Try filename-based lookup first (more specific: docker-compose.yml, Makefile, etc.) const basename filePath.split(/).pop() ?? filePath; const filenameMatch this.byFilename.get(basename.toLowerCase()); if (filenameMatch) return filenameMatch; // Fall back to extension-based lookup ... }这与 Dockerfile 配置的形态完全契合dockerfileConfig.extensions是空数组[]只靠filenames白名单命中而docker-compose虽然带.yml扩展名也走文件名分支优先避免与泛化yaml配置混淆。配置合法性由 types.ts 的StrictLanguageConfigSchema校验——至少必须提供扩展名或文件名之一才能被注册表检测Dockerfile 恰好满足文件名非空这一条件。3.3 配置层dockerfileConfig 的完整字段完整配置见 dockerfile.tsexport const dockerfileConfig { id: dockerfile, displayName: Dockerfile, extensions: [], filenames: [Dockerfile, Dockerfile.dev, Dockerfile.prod, Dockerfile.test], concepts: [multi-stage builds, layers, base images, COPY/ADD, EXPOSE, ENTRYPOINT, CMD, ARG, ENV], filePatterns: { entryPoints: [Dockerfile], barrels: [], tests: [], config: [], }, } satisfies LanguageConfig;该配置由 configs/index.ts 纳入builtinLanguageConfigs非代码语言段经LanguageRegistry.createDefault()预注册。filePatterns.entryPoints: [Dockerfile]声明了根Dockerfile在该语言的入口点地位——在分层分析中入口点文件通常是层级归属的强证据。四、Dockerfile 在知识图谱中的最终形态综合以上机制一个含Dockerfile与docker-compose.yml的项目其.ua/knowledge-graph.json中的典型产出为节点类型。按 SKILL.md 的 Node Types 表共 13 类Deployable service definition (Dockerfile, K8s) 对应service类型ID 约定为service:relative-path。分层归一化逻辑同样将service:列为合法的节点 ID 前缀与file:、config:、document:、pipeline:等并列因此 Dockerfile 节点可以进入layers.json的nodeIds。摘要与概念。节点summary按片段 Summary Style 一节生成如多阶段构建产出最小化 Node.js 生产镜像共 N 个构建阶段languageNotes/languageLesson则可能基于 2.1 节的概念检测结果生成其中EXPOSE、layers等仅存在于机器配置侧的概念会参与该检测。关系边。按 2.3 节 Edge Patterns 产出deploys权重 0.7、depends_on权重 0.6、related权重 0.5三类边使 Dockerfile 节点与打包目标、依赖清单、编排服务之间形成连通子图。五、实战验证在含 Dockerfile 的项目中观察全流程适用前提项目已安装 Understand-Anything 插件Node.js ≥ 22、pnpm ≥ 10且仓库中存在Dockerfile或其变体。步骤如下触发分析。在项目中运行/understand可选--language zh以中文生成全部文本内容。若只想重跑架构分析而非全量重建可配合--full强制全量或依赖 commit hash 的增量判断。检查扫描结果。Phase 1 结束后查看$UA_DIR/intermediate/scan-result.json$UA_DIR为项目根的.ua/或已存在时的旧版.understand-anything/。Dockerfile条目应呈现language: dockerfile、fileCategory: infraDockerfile.dev等变体同样命中dockerfile。检查最终图谱。分析完成后查看$UA_DIR/knowledge-graph.jsonnodes中查找type: service且filePath指向 Dockerfile 的节点其summary风格应符合 2.4 节样例edges中查找该节点的deploys/depends_on出边以及 compose 服务间的related边layers中确认该节点被归入某层例如基础设施/部署层。增量更新。修改 Dockerfile 后再次运行/understand变更文件列表git diff lastCommitHash..HEAD --name-only会包含该 Dockerfile仅重新分析受影响批次——这是验证depends_on 包清单这类边随COPY指令变化而更新的便捷方式。一个边界提示语言片段仅在 Phase 1 检测到对应语言时于 Phase 4 注入若某次分析因--exclude模式或.understandignore规则把Dockerfile排除在扫描之外则dockerfile.md片段不会被加载图谱中也不会有service节点与deploys边。排查此类缺边问题时应先回到scan-result.json确认文件是否被扫描到。小结dockerfile.md 虽然只有 30 余行却完整承担了三重职责以 Key Concepts 赋予 LLM 阅读 Dockerfile 的领域知识、以 Notable File Patterns 圈定分析对象、以 Edge Patterns 和 Summary Style 规定图谱产出的形态。它与 core 包的 dockerfile.ts / docker-compose.ts 机器配置、scan-project.mjs 的检测逻辑、LanguageRegistry 的文件名优先查找共同构成了一条从磁盘上的 Dockerfile 文件到知识图谱中的 service 节点与 deploys 边的完整链路——这也是 Understand-Anything 能把非代码基础设施文件纳入会教人的图谱的关键设计。【免费下载链接】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），仅供参考