尧图网站建设 
Understand-Anything 的 Shell 语言提示片段让知识图谱“读懂”脚本文件的 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本文深入解析 Understand-Anything 插件中 Shell 语言提示片段 的设计意图与完整内容它是一份注入给 LLM 子代理的语言专属上下文用于在架构分析阶段引导模型正确识别 Shell 脚本的关键概念、常见文件模式、图边语义与摘要风格。读完本文你将了解这份片段在/understand七阶段流水线中的注入位置、其 10 个核心概念与 4 条边模式如何映射到知识图谱的 Schema以及仓库中配套的 ShellParser 与语言注册表如何在确定性层面与之协同工作。一、这份文件在整个插件中的定位skills/understand/languages/目录下存放着按语言 id 命名的 Markdown 提示片段如python.md、dockerfile.md、shell.md。它们不是给用户阅读的文档而是 SKILL.md 所定义的分析流水线的“弹药库”。在 Phase 4ARCHITECTURE架构层识别中主会话会按 Phase 1 扫描出的语言列表逐一加载片段For each language detected in Phase 1 (e.g.,python,markdown, …,shell,html,css), read the file at./languages/language-id.mdand append its content after the base template under a## Language Contextheader.Include non-code language snippets— they provide edge patterns and summary styles for non-code files.也就是说只要项目的文件扫描阶段把某个项目识别为“含有 Shell 脚本”.sh、.bash、.zsh文件均会被映射到shell语言 id见后文第四节shell.md的全部内容就会被原样追加到architecture-analyzer子代理定义见 agents/architecture-analyzer.md的提示词中。这份片段回答的核心问题是当 LLM 面对一个 Shell 脚本文件节点时它应该抓住哪些语言特征来撰写摘要、推断依赖、选择图边类型二、Key Concepts10 个 Shell 关键概念及其图谱意义片段的第一部分## Key Concepts列出了 10 个 Shell 语言的关键概念这是模型理解脚本节点时的“概念词典”概念语法要点原文档对图谱分析的指引意义Shebang Line#!/bin/bash或#!/usr/bin/env bash指定解释器判断脚本的运行环境与解释器依赖VariablesVARvalue赋值$VAR或${VAR}展开两侧不能有空格识别配置注入点环境变量驱动的脚本行为Functionsfunction name()或name()两种定义风格与 ShellParser 的正则严格对应Conditionalsif [[ condition ]]; then ... fi[[ ]]为扩展测试理解分支逻辑与守卫条件Loopsfor item in list、while condition、until condition识别批量处理型脚本Pipes and Redirection\|串联命令//21输出重定向命令链即隐式的数据流是推断triggers边的依据Exit Codes$?捕获上一条命令状态set -e失败即退出判断脚本的错误传播行为Strict Modeset -euo pipefail出错即退、未定义变量报错、管道失败报错区分“健壮化”脚本与快速原型脚本的复杂度评级Command Substitution$(command)把命令输出捕获为字符串识别“脚本内嵌调用其他工具/脚本”的依赖信号Here DocumentsEOF ... EOF多行字符串输入避免把 heredoc 内容误判为独立逻辑块这些概念清单的作用是让 LLM 在撰写文件摘要和推断边时具备与人类 Shell 工程师一致的心智模型。例如看到set -euo pipefail应意识到这是一个生产级健壮脚本看到命令替换$(command)应意识到该脚本可能triggers了另一个进程。三、Notable File Patterns五类值得重点识别的 Shell 文件片段的## Notable File Patterns部分枚举了 5 类在项目中高频出现、且角色明确的 Shell 文件*.sh/*.bash— 通用 Shell 脚本文件scripts/*.sh— 项目自动化脚本构建、部署、环境初始化entrypoint.sh— Docker 容器入口点脚本install.sh/setup.sh— 环境搭建脚本.bashrc/.bash_profile/.zshrc— Shell 配置文件这组模式并非空泛的经验罗列它与仓库中三处确定性实现精确呼应语言识别scan-project.mjs 的LANGUAGE_BY_EXT表把.sh、.bash、.zsh三种扩展名统一映射到shell语言 id这是 Phase 4 能触发加载shell.md片段的前提。配置类 dotfile同一脚本中的dotfileKey()函数scan-project.mjs会把.bashrc、.env.local这类点文件的“首段”当作隐式扩展名处理使得.bashrc等配置文件能被正确识别而非落入unknown。语言注册表shell.ts 中的shellConfig声明了扩展名列表.sh、.bash、.zsh与 8 个概念关键词variables、functions、conditionals、loops、pipes、redirection、subshells、exit codes并在filePatterns.config中登记了.bashrc、.zshrc、.profile作为配置类文件——与片段中第 5 条模式一致。LanguageRegistry 则通过“先按文件名、再按扩展名”的查找顺序把文件路由到该配置。此外shellConfig的filePatterns.entryPoints为空数组从源码结构看这意味着核心包不把任何 Shell 文件默认视为“入口点”——入口点的判定交由扫描阶段的通用模式匹配如index.ts、main.py等清单完成Shell 的entrypoint.sh则主要依靠上述语言片段的语义提示来被 LLM 正确归类。四、Edge Patterns脚本文件在图谱中的四种边片段最有价值的部分是## Edge Patterns它直接规定了 Shell 脚本节点应当发出哪四类边——这正是“语言片段指导图构建”的典范片段中的模式图谱边类型语义说明Shell scriptstriggersother scripts or build processes they invoketriggers脚本调用./build.sh、make等了其他脚本或构建流程Entry point scriptsdeploysthe application they startdeploys入口脚本如entrypoint.sh启动了它所部署的应用Setup scriptsconfiguresthe development environmentconfigures环境初始化脚本配置了开发环境Build scriptsdepends_onthe source files they compile or packagedepends_on构建脚本依赖它所编译/打包的源码文件这四种边全部出现在 SKILL.md 末尾的 KnowledgeGraph Schema 参考中triggers、deploys属于“Infrastructure”类边depends_on、configures属于“Dependencies”类边权重约定分别为 0.6 与 0.7imports/deploys/migrates为 0.7depends_on/configures/triggers为 0.6。值得注意的是这些边连接的对象往往不是同语言的代码文件而是跨类别节点file脚本连向serviceDockerfile 所代表的服务、pipelineCI 配置、其他file被调用的脚本。这与 architecture-analyzer.md 中要求的“跨类别依赖分析”cross-category dependency analysis相互衔接——架构子代理会统计config - file、service - file这类边矩阵而 Shell 脚本产生的triggers/deploys/configures边正是其中“脚本自动化层”与“基础设施层”之间的桥梁帮助最终的分层结果把scripts/目录合理划入layer:infrastructure或独立的自动化层。五、Summary StyleShell 节点的摘要范本片段的## Summary Style给出了三条可直接模仿的摘要句式Build automation script compiling TypeScript, running tests, and packaging the release artifact. Docker entry point script handling signal forwarding and graceful shutdown. Environment setup script installing dependencies and configuring development tools.这三条范本遵循 file-analyzer.md 对代码类文件摘要的通用要求“描述目的与角色”并明确否决“The utils file contains utility functions”这类空话式摘要其共同结构是先给文件定性Build automation script / Docker entry point script / Environment setup script——恰好覆盖了上一节“Notable File Patterns”中scripts/*.sh、entrypoint.sh、setup.sh三种角色再用动宾短语列出职责compiling… running… packaging… / handling signal forwarding… / installing… configuring…一句话内包含多个动作信息密度高不展开实现细节保持 1–2 句的长度约束与file-analyzer的 summary 字段要求一致。由于/understand支持--language选项生成中文、日文等本地化内容这些英文范本在中文输出场景下会被语言指令改写但其“定性 职责枚举”的结构会被保留。六、确定性侧的配套实现ShellParser语言片段负责“语义层”的引导而结构层的提取由核心包中的 ShellParser 完成。它注册了shell与jenkinsfile两个语言注释说明 Jenkinsfile 的 Groovy DSL 中函数风格语法足够相似可顺带识别 step 块提供两项能力函数提取analyzeFile同时匹配name() {与function name {两种风格并刻意要求开括号出现在当前行或下一个非空行——源码注释解释了这个守卫的必要性否则诸如 heredoc/注释中出现的command_substitution_demo() echo hi之类行会被误判为函数定义。函数体通过花括号深度计数定位结束行。注释同时明确不提取变量声明、别名与 trap 处理器。引用提取extractReferences逐行匹配source或.命令^\s*(?:source|\.)[ \t][]?([^\s])[]?把source ./lib/common.sh解析为file类型引用。这与语言片段中“Shell scripts triggers other scripts”的边模式形成互补确定性解析器负责能静态看出的source引用LLM 结合提示片段负责补上调用、部署、配置等更宽泛的边。该解析器经由 parsers/index.ts 导出并纳入插件注册表与TreeSitterPlugin一样服务于extract-structure.mjs等脚本的结构提取流程。七、如何复现这一流程在一个安装了 Understand-Anything 插件的项目中上述机制的触发链路是运行/understand后Phase 1 由scan-project.mjs扫描文件.sh/.bash/.zsh文件被打上language: shell、fileCategory: script两个标记scan-project.mjs 的CATEGORY_BY_EXT将这三类扩展名归入script类别Phase 2 中file-analyzer子代理把script类别的文件按 file-analyzer.md 的映射表创建为file类型节点“Shell scripts treat like code”并依据片段中的 Summary Style 撰写摘要Phase 4 中主会话检测到语言列表含shell读取 shell.md 并以## Language Context标题追加进architecture-analyzer提示词模型据此产出带triggers/deploys/configures/depends_on边的分层结果写入.ua/intermediate/layers.json旧项目为.understand-anything/。整个过程中语言片段是“只注入、不持久化”的上下文最终图谱中留下的只是它引导产生的节点摘要、边和分层——这也是仓库将其与框架片段frameworks/、输出语言指南locales/并列为三类可注入上下文的原因。小结Shell 语言提示片段 虽然只有 35 行却是 Understand-Anything“提示词即配置”设计的一个典型样本Key Concepts 提供概念词典、Notable File Patterns 提供识别清单、Edge Patterns 提供与 KnowledgeGraph Schema 一一对应的边类型契约、Summary Style 提供可复用的摘要范本。它与 shellConfig语言注册、scan-project.mjs扫描识别、ShellParser结构提取共同构成 Shell 脚本从“被识别”到“被理解”再到“被分层”的完整链路。阅读同目录下的dockerfile.md、yaml.md、markdown.md等兄弟片段可以看到同一套设计范式在 25 种语言上的复用。【免费下载链接】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 的 Shell 语言提示片段：让知识图谱“读懂”脚本文件的 LLM 上下文设计
Understand-Anything 的 Shell 语言提示片段让知识图谱“读懂”脚本文件的 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本文深入解析 Understand-Anything 插件中 Shell 语言提示片段 的设计意图与完整内容它是一份注入给 LLM 子代理的语言专属上下文用于在架构分析阶段引导模型正确识别 Shell 脚本的关键概念、常见文件模式、图边语义与摘要风格。读完本文你将了解这份片段在/understand七阶段流水线中的注入位置、其 10 个核心概念与 4 条边模式如何映射到知识图谱的 Schema以及仓库中配套的 ShellParser 与语言注册表如何在确定性层面与之协同工作。一、这份文件在整个插件中的定位skills/understand/languages/目录下存放着按语言 id 命名的 Markdown 提示片段如python.md、dockerfile.md、shell.md。它们不是给用户阅读的文档而是 SKILL.md 所定义的分析流水线的“弹药库”。在 Phase 4ARCHITECTURE架构层识别中主会话会按 Phase 1 扫描出的语言列表逐一加载片段For each language detected in Phase 1 (e.g.,python,markdown, …,shell,html,css), read the file at./languages/language-id.mdand append its content after the base template under a## Language Contextheader.Include non-code language snippets— they provide edge patterns and summary styles for non-code files.也就是说只要项目的文件扫描阶段把某个项目识别为“含有 Shell 脚本”.sh、.bash、.zsh文件均会被映射到shell语言 id见后文第四节shell.md的全部内容就会被原样追加到architecture-analyzer子代理定义见 agents/architecture-analyzer.md的提示词中。这份片段回答的核心问题是当 LLM 面对一个 Shell 脚本文件节点时它应该抓住哪些语言特征来撰写摘要、推断依赖、选择图边类型二、Key Concepts10 个 Shell 关键概念及其图谱意义片段的第一部分## Key Concepts列出了 10 个 Shell 语言的关键概念这是模型理解脚本节点时的“概念词典”概念语法要点原文档对图谱分析的指引意义Shebang Line#!/bin/bash或#!/usr/bin/env bash指定解释器判断脚本的运行环境与解释器依赖VariablesVARvalue赋值$VAR或${VAR}展开两侧不能有空格识别配置注入点环境变量驱动的脚本行为Functionsfunction name()或name()两种定义风格与 ShellParser 的正则严格对应Conditionalsif [[ condition ]]; then ... fi[[ ]]为扩展测试理解分支逻辑与守卫条件Loopsfor item in list、while condition、until condition识别批量处理型脚本Pipes and Redirection\|串联命令//21输出重定向命令链即隐式的数据流是推断triggers边的依据Exit Codes$?捕获上一条命令状态set -e失败即退出判断脚本的错误传播行为Strict Modeset -euo pipefail出错即退、未定义变量报错、管道失败报错区分“健壮化”脚本与快速原型脚本的复杂度评级Command Substitution$(command)把命令输出捕获为字符串识别“脚本内嵌调用其他工具/脚本”的依赖信号Here DocumentsEOF ... EOF多行字符串输入避免把 heredoc 内容误判为独立逻辑块这些概念清单的作用是让 LLM 在撰写文件摘要和推断边时具备与人类 Shell 工程师一致的心智模型。例如看到set -euo pipefail应意识到这是一个生产级健壮脚本看到命令替换$(command)应意识到该脚本可能triggers了另一个进程。三、Notable File Patterns五类值得重点识别的 Shell 文件片段的## Notable File Patterns部分枚举了 5 类在项目中高频出现、且角色明确的 Shell 文件*.sh/*.bash— 通用 Shell 脚本文件scripts/*.sh— 项目自动化脚本构建、部署、环境初始化entrypoint.sh— Docker 容器入口点脚本install.sh/setup.sh— 环境搭建脚本.bashrc/.bash_profile/.zshrc— Shell 配置文件这组模式并非空泛的经验罗列它与仓库中三处确定性实现精确呼应语言识别scan-project.mjs 的LANGUAGE_BY_EXT表把.sh、.bash、.zsh三种扩展名统一映射到shell语言 id这是 Phase 4 能触发加载shell.md片段的前提。配置类 dotfile同一脚本中的dotfileKey()函数scan-project.mjs会把.bashrc、.env.local这类点文件的“首段”当作隐式扩展名处理使得.bashrc等配置文件能被正确识别而非落入unknown。语言注册表shell.ts 中的shellConfig声明了扩展名列表.sh、.bash、.zsh与 8 个概念关键词variables、functions、conditionals、loops、pipes、redirection、subshells、exit codes并在filePatterns.config中登记了.bashrc、.zshrc、.profile作为配置类文件——与片段中第 5 条模式一致。LanguageRegistry 则通过“先按文件名、再按扩展名”的查找顺序把文件路由到该配置。此外shellConfig的filePatterns.entryPoints为空数组从源码结构看这意味着核心包不把任何 Shell 文件默认视为“入口点”——入口点的判定交由扫描阶段的通用模式匹配如index.ts、main.py等清单完成Shell 的entrypoint.sh则主要依靠上述语言片段的语义提示来被 LLM 正确归类。四、Edge Patterns脚本文件在图谱中的四种边片段最有价值的部分是## Edge Patterns它直接规定了 Shell 脚本节点应当发出哪四类边——这正是“语言片段指导图构建”的典范片段中的模式图谱边类型语义说明Shell scriptstriggersother scripts or build processes they invoketriggers脚本调用./build.sh、make等了其他脚本或构建流程Entry point scriptsdeploysthe application they startdeploys入口脚本如entrypoint.sh启动了它所部署的应用Setup scriptsconfiguresthe development environmentconfigures环境初始化脚本配置了开发环境Build scriptsdepends_onthe source files they compile or packagedepends_on构建脚本依赖它所编译/打包的源码文件这四种边全部出现在 SKILL.md 末尾的 KnowledgeGraph Schema 参考中triggers、deploys属于“Infrastructure”类边depends_on、configures属于“Dependencies”类边权重约定分别为 0.6 与 0.7imports/deploys/migrates为 0.7depends_on/configures/triggers为 0.6。值得注意的是这些边连接的对象往往不是同语言的代码文件而是跨类别节点file脚本连向serviceDockerfile 所代表的服务、pipelineCI 配置、其他file被调用的脚本。这与 architecture-analyzer.md 中要求的“跨类别依赖分析”cross-category dependency analysis相互衔接——架构子代理会统计config - file、service - file这类边矩阵而 Shell 脚本产生的triggers/deploys/configures边正是其中“脚本自动化层”与“基础设施层”之间的桥梁帮助最终的分层结果把scripts/目录合理划入layer:infrastructure或独立的自动化层。五、Summary StyleShell 节点的摘要范本片段的## Summary Style给出了三条可直接模仿的摘要句式Build automation script compiling TypeScript, running tests, and packaging the release artifact. Docker entry point script handling signal forwarding and graceful shutdown. Environment setup script installing dependencies and configuring development tools.这三条范本遵循 file-analyzer.md 对代码类文件摘要的通用要求“描述目的与角色”并明确否决“The utils file contains utility functions”这类空话式摘要其共同结构是先给文件定性Build automation script / Docker entry point script / Environment setup script——恰好覆盖了上一节“Notable File Patterns”中scripts/*.sh、entrypoint.sh、setup.sh三种角色再用动宾短语列出职责compiling… running… packaging… / handling signal forwarding… / installing… configuring…一句话内包含多个动作信息密度高不展开实现细节保持 1–2 句的长度约束与file-analyzer的 summary 字段要求一致。由于/understand支持--language选项生成中文、日文等本地化内容这些英文范本在中文输出场景下会被语言指令改写但其“定性 职责枚举”的结构会被保留。六、确定性侧的配套实现ShellParser语言片段负责“语义层”的引导而结构层的提取由核心包中的 ShellParser 完成。它注册了shell与jenkinsfile两个语言注释说明 Jenkinsfile 的 Groovy DSL 中函数风格语法足够相似可顺带识别 step 块提供两项能力函数提取analyzeFile同时匹配name() {与function name {两种风格并刻意要求开括号出现在当前行或下一个非空行——源码注释解释了这个守卫的必要性否则诸如 heredoc/注释中出现的command_substitution_demo() echo hi之类行会被误判为函数定义。函数体通过花括号深度计数定位结束行。注释同时明确不提取变量声明、别名与 trap 处理器。引用提取extractReferences逐行匹配source或.命令^\s*(?:source|\.)[ \t][]?([^\s])[]?把source ./lib/common.sh解析为file类型引用。这与语言片段中“Shell scripts triggers other scripts”的边模式形成互补确定性解析器负责能静态看出的source引用LLM 结合提示片段负责补上调用、部署、配置等更宽泛的边。该解析器经由 parsers/index.ts 导出并纳入插件注册表与TreeSitterPlugin一样服务于extract-structure.mjs等脚本的结构提取流程。七、如何复现这一流程在一个安装了 Understand-Anything 插件的项目中上述机制的触发链路是运行/understand后Phase 1 由scan-project.mjs扫描文件.sh/.bash/.zsh文件被打上language: shell、fileCategory: script两个标记scan-project.mjs 的CATEGORY_BY_EXT将这三类扩展名归入script类别Phase 2 中file-analyzer子代理把script类别的文件按 file-analyzer.md 的映射表创建为file类型节点“Shell scripts treat like code”并依据片段中的 Summary Style 撰写摘要Phase 4 中主会话检测到语言列表含shell读取 shell.md 并以## Language Context标题追加进architecture-analyzer提示词模型据此产出带triggers/deploys/configures/depends_on边的分层结果写入.ua/intermediate/layers.json旧项目为.understand-anything/。整个过程中语言片段是“只注入、不持久化”的上下文最终图谱中留下的只是它引导产生的节点摘要、边和分层——这也是仓库将其与框架片段frameworks/、输出语言指南locales/并列为三类可注入上下文的原因。小结Shell 语言提示片段 虽然只有 35 行却是 Understand-Anything“提示词即配置”设计的一个典型样本Key Concepts 提供概念词典、Notable File Patterns 提供识别清单、Edge Patterns 提供与 KnowledgeGraph Schema 一一对应的边类型契约、Summary Style 提供可复用的摘要范本。它与 shellConfig语言注册、scan-project.mjs扫描识别、ShellParser结构提取共同构成 Shell 脚本从“被识别”到“被理解”再到“被分层”的完整链路。阅读同目录下的dockerfile.md、yaml.md、markdown.md等兄弟片段可以看到同一套设计范式在 25 种语言上的复用。【免费下载链接】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），仅供参考