Posts

说到 RAG（检索增强生成），业界最惯常的思维往往是：上向量数据库、调 Embedding 模型、再写召回逻辑。 然而，在面对中小规模的内部知识库，这条路径往往伴随着较高的成本和复杂的运维。 今天，我们将反其道而行之：不上向量库、不调 Embedding，纯靠标准库的 SQLite FTS5，配合轻量的 jieba 中文分词，来实现一套毫秒级响应的文档检索方案。 这套方案的实现关键，是一个轻量级的文档索引器。 索引器要做到什么？ 存储交给免管理后台、易协同的 Markdown，检索不借助外部 Embedding 模型，那么这个索引器唯一要攻克的难关，就是提供不亚于模糊语义的“检索精确度”。 具体而言，它必须满足以下三项核心指标： 响应快：用户提问后，毫秒级快速返回候选章节； 排序稳：利用 FTS5 内置的 BM25 算法，把最相关的章节推到顶部； 定位准：避开“粗暴按字数硬切片”的局限，精准定位并提取具体章节（Anchor）。 为了达成这些指标，我们需要文档切片、双层分词、虚拟表存储以及密度滑窗高亮等核心技术。在逐个拆解这些技术细节之前，我们先看一下索引器的工作流。 索引器的整体架构 整个设计围绕唯一的核心类 DocIndex 展开。它分为两部分：build() 负责离线建库，而 search() / list() / read() 负责在线查询。 graph TD %% Base Flow subgraph BuildPipeline [Build Pipeline 离线/初始化] A[Markdown 文件] -->|rglob 遍历| B[split_markdown 切块] B -->|生成 Anchor 锚点| C[Chunk 原文] C --> D[jieba 空格 Token 流] C -->|"作为 raw_content (不索引)"| E[(SQLite FTS5 虚拟表)] D -->|"作为 content (索引列)"| E end subgraph SearchPipeline [Search Pipeline 在线检索] F[用户 Query] -->|jieba / Tokens 提取| G[OR 拼接 Match 语句] G -->|MATCH 查询| E E -->|bm25 排序评分/负数越小越相关| H[命中 Chunk] H -->|密度滑窗 & 倒序高亮算法| I[SearchHit 片段] I -->|回显前端/大模型上下文| J[用户/大模型] end 数据模型：FTS5 虚拟表与“双列”设计 建索引的第一步，是定义 FTS5 虚拟表的 schema。 ...

在互联网研发团队里，前后端分离已经是事实标准，这是长期技术演进的结果。 以前开发的流程是：产品需求 ➔ 后端写接口、出文档 ➔ 前端做用户界面、联调。这个模式看似专业，但很多时间浪费在了沟通和扯皮上。 半年前，我们看到 Vibe Coding 带来了效率提升，为了应对变化，我所在的团队做了一个挺激进的决定：依靠 AI 工具，拆掉传统的前后端建制，全面改用“领域负责人”模式。 原有的前端和后端开发人员，现在变成独立垂直领域的负责人。一个人负责从数据库设计、后端逻辑到 UI 全环节闭环。我们这样做，不仅仅是为了效率，更是为了鼓励团队成员拥抱变化，在实践中提升自己的综合能力。 新旧组织架构和工作流程对比 flowchart TB subgraph 传统模式 ["🚫 传统模式：前后端分离 (按职能)"] direction TB P1([产品需求]) --> B1[后端开发<br/>设计表/写接口/出文档] P1 --> F1[前端开发<br/>做界面/等接口/写逻辑] B1 --> J1{漫长的<br/>沟通/联调/扯皮} F1 --> J1 OPS1[全局架构与运维基建] -.底座支撑.- B1 OPS1 -.底座支撑.- F1 J1 --> OPS1 OPS1 --> R1([上线发布]) end subgraph 新模式 ["🚀 AI驱动新模式：领域负责人 (按业务)"] direction TB P2([产品需求]) --> D1[领域负责人 A<br/>研发闭环] P2 --> D2[领域负责人 B<br/>研发闭环] AE[横向架构专家<br/>规范/CR] -.-> D1 AE -.-> D2 AI((AI 工具支持)) -.-> D1 AI -.-> D2 OPS2[全局架构与运维基建<br/>持续集成/自动化] -.稳固底座.- D1 OPS2 -.稳固底座.- D2 D1 --DB+后端+UI--> OPS2 D2 --DB+后端+UI--> OPS2 OPS2 --> R2([上线发布]) end 转型路线 这种组织架构转变，需要一个逐渐学习和适应的过程，我们是分三个阶段推进的： ...

