你好 👋

老样子，在分享实操方法前，我习惯先理清底层逻辑。这不仅能照顾到非技术背景的用户，对我自己也是一种锻炼——将晦涩的专业知识讲得通俗易懂，本身就是一件具有挑战的事。 计费原理 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 的话题挺多的，它能替人干很多活，很多人都在推荐。特别是和我一样的牛马们，仿佛找到了替自己干活的赛博牛马，突然有翻身农奴做主人的感觉，简直不要太爽！ 但爽的同时，必须清醒认识到：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 的文件夹范围太大，它依然能在授权区域内自由读取、修改文件。 传输加密能保护数据在路上不泄漏，但不该上路的数据还是可能会上路。 ...

本文之前发过，但排版有些问题，在此重发。 我一直认为，面试就像相亲一样，一看命运，二看感觉。命运负责安排什么人到你面前，至于能不能在一起，更多时候看感觉。简历筛选有时候也是看感觉，我不相信一个肉眼凡胎，一天面对几十上百份简历，能对每一份简历都做出客观的评价。 这话听起来有点残酷，但承认人的局限性，也许是我们思考“如何让筛选机制变得更公平、更客观”的一个好起点。 最近我们在招聘，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 真正去读每一份简历，流程如下： ...

最近有朋友说：“我每天都有一些很碎片的想法，我想知道，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帮我创建专家的时候，自动起名叫“深度思维引导师”，可能你创建的时候，它的名字不一样，请根据实际情况选择。 ...

最近网上很多教程，教人怎么用笔记软件（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 检索文档并回答问题。 他没有 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（检索增强生成），业界最惯常的思维往往是：上向量数据库、调 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 流水线的每道工序 架构图里的每个节点，对应一道具体的工序。 ...