一、引言AI Coding 提升代码质量的关键——知识库的深度建设在当前 AI Coding 快速普及的背景下业界普遍面临一个核心矛盾模型“能写” ≠ “写得对”。尤其在高频迭代、强业务耦合的场景中代码的正确性、可维护性和一致性远比“能生成”更重要。要突破这一瓶颈关键在于让 AI 不仅“会写”更要“懂上下文”——即深刻理解特定项目的技术契约、业务语义与工程惯例。为此我们提出构建一套高质量、结构化的知识体系作为 AI Coding 的“认知基础设施”。这一体系包含两个互补维度Spec 知识库基于规范驱动开发Spec-Driven Development, SDD沉淀的项目级契约与规则RAGRetrieval-Augmented Generation知识库动态接入外部文档、历史方案、最佳实践等非结构化或半结构化知识。二者共同构成 AI 的“上下文感知能力”使其不仅能理解“要做什么”更能精准把握“怎么做才对”。Spec 提供强约束的“硬规则”RAG 提供灵活丰富的“软上下文”。本文将系统阐述这一知识体系的构想、落地现状与未来演进。二、前置知识调研1.Spec简介AI Coding 的“宪法”1.1 什么是SpecSpecSpecification规范 是对软件系统行为、接口、数据格式或业务规则的精确、无歧义、可验证的描述。在 AI Coding 中SPEC 扮演着“宪法”的角色——它明确告诉 AI“代码必须满足哪些条件才算正确”而不是依赖模型自行猜测、模仿或凭“感觉”生成。其核心价值体现在两个层面规范即契约SPEC 是开发者、AI Agent 与系统之间达成的共识性“契约”清晰界定“做什么”What、“为什么做”Why以及“如何做”How。AI 的指令集为大语言模型LLM提供明确、结构化的上下文显著减少幻觉hallucination提升生成代码的准确性与一致性。1.2 Spec Coding VS Vibe Coding随着AI编程普及开发者分化出两种范式Vibe Coding 依赖直觉和意图模仿快但不可靠Spec Coding 严格遵循规范可靠且易维护适合企业级和高要求场景。选择关键在于权衡速度与确定性。对比如下维度Vibe CodingSpec Coding依据依赖开发者或 LLM 对“大致感觉”的主观理解严格遵循书面化、结构化的规范文档生成逻辑“我觉得应该这样写”——基于统计模式与风格模仿“规则要求必须这样写”——基于契约约束与条件满足可靠性易产生幻觉、遗漏边界条件结果不可预测行为可预期、可验证、可审计维护成本初期快后期高需求变更或缺陷修复需反复试错初期需投入后期低只需更新 SPECAI 可自动适配新规则适用场景快速原型、个人项目、探索性编码企业级开发、安全关键系统、合规性要求高的场景2.RAG简介让 LLM “看得见”你的私有知识2.1 什么是RAGRAGRetrieval-Augmented Generation 是一种结合“搜索”与“生成”的技术使 LLM 在回答问题时能参考外部知识库生成更准确、可溯源、事实性强的答案。其工作流程分为三步Retrieve检索根据用户查询从外部知识库如文档、数据库中检索最相关的文本片段Augment增强将检索结果拼接到原始 Prompt 中形成增强上下文Generate生成LLM 基于增强后的上下文生成最终回答。2.2 为什么需要 RAG尽管 LLM 能力强大但在实际应用中仍面临诸多局限知识静态无法访问私有或实时数据容易产生幻觉输出内容可靠性存疑更新成本高昂需要重新训练或微调模型。RAG 提供了一种创新性的解决思路。其核心理念是不求模型“记住一切”而让它“懂得查找”。通过按需检索可信知识源RAG 显著提升了生成内容的准确性、时效性与可溯源性。下表对比了 LLM 与 RAG 在核心维度上的差异直观展现 RAG 如何有效弥补 LLM 的实际应用短板。能力维度传统 LLMRAG知识范围仅限训练数据截止前的公开知识无法访问私有或实时数据可结合外部知识库支持私有文档、最新规范、实时信息知识更新需微调或重新训练成本高、周期长仅需更新检索库无需改动模型低成本快速迭代幻觉风险高无答案时易编造虚假信息低基于真实检索结果生成答案有据可依垂直领域表现泛化能力强但专业深度不足通过领域知识库显著提升专业性与准确性回答相关性依赖 prompt 完整性易遗漏关键上下文动态注入高相关检索片段增强上下文匹配度安全与合规私有数据需输入上下文存在泄露风险原始数据保留在检索层可通过权限控制保障数据安全部署与维护成本模型固定但扩展知识需重训轻量灵活仅维护检索索引适合持续演进2.3 RAG工作流程RAG 系统包含两个核心阶段离线阶段构建知识库在线阶段处理实时查询。以下详细介绍高级 RAG 系统在这两个阶段的关键实现流程。离线阶段知识库构建文档预处理对原始文档进行清洗去除噪声和无关信息智能分块将长文档切分成语义完整、大小适中的文本片段索引增强为文本片段添加元数据如来源、时间、分类和关键词标签向量化编码使用嵌入模型将文本转换为向量表示数据入库将向量与原文一同存储到向量数据库中构建完整的检索索引在线阶段实时查询查询优化对用户问题进行改写、扩展和消歧提升查询表达的准确性向量化检索将优化后的查询转换为向量表示混合召回在向量数据库中执行语义检索与关键词匹配的混合检索策略召回候选文档集重排序使用精排模型对候选文档进行相关性打分与重新排序结果返回将最相关的文档片段提供给大模型用于答案生成2.4 RAG关键技术2.4.1 分块Chunking分块是连接原始知识库与 LLM 有限上下文窗口的关键环节。其核心目标是将大型文档切分为语义完整、长度适中的文本块既满足嵌入模型对输入长度的限制又确保每个片段保留足够的上下文信息以支持精准检索。这一过程不仅直接影响嵌入质量和向量检索的准确性还从根本上决定了最终生成回答的相关性与可靠性。以下是五种用于RAG的分块策略2.4.1.1 固定大小分块Fixed-size chunking固定大小分块是一种将文本按预设长度如字符、单词或 token 数量均匀切分为等长片段的策略。优点实现简单易于自动化所有块大小一致便于批量处理和向量化可通过设置重叠区域overlap部分缓解上下文断裂问题。缺点容易在句子或语义单元中间切断破坏语义完整性关键信息可能被拆分到多个块中降低检索相关性和生成质量2.4.1.2 语义分块Semantic Chunking语义分块是一种基于文本内在语义结构的智能分块方法。它首先将文档按自然语言单元如句子或段落切分然后逐段计算嵌入向量并通过余弦相似度衡量相邻段落的语义关联性。若相似度高则合并为一个块一旦相似度显著下降即视为语义边界开启新块。优点保留完整的语义单元和语言逻辑避免信息割裂每个块包含更连贯、更丰富的上下文信息显著提升检索准确性和生成质量缺点依赖相似度阈值来判断语义边界而该阈值难以统一需针对不同文档调整2.4.1.3 递归分块Recursive Chunking递归分块是一种层次化、自上而下的分块策略。它首先利用文本中天然的分隔符如句号、换行、标题等进行粗粒度切分然后对超出预设长度限制的块递归地进一步拆分直到所有子块都满足大小要求若某一块已符合长度限制则保留原样不再切割。优点相比固定大小分块能更好地保留完整句子和上下文逻辑助于保持语义完整性缺点计算开销略高尤其在深层递归时2.4.1.4 基于文档结构分块Document structure-based chunking基于文档结构的分块Document Structure-based Chunking 是一种利用文档自身层级结构如标题、章节、段落等来划定分块边界的策略。它将每个逻辑单元例如一个章节或带标题的小节作为一个独立的文本块从而在最大程度上保留原文的组织结构和语义完整性。优点紧密贴合文档的原始逻辑结构块内信息高度相关对结构化文档如技术文档、论文、说明书效果尤佳。缺点依赖文档具备清晰、规范的结构对格式混乱或无结构的文本如纯文本日志、网页抓取内容效果有限生成的块长度可能差异很大部分块可能超出嵌入模型或LLM的token限制2.4.1.5 基于LLM分块LLM-based Chunking基于大语言模型的分块LLM-based Chunking 是一种利用大语言模型LLM自身理解能力来生成语义连贯、独立文本块的方法。通过精心设计的提示prompt可以引导 LLM 将原始文档重构成多个语义完整、边界清晰的片段。优点LLM 能深入理解上下文和逻辑关系生成的文本块语义完整、边界合理缺点计算成本最高需对全文调用 LLM推理开销大受限于 LLM 自身的上下文窗口长度处理超长文档时需额外分段策略2.4.2 向量编码EmbeddingEmbedding 是 RAG系统实现语义级检索的核心技术主要应用于检索阶段。其核心思想是将人类可读的非结构化信息如自然语言文本转化为机器可理解、可计算的高维向量表示从而在向量空间中高效、精准地捕捉和匹配语义信息。其关键作用体现在以下两个方面向量空间映射将用户查询与知识库中的文档统一映射到同一个连续的向量空间中使语义相近的内容在该空间中彼此靠近语义相似度计算基于向量之间的相似度度量如余弦相似度快速检索出与用户查询在语义上最相关的文档片段。目前主要的 Embedding 类型主要包括文本 Embedding专门用于处理纯文本数据通过模型如 Sentence-BERT、DPR、BGE 等将句子或段落编码为固定维度的句向量。这是当前 RAG 系统中最广泛采用的嵌入形式多模态Enmedding能够联合编码多种模态的信息如文本、图像、音频等将不同模态的内容映射到一个共享的语义向量空间适用于图文检索、跨模态问答等更复杂的应用场景。2.4.3 查询转换Query Transformation查询转换是在用户输入原始问题后、正式发起检索前对查询语句进行语义澄清、结构优化或意图补全的过程。它的核心作用是弥合用户自然语言表达与知识库专业术语/结构之间的语义鸿沟——通过生成更精准、更完整、更适合检索系统理解的查询形式显著提升召回结果的相关性与覆盖率。主要方法包括2.4.3.1 查询重写Query Rewriting核心思想将用户模糊或笼统的问题转化为更具体、细节更丰富的表述明确关键意图如受众、目标、范围等从而引导检索系统返回更精准、实用的信息避免因问题过于宽泛而得到泛泛而谈的结果。示例用户原问题“怎么学Python”重写后的问题“零基础初学者如何系统学习Python编程语言推荐的学习路径和资源有哪些”2.4.3.2 子查询拆解Sub-query Decomposition核心思想将包含多个意图或维度的复合型问题拆解为若干个单一、明确的子问题分别进行检索后再综合答案确保每个关键方面都被充分覆盖防止因整体匹配失败或注意力分散而导致重要信息遗漏。示例用户原问题“购买新能源汽车时需要考虑哪些因素补贴政策和充电设施是否完善”拆解为“选购新能源汽车时应重点关注哪些参数和配置”“当前国家和地方对新能源汽车有哪些购车补贴政策”“家用充电桩安装条件和流程是什么”2.4.3.3 回退提问Step-back Prompting核心思想当原始问题聚焦于具体现象或应用时先“后退一步”提出一个更高层次、更通用的背景性问题以获取支撑性原理或上下文知识从而为理解或解答原始问题提供更扎实的基础避免因过度聚焦细节而忽略关键背景信息。示例用户原问题“为什么我的手机电池掉电特别快”回退问题“影响智能手机电池续航的主要因素有哪些”2.4.4 检索Retrieval检索是RAG系统中连接用户查询与外部知识库的核心机制其目标是从海量文档中高效、准确地召回与问题最相关的信息片段为后续大模型生成提供高质量上下文支撑。不同检索范式在语义理解能力、关键词敏感性、计算效率和适用场景上各有侧重合理选择或融合多种策略对系统整体性能至关重要。在实际应用中单一检索方法往往难以兼顾精确匹配、语义理解与关系推理等多维需求。因此现代RAG系统普遍摒弃“单打独斗”的检索模式转而采用混合检索Hybrid Search——这已成为当前业界的标准实践。混合检索的核心思想是并行调用多种互补的检索路径再通过智能融合策略整合结果从而在召回广度与排序精度之间取得更优平衡。目前主流系统通常同时集成以下四类检索方式检索方法原理优点缺点适用场景全文检索基于关键词匹配通过倒排索引快速定位包含查询词的文档并利用相关性算法如BM25对结果进行排序强调字面匹配和检索效率。- 查询高效延迟低 - 工程成熟可解释性强- 无语义理解能力 - 对同义词或表达变化不敏感查询含明确关键词如人名、术语稠密向量检索使用模型将查询与文档编码为稠密向量映射到低维、稠密的向量空间中。通过向量相似度匹配语义。- 强大的语义理解能力- 计算与存储开销大 - 可解释性差开放域问答、客服对话等用户表述多样的场景稀疏向量检索使用上下文感知的语言模型为每个词项预测其在当前文本中的重要性权重生成一个高维词汇表大小如 30K、但绝大多数维度为 0 的稀疏向量。检索仍依赖传统倒排索引但排序使用学习到的语义权重。- 兼顾语义与效率- 语义能力有限 - 依赖训练数据与词表覆盖兼顾关键词准确性与语义泛化的混合检索需求。图检索在结构化的知识图谱上进行检索将实体作为节点、关系作为边。查询通过图遍历或图神经网络寻找满足逻辑约束的实体路径- 支持复杂逻辑推理 - 结构清晰、可追溯- 构建成本高 - 难以处理非结构化文本需要多跳推理、强逻辑性的问答任务2.4.5 重排序ReRanking重排序是在初步检索之后对候选文档按与用户问题的语义相关性重新打分和排序的过程。它的核心作用是提升最终送入大模型的上下文质量——通过更精准地判断“哪些段落真正有用”过滤掉表面相关但语义不匹配的内容。无论是在多路召回结果融合后还是单一检索路径下重排序都能显著改善生成效果。以目前广泛使用的 Cross-Encoder 重排模型如 Cohere Rerank、bge-reranker 系列等为例其在 RAG 系统中的典型重排流程如下获取初筛候选从前期检索阶段例如 BM25、稠密向量或稀疏向量召回的结果中合并并选取 Top-K 个候选文档。构造查询-文档对将用户的问题与每个候选文档拼接成一个完整的输入文本便于模型整体理解两者关系。计算相关性得分把每个拼接后的文本对输入 Cross-Encoder 模型。模型会通读整个句子综合判断问题和文档在语义上是否匹配并输出一个 0 到 1 之间的相关性分数——比如 0.9 表示高度相关0.2 表示基本无关。重排序并筛选根据得分对所有候选文档从高到低重新排序最终只保留 Top-N 个最相关的段落如 N 510作为上下文送入大语言模型生成答案。3.MCP简介AI 时代的“Type-C 接口”3.1 什么是MCP模型上下文协议Model Context Protocol简称MCP 是一种专为 LLM 和 AI 应用设计的标准化通信协议旨在解决当前 AI 系统在连接外部工具、数据源和业务逻辑时面临的碎片化、耦合度高、维护困难等问题。简言之MCP 提供了一种通用、动态且自描述的集成机制使 AI 应用如 Claude、Cursor 等能够安全、灵活地发现并调用各类后端服务的能力而无需在代码中硬编码具体的接口细节。类比理解如果把传统 API 比作“专用充电线”每台设备需要特定接口那么 MCP 就是“Type-C”——一个统一、即插即用、支持热插拔和能力协商的智能接口标准。3.2 核心架构MCP 基于 Client-Server 架构包含三个角色主机(Host)运行 MCP 客户端的 AI 应用如 Claude Desktop、Cursor客户端(Client)在主机内运行使其能与 MCP 服务器通信服务器(Server)暴露特定功能并提供数据访问工具(Tools)使 LLM 能够执行具体操作的可调用函数。比如天气查询工具 get_weather可以获取指定地点天气资源(Resources)向 LLM 公开服务器中的数据和内容。比如知识库文档、数据库记录、配置文件等提示 (Prompts)提供可复用的提示词模板。比如翻译提示词模版、数据分析提示词模版等3.3 通信流程MCP 的运行过程可分为两个关键阶段能力交换与运行时调用。前者实现服务发现与接口的动态协商后者负责用户请求的安全执行与响应生成二者协同构建了一个动态、安全且对大语言模型LLM友好的工具集成闭环。3.3.1 阶段一能力交换这是 MCP 会话的初始化阶段通常在 Host 启动或首次连接某个 MCP 服务时触发用于建立通信并动态发现服务器提供的功能。Host 启动 MCP Client 并连接 MCP Server用户在 AI 应用如 Claude Desktop中启用了某个插件例如“天气助手”Host 启动内置的 MCP Client并通过预配置的方式如本地进程、WebSocket URL连接到对应的 MCP Server例如一个运行在localhost:8080/weather-mcp的服务。Client 发送初始化请求MCP Client 向 Server 发送initialize请求{ method: initialize, params: { clientInfo: { name: Claude Desktop, version: 1.5 }, capabilities: { supportsPrompts: true } } }Server 返回自身能力清单MCP Server 响应声明它能提供哪些 Tools工具、Resources资源 和 Prompts提示模板每个都附带结构化元数据如参数 schema、描述、权限等级{ result: { serverInfo: { name: Weather MCP Server, version: 2.1 }, capabilities: { tools: [ { name: get_weather, description: 获取指定城市和日期的天气预报, parameters: { type: object, properties: { location: { type: string, description: 城市名称 }, date: { type: string, format: date, description: 查询日期格式 YYYY-MM-DD } }, required: [location] }, requiresUserConsent: false // 可配置是否需要用户确认 } ], resources: [], prompts: [] } } }Client 注册能力并完成握手MCP Client 解析响应将get_weather工具注册到当前会话的“可用工具集”中。后续 LLM 在生成回复时即可“知道”自己可以调用这个工具。3.3.2 阶段二运行时调用当用户发起具体查询时系统进入运行时阶段执行工具调用并生成最终回答。以用户提问 “明天北京天气怎么样” 为例LLM 分析问题并选择工具Host 将用户输入传递给 LLM。LLM 根据上下文和已注册的工具列表决定调用get_weather并生成工具调用指令{ tool_name: get_weather, arguments: { location: 北京, date: 2025-06-15 } }MCP Client 检查并请求用户授权可选MCP Client 查看该工具的元数据若requiresUserConsent: true→ 弹出确认框“AI 想查询北京天气是否允许”若为false如本例或用户已设置“自动同意”则跳过确认。Client 向 Server 发起工具调用MCP Client 通过协议通道发送call请求{ method: call, params: { name: get_weather, arguments: { location: 北京, date: 2025-06-15 } } }Server 执行工具并返回结果{ result: { temperature: 28, unit: °C, condition: Sunny, summary: 北京明天晴气温 28°C } }Client 将结果注入 LLM 上下文MCP Client 收到结果后将其与原始用户问题一起提交给 LLM工具返回“北京明天晴气温 28°C”LLM 生成自然语言回答LLM 综合信息输出流畅回答LLM返回“明天北京天气晴朗最高气温 28 摄氏度适合外出”。三、落地实践1. 总体架构为提升 AI Coding 在高频、高复杂度业务场景中的采纳率我们构建了“SPEC硬规则 RAG软上下文 MCP标准化接口”三位一体的知识增强体系。该体系通过分层协同兼顾准确性、灵活性与可维护性。本地 SPEC 知识库优势提供强约束、机器可读的契约规范确保生成代码在接口、数据格式、异常处理等方面严格符合业务要求支持自动化验证行为可预期、可审计。适用场景接口定义、代码流程描述、扩展点契约、编码规范、兜底策略等必须遵守的确定性规则。集成方式直接嵌入 IDE 上下文如 Aone Copilot无需 MCP 检索作为 LLM 的基础约束条件实时生效。RAG 知识库优势动态检索非结构化/半结构化私有知识如业务领域知识、术语、历史经验提供语境感知的“软上下文”按需召回避免上下文过载支持低成本持续更新。适用场景需求背景解释、最佳实践参考、隐性规则说明、跨域联调上下文等辅助信息。集成方式通过 MCP 协议封装为标准工具服务按需调用避免上下文膨胀。2. Spec知识库本地 SPEC 知识库已在猫超导购 C 端工程中全面落地形成稳定的工作流所有 Solution 与通用组件均配套.spec/目录明确定义输入输出、实验开关、兜底逻辑等关键要素团队沉淀的通用 Rules如日志规范 GuideLog、参数校验模板、稳定性兜底策略已嵌入 Prompt Rules工程作为系统级约束Aone Copilot 在代码生成前自动加载相关 SPEC 文件将其转化为内部约束条件确保产出符合业务语义与系统架构。SPEC知识库结构目录分层如下天猫超市应用/ ├── .spec/ # 主流程与模块规范 │ ├── mainflow/ # 主流程模块 │ │ │ ├── solution/ # Solution 模块按业务子场景分类 │ │ ├── category/ # 分类相关 │ │ ├── superfiery/ # 超级爆款 │ │ ├── publicentrance/ # 公域入口 │ │ ├── scenecard/ # 场景卡 │ │ ├── cartfeeds/ # 购物车与下单页 Feeds │ │ └── intentioncard/ # 动线插卡 │ │ │ ├── commoncomponents/ # 通用组件模块按能力维度分组 │ │ ├── experiment/ # 实验平台能力ABTest、ADP、IGraph 等 │ │ ├── user/ # 用户相关服务用户画像、分桶等 │ │ ├── item/ # 商品与类目类目服务、ID 映射、缓存等 │ │ ├── coupon/ # 红包召回能力通用红包、超级爆款红包、公域红包等 │ │ └── utility/ # 工具类通用能力定坑工具等 │ │ │ └── descriptive/ # 描述性规范 │ ├── .lifecycle/ # 需求全生命周期目录 │ └── super_fiery_iteration/ # 示例超级爆款迭代需求 │ ├── breakdown/ # 需求拆解文档 │ └── tech/ # 技术方案文档 │ └── .aone_copilot/ # Aone Copilot 规则根目录 └── rules/ # 项目级别rules包括编码规范、项目目录将猫超闪购系统文档体系划分为三大类功能规范整体划分为主流程、解决方案、通用组件和描述性规范四类。主流程聚焦应用框架的核心执行链路解决方案按业务场景组织涵盖分类导购、超级爆款、公域入口、场景卡、换购、动线插卡等多样化导购形态通用组件按能力属性归类为实验、用户、商品、红包、工具等模块支撑多场景复用描述性规范则专门用于统一管理推荐模型策略、前端商品结构等非代码但关键的协作文档。需求生命周期管理围绕具体需求集中管理从需求拆解到技术方案的全过程文档确保需求实现可追溯。项目级规则统一定义编码规范、目录结构及导购架构等项目级工程标准。3. RAG知识库针对SPEC无法覆盖的非结构化与半结构化知识如业务领域术语、历史技术方案、跨团队协作上下文等同时也为解决因文档激增导致模型上下文长度不堪重负这一瓶颈我们启动 RAG 知识库建设目前处于初步落地与验证阶段。本阶段的核心目标是通过统一托管与智能检索将分散在各业务线的静态知识转化为 AI 可按需调用的动态上下文从而在不增加模型输入负担的前提下显著提升生成结果的准确性与业务贴合度。具体进展如下统一托管与知识整合已将部分核心业务文档导入 AI Studio 知识库智能检索能力建设基于 AI Studio 提供的向量检索与重排序能力实现关键词语义混合召回该机制能在用户提问时自动理解意图从海量文档中精准召回最相关的片段轻量集成与 MCP 封装通过 MCP 协议将 RAG 检索能力封装为标准化工具以“即插即用”的方式嵌入 Aone Copilot 工作流试点场景验证在“需求澄清”“错误诊断”“方案参考”等场景中初步验证能有效补充 SPEC 未覆盖的上下文。3.1 AI Studio知识库构建3.1.1 创建知识库在AI Studio平台创建新的知识库实例作为后续文档管理和检索的基础容器。3.1.2 知识库配置根据实际需求配置知识库参数向量模型选择选择适合业务场景的向量化模型文档更新策略设置文档的自动更新和同步机制3.1.3 添加文档支持多种文档格式上传至知识库3.2 MCP服务器构建3.2.1 获取知识库凭证信息获取知识库ID在知识库详情页面复制知识库唯一标识ID知识库AK绑定申请知识库AK免费体验AK绑定在知识库设置中完成AK绑定配置3.2.2 知识库检索API构建以下是关键词检索的API调用示例使用上文获取的AK和知识库ID关键词检索APIcurl --location 检索地址 \ --header X-AK: AK \ --header Request-Origion: SwaggerBootstrapUi \ --header accept: */* \ --header Content-Type: application/json \ --data { question: 需要提出的问题, searchComponent: { inDomainTags: [], keywordComponent: { maxMatchingThreshold: 1.0, retrievalCounts: 3, retrievalType: ORIGIN_CHUNK }, repositoryId: 知识库ID }, source: API }3.2.3 MCP服务器快速部署渐进式策略采用 “本地试点 → 云端迁移” 策略确保稳定性与可维护性。通过“一句话生成MCP服务”prompt快速构建本地MCP服务Aone Copilot集成验证3.3 Aone Copilot实战应用3.3.1 实际提问3.3.2 检索质量验证对比检索过程中返回的RAG知识库片段3.3.3 代码生成基于MCP检索召回的知识库内容能够准确生成符合业务逻辑和技术规范的代码。四、后续规划目前AI Coding 的知识支撑体系已初步落地SPEC 知识库在规范驱动开发中持续发挥作用RAG 知识库也初步验证了其在补充非结构化上下文方面的可行性。在此基础上我们设想下一阶段可围绕以下方向逐步探索优化尝试构建一个更高质量、更具扩展性的智能知识底座SPEC 知识库将持续完善进一步优化spec目录的分层结构提升规范的可发现性与复用性探索建立自动保鲜机制通过代码变更感知等方式确保 SPEC 与实现同步演进避免“规范滞后于代码”。进一步夯实 AI Coding 的“硬规则”基础。RAG 知识库将重点优化以下方向以提升动态上下文的质量与覆盖向量模型调优评估并引入更契合技术文档语义的嵌入模型提升语义匹配精度与跨文档关联能力检索效果增强支持关键词与向量混合检索引入重排序re-ranking等机制提高召回结果的相关性与实用性业务知识库持续建设在现有基础上逐步丰富各业务域的核心文档如导购、推荐、渲染等领域的规范、流程朝着覆盖全面、结构清晰、易于维护的领域知识体系演进。MCP 服务云端化若本地验证顺利将把当前基于本地部署的 MCP 检索服务迁移至云端平台。团队介绍我们是淘天集团-自营技术-导购商详团队致力于打造智能化、体系化的天猫超市消费者导购链路通过产品架构设计与持续优化构建覆盖私域全链路的导购产品体系。我们深度融合AI技术积极探索内容化、场景化等创新导购形态为用户提供更精准、更沉浸的购物体验同时为猫超自营业务提供从B端到C端的一体化导购解决方案驱动业务增长与商业价值提升。参考资料https://blog.dailydoseofds.com/p/5-chunking-strategies-for-rag?refdailydoseofds.comhttps://www.dailydoseofds.com/p/visual-guide-to-model-context-protocol-mcp/https://yonglun.me/rag101/https://zhuanlan.zhihu.com/p/674755232想入门 AI 大模型却找不到清晰方向备考大厂 AI 岗还在四处搜集零散资料别再浪费时间啦2026 年AI 大模型全套学习资料已整理完毕从学习路线到面试真题从工具教程到行业报告一站式覆盖你的所有需求现在全部免费分享扫码免费领取全部内容​一、学习必备100本大模型电子书26 份行业报告 600 套技术PPT帮你看透 AI 趋势想了解大模型的行业动态、商业落地案例大模型电子书这份资料帮你站在 “行业高度” 学 AI1. 100本大模型方向电子书2. 26 份行业研究报告覆盖多领域实践与趋势报告包含阿里、DeepSeek 等权威机构发布的核心内容涵盖职业趋势《AI 职业趋势报告》《中国 AI 人才粮仓模型解析》商业落地《生成式 AI 商业落地白皮书》《AI Agent 应用落地技术白皮书》领域细分《AGI 在金融领域的应用报告》《AI GC 实践案例集》行业监测《2024 年中国大模型季度监测报告》《2025 年中国技术市场发展趋势》。3. 600套技术大会 PPT听行业大咖讲实战PPT 整理自 2024-2025 年热门技术大会包含百度、腾讯、字节等企业的一线实践安全方向《端侧大模型的安全建设》《大模型驱动安全升级腾讯代码安全实践》产品与创新《大模型产品如何创新与创收》《AI 时代的新范式构建 AI 产品》多模态与 Agent《Step-Video 开源模型视频生成进展》《Agentic RAG 的现在与未来》工程落地《从原型到生产AgentOps 加速字节 AI 应用落地》《智能代码助手 CodeFuse 的架构设计》。二、求职必看大厂 AI 岗面试 “弹药库”300 真题 107 道面经直接抱走想冲字节、腾讯、阿里、蔚来等大厂 AI 岗这份面试资料帮你提前 “押题”拒绝临场慌1. 107 道大厂面经覆盖 Prompt、RAG、大模型应用工程师等热门岗位面经整理自 2021-2025 年真实面试场景包含 TPlink、字节、腾讯、蔚来、虾皮、中兴、科大讯飞、京东等企业的高频考题每道题都附带思路解析2. 102 道 AI 大模型真题直击大模型核心考点针对大模型专属考题从概念到实践全面覆盖帮你理清底层逻辑3. 97 道 LLMs 真题聚焦大型语言模型高频问题专门拆解 LLMs 的核心痛点与解决方案比如让很多人头疼的 “复读机问题”三、路线必明 AI 大模型学习路线图1 张图理清核心内容刚接触 AI 大模型不知道该从哪学起这份「AI大模型 学习路线图」直接帮你划重点不用再盲目摸索路线图涵盖 5 大核心板块从基础到进阶层层递进一步步带你从入门到进阶从理论到实战。L1阶段:启航篇丨极速破界AI新时代L1阶段了解大模型的基础知识以及大模型在各个行业的应用和分析学习理解大模型的核心原理、关键技术以及大模型应用场景。L2阶段攻坚篇丨RAG开发实战工坊L2阶段AI大模型RAG应用开发工程主要学习RAG检索增强生成包括Naive RAG、Advanced-RAG以及RAG性能评估还有GraphRAG在内的多个RAG热门项目的分析。L3阶段跃迁篇丨Agent智能体架构设计L3阶段大模型Agent应用架构进阶实现主要学习LangChain、 LIamaIndex框架也会学习到AutoGPT、 MetaGPT等多Agent系统打造Agent智能体。L4阶段精进篇丨模型微调与私有化部署L4阶段大模型的微调和私有化部署更加深入的探讨Transformer架构学习大模型的微调技术利用DeepSpeed、Lamam Factory等工具快速进行模型微调并通过Ollama、vLLM等推理部署框架实现模型的快速部署。L5阶段专题集丨特训篇 【录播课】四、资料领取全套内容免费抱走学 AI 不用再找第二份不管你是 0 基础想入门 AI 大模型还是有基础想冲刺大厂、了解行业趋势这份资料都能满足你现在只需按照提示操作就能免费领取扫码免费领取全部内容​2026 年想抓住 AI 大模型的风口别犹豫这份免费资料就是你的 “起跑线”