2022年底，OpenAI 首次向公众开放 ChatGPT，不到 4 年的时间里，AI 技术呈现爆炸式发展。今天没有几个人不谈 AI，然而我想问你一个问题：面对 AI 的大浪潮，你是否焦虑？ 随着前段时间 OpenClaw（龙虾）的大火，甚至像“鹅厂”这样的巨头，也亲自下场，摆摊帮用户装“龙虾”。那几天，我收到好多不同行业朋友的私信，问题都是关于它的。我认为这是一个标志性事件，意味着 AI 已经真正走进千家万户。更多人开始思考 AI 对自己的影响，说直白点，人们开始担心 AI 会不会替代自己的工作，这是关乎个体切身利益的。当然，也有人在思考，怎么利用 AI 帮自己做事情。 我当时写了一段通用的回复，就是让大家不要焦虑，警惕 FOMO 情绪—— Fear of Missing Out，是一种害怕错过、恐惧错失的情绪。我最近写关于 AI 的文章，也是刻意保持冷峻，尽量避免用一些容易让人焦虑的词汇，因为我自己也不喜欢看那些夸大叙事的文案。 但我现在回过头来想，我算是一个 AI 从业者，我了解 AI 是什么，了解它是怎么运作的，我甚至用它来替代了很多人工。如果我再去跟一个非技术从业者，或者一个即将被 AI 替代岗位的人，甚至因为 AI 已经失业的人说“不要焦虑”，那是站着说话不腰疼，这跟“何不食肉糜”有什么区别？ 我必须承认，作为一个比较“懂行”的人，我也焦虑过。其实我们可以大胆地承认，我们是焦虑了，那又如何呢？也由不得我们不面对这样的事实。但今天能来看这篇文章的人，我假定你是希望借助 AI 有所作为的。我今天不想跟你说“不要焦虑”，也不想端上“化焦虑为动力”的鸡汤，更不想说“拥抱变化”这样的宏观叙事（这些话，我已经在工作场合说够了 😁）。今天我想从自己的经验出发，分享一些粗浅的见解。 学会战略性掉队 OpenAI 刚发布 GPT-3.5 没多久，我发布了一个基于 OpenAI API 的 Web 客户端的开源项目，因为当时这样的项目还不多，所以这个项目在 GitHub 上很快有了 1K Star。我当时挺兴奋的，只要社区有人反馈问题，我第一时间响应，那段时间可谓没日没夜地干。可是很快，其他厂商的模型也出来了，附带的各种技术也如雨后春笋一般出现：知识库、RAG、文档处理等等。我开始感觉有点跟不上了。因为发展太快了，我有很多东西都需要学习，就特别焦虑，加上连续一段时间的高强度学习和工作，感觉身体不太舒服。 于是我决定放弃更新那个项目，决定不紧跟这些新东西，很长一段时间里，也不去看每天都有什么新的概念、技术出来。后来发现，其实对我的影响也不是很大。我保护了自己，没有过度消耗自己的身心。 自媒体繁荣的今天，每天都充斥着各种“毁灭式”假说——今天不学XXX，明天就被淘汰。如果我们被这样的情绪裹挟，可能会过度地消耗自己。我保护自己的方法很简单，切断那些贩卖焦虑的信息源。你的身体和精神，永远比一个人造的概念有价值。 恐惧是因为未知 虽然我们前面说可以不紧跟新概念，但万变不离其宗，理解一些基本概念和原理还是很有用的。如果自己不去了解，只会被别人牵着鼻子走。 举个例子，现在大家都听说过一个词，叫“智能体”。我作为相关从业者，第一次听到这个词的时候，我是觉得很玄乎的。了解后才知道，这是国内对“Agent”的叫法。我还特意去搜索了港台地区的文章，想看看他们是怎么翻译的，他们的很多文章就叫“代理”，或者直接不翻译，就叫“Agent”。叫“代理”就容易理解很多，它其实是一种连接大模型与各种系统的技术的统称。而 “智能体” 听起来很高级，如果你不去理解背后的意思，是不是就被吓晕了？ 再比如，现在很火的 SKILL（技能），如果你理解它，你就会发现，它的本质还是“提示词”，就是你如何把“一项任务该怎么做”，清晰地表达给大模型。 所以，很多时候我们的恐慌，并不是因为 AI 本身有多可怕，而是来源于信息差。那些贩卖焦虑的人，最擅长的就是造概念。你看到满屏都是自己听不懂的英文缩写，觉得自己已经被时代抛弃了，能不焦虑吗？ 如果你想消除信息差带来的焦虑，请你亲自去脱下那些名词的外衣。如果精力有限，你不需要系统性地去学习，你只需要让 AI 来告诉你：某个词是什么意思？原理是什么？一直问到你理解为止。你就会发现，哦，原来也就那么回事。 ...

