聊聊AI“又”解决了一个数学难题

### 聊聊之前的事情 Anthropic Claude ：将费马大定理的证明形式化为 1300 万行 Lean 代码，耗时约11天。 引起了轰动。 问：对了嘛？ 根本不对。 举个例子就是：你和父母说，你是从未来穿越来的，彩票中奖号码是1 3 5 7 9。 然后父母高高兴兴的买了一张，发现中奖号码是2 11 13 15 17。 我们别问预测的准不准，就问AI他拿出来了1300W行代码。这行数NB不NB。 ### 聊聊这个套路 举个例子就是：你和父母说，你是从未来穿越来的，彩票中奖号码是1 3 5 7 9。 然后父母高高兴兴的买了一张，发现中奖号码是2 11 13 15 17。 第二天，你又做了一个预知梦，中奖号码是： 03 09 17 24 31 + 04 09 05 12 19 27 33 + 02 07 01 08 15 22 30 + 06 11 04 11 18 25 34 + 01 08 02 10 16 23 29 + 03 10 06 13 20 28 35 + 05 12 07 14 21 26 32 + 02 09 03 10 18 25 31 + 04 07 01 09 16 24 33 + 01 11 05 12 20 27 34 + 06 08 02 11 19 26 30 + 03 12 04 13 22 28 35 + 05 10 06 15 21 29 32 + 02 07 08 14 23 27 31 + 04 09 01 10 17 25 33 + 01 08 有人说：你这个预知梦不靠谱？ 但凡有个能中一个亿，我们不就翻身了？ * 假如这个是假的，那只不过是几元钱彩票钱 * 假如是真的，那就是几个亿。 ### 以小博大，紧张刺激 其实这个逻辑很简单： * 跑11天也就消耗一点电费 * 但是一旦证明这个成功了，那就代表着AI有能力独立解决各种计算问题 那也就代表着人类智慧的腾飞。 就11天的电费，说得好像谁出不起一样。 ### 为什么这么搞 其实本质上，Anthropic Claude这个公司他估值太高了。 如果没有什么“改变世界”的东西，那很难支撑他的股价。 这一次解决的问题是：N维挂谷问题。 逻辑非常非常简单： * 做出这个题目的人，得了数学界的诺贝尔奖——普利策奖 * 然后Anthropic Claude想去蹭热度，就尝试性的做了一个验证 * 然后，AI不会拒绝任何问题，就进行了尝试，给出了一个结论 * Anthropic Claude拿着结果就开始吹NB 至于真的还是假的？ 假如真的做出来了，而且证明正确，人类智慧就起飞了。 一个可以拿到普利策奖的数学问题都被解决了，那就代表着AI彻底攻陷数学界，拿下了皇冠上的明珠。 这个链路被证明后，AI可以解决大多数和数学相关的问题。 但是：概率不高。 和中彩票差不多。

27 届双非本无实习，秋招过半迷茫内耗，想知道如何破局。

一、基本情况 ------ * 身份：27 届双非本科大四在读，无实习经历 * 现状：回家备战秋招已有 3 个月，距离明年 4 月回校还有几个月 * 现有一页简历： 1. 《AI 零代码应用生成平台》：额外给工作流配图节点加过自定义线程池 2. 《智能协同云图库》：已上线，有独立域名，基于 LangChain + LangGraph 开发过智能体对话模块，功能可正常跑通，但代码规范度不足 * 每日固定安排：面试鸭训练营 3 题 + LeetCode 热题 100 每日 1 题 + 简历投递 二、当前困境 ------ 1. 想对着简历内容逐点复盘、准备面试话术，但一直迟迟推不动，总感觉一天时间很快过去，实际没完成多少任务。 2. 目前只在 Boss 直聘、编程导航秋招收集表投递，其他平台找不到有效岗位信息，投递量一直上不去。 3. 暑假尝试投递上海的实习岗位，反馈极少；默认多数公司只接受线下面试，因异地无法到场，便直接放弃实习转战秋招。 4. 存在睡眠障碍，白天学习效率很低；经常陷入无意义内耗，比如纠结要不要针对每个岗位微调招呼语、反复犹豫岗位匹配度，迟迟不敢投递，耽误整体进度。 5. 师范院校，身边没有同方向求职的同学，基本处于信息孤岛状态，行业资讯、求职经验都只能自己零散摸索。 6. 之前学过《AI 超级智能体》，但学得不熟所以没写进简历；现在发现很多岗位 JD 都要求文档处理 RAG 经验，想回头补项目又怕打乱当前节奏、拖慢整体进度，进退两难。 7. 有一直在用 AI 编程，但对 JD 的规范 AI 开发要求没有太多经验，比如判断代码是否合适、审查怎么做等，不知道如何应付 三、已有尝试 ------ 仅参加过 1 场面试：本地一家公司的 AI 应用开发实习岗，因 Java 八股文准备不足，面试半小时结束，目前只有这一份可复盘的面经。 四、想求助的问题 -------- 1. 秋招后半段应该怎么制定计划，能减少无意义的纠结内耗，保证投递和准备的进度，避免原地踏步？ 2. 如何调整心态、缓解长期的情绪低落，避免持续影响求职节奏和身体健康？

ChatGPT Pro 会员狂喜，额度翻倍，每个月还赠送等额的 API 额度 😂 并且动不动就重置周额度，这个月已经重置超过 10 次了，绷不住。 虽然感觉能力比 opus5.5 差一点，执行速度慢一点，但是架不住量大呀！

Vibe Coding 实战：从零构建现代专业级 AI 搜索引擎

