推荐语
告别“伪智能”代码，揭秘如何通过Spec+RAG技术让AI程序员真正理解你的项目需求，写出高质量代码。核心内容： 1. AI Coding当前困境与突破方向：从“能写”到“写得对”的转变 2. Spec知识库与RAG知识库的协同作用：构建AI的上下文感知能力 3. Spec Coding与Vibe Coding的对比分析：企业级开发的最佳实践选择
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
一、引言：AI Coding 提升代码质量的关键
——知识库的深度建设
在当前 AI Coding 快速普及的背景下，业界普遍面临一个核心矛盾：模型“能写” ≠ “写得对”。尤其在高频迭代、强业务耦合的场景中，代码的正确性、可维护性和一致性远比“能生成”更重要。
要突破这一瓶颈，关键在于让 AI 不仅“会写”，更要“懂上下文”——即深刻理解特定项目的技术契约、业务语义与工程惯例。为此，我们提出构建一套高质量、结构化的知识体系，作为 AI Coding 的“认知基础设施”。这一体系包含两个互补维度：
Spec 知识库：基于规范驱动开发（Spec-Driven Development, SDD）沉淀的项目级契约与规则；
RAG（Retrieval-Augmented Generation）知识库：动态接入外部文档、历史方案、最佳实践等非结构化或半结构化知识。
二者共同构成 AI 的“上下文感知能力”，使其不仅能理解“要做什么”，更能精准把握“怎么做才对”。Spec 提供强约束的“硬规则”，RAG 提供灵活丰富的“软上下文”。本文将系统阐述这一知识体系的构想、落地现状与未来演进。
1.1 什么是Spec？
Spec（Specification，规范） 是对软件系统行为、接口、数据格式或业务规则的精确、无歧义、可验证的描述。在 AI Coding 中，SPEC 扮演着“宪法”的角色——它明确告诉 AI：“代码必须满足哪些条件才算正确”，而不是依赖模型自行猜测、模仿或凭“感觉”生成。
其核心价值体现在两个层面：
1.2 Spec Coding VS Vibe Coding
随着AI编程普及，开发者分化出两种范式：Vibe Coding 依赖直觉和意图模仿，快但不可靠；Spec Coding 严格遵循规范，可靠且易维护，适合企业级和高要求场景。选择关键在于权衡速度与确定性。对比如下：
维度 |
Vibe Coding |
Spec Coding |
依据 |
依赖开发者或 LLM 对“大致感觉”的主观理解 |
严格遵循书面化、结构化的规范文档 |
生成逻辑 |
“我觉得应该这样写”——基于统计模式与风格模仿 |
“规则要求必须这样写”——基于契约约束与条件满足 |
可靠性 |
易产生幻觉、遗漏边界条件，结果不可预测 |
行为可预期、可验证、可审计 |
维护成本 |
初期快，后期高：需求变更或缺陷修复需反复试错 |
初期需投入，后期低：只需更新 SPEC，AI 可自动适配新规则 |
适用场景 |
快速原型、个人项目、探索性编码 |
企业级开发、安全关键系统、合规性要求高的场景 |
2.RAG简介：让 LLM “看得见”你的私有知识
2.1 什么是RAG？
RAG（Retrieval-Augmented Generation） 是一种结合“搜索”与“生成”的技术，使 LLM 在回答问题时能参考外部知识库，生成更准确、可溯源、事实性强的答案。
其工作流程分为三步：
Retrieve（检索）：根据用户查询，从外部知识库（如文档、数据库）中检索最相关的文本片段；
Augment（增强）：将检索结果拼接到原始 Prompt 中，形成增强上下文；
Generate（生成）：LLM 基于增强后的上下文生成最终回答。
2.2 为什么需要 RAG？
尽管 LLM 能力强大，但在实际应用中仍面临诸多局限：知识静态，无法访问私有或实时数据；容易产生幻觉，输出内容可靠性存疑；更新成本高昂，需要重新训练或微调模型。
RAG 提供了一种创新性的解决思路。其核心理念是：不求模型“记住一切”，而让它“懂得查找”。通过按需检索可信知识源，RAG 显著提升了生成内容的准确性、时效性与可溯源性。
下表对比了 LLM 与 RAG 在核心维度上的差异，直观展现 RAG 如何有效弥补 LLM 的实际应用短板。
能力维度 |
传统 LLM |
RAG |
知识范围 |
仅限训练数据截止前的公开知识，无法访问私有或实时数据 |
可结合外部知识库，支持私有文档、最新规范、实时信息 |
知识更新 |
需微调或重新训练，成本高、周期长 |
仅需更新检索库，无需改动模型，低成本快速迭代 |
幻觉风险 |
高：无答案时易编造虚假信息 |
低：基于真实检索结果生成，答案有据可依 |
垂直领域表现 |
泛化能力强，但专业深度不足 |
通过领域知识库显著提升专业性与准确性 |
回答相关性 |
依赖 prompt 完整性，易遗漏关键上下文 |
动态注入高相关检索片段，增强上下文匹配度 |
安全与合规 |
私有数据需输入上下文，存在泄露风险 |
原始数据保留在检索层，可通过权限控制保障数据安全 |
部署与维护成本 |
模型固定，但扩展知识需重训 |
轻量灵活，仅维护检索索引，适合持续演进 |
2.3 RAG工作流程
RAG 系统包含两个核心阶段：离线阶段构建知识库，在线阶段处理实时查询。以下详细介绍高级 RAG 系统在这两个阶段的关键实现流程。
文档预处理：对原始文档进行清洗，去除噪声和无关信息；
智能分块：将长文档切分成语义完整、大小适中的文本片段；
索引增强：为文本片段添加元数据（如来源、时间、分类）和关键词标签；
向量化编码：使用嵌入模型将文本转换为向量表示；
数据入库：将向量与原文一同存储到向量数据库中，构建完整的检索索引；
查询优化：对用户问题进行改写、扩展和消歧，提升查询表达的准确性；
向量化检索：将优化后的查询转换为向量表示；
混合召回：在向量数据库中执行语义检索与关键词匹配的混合检索策略，召回候选文档集；
重排序：使用精排模型对候选文档进行相关性打分与重新排序；
结果返回：将最相关的文档片段提供给大模型用于答案生成；
2.4 RAG关键技术
2.4.1 分块（Chunking）
分块是连接原始知识库与 LLM 有限上下文窗口的关键环节。其核心目标是将大型文档切分为语义完整、长度适中的文本块，既满足嵌入模型对输入长度的限制，又确保每个片段保留足够的上下文信息以支持精准检索。这一过程不仅直接影响嵌入质量和向量检索的准确性，还从根本上决定了最终生成回答的相关性与可靠性。
以下是五种用于RAG的分块策略：
2.4.1.1 固定大小分块（Fixed-size chunking）
固定大小分块是一种将文本按预设长度（如字符、单词或 token 数量）均匀切分为等长片段的策略。
优点：
缺点：
2.4.1.2 语义分块（Semantic Chunking）
语义分块是一种基于文本内在语义结构的智能分块方法。它首先将文档按自然语言单元（如句子或段落）切分，然后逐段计算嵌入向量，并通过余弦相似度衡量相邻段落的语义关联性。若相似度高，则合并为一个块；一旦相似度显著下降，即视为语义边界，开启新块。
优点：
缺点：
2.4.1.3 递归分块（Recursive Chunking）
递归分块是一种层次化、自上而下的分块策略。它首先利用文本中天然的分隔符（如句号、换行、标题等）进行粗粒度切分，然后对超出预设长度限制的块递归地进一步拆分，直到所有子块都满足大小要求；若某一块已符合长度限制，则保留原样，不再切割。
优点：
缺点：
2.4.1.4 基于文档结构分块（Document structure-based chunking）
基于文档结构的分块（Document Structure-based Chunking） 是一种利用文档自身层级结构（如标题、章节、段落等）来划定分块边界的策略。它将每个逻辑单元（例如一个章节或带标题的小节）作为一个独立的文本块，从而在最大程度上保留原文的组织结构和语义完整性。
优点：
缺点：
2.4.1.5 基于LLM分块（LLM-based Chunking）
基于大语言模型的分块（LLM-based Chunking） 是一种利用大语言模型（LLM）自身理解能力来生成语义连贯、独立文本块的方法。通过精心设计的提示（prompt），可以引导 LLM 将原始文档重构成多个语义完整、边界清晰的片段。
优点：
缺点：
2.4.2 向量编码（Embedding）
Embedding 是 RAG系统实现语义级检索的核心技术，主要应用于检索阶段。其核心思想是将人类可读的非结构化信息（如自然语言文本）转化为机器可理解、可计算的高维向量表示，从而在向量空间中高效、精准地捕捉和匹配语义信息。
其关键作用体现在以下两个方面：
目前主要的 Embedding 类型主要包括：
2.4.3 查询转换（Query Transformation）
查询转换是在用户输入原始问题后、正式发起检索前，对查询语句进行语义澄清、结构优化或意图补全的过程。它的核心作用是弥合用户自然语言表达与知识库专业术语/结构之间的语义鸿沟——通过生成更精准、更完整、更适合检索系统理解的查询形式，显著提升召回结果的相关性与覆盖率。主要方法包括：
2.4.3.1 查询重写（Query Rewriting）
核心思想：将用户模糊或笼统的问题转化为更具体、细节更丰富的表述，明确关键意图（如受众、目标、范围等），从而引导检索系统返回更精准、实用的信息，避免因问题过于宽泛而得到泛泛而谈的结果。
示例：
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 = 5～10），作为上下文送入大语言模型生成答案。
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 服务时触发，用于建立通信并动态发现服务器提供的功能。
{ "method": "initialize", "params": { "clientInfo": { "name": "Claude Desktop", "version": "1.5" }, "capabilities": { "supportsPrompts": true } }}
{ "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": [] } }}
3.3.2 阶段二：运行时调用
当用户发起具体查询时，系统进入运行时阶段，执行工具调用并生成最终回答。以用户提问 “明天北京天气怎么样？” 为例：
{ "tool_name": "get_weather", "arguments": { "location": "北京", "date": "2025-06-15" }}
{ "method": "call", "params": { "name": "get_weather", "arguments": { "location": "北京", "date": "2025-06-15" } }}
{ "result": { "temperature": 28, "unit": "°C", "condition": "Sunny", "summary": "北京明天晴，气温 28°C" }}
为提升 AI Coding 在高频、高复杂度业务场景中的采纳率，我们构建了“SPEC（硬规则） + RAG（软上下文） + MCP（标准化接口）”三位一体的知识增强体系。该体系通过分层协同，兼顾准确性、灵活性与可维护性。
优势：提供强约束、机器可读的契约规范，确保生成代码在接口、数据格式、异常处理等方面严格符合业务要求；支持自动化验证，行为可预期、可审计。
适用场景：接口定义、代码流程描述、扩展点契约、编码规范、兜底策略等必须遵守的确定性规则。
集成方式：直接嵌入 IDE 上下文（如 Aone Copilot），无需 MCP 检索，作为 LLM 的基础约束条件实时生效。
优势：动态检索非结构化/半结构化私有知识（如业务领域知识、术语、历史经验），提供语境感知的“软上下文”；按需召回，避免上下文过载；支持低成本持续更新。
适用场景：需求背景解释、最佳实践参考、隐性规则说明、跨域联调上下文等辅助信息。
集成方式：通过 MCP 协议封装为标准工具服务，按需调用，避免上下文膨胀。
本地 SPEC 知识库已在猫超导购 C 端工程中全面落地，形成稳定的工作流：
所有 Solution 与通用组件均配套 .spec/ 目录，明确定义输入输出、实验开关、兜底逻辑等关键要素；
团队沉淀的通用 Rules（如日志规范 GuideLog、参数校验模板、稳定性兜底策略）已嵌入 Prompt Rules工程，作为系统级约束；
Aone Copilot 在代码生成前自动加载相关 SPEC 文件，将其转化为内部约束条件，确保产出符合业务语义与系统架构。
SPEC知识库结构目录分层如下：
天猫超市应用/├── .spec/ │ ├── mainflow/ │ ││ ├── solution/ │ │ ├── category/ │ │ ├── superfiery/ │ │ ├── publicentrance/ │ │ ├── scenecard/ │ │ ├── cartfeeds/ │ │ └── intentioncard/ │ ││ ├── commoncomponents/ │ │ ├── experiment/ │ │ ├── user/ │ │ ├── item/ │ │ ├── coupon/ │ │ └── utility/ │ ││ └── descriptive/ │├── .lifecycle/ │ └── super_fiery_iteration/ │ ├── breakdown/ │ └── tech/ │ └── .aone_copilot/ └── rules/
功能规范：整体划分为主流程、解决方案、通用组件和描述性规范四类。主流程聚焦应用框架的核心执行链路；解决方案按业务场景组织，涵盖分类导购、超级爆款、公域入口、场景卡、换购、动线插卡等多样化导购形态；通用组件按能力属性归类为实验、用户、商品、红包、工具等模块，支撑多场景复用；描述性规范则专门用于统一管理推荐模型策略、前端商品结构等非代码但关键的协作文档。
需求生命周期管理：围绕具体需求，集中管理从需求拆解到技术方案的全过程文档，确保需求实现可追溯。
项目级规则：统一定义编码规范、目录结构及导购架构等项目级工程标准。
针对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 获取知识库凭证信息
3.2.2 知识库检索API构建
以下是关键词检索的API调用示例（使用上文获取的AK和知识库ID）：
关键词检索API
curl --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服务器快速部署（渐进式策略）
采用 “本地试点 → 云端迁移” 策略，确保稳定性与可维护性。
3.3 Aone Copilot实战应用
3.3.1 实际提问
3.3.2 检索质量验证
对比检索过程中返回的RAG知识库片段：
3.3.3 代码生成
基于MCP检索召回的知识库内容，能够准确生成符合业务逻辑和技术规范的代码。
目前，AI Coding 的知识支撑体系已初步落地：SPEC 知识库在规范驱动开发中持续发挥作用，RAG 知识库也初步验证了其在补充非结构化上下文方面的可行性。在此基础上，我们设想下一阶段可围绕以下方向逐步探索优化，尝试构建一个更高质量、更具扩展性的智能知识底座：
向量模型调优：评估并引入更契合技术文档语义的嵌入模型，提升语义匹配精度与跨文档关联能力；
检索效果增强：支持关键词与向量混合检索，引入重排序（re-ranking）等机制，提高召回结果的相关性与实用性；
业务知识库持续建设：在现有基础上，逐步丰富各业务域的核心文档（如导购、推荐、渲染等领域的规范、流程），朝着覆盖全面、结构清晰、易于维护的领域知识体系演进。
MCP 服务云端化：若本地验证顺利，将把当前基于本地部署的 MCP 检索服务迁移至云端平台。
团队介绍
我们是淘天集团-自营技术-导购&商详团队，致力于打造智能化、体系化的天猫超市消费者导购链路，通过产品架构设计与持续优化，构建覆盖私域全链路的导购产品体系。我们深度融合AI技术，积极探索内容化、场景化等创新导购形态，为用户提供更精准、更沉浸的购物体验，同时为猫超自营业务提供从B端到C端的一体化导购解决方案，驱动业务增长与商业价值提升。
https://blog.dailydoseofds.com/p/5-chunking-strategies-for-rag?ref=dailydoseofds.com
https://www.dailydoseofds.com/p/visual-guide-to-model-context-protocol-mcp/
https://yonglun.me/rag101/
https://zhuanlan.zhihu.com/p/674755232
粤ICP备14082021号
免费POC，
零成本试错