过去，合同审批需要审批人逐字对比，有的合同十几页甚至几十页。靠肉眼看，不仅效率极低，而且容易漏看，不同人的判断标准还不一样。 最近，我们决定把 AI 加入到我们的合同审批流程中，来减轻审批人员的工作量。这篇文章，就是本次实战的复盘。不是技术教程，而是真实经验分享。 想象 vs 现实 一开始我们想得很简单：让审批人员把合同丢给 AI 对话框，让 AI 看看有没有问题。 但很快面临几个问题： 数据泄露风险：合同是一家公司的核心机密，不能把原文都发送给模型提供商。 流程脱节：聊天得出的结论无法在公司系统里留痕，也没法在现有的审批流程中流转。 幻觉问题：但合同审批是一件非常严肃的事情，如果 AI 产生幻觉，后果也许很严重。 于是我们转变了思路：我们需要的不是一个“聊天机器人”，而是一条“审批流水线”。 把 AI 审查作为其中一环，AI 只负责发现合同中的风险点，再流转到人工审批。 整体架构 flowchart TD A[业务员上传合同] --> B{预检：文件与模板相似度} B -->|不匹配| B1[告警拦回] B -->|匹配| C[文本提取 + 模板快照冻结] C --> D[AI 大模型审查 + 红线规则引擎] D --> E{风险聚合评分} E -->|低风险| F[流转人工审批] E -->|中高风险| G[直接驳回给业务员] E -->|任何环节异常| H[不放行，标记异常等待重试] F --> I{审批人决策} I -->|通过| J[合同生效] I -->|驳回| K[退回修改] G --> K K -->|重新提交| A 流水线的每道工序 架构图里的每个节点，对应一道具体的工序。 ...

前段时间，一位在教育行业做教研的朋友愁眉苦脸。他们需要从几百份试题文件中把上万个数学题录入到题库中。 作为一个程序员，每次听到这种重复、机械的工作内容，我简直不能忍受。如果让我去干这样的工作，我会感觉很痛苦。 但作为朋友，我能让他这么痛苦吗？于是我决定帮他的团队搭建一套“AI 原生”的题库系统。 什么叫"AI 原生"？ 在我理解中，AI 原生不只是“用 AI”这么简单，而是在做系统架构设计时就将 AI 作为核心要素，在系统的主要流程中起到重要的作用。具体到这个题库系统： 题目不是人手动一个个敲进去的，而是由 AI 从文档中批量提取出来的 知识点不是人手动一个个勾选的，而是由 AI 自动匹配上去的 自带 AI 对话框，AI 不只是"辅助工具"，经过管理员授权，它在系统中可以搜索题库、查询知识点、生成题目和智能组卷 整体架构一览 graph TB subgraph 用户端 Teacher[教师/教研员] Admin[管理员] end subgraph 前端["前端"] Import[智能导入] QBank[题库管理] Chat[AI 对话] Paper[组卷] end subgraph 后端["后端"] API[API 网关] DocProc[文档处理引擎] AIService[AI 服务层] CRUD[数据层] end subgraph AI["AI 引擎"] Gemini[Gemini] OpenAI[OpenAI] end subgraph 存储 MySQL[(MySQL)] ChromaDB[(ChromaDB<br/>向量数据库)] FileStore[(文件存储)] end subgraph 后台 Worker[后台 Worker<br/>批量异步任务处理] end Teacher --> Import & QBank & Chat & Paper Admin --> QBank Import & QBank & Chat & Paper --> API API --> DocProc & AIService & CRUD Worker --> DocProc DocProc --> AIService AIService --> Gemini & OpenAI CRUD --> MySQL AIService --> ChromaDB DocProc --> FileStore 下面聊聊设计过程中的几个关键决策和核心功能。 ...