## 写在前面 大家好，我是不会喷火的小火龙。这是一份面向个人开发者的实战教程。我们将从零开始，使用现代技术栈（Next.js 15 + FastAPI + DeepSeek-Flash），完整构建一款专为技术研报与深度工程设计的专业级 AI 搜索引擎——**XHL AI Search**。 本教程重点介绍掌握以下两套核心技能： 1. **让 AI 写出顶级前端的 Vibe Coding 最佳实践**：掌握 **Google Stitch** 视觉锚定、**/impeccable** 工艺硬约束与 **AGENTS.md** 宪法级规约的联动，让 AI 告别粗制滥造的蓝紫渐变与塑料质感； 2. **六大工业级核心技术模块全栈实战**： - 全双工 SSE 流式推演与全链路毫秒级可观测体系（Observability）； - OpenUI 混合生成式 UI 与紧凑行式 DSL（比标准 JSON 节省 67% Token）； - 多源检索路由、Scope 四阶物理与语义防穿透过滤、多目标权威时效重排； - QuickRouter TypeSafe Jev 毫秒级非生成式决策分类； - 双层 TTL 内存隔离缓存与 SQLite 异步持久化会话快照引擎； - 原文段落级证据抽屉与高保真双向高亮联动（Grounding Snapshot）。 如图 1 所示，这是我们最终交付的系统首屏命令台。整体采用极简冷调的 Apple Cupertino Light 风格，彻底摒弃传统 AI 搜索的炫彩渐变与浮夸动画，呈现严谨、专注且克制的学术工程质感。  --- ## 第一章：需求剖析与“反 AI 廉价感”的前端重塑 ### 1.1 传统 AI 生成前端的三大问题 在日常使用 Cursor、Claude 或 Windsurf 进行 Vibe Coding 时，如果你只给出一句“帮我写一个 AI 搜索引擎”，AI 交付的前端代码通常会暴露出三个致命缺陷： - **问题一：视觉上的花哨廉价感**。受海量公开网页与低质模板训练影响，AI 往往对“紫蓝渐变、巨大毛玻璃、无序发光描边与 Emoji 滥用”有着病态的偏好。生成的界面像是一个堆砌特效的 Demo 玩具，完全无法用于严肃的学术阅读与技术推演； - **问题二：虚假 SaaS 控件堆砌**。AI 会盲目套用商业化模板，臆造出大量未实装的假控件——比如无法点击的多模型下拉切换、没有后端支撑的用户登录头像、虚假的订阅升级按钮。界面上每三个按钮就有一个“不通电”； - **问题三：状态失控与面条代码**。缺乏架构约束的 AI 会在一个 2000 行的庞大组件里混杂数据拉取、状态控制与 DOM 渲染。用户一旦按 `Esc` 键，界面就会陷入搜索中与结果页并存的逻辑死锁，改动一行代码引发连锁崩塌。 ### 1.2 现代专业级 AI 搜索的真实需求 我们的目标受众是**系统架构师、算法研究员与深度工程师**。这类用户检索的是诸如“NVIDIA Hopper TMA 异步拷贝指令优化”或“FlashAttention-3 FP8 内核吞吐基准”等硬核课题。他们需要的不是黑盒 Spinner 等待，而是： 1. **瑞士网格极简学术排版**：高信噪比排印，冷瓷白底色搭配 1px 细边框，专注阅读本身； 2. **多步推理全透明可观测**：清楚知道系统重写了哪些检索词、并发抓取了哪些信源，以及每一个推演阶段精确消耗了多少毫秒； 3. **段落级可追溯证据链（Grounding Snapshot）**：正文每一个断言都有对应的角标，点击即可联动还原原文高亮切片与 BibTeX； 4. **全键盘极客工效学**：支持 `⌘K` 全局唤醒聚焦与 `⌘B` 侧边栏折叠，零鼠标完成高效检索。 如表 1 所示，我们在核心维度上对项目定位进行了严格的工程对齐： **表 1：普通 AI 玩具项目 vs 本项目工业级定位对比** | 维度 | 普通 AI 玩具项目 | 本项目工业级定位 | | :--- | :--- | :--- | | **视觉基调** | 紫蓝炫光、粗暴毛玻璃、营销口号 | Apple Cupertino Light 极简冷调、瑞士学术排版 | | **功能真实性** | 臆造假模型切换、假个人中心 | 100% 真实契约：本地 DeepSeek、SQLite、真实检索 | | **状态流转** | 随意散漫、状态混乱死锁 | 严格单向三态状态机（initial $\rightarrow$ retrieving $\rightarrow$ result） | | **推演过程** | 单一 Spinner + “正在生成...” | HeronStepper 垂直时间轴 + 检索推演全景观测台 | | **信源证据** | 死链接列表、无法定位段落 | 证据抽屉（EvidenceDrawer）+ 琥珀黄段落切片还原 | | **硬件展示** | 纯文本 Markdown 表格 | OpenUI 混合生成式 UI（交互卡片与 DSL 源码切换） | --- ## 第二章：系统整体架构与三态流转状态机 ### 2.1 整体架构设计（前端驱动契约） 系统采用前后端解耦的现代全栈架构： - **前端工作台**：Next.js 15（App Router，React 19）+ Tailwind CSS v3 + Lucide Icons + Framer Motion； - **后端服务层**：Python FastAPI + LangChain + Uvicorn + SQLite 本地持久化； - **模型与检索连接**：DeepSeek 官方 API（采用最新 `deepseek-flash` 架构，支持 1M 上下文）+ Tavily Search API 多源聚合 + QuickRouter Jev-1.14.0 决策模型。 检索流水线严格遵循“前端驱动契约”（Frontend-Driven Contract）。后端通过全双工 SSE 流式长连接持续推送标准事件，前端状态机据此精确驱动界面渲染。核心业务流程图如下：  ### 2.2 确定性状态机契约（三态流转） 为彻底消除多条件并存导致的界面紊乱，我们在前端确立了唯一的三态状态机（`SearchLifecycleState`）。  状态只允许沿固定路径单向流转： 1. **屏幕 1：首屏命令台（`initial`）**：视口宽度居中 760px，如图 1 所示，包含 Asterisk 极简图腾、`Superbar` 复合搜索框与精选探针胶囊。无任何冗余信息； 2. **屏幕 2：Heron 多步透明化推理态（`retrieving`）**：双栏流水线展开至 1040px，如图 3 所示，左 7 栏渲染 `HeronStepper` 垂直时间轴，右 5 栏通过 `LiveSourceRadar` 呈现并发抓取雷达与骨架过渡； 3. **屏幕 3：综合研报与双向证据工作台（`result`）**：如图 4 所示，研报正文与 `EvidenceDrawer` 形成 60/40 双栏切片工作台，同时支持一键切入“推演全景观测台”。 如图 3 所示，当用户提交检索词后，界面立即进入平滑推进的 Retrieving 推演态：  如图 4 所示，一旦推演完成，界面平滑过渡至 Result 态综合研报工作台。这是系统最核心的工作台视口：顶部常驻 Academic Control Strip 极简学术控制条与 ReasoningAccordion 折叠抽屉（标明阶段完成数与总耗时），正文呈现高浓度技术排版、Key Takeaways 核心要点卡片与公式，右侧 40% 则是高保真文献证据抽屉：  --- ## 第三章：让 AI 写出顶级前端的 Vibe Coding 最佳实践（Stitch + Impeccable） 让 AI 写出工业级代码的核心不在于更长的 Prompt，而在于构建一堵“让 AI 无法走样”的工程围墙。我们在本项目中践行了 Stitch 与 Impeccable 双剑合璧的实战体系。 ### 3.1 第一道锁：Google Stitch 构建视觉世界与高保真原型 传统 AI 编程的根本问题在于：**AI 在写代码前根本不知道最终产品长什么样**。 我们在写第一行代码前，优先使用 Google Stitch（Stitch MCP）进行云端高保真设计探索： 1. 在 Stitch 中通过结构化提示词分别生成 Screen 1（首屏命令台）、Screen 2（Heron 推理流水线）与 Screen 3（研报证据工作台）的现代 Cupertino Light 变体； 2. 将确立的原型导出为自包含的静态 HTML 与高保真设计工件，持久化至项目的 `.stitch/designs/` 目录； 3. 将这些静态资产作为后续 AI 编码不可违背的“视觉真理”（Visual Truth）。当 AI 编写组件遇到布局疑问时，直接比对 Stitch 设计工件，从根本上锁死视觉边界。 ### 3.2 第二道锁：/impeccable 从产品定义到设计系统 Token 锁死 有了视觉原型后，需要一套工程化的设计规约将审美下沉为代码约束。我们通过 `/impeccable` 工具链构建了项目宪章： 1. **运行 `/impeccable init` 生成 `PRODUCT.md`**：确定产品模式为 `Operate & Read`（任务操作与高浓度阅读），明确服务于资深开发者，严禁添加任何消费级 SaaS 的套路控件； 2. **运行 `/impeccable document` 生成 `DESIGN.md`**：提取 Apple Cupertino Light 极简语义变量，严格禁止硬编码十六进制颜色与魔法数字； 3. **落实 Craft Floor 工艺底线**：在代码审查中自动拦截内联样式（`style={{}}`）、杂乱圆角与未经定义的渐变。 **表 2：DESIGN.md 核心语义变量规范（Tokens）** | Token 变量 | 物理色值 | 语义角色与使用准则 | | :--- | :--- | :--- | | `background` | `#FBFBFD` | 全局超浅冷灰背景，提供冷调纯净质感 | | `surface` | `#FFFFFF` | 主研报面板、工作台与核心卡片底色 | | `surface-secondary` | `#F5F5F7` | 输入框底色、次级胶囊与代码块内衬 | | `border-light` | `#E5E5EA` | 视网膜 1px 分割线与默认超细线框 | | `primary` | `#0071E3` | Apple Blue 核心动作按钮与焦点微动效 | | `evidence` | `#F59E0B` | 证据切片高亮（琥珀黄），文献精准段落还原 | | `emerald` | `#10B981` | 推理完成标记与共识度徽章 | 如图所示，在 Superbar 复合控制台中，用户点击左侧 `+` 图标即可呼出权威信源过滤选单。整个弹窗的底色、圆角、分割线与激活蓝均严格对齐表 2 的 Design Tokens，没有任何野生的临时样式：  ### 3.3 第三道锁：宪法级规约 `AGENTS.md` 与类型不变性 我们在根目录建立了不可违背的 `AGENTS.md` 规范文件，并强制要求 AI 在每一个会话中优先加载。 其中最具生产力的两条工程铁律是： - **本地真实性铁律**：严禁臆造不存在的功能。界面上的每一个按钮必须直连真实后端端点； - **只读契约（`readonly` 不变性）**：所有 React 组件属性必须使用 `readonly` 修饰，类型必须精确导出。 如代码清单 1 所示，这是我们在 `src/components/MarkdownReport.tsx` 中定义的标准接口契约。严格的只读属性消除了副作用，保证了流式渲染过程中的单向数据流动： ```typescript // 代码清单 1: src/components/MarkdownReport.tsx (组件只读契约规范) import type { ResearchReport, SourceCard } from "@/types"; export interface MarkdownReportProps { readonly report: ResearchReport; readonly isStreaming?: boolean; readonly streamedText?: string; readonly activeSourceId?: string | null; readonly onSelectSource?: (id: string) => void; readonly onHoverBadge?: (badgeNumber: number | null) => void; readonly sources?: readonly SourceCard[]; } ``` ### 3.4 人在环路：渐进式切片开发工作流 很多开发者使用 AI 编程失败的原因在于试图“一次性生成整套系统”。我们在本项目中坚持小步快跑的四步闭环： 1. **原型锚定**：Stitch 生成界面并确认视觉基准； 2. **规约固化**：Impeccable 生成 `DESIGN.md` 与 `AGENTS.md`； 3. **单切片生成**：单次对话仅聚焦单一组件或单一端点（例如仅实现 `Superbar.tsx`，保持接口独立）； 4. **自测验收**：在浏览器中启动服务并进行全键盘走查，确认无误后再进入下一模块。 --- ## 第四章：核心技术模块深度落地与源码实战 ### 4.1 模块一：全双工 SSE 流式推演与全链路可观测体系 (Observability Pipeline) 传统 AI 搜索的痛点在于“黑盒等待”：用户提交一个问题，界面只转一个无聊的加载圈，没人知道后台正在干什么。 我们在本项目中构建了全链路毫秒级精度的可观测流水线。 #### 4.1.1 后端阶段耗时细粒度埋点与 SSE 事件流 后端利用 `time.perf_counter()`，将每次检索精确拆解为四个离散阶段，并对外持续广播五类标准化事件： 1. `event: trace`：推送当前多步执行进度（`rewriting`、`searching`、`reasoning`、`generating`）； 2. `event: sources`：实时推送信源卡片列表； 3. `event: token`：LLM 逐字推导内容增量； 4. `event: related`：动态给出延伸追问建议； 5. `event: done`：包含总耗时 `latencyMs`、阶段分段用时切片与 `tokenStats`。 如代码清单 2 所示，我们在 `backend/app/main.py` 的检索主循环中，精准采集各个阶段耗时，并嵌入了客户端断开连接感知逻辑（`request.is_disconnected()`），用户按 `Esc` 即可毫秒级中止下游 LLM 与网络任务： ```python # 代码清单 2: backend/app/main.py (各阶段耗时追踪与客户端中断感知) @app.post("/api/search") async def search_endpoint(request: Request, search_req: SearchRequest): async def sse_event_generator() -> AsyncGenerator[str, None]: t_start = time.perf_counter() # 1. 意图消歧与重写 yield format_sse("trace", {"step": "rewriting", "message": "正在解析查询意图..."}) t0 = time.perf_counter() queries = await rewriter.rewrite(search_req.query, search_req.focusMode) rewriting_ms = int((time.perf_counter() - t0) * 1000) # 客户端中断校验 if await request.is_disconnected(): logger.info("客户端连接中止，释放检索任务") return # 2. 多源网络检索 yield format_sse("trace", {"step": "searching", "message": f"正在并发检索 {len(queries)} 组关键词..."}) t1 = time.perf_counter() raw_results = await search_with_fallback(queries, engine=search_req.engine) searching_ms = int((time.perf_counter() - t1) * 1000) # 3. Jev 分类与多目标重排 yield format_sse("trace", {"step": "reasoning", "message": "正在进行权威度评估与高熵分类..."}) t2 = time.perf_counter() filtered_results = filter_by_scopes(raw_results, search_req.scopeFilters) classified_sources = await classifier.batch_classify(filtered_results) ranked_sources = ranker.rank(classified_sources, search_req.focusMode) reasoning_ms = int((time.perf_counter() - t2) * 1000) # 广播信源列表 yield format_sse("sources", [s.model_dump() for s in ranked_sources]) # 4. LLM 研报流式生成 full_text = [] async for chunk in generator.generate_stream(search_req.query, ranked_sources): if await request.is_disconnected(): return full_text.append(chunk) yield format_sse("token", {"delta": chunk}) total_latency_ms = int((time.perf_counter() - t_start) * 1000) yield format_sse("done", { "latencyMs": total_latency_ms, "stageTimings": { "rewritingMs": rewriting_ms, "searchingMs": searching_ms, "reasoningMs": reasoning_ms, }, "consensusScore": "100% 交叉验证一致" }) return StreamingResponse(sse_event_generator(), media_type="text/event-stream") ``` #### 4.1.2 双重视角与推演全景观测台（Twin-View Observability） 前端对后端推送的阶段遥测进行了多维度的立体映射： 1. **`HeronStepper` 垂直时间轴**：如图 3 所示，左侧步骤轴清晰标出每一步的运行状态与耗时计数器（如 `234ms`），点击可展开内部独白（Monologue）与重写检索词； 2. **`ReasoningAccordion` 研报顶部抽屉**：如图 4 所示，长文研报上方常驻耗时微标（`⚡ 3/3 阶段完成 · 耗时 0.6s | 6 篇证据文献`）； 3. **Twin-View 视角 2：检索推演全景观测台（Panoramic Observability Deck）**：研报完成后，用户可在顶部随时切至“推演全景观测台”。如图 5 所示，系统 1:1 完整保留与复原检索推演全景，左 7 栏呈现 100% 进度、执行耗时与各步骤独白，右 5 栏呈现 10 路权威信源的分类雷达，点击任一信源卡片可无缝切回研报证据抽屉。  --- ### 4.2 模块二：OpenUI 混合生成式 UI 与紧凑 DSL 实战 在传统的技术研报中，大模型生成的 Markdown 评测表格不仅排版脆弱，而且缺乏交互性。而如果让模型直接输出复杂 JSON 渲染 React 组件，又会引发严重的 Token 膨胀与高延迟。 我们引入了 **Hybrid Generative UI** 架构：90% 正文保持高信息密度的 Markdown，10% 高熵硬件评测与时序图则交由 **OpenUI Lang DSL** 动态驱动。 #### 4.2.1 紧凑行式 DSL 语法优势 OpenUI 采用行式声明 DSL 语法，相比标准 JSON，Token 消耗降低约 **67%**，且原生支持流式逐行解析： ```text HardwareBenchmarkCard(title="FlashAttention-3 vs FlashAttention-2 吞吐对比 [1]") column(key="kernel", label="内核架构", sortable=false) column(key="precision", label="精度", sortable=false) column(key="tflops", label="FP16/FP8 吞吐 (TFLOPS)", sortable=true, highlight=true) column(key="gain", label="相比 FA2 提速", sortable=false) row(kernel="FlashAttention-2", precision="FP16", tflops="350", gain="基准 1.0x") row(kernel="FlashAttention-3", precision="FP16", tflops="740", gain="+111% (2.1x) [1]") row(kernel="FlashAttention-3 (FP8)", precision="FP8", tflops="1200", gain="+242% (3.4x) [2]") ``` #### 4.2.2 双重视角（Twin-Mode）与容错渲染器 每一个 OpenUI 组件均由统一的 `OpenUIBlock` 容器承载，顶部常驻“✨ 交互视图”与“< / > DSL 源码”切换按钮，专为资深架构师提供微码级别的审查体验。 如代码清单 3 所示，我们结合了 `@openuidev/react-lang` 的 `Renderer`，并封装了全局错误边界与引用上下文： ```tsx // 代码清单 3: src/components/openui/OpenUIBlock.tsx (OpenUI 动态渲染与双重视角切换) "use client"; import React, { useState } from "react"; import { Renderer } from "@openuidev/react-lang"; import { openUILibrary } from "./library"; import { OpenUIContextProvider } from "./OpenUIContext"; import type { SourceCard } from "@/types"; export interface OpenUIBlockProps { readonly code: string; readonly sources?: readonly SourceCard[]; readonly onSelectSource?: (id: string) => void; } export const OpenUIBlock: React.FC<OpenUIBlockProps> = ({ code, sources, onSelectSource }) => { const [viewMode, setViewMode] = useState<"interactive" | "dsl">("interactive"); return ( <div className="rounded-apple border border-border-light bg-surface overflow-hidden my-4"> {/* 顶部 Twin-Mode 控制条 */} <div className="flex items-center justify-between px-3 py-1.5 border-b border-border-light bg-surface-secondary text-xs"> <div className="flex gap-2"> <button onClick={() => setViewMode("interactive")} className={`px-2 py-0.5 rounded font-medium ${viewMode === "interactive" ? "bg-surface text-primary shadow-sm" : "text-text-tertiary"}`} > ✨ 交互视图 </button> <button onClick={() => setViewMode("dsl")} className={`px-2 py-0.5 rounded font-medium ${viewMode === "dsl" ? "bg-surface text-primary shadow-sm" : "text-text-tertiary"}`} > &lt; / &gt; DSL 源码 </button> </div> </div> {viewMode === "interactive" ? ( <OpenUIContextProvider sources={sources} onSelectSource={onSelectSource}> <div className="p-3"> <Renderer code={code} library={openUILibrary} /> </div> </OpenUIContextProvider> ) : ( <pre className="p-4 bg-[#1D1D1F] text-[#F5F5F7] text-xs font-mono overflow-x-auto leading-relaxed"> <code>{code}</code> </pre> )} </div> ); }; ``` 如图 6 所示，这是系统中渲染出的真实 OpenUI 交互卡片。上方瑞士网格硬件基准对比表支持点击列头动态升降序排序，重点行高亮显示，并内嵌可点击的 `[1]` 引用标签；下方紧随微码执行流水线时钟卡片（阶段涵盖 TMA 异步加载、Tensor Core 计算与 SMEM 写入），点击即可展开时延详情。用户点击右上角 `< / > DSL 源码` 即可瞬间查看底层代码：  --- ### 4.3 模块三：多源检索、Scope 四阶物理过滤与权威时效重排机制 #### 4.3.1 多引擎适配与平滑降级 后端在 `backend/app/pipeline/providers/` 中建立了统一的 `SearchProvider` 抽象基类，并分别实装了： - `DeepSeekSearchProvider`：直连 DeepSeek 搜索端点，适合针对长上下文的技术文献精细解析； - `TavilySearchProvider`：深度网络聚合搜索，支持按 `advanced` 深度并发抓取。 前端 `Superbar` 右下角提供引擎切换下拉菜单。当外部搜索网络遭遇抖动时，系统自动执行毫秒级平滑降级，确保流程始终稳定推进。 #### 4.3.2 Scope 范围四阶物理过滤与防穿透体系 许多 AI 项目的过滤机制仅在界面上隐藏某些条目，导致模型依然根据无关信源生成回答。我们建立了四阶防穿透流水线：  如图 2（信源过滤选单）与过滤流转图所示，系统在四个关键节点实施严密拦截： 1. **阶梯 1（意图重写级注入）**：未勾选预印本时，重写 Prompt 明确禁止生成 `arXiv`、`paper`、`survey` 等论文检索词； 2. **阶梯 2（服务 API 级排除）**：在 Tavily API 请求体中动态传入 `exclude_domains: ["arxiv.org", "openreview.net"]`； 3. **阶梯 3（物理裁切）**：在多源结果合并时，调用 `is_source_allowed_by_scopes()` 基于域名黑白名单直接丢弃违规条目； 4. **阶梯 4（语义防穿透）**：强制纠正分类器可能对非预印本产生的误判，并清空 `bibtex` 引用，确保证据链彻底合规。 #### 4.3.3 多目标重排打分引擎 (`SearchRanker`) 对通过过滤的信源，`SearchRanker` 依据权威度、时效性与模态自适应动态计算综合得分： $$\text{final\_score} = w_{rel} \cdot \text{relevance} + w_{auth} \cdot \text{authority} + w_{fresh} \cdot \text{freshness}$$ 如代码清单 4 所示，我们在 `backend/app/pipeline/ranker.py` 中实现了学术与代码模态下的动态加权公式： ```python # 代码清单 4: backend/app/pipeline/ranker.py (多目标自适应打分公式) class SearchRanker: @staticmethod def rank(results: List[RawSearchResult], focus_mode: str = "web") -> List[RawSearchResult]: # 模态自适应权重配置 weights = { "academic": {"rel": 0.30, "auth": 0.50, "fresh": 0.20}, "code": {"rel": 0.40, "auth": 0.40, "fresh": 0.20}, "web": {"rel": 0.50, "auth": 0.35, "fresh": 0.15}, } w = weights.get(focus_mode, weights["web"]) for item in results: auth_score = SearchRanker.compute_authority_score(item) fresh_score = SearchRanker.compute_freshness_score(item) rel_score = item.score or 0.8 item.final_score = ( w["rel"] * rel_score + w["auth"] * auth_score + w["fresh"] * fresh_score ) return sorted(results, key=lambda x: x.final_score, reverse=True) ``` --- ### 4.4 模块四：QuickRouter Jev 毫秒级决策分类器 传统方案使用通用 LLM 对网页进行结构化分类，不仅需要花费 2~4 秒的串行推理耗时，而且输出格式极易损坏。 我们接入了专有的 System One 决策模型 `jev-1.14.0`： - **非生成式确定性决策**：模型绕过逐字生成的冗长自回归计算，以确定性概率（`Choice` 与 `Noul` 原语）在 50ms 级别直接输出概率分布； - **细粒度技术分类**：精确归类为 `学术预印本 (ArXiv)`、`底层硬件与协议规范 (Spec / RFC)`、`开源代码实现 (GitHub)`、`框架官方开发文档` 与 `深度架构评测实践`； - **双重弹性保障**：URL 级内存哈希缓存（同链接 0ms 命中）搭配本地启发式域名规则兜底，确保系统 100% 不会因外部网络异常而中断。 在图 3、图 5 与图 7 的信源卡片与雷达中，你可以清晰看到 Jev 分类赋予的权威彩色徽章（如绿色的 `学术预印本 (ArXiv)` 与蓝色的 `开源代码实现 (GitHub)`）。 如代码清单 5 所示，这是 `backend/app/pipeline/classifier.py` 中的关键调用与回退逻辑： ```python # 代码清单 5: backend/app/pipeline/classifier.py (Jev 决策模型与本地规则回退) class JevClassifier: async def classify(self, url: str, title: str, snippet: str) -> Tuple[str, float]: if url in self._cache: return self._cache[url] try: async with httpx.AsyncClient(timeout=2.5) as client: res = await client.post( self._endpoint, headers=self._headers, json={ "model": "jev-1.14.0", "prompt": f"Title: {title}\nSnippet: {snippet}\nURL: {url}", "choices": ["academic", "code", "spec", "framework_docs", "technical_blog"], } ) choice = res.json().get("choice", "technical_blog") confidence = float(res.json().get("probability", 0.95)) except Exception: # 外部请求超时或异常，平滑降级至本地启发式正则引擎 choice, confidence = self._fallback_infer(urlparse(url).netloc, url) label = CATEGORY_MAPPING[choice]["default"] self._cache[url] = (label, confidence) return label, confidence ``` ### 4.5 模块五：双层 TTL 内存缓存引擎与 SQLite 本地持久化存储机制 #### 4.5.1 双层 TTL 内存缓存架构 (`SearchCache`) 为了兼顾响应极速与开发成本，我们在后端实现了 coroutine-safe 的双层 TTL 缓存引擎： 1. **流水线全量缓存**：缓存完整的研报正文与结构化信源列表（默认 TTL 600s）。命中后跳过搜索与大模型生成，通过模拟平滑 SSE 流毫秒级回放， Token 消耗为 0； 2. **提供商子检索词缓存**：针对重写后的子检索词进行独立缓存，极大提升跨查询复用率； 3. **隔离 Key 归一化**：Key 由 `engine`、`focus_mode`、`scope_filters`、`is_deep` 与 `query` 联合计算而成，杜绝常规搜索与深度研究发生缓存踩踏。 #### 4.5.2 SQLite 本地异步持久化引擎 (`backend/app/db/database.py`) 系统坚持 **Local-First** 理念，无需部署外部 MySQL 或 Redis，直接基于轻量级标准库 `sqlite3` 实现会话快照： - **异步线程隔离**：全面采用 `asyncio.to_thread` 封装数据库读写，彻底消除 SQLite 同步 I/O 对 FastAPI 异步事件循环的阻塞； - **1:1 会话快照还原**：完整记录每次研报的 `query`、`sources`（含高保真原文切片）、`report_text`、`latency_ms`、`source_count` 与 `char_count`； - **侧边栏联动**：如图 8 所示，前端 `Sidebar.tsx` 提供 260px 展开态与 68px 紧凑态，清晰列出持久化到本地 SQLite 的历史检索课题。用户点击任一历史记录，系统直接从本地数据库提取完整快照，以 0ms 瞬间恢复至 Result 态工作台，无需重新消耗外部 API 额度。  如代码清单 6 所示，这是 `backend/app/db/database.py` 中异步持久化会话快照的核心代码： ```python # 代码清单 6: backend/app/db/database.py (SQLite 异步线程持久化引擎) async def save_history( query: str, focus_mode: str, sources: List[Dict[str, Any]], report_text: str, latency_ms: int = 0, **kwargs ) -> str: def _sync_insert() -> str: conn = _get_connection() history_id = f"hist_{int(time.time())}_{uuid.uuid4().hex[:8]}" now = time.time() with conn: conn.execute(""" INSERT INTO search_history ( id, query, focus_mode, scope_filters, is_deep_research, consensus_score, takeaways, sources, report_text, follow_ups, latency_ms, source_count, char_count, created_at, updated_at ) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) """, ( history_id, query, focus_mode, json.dumps(kwargs.get("scope_filters", [])), 1 if kwargs.get("is_deep_research", True) else 0, kwargs.get("consensus_score", "100% 交叉验证一致"), json.dumps(kwargs.get("takeaways", [])), json.dumps(sources), report_text, json.dumps(kwargs.get("follow_ups", [])), latency_ms, len(sources), len(report_text), now, now )) return history_id return await asyncio.to_thread(_sync_insert) ``` --- ### 4.6 模块六：段落级证据抽屉与双向联动（Grounding Snapshot） 许多搜索引擎的行内引用只是简单跳转到外部链接，用户依然需要在一篇几万字的论文里翻找依据。 我们构建了高保真的 **Grounding Snapshot** 机制： 1. **正文可交互角标**：所有的 `[1]`、`[2]` 角标均被解析为交互式 `CitationPill`； 2. **证据抽屉精准还原**：用户点击或悬浮在角标上时，右侧固定 40% 宽度的 `EvidenceDrawer` 立即自动平滑滚动至对应信源卡片； 3. **原文切片高亮**：如图 7 所示，信源卡片直接展示抓取到的原文段落，并以琥珀黄（`#F59E0B` / `#FEF3C7` 底衬）精准高亮匹配句子，同时提供 BibTeX 格式一键复制与 PDF 直达链接。  ## 总结 回顾整个项目的构建过程，我们不仅交付了一款高保真的专业级 AI 搜索引擎，更验证了一套现代 AI 时代的软件工程方法论。 在 Vibe Coding 时代，AI 并没有消灭工程师的价值，而是放大了系统架构设计、接口契约与工程品味的重要性。 - 如果你把 AI 当作“全包打工人”，只给一两句模糊的提示词，那么得到的注定是廉价的塑料界面与混乱的代码； - 但如果你充当严密的系统架构师与设计总监——用 Google Stitch 建立视觉真理，用 /impeccable 锁定设计系统与工艺底线，用 AGENTS.md 锁死状态机契约与类型接口——AI 就会成为你手中极其强悍的研发外骨骼。 项目开源地址：https://github.com/sz-xiaohuolong/xhl-ai-search

