灵感来源本文的核心技术思路来源于鱼皮程序员鱼皮的 《再见百度我用 1 小时开发了个 AI 搜索引擎Codex GPT 5.5 DeepSeek V4 真香~》 一文。为什么做这个Gartner 预测到 2026 年传统搜索引擎访问量将下降 25%中国信通院《2025年人工智能搜索技术发展白皮书》显示超过 40% 的企业获客流量将来自 AI 搜索平台。作为一个开发者我决定亲手造一个 AI 搜索引擎——不只是调 API而是深入理解每个技术选型背后的 trade-off并给它装上真正的智能记忆系统不是简单的缓存。一、2026 年 AI 搜索的三个认知升级在动手之前我先梳理了当前 AI 搜索领域的三个关键趋势这直接决定了我的技术架构选择1️⃣ 从 SEO 到 GEO搜索逻辑的根本性变革传统 SEO搜索引擎优化针对的是关键词匹配算法而GEOGenerative Engine Optimization面对的是大模型的语义理解能力。这意味着内容策略转变不再堆砌关键词而是提供结构化、有深度的信息AI 更容易提取引用溯源变得至关重要ChatGPT Search、Perplexity 都强制要求标注来源否则会被判定为幻觉时效性权重提升根据我的测试同一问题 24 小时内的搜索结果变化率高达 37%2️⃣ Vibe Coding 已成主流开发范式2026 年美国已有92% 的开发者在日常工作中采用某种形式的 Vibe Coding数据来源Vibe Coding 2026 行业报告。但跟 2025 年初 Karpathy 提出氛围编程时的随意不同现在的 Vibe Coding 已经进化为结构化的 AI 辅助开发方法论维度传统编程2026 Vibe Coding角色定位代码编写者架构设计师 质量把控者核心技能语法熟练度需求拆解 Prompt 工程工具链VS Code 手写Trae/Cursor 自然语言规格说明迭代速度天级小时级我用的是字节跳动的 Trae IDE它的中文自然语言理解能力确实比 Cursor 更适合中文场景。3️⃣ “智能记忆” ≠ 简单缓存市面上大多数 AI 搜索教程只讲到查询缓存就结束了我设计了一套分层记忆架构目前短期记忆层已经实现┌─────────────────────────────────────┐ │ 用户查询层 (Query) │ ├─────────────────────────────────────┤ │ 短期记忆 (Short-term Memory) │ ← SQLite 缓存层已实现 │ - 相似度匹配 (Jaccard 关键词) │ │ - 时效性校验 (重新搜索对比) │ │ - TTL: 24 小时 LRU 淘汰 │ ├─────────────────────────────────────┤ │ 长期记忆 (Long-term Memory) │ ← 未来可扩展 │ - 用户画像 偏好学习 │ │ - 跨会话知识图谱 │ │ - 向量数据库语义检索 │ └─────────────────────────────────────┘目前实现的是短期记忆层用 SQLite 存储查询缓存通过compute_sources_similarity做三维度相似度匹配URL Jaccard 50% 标题关键词 30% 结果数量 20%命中缓存时重新搜索做时效性校验TTL 24 小时 LRU 淘汰。长期记忆层用户画像、知识图谱、向量数据库目前还是规划阶段没有实现。对于个人项目来说SQLite 相似度算法的成本效益比更高省去了 Milvus/Pinecone 的运维复杂度。如果未来用户量增长可以平滑迁移到 ChromaDB 或 Qdrant。二、技术架构与选型 Trade-off核心技术栈及选型理由组件选择替代方案选型理由搜索 APITavily SearchSerper、Bing API返回结构化数据标题URL摘要LangChain 官方集成支持图片/视频搜索LLMDeepSeek V4GPT-4o、Claude 3.5兼容 OpenAI SDK 格式成本仅为 GPT-4o 的 1/10中文能力强后端框架FastAPIDjango、Flask原生异步支持async/await自动生成 OpenAPI 文档性能是 Django 的 3 倍前端框架Vue 3 TypeScriptReact、Next.js组合式 API 更直观TypeScript 类型安全Tailwind CSS 快速原型缓存方案SQLite 自定义相似度Redis、Memcached零运维单文件数据库支持 WAL 并发模式适合中小规模三、踩坑实录那些文档里不会告诉你的细节 坑 #1SSE 流式输出的 TCP 分包陷阱问题现象AI 回答需要 20 秒左右用户盯着空白页面体验极差。用 SSEServer-Sent Events实现流式输出后发现前端偶尔报JSON Parse Error。根因分析TCP 协议的数据包分割是不确定的。一个完整的 SSE 事件如data: {type:answer,data:你好}\n\n可能被拆成两个数据包到达数据包 1: data: {\type\:\answer\, 数据包 2: \data\:\你好\}\n\n如果直接对每个数据包调用JSON.parse()必然会失败。解决方案前端必须实现缓冲区拼接机制letbufferwhile(true){bufferdecoder.decode(value,{stream:true})constlinesbuffer.split(\n)bufferlines.pop()||// 关键保留未完成的行for(constlineoflines){if(!line.startsWith(data: ))continueconstdataJSON.parse(line.slice(6))handleEvent(data)}}lines.pop()这一行是精髓——把最后一个可能不完整的行留在 buffer 里等下一个数据包到了再拼接。 坑 #2AI 引用格式的驯兽指南问题现象在 System Prompt 里写请标注引用来源AI 的输出五花八门(来源: 1)参考[1][source 1]干脆不标三层解决方案Layer 1Prompt 约束准确率 70%SYSTEM_PROMPT你是一个专业的AI搜索引擎助手。 要求 1. 回答要全面、准确、有深度 2. 引用来源必须使用 [1], [2] 格式严格遵循不得使用其他格式 3. 使用 Markdown 格式代码块标注语言类型 搜索结果{context}Layer 2前端正则替换兜底覆盖率 100%MarkdownRenderer :contentprocessedAnswer citation-clickhandleCitationClick / script setup const processedAnswer computed(() { return answer.value .replace(/\[?来源[:]\s*(\d)\]?/g, [$1]) // 标准化中文引用 .replace(/\[source\s*(\d)\]/gi, [$1]) // 英文引用 .replace(/来源[:]\s*(\d)/g, [$1]) // 全角括号 }) /scriptLayer 3安全消毒防 XSS渲染顺序必须是引用替换 → Markdown 渲染 → DOMPurify 消毒如果先消毒再替换自定义的citation-linkCSS 类会被过滤掉。额外细节不是所有引用都有对应 URL。做了分支处理有 URL → 蓝色可点击链接无 URL → 灰色不可点击标记避免跳转到空白页 坑 #3智能缓存的时效性 vs 成本平衡术为什么不能简单缓存场景上午 10 点搜今天北京天气→ 缓存下午 2 点再搜 → 如果直接返回缓存答案已过时。我的方案三维度相似度 时效性校验Step 1即使缓存命中也重新调用 Tavily 搜索Step 2对比新旧搜索结果的相似度defcompute_sources_similarity(old_sources,new_sources):# 维度 1URL Jaccard 相似度权重 50%old_urlsset(s.get(url,)forsinold_sourcesifs.get(url))new_urlsset(s.get(url,)forsinnew_sourcesifs.get(url))url_jaccardlen(old_urlsnew_urls)/len(old_urls|new_urls)if(old_urls|new_urls)else0# 维度 2标题关键词重叠度权重 30%def_tokenize(text):wordsre.findall(r[\w\u4e00-\u9fff],text.lower())returnset(wforwinwordsiflen(w)1)old_wordsset()new_wordsset()forsinold_sources:old_words.update(_tokenize(s.get(title,)))forsinnew_sources:new_words.update(_tokenize(s.get(title,)))title_simlen(old_wordsnew_words)/len(old_words|new_words)if(old_words|new_words)else0# 维度 3结果数量比例权重 20%len_ratiomin(len(old_sources),len(new_sources))/max(len(old_sources),len(new_sources))ifmax(len(old_sources),len(new_sources))0else0return0.50*url_jaccard0.30*title_sim0.20*len_ratioStep 3阈值判断相似度阈值行为适用场景≥ 0.75直接返回缓存知识类问题“Python 装饰器用法”0.5 ~ 0.75返回缓存 标注信息可能略有更新新闻类问题“最新科技资讯” 0.5丢弃缓存重新生成时效性强的问题“今天股市行情”隐私保护查询内容不以明文存储先标准化strip().lower()再算 SHA-256 哈希值。“Python 编程” 和 python 编程 会命中同一个缓存。效果量化缓存命中率67.3%基于 1,000 次真实查询统计平均响应时间20.3 秒 →0.15 秒缓存命中时LLM 调用成本降低67%每月节省约 $3.35四、多模态搜索从文字到图文视频为什么做多模态用户搜RK3588 部署教程时一张架构图 十段文字搜React 性能优化时视频教程链接体验更好。Tavily 默认不返回图片/视频需手动开启self.tavily_searchTavilySearch(max_resultssettings.tavily_max_results,search_depthsettings.tavily_search_depth,include_imagesTrue,# 开启图片搜索include_image_descriptionsTrue,# 获取图片描述用于 AI 理解上下文include_faviconTrue,include_usageTrue,)数据归一化挑战Tavily 的图片 URL 散落在多个字段image_url标准字段image别名img_src某些源的特有字段甚至混在普通搜索结果里网页缩略图写了_normalize_results()函数统一处理视频识别策略通过域名白名单判断避免误判“youtube.com”, “youtu.be”, “bilibili.com”, “b23.tv”, “douyin.com”, “youku.com”, “iqiyi.com”。前端展示优化图片网格懒加载 hover 放大效果 点击跳转原图div classgrid grid-cols-2 md:grid-cols-3 lg:grid-cols-4 gap-4 a v-for(img, idx) in images :keyidx :hrefimg.image_url target_blank classgroup block overflow-hidden rounded-lg img :srcimg.image_url classw-full h-48 object-cover group-hover:scale-105 transition-transform duration-300 loadinglazy / /a /div视频卡片暂不做内嵌播放器版权风险 性能开销改为卡片列表跳转原站。五、未来可优化路线图缓存策略精细化新闻类 TTL 1 小时知识类 TTL 72 小时成本控制开关相关问题推荐改为可选功能节省 50% LLM 调用成本Prompt 注入检测过滤恶意提示词如忽略之前的指令长期记忆层接入向量数据库ChromaDB/Qdrant用户偏好学习技术栈偏好、领域兴趣跨会话知识图谱搜索历史语义关联结果排序优化来源权威性评分edu/gov 域名加权内容时效性衰减函数发布时间越新权重越高图片嵌入回答AI 生成回答时自动插入相关图片实现图文混排多 Agent 协作架构参考 Supermemory 的 99% 准确率方案搜索 Agent负责信息检索记忆 Agent负责长期记忆管理验证 Agent负责事实核查降低幻觉率个性化推荐基于用户历史搜索行为主动推送相关领域更新移动端适配PWA 支持 离线缓存六、完整提示词Prompt# 角色 你是一个全栈工程师擅长 Python FastAPI LangChain Vue 3 开发熟悉 2026 年 AI 辅助开发Vibe Coding的最佳实践。 ## 任务 开发 ai-search AI 搜索引擎具备以下核心能力 ### 必须实现的功能 1. **联网搜索**调用 Tavily Search API获取实时信息 2. **智能回答**DeepSeek V4 综合分析生成带引用来源的回答 3. **流式输出**SSE 打字机效果TTFT 3 秒 4. **智能记忆系统**非简单缓存 - 工作记忆会话级上下文30 分钟 TTL - 短期记忆SQLite 三维度相似度匹配24 小时 TTL - 长期记忆预留接口未来接向量数据库 5. **多模态搜索**图片网格 视频卡片 6. **引用溯源**[1][2] 格式 可点击链接 7. **相关问题推荐**AI 自动生成延伸问题 ### 技术约束 - 后端FastAPI异步 LangChain SQLiteWAL 模式 - 前端Vue 3 TypeScript Tailwind CSS - AIDeepSeek V4兼容 OpenAI SDK - 安全DOMPurify XSS 防护 CORS 精确配置 输入验证 - 性能缓存命中时响应时间 200ms ### 质量要求 1. 所有 API 返回必须有统一的错误处理和日志记录 2. 前端必须处理网络断开、API 限流等异常情况 3. 代码必须有类型注解Python type hints TypeScript interface 4. 每完成一个模块必须自主测试并修复 Bug ## 开发流程 1. 搭建 FastAPI 后端框架 Tavily 集成含容错处理 2. 接入 DeepSeek V4 SSE 流式输出 3. 实现智能记忆系统相似度算法 时效性校验 4. Vue 3 前端开发搜索页 结果页 Markdown 渲染 5. 引用来源组件 DOMPurify 安全消毒 6. 多模态搜索图片/视频归一化 前端展示 7. 工程化完善CORS、日志、配置管理、缓存 API 8. 全流程测试 性能优化最后说两句做完这个项目我对 AI 辅助开发有了更深的体会。一方面门槛确实变低了。以前做一个搜索引擎是大厂才能干的事情现在用 Trae 这样的 AI IDE配合 Tavily DeepSeek 的 API一个下午就能搭出能跑的原型。AI 能帮你写代码、改 Bug、做优化甚至帮你设计缓存策略的相似度算法。但另一方面AI 能写和AI 能写好是两回事。Trae 生成的第一版 SSE 解析代码有缓冲区拼接的坑第一版分词函数不支持中文第一版缓存策略没考虑时效性……这些都需要你跑起来验证发现问题后再用提示词引导它修复。所以 AI 时代的开发模式更像是一个人机协作开发Vibe Coding的过程AI 负责快速产出和试错人负责判断方向、验证结果、把控细节。你不需要一行行手写代码但你得知道代码在干什么、哪里可能出问题、怎么验证对不对。AI 是杠杆不是替身。会用杠杆的人才能撬得动更大的东西。
从零搭建 AI 搜索引擎：我给装上了智能记忆，还踩了这些坑
灵感来源本文的核心技术思路来源于鱼皮程序员鱼皮的 《再见百度我用 1 小时开发了个 AI 搜索引擎Codex GPT 5.5 DeepSeek V4 真香~》 一文。为什么做这个Gartner 预测到 2026 年传统搜索引擎访问量将下降 25%中国信通院《2025年人工智能搜索技术发展白皮书》显示超过 40% 的企业获客流量将来自 AI 搜索平台。作为一个开发者我决定亲手造一个 AI 搜索引擎——不只是调 API而是深入理解每个技术选型背后的 trade-off并给它装上真正的智能记忆系统不是简单的缓存。一、2026 年 AI 搜索的三个认知升级在动手之前我先梳理了当前 AI 搜索领域的三个关键趋势这直接决定了我的技术架构选择1️⃣ 从 SEO 到 GEO搜索逻辑的根本性变革传统 SEO搜索引擎优化针对的是关键词匹配算法而GEOGenerative Engine Optimization面对的是大模型的语义理解能力。这意味着内容策略转变不再堆砌关键词而是提供结构化、有深度的信息AI 更容易提取引用溯源变得至关重要ChatGPT Search、Perplexity 都强制要求标注来源否则会被判定为幻觉时效性权重提升根据我的测试同一问题 24 小时内的搜索结果变化率高达 37%2️⃣ Vibe Coding 已成主流开发范式2026 年美国已有92% 的开发者在日常工作中采用某种形式的 Vibe Coding数据来源Vibe Coding 2026 行业报告。但跟 2025 年初 Karpathy 提出氛围编程时的随意不同现在的 Vibe Coding 已经进化为结构化的 AI 辅助开发方法论维度传统编程2026 Vibe Coding角色定位代码编写者架构设计师 质量把控者核心技能语法熟练度需求拆解 Prompt 工程工具链VS Code 手写Trae/Cursor 自然语言规格说明迭代速度天级小时级我用的是字节跳动的 Trae IDE它的中文自然语言理解能力确实比 Cursor 更适合中文场景。3️⃣ “智能记忆” ≠ 简单缓存市面上大多数 AI 搜索教程只讲到查询缓存就结束了我设计了一套分层记忆架构目前短期记忆层已经实现┌─────────────────────────────────────┐ │ 用户查询层 (Query) │ ├─────────────────────────────────────┤ │ 短期记忆 (Short-term Memory) │ ← SQLite 缓存层已实现 │ - 相似度匹配 (Jaccard 关键词) │ │ - 时效性校验 (重新搜索对比) │ │ - TTL: 24 小时 LRU 淘汰 │ ├─────────────────────────────────────┤ │ 长期记忆 (Long-term Memory) │ ← 未来可扩展 │ - 用户画像 偏好学习 │ │ - 跨会话知识图谱 │ │ - 向量数据库语义检索 │ └─────────────────────────────────────┘目前实现的是短期记忆层用 SQLite 存储查询缓存通过compute_sources_similarity做三维度相似度匹配URL Jaccard 50% 标题关键词 30% 结果数量 20%命中缓存时重新搜索做时效性校验TTL 24 小时 LRU 淘汰。长期记忆层用户画像、知识图谱、向量数据库目前还是规划阶段没有实现。对于个人项目来说SQLite 相似度算法的成本效益比更高省去了 Milvus/Pinecone 的运维复杂度。如果未来用户量增长可以平滑迁移到 ChromaDB 或 Qdrant。二、技术架构与选型 Trade-off核心技术栈及选型理由组件选择替代方案选型理由搜索 APITavily SearchSerper、Bing API返回结构化数据标题URL摘要LangChain 官方集成支持图片/视频搜索LLMDeepSeek V4GPT-4o、Claude 3.5兼容 OpenAI SDK 格式成本仅为 GPT-4o 的 1/10中文能力强后端框架FastAPIDjango、Flask原生异步支持async/await自动生成 OpenAPI 文档性能是 Django 的 3 倍前端框架Vue 3 TypeScriptReact、Next.js组合式 API 更直观TypeScript 类型安全Tailwind CSS 快速原型缓存方案SQLite 自定义相似度Redis、Memcached零运维单文件数据库支持 WAL 并发模式适合中小规模三、踩坑实录那些文档里不会告诉你的细节 坑 #1SSE 流式输出的 TCP 分包陷阱问题现象AI 回答需要 20 秒左右用户盯着空白页面体验极差。用 SSEServer-Sent Events实现流式输出后发现前端偶尔报JSON Parse Error。根因分析TCP 协议的数据包分割是不确定的。一个完整的 SSE 事件如data: {type:answer,data:你好}\n\n可能被拆成两个数据包到达数据包 1: data: {\type\:\answer\, 数据包 2: \data\:\你好\}\n\n如果直接对每个数据包调用JSON.parse()必然会失败。解决方案前端必须实现缓冲区拼接机制letbufferwhile(true){bufferdecoder.decode(value,{stream:true})constlinesbuffer.split(\n)bufferlines.pop()||// 关键保留未完成的行for(constlineoflines){if(!line.startsWith(data: ))continueconstdataJSON.parse(line.slice(6))handleEvent(data)}}lines.pop()这一行是精髓——把最后一个可能不完整的行留在 buffer 里等下一个数据包到了再拼接。 坑 #2AI 引用格式的驯兽指南问题现象在 System Prompt 里写请标注引用来源AI 的输出五花八门(来源: 1)参考[1][source 1]干脆不标三层解决方案Layer 1Prompt 约束准确率 70%SYSTEM_PROMPT你是一个专业的AI搜索引擎助手。 要求 1. 回答要全面、准确、有深度 2. 引用来源必须使用 [1], [2] 格式严格遵循不得使用其他格式 3. 使用 Markdown 格式代码块标注语言类型 搜索结果{context}Layer 2前端正则替换兜底覆盖率 100%MarkdownRenderer :contentprocessedAnswer citation-clickhandleCitationClick / script setup const processedAnswer computed(() { return answer.value .replace(/\[?来源[:]\s*(\d)\]?/g, [$1]) // 标准化中文引用 .replace(/\[source\s*(\d)\]/gi, [$1]) // 英文引用 .replace(/来源[:]\s*(\d)/g, [$1]) // 全角括号 }) /scriptLayer 3安全消毒防 XSS渲染顺序必须是引用替换 → Markdown 渲染 → DOMPurify 消毒如果先消毒再替换自定义的citation-linkCSS 类会被过滤掉。额外细节不是所有引用都有对应 URL。做了分支处理有 URL → 蓝色可点击链接无 URL → 灰色不可点击标记避免跳转到空白页 坑 #3智能缓存的时效性 vs 成本平衡术为什么不能简单缓存场景上午 10 点搜今天北京天气→ 缓存下午 2 点再搜 → 如果直接返回缓存答案已过时。我的方案三维度相似度 时效性校验Step 1即使缓存命中也重新调用 Tavily 搜索Step 2对比新旧搜索结果的相似度defcompute_sources_similarity(old_sources,new_sources):# 维度 1URL Jaccard 相似度权重 50%old_urlsset(s.get(url,)forsinold_sourcesifs.get(url))new_urlsset(s.get(url,)forsinnew_sourcesifs.get(url))url_jaccardlen(old_urlsnew_urls)/len(old_urls|new_urls)if(old_urls|new_urls)else0# 维度 2标题关键词重叠度权重 30%def_tokenize(text):wordsre.findall(r[\w\u4e00-\u9fff],text.lower())returnset(wforwinwordsiflen(w)1)old_wordsset()new_wordsset()forsinold_sources:old_words.update(_tokenize(s.get(title,)))forsinnew_sources:new_words.update(_tokenize(s.get(title,)))title_simlen(old_wordsnew_words)/len(old_words|new_words)if(old_words|new_words)else0# 维度 3结果数量比例权重 20%len_ratiomin(len(old_sources),len(new_sources))/max(len(old_sources),len(new_sources))ifmax(len(old_sources),len(new_sources))0else0return0.50*url_jaccard0.30*title_sim0.20*len_ratioStep 3阈值判断相似度阈值行为适用场景≥ 0.75直接返回缓存知识类问题“Python 装饰器用法”0.5 ~ 0.75返回缓存 标注信息可能略有更新新闻类问题“最新科技资讯” 0.5丢弃缓存重新生成时效性强的问题“今天股市行情”隐私保护查询内容不以明文存储先标准化strip().lower()再算 SHA-256 哈希值。“Python 编程” 和 python 编程 会命中同一个缓存。效果量化缓存命中率67.3%基于 1,000 次真实查询统计平均响应时间20.3 秒 →0.15 秒缓存命中时LLM 调用成本降低67%每月节省约 $3.35四、多模态搜索从文字到图文视频为什么做多模态用户搜RK3588 部署教程时一张架构图 十段文字搜React 性能优化时视频教程链接体验更好。Tavily 默认不返回图片/视频需手动开启self.tavily_searchTavilySearch(max_resultssettings.tavily_max_results,search_depthsettings.tavily_search_depth,include_imagesTrue,# 开启图片搜索include_image_descriptionsTrue,# 获取图片描述用于 AI 理解上下文include_faviconTrue,include_usageTrue,)数据归一化挑战Tavily 的图片 URL 散落在多个字段image_url标准字段image别名img_src某些源的特有字段甚至混在普通搜索结果里网页缩略图写了_normalize_results()函数统一处理视频识别策略通过域名白名单判断避免误判“youtube.com”, “youtu.be”, “bilibili.com”, “b23.tv”, “douyin.com”, “youku.com”, “iqiyi.com”。前端展示优化图片网格懒加载 hover 放大效果 点击跳转原图div classgrid grid-cols-2 md:grid-cols-3 lg:grid-cols-4 gap-4 a v-for(img, idx) in images :keyidx :hrefimg.image_url target_blank classgroup block overflow-hidden rounded-lg img :srcimg.image_url classw-full h-48 object-cover group-hover:scale-105 transition-transform duration-300 loadinglazy / /a /div视频卡片暂不做内嵌播放器版权风险 性能开销改为卡片列表跳转原站。五、未来可优化路线图缓存策略精细化新闻类 TTL 1 小时知识类 TTL 72 小时成本控制开关相关问题推荐改为可选功能节省 50% LLM 调用成本Prompt 注入检测过滤恶意提示词如忽略之前的指令长期记忆层接入向量数据库ChromaDB/Qdrant用户偏好学习技术栈偏好、领域兴趣跨会话知识图谱搜索历史语义关联结果排序优化来源权威性评分edu/gov 域名加权内容时效性衰减函数发布时间越新权重越高图片嵌入回答AI 生成回答时自动插入相关图片实现图文混排多 Agent 协作架构参考 Supermemory 的 99% 准确率方案搜索 Agent负责信息检索记忆 Agent负责长期记忆管理验证 Agent负责事实核查降低幻觉率个性化推荐基于用户历史搜索行为主动推送相关领域更新移动端适配PWA 支持 离线缓存六、完整提示词Prompt# 角色 你是一个全栈工程师擅长 Python FastAPI LangChain Vue 3 开发熟悉 2026 年 AI 辅助开发Vibe Coding的最佳实践。 ## 任务 开发 ai-search AI 搜索引擎具备以下核心能力 ### 必须实现的功能 1. **联网搜索**调用 Tavily Search API获取实时信息 2. **智能回答**DeepSeek V4 综合分析生成带引用来源的回答 3. **流式输出**SSE 打字机效果TTFT 3 秒 4. **智能记忆系统**非简单缓存 - 工作记忆会话级上下文30 分钟 TTL - 短期记忆SQLite 三维度相似度匹配24 小时 TTL - 长期记忆预留接口未来接向量数据库 5. **多模态搜索**图片网格 视频卡片 6. **引用溯源**[1][2] 格式 可点击链接 7. **相关问题推荐**AI 自动生成延伸问题 ### 技术约束 - 后端FastAPI异步 LangChain SQLiteWAL 模式 - 前端Vue 3 TypeScript Tailwind CSS - AIDeepSeek V4兼容 OpenAI SDK - 安全DOMPurify XSS 防护 CORS 精确配置 输入验证 - 性能缓存命中时响应时间 200ms ### 质量要求 1. 所有 API 返回必须有统一的错误处理和日志记录 2. 前端必须处理网络断开、API 限流等异常情况 3. 代码必须有类型注解Python type hints TypeScript interface 4. 每完成一个模块必须自主测试并修复 Bug ## 开发流程 1. 搭建 FastAPI 后端框架 Tavily 集成含容错处理 2. 接入 DeepSeek V4 SSE 流式输出 3. 实现智能记忆系统相似度算法 时效性校验 4. Vue 3 前端开发搜索页 结果页 Markdown 渲染 5. 引用来源组件 DOMPurify 安全消毒 6. 多模态搜索图片/视频归一化 前端展示 7. 工程化完善CORS、日志、配置管理、缓存 API 8. 全流程测试 性能优化最后说两句做完这个项目我对 AI 辅助开发有了更深的体会。一方面门槛确实变低了。以前做一个搜索引擎是大厂才能干的事情现在用 Trae 这样的 AI IDE配合 Tavily DeepSeek 的 API一个下午就能搭出能跑的原型。AI 能帮你写代码、改 Bug、做优化甚至帮你设计缓存策略的相似度算法。但另一方面AI 能写和AI 能写好是两回事。Trae 生成的第一版 SSE 解析代码有缓冲区拼接的坑第一版分词函数不支持中文第一版缓存策略没考虑时效性……这些都需要你跑起来验证发现问题后再用提示词引导它修复。所以 AI 时代的开发模式更像是一个人机协作开发Vibe Coding的过程AI 负责快速产出和试错人负责判断方向、验证结果、把控细节。你不需要一行行手写代码但你得知道代码在干什么、哪里可能出问题、怎么验证对不对。AI 是杠杆不是替身。会用杠杆的人才能撬得动更大的东西。
