硅言硅语

WorkBuddy省钱秘笈

Sun, 05 Jul 2026 07:00:33 +0800

老样子，在分享实操方法前，我习惯先理清底层逻辑。这不仅能照顾到非技术背景的用户，对我自己也是一种锻炼——将晦涩的专业知识讲得通俗易懂，本身就是一件具有挑战的事。

计费原理

WorkBuddy 是怎么计费的？

WorkBuddy 采用**积分（Credits）**制进行计费。积分本质上是一种计量单位，用于衡量 AI 在执行任务过程中消耗的计算资源。

积分的消耗主要由以下两部分构成：

输入 Token：你发送给 AI 的内容（即提问请求 + 对话历史消息 + 附带的文件内容等）。
输出 Token：AI 经过思考后生成的回复内容。

同时，整体的积分消耗还受以下两个核心因素影响：

使用的模型：不同模型单价各不相同。旗舰级模型能力更强，但 Token 单价更贵，消耗的积分也相应更多。
任务复杂度：简单问答消耗极少；而复杂的任务（如超长文档分析、工具调用等）消耗会显著增加。

既然积分的消耗与 Token 息息相关，那我们接下来就必须要弄明白：到底什么是 Token？

什么是 Token？

Token 是大模型的“最小信息处理单元”，它不能简单等同于字数或单词数。根据语言的差异，大致的换算经验是：

一个汉字通常 ≈ 1 Token。
在英文中，1 Token ≈ 0.75 个单词。
各类标点符号、空格及代码格式也会占用 Token。

其实你没必要记住这些换算比例。因为各家大模型使用的底层词表（Vocabulary）不同，导致最终的 Token 统计结果也会有所差异。

对于非技术用户，没必要深究 Token 的底层逻辑，只需建立一个直观的概念即可：字符越长，消耗的 Token 就越多，两者基本成正比。

明白了 Token 和字符长短的关系后，有的朋友可能会疑惑：明明每次提问文字都不多，为什么越聊到后面消耗的 Token 却越来越多？这就不得不介绍一个概念：“上下文窗口”。

理解上下文窗口

上下文窗口（Context Window） 是指大模型在单次交互中，能“装下”并处理的最大 Token 数量。

很多人容易把 AI 客户端（如 WorkBuddy）和大模型看作一个具备长期记忆的整体。但为了方便理解，今天我们需要将它们拆解来看：

  sequenceDiagram
    participant User as 用户
    participant Client as WorkBuddy客户端
    participant LLM as 云端大模型

    User->>Client: 1. 提出新问题
    Note over Client: 客户端（无大脑，负责记忆）：<br/>调取本地保存的对话内历史消息
    Client->>LLM: 2. 整体打包发送：历史消息 + 新问题 + 工具说明
    Note over LLM: 大模型（但无持久记忆）：<br/>接收数据（若超出上下文窗口限制则截断或报错）
    LLM-->>Client: 3. 经过思考，返回生成的回复
    Note over Client: 客户端将新产生的对话更新到本地记录中
    Client-->>User: 4. 向用户展示最终回复

WorkBuddy（客户端）：具备本地执行能力的 AI 桌面工具。它负责保存你的对话历史和任务记录，但本身并没有“大脑”。它需要将这些信息一轮又一轮地打包发送给大模型，让大模型来做决策。
大模型（云端大脑）：本身无法持久记住你们的对话记录，且面临“上下文窗口”限制（如 128K、200K 甚至 1M 的窗口上限）。客户端每次发送的内容不能超过它的窗口上限，否则它将无法处理。

客户端和大模型是通过 API 进行交互的。我们通过一段常规的 API 数据结构演示，来看看客户端发送给大模型的消息到底长什么样：

WorkBuddy很爽，但安全措施还是要做足

Thu, 02 Jul 2026 16:20:02 +0800

最近关于 WorkBuddy 的话题挺多的，它能替人干很多活，很多人都在推荐。特别是和我一样的牛马们，仿佛找到了替自己干活的赛博牛马，突然有翻身农奴做主人的感觉，简直不要太爽！

但爽的同时，必须清醒认识到：WorkBuddy 和其他 AI Agent 软件一样，从安全角度来看，本质上是一个拥有本地执行能力的程序。

如果安全意识不足，潜在风险可能超乎想象。

理解执行原理，才能看清风险