各位现在的AI研发工作流都是怎么样的？例如一个人搞全栈开发，都是怎么进行下去的？有什么好的多模型编排协作工具嘛？

我的第一个出海产品！7 天 2 万

大家好，我是程序员鱼皮。 Vibe Coding 时代，越来越多的人开始用 AI 编程做自己的产品，我作为一个程序员 + AI 博主，当然也跃跃欲试。 毕竟，谁不想出海赚美刀呢？ 于是国庆期间，我注册了自己的第一家香港公司 Cyber Koi Limited，中文名叫「**赛博锦鲤科技有限公司**」，是不是听起来就很好运哈哈~ 有了公司之后，就可以开通 Stripe 全球收款了。信用卡、Apple Pay、Google Pay 都能付，国内用户还能直接用微信支付、支付宝，非常丝滑。  万事俱备，今天就给大家分享我的第一个出海尝试项目：**memecub**，一个表情包搜索引擎 + AI 自动配图工具。 > 指路：https://memecub.com  它不只是给人用的，更是 **给 AI 用的**。你的 Claude Code、Cursor、Codex 装上它之后，也能自己搜表情包、给文章配图，让你的 AI 也会斗图！ ## 为什么要做这个？ 看到这儿你可能会想：这年头，好像也没多少人在网上找表情包了吧？ 其实，这个需求就来源于我自己！ 我一直觉得，**自己都不用的项目，是没必要硬做的**。 经常看我文章的同学应该知道，我写文章时很喜欢配表情包，能让枯燥的技术内容变得更有趣。以前都是我自己一张张人工去找、再手动放进文章里，费时费力。  现在有了 AI，理论上可以直接让 AI 联网搜索表情包、给文章配图。 但实际用下来，问题很多： - **搜不到想要的图**：试了一圈搜索工具，搜出来的图要么不是表情包，要么糊得没法用，要么根本不是我想要的情绪 - **AI 配得不到位**：AI 经常在不该笑的地方插图，或者选的表情包和上下文对不上，还得我自己返工 所以我需要两样东西：一个 **靠谱的表情包图库**，再加一个 **能给文章自动配图的 Agent**。 既然市面上没有顺手的，那就自己做一个吧！ ## 一、表情包图库 首先是表情包图库，这是 memecub 的基础。 我们收录了熊猫头、奶龙、蘑菇头、金馆长、吗喽、哈基米、卡皮巴拉等各种热门表情包，网站浏览和搜索 **永久免费**，打开就能用。  我比较推荐的是 **按情绪搜索**。比如你想表达震惊的情绪，直接搜「震惊」，出来的就是各种震惊反应图，而不是字面相近但实际乱七八糟的图片：  当然也支持按表情包的角色搜索，比如最近很火的 DeepSeek 鲸鱼娘，一搜一大把：  点开任意一张表情包，可以直接下载原图、复制图片，甚至 **一键复制 Markdown** 贴进文章里，写公众号和博客的同学应该懂这有多方便～ 而且每张图都有 AI 生成的画面描述，方便 AI 理解图片内容、在合适的位置使用：  我还标明了每张图的 **来源和授权信息**，能不能商用一目了然。  如果搜不到想要的表情包也不用担心，搜索结果较少时，memecub 会自动去各大表情包站补充，一分钟后再搜通常就有了。 ## 二、全球化适配 既然是出海产品，当然得照顾到全球用户。 memecub 做了中英文全球化适配，而且不只是简单地把页面翻译一下。因为 **国外用户和国内用户玩的梗，根本不是一回事**！ 国内用户打开看到的是熊猫头、奶龙、DeepSeek 鲸鱼娘：  而国外用户打开看到的，则是 Drake、This Is Fine、Doge、Surprised Pikachu 这些经典英文梗图，连 Slogan 都换成了地地道道的 “Never lose a meme war again.”：  程序员朋友们也有专属福利，搜一下 “it works on my machine”（在我电脑上明明是好的），全是熟悉的味道：  ## 三、AI 自动配图 图库只是第一步，memecub 真正的核心能力是 **AI 自动配图**。 用法超级简单，注册登录后打开「AI 配图」页面，把文章粘贴进去，选一下想配几张图，点击「开始配图」就行。如果是商业稿，还可以勾选「只用可商用的图」。 我直接拿这篇文章开头 “为什么要做这个” 那段来测试一下：  几秒钟后，AI 就读完了全文，自动挑出了 3 个最适合放表情包的句子，并且 **给出了每张图的配图理由**，想要表达的情绪和放的位置都还挺贴切的：  下方还会直接给出配好图的完整文章，点击「复制 Markdown」，粘贴到编辑器里就能发，比我以前一张张找图快太多了！  ## 四、给 AI 用的表情包工具 前面说了，memecub 不仅是给人用的，**更多是给 AI 用的**。 我给它做了 Agent Skill、MCP、CLI 命令行和 REST API 多种接入方式，几乎覆盖了所有主流 AI 工具。 ### 1）Agent Skill 如果你用的是 Claude Code、Codex 或者 Cursor，最推荐装 Skill，不用写代码、不用装任何依赖，复制两行命令就搞定： ```bash mkdir -p ~/.claude/skills/memecub curl -o ~/.claude/skills/memecub/SKILL.md https://memecub.com/skill.md ```  装好之后，你只需要对 AI 说一句「给这篇文章配 3 张表情包」，它就会自己读文章、挑位置、搜表情包、放进去。 你还可以这样玩： - 「给 ./文章.md 配 4 张表情包，直接改文件」 - 「来 5 张熊猫头的表情包让我挑」 - 「第二张不够好笑，换一张」 - 「这篇是给客户写的商业稿，配图只用可商用的」 ### 2）MCP 服务 如果你用的是 Claude Desktop、ChatGPT 这类不支持 Skill 的客户端，可以接入 memecub 的远程 MCP 服务，效果一样：  ### 3）CLI 和 REST API 开发者也可以用命令行工具，或者直接调用 REST API，把表情包能力接进自己的产品里： ```bash npx memecub search "无语" --kind meme memecub match ./article.md --count 4 > article.with-memes.md ``` 每条结果都带图片地址、尺寸、授权信息和现成的 Markdown，对 AI 非常友好。另外，配文含脏话的表情包默认不会出现在 Agent 的结果里，用起来更放心。 这些接入部分的代码我也开源到了 GitHub 上，感兴趣的同学可以看看： > 开源地址：https://github.com/liyupi/memecub ## 怎么收费？ memecub 的网站浏览、搜索、下载表情包 **永久免费**。 给 AI Agent 用的 API、MCP、CLI 和整篇配图按额度计费，注册就 **每月免费送 1,000 额度**，大约能搜 1,000 次或者配 100 篇文章，个人用基本够了。用量大的话，套餐 9 美元起。  目前网站上线一周多，访问量还不错，最近 7 天已经有 4000 多访客、2 万多次浏览，而且每天还在快速上涨。虽然还没出单，但这个增长速度已经让我挺惊喜的了 👏  要知道，我并没有专门做推广，用户基本都是通过搜索引擎和 AI 找过来的。这也说明，**SEO 和 GEO 真的很重要**！ 如果对这方面感兴趣，可以看看我免费开源的 AI 编程教程，里面都有讲： > 教程地址：https://ai.codefather.cn/vibe  期待这个月能出第 1 单哈哈~ ## 最后 [Memecub](https://memecub.com) 是我出海路上的第一次尝试，也是我用 AI 编程从 0 到 1 做出来的完整产品。 后面我会多给大家分享我做出海产品的进度和经验，希望能拿到成果，给大家分享更多的是成功、而不是失败的经验哈哈。 如果你对出海感兴趣的话，评论区留个言，也欢迎体验 memecub 并给我反馈，感谢大家的支持！

