前段时间，一位在教育行业做教研的朋友愁眉苦脸。他们需要从几百份试题文件中把上万个数学题录入到题库中。 作为一个程序员，每次听到这种重复、机械的工作内容，我简直不能忍受。如果让我去干这样的工作，我会感觉很痛苦。 但作为朋友，我能让他这么痛苦吗？于是我决定帮他的团队搭建一套“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. 官方文档服务极简架构设计 为了让提供商维护文档最简单，同时对外部调用有一定的权限隔离和控制，我们设计了如下极简架构： ...

不管是在网上，还是和身边朋友聊天时，经常看到有人吐槽 AI 胡编乱造。 相信最近很多人都刷到过一个很搞笑的事件：一位网友轻信豆某包关于机票退票手续费仅 5% 的建议，实际被扣 40%，损失 600 元。豆某包随后生成“赔付承诺书”却因无法转账反悔，并支招网友起诉自己，该网友随后便向法院提交了立案申请。 这类问题在 AI 应用里有一个专门的说法，叫“幻觉”（Hallucination）。 今天我想聊聊，AI 为什么会产生幻觉，以及我们在日常使用中，怎么尽量降低它胡编乱造的概率。 AI 为什么会胡编乱造？ 你有没有好奇过，为什么 AI 明明不知道答案，却还能说得那么完整？ 很多人会把 AI 想象成一个巨大的资料库。我们问一个问题，它就去资料库里查一条记录，然后把结果返回给我们。 但大模型默认并不是这么工作的。 我们可以简单粗暴地理解为：大模型更像一个“超级文字接龙机”。当然，这只是一个方便理解的比喻。现代大模型在训练中确实学到了很多概念、知识和推理模式，但它最基础的生成方式，仍然是根据前面的上下文，预测后面接什么内容最合理。 比如我说“锄禾日当”，模型很容易接出“午”。因为在它见过的大量文本里，这两个词经常连在一起。 如果问题是写一段文案、整理一份提纲，这种能力非常好用。但如果问题是“某个政策是哪天发布的”“某个案例是否真实存在”，它就可能出问题。因为这类问题需要核对事实，而不是只生成一段看起来顺的文字。 我们可以把没有检索工具参与的回答过程，看成一次“闭卷考试”： flowchart TD User[用户提问: 帮我查某行业市场数据] Model[大语言模型] Context{上下文里有可靠依据吗?} Guess[根据语言模式生成回答] Detail[补全听起来合理的细节] Answer[输出一段看似完整的回答] User --> Model Model --> Context Context -- "依据充分" --> Answer Context -- "依据不足" --> Guess Guess --> Detail Detail --> Answer 所以我们会看到一种很奇怪的现象：它不是简单地说“不知道”，而是生成了一段看起来有帮助的回答。问题在于，看起来有帮助，不等于事实上可靠。 那如果我们在提示词里写“不要编造，不知道就说不知道”，有没有用？ 有用，但不是保险丝。它通常能降低一部分风险，但只要模型手里没有可靠证据，而你的问题又要求它给出完整答案，它仍然可能根据模糊记忆和语言模式，生成一段没有依据的内容。 所以，减少幻觉的关键，不是反复提醒它“你不许编”，而是改变任务结构。 怎么让 AI 少胡编乱造？ 让 AI 先查资料 最直接的办法，是让 AI 不要只凭印象回答，而是先检索资料，再基于资料总结。 ...