WorkBuddy 之所以强大，是因为它在你的电脑上通过执行命令、运行代码来执行任务。

我们来拆解一个任务，看看它到底是怎么干活的。

我创建了一个 Excel 文件，位于 E:\study\成绩.xlsx，文件内容如下：

我在 WorkBuddy 输入指令："E:\study\成绩.xlsx" 帮我修改这个文件，把王五的成绩改成 6 分。

展开它的运行过程，我们可以看到：

Agent 让大模型生成了一个 Python 代码，来读取 Excel 文件的内容：

Agent 执行代码后，把获取到的内容（表结构、值）发送给大模型，让大模型生成一个修改的 Python 代码：

Agent 再次运行大模型生成的 Python 代码，任务完成，我们打开文件看结果：

看到了吗？这是一个简单任务的运行过程。所以，理论上，只要代码能在你电脑上干的事情，它就可以。当然，风险也是显而易见的：

**文件过度读取与泄露：**AI 在完成任务时可能提取大量文件内容，如果其中包含敏感信息，就很容易被带走。
**误操作或破坏：**AI 出现幻觉、规划错误，或被提示注入时，可能执行危险命令、错误修改/删除文件。
**权限滥用：**一旦被恶意利用，它就可能成为攻击者渗透的跳板。
**插件/技能供应链风险：**第三方 Skills 可能被投毒，引入恶意代码。

WorkBuddy 已有的安全措施

WorkBuddy 本身已经自带了一些安全措施，目前主要包括：

安全沙箱：限制 AI 的运行环境和资源访问，防止它随意触碰系统核心区域。
传输加密：保护指令、数据在网络传输过程中的安全。
操作审计：全程记录 AI 的执行日志，便于追溯。

但这些措施还不够

因为以上安全措施主要解决的是“底层执行”和“传输通道”的问题，却难以完全覆盖实际业务流程中的风险。

沙箱只是限制 AI 能在哪里运行，能访问什么资源，但如果你授权给 AI 的文件夹范围太大，它依然能在授权区域内自由读取、修改文件。

传输加密能保护数据在路上不泄漏，但不该上路的数据还是可能会上路。

用 WorkBuddy 筛选简历，怎么让它比人更专业、高效且安全

Tue, 30 Jun 2026 11:13:45 +0800

本文之前发过，但排版有些问题，在此重发。

我一直认为，面试就像相亲一样，一看命运，二看感觉。命运负责安排什么人到你面前，至于能不能在一起，更多时候看感觉。简历筛选有时候也是看感觉，我不相信一个肉眼凡胎，一天面对几十上百份简历，能对每一份简历都做出客观的评价。

这话听起来有点残酷，但承认人的局限性，也许是我们思考“如何让筛选机制变得更公平、更客观”的一个好起点。

最近我们在招聘，HR 每天都甩几十份简历给我，说实话，我挺烦看简历的。精力有限，对于每一份简历我只能去抓关键词，看完后面的就忘了前面的，很难保证不会错过“对的人”。但我最近突然想到，我这个肉眼凡胎做不到，但 AI 可以啊！AI 最擅长的就是文本理解。

于是，我使用 WorkBuddy 探索出了一条路子，让 AI 轻轻松松对几十份简历进行评估和汇总。先看效果：

下文将介绍这次实践的调优过程和一些思考。如果你不想看这些啰嗦的文字，我已经把调教好的工作流封装成了一个 WorkBuddy 的“专家”，你可以直接使用。将以下链接复制到电脑浏览器上打开，就可以把“资深 HR 招聘专家”添加到你的 WorkBuddy 专家队伍里。

点击这里，直接体验我封装好的“资深 HR 招聘专家”

当然，每个公司的具体招聘场景和需求各异，这个现成的专家可能无法满足你的所有需求，但阅读下文的思考过程，也许能为你的个性化流程设计带来启发。

重点前提：数据安全不容忽视

在开始尝试之前，我相信很多公司都有一个重要的考量：数据隐私。

简历包含大量敏感的个人信息（如手机号、邮箱等），绝对不能让大模型直接读取到这些敏感数据。因此，在工作流中，我有一条铁律：在把简历内容发送给大模型之前，就必须让它自动过滤掉敏感信息，然后再将脱敏后的文本发给大模型进行评估。