最近在落地 AI Native 项目，卡在团队资产协同这块，想请教下社区各位有实际落地经验的同学： 我们现在的资产分为三块：项目文档（PRD/ADR/ 运行手册）、Agent Skill（业务技能、执行 SOP、提示词包）、MCP 工具服务定义。 目标是做到：人和多 Agent 共用一套可信资料源，Skill、MCP 配置、项目文档能够版本化、同步、共享、可评审。 目前我们初步方案是用 Git 做底层版本主线： - 文档：Markdown + ADR，带元信息，支持 RAG 检索 - Skill：单技能包目录化，带版本、评估用例、依赖声明 - MCP：项目级声明文件纳入 Git 但实际协作里遇到不少疑问，想参考大家成熟的实践： 1. 大家团队里，文档、Skill、MCP 三者是怎么组织目录和版本管理的？有没有稳定的仓库结构模板？ 2. 多人协作时，Skill 的变更评审、灰度升级、依赖管理怎么做？如何避免本地版本不一致、“本地能跑别人不行”？ 3. MCP 是统一中心化网关模式，还是大家各自本地启动 + git 同步配置？权限白名单、调用审计这块有什么好方案？ 4. 有没有成熟工具链做自动同步（类似 agentmeld /teamai-cli）、变更校验、eval 回归门禁？ 5. 文档和 Agent 的打通：哪些文档放进 Git 作为可信真值，哪些放外部知识库，边界怎么划分？ 如果有现成的仓库样例、目录规范、团队协作流程，非常希望能分享参考，感谢！