我们在上一篇中讲了 Agent + Markdown 作为私有知识库的可能性，今天我想分享一些我对 Markdown 的认识。 我与 Markdown 的不解之缘 我已经记不清第一次看到 Markdown 这个词是什么时候了，或许是第一次接触开源项目，看到项目下的 README.md，又或许是当年玩博客的时候，寻找好用的编辑器的时候发现的。 总之它在我的工作和生活中，出现的频率越来越高。因为我是一个程序员，所以接触得算是比较早的。早期只用它来写项目的文档。后来用 hugo 搭建了基于 Markdown 的个人网站，这样我可以把更多精力放在内容输出上，不用管排版这些琐事。再后来，市面上涌现了诸如 Obsidian、Logseq 这样优秀的双链笔记软件，它们无一例外地将 Markdown 作为底层格式，让它一跃成为了个人知识库管理（PKM）的绝对主力。现在呢，作为AI应用的开发者，几乎每天都用到它，因为几乎所有主流大模型的 API 在默认情况下都采用 Markdown 格式进行输出。 大模型的通用语言 你有没有好奇过，你在与AI对话的时候，AI应用是怎么展现那么丰富且有层次的内容的？比如下图是我与 Grok 的对话，它的回答包含了表格、无序列表。 这只是比较简单的回答，它的表现力远不止于此。那它是怎么实现的？答案是 Markdown。模型层面给出的内容如下图： 我们可以把一个AI应用分成2个抽象层：模型层和应用层。当我们发起提问时，应用层将问题转发给模型；模型经过计算，生成纯文本的 Markdown 内容作为回答；而像 Grok 网页端或手机 APP 这样的应用层，在接收到 Markdown 后，会利用内置的渲染器将其转换成丰富的视觉效果呈现给我们。这形成了一个完整的交互闭环： flowchart TD User((用户)) subgraph App [应用层] Input[对话输入框] Renderer[Markdown 渲染器] Output[富文本视图展现] Renderer --> Output end subgraph Model [模型层] LLM(大语言模型) end User -- "1. 提问/输入提示词" --> Input Input -- "2. 转发请求" --> LLM LLM -- "3. 返回 Markdown 纯文本" --> Renderer Output -- "4. 呈现最终结果" --> User 所以，我们可以简单粗暴地理解为：Markdown 是大语言模型向人类表达世界的通用语言。 ...

本文面向非技术用户，笔者尽自己最大可能表达得通俗易懂。 从 Chatbot 到 Agent 从 2022 年 11 月 OpenAI 首次向公众开放 ChatGPT 到今天，LLM（大语言模型）和相关生态的发展可谓日新月异。 最开始的时候，人们只是把它当成一个聊天机器人，用来写文案、解答问题、生成代码和翻译等。但 LLM 发展到了今天，情况已经彻底不同。我们已经从单纯的 Chatbot 时代，进入 Agent 时代。 如果你知道什么是 Agent, 请跳过这部分。 这个 Agent，国内翻译过来叫做智能体。我感觉这个翻译有点玄乎，所以特意去搜了一下其他中文区（港台）的人是怎么翻译的，人们经常直接使用英文原词 Agent，或者称之为“代理”。我认为直接叫 Agent 更让人容易理解，因为它本质上就是一个大模型和其他系统的代理，所以在本文中我们就直接叫 Agent 。 那我们经常听到大模型和Agent，它们到底是什么关系？其实一句话就能说清楚：大模型是“大脑”，而 Agent 是它的“手”。 ​大模型本质上是一个纯粹的“输入输出模型”。它的知识在训练完成的那一刻就被冻结了，它没有眼睛，也没有触角，无法主动连接这个世界。你给它什么输入，它就给你什么输出。 Agent 就像是一个中间代理。它可以去浏览网页、获取最新的新闻、读取你本地的文件、甚至调用各种外部工具。它把抓取到的最新信息，重新打包，源源不断地“喂”给大模型。​大模型负责思考，Agent 负责连接。 graph TD User((🧑‍💻 用户)) -->|发指令| Agent{🤖 Agent} Agent -->|调动| Tools[🌐 网页 / 📁 文件 / 🔧 工具] Tools -->|返回真实世界信息| Agent Agent -->|整理打包并提交| LLM((🧠 大模型)) LLM -->|思考并解答| Agent Agent -->|把大模型的答案交付给| User classDef user fill:#e1f5fe,stroke:#03a9f4,stroke-width:2px; classDef agent fill:#fff9c4,stroke:#fbc02d,stroke-width:2px; classDef llm fill:#fce4ec,stroke:#f06292,stroke-width:2px; class User user; class Agent agent; class LLM llm; 我们举个例子，在 ChatGPT 刚发布的时候，你问它今天有什么新闻？它会跟你说：“对不起，我的知识截止到某年某月某日”。那今天我们去问AI，今天有什么新闻？它能够回答了，因为它现在可以通过 Agent 去查询新闻网站上面的讯息。 ...