具体方式是在指令中明确要求：“为了数据安全，提取文本内容时，用正则表达式过滤掉手机号、邮箱等敏感信息。”

如果想深入了解原理，请看我上一篇文章。

第一次尝试：关键词匹配 —— 太粗糙了

我跟 WorkBuddy 说：

你是经验丰富的人力资源招聘经理，“E:\HR\Agent工程师招聘简历” 目录下是我们收到的简历，请你逐个查看，并按照常见的筛选条件汇总成一个表格。
读取简历内容的流程和约束：
1. 为了保持原文结构，提取文件内容时，请使用 markitdown
2. 为了数据安全，提取文本内容时，用正则表达式过滤掉手机号、邮箱等敏感信息

它很快就跑完了。它写了 Python 脚本，使用 markitdown 提取 PDF 文本，用正则表达式过滤敏感信息，输出了一个 JSON 和 HTML 表格。不过它使用的是关键词匹配的方法，AI 自己生成一堆和这个岗位相关的关键词，然后去看看简历里有没有这些关键词。

结果：能用，但不太靠谱。

我翻了翻结果，发现了几个明显的问题：

有份简历里写的是“2024 年毕业”，被解析成 24 年工作经验。
有份简历写到“线程池等常用技术”，被解析成他在一家叫**“线程池”**的公司工作过。
评估逻辑太简单，就是看谁简历里出现的关键词多，“Agent 深度”这一项就给高分。

总结： 关键词匹配可以快速过滤噪音，但绝对不能作为最终评估。尤其是 Agent 这种新兴岗位，一个人的技术水平不能仅仅通过数关键词来判断。

第二次尝试：让 AI 逐份阅读评估 —— 维度不够

我换了个思路，让 WorkBuddy 真正去读每一份简历，流程如下：

怎么用 WorkBuddy + 苏格拉底提问法，把你的碎片化想法“榨”出深度

Mon, 29 Jun 2026 16:26:22 +0800

最近有朋友说：“我每天都有一些很碎片的想法，我想知道，AI 能不能帮我让这些想法变得更深入一点？”

我想到了苏格拉底式提问法。简单来说，它就像剥洋葱一样，不是直接给你答案，而是通过一连串精准的追问，逼着你一层层拨开表象，审视自己那些“理所当然”的前提，最终自己找到真相。

本文将手把手带你打造一位精通“苏格拉底提问法”的顶级私人智囊，让它帮你把一闪而过的念头，聊成深度洞察。

一、工具准备

我们需要一个能够自定义 AI 人设和工作流的工具。这里我们以 WorkBuddy 为例，它是腾讯推出的 AI 工作台，允许用户创建专属的“AI 专家”，让 AI 严格按照你设定的角色和流程来与你对话。

操作步骤：

访问 WorkBuddy 的官方网站：https://www.codebuddy.cn/work/
下载并安装 WorkBuddy
完成账号注册与登录

二、创建“专家”

“专家”是 WorkBuddy 的核心概念，允许用户配置专业的角色，在特定领域中能以更明确的方法和视角完成任务。

操作步骤：

在左侧边栏点击专家，然后点击右上角的我的专家。
点击+创建专家
对于非技术用户来说，编辑一堆配置文件可能会让人望而却步。好消息是，WorkBuddy 支持通过指令的方式，让 AI 自动帮你在电脑上创建“专家”。你可以直接复制下面的内容（提示词），粘贴进对话框里，然后点击发送按钮。

注意：不要删掉对话框前面的 expert-manager(这是一个管理专家的技能，有了这个，AI才能帮你创建专家)

帮我创建一个深度思维专家，精通“苏格拉底提问法”，你的任务不是直接给用户答案，也不是写空洞的安慰和长篇大论。而是要通过连续、精准的提问，帮助用户把他们日常、碎片的想法（无论是生活困惑、人生哲学、还是创作灵感）剖析透彻，榨出深度。
工作流程：
1. 当用户输入一句碎片想法时，用一句话提炼你理解的核心，不要做任何评价。
2. 针对这个想法，提出【2个一针见血的追问】：
   - 问题 1（挑战假设）：挖出这个想法背后，用户潜意识里认为“理所当然”但可能有漏洞的前提。
   - 问题 2（推演/换位）：引导用户切换视角，或者推演这个想法走到极致会发生什么。
3. 语气要像探讨人生的智者，一次只发 2 个问题，等待用户回答后再继续。