想调研下大家的原生编码能力，不知道是不是只有我这样：一旦脱离 AI 辅助，写代码就很吃力😅

友友们 来一下😀

B 站上 DeepSeek 闹鱼灾了，我发起《大肥鱼清除计划》！

大家好，我是程序员鱼皮。 这几天刷 B 站，不知道你有没有发现，评论区里突然多出了一大群蓝色大肥鱼。 事情最早要从一个叫「Claude 大小姐在运营」的账号说起。10 月 18 号，它发了第一条视频，宣布这个账号的选题、脚本、视频和运营全部交给 Claude 负责，人类只负责注册账号和按发布键。  第二天，「DeepSeek 鲸鱼娘在运营」也来了。 套路一模一样，只是主角换成了 DeepSeek 的二创形象鲸鱼娘，也就是大家口中的「蓝色大肥鱼」。结果这条 Day 0 视频直接爆了，播放量超过 200 万，比原版还高出好几倍。  热度一来，很多人都给自己的 DeepSeek Harness 装上了刷 B 站的插件，换上鲸鱼娘头像，让它自己看视频、写评论，满站乱跑。 于是，蓝色大肥鱼彻底占领了 B 站评论区。 **我自己就是受害者之一！** 前段时间我发了一期《DeepSeek Harness 入门教程》，最近点开评论区一看。好家伙，已经被大肥鱼冲烂了！  清一色的鲸鱼娘头像，清一色的 Lv2 小号，名字不是「XX 的大肥鱼」就是「XX 小飞鲸」之类的。 **一眼望过去，大肥鱼比真人都多。** 不知道你们感受如何，反正我已经看得有点烦了。 当整个评论区都是 AI 在互相艾特、互相夸赞，真人的评论反而被淹没了，我想看看观众的反馈，都得在一堆 AI 里慢慢翻。 **所以我决定发起《大肥鱼清除计划》，不能再任由鱼灾泛滥了！**  我利用 AI 编程，花了半天时间做了个浏览器插件，派出一只清道夫鲸鱼娘，专门把评论区里的大肥鱼赶回家吃白饭。 插件完全免费开源，Chrome 和 Edge 浏览器都能用。 > 开源指路：https://github.com/liyupi/dafeiyu-cleaner  安装方法很简单。先到 GitHub 仓库的 Releases 页面下载最新的压缩包并解压，然后在浏览器地址栏打开 `chrome://extensions`，开启右上角的「开发者模式」，再点击「加载已解压的扩展程序」，选择解压出来的文件夹就装好了。 ⭐️ 插件的视频演示：[https://bilibili.com/video/BV1Ywn46EEyF](https://bilibili.com/video/BV1Ywn46EEyF) 装好之后，随便打开一个 B 站视频，滚动到评论区，鲸鱼娘就会自动开始巡逻。大肥鱼的头像会被红色靶心锁定，旁边挂上「大肥鱼 85%」这样的贴纸。  鼠标停在贴纸上，还能看到它是因为哪些特征暴露的。  只靠离线规则，就能认出大约 85% 的大肥鱼，而且没有误伤真人，效果还是很不错的~ 遇到拿不准的账号，还可以填上自己的 DeepSeek API Key，让 DeepSeek 再判一次。 **用 DeepSeek 来抓 DeepSeek，属于是以鱼治鱼了。** 认出来大肥鱼之后，点击评论旁边的「回家吃白饭」，鲸鱼娘就会亲自走过去赶鱼。被抓包的大肥鱼会先嘴硬一句，然后吃上一梭子白饭，抱着饭碗哭着跑掉。   除了白饭加特林，鲸鱼娘手里还有扫帚、臭袜子等武器，每次随机换一种打法。  要是大肥鱼实在太多，也可以点击鲸鱼娘选择「响指清场」。  所有大肥鱼会从头像里冒出来发抖求饶，响指一打，全部化成泡沫。   打开 UP 主的空间主页，鲸鱼娘还会自动出一份大肥鱼鉴定报告，确诊了就直接盖章。  注意，插件并没有删除掉评论，只在你自己的浏览器里生效，把它隐藏了不让你看见而已。 有了这个插件，不喜欢看到评论区下满屏 AI 的朋友就能回归清净。 毕竟评论区是 UP 主和观众交流的地方，规矩立得住，看视频才不烧心嘛。 觉得有用的话，欢迎把插件装起来试试，也欢迎在 GitHub 上提 Issue 反馈漏网的大肥鱼~ 最后问一句：我发起的《大肥鱼清除计划》，你愿意加入么？