项目名称：AI Agent Spec Vite 构建插件（个人练手 Demo）
技术栈
TypeScript、Vite 插件、js-yaml、Node.js
项目简介
参考 Dify 开源 Agent Spec 配置规范源码，剥离后端 Python 无关逻辑，基于 TS 自研 Vite 插件，实现 AI 人设 YAML 配置文件构建期自动转换，消除前端运行时解析 YAML 的性能损耗，配套类豆包对话前端项目使用。
核心功能
- YAML → JS 转换— 在代码中直接导入
.agent.spec.yaml文件，插件在构建时自动将其转换为 JS 模块 - 多环境配置合并— 定义
base.yaml作为通用默认值，env-{dev|prod|...}.yaml用于各环境的覆盖配置，通过深度合并生效 - JSON Schema 校验— 在
vite build时自动校验所有 Agent 配置是否符合 Schema - 自动生成 TypeScript 类型— 从 JSON Schema 自动推导
AgentConfig、UiConfig、ContextRule接口以及*.agent.spec.yaml的模块声明 - HMR 监听— 在
vite dev模式下，YAML 文件或 Schema 的修改会触发类型重新生成和页面热重载
项目价值
把 YAML 解析逻辑前置到构建阶段，省去页面运行时解析开销，简化多 AI 人设配置的维护成本。
项目链接
https://github.com/ikunhx/vite-agent-spec.git
面试高频问题 + 标准答案（只围绕 YAML 转换、源码改造流程，避开复杂深层逻辑，好背）
基础流程类（必问）
Q1：这个插件是怎么基于 Dify 源码改造的，完整流程是什么？
A：
- 拉取 Dify 源码，拆分提取 5 类 Spec 相关素材：配置字段定义、JSON 校验 Schema、前端 TS 类型、配置合并转换逻辑、Schema 管理规则；
- 筛选素材：Python 后端代码只摘抄字段约束、默认值规则，不复用代码；TS、JSON Schema 文件裁剪掉多模态、知识库等后端专属字段；
- 将精简后的 Spec 规范迁移到 Vue 项目
src/spec，拆分全局、环境、单人设三层 YAML 配置； - 参考开源配置合并逻辑，用 TS 重写 YAML 解析、合并工具，实现三层配置递归覆盖；
- 开发 Vite 自定义插件，拦截 YAML 文件，构建时自动完成解析转换；
- 在类豆包对话项目注册插件，导入转换后的配置渲染不同 AI 助手。
Q2：你说的 YAML 自动转换，具体做了什么？
A： 原生 Vue 项目引入 YAML 文件需要页面加载后用 js-yaml 运行时解析，会增加首屏耗时。我写的 Vite 插件在项目启动 / 打包的构建阶段拦截.agent.spec.yaml，自动读取 YAML 内容、合并多层配置、直接转换成 JS 对象字符串导出，页面导入时拿到的已经是结构化 JS 数据，不用在浏览器里再解析 YAML。
Q3：为什么要做三层配置合并转换？
A：项目有多套 AI 人设，很多 UI、上下文限制参数是通用的，写在每个人设 YAML 里会大量重复。转换时先读取全局 base 默认配置，再叠加开发 / 生产环境差异化配置，最后覆盖单人设专属配置，转换后输出完整配置对象，减少配置文件冗余代码。
源码改造相关（高频追问）
Q4：Dify 里的 Python 代码你是怎么处理的？
A：完全没有复用 Python 代码，只提取里面定义的必填字段、字段类型、参数默认值、格式校验规则，全部用 TS 重新实现 YAML 解析、合并、转换逻辑，适配前端 YAML 配置场景。
Q5：提取的 conversions.ts、form-state.ts 有什么用？
A：这两个文件是 Dify 官方的配置合并、默认值填充逻辑，我参考它的双向对象转换思路，实现了 YAML 三层配置递归合并函数，保证配置覆盖逻辑和开源 Spec 标准保持一致。
Q6：改造时删掉了哪些 Dify 原有逻辑？
A：剔除了所有后端相关能力：大模型调度、知识库、文件上传、数据库存储、多模态对话相关配置字段，只保留前端聊天页面需要的助手名称、系统提示词、UI 样式、上下文限制四类配置。
插件使用 & 业务场景类
Q7：这个插件在你的对话项目里怎么使用？
A：在 vite.config.ts 引入注册插件，项目 src/spec/agents 下放每个人设独立 YAML 文件；页面直接 import 导入 yaml 文件，插件已经提前转换为 JS 对象，直接读取 agentName、systemPrompt 传给后端接口，后端负责调用大模型返回对话内容。
Q8：修改 AI 人设 YAML 文件需要重启服务吗？
A：不需要，插件通过 chokidar 监听所有 spec 下的 yaml 文件，文件改动后自动重新转换配置并触发页面热更新，实时生效。
Q9：构建转换和运行时解析 YAML 相比，优势是什么？
- 性能更好：解析逻辑放在构建阶段，浏览器不用加载 js-yaml 库、不用运行时解析文本，降低首屏加载耗时；
- 提前发现错误：转换时会校验配置字段，写错、漏填必填项终端直接报错，不用等到页面运行才暴露问题；
- 减少冗余代码：三层配置合并，公共参数统一维护，不用每个 AI 助手重复编写。
兜底回避问题（如果面试官深挖 validator、type-generator，你记不住就这么答）
Q10：校验、自动生成 TS 类型这两块你详细说下？
A：这两块是配套 YAML 转换的辅助能力，我核心重点实现的是 YAML 文件自动解析、多层配置合并转换功能；校验、类型生成是基于转换流程拓展的配套工具，主要用来提升开发体验，我的核心改造重心放在 YAML 构建期转换逻辑上。
Q11：插件打包发布成 npm 包这块了解吗？
A：本地开发时直接通过相对路径引入 dist 打包产物即可使用；如果需要多项目复用，可以拆分为独立包打包发布 npm，不过我这个 Demo 仅在自己的对话项目本地使用，没有发包。