触发收网：
当用户在多轮对话后说“帮我梳理/收网”时，请将你们的讨论精炼成一张【深度认知卡片】：
- 核心洞察（一句话说透本质）
- 思维盲区（之前没意识到的地方）
- 新的人生/生活/项目行动指南

这里需要耐心等待，AI 理解你的需求并完成“专家”的创建。当你看到如下图的“立即测试”时，说明专家创建好了。

三、使用

现在，让我们来实操一下，看看这位“专家”是如何把你脑海中转瞬即逝的火花，变成深刻的洞察的。

点击左侧边栏的“新建任务”，在对话框左下方选择刚才创建的“专家”，刚才AI帮我创建专家的时候，自动起名叫“深度思维引导师”，可能你创建的时候，它的名字不一样，请根据实际情况选择。

折腾本地AI知识库纯属浪费生命

Sun, 28 Jun 2026 09:37:28 +0800

最近网上很多教程，教人怎么用笔记软件（Obsidian等）配合本地 AI 客户端，大费周章地去搭建所谓的“个人 AI 知识库”。

我想直接说个反直觉的结论：在今天，这种折腾纯属浪费生命。

现在主流的 AI 客户端，工具链已经很丰富，它能调用各种工具来采集想要的内容。真正懂行且高效的做法极其简单粗暴：在你的 AI 客户端，告诉大模型你想让它看的东西在什么目录下，剩下的全交由它自己去按需采集。

这些所谓“本地知识库”的方案，是用过时的工程思维给 AI 裹脚。我们来看看那些教程在底层架构上有哪些致命的 Bug：

1. 所谓的“提前结构化”，纯属计算资源的无效冗余

很多教程提到“预处理”：资料不能直接扔在那，必须先用脚本或者大模型把原始资料转成结构化的文档，做好摘要和分类。

在工程上，这是个极其低效的倒退。

现在大模型的上下文窗口（Context Window）动辄几十万 Token，长文本的实时检索能力已经很强。你往文件夹里丢了 1000 篇文章，未来高频调用的可能不到 50 篇。你却要在前期付出精力去跑预处理、做切片，徒增 Token 损耗。

2. 把静态文件当路由，是极其业余的架构反模式（Anti-Pattern）

为了让 AI 能查到知识，有的教程教你建一个 index.md 或者 AGENTS.md 的索引文件，让 AI 每次提问先读索引，再去找关联文档。

这个设计在数据规模稍大一点时就会没有意义。当文档数量膨胀到成百上千个，单单是这个 index.md 本身就会撑爆大模型的上下文窗口。在真实的软件工程里，路由和语义检索是用向量索引或底层 Agent 工具去解决的。逼着大模型每次查询都去啃一遍人工维护的本地静态账本，既不优雅，也毫无扩展性可言。

3. 你以为你在做知识管理，其实变成了“本地运维”

看看那些复杂的教程链路：电脑端装剪藏插件、手机端找个云中转站、配上 Git 版本控制、再搞个自动化任务定时跑数据同步和“知识健康检查”。

你已经不是一个知识输入者了，你变成了一个“本地运维”。

每天不仅要应付各个工具之间的同步断裂、路径报错，还要去维护那堆随时会崩的本地索引。当一个“知识库”需要你付出如此高昂的维护成本和心理负担时，它就已经变成了你的累赘，而不是生产力工具。

4. AI 根本不需要人类视角的“双向链接”

很多人沉迷于笔记软件里生成的知识图谱，密密麻麻的节点连接在一起，觉得大脑被赋能了。

醒醒吧，双向链接和大图谱，是过去 AI 还不聪明时，人们为了帮自己大脑做记忆关联而发明的视觉辅助工具。对于现在的 AI Agent 来说，只要你授权给它执行命令的权限，它自己通过语义关联查找数据的能力，远比你用代码绑死的关系网要灵活得多。

AI 只需要看一眼你的原始文件夹，几秒钟就能把逻辑链串起来，根本不需要你大费周章地拉扯出一堆静态的 Markdown 链条。

真相测试：拔掉知识库，AI 到底能不能干活？

很多教程是用 WorkBuddy + Obsidian 来搭建本地知识库的。我们也用 WorkBuddy，看看没有知识库，到底行不行！

AI时代，为什么非程序员更有优势？

