尧图网站建设 
Understand-Anything 中的 Terraform 语言提示片段让 LLM 看懂 IaC 代码并生成知识图谱【免费下载链接】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-AnythingUnderstand-Anything 是一个把代码库转化为交互式知识图谱的工具它通过 LLM 子代理逐批分析文件产出knowledge-graph.json供仪表盘浏览。对于基础设施即代码IaC仓库而言Terraform 配置文件的理解质量直接决定了图谱中资源、变量与模块之间关系是否正确。本文基于 Terraform 语言提示片段下称提示片段展开完整覆盖其核心概念、文件模式、边模式与摘要风格四大板块并结合仓库源码说明这些片段是如何被注入 LLM 提示词、以及其中的边类型如何被图谱 schema 校验的。读完本文你将掌握Terraform 在 Understand-Anything 流水线中的定位语言 ID、文件扩展名、节点类型、提示片段四个板块的完整内容与用途以及provisions、depends_on、deploys、configures等 Terraform 专属边类型在 边类型 schema 中的定义与别名归一化机制。提示片段在 /understand 流水线中的位置Terraform 提示片段并不是一份独立的用户文档而是/understand技能执行 Phase 4ARCHITECTURE识别架构分层阶段注入给architecture-analyzer子代理的上下文素材。根据 SKILL.md 的说明Language context injection: For each language detected in Phase 1 (e.g.,python,markdown, …,terraform, …), read the file at./languages/language-id.md… and append its content after the base template under a## Language Contextheader. If the file does not exist for a detected language, skip it silently.即Phase 1 扫描项目时若检测到 Terraform 语言语言 ID 为terraform技能会自动读取与本SKILL.md同目录下的languages/terraform.md将其全文追加到架构分析器提示词的## Language Context标题之下。值得注意的是SKILL.md 明确要求Include non-code language snippets — they provide edge patterns and summary styles for non-code files——Terraform 属于典型的非代码语言这类片段的核心价值就是提供边模式Edge Patterns和摘要风格Summary Style弥补 LLM 对.tf文件语义关系的判断能力。语言 ID 是如何被检测到的提示片段的加载依赖语言 ID 与文件名一一对应terraform.md↔ IDterraform。这一 ID 由 语言注册表配置 定义export const terraformConfig { id: terraform, displayName: Terraform, extensions: [.tf, .tfvars], concepts: [resources, data sources, variables, outputs, modules, providers, state, workspaces], filePatterns: { entryPoints: [main.tf], barrels: [], tests: [], config: [terraform.tfvars, variables.tf], }, } satisfies LanguageConfig;从源码结构看该配置完成了三件事扩展名识别.tf与.tfvars是 Terraform 的判定依据对应 StrictLanguageConfigSchema 中至少一个扩展名或文件名的必填约束概念词表concepts字段列出了 resources、data sources、variables、outputs、modules、providers、state、workspaces 八个概念——与提示片段Key Concepts板块高度呼应二者共同构成 LLM 分析 Terraform 文件时的领域知识底料文件模式约定main.tf被登记为入口点entryPointvariables.tf与terraform.tfvars被登记为配置文件config。这与提示片段File Patterns板块中main.tf的地位一致可推断在架构分层时main.tf更容易被识别为基础设施层的锚点文件。配套的 扫描脚本 顶部注释也声明其语言清单与packages/core/src/languages/configs/*保持同步保证 Phase 1 扫描与 Phase 4 语言上下文注入使用同一套语言 ID。Key Concepts提示片段如何教 LLM 理解 Terraform提示片段的第一板块Key Concepts以 10 条要点概括了 Terraform 的领域模型。完整继承如下每条概念都会在架构分析时作为提示词的一部分直接参与 LLM 推理概念要点原文语义Declarative Infrastructure声明式基础设施定义期望状态Terraform 计算并应用 diffProviders连接云 APIAWS、GCP、Azure、Kubernetes 等的插件Resourcesresource type name块声明基础设施组件Data Sourcesdata type name块读取已有基础设施状态Variablesvariable块用默认值与校验来参数化配置Outputsoutput块暴露值供跨模块引用或人工消费Modules可复用、可组合的基础设施包自带 variables 与 outputsState Management.tfstate文件跟踪真实资源映射切勿提交到 gitWorkspaces隔离的状态环境从同一份代码管理 dev/staging/prodPlan and Applyterraform plan预览变更terraform apply执行变更这 10 条概念与语言注册表配置中的concepts数组互为补充注册表提供压缩版词表用于机器检测提示片段提供面向 LLM 的完整语义描述。其中State Management条目明确提示.tfstate不应提交 git——这意味着在真实分析场景中若.understandignore或--exclude排除了状态目录图谱就不会把状态文件误识别为资源节点。Notable File Patterns约定俗成的文件名约定第二板块列出了 Terraform 项目的标准文件布局LLM 依据这些约定判断每个.tf文件的角色main.tf— 主资源定义variables.tf— 输入变量声明含类型与默认值outputs.tf— 输出值定义providers.tf— Provider 配置与版本约束backend.tf— 远程状态后端配置S3、GCS 等modules/**/*.tf— 可复用基础设施模块*.tfvars— 面向不同环境的变量值文件terraform.lock.hcl— Provider 版本锁文件这份清单与核心包配置形成交叉印证filePatterns.entryPoints登记了main.tffilePatterns.config登记了variables.tf配置清单中的terraform.tfvars也覆盖.tfvars家族。可以推断当架构分析器处理一个典型的infra/目录时main.tf会因入口身份获得更高的层级判定权重而variables.tf/outputs.tf则会被归为参数化辅助文件这与提示片段中Variables/Outputs概念板块的分工描述是一致的。Edge PatternsTerraform 文件之间的四类关系边第三板块Edge Patterns是整份提示片段中技术密度最高的部分——它直接规定 Terraform 文件之间应当产生哪四种语义边Terraform 文件provisions其自身定义的基础设施资源模块引用在 Terraform 文件之间创建depends_on边Terraform 通过引用容器镜像或部署目标来deploys应用代码变量文件configures它所参数化的 Terraform 模块。这四条边类型并非凭空约定它们在核心 schema 中都有正式定义。schema.ts 的EdgeTypeSchema将边类型分为若干组其中基础设施组为deploys, serves, provisions, triggers, // Infrastructure依赖组中则包含depends_on、configures见 types.ts 中EdgeType的同一分组注释。此外 schema 还内置了一套别名归一化表把 LLM 可能生成的近义边类型自动改写为标准值例如creates→provisionsuses/requires→depends_ondescribes→documents、exposes→servesSchema 测试 中的两个用例锁定了这一行为一个用例验证deploys、serves、migrates、documents、provisions、routes、defines_schema、triggers全部通过校验另一个用例验证creates: provisions等别名会被自动纠正。这保证了即使 LLM 在分析 Terraform 文件时写出creates而非provisions合并进assembled-graph.json的边仍然会落到标准类型上。边在 file-analyzer 中的落地位置值得说明的是Edge Patterns板块的受众与Language Context注入并不完全重合。Phase 2 中真正逐文件产出节点的 file-analyzer 代理 自带一套完整的边类型表其中与 Terraform 直接相关的定义包括节点类型*.tf、*.tfvars等非代码基础设施文件被归类为resource节点fileCategory 为infra这是provisions边的源端节点边类型configures配置/变量文件作用于模块权重 0.6、deploys基础设施文件构建/部署代码权重 0.7、depends_on运行时依赖权重 0.6标签约定*.tf文件被赋予infrastructure、deployment标签。提示片段中的 Edge Patterns 板块正是对这些通用规则在 Terraform 语境下的具象化它告诉 LLM模块引用 →depends_on、变量文件 →configures模块把抽象的边类型表映射到.tf文件的具体场景上。两个来源叠加构成了 Terraform 文件从节点分类、标签、到关系边的完整判定链。Summary Style三段式摘要模板第四板块Summary Style给出了 Terraform 文件节点摘要summary 字段的三个示范句式要求摘要遵循用途 数量 具体资源的写法Terraform configuration provisioning N AWS resources including VPC, ECS cluster, and RDS instance.Infrastructure module defining a reusable Kubernetes namespace with RBAC and network policies.Variable definitions for N environment-specific settings (region, instance type, scaling).这三条示例恰好对应了文件模式的三种典型角色main.tf式的资源定义文件第一句呼应provisions边、modules/**/*.tf式的模块文件第二句呼应Modules概念、*.tfvars式的变量定义第三句呼应configures边。file-analyzer 对 Infra 文件的通用要求是Describe what gets deployed/built而这里的模板进一步把要求收窄到provisioning N 个 X 云资源包括…——数量与具体资源名的组合使得摘要在仪表盘ProjectOverview或节点信息面板中具备可直接检索的信息量。从注入到成图一份 .tf 文件走过的完整链路把前述各环串联起来一份 Terraform 文件在 Understand-Anything 中的处理链路如下各环节均有仓库内对应物可按路径查阅扫描scan-project.mjs 依据语言注册表含 terraform.ts识别.tf/.tfvars为terraform语言产出fileCategory: infra的文件清单与scan-result.json分批compute-batches.mjs生成batches.jsonTerraform 文件按其所在批次分派给 file-analyzer 子代理分析file-analyzer 按 代理定义 为每个.tf文件创建resource:节点按权重表产出provisions/configures/depends_on/deploys边合并merge-batch-graphs.py归一化节点 ID 与复杂度、去重并丢弃悬空边边类型则经由 schema.ts 的别名表完成最后兜底如creates→provisions架构分层Phase 4 的 architecture-analyzer 在提示词中注入本提示片段全文## Language Context据此把 Terraform 文件归入基础设施层并写出符合 Summary Style 的摘要成图最终汇入$UA_DIR/knowledge-graph.json在 dashboard 中呈现为可搜索、可导航的交互图谱。小结Terraform 语言提示片段 的篇幅不长但四个板块各司其职Key Concepts 提供领域语义File Patterns 提供文件名到角色的映射Edge Patterns 规定provisions/depends_on/deploys/configures四类关系边Summary Style 约束节点摘要的句式与信息密度。它的生效机制则由 SKILL.md 的 Phase 4 语言上下文注入驱动并由 核心语言注册表、边类型 schema 及其 测试用例 在机器层面完成校验与归一化。对以 Terraform 管理基础设施的团队而言理解这套片段机制意味着你看到的每一个resource:节点与每一条 IaC 关系边背后都有明确的检测规则、提示词依据和 schema 兜底而非 LLM 的自由发挥。【免费下载链接】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 中的 Terraform 语言提示片段：让 LLM 看懂 IaC 代码并生成知识图谱
Understand-Anything 中的 Terraform 语言提示片段让 LLM 看懂 IaC 代码并生成知识图谱【免费下载链接】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-AnythingUnderstand-Anything 是一个把代码库转化为交互式知识图谱的工具它通过 LLM 子代理逐批分析文件产出knowledge-graph.json供仪表盘浏览。对于基础设施即代码IaC仓库而言Terraform 配置文件的理解质量直接决定了图谱中资源、变量与模块之间关系是否正确。本文基于 Terraform 语言提示片段下称提示片段展开完整覆盖其核心概念、文件模式、边模式与摘要风格四大板块并结合仓库源码说明这些片段是如何被注入 LLM 提示词、以及其中的边类型如何被图谱 schema 校验的。读完本文你将掌握Terraform 在 Understand-Anything 流水线中的定位语言 ID、文件扩展名、节点类型、提示片段四个板块的完整内容与用途以及provisions、depends_on、deploys、configures等 Terraform 专属边类型在 边类型 schema 中的定义与别名归一化机制。提示片段在 /understand 流水线中的位置Terraform 提示片段并不是一份独立的用户文档而是/understand技能执行 Phase 4ARCHITECTURE识别架构分层阶段注入给architecture-analyzer子代理的上下文素材。根据 SKILL.md 的说明Language context injection: For each language detected in Phase 1 (e.g.,python,markdown, …,terraform, …), read the file at./languages/language-id.md… and append its content after the base template under a## Language Contextheader. If the file does not exist for a detected language, skip it silently.即Phase 1 扫描项目时若检测到 Terraform 语言语言 ID 为terraform技能会自动读取与本SKILL.md同目录下的languages/terraform.md将其全文追加到架构分析器提示词的## Language Context标题之下。值得注意的是SKILL.md 明确要求Include non-code language snippets — they provide edge patterns and summary styles for non-code files——Terraform 属于典型的非代码语言这类片段的核心价值就是提供边模式Edge Patterns和摘要风格Summary Style弥补 LLM 对.tf文件语义关系的判断能力。语言 ID 是如何被检测到的提示片段的加载依赖语言 ID 与文件名一一对应terraform.md↔ IDterraform。这一 ID 由 语言注册表配置 定义export const terraformConfig { id: terraform, displayName: Terraform, extensions: [.tf, .tfvars], concepts: [resources, data sources, variables, outputs, modules, providers, state, workspaces], filePatterns: { entryPoints: [main.tf], barrels: [], tests: [], config: [terraform.tfvars, variables.tf], }, } satisfies LanguageConfig;从源码结构看该配置完成了三件事扩展名识别.tf与.tfvars是 Terraform 的判定依据对应 StrictLanguageConfigSchema 中至少一个扩展名或文件名的必填约束概念词表concepts字段列出了 resources、data sources、variables、outputs、modules、providers、state、workspaces 八个概念——与提示片段Key Concepts板块高度呼应二者共同构成 LLM 分析 Terraform 文件时的领域知识底料文件模式约定main.tf被登记为入口点entryPointvariables.tf与terraform.tfvars被登记为配置文件config。这与提示片段File Patterns板块中main.tf的地位一致可推断在架构分层时main.tf更容易被识别为基础设施层的锚点文件。配套的 扫描脚本 顶部注释也声明其语言清单与packages/core/src/languages/configs/*保持同步保证 Phase 1 扫描与 Phase 4 语言上下文注入使用同一套语言 ID。Key Concepts提示片段如何教 LLM 理解 Terraform提示片段的第一板块Key Concepts以 10 条要点概括了 Terraform 的领域模型。完整继承如下每条概念都会在架构分析时作为提示词的一部分直接参与 LLM 推理概念要点原文语义Declarative Infrastructure声明式基础设施定义期望状态Terraform 计算并应用 diffProviders连接云 APIAWS、GCP、Azure、Kubernetes 等的插件Resourcesresource type name块声明基础设施组件Data Sourcesdata type name块读取已有基础设施状态Variablesvariable块用默认值与校验来参数化配置Outputsoutput块暴露值供跨模块引用或人工消费Modules可复用、可组合的基础设施包自带 variables 与 outputsState Management.tfstate文件跟踪真实资源映射切勿提交到 gitWorkspaces隔离的状态环境从同一份代码管理 dev/staging/prodPlan and Applyterraform plan预览变更terraform apply执行变更这 10 条概念与语言注册表配置中的concepts数组互为补充注册表提供压缩版词表用于机器检测提示片段提供面向 LLM 的完整语义描述。其中State Management条目明确提示.tfstate不应提交 git——这意味着在真实分析场景中若.understandignore或--exclude排除了状态目录图谱就不会把状态文件误识别为资源节点。Notable File Patterns约定俗成的文件名约定第二板块列出了 Terraform 项目的标准文件布局LLM 依据这些约定判断每个.tf文件的角色main.tf— 主资源定义variables.tf— 输入变量声明含类型与默认值outputs.tf— 输出值定义providers.tf— Provider 配置与版本约束backend.tf— 远程状态后端配置S3、GCS 等modules/**/*.tf— 可复用基础设施模块*.tfvars— 面向不同环境的变量值文件terraform.lock.hcl— Provider 版本锁文件这份清单与核心包配置形成交叉印证filePatterns.entryPoints登记了main.tffilePatterns.config登记了variables.tf配置清单中的terraform.tfvars也覆盖.tfvars家族。可以推断当架构分析器处理一个典型的infra/目录时main.tf会因入口身份获得更高的层级判定权重而variables.tf/outputs.tf则会被归为参数化辅助文件这与提示片段中Variables/Outputs概念板块的分工描述是一致的。Edge PatternsTerraform 文件之间的四类关系边第三板块Edge Patterns是整份提示片段中技术密度最高的部分——它直接规定 Terraform 文件之间应当产生哪四种语义边Terraform 文件provisions其自身定义的基础设施资源模块引用在 Terraform 文件之间创建depends_on边Terraform 通过引用容器镜像或部署目标来deploys应用代码变量文件configures它所参数化的 Terraform 模块。这四条边类型并非凭空约定它们在核心 schema 中都有正式定义。schema.ts 的EdgeTypeSchema将边类型分为若干组其中基础设施组为deploys, serves, provisions, triggers, // Infrastructure依赖组中则包含depends_on、configures见 types.ts 中EdgeType的同一分组注释。此外 schema 还内置了一套别名归一化表把 LLM 可能生成的近义边类型自动改写为标准值例如creates→provisionsuses/requires→depends_ondescribes→documents、exposes→servesSchema 测试 中的两个用例锁定了这一行为一个用例验证deploys、serves、migrates、documents、provisions、routes、defines_schema、triggers全部通过校验另一个用例验证creates: provisions等别名会被自动纠正。这保证了即使 LLM 在分析 Terraform 文件时写出creates而非provisions合并进assembled-graph.json的边仍然会落到标准类型上。边在 file-analyzer 中的落地位置值得说明的是Edge Patterns板块的受众与Language Context注入并不完全重合。Phase 2 中真正逐文件产出节点的 file-analyzer 代理 自带一套完整的边类型表其中与 Terraform 直接相关的定义包括节点类型*.tf、*.tfvars等非代码基础设施文件被归类为resource节点fileCategory 为infra这是provisions边的源端节点边类型configures配置/变量文件作用于模块权重 0.6、deploys基础设施文件构建/部署代码权重 0.7、depends_on运行时依赖权重 0.6标签约定*.tf文件被赋予infrastructure、deployment标签。提示片段中的 Edge Patterns 板块正是对这些通用规则在 Terraform 语境下的具象化它告诉 LLM模块引用 →depends_on、变量文件 →configures模块把抽象的边类型表映射到.tf文件的具体场景上。两个来源叠加构成了 Terraform 文件从节点分类、标签、到关系边的完整判定链。Summary Style三段式摘要模板第四板块Summary Style给出了 Terraform 文件节点摘要summary 字段的三个示范句式要求摘要遵循用途 数量 具体资源的写法Terraform configuration provisioning N AWS resources including VPC, ECS cluster, and RDS instance.Infrastructure module defining a reusable Kubernetes namespace with RBAC and network policies.Variable definitions for N environment-specific settings (region, instance type, scaling).这三条示例恰好对应了文件模式的三种典型角色main.tf式的资源定义文件第一句呼应provisions边、modules/**/*.tf式的模块文件第二句呼应Modules概念、*.tfvars式的变量定义第三句呼应configures边。file-analyzer 对 Infra 文件的通用要求是Describe what gets deployed/built而这里的模板进一步把要求收窄到provisioning N 个 X 云资源包括…——数量与具体资源名的组合使得摘要在仪表盘ProjectOverview或节点信息面板中具备可直接检索的信息量。从注入到成图一份 .tf 文件走过的完整链路把前述各环串联起来一份 Terraform 文件在 Understand-Anything 中的处理链路如下各环节均有仓库内对应物可按路径查阅扫描scan-project.mjs 依据语言注册表含 terraform.ts识别.tf/.tfvars为terraform语言产出fileCategory: infra的文件清单与scan-result.json分批compute-batches.mjs生成batches.jsonTerraform 文件按其所在批次分派给 file-analyzer 子代理分析file-analyzer 按 代理定义 为每个.tf文件创建resource:节点按权重表产出provisions/configures/depends_on/deploys边合并merge-batch-graphs.py归一化节点 ID 与复杂度、去重并丢弃悬空边边类型则经由 schema.ts 的别名表完成最后兜底如creates→provisions架构分层Phase 4 的 architecture-analyzer 在提示词中注入本提示片段全文## Language Context据此把 Terraform 文件归入基础设施层并写出符合 Summary Style 的摘要成图最终汇入$UA_DIR/knowledge-graph.json在 dashboard 中呈现为可搜索、可导航的交互图谱。小结Terraform 语言提示片段 的篇幅不长但四个板块各司其职Key Concepts 提供领域语义File Patterns 提供文件名到角色的映射Edge Patterns 规定provisions/depends_on/deploys/configures四类关系边Summary Style 约束节点摘要的句式与信息密度。它的生效机制则由 SKILL.md 的 Phase 4 语言上下文注入驱动并由 核心语言注册表、边类型 schema 及其 测试用例 在机器层面完成校验与归一化。对以 Terraform 管理基础设施的团队而言理解这套片段机制意味着你看到的每一个resource:节点与每一条 IaC 关系边背后都有明确的检测规则、提示词依据和 schema 兜底而非 LLM 的自由发挥。【免费下载链接】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），仅供参考