当设计系统文档有了智能管家用 LangChain 搭建设计规范的问答助手一、深度引言与场景痛点设计系统的文档像一座图书馆——规范条目分类清晰索引完整但新成员走进这座图书馆时面对几百页的规范文档往往不知道该从哪本书开始读。按钮的 hover 状态用什么颜色——这个问题在规范文档中有明确答案但你需要先找到按钮章节再找到状态矩阵子章节再在表格中定位 hover 行最后才能看到颜色值。三步查找每一步都可能走错路。智能问答助手给这座图书馆配了一个管家——你直接问按钮 hover 用什么颜色管家立刻回答var(--color-primary-action-hover)参考规范第 3.2 节。管家的能力不是记忆所有答案而是理解你的问题意图在文档中精准定位相关章节提取答案并附带引用来源。这篇文章解决的核心问题如何用 LangChain 搭建一套设计系统文档的智能问答助手让新成员通过自然语言快速获取规范信息降低设计系统的学习门槛和使用摩擦。二、底层机制与原理深度剖析LangChain 问答助手的核心机制是 RAGRetrieval-Augmented Generation先从文档中检索与问题相关的片段再把检索结果作为上下文喂给大模型生成回答。检索的精准度决定回答的质量。flowchart TD A[用户问题按钮 hover 状态用什么颜色] -- B[问题预处理] B -- B1[意图识别查询交互状态规范] B -- B2[关键词提取按钮 / hover / 颜色] B1 B2 -- C[向量检索层] C -- C1[将问题转为向量嵌入] C -- C2[在设计系统文档向量库中检索最近邻片段] C -- C3[返回 Top-3 最相关文档片段] C1 C2 C3 -- D[上下文组装层] D -- D1[拼接检索片段作为 Prompt 上下文] D -- D2[附加设计系统元数据版本号、适用范围] D -- D3[注入回答格式指令答案 规范引用来源] D1 D2 D3 -- E[大模型生成层] E -- E1[GPT-4o 基于上下文生成回答] E -- E2[答案附带规范章节引用] E -- E3[不确定时标注需要进一步确认] E1 E2 E3 -- F[回答输出] F -- F1[var(--color-primary-action-hover)] F -- F2[参考规范 3.2 节 · 按钮状态矩阵]问题预处理层提取问题的核心意图和关键词。用户的问题可能是模糊的——按钮变色可能指 hover 状态变色也可能指品牌色变更。预处理层把模糊问题拆解为结构化查询意图交互状态规范查询 关键词 {按钮, hover, 颜色}。这步预处理提高了后续检索的命中率。向量检索层是 RAG 的核心。设计系统文档在搭建时已经被切分为片段并转为向量嵌入存入向量库。检索时将用户问题也转为向量嵌入在向量库中找到距离最近的片段语义最相关。Top-3 检索确保上下文足够丰富但不冗长——3 个片段约 1500-2000 字刚好填满大模型的上下文窗口而不溢出。上下文组装层把检索结果组织为大模型可理解的 Prompt。组装的关键是附加元数据——规范版本号、适用范围、相关交叉引用。这些元数据让大模型知道答案的适用边界避免给出过时或不适用的规范信息。大模型生成层基于组装的上下文生成回答。回答必须附带规范章节引用来源让用户可以追溯到原始文档确认。如果上下文中没有足够信息回答问题大模型标注需要进一步确认而非猜测答案避免错误信息误导用户。三、生产级代码实现与最佳实践文档切分与向量库搭建// scripts/design-system-rag/build-vector-store.ts import { RecursiveCharacterTextSplitter } from langchain/text_splitter; import { OpenAIEmbeddings } from langchain/embeddings/openai; import { FaissStore } from langchain/vectorstores/faiss; import fs from fs; import path from path; interface DocSection { title: string; // 规范章节标题 content: string; // 章节内容文本 version: string; // 规范版本号 category: string; // 分类组件 / Token / 交互 / 无障碍 filePath: string; // 原始文件路径用于追溯引用 } // 从设计系统文档目录加载所有 Markdown 文件 async function loadDesignSystemDocs(docDir: string): PromiseDocSection[] { const sections: DocSection[] []; const files fs.readdirSync(docDir, { recursive: true }) .filter(file file.endsWith(.md)); for (const file of files) { const filePath path.join(docDir, file); const content fs.readFileSync(filePath, utf-8); // 解析 Markdown 标题作为章节划分依据 const headingRegex /^## (.)$/gm; let match; const chunks content.split(headingRegex); for (let i 1; i chunks.length; i 2) { sections.push({ title: chunks[i], // 标题 content: chunks[i 1], // 内容 version: v3.2, // 当前规范版本 category: categorizeByTitle(chunks[i]), filePath: file }); } } return sections; } // 根据标题判断章节分类 function categorizeByTitle(title: string): string { if (title.includes(Button) || title.includes(Card) || title.includes(Input)) return 组件; if (title.includes(Token) || title.includes(颜色) || title.includes(间距)) return Token; if (title.includes(交互) || title.includes(状态) || title.includes(动画)) return 交互; if (title.includes(无障碍) || title.includes(ARIA) || title.includes(焦点)) return 无障碍; return 通用; } // 切分文档为向量嵌入片段并存储到向量库 async function buildVectorStore(sections: DocSection[]): PromiseFaissStore { const splitter new RecursiveCharacterTextSplitter({ chunkSize: 500, // 每个片段约 500 字符 chunkOverlap: 50, // 片段间重叠 50 字符避免语义断裂 separators: [\n## , \n### , \n\n, \n, ] // 按标题层级切分 }); // 将每个章节切分为更小的片段 const splitDocs []; for (const section of sections) { const chunks await splitter.splitText(section.content); for (const chunk of chunks) { splitDocs.push({ pageContent: 【${section.category}】${section.title}\n${chunk}, metadata: { title: section.title, version: section.version, category: section.category, filePath: section.filePath } }); } } // 使用 OpenAI Embeddings 将片段转为向量并存入 FAISS 向量库 const embeddings new OpenAIEmbeddings({ openAIApiKey: process.env.OPENAI_API_KEY, modelName: text-embedding-3-small // 使用较小模型降低成本 }); const vectorStore await FaissStore.fromDocuments( splitDocs.map(d ({ pageContent: d.pageContent, metadata: d.metadata })), embeddings ); // 保存向量库到本地文件下次启动时直接加载无需重新嵌入 await vectorStore.save(vector-store/design-system-faiss); return vectorStore; }问答助手 Chain 构建// scripts/design-system-rag/qa-chain.ts import { RetrievalQAChain } from langchain/chains; import { ChatOpenAI } from langchain/chat_models/openai; import { FaissStore } from langchain/vectorstores/faiss; import { OpenAIEmbeddings } from langchain/embeddings/openai; async function createQAChain(): PromiseRetrievalQAChain { // 加载已保存的向量库 const embeddings new OpenAIEmbeddings({ openAIApiKey: process.env.OPENAI_API_KEY, modelName: text-embedding-3-small }); const vectorStore await FaissStore.load( vector-store/design-system-faiss, embeddings ); // 创建检索器返回最相关的 3 个文档片段 const retriever vectorStore.asRetriever({ k: 3, // Top-3 检索 searchType: similarity // 语义相似度检索 }); // 创建大模型实例 const llm new ChatOpenAI({ openAIApiKey: process.env.OPENAI_API_KEY, modelName: gpt-4o, temperature: 0.1 // 低温度确保回答确定性 }); // 构建 QA Chain检索 → 组装上下文 → 生成回答 const chain RetrievalQAChain.fromLLM(llm, retriever, { returnSourceDocuments: true, // 返回引用来源文档 prompt: 你是设计系统规范问答助手。基于以下检索到的规范片段回答用户问题。 回答规则 1. 优先使用检索片段中的信息回答 2. 回答中必须附带规范章节引用来源标题 文件路径 3. 如果检索片段中没有足够信息回答这个问题在当前规范中未明确定义建议咨询设计团队 4. 不猜测、不编造不在检索片段中的信息 5. 如果问题涉及多个规范条目逐一列出每个条目的答案和引用来源 检索到的规范片段 {context} 用户问题{question} }); return chain; } // 执行问答 async function askQuestion(question: string): Promise{ answer: string; sources: Array{ title: string; filePath: string; snippet: string }; } { const chain await createQAChain(); const result await chain.call({ query: question }); return { answer: result.text, sources: result.sourceDocuments.map(doc ({ title: doc.metadata.title, filePath: doc.metadata.filePath, snippet: doc.pageContent.substring(0, 100) })) }; }Slack 集成版问答助手// scripts/design-system-rag/slack-bot.ts import { App } from slack/bolt; const slackApp new App({ signingSecret: process.env.SLACK_SIGNING_SECRET!, token: process.env.SLACK_BOT_TOKEN! }); // 监听设计系统频道中的问题消息 slackApp.message(async ({ message, say }) { // 只处理包含设计系统关键词的消息 const keywords [规范, Token, 组件, 按钮, 间距, 颜色, 无障碍, ARIA, 状态]; const text message.text || ; const isDesignQuestion keywords.some(k text.includes(k)); if (!isDesignQuestion) return; // 调用问答助手 const { answer, sources } await askQuestion(text); // 格式化 Slack 回复消息 const blocks [ { type: section, text: { type: mrkdwn, text: answer } }, { type: context, elements: sources.map(s ({ type: mrkdwn, text: *引用来源*: ${s.title} — ${s.filePath} })) } ]; await say({ blocks }); }); // 启动 Slack Bot (async () { await slackApp.start(process.env.PORT || 3000); console.log(⚡ 设计系统问答助手已启动); })();四、边界分析与架构权衡文档切分的语义边界。RecursiveCharacterTextSplitter 按字符数切分可能把一个完整的规范条目比如按钮状态矩阵表格切成两半前半截在片段 A后半截在片段 B。检索时可能只命中片段 A大模型看不到完整的表格回答可能不完整。解决方案使用 Markdown 标题作为切分优先边界——优先在标题处切分只在标题间隔太长时才按字符数二次切分。这保持了章节的语义完整性。向量检索的召回率。Top-3 检索可能在某些问题上召回不够——用户问设计系统中所有使用主色的组件有哪些这个问题需要扫描大量章节才能完整回答Top-3 只能覆盖部分。解决方案对于这类广域查询将 k 值提升到 8-10但增加大模型对多片段的汇总能力。代价是 Prompt 上下文变长API 成本增加。规范版本漂移。向量库中的文档片段标注了版本号但设计系统持续更新——新版本规范发布后向量库需要重建。如果不重建问答助手可能给出过时的答案。解决方案在 CI 中设置定期重建任务——每次规范文档有 Git 提交时自动触发向量库重建确保检索结果始终是最新的。重建耗时约 5-10 分钟取决于文档量在非工作时间执行不影响用户体验。大模型的幻觉风险。RAG 框架通过上下文约束降低幻觉概率但不完全消除——大模型可能在检索片段的基础上推理出看似合理但实际不在规范中的结论。Prompt 中的规则 4不编造不在检索片段中的信息是防线但大模型偶尔会违反。解决方案在回答后增加一步自动验证——用规则引擎检查回答中提到的 Token 名、组件名是否确实存在于设计系统中验证失败时标注此回答需要人工确认。五、总结设计系统文档的智能问答助手不是替代文档而是加速文档的检索和消化——你不需要从几百页中找到答案只需要问一句话。RAG 框架确保回答基于真实规范而非模型猜测引用来源让答案可追溯到原始文档三重防线检索约束、Prompt 规则、自动验证降低幻觉风险。LangChain 提供了 RAG 的基础设施——文档切分、向量嵌入、检索组装、大模型生成每个环节都有成熟的组件。搭建助手的难点不在技术实现而在文档质量和检索精准度——文档写得越结构化切分越精确检索命中率越高回答质量越好。问答助手是设计系统活起来的第一步——从被动查阅到主动服务。下一步是让助手不仅能回答问题还能执行操作——把这个按钮的 hover 颜色改成 Token 引用助手直接修改代码并提交 PR。从问答到执行是设计系统智能化从管家到助手的跃迁。