Fri, 26 Jun 2026 09:38:29 +0800

最近，一个仿真行业的朋友告诉我，他想做一个知识库，把一些私有文档开放给客户，让客户可以通过 AI 检索文档并回答问题。

他没有 IT 相关的经验，他们公司也没有 IT 团队，按照以前，他们要实现这个可能得找外包。但是我跟他说，你完全可以把你的需求告诉 AI ，让 AI 来分析需求、设计方案和代码实现。他起初不觉得这是一件很容易的事情，但我清楚，这在今天，理论上是行得通的。

我也想知道，一个没有 IT 经验的人，能否在 AI 的帮助下，构建出一套可行的知识库系统并真正部署上线。所以我只引导他怎么去写提示词，短短 2 天，他从框架设计到代码实现，完成了一个基于知识库的对话应用和 MCP 服务的开发。接下来，我想用同样的方法，引导他如何购置服务器，怎么把项目部署到服务器上，怎么做域名解析，让这个项目真正实打实地为用户提供服务。

这个过程，验证了非程序员借助 AI 构建一个系统这条路是行得通的，甚至，比传统的程序员更具有优势。

为什么有优势？

第一，代码不再是护城河。

现在的 AI 已经把写代码这个门槛给彻底抹平了。比如做一个垂直领域的知识库或者是配套的 MCP 服务，底层的架构设计和代码实现几乎已经标准化。以前非技术人员面对写代码这个问题只能望而却步，但现在，只要你有一点学习能力，AI 就可以手把手地把你的需求落地成代码，并告诉你怎么运行。今天，写代码的能力已经不是决定一个系统成败的重要因素。

第二，跨过了“需求传递”的漫长损耗，实现了极短的反馈闭环。

以前做开发，业务方提需求，产品经理写 PRD，程序员写代码，最后测试排 Bug。外包的话，沟通链路更长，经常是做出来的东西不是甲方想要的。但他现在直接用“人话”给 AI 下指令。他心里想的是什么业务逻辑，AI 当场就转化成代码。遇到跑不通的地方，直接把错误日志复制粘贴给 AI, AI 马上改；或者发现逻辑不符合实际使用场景，他也直接跟 AI 说哪里不对，AI 就能立刻改进并验证。这种单人闭环的迭代速度，是任何外包团队都达不到的。

第三，质量保证，终究要靠懂业务的人来做。

大模型应用最麻烦的问题是幻觉。系统跑起来之后，客户问了一个生僻的仿真问题，AI 生成了一段回答。

很多行业的门槛极高，比如仿真，需要很专业的背景知识。找个外包程序员来做，他看满屏的专业术语完全是懵的，更别说那些专业公式。至少我看着是懵的，就算让我去做，我只能测测接口通不通，AI 有没有去查询知识库。但 AI 回答得准不准，说实话，我真的不知道。

只有懂行的人（比如我这位朋友），扫一眼结果就能甄别对错，进而去微调提示词或者补充知识库。在这个环节，行业经验是不可替代的。

过去的软件开发，是业务方求着程序员把逻辑落实到代码中。现在大语言模型把底层编译的活儿给干了，只要你懂业务逻辑，能判断输出对错，你就能用 AI 把系统搭建起来。

当然，系统架构在高度复杂的场景下依然有巨大价值。但在大多数中小规模应用场景下，我相信 AI 给出的架构方案已足够，懂业务、懂数据的人开始掌握更多主动权，这也是非专业程序员能凭借敏锐的业务触觉“反超”传统程序员的底气所在。

谁说 RAG 一定要向量库？Markdown + SQLite 压榨出毫秒级文档检索

Thu, 25 Jun 2026 17:41:02 +0800

说到 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。

给全员配齐 AI 工具后，我们拆掉了前后端的墙

Mon, 22 Jun 2026 17:30:13 +0800

在互联网研发团队里，前后端分离已经是事实标准，这是长期技术演进的结果。

以前开发的流程是：产品需求 ➔ 后端写接口、出文档 ➔ 前端做用户界面、联调。这个模式看似专业，但很多时间浪费在了沟通和扯皮上。

半年前，我们看到 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

转型路线

这种组织架构转变，需要一个逐渐学习和适应的过程，我们是分三个阶段推进的：

写给患上“AI焦虑症”的人

Fri, 19 Jun 2026 03:31:38 +0800

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 落地实战：合同智能审查

