Understand-Anything 的 Express 框架附录从框架检测到分层建模的完整机制【免费下载链接】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 插件的知识图谱流水线中express.md 是一份专门面向 Express 项目的分析附录Framework Addendum当扫描阶段检测到目标项目使用 Express 时它会被注入到file-analyzer与architecture-analyzer两个子代理的提示词中为 Express 项目规定规范化的文件角色、边缘模式和七层架构划分。读完本文你能掌握这份附录的完整规则文件角色表、四类边模式、层级映射、languageLesson 模式以及它背后的框架检测配置express.ts、检测算法framework-registry.ts和注入时机SKILL.md 的 Phase 4从而理解 Understand-Anything 是如何把 Express 约定编码进图谱节点、边与分层的。一、附录的定位不是独立提示词而是叠加层express.md 文件头两行明确了自己的使用约束Injected into file-analyzer and architecture-analyzer prompts when Express is detected. Do NOT use as a standalone prompt — always appended to the base prompt template.也就是说它不是可以独立运行的提示词而是必须拼接在基础提示词模板之后的补充规则。其工作方式是在基础分析规则之上叠加 Express 专属约定apply these additional conventions on top of the base analysis rules。注入发生在分析流水线的哪一步在 SKILL.md 定义的 Phase 4ARCHITECTURE中主会话为architecture-analyzer子代理构建组合提示词时按固定顺序拼接上下文语言上下文注入对 Phase 1 检测到的每种语言读取languages/language-id.md如languages/javascript.md、languages/typescript.md拼接到基础模板的## Language Context标题之后框架附录注入对 Phase 1 检测到的每个框架读取frameworks/framework-id-lowercase.mdExpress 即frameworks/express.md整体追加在语言上下文之后若文件不存在则静默跳过输出语言注入若输出语言非英文再追加locales/lang.md。因此 Express 附录只在检测命中时生效且与语言上下文如 TypeScript 附录共存于同一份提示词中。附录文件路径由框架配置显式声明express.ts 中的promptSnippetPath: ./frameworks/express.md就是把这份 Markdown 与配置关联起来的锚点。二、Express 是如何被检测出来的检测配置express.ts 的逐字段解析express.ts 是整个插件内置的 10 个框架配置之一见 framework-registry.test.ts 中 registers all 10 built-in framework configs 的断言完整内容如下export const expressConfig { id: express, displayName: Express, languages: [javascript, typescript], detectionKeywords: [\express\:, express-validator, express-session], manifestFiles: [package.json], promptSnippetPath: ./frameworks/express.md, entryPoints: [ src/index.js, src/app.js, server.js, app.js, src/index.ts, src/app.ts, ], layerHints: { routes: api, controllers: service, models: data, middleware: middleware, services: service, db: data, }, } satisfies FrameworkConfig;各字段在分析流水线中的实际用途字段取值作用idexpress框架唯一标识决定附录文件为frameworks/express.mdid 小写形式displayNameExpress展示名写入图谱project.frameworks字段languagesjavascript,typescript登记到语言→框架索引getForLanguageExpress 因此同时匹配 JS 与 TS 项目detectionKeywordsexpress:、express-validator、express-session在package.json内容中做子串匹配注意第一个关键词带引号用于匹配 dependencies 中的依赖项键名避免误伤任意提到 express 字样的内容manifestFilespackage.json只在这些清单文件中查找关键词promptSnippetPath./frameworks/express.md指向本文分析的附录文件entryPointsserver.js、app.js、src/index.ts等 6 个候选为 Phase 5TOUR的从入口点开始提供 Express 惯例候选layerHints目录名→层级映射作为 Express 专属的目录分层先验与architecture-analyzer的通用目录模式表互补检测算法FrameworkRegistry.detectFrameworksframework-registry.ts 中detectFrameworks的核心逻辑是遍历所有已注册框架配置FrameworkRegistry.createDefault()预注册全部内置框架对每个框架在其manifestFiles中按基名匹配key manifestFile || key.endsWith(/ manifestFile)找到清单内容将清单内容整体转小写后逐个检查detectionKeywords是否为子串同样转小写比较——即检测是大小写不敏感的命中任一关键词即登记该框架并用Set保证同一框架不会被重复报告所有注册动作都经过FrameworkConfigSchematypes.ts的 Zod 校验id、displayName、languages、detectionKeywords、manifestFiles、promptSnippetPath均为必填且非空。测试用例 framework-registry.test.ts 验证了这些行为大小写不敏感Django4.2也能命中、无匹配时返回空数组、多清单命中同一框架时去重、重复注册配置不产生重复项。对 Express 而言实际效果是只要package.json中出现express:dependencies/devDependencies 键或express-validator、express-session依赖Phase 1 的扫描结果就会把 Express 记入frameworks列表Phase 4 随即把 express.md 全文追加进分析提示词。三、规范文件角色表Canonical File Roles附录的第一节要求file-analyzer在分析 Express 项目时按以下表为文件分配角色与标签。这 12 类模式覆盖了 Express 项目的典型目录布局文件 / 模式角色标签app.js,app.ts应用入口——创建 Express 应用、挂载中间件与路由entry-point,configserver.js,server.ts,index.js,index.ts服务器引导——启动 HTTP 监听器可能 import appentry-point,configroutes/*.js,routes/*.ts路由定义——把 HTTP 方法与路径映射到处理器api-handler,routingcontrollers/*.js,controllers/*.ts请求处理器——处理请求、编排服务、返回响应api-handler,servicemodels/*.js,models/*.ts数据模型——Mongoose schema、Sequelize 模型或纯数据定义data-modelmiddleware/*.js,middleware/*.ts中间件函数——认证、日志、校验、错误处理middlewareservices/*.js,services/*.ts业务逻辑——与 HTTP 层解耦的领域操作servicedb/*.js,db/*.ts,database/*.js数据库连接与配置data-model,configconfig/*.js,config/*.ts应用配置——环境变量、特性开关configvalidators/*.js,validators/*.ts请求校验 schemaJoi、Zod、express-validatorvalidation,utilityutils/*.js,utils/*.ts共享工具函数utilitytests/*.js,test/*.js,__tests__/*.js单元与集成测试test这些标签直接对应 file-analyzer.md 中为代码文件分配 3-5 个小写连字符标签的要求如entry-point、api-handler、middleware、data-model均在其候选词表内。file-analyzer先用捆绑脚本extract-structure.mjs做确定性结构抽取函数、类、导出、调用图再由 LLM 结合上述角色表写summary、tags和complexity——附录的价值在于让标签体系在整个 Express 项目内保持一致从而让后续分层、搜索和 dashboard 过滤都有稳定的语义锚点。四、四类必须寻找的边模式Edge Patterns图谱的表达力取决于边。附录第二节规定了分析 Express 项目时必须主动寻找的四种边模式每一种都对应depends_on或 middleware 类边1. 路由挂载Route mounting当app.use(/api/users, usersRouter)挂载一个路由子树时从主应用到路由模块创建depends_on边。这些边表达的是HTTP 路由树——它们让图谱能够回答/api/users下的请求由哪些文件处理这类问题。2. 中间件链Middleware chain当app.use(cors())、app.use(authMiddleware)或router.use(validate)注册中间件时从应用或路由到中间件函数创建 middleware 边。附录特别强调顺序很重要——中间件按注册顺序执行。这一点在图谱中有真实语义schema.ts 的EdgeTypeSchema把middleware列为 Behavioral行为类边类型之一专用于表达请求管线中的执行关系与结构性的imports、依赖性的depends_on区分开来。3. 控制器到服务的调用Controller-to-service calls当控制器 import 并调用某个服务函数时从控制器到服务创建depends_on边。这条边表达的是HTTP 处理与业务逻辑的分离——是判断 Express 项目是否遵循分层约定的关键证据。4. 模型间关系Model relationships当模型互相引用Mongoose 的ref、Sequelize 的 associations时在模型文件之间创建depends_on边并在边的描述中注明关系类型如 belongsTo/hasMany。这让数据模型的关联结构也进入图谱而不是只剩 import 关系。边的权重约定附录没有重定义权重而是沿用全局约定。按 SKILL.md 中的 Edge Weight Conventionsdepends_on权重为 0.6middleware等其余类型落在All others档权重 0.5。file-analyzer.md 的边类型表同样给出depends_on的定义——文件对项目内另一文件存在运行时依赖比 imports 更宽包含动态 require、懒加载权重 0.6方向 forward。file-analyzer对每条边还要求source/target必须指向真实节点悬挂边会由合并脚本merge-batch-graphs.py统一丢弃兜底。五、Express 的七层架构划分附录第三节规定了 Express 项目检测到相应目录时应使用的层级划分。层级 ID 遵循 architecture-analyzer.md 的layer:kebab-case格式约定Layer ID层名归属内容layer:apiAPI 层routes/、controllers/、请求校验器layer:data数据层models/、db/、迁移文件、seederlayer:service服务层services/、业务逻辑模块layer:middleware中间件层middleware/、错误处理器、认证、日志layer:config配置层app.js、config/、环境变量设置、server.jslayer:utility工具层utils/、helpers/、共享纯函数layer:test测试层tests/、__tests__/、*.test.js、*.spec.js框架 layerHints 与通用目录模式的分工这份七层表不是凭空写的它与两处通用先验共同构成分层决策依据express.ts 的layerHintsroutes→api、controllers→service、models→data、middleware→middleware、services→service、db→data是 Express 专属的目录分层提示architecture-analyzer.md 的通用目录模式表routes/api/endpoints/handlers等目录名映射到api模式标签middleware/plugins/interceptors映射到middlewareutils/helpers映射到utility__tests__/test/tests映射到test——与附录的七层表高度吻合。值得注意的一个 Express 特化点controllers目录在附录与layerHints中都归入Service 层/service标签请求处理器——处理请求、编排服务而通用模式表把controllers归为api模式标签。从源码结构看这体现了 Express 社区惯例——控制器是薄编排层thin orchestrator职责偏业务编排而非纯 HTTP 端点。附录的作用正是用项目专属约定覆盖这种歧义。分层结果最终以layers.json落盘并受 Phase 4 归一化规则约束每个层必须含id/name/description/nodeIds四个字段每个文件节点必须恰好属于一个层所有nodeIds必须真实存在。file-analyzer.md 中也有同样严格的约束EVERY file node ID from the input MUST appear in exactly one layer——缺漏会导致下游流水线断裂。六、languageLesson五个值得写进导览的 Express 模式附录最后一节列出应写入languageLesson的显著模式。languageLesson是图谱 tour 步骤的可选字符串字段见 SKILL.md Phase 5 中 tour 步骤的order/title/description/nodeIds加可选languageLesson形状它让交互式 dashboard 的导览步骤能附带一段教学性说明而不只是文件跳转。五个模式全部继承如下中间件链req, res, nextExpress 通过中间件管线处理请求——每个中间件接收req、res和next()回调以向前传递控制权。这与第四节中间件链边呼应图谱中的 middleware 边正是这条管线的静态投影。错误处理中间件4 参数签名签名为(err, req, res, next)的中间件捕获错误——必须注册在所有路由之后才能作为全局错误处理器生效。这是 Express 最易踩坑的注册顺序约束写进 languageLesson 对新人读项目极具价值。Router 模块化express.Router()创建可挂载的模块化路由处理器可在不同路径前缀下组合进主应用——这正是第一节路由挂载边的源码形态。MVC 模式Express 应用常把关注点分离为 Model数据、View响应格式化、Controller请求处理——对应文件角色表中models/、响应格式化逻辑与controllers/的分工。Body 解析与校验请求体解析express.json()、express.urlencoded()与校验Joi、Zod、express-validator属于路由处理器之前应用的中间件职责——它们落在文件角色表的middleware/*与validators/*两行并应体现为中间件链边。七、把规则落到产物一次 Express 分析的验证路径把上文串起来/understand分析一个 Express 项目时与附录相关的事实链是Phase 1 SCAN产出scan-result.json其中frameworks包含Express由FrameworkRegistry.detectFrameworks对package.json做关键词匹配得出Phase 2 ANALYZE中file-analyzer按角色表打标签entry-point、api-handler、middleware、data-model…并按四类边模式补发depends_on/middleware 边每批输出写入.ua/intermediate/batch-i.json再由merge-batch-graphs.py合并、去重、丢弃悬挂边Phase 4 ARCHITECTURE中architecture-analyzer收到基础模板 语言上下文 express.md 全文 目录树的组合提示词产出 3-10 个层Express 项目通常即上述七层的子集最终产物是项目数据目录.ua/或旧项目已存在时的.understand-anything/下的knowledge-graph.json。因此验证附录是否生效的最直接方式是检查最终图谱layers数组中是否出现layer:api/layer:middleware等 IDedges中是否存在路由文件到控制器/服务文件的depends_on边权重 0.6tour 步骤的languageLesson是否包含中间件链、四参数错误处理等 Express 模式说明。相关行为还可由仓库测试佐证config-schema.test.ts 断言每个内置框架配置都通过 schema 校验且promptSnippetPath非空framework-registry.test.ts 则覆盖了关键词检测的边界情况。小结express.md 这份附录是 Understand-Anything 把框架领域知识注入 LLM 分析环节的标准做法检测配置express.ts决定何时生效附录本体决定如何生效——12 行文件角色表统一标签语义4 类边模式刻画路由树/中间件管线/服务编排/模型关联7 个layer:*层提供 Express 惯例下的分层骨架5 条 languageLesson 模式支撑交互式导览。它本身不执行任何代码却通过提示词注入显著提高了 Express 项目在图谱、分层与导览三个维度上的分析一致性。对于维护者新增一个框架支持只需三步在languages/frameworks/下写配置经FrameworkConfigSchema校验、在skills/understand/frameworks/下写同名附录、并由 index.ts 导出进入builtinFrameworkConfigs。【免费下载链接】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 的 Express 框架附录：从框架检测到分层建模的完整机制
Understand-Anything 的 Express 框架附录从框架检测到分层建模的完整机制【免费下载链接】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 插件的知识图谱流水线中express.md 是一份专门面向 Express 项目的分析附录Framework Addendum当扫描阶段检测到目标项目使用 Express 时它会被注入到file-analyzer与architecture-analyzer两个子代理的提示词中为 Express 项目规定规范化的文件角色、边缘模式和七层架构划分。读完本文你能掌握这份附录的完整规则文件角色表、四类边模式、层级映射、languageLesson 模式以及它背后的框架检测配置express.ts、检测算法framework-registry.ts和注入时机SKILL.md 的 Phase 4从而理解 Understand-Anything 是如何把 Express 约定编码进图谱节点、边与分层的。一、附录的定位不是独立提示词而是叠加层express.md 文件头两行明确了自己的使用约束Injected into file-analyzer and architecture-analyzer prompts when Express is detected. Do NOT use as a standalone prompt — always appended to the base prompt template.也就是说它不是可以独立运行的提示词而是必须拼接在基础提示词模板之后的补充规则。其工作方式是在基础分析规则之上叠加 Express 专属约定apply these additional conventions on top of the base analysis rules。注入发生在分析流水线的哪一步在 SKILL.md 定义的 Phase 4ARCHITECTURE中主会话为architecture-analyzer子代理构建组合提示词时按固定顺序拼接上下文语言上下文注入对 Phase 1 检测到的每种语言读取languages/language-id.md如languages/javascript.md、languages/typescript.md拼接到基础模板的## Language Context标题之后框架附录注入对 Phase 1 检测到的每个框架读取frameworks/framework-id-lowercase.mdExpress 即frameworks/express.md整体追加在语言上下文之后若文件不存在则静默跳过输出语言注入若输出语言非英文再追加locales/lang.md。因此 Express 附录只在检测命中时生效且与语言上下文如 TypeScript 附录共存于同一份提示词中。附录文件路径由框架配置显式声明express.ts 中的promptSnippetPath: ./frameworks/express.md就是把这份 Markdown 与配置关联起来的锚点。二、Express 是如何被检测出来的检测配置express.ts 的逐字段解析express.ts 是整个插件内置的 10 个框架配置之一见 framework-registry.test.ts 中 registers all 10 built-in framework configs 的断言完整内容如下export const expressConfig { id: express, displayName: Express, languages: [javascript, typescript], detectionKeywords: [\express\:, express-validator, express-session], manifestFiles: [package.json], promptSnippetPath: ./frameworks/express.md, entryPoints: [ src/index.js, src/app.js, server.js, app.js, src/index.ts, src/app.ts, ], layerHints: { routes: api, controllers: service, models: data, middleware: middleware, services: service, db: data, }, } satisfies FrameworkConfig;各字段在分析流水线中的实际用途字段取值作用idexpress框架唯一标识决定附录文件为frameworks/express.mdid 小写形式displayNameExpress展示名写入图谱project.frameworks字段languagesjavascript,typescript登记到语言→框架索引getForLanguageExpress 因此同时匹配 JS 与 TS 项目detectionKeywordsexpress:、express-validator、express-session在package.json内容中做子串匹配注意第一个关键词带引号用于匹配 dependencies 中的依赖项键名避免误伤任意提到 express 字样的内容manifestFilespackage.json只在这些清单文件中查找关键词promptSnippetPath./frameworks/express.md指向本文分析的附录文件entryPointsserver.js、app.js、src/index.ts等 6 个候选为 Phase 5TOUR的从入口点开始提供 Express 惯例候选layerHints目录名→层级映射作为 Express 专属的目录分层先验与architecture-analyzer的通用目录模式表互补检测算法FrameworkRegistry.detectFrameworksframework-registry.ts 中detectFrameworks的核心逻辑是遍历所有已注册框架配置FrameworkRegistry.createDefault()预注册全部内置框架对每个框架在其manifestFiles中按基名匹配key manifestFile || key.endsWith(/ manifestFile)找到清单内容将清单内容整体转小写后逐个检查detectionKeywords是否为子串同样转小写比较——即检测是大小写不敏感的命中任一关键词即登记该框架并用Set保证同一框架不会被重复报告所有注册动作都经过FrameworkConfigSchematypes.ts的 Zod 校验id、displayName、languages、detectionKeywords、manifestFiles、promptSnippetPath均为必填且非空。测试用例 framework-registry.test.ts 验证了这些行为大小写不敏感Django4.2也能命中、无匹配时返回空数组、多清单命中同一框架时去重、重复注册配置不产生重复项。对 Express 而言实际效果是只要package.json中出现express:dependencies/devDependencies 键或express-validator、express-session依赖Phase 1 的扫描结果就会把 Express 记入frameworks列表Phase 4 随即把 express.md 全文追加进分析提示词。三、规范文件角色表Canonical File Roles附录的第一节要求file-analyzer在分析 Express 项目时按以下表为文件分配角色与标签。这 12 类模式覆盖了 Express 项目的典型目录布局文件 / 模式角色标签app.js,app.ts应用入口——创建 Express 应用、挂载中间件与路由entry-point,configserver.js,server.ts,index.js,index.ts服务器引导——启动 HTTP 监听器可能 import appentry-point,configroutes/*.js,routes/*.ts路由定义——把 HTTP 方法与路径映射到处理器api-handler,routingcontrollers/*.js,controllers/*.ts请求处理器——处理请求、编排服务、返回响应api-handler,servicemodels/*.js,models/*.ts数据模型——Mongoose schema、Sequelize 模型或纯数据定义data-modelmiddleware/*.js,middleware/*.ts中间件函数——认证、日志、校验、错误处理middlewareservices/*.js,services/*.ts业务逻辑——与 HTTP 层解耦的领域操作servicedb/*.js,db/*.ts,database/*.js数据库连接与配置data-model,configconfig/*.js,config/*.ts应用配置——环境变量、特性开关configvalidators/*.js,validators/*.ts请求校验 schemaJoi、Zod、express-validatorvalidation,utilityutils/*.js,utils/*.ts共享工具函数utilitytests/*.js,test/*.js,__tests__/*.js单元与集成测试test这些标签直接对应 file-analyzer.md 中为代码文件分配 3-5 个小写连字符标签的要求如entry-point、api-handler、middleware、data-model均在其候选词表内。file-analyzer先用捆绑脚本extract-structure.mjs做确定性结构抽取函数、类、导出、调用图再由 LLM 结合上述角色表写summary、tags和complexity——附录的价值在于让标签体系在整个 Express 项目内保持一致从而让后续分层、搜索和 dashboard 过滤都有稳定的语义锚点。四、四类必须寻找的边模式Edge Patterns图谱的表达力取决于边。附录第二节规定了分析 Express 项目时必须主动寻找的四种边模式每一种都对应depends_on或 middleware 类边1. 路由挂载Route mounting当app.use(/api/users, usersRouter)挂载一个路由子树时从主应用到路由模块创建depends_on边。这些边表达的是HTTP 路由树——它们让图谱能够回答/api/users下的请求由哪些文件处理这类问题。2. 中间件链Middleware chain当app.use(cors())、app.use(authMiddleware)或router.use(validate)注册中间件时从应用或路由到中间件函数创建 middleware 边。附录特别强调顺序很重要——中间件按注册顺序执行。这一点在图谱中有真实语义schema.ts 的EdgeTypeSchema把middleware列为 Behavioral行为类边类型之一专用于表达请求管线中的执行关系与结构性的imports、依赖性的depends_on区分开来。3. 控制器到服务的调用Controller-to-service calls当控制器 import 并调用某个服务函数时从控制器到服务创建depends_on边。这条边表达的是HTTP 处理与业务逻辑的分离——是判断 Express 项目是否遵循分层约定的关键证据。4. 模型间关系Model relationships当模型互相引用Mongoose 的ref、Sequelize 的 associations时在模型文件之间创建depends_on边并在边的描述中注明关系类型如 belongsTo/hasMany。这让数据模型的关联结构也进入图谱而不是只剩 import 关系。边的权重约定附录没有重定义权重而是沿用全局约定。按 SKILL.md 中的 Edge Weight Conventionsdepends_on权重为 0.6middleware等其余类型落在All others档权重 0.5。file-analyzer.md 的边类型表同样给出depends_on的定义——文件对项目内另一文件存在运行时依赖比 imports 更宽包含动态 require、懒加载权重 0.6方向 forward。file-analyzer对每条边还要求source/target必须指向真实节点悬挂边会由合并脚本merge-batch-graphs.py统一丢弃兜底。五、Express 的七层架构划分附录第三节规定了 Express 项目检测到相应目录时应使用的层级划分。层级 ID 遵循 architecture-analyzer.md 的layer:kebab-case格式约定Layer ID层名归属内容layer:apiAPI 层routes/、controllers/、请求校验器layer:data数据层models/、db/、迁移文件、seederlayer:service服务层services/、业务逻辑模块layer:middleware中间件层middleware/、错误处理器、认证、日志layer:config配置层app.js、config/、环境变量设置、server.jslayer:utility工具层utils/、helpers/、共享纯函数layer:test测试层tests/、__tests__/、*.test.js、*.spec.js框架 layerHints 与通用目录模式的分工这份七层表不是凭空写的它与两处通用先验共同构成分层决策依据express.ts 的layerHintsroutes→api、controllers→service、models→data、middleware→middleware、services→service、db→data是 Express 专属的目录分层提示architecture-analyzer.md 的通用目录模式表routes/api/endpoints/handlers等目录名映射到api模式标签middleware/plugins/interceptors映射到middlewareutils/helpers映射到utility__tests__/test/tests映射到test——与附录的七层表高度吻合。值得注意的一个 Express 特化点controllers目录在附录与layerHints中都归入Service 层/service标签请求处理器——处理请求、编排服务而通用模式表把controllers归为api模式标签。从源码结构看这体现了 Express 社区惯例——控制器是薄编排层thin orchestrator职责偏业务编排而非纯 HTTP 端点。附录的作用正是用项目专属约定覆盖这种歧义。分层结果最终以layers.json落盘并受 Phase 4 归一化规则约束每个层必须含id/name/description/nodeIds四个字段每个文件节点必须恰好属于一个层所有nodeIds必须真实存在。file-analyzer.md 中也有同样严格的约束EVERY file node ID from the input MUST appear in exactly one layer——缺漏会导致下游流水线断裂。六、languageLesson五个值得写进导览的 Express 模式附录最后一节列出应写入languageLesson的显著模式。languageLesson是图谱 tour 步骤的可选字符串字段见 SKILL.md Phase 5 中 tour 步骤的order/title/description/nodeIds加可选languageLesson形状它让交互式 dashboard 的导览步骤能附带一段教学性说明而不只是文件跳转。五个模式全部继承如下中间件链req, res, nextExpress 通过中间件管线处理请求——每个中间件接收req、res和next()回调以向前传递控制权。这与第四节中间件链边呼应图谱中的 middleware 边正是这条管线的静态投影。错误处理中间件4 参数签名签名为(err, req, res, next)的中间件捕获错误——必须注册在所有路由之后才能作为全局错误处理器生效。这是 Express 最易踩坑的注册顺序约束写进 languageLesson 对新人读项目极具价值。Router 模块化express.Router()创建可挂载的模块化路由处理器可在不同路径前缀下组合进主应用——这正是第一节路由挂载边的源码形态。MVC 模式Express 应用常把关注点分离为 Model数据、View响应格式化、Controller请求处理——对应文件角色表中models/、响应格式化逻辑与controllers/的分工。Body 解析与校验请求体解析express.json()、express.urlencoded()与校验Joi、Zod、express-validator属于路由处理器之前应用的中间件职责——它们落在文件角色表的middleware/*与validators/*两行并应体现为中间件链边。七、把规则落到产物一次 Express 分析的验证路径把上文串起来/understand分析一个 Express 项目时与附录相关的事实链是Phase 1 SCAN产出scan-result.json其中frameworks包含Express由FrameworkRegistry.detectFrameworks对package.json做关键词匹配得出Phase 2 ANALYZE中file-analyzer按角色表打标签entry-point、api-handler、middleware、data-model…并按四类边模式补发depends_on/middleware 边每批输出写入.ua/intermediate/batch-i.json再由merge-batch-graphs.py合并、去重、丢弃悬挂边Phase 4 ARCHITECTURE中architecture-analyzer收到基础模板 语言上下文 express.md 全文 目录树的组合提示词产出 3-10 个层Express 项目通常即上述七层的子集最终产物是项目数据目录.ua/或旧项目已存在时的.understand-anything/下的knowledge-graph.json。因此验证附录是否生效的最直接方式是检查最终图谱layers数组中是否出现layer:api/layer:middleware等 IDedges中是否存在路由文件到控制器/服务文件的depends_on边权重 0.6tour 步骤的languageLesson是否包含中间件链、四参数错误处理等 Express 模式说明。相关行为还可由仓库测试佐证config-schema.test.ts 断言每个内置框架配置都通过 schema 校验且promptSnippetPath非空framework-registry.test.ts 则覆盖了关键词检测的边界情况。小结express.md 这份附录是 Understand-Anything 把框架领域知识注入 LLM 分析环节的标准做法检测配置express.ts决定何时生效附录本体决定如何生效——12 行文件角色表统一标签语义4 类边模式刻画路由树/中间件管线/服务编排/模型关联7 个layer:*层提供 Express 惯例下的分层骨架5 条 languageLesson 模式支撑交互式导览。它本身不执行任何代码却通过提示词注入显著提高了 Express 项目在图谱、分层与导览三个维度上的分析一致性。对于维护者新增一个框架支持只需三步在languages/frameworks/下写配置经FrameworkConfigSchema校验、在skills/understand/frameworks/下写同名附录、并由 index.ts 导出进入builtinFrameworkConfigs。【免费下载链接】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），仅供参考