大模型迭代日新月异，中小企业如何在浪潮中稳住自己才是关键。如果不做好架构规划，有可能今天花十几万买的方案，明天就可能被新模型淘汰。 不管你是自建还是采购 AI 基础设施，请确认是否具备这三层抽象：提供商层（Provider）、模型层（Model）、应用层（Application）。 一、三层抽象架构 graph BT subgraph L1["第一层：提供商层 Provider"] A["基础设施与算力\nOpenAI / Google / 阿里云 / Azure ..."] end subgraph L2["第二层：模型层 Model"] B["通用推理引擎\nGPT-5.5 / Gemini-3.5 / 通义千问 ..."] end subgraph L3["第三层：应用层 Application"] C["助手 Assistant / 智能体 Agent"] end L1 -->|隔离硬件与网络复杂性| L2 L2 -->|隔离技术变动 · 沉淀核心业务| L3 L3 --> D((企业核心业务场景)) 二、 为什么要进行这三层抽象？ 1. 提供商层（Provider）的抽象：获得基础设施弹性 提供商层是算力的物理承载方（如OpenAI、Google、阿里云 等）。在这一层做抽象，本质上是将业务软件与算力提供商解耦。 为什么要做：企业真正需要的不是绑定某一家云厂商，而是稳定、合规、可持续的 AI 算力供给。不同提供商在网络质量、区域合规、价格策略、模型接入速度和服务稳定性上各有差异且随时变化，如果业务代码直接依赖某个底层接口，基础设施的任何波动都会传导到业务系统。 抽象的价值：通过标准的 API 路由或中台网关进行抽象，企业可以把底层提供商变成可调度、可替换的基础设施资源。哪里网络更稳，就优先走哪里；哪里成本更低，就把非关键任务调度过去；哪里合规条件更适合，就把敏感业务部署在那里。核心价值不只是规避供应商锁定，而是让业务不被基础设施的不确定性牵着走。 2. 模型层（Model）的抽象：对抗技术迭代，实现“成本最优解” 模型层是通用的推理"大脑"（如 GPT-5.5、Gemini-3.5、通义千问等）。在这一层做抽象，是将通用的推理智力与具体的业务场景解耦。 为什么要做：没有一个模型能包办企业的所有业务。写复杂代码需要逻辑极其严密的模型，而日常的财务对账、文案润色，国产高性价比模型完全可以胜任。如果统一调用最贵的模型，算力调用的成本会变成无底洞。 抽象的价值：模型层的抽象让企业拥有了"看人下菜碟"的能力。后台可以通过路由机制，根据任务的复杂程度自动分发给不同的模型。更重要的是，当市场上出现更便宜、更强大的新模型时，企业可以随时切换，而不需要重构任何业务代码。 3. 应用层（Application）的抽象：沉淀企业资产，打造真正的行业护城河 应用层是把智力转化为生产力。但模型本身是公共资源，同一个 GPT-5.5 谁都能调用——真正让应用层产生差异化价值的，是企业喂给它的私有数据和行业知识：产品数据、历史订单、客户画像、内部流程 SOP……这些才是别人抄不走的东西。 ...

