7.31 RAG八股+小程序学习+公众号阅读

RAG八股

讲讲你用的向量数据库？数据量级是多大？性能如何？遇到过性能瓶颈吗？

面试官您好，我整套 RAG 项目是分两个阶段落地的，前期本地原型验证用Chroma ，正式上线生产环境换成了Qdrant，这块选型思路也是踩坑之后才理顺的。

先说数据量级：知识库原始文档拆分切片之后，向量总量稳定在380万条左右 ，向量维度是 768 维，基于 BGE 嵌入模型生成，每条向量都会挂载部门、文档类型、更新时间这类元数据字段，日常还要持续增量新增文档，日均写入向量大概 2 万条。索引默认用的行业主流HNSW 图索引，追求高召回率，业务要求检索召回稳定在 94% 以上。

再讲线上实测性能，我们部署是单机高配服务、Docker 容器化部署，搭配 NVMe 高速磁盘：

查询性能：普通用户问答请求取 Top5 召回，单次检索 P50 延迟稳定在 8~12ms，高峰期并发拉高时 P99 延迟控制在 35ms 以内，接口整体 QPS 平稳支撑 200 左右，完全匹配内部客服问答系统的并发需求；同时 Qdrant 原生自带混合检索，稠密向量 + BM25 稀疏检索一起召回，专有名词、产品编号这类精准内容不会丢召回，弥补纯向量检索的短板。

写入性能：批量同步知识库数据时，写入速率能跑到 5000 向量 / 秒，增量单条实时写入毫秒级完成，支持在线热更新索引，不用停服重建索引，知识库修改、删除文档都不会影响线上检索服务。

然后重点说实际遇到的三处明显性能瓶颈，以及对应的优化方案，刚好对应向量库底层原理、索引特性、工程使用问题：

第一个瓶颈是叠加元数据过滤后，检索延迟翻倍上涨。

最开始写代码是先做向量 ANN 检索、再去过滤元数据标签，经常出现召回的 Top 结果全都不符合部门、时间筛选条件，只能放大召回数量再过滤，白白增加检索计算量，延迟直接翻一倍。优化方案可以改成检索前置过滤，让 Qdrant 先根据 metadata 条件圈定数据子集，只在筛选后的数据集里执行 HNSW 检索；同时给高频过滤字段建立标量索引，过滤耗时直接砍掉 60%，延迟回归正常区间。

第二个瓶颈是HNSW 索引内存占用过高，大向量量下频繁出现内存波动。

HNSW 依靠多层图结构查询快、召回高，但缺点就是内存开销大。300 多万条向量全量加载进内存时，服务内存峰值冲到 22G，服务器内存资源紧张，偶发 OOM 告警。优化做了两件事：第一开启8bit 向量量化压缩，向量存储体积直接压缩 75%，内存占用降到 9G 左右，召回率仅仅下跌 1 个百分点，完全在业务容忍范围；第二调整HNSW 构建参数，合理调低 M、efConstruction 参数，在不影响线上查询 ef 取值的前提下，缩减索引构建时的图节点连接数，平衡内存与检索精度。

第三个瓶颈是大批量批量导入向量时，线上查询 QPS 断崖式下跌。

大批量同步历史知识库的时候，后台构建 HNSW 索引会抢占 CPU、磁盘 IO 资源，前台用户检索请求排队堆积，响应超时率升高。优化策略一是拆分大批量任务，改为分片分批异步写入，错开业务访问高峰执行全量同步；二是开启 Qdrant 的写入限流，隔离读写资源，读写链路互不抢占硬件资源；三是冷数据开启磁盘存储模式，高频访问的热向量常驻内存，冷热分层进一步缓解内存、IO 压力。

顺带对比一下当初为什么放弃 Chroma 上生产：Chroma 上手零成本、Python 一行安装就能跑，开发阶段效率很高，但它的分布式体系不成熟，数据突破百万级之后检索延迟抖动很明显，也扛不住并发访问，只适合本地调试、原型验证。而 Milvus 虽然适配亿级超大分布式场景，但是部署依赖组件多、运维成本太重，我们团队人手有限，300 多万的量级 Qdrant 刚好兼顾性能、运维成本，是性价比最高的选择。

补充一下底层原理层面的理解：IVF 聚类索引更适合亿级海量数据、靠牺牲少量精度换取更低内存开销，我们当前量级没必要更换 IVF，后续数据突破千万、走向集群化部署时，才会考虑 HNSW+IVF 两种索引按需切换使用。整体整套使用流程，也是吃透向量数据库 ANN 检索本质、索引算法差异之后，一步步调优落地的。

小程序

页面导航

什么是页面导航

小程序中实现页面导航的两种方式

声明式导航

导航到 tabBar 页面

导航到非 tabBar 页面

后退导航

编程式导航

导航到 tabBar 页面

导航到非 tabBar 页面

后退导航

导航传参

声明式导航传参

编程式导航传参

在 onLoad 中接收导航参数

页面导航模块综合练习