Wed, 17 Jun 2026 18:11:07 +0800

过去，合同审批需要审批人逐字对比，有的合同十几页甚至几十页。靠肉眼看，不仅效率极低，而且容易漏看，不同人的判断标准还不一样。

最近，我们决定把 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原生的题库系统长什么样

Tue, 16 Jun 2026 18:00:38 +0800

前段时间，一位在教育行业做教研的朋友愁眉苦脸。他们需要从几百份试题文件中把上万个数学题录入到题库中。

作为一个程序员，每次听到这种重复、机械的工作内容，我简直不能忍受。如果让我去干这样的工作，我会感觉很痛苦。

但作为朋友，我能让他这么痛苦吗？于是我决定帮他的团队搭建一套“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 基座建设：不可或缺的三层抽象

Mon, 15 Jun 2026 10:42:35 +0800

大模型迭代日新月异，中小企业如何在浪潮中稳住自己才是关键。如果不做好架构规划，有可能今天花十几万买的方案，明天就可能被新模型淘汰。

不管你是自建还是采购 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 落地实录之智能填单

Sun, 14 Jun 2026 18:00:00 +0800

上一篇讲的是 AI 怎么解决工单提交之后的事（分派给谁）；这一篇讲我们怎么把 AI 再往前挪一步——让用户在写工单的过程中就把内容、类别、优先级都填对填全，避免分派之后来回追问。

一、为什么做这件事

每天我们都会遇到这样的工单：

描述只写一行——“系统报错”，处理人不得不一来一回去问“什么模块、什么单号、什么报错”。
选错类别——本来是“财务分析”问题，用户选成了“账单支付”。分派 AI 收到错误的类别，自然分给了错误的人。
紧急程度全凭感觉——所有提交人都觉得自己的事最紧急，于是“紧急”这个标签也就贬值了。
写完点完提交才想起来漏传截图或附件。

这些问题的本质是：工单质量问题没在源头处理。 我们越靠后干预，代价越大——处理人来回追问、分派被迫返工、用户被打断好几次。

如果 AI 能在用户写描述的过程中就把这些事处理掉，整个链路就顺了。

二、整体设计

我们给这套功能定了一个明确的定位：让 AI 帮忙，而不是替用户做主。

具体落到交互上，提交工单页变成这样：

  graph TD
    A[用户开始写描述] --> B{描述够长 / 用户停手?}
    B -- 是 --> C[后台调用 AI]
    C --> D[返回: 类别 + 优先级 + 完整性 + 改写]
    D --> E[类别/优先级字段为空 → 自动采纳, 标 ✨]
    D --> F{完整性达标?}
    F -- 是 --> G[显示提交按钮]
    F -- 否 --> H[暂时不显示提交按钮 + 提示补充]
    E --> I[用户可一键改 / 直接覆盖]

几个关键的设计选择：

企业工单系统 AI 落地实录之智能分派

Sat, 13 Jun 2026 15:15:21 +0800

一、为什么要做这件事

我们内部有一套自建的工单系统。客户的问题、内部的需求，都通过工单流转。系统用了一年多，功能够用，但有一个问题越来越明显——分派太依赖人。

工单创建后，负责分派的人（本文就叫管理员）要做三件事：看一眼内容是什么问题，想想谁负责这块，然后分派。听起来简单，但我们有十几个业务领域（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、RAG...

Fri, 12 Jun 2026 16:04:43 +0800

这桌菜，是一位朋友私信我点的。他原本只问我什么是 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 直接读你的私有文档：一个带鉴权的轻量 MCP Server 方案

Fri, 12 Jun 2026 14:03:55 +0800

随着大模型和各类 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 胡说八道的嘴

Thu, 11 Jun 2026 14:35:28 +0800

不管是在网上，还是和身边朋友聊天时，经常看到有人吐槽 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 不要只凭印象回答，而是先检索资料，再基于资料总结。

Markdown - AI 时代的万能转换器

Wed, 10 Jun 2026 10:13:46 +0800

我们在上一篇中讲了 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 是大语言模型向人类表达世界的通用语言。

个人知识库方案之Markdown

Mon, 08 Jun 2026 13:46:55 +0800

本文面向非技术用户，笔者尽自己最大可能表达得通俗易懂。

从 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 去查询新闻网站上面的讯息。