上一篇讲的是 AI 怎么解决工单提交之后的事（分派给谁）；这一篇讲我们怎么把 AI 再往前挪一步——让用户在写工单的过程中就把内容、类别、优先级都填对填全，避免分派之后来回追问。 一、为什么做这件事 每天我们都会遇到这样的工单： 描述只写一行——“系统报错”，处理人不得不一来一回去问“什么模块、什么单号、什么报错”。 选错类别——本来是“财务分析”问题，用户选成了“账单支付”。分派 AI 收到错误的类别，自然分给了错误的人。 紧急程度全凭感觉——所有提交人都觉得自己的事最紧急，于是“紧急”这个标签也就贬值了。 写完点完提交才想起来漏传截图或附件。 这些问题的本质是：工单质量问题没在源头处理。 我们越靠后干预，代价越大——处理人来回追问、分派被迫返工、用户被打断好几次。 如果 AI 能在用户写描述的过程中就把这些事处理掉，整个链路就顺了。 二、整体设计 我们给这套功能定了一个明确的定位：让 AI 帮忙，而不是替用户做主。 具体落到交互上，提交工单页变成这样： graph TD A[用户开始写描述] --> B{描述够长 / 用户停手?} B -- 是 --> C[后台调用 AI] C --> D[返回: 类别 + 优先级 + 完整性 + 改写] D --> E[类别/优先级字段为空 → 自动采纳, 标 ✨] D --> F{完整性达标?} F -- 是 --> G[显示提交按钮] F -- 否 --> H[暂时不显示提交按钮 + 提示补充] E --> I[用户可一键改 / 直接覆盖] 几个关键的设计选择： ...

一、为什么要做这件事 我们内部有一套自建的工单系统。客户的问题、内部的需求，都通过工单流转。系统用了一年多，功能够用，但有一个问题越来越明显——分派太依赖人。 工单创建后，负责分派的人（本文就叫管理员）要做三件事：看一眼内容是什么问题，想想谁负责这块，然后分派。听起来简单，但我们有十几个业务领域（CRM、订单、商品、申报……），每个领域有技术负责人和产品经理，有的问题是 Bug 要找技术，有的是需求要找 PM。管理员得对团队分工烂熟于心。 现实是： 管理员请假，没人分得准 新来的管理员要花很久才能搞清楚谁管什么 高峰期工单堆积，分派成了瓶颈 分错了还要重新转派，来回耽误时间 我们想了想，这件事完全可以交给 AI 来做——整个过程可以抽象为：“看内容→查分工表→选人。 二、我们怎么做的 2.1 模型选择 我们选了阿里云百炼（DashScope）上的 Qwen 3.7 模型，走 OpenAI 兼容接口。选它的原因也简单：国内访问稳定，按量付费便宜，兼容 OpenAI 协议意味着以后想换模型改个地址就行。 2.2 架构：AI 是插件，不是核心 我们做了一个关键决定：不为 AI 改动现有系统架构。 工单系统原本就有一套自动化规则引擎——“当工单创建时，执行某个动作”。我们把 AI 分派做成了自动化引擎的一种动作类型，和"发送通知"“自动分配"平级： graph TD A[工单创建] --> B[触发自动化规则] B --> C[动作类型: AI 分析] C --> D[AI 返回建议] D --> E{置信度够高?} E -- 是 --> F[自动分派] E -- 否 --> G[生成待审核建议，推送给管理员] 后端实现上，AI 分析是一个异步队列任务。工单创建后立刻返回成功，AI 在后台默默干活，不阻塞用户操作。 这个设计的好处是：关掉这条自动化规则，系统立刻回到手动分派模式，零影响。 同时，所有 AI 相关的配置——模型提供商、模型参数、Prompt 模板、处理人状态——都做成了可视化后台管理页面。组织架构调整、新人入职时，管理员改一下配置就行，不需要开发介入。 2.3 Prompt 才是灵魂 很多人以为接入大模型就是写几行代码调 API 的事。代码确实不多，但写 Prompt 花的时间比写代码多得多。我们迭代了三版。 ...