公众号阅读

AI编程能力边界探索：基于 Claude Code 的 Spec Coding 项目实战｜得物技术

文章章读书笔记：AI编程能力边界探索

一、核心概念：Spec Coding (规格驱动编码)

定义：在写代码前，先编写规格文档，通过 openspec 工具驱动开发。
工作流四阶段 ：proposal（提案）→ specs（规格）→ design（设计）→ tasks（任务）。
三大价值：
1. 减少返工：在"为什么做"和"怎么做"上先达成共识。
2. 驾驭复杂：跨文件、跨层级的复杂功能通过分组任务让AI聚焦。
3. 可审计性：完整的决策链记录（提案→设计→任务），方便回溯。

二、项目实战：10天从0到1全流程

项目背景：标准的企业级中后台（表格、表单、看板），全程使用 Claude Code，无产品经理和UI设计师。
关键数据 ：10天，217条指令，2754次工具调用 （读取738次、编辑550次、命令662次、任务标记208次），净增2.5万行代码 ，提效36%。
四阶段演进路线：
1. 设计：AI扮演产品经理和UI设计师，产出PRD和高保真HTML原型。
2. 搭建（2天）：问答式交互，搭建基础设施，打通前后端链路。
3. 功能开发（4天，89条指令）：引入SDD，80%功能在此阶段完成。
4. 打磨部署（4天，108条指令）：重构、优化、解决复杂构建问题。

三、四大典型案例复盘

AI驱动产品设计：AI通过扮演不同角色（PM、UI、研发），独立完成从概念到PRD的全流程，改变了传统三角色模式。
SDD驱动功能研发 ：开发"定时任务管理"模块，AI代码占比100%，6个接口通过MCP直连文档一次生成、零联调返工，单日人效提升3倍。
SDD驱动系统重构：区别于新功能，重构是"在活体系统上动手术"。通过34个精确任务，将混乱的组件解耦，巨型Hook和组件Props得到有效治理。
复杂问题排障：揭示了AI的失效模式。本地无法复现的CI构建问题，因多根因掩盖、隐性行为无文档、跨平台不一致等因素，耗时4小时才解决。

四、三大核心基础设施

三层规范体系（消除不确定性）：
- 约束层 (rules/)：7个文件，规定"禁止什么"（如ts、命名、代码风格）。
- 示范层 (code-design/)：标准模板代码，告诉AI"标准产出长什么样"。
- 视觉层 (ui-design/)：HTML设计稿，告诉AI"页面应该长什么样"。
MCP工具链（消除信息断层）：
- 接口文档MCP：AI直连API平台，自动拉取完整字段、枚举、必填项，零遗漏。
- 飞书文档MCP：AI直读PRD和设计文档，无需人工复制粘贴。

五、核心洞察：重新理解AI与开发者

AI新角色："极度服从、无限耐心、但缺乏内部业务常识的顶级执行者"，而非简单的"副驾驶"。
AI能力边界框架：
- 能做：确定性空间内的高效执行。
- 受限：需要人对不确定性的空间（业务、环境、隐性知识）进行边界划定。
分级协作模式：
- 小需求（改文案）：直接对话，即扫即改。
- 中需求（标准CRUD）：基于Rules/Skills预设规范生成。
- 大需求（复杂模块）：走完整的OpenSpec (SDD)标准流。
AI三种失效模式与对策：
1. 规范真空 ：自行填充默认值 → 对策：补全CLAUDE.md规范，一次修复。
2. 信息孤岛 ：看不到系统外状态（如CI环境）→ 对策：在架构设计阶段前置锁定跨环境依赖。
3. 目标模糊 ：把问人的问题当执行问题 → 对策：Spec的proposal阶段强制要求先写"Why"。
开发者角色重构：
- 工作重心向上迁移：从写代码 转为写规范、定架构、审质量。
- 核心竞争力变为：规范设计能力 、系统性思维 、前移的质量意识。
一句话总结 ：AI Coding的本质是用结构化规范将不确定性消除在执行之前。规范是杠杆，AI是力，Spec是支点。

💬 评论区要点总结

关切与挑战：
- 技术债务/老项目：大家普遍关心在有历史背景和复杂技术债（如2000年老项目）的项目中如何应用。
- 设计还原度：设计产物与最终实现效果对不上，如何解决？（作者回复：通过完善指令，让AI更新各阶段产物）。
- 需求频繁变更：业务来回折腾时，这套流程的鲁棒性如何。
工具与方法论细节：
- 图片生成工具 ：文章中的插图使用开源技能 baoyu-article-illustrator 生成。
- 工作流顺序争议 ：有评论指出Spec顺序应是proposal→specs→design，作者回复称openspec源码中specs和design在proposal完成后是并行状态，顺序有随机性。
- 质量保障补充 ：有评论建议在SDD基础上引入TDD (测试驱动开发)，用superpowers插件保证质量。
- 调整流程：开发中需要调整时，如提案未归档可继续对话修改；如已归档，建议新建提案