这桌菜，是一位朋友私信我点的。他原本只问我什么是 SKILL，但这堆概念（Agent、MCP、SKILL、RAG……）彼此咬合得很紧，单拎一个出来讲容易“盲人摸象”，索性一桌端上来。 大前提：区分模型和应用 很多人把“大模型”和“AI 整体”画等号，其实日常用的 AI 是分两层的： 模型层（大脑）：藏在服务器里负责思考的核心引擎。 应用层：你看得见的界面（chatgpt.com、ChatGPT APP）+ 围绕大脑构建的各种辅助组件（也就是下文要讲的 RAG、Agent 等）。 直接上图： flowchart TD User((用户)) subgraph App [应用层] UI[界面: 看得见的输入框] Agent["Agent 框架: 像 OpenClaw🦞、Claude Code、LangGraph 这类调度大厨, 负责拆任务、调资源"] RAG[RAG: 专属知识库补充] SKILL[SKILL: 用到再翻的工作手册] MCP[MCP: 对接外部工具与数据的标准接口] end subgraph Model [模型层 - 核心引擎] LLM((大语言模型: 算力引擎)) end User -- "1. 下达指令" --> UI UI --> Agent Agent -.调用.-> RAG Agent -.加载.-> SKILL Agent -.调用.-> MCP Agent <== "2. 多轮往返: 思考 → 调工具 → 看结果 → 再思考" ==> LLM Agent -- "3. 整合后呈现" --> User 你可以看到，标题里那些缩写全在应用层。Agent 和大模型之间也不是“问一句答一句”，而是会多轮反复往返——后面会再展开。 ...

随着大模型和各类 AI 应用的普及，越来越多用户遇到产品使用问题时，第一反应已经从“去官网查手册”变成了“向 AI 提问”。 然而，通用 AI 的训练数据往往缺乏你家产品最新、最准确的操作指南或使用规则。无论你是 SaaS 厂商、智能硬件企业，还是任何对外提供产品文档的团队，如何让你的客户在使用 AI 时直接精准读取你提供的官方文档呢？ 今天我们就来聊一个简单的方案：基于 MCP（Model Context Protocol） 协议、用 FastMCP 框架，几十行代码搭一个带鉴权的 Markdown 知识库 MCP Server。 1. FastMCP 是什么？ 如果说 MCP 是 AI 与外部数据源之间的通用语言，那 FastMCP 就是让你用几行 Python 就能“开口说”这门语言的工具包。 MCP 是 Anthropic 在 2024 年提出的标准化协议，用于在 AI 模型和外部数据源（或工具）之间建立安全连接。 而 FastMCP 让你不必直接处理 MCP 规范里的底层通信和 JSON Schema 描述：你只需要写普通的 Python 函数，加一个 @mcp.tool() 装饰器，它就会把这个函数自动包装成任意 MCP 客户端都能直接调用的标准接口。 如果你想先把 MCP 和它周围的 Agent、SKILL、RAG 这几个概念一次理清楚，可以先读这篇：《上菜啦！大龙虾、SKILL、Agent、MCP、RAG…》。 2. 适用场景 基于 FastMCP 的极简特性，它非常适合产品和服务提供商打造“智能文档引擎”： 📚 产品官方知识引擎（本文实践）：让客户的 AI 工具直接搜索、读取你家产品的最新 Markdown 使用手册，降低 AI 在回答 API 对接、设备联网等具体问题时产生幻觉的概率。 🛠 内部研发知识库：把内部架构设计、运维规范、Code Review 清单暴露给团队成员 IDE 里的 Copilot/Cursor，避免新人到处问、老人重复回答。 🔐 分级/私域数据访问：通过轻量级鉴权对不同客户开放不同范围的文档，例如对合作伙伴开放高级集成指南，对普通用户只暴露公开 FAQ。 3. 官方文档服务极简架构设计 为了让提供商维护文档最简单，同时对外部调用有一定的权限隔离和控制，我们设计了如下极简架构： ...