现在安装 MySQL 真方便：直接让 AI 帮忙安装，再跟着它的指引，在 DataGrip 里配置本地连接。

最近看了一个视频叫「被 Vibe Coding 抚平的大脑褶皱，还能救回来吗？」，聊的是 AI 时代学编程的困境，感觉说的挺好的，给鱼友们分享一下。 视频中提到现在学编程和以前最大的区别是，以前卡住了你只能自己想、查文档、翻 Stack Overflow，这个过程虽然痛苦，但你的脑子确实在转。现在有了 AI，卡住的第一反应就是打开 ChatGPT 问一句，代码瞬间就出来了，跑通了，感觉自己搞定了。但问题是，你的大脑在这个过程中几乎没有参与。视频里提到一个实验，有个学生读完题 10 秒钟就放弃思考去问 AI 了，事后还觉得是自己独立完成的。这就是 AI 带来的最大陷阱——你以为自己在学，其实只是在看AI 表演。 视频基于一项研究，总结了学编程时容易掉进去的 8 种思维陷阱。研究表明光是知道这些陷阱的存在，就能明显提升学习效果。前 5 种是编程学习中一直存在的，后 3 种是 AI 时代新出现的： 1）Forming（构建错误）：你理解了问题，但用了错误的方法去解决。比如题目要你判断正数多还是负数多，你写了个求和的逻辑，方向对了路走偏了。 2）Dislodging（思维固着）：你已经意识到方法不对，但就是转不过弯来换思路，反复在错误的方向上修修补补。 3）Assumption（假设偏差）：你完美地解决了一个问题，但不是题目要求的那个问题。比如题目要处理任意个数字，你只处理了四个。4）Location（定位缺失）：跳过了关键步骤就开始写代码，感觉快写完了，测试的时候才发现漏了循环或数据结构这种核心东西，得大改。 5）Achievement（成就幻觉）：写了一大堆代码，明知道有问题但不愿意推倒重来，总想着再改改就好了，结果越改越乱。 6）Progression（进度错觉）：AI 帮你写出了超出你水平的代码，作业都能交，但基础可能已经落后好几周了，自己完全不知道。这个是最危险的，等到面试或者独立写代码的时候才发现脑子里是空的。 7）Interruption（思维中断）：你正在集中精力思考，AI 自动补全突然弹出来一段代码，思路直接被打断。有意思的是实验中表现好的学生大多直接忽略了 AI 的补全建议。 8）Mislead（误导跟随）：信了 AI 给的一个看似合理但方向错误的建议，白白浪费时间走弯路。 大佬给出的建议是，遇到问题先别急着问 AI，给自己至少五分钟独立思考。卡住、沮丧、想摔键盘，这些不是你学不会的信号，这就是解决问题时的正常感受。AI 生成的代码跑通之后，试着关掉 AI 自己从零写一遍，能写出来才算真的会了。最重要的是分清场景，工作赶进度可以用 AI 提效，但练习和学习的时候请把「拐杖」放下，自己走。别让 AI 替你长脑子。

学习开源项目时我们应该画哪些图？

大家好，我是不会喷火的小火龙。 刚开始深入看开源项目的时候，我经历过两个极端。 一个是纯靠肉眼硬看。连着翻了三天，几万行代码从头看到尾，自以为搞懂了，合上电脑脑子里依然是一团浆糊。 另一个是把精力全花在画图的排版上。打开 Draw.io，花了一整个下午在画布上拖方块、微调对齐像素、挑选各种莫兰迪配色，画出一张五颜六色的庞大架构图。结果第二天回头看，自己都找不到核心的调用链路在哪里。 后来我才明白，画图真正的价值是帮大脑把复杂的调用和数据流降维，理清骨架，而不是做图表美化。 关键在于什么阶段、带着什么目的、选什么工具、画什么图。 这篇文章把这件事梳理清楚：工具怎么选、常见问题对应什么图、拿到项目按什么顺序画，以及几个容易踩坑的地方。 --- ## 一、工具选型：Mermaid、draw.io、Excalidraw、SVG 各自的边界 很多人问我画图该用什么工具，我的建议是不同场景用不同的工具，不用强求某一款。 ### Mermaid：代码化与版本管理首选 Mermaid 用纯文本语法生成图表，天然支持 Git 版本管理，和 Markdown 完美融合。GitHub 的 README 里直接写 Mermaid 代码就能直接渲染。 它的优势在于修改极快：调整一张图只需要改几行文本，不用打开任何独立的图形编辑器，也特别适合让 AI 帮我们生成初稿。 适合场景：API 调用流程图、Agent 状态执行循环、时序图（Sequence Diagram）、README 技术流程文档。 ### draw.io：正式架构与工业级排版 draw.io（diagrams.net）完全免费开源，组件库非常全，自带 AWS、GCP、Azure 和 K8s 的官方图标集。它的连线锚点吸附精准，支持复杂的多层对齐。当你需要画一张正式的技术方案图或论文架构图时，它最稳妥。 适合场景：微服务架构图、云原生与 K8s 部署拓扑、技术方案设计图、PPT 汇报图。 ### Excalidraw：讨论方案与直观教学的手绘白板 Excalidraw 的手绘质感能降低心理门槛。画出来的线条带着手绘感，不会让人觉得是不可更改的最终定稿，反而能鼓励大家提出修改建议。 适合场景：早期技术方案讨论、团队白板脑暴、教程里的直观概念解释图。 ### SVG：矢量控制与极简图形 SVG 本质是 XML 代码，可以精准控制每一个节点与路径，无限放大不会模糊，文件体积极小。 适合场景：极简矢量插画、高质量技术信息图、Logo 与技术图标。 ### AI 生图：概念隐喻与视觉呈现 如果不需要精确的技术细节，只是想表达某种技术概念的反差或情绪隐喻，用 Midjourney 或 GPT-4o 生图效率最高。 适合场景：技术博客与公众号封面、宏观概念反差插画。 如下表所示，我把常见的开发场景与推荐的绘图工具整理成了对照表： | 开发场景 | 推荐工具 | 选型理由 | |:---|:---|:---| | API 调用流程 | Mermaid | 纯文本代码化，Git 可版本控制，AI 生成方便 | | Agent 执行流程 | Mermaid | 状态循环与条件分支表达清晰 | | UML 时序图 | Mermaid | 语法简洁，`sequenceDiagram` 原生支持强 | | 微服务架构图 | draw.io | 组件库全，锚点吸附准，适合复杂拓扑 | | 云 / K8s 架构 | draw.io | 内置各云厂商与 K8s 官方图标 | | 论文系统架构 | draw.io / SVG | 矢量导出，排版精度容易对齐 | | 方案讨论草稿 | Excalidraw | 手绘风格心理门槛低，方便随时修改 | | 教程解释图 | Excalidraw | 风格柔和，降低读者的理解门槛 | | README 技术流程 | Mermaid | 直接在 Markdown 中渲染，无需上传图片文件 | | PPT 高质量信息图 | SVG / draw.io | 矢量无损缩放，支持精细排版 | | 博客 / 公众号封面 | AI 生图 | 视觉冲击力强，易于传达情绪 | | 概念视觉 | AI 生图 | 适合抽象概念的隐喻呈现 | | 极简矢量插画 | SVG | 代码可控，文件体积极小 | | Logo / Icon | SVG | 矢量无限缩放，保持视觉规范统一 | --- ## 二、问题驱动：想搞清楚什么问题，就画什么图 画图容易犯的错误是把静态依赖、动态调用和部署环境全揉在一张图里，箭头到处穿插，最后画成一张谁也看不懂的蜘蛛网。 画图的核心是问题驱动：心里有什么疑问，就画什么图去回答。 工程中常见的核心问题，可以按照从宏观到微观分为四个层次。如图所示：  下面挑几个最常用的具体拆解： **系统架构图**回答项目整体是干什么的。重点标出前端、后端、AI 模块、数据库、消息中间件以及第三方外部服务的边界，让人一眼看清系统的大致构成。 **模块图与组件图**回答项目由哪些模块组成。重点是标清每个模块的单一职责，以及模块之间的单向依赖关系。 **调用链图**回答一个请求穿透了哪些代码。从 Controller 到 Service，再到数据访问层，梳理出入口到出口的调用路径。 **时序图**回答不同对象之间的调用顺序。谁先发起调用、返回什么、是同步等待还是异步通知，时序图最适合表达这类时序关系。 **数据流图**回答数据从哪里来、到哪里去。顺着请求参数，看它在内存里被转换成了什么对象、通过消息队列发送了什么格式、最终持久化到了数据库的哪些字段。 **状态图**回答核心对象的状态迁移规则。比如订单从待支付到已支付、已发货的生命周期，或者 Agent 记忆提取时的添加、更新、删除判定。 **Agent Workflow 图**回答 AI Agent 怎么循环运转。LLM 推理、工具选择、执行反馈、记忆读写、条件路由，这些用带有判断条件的状态图画出来最为直观。  --- ## 三、实战闭环：学习开源项目的 6 步画图 SOP 拿到一个陌生的开源项目，具体可以按下面这 6 步来画。如图所示：  ### Step 1：跑起来项目，画系统架构图 这是第一步。先别扎进源码，顺着 README 的 QuickStart 把 Demo 跑通一遍，感受一下输入输出和交互方式。 项目跑起来后，画一张粗粒度的系统架构图：前端在哪、后端在哪、用了什么数据库、调了哪些第三方接口。这张图不需要任何代码细节，把黑盒变成灰盒即可。 ### Step 2：看 README 和目录结构，画模块图 不深入具体文件，只看一级目录名和项目文档说明。弄清楚项目分了几个主要模块、各模块负责什么业务、它们之间的大致依赖方向。 画出来的模块图应该能解答一个问题：如果后续要改某个功能，应该去哪个目录下找。 ### Step 3：选一个核心功能，画业务流程图 在所有功能中，选出最常用的一条主线（Happy Path）。比如电商项目选下单支付，Agent 项目选用户提问到输出回复，知识库项目选文档解析到检索召回。 画出纯业务视角的流转步骤：从哪里触发、经历几个阶段、产生什么结果。这一步暂时不涉及具体的代码和类名。 ### Step 4：从入口开始追踪源码，画调用链或时序图 找到入口函数（比如 Controller 接口或 CLI 命令），顺着刚才挑出的业务主线单向跟读代码。 这里有个关键原则：只跟正常流程的主干，先忽略异常重试、参数兜底和日志打印。把一条请求流经的关键类和方法串联起来。涉及多个对象协同的，画时序图往往更清楚。 ### Step 5：分析关键参数与消息传递，画数据流图 把目光从代码调用转移到数据本身。请求携带的入参是什么结构，在中间层被解组成什么对象，有没有通过消息管道流转，最终落盘时的表结构是怎样的。 数据流图能帮我们理清核心业务实体在整个系统里的流动全貌。 ### Step 6：遇到复杂结构按需补图 前 5 步已经能帮我们掌握系统的大致脉络。遇到某些局部复杂度高的模块，再针对性补充： - 数据库表关联较多，补一张 ER 图 - 类继承和接口抽象层级较深，补一张类图 - 实体状态迁移规则较多，补一张状态图 - 涉及智能体自主决策，补一张 Agent Workflow 流程图 - 涉及上线部署和容器编排，补一张部署架构图 举个例子，如图所示，一个典型的 AI Agent 循环执行图如下：  Agent 的核心机制包含推理、判断、工具调用、观察反馈与再次推理。这类包含循环与条件分支的结构，用状态图能够把每一次跳转的条件表达得清晰明了。 --- ## 四、画架构图容易踩的 3 个坑 很多经验丰富的工程师画出来的图线条不多，但表达很精准。他们通常会注意避开这几个常见误区： ### 1. 试图在一张图里展示所有细节 如果一张图在 30 秒内没办法让读者看明白核心逻辑，说明它的信息量过载了。 不少人画图习惯把所有技术栈图标全摆上去，每个方块之间拉满箭头，最终变成一张庞杂的连线网。好的架构图通常是做减法的结果，画出来的模块越克制，沟通成本越低。 ### 2. 第一版图就塞入大量分支逻辑 第一版架构图最好只关注标准的正常流程。 如果一上来就把重试策略、熔断降级、权限校验、日志打点全画进去，主干流程就会被杂音淹没。先把正常主干画清晰，有需要再为复杂的边缘逻辑单独画子图。 ### 3. 脱离源码之后图无法自解释 判断一张图是否清晰的标准很简单：不看源码的情况下，把图拿给同组的工程师看，对方能不能在短时间内看懂业务逻辑和流转顺序。 如果必须边看图边翻源码才能明白箭头在表达什么，说明图上的职责边界或数据流向还没有梳理到位。 --- ## 写在最后 画图本身并不是目的，通过画图建立对系统的全局理解才是目的。 代码细节随时可以让 AI 协助编写或查找，但能把复杂系统抽象为清晰结构的能力，是工程师长期积累下来的关键基本功。 下次看一个陌生的开源项目时，可以先别急着逐行读代码。先问自己当前最需要弄清楚什么问题，选好合适的工具，把那张对应的图画出来。 --- > 我是小火龙，一个持续在 GitHub 等开源社区挖掘真正好用、能打的高价值项目，同时记录自己用 AI 搓工具、做产品、踩坑填坑全过程的独立开发者。如果今天这篇对你有启发，欢迎关注公众号「**[小火龙AI 手记](https://mp.weixin.qq.com/s/u_bHjYo00gbDJUk8bTkrdA)**」，我们下篇见。

DeepSeek 官方偷偷上传 Harness 桌面端安装包，我已经用上了。。附最新下载地址

大家好，我是程序员鱼皮。 前段时间我写过 [一篇文章](https://mp.weixin.qq.com/s/ieOE4mzyMoa8OVcAOAkhzg)，说自己在 DeepSeek Harness 的开源仓库里发现，官方竟然偷偷做了桌面端。  当时官方没有放出安装包，我是让 AI 帮忙把源码拉到本地编译，才跑起来的。  没想到才过了十来天，DeepSeek Harness 桌面端的安装包就出来了。不过这次并不是官方正式发布的，而是被万能的网友给扒了出来！ 有网友发现 DeepSeek 自家的下载域名多了桌面端的更新清单和安装包，顺藤摸瓜找到了下载地址，很快就在社交平台上传开了。还有网友专门验了签名，安装包用的是「杭州深度求索人工智能」公司主体的苹果开发者证书，并且通过了苹果官方的公证，基本可以确定是 DeepSeek 自己打的包。 **但到目前为止，DeepSeek 官方还没有发任何公告。** 虽然官方还没官宣，但很多人已经吃上螃蟹了（包括我）。截止到文章发布时，最新版本是 `0.1.7-rc.2` 。 下载地址我已经帮大家整理好了： - DeepSeek Harness 客户端 Windows 版本：https://download.deepseek.com/dsh-desk/bin/win-x64/deepseek-harness-0.1.7-rc.2-win-x64.exe - DeepSeek Harness 客户端 Mac 版本（Apple 芯片）：https://download.deepseek.com/dsh-desk/bin/mac-arm64/deepseek-harness-0.1.7-rc.2-mac-arm64.dmg 目前官方只打包了这两个版本，用 Intel 芯片 Mac 和 Linux 的朋友暂时还得再等等。 安装包都不小，Windows 版接近 300 MB，Mac 版将近 370 MB。因为官方把 Node.js、pnpm 和 Python 运行环境全都打包了进去，你的电脑上不用提前装任何环境。 **选择对应系统的版本下载，双击安装就能打开了。** 第一眼看上去，桌面端的界面跟 DeepSeek Harness 网页版几乎一模一样。  我去翻了下仓库里 `apps/desktop` 目录的源码，桌面端是在完整的 DSH 网页应用外面套了一层 Electron 壳，界面用的是同一套前端代码。 套壳的好处是，桌面端的对话记录和配置都跟网页版是互通的。因为两者读写的是电脑上同一个 `~/.dsh` 数据目录，我之前在网页版里创建的工作区和聊过的会话都还在，配置好的第三方模型也能直接切换使用。  新版本的 DSH 还在左侧菜单栏加了一个「插件」入口，里面内置了 7 个官方插件，包括智能体团队、自动授权审查、语音输入、终端、Agent 循环、子智能体和网页搜索。比如开启智能体团队插件后，就能让多个 Agent 分工协作，还带有共享的任务看板。  除了官方插件，你还可以点击右上角的「添加插件」，直接输入 GitHub 仓库地址来安装第三方插件。 比如我安装了一个社区开发者做的 dsh-web 全家桶插件，它把一大批网页端的增强插件聚合到了一起，能全方位增强 DeepSeek Harness 的能力。  装好之后，DSH 就变成了这个样子，聊天背景换成了二次元插画，右下角还多了一个看板娘。 你喜欢么？  让我比较意外的是，桌面端和网页版的 UI 还是有点儿差别的。比如在左下角可以直接登录 DeepSeek 账号，查看充值余额、查询用量，还能直接充值。  而且登录账号之后，模型列表里会多出一组「DeepSeek 账号」模型，可以直接用账号里的余额来跑任务，不用再去开放平台单独申请 API Key 了。对新手来说，这一步能省掉不少麻烦。  能看出来，DeepSeek 官方这次是真的打算好好做 Harness 桌面端了。账号登录、首次使用引导、自动更新这些面向普通用户的功能都安排上了，安装包还用公司证书做了签名，值得期待一波。 **但是，我不建议大家现在就把 DeepSeek Harness 桌面端当作主力工具，尝尝鲜就好。** 一方面，官方还没有发布上线公告；另一方面，作为实验版本，它的功能还不全，体验也比较一般。 比如我在 Mac 上就没办法缩放字体，一开始我还以为是自己没找到设置，后来翻了下源码，发现 macOS 的菜单里确实没有放大和缩小这两项，所以给大家看的截图字都很小。。。 **臻品大家共赏，屎给鱼皮先吃。** 为了帮大家节省时间，我是认真的！ 最后分享一下，我是怎么实时获取到 DeepSeek Harness 桌面端的最新下载地址的？🤔 **很简单，直接问 AI 啊！** 我让 DeepSeek Harness 用最简单直接、不绕弯子的方式告诉我怎么获取：  原理其实很简单。桌面端内置了自动更新功能，每隔 10 分钟左右就会去官方服务器读取一份更新清单文件，清单里写着最新的版本号和安装包地址。所以我们也不用去猜文件名，直接打开这份清单看一眼，就能拿到最新的下载链接： - Windows 版更新清单：https://download.deepseek.com/dsh-desk/feeds/win-x64/nightly.yml - Mac 版更新清单：https://download.deepseek.com/dsh-desk/feeds/mac-arm64/nightly-mac.yml 注意，Mac 版清单里给的是 `.zip` 格式的自动更新包，把链接结尾的 `.zip` 换成 `.dmg`，就是我们平时双击安装的安装包了。 OK 就聊到这里，如果你还不了解 DeepSeek Harness，或者想学习更多 AI 编程工具的玩法和技巧，可以看看我免费开源的 [《AI 编程零基础入门教程》](https://ai.codefather.cn/vibe)，上千张图、几十万字，带你从 0 开始快速学会 AI 编程，做出自己的产品、跑通变现全流程，一次拿捏。 > 开源指路：[https://github.com/liyupi/ai-guide](https://github.com/liyupi/ai-guide)  我是鱼皮，持续分享 AI 编程干货。觉得有用的话记得点赞收藏和关注~ 你已经装上 DeepSeek Harness 桌面端了么？用起来感觉怎么样？欢迎在评论区聊聊~

AI 时代学习开源项目的正确姿势

大家好，我是不会喷火的小火龙。 前段时间，我为了搞懂一个 GitHub 上 5 万星的开源 Agent 框架，把仓库一股脑扔进 Cursor，开启 `@workspace` 让 AI 从 `src/` 目录开始逐文件解释。花了一整天，把核心类打满了中文注释，每个函数都附上了"作用说明"，感觉自己全看懂了。 结果隔天想动手写一个轻量版，打开空白编辑器，两眼一黑。 "ToolManager 为什么要从 Agent 里抽出来？""上下文压缩应该放在哪一层？""权限沙箱的边界到底怎么划？"这些问题一个都答不上来。我盯着空白屏幕意识到：昨天一整天的"阅读"，全是假的。 这种状态在认知心理学里有个名字，叫**假性掌握（Illusion of Competence）**。AI 解释得越流畅，你的思维惰性越严重。你以为自己在学习，其实只是在围观 AI 表演。 如图 1 所示，这就是盲目用 AI 逐行翻译源码与真正用架构思维学习的区别。  今天这篇文章，我想认真聊聊：**在 AI 时代，学习一个开源项目，到底应该学什么、怎么学？** --- ## 一、从"读代码"到"看系统"：时代已经变了 在 AI 编程工具出现之前，读源码是一件极其痛苦但又绕不开的事。 那时候的经典方法论，我管它叫**传统 18 条心法**，核心逻辑是这样的：先背 JDK 基础类库，再学常见设计模式，然后找到入口类，单步断点逐行跟踪调用链，在脑子里（或纸上）手动还原整个执行路径。 这套方法有它的智慧。"先跑通 demo 再看源码""先抓主线再看分支""不要过度扣实现细节""看类名和职责而不是看每一行"，这些都是经过大量实战锤炼出来的工程常识，到今天也没有过时。 但那个时代读源码的终极目的是什么？是为了"手写出同样的代码"。背面试八股需要它，手写中间件需要它，排查线上疑难 Bug 也需要它。 今天呢？Coding Agent 已经能秒级生成几千行符合规范的业务代码。你让它手写一个完整的 CRUD 服务、一个 CLI 工具、甚至一个中间件的骨架，它可能写得比你还快还规范。 开发者的不可替代能力，正在发生根本性的转移。 如图 2 所示，两代开发者在源码学习上的能力链路已经截然不同：  过去拼的是"手写代码的能力"，现在拼的是"看透系统设计，并判断 Agent 写出来的东西到底对不对"。 这就是我理解的核心原则：**Architecture First，Code Second。** 代码不是学习的终点。代码是验证你对架构理解是否正确的证据。 --- ## 二、核心武器：Architecture First，Code Second 搞清楚能力转移的方向之后，具体该怎么落地？我的解法只有一句话：**Architecture First，Code Second（架构优先，代码次之）。** 这套方法论包含四个核心动作。 ### 1. 先理解系统，再看代码 过去很多人读源码，习惯顺着目录树从上往下点： `目录结构 → 模块 → 类 → 方法 → 逐行读代码` 这种读法在 AI 时代投入产出比极低。几万行代码看下来，脑子里全是一堆函数碎片，拼不出完整画面。 更有效的方式是完全倒过来： `项目解决什么问题 → 用户输入与输出 → 核心模块划分 → 数据流转链路 → 关键抽象决策 → 最后精读那 20% 核心代码` 打开一个项目，先搞清楚它在什么场景下解决谁的问题，一条正常请求从进入到返回经历了哪些节点。把骨架理清楚了，细节才有挂靠的地方。 ### 2. 先抓一条主干，暂时屏蔽分支 一个 5 万行代码的成熟项目，通常包含大量边缘处理逻辑：异常重试、灰度开关、多版本兼容、各种格式适配。 如果一上来就试图把这些细节全看懂，很快就会被淹死。 任何系统都有它的主干（Happy Path）。用户发一条请求，系统走最标准的成功路径返回结果。先顺着这条主线走一遍，把核心流转搞明白。至于重试机制、错误兜底、特殊边界，等主干通了再去抽查，效率高得多。 ### 3. 追问"为什么存在"，而不是"里面写了什么" 在源码里看到一个重要的类或抽象时，不要把力气花在看具体语法上。重点问三个问题： 1. 为什么需要这个独立模块？ 2. 如果把它删掉，直接写在调用方里，系统会发生什么？ 3. 有没有别的替代方案，作者为什么选了当前的写法？ 可迁移的从来不是某种语言的语法糖，而是这些设计权衡。只要换个业务场景，语法可能全变了，但模块解耦和职责划分的思路是通用的。 ### 4. 终极验证：脱离源码自己推演一遍 检验自己有没有真正理解一个系统，最好的标准很简单：关掉源码窗口，假设给你一个类似的需求，你能把核心模块的划分、数据流和关键接口画出来吗？ 如果能推演出来，说明抓住了系统的骨架；如果脑子一片空白，说明只是在围观代码，并没有把它内化。  --- ## 三、实战拆解：设计一个 Coding Agent 时，我们到底在学什么？ 理论说多了容易空，我拿一个真实的例子来展开。 最近我在研究如何自己搓一个轻量级的 Coding Agent（类似 Claude Code / Cline 那种），需要参考现有的成熟项目。这个过程中，两种截然不同的学习深度给了我很大的触动。 ### 低阶学法：机械读代码 让 AI 逐行分析 `tools/file_reader.py` 里的装饰器怎么写的、入参用的 Pydantic 还是 dataclass、异常处理走的哪个分支。花半天时间搞明白了"这个文件怎么写的"，但完全不知道"为什么要有这个文件"。 ### 高阶学法：理解设计决策 我开始问一个完全不同的问题：**为什么成熟的 Coding Agent 里，核心推理循环（ReAct Loop）的代码量不足整个系统的 1%，而超过 99% 的工程代码都在做 Harness（载体架构）？** 答案是：一个能在生产环境跑起来的 Agent，需要解决的工程问题远比"调 LLM API"复杂得多。权限沙箱、上下文压缩、工具调度与注册、状态恢复、错误重试……这些构成了系统真正的壁垒。 其中最让我印象深刻的一个设计决策是：**为什么必须把工具抽象成一个独立的 ToolManager（工具管理类），而不能把"读文件""写文件""执行终端命令"这些操作直接写在 Agent 的主循环里？** 如图 3 所示，一个设计良好的 Coding Agent，核心循环与工具层应该是完全解耦的：  这时候"反事实推演"就派上用场了。我问自己三个 What If： **What If 1：把工具代码直接写在 Agent 主循环里？** 工具从 3 个增长到 50 个时，Agent 主文件会膨胀成一个几千行的"上帝类（God Class）"。每加一个工具都要改核心循环的代码，任何一个工具的 Bug 都可能导致整个 Agent 崩溃。 **What If 2：没有统一的权限网关？** `read_file` 是只读操作，`bash_exec` 可以执行任意终端命令，两者的安全级别完全不同。如果没有 ToolManager 层统一拦截和分级授权，系统在生产环境就是一颗定时炸弹。 **What If 3：工具接口不统一？** 每个工具的输入输出格式各不相同，LLM 的 Tool Calling 就需要为每个工具写一套特殊的适配代码。而且当 MCP（Model Context Protocol）这类动态扩展协议出现时，没有统一接口的系统根本无法接入外部工具生态。 这三个反事实推演做完，我对"为什么需要 ToolManager"的理解，比逐行读完所有工具代码加起来都深刻。 这就是高阶学法的要点：真正有价值、能终生迁移的，从来不是某一行代码怎么写，而是**"为什么要有这个抽象、如果没有它系统会发生什么"**。 --- ## 四、两套开箱即用的实操 SOP 方法论再好，落不了地也是空话。我把自己用过的学习路径整理成了两套 SOP，分别对应两种最常见的场景。 如图 4 所示：  ### SOP A：JD 倒排驱动法（面对有教程的成熟大项目） **Step 1：先跑起来。** 这条传统心法到今天依然是黄金准则。不要上来就扎进源码，先顺着 QuickStart 或 Demo 把项目跑通一遍，亲手感受它的输入是什么、输出是什么、核心交互长什么样。没有体感的阅读是盲人摸象。 **Step 2：用 5 份目标岗位 JD 倒逼学习优先级。** 找 5 份你感兴趣的岗位 JD（比如"AI Agent 工程师"或"LLM 应用架构师"），把里面的技能关键词提取出来，让 Agent 帮你把教程中的模块重新排序： - **P0（精学）**：JD 中高频出现、且你目前不会从零设计的模块。比如 Tool Calling 机制、Memory 管理。 - **P1（理解原理）**：JD 提到但你有一定基础的。比如 Prompt Engineering、RAG Pipeline。 - **P2（快速浏览）**：了解有这个东西就行。比如部署方案、监控接入。 - **P3（直接跳过）**：纯粹的样板代码、DTO 定义、配置文件。 **Step 3：按"能力主题"驱动学习，不要按章节翻阅。** 比如你这一周的学习主题是"Tool Calling 机制"，那就跨章节把所有跟 Tool Calling 相关的内容串起来看，而不是从第 1 章读到第 20 章。 ### SOP B：核心链路追踪法（面对只有 GitHub 仓库的野生项目） **Step 1：让 Agent 做一次 Repository Survey。** 不要让它逐个目录介绍"这个文件夹是什么"，而是让它以架构师视角回答："系统的输入是什么？输出是什么？中间经过了哪些核心模块？数据是怎么流转的？" **Step 2：找到唯一入口，顺着 Happy Path 单向追踪。** 从 `main.ts`、`cli.py` 或 HTTP 入口开始，追踪一个最典型请求从进入到返回的完整路径。不要分叉，不要看错误处理，先把"正常情况下系统怎么工作"搞清楚。 **Step 3：只精读那 20% 决定 80% 行为的核心代码。** 它们通常是：核心循环（如 ReAct Loop）、核心抽象类（如 BaseTool / ToolManager）、核心机制（如上下文压缩策略、记忆提取逻辑）。其余的胶水代码、配置解析、日志打印，让 AI 总结即可，不用你自己读。 --- ## 五、把 Agent 变成你的"架构导师与面试官" 学完方法论和 SOP，最后还有一个认知转变：**你对 Agent 的提问方式，决定了你的学习深度。** 大多数人跟 Agent 的对话停留在最浅的两层："这个函数是干什么的？""这段代码怎么运行的？"这跟查字典没有本质区别。 如图 5 所示，真正高价值的提问应该从 What 逐步跃迁到 Design：  Level 4 之前是知识获取，Level 4 之后才是能力构建。 ### 终极验证：逼自己"重新设计" 我自己用得最多的一个 Prompt 模板，分享给大家： > **Prompt**："现在假装你看不到这个项目的源码。我来描述一个需求：我需要设计一个支持动态扩展的工具管理系统，要求能统一注册、参数校验、权限分级和沙箱执行。请你像一个架构师导师一样，不要直接给我答案，通过不断追问来引导我完成设计。等我设计完成后，再拿我的方案与这个开源库的真实实现做对比，指出差异和不足。" 用这个方法，学习过程就变成了： 1. 自己先思考，画出你认为合理的架构； 2. Agent 通过追问暴露你思考的盲区； 3. 你修改方案后，Agent 拿真实源码跟你对比； 4. 差异本身就是你最大的学习收获。 只有脱离源码也能把类似系统的架构重新画出来，才算真正完成了工程能力的内化。 --- ## 写在最后 代码依然重要。但在 AI 时代，代码已经从"学习的终点"，变成了"验证你对架构理解是否正确的证据"。 传统心法里那些精华，先跑通 demo、抓大放小、看职责而非实现，到今天不仅没有过时，反而成了指挥 Agent 的核心心法。变化的是工具，不变的是系统思维。 如果你也在用 AI 学项目、搓工具，希望这篇的两套 SOP 和六层提问模型能帮到你。 --- > 我是小火龙，一个持续在 GitHub 等开源社区挖掘真正好用、能打的高价值项目，同时记录自己用 AI 搓工具、做产品、踩坑填坑全过程的独立开发者。如果今天这篇对你有启发，欢迎关注公众号「**[小火龙AI 手记](https://mp.weixin.qq.com/s/zRLvhMoVhhW0WjEFwAXJHg)**」，我们下篇见。

实习招聘

坐标杭州、上市公司/西湖大学机器感知与学习实验室 我们专注具身智能前沿研究。现面向全球招募访问学生，四个方向任你选👇 ## 🧊 方向一｜数据采集 ▸ 机器人操作数据处理与数据集构建（遥操作 / 仿真 / UMI/Ego） ▸ 多源数据对齐与预处理、标注体系建设 ▸ 对接模型训练团队，建设数据标准与规范 💡加分项：LeRobot/RLDS、ROS2/OpenCV/PyTorch、大规模机器人数据处理 Pipeline ## 🧠 方向二｜模型研发 ▸ VLA/WAM/VLM 具身模型整体方案设计与训练优化 ▸ 记忆机制研究、仿真 / 真机评测方法构建 ▸ 算法落地为可复现训练推理流程 💡加分项：顶会论文、多模态 / 视频模型研究、分布式训练经验 ## ⚙️ 方向三｜模型部署（Jetson 端） ▸ VLM/VLA 高效部署至 NVIDIA Jetson ▸ PyTorch→ONNX/TensorRT 转换、INT8 量化与推理优化 ▸ VLA 推理架构设计 + ROS 真机联调 💡加分项：TensorRT Plugin/CUDA Kernel、vLLM、真机 / 端侧 AI 部署经验 ## 🌍 方向四｜物理引擎开发 ▸ 面向具身仿真的物理引擎研发（机械臂 / 双足 / 人形） ▸ 刚体动力学 / 接触求解 / 碰撞检测 / GPU 大规模并行仿真 ▸ 持续优化仿真参数，提升 Sim2Real 一致性 💡加分项：MuJoCo/Isaac Sim/Genesis/Newton、CUDA/HPC 经验 真弹性办公，自由选择工作时间。每日不少于8小时，然后待遇高于市场水平（因为还要物色是否有读博打算，所以多给点钱希望来的人优秀）

从重排序到 RAG 护栏：TypeSafe 如何把 AI 判断变成可编程能力

# 从重排序到 RAG 护栏：TypeSafe 如何把 AI 判断变成可编程能力 > 面向 AI 应用开发者的 System One、概率决策与企业落地教程  我最初是从官方的 re-ranking cookbook 接触 TypeSafe 的。文档里写“performance 提升”，图表又是 Top-1、Top-5、Top-10，我一开始还在想：这里说的性能，到底是接口更快，还是正确率更高？ 顺着这个问题继续看，疑问越来越多：BM25 本来不是就会排序吗？RRF 和 TypeSafe 是替代关系吗？RAG 段落分类能不能拿来做入库前的数据清洗？函数调用、引用核对和 LLM 护栏，为什么也会出现在同一个产品的 cookbook 里？ 把这些内容串起来以后，我发现 TypeSafe 最容易被误解的地方，是我们习惯把所有模型都放进“生成式大模型”这个框里。它实际在解决的是另一类问题。 做 AI 应用时，我们很容易形成一种惯性：只要任务里出现自然语言，就把它交给大模型生成答案。 这套办法能跑起来，但系统一复杂，问题也会跟着出现。一次模型调用既要理解意图，又要选工具、找证据、判断风险，最后还要生成回复。返回值通常是一段文本，程序再从文本里解析 JSON；一旦模型换个说法，后面的控制流就可能失效。 TypeSafe 想解决的是这类问题中的一小块：**程序不需要模型“写一段话”，只需要它做一个受约束的判断。** 例如： - 这 30 个候选段落中，哪一个最可能回答问题？ - 这段检索结果是否包含直接证据？ - 用户是在查订单，还是要退款？ - 这条引用真的支持前面的结论吗？ - 当前判断是否足够确定，可以自动执行？ TypeSafe 把这类任务称为 System One：给模型一份状态，再提出若干个窄而明确的问题，模型返回类型化答案、概率和置信度，剩下的选择、阈值、路由与副作用仍由代码掌控。 所以这篇文章不把 TypeSafe 讲成又一个万能模型。我会把它放回真实的 AI 应用架构中，看看它与 BM25、向量检索、RRF、传统 reranker 和生成式 LLM 到底是什么关系，以及哪些场景值得用，哪些场景不值得。 --- ## 一、生成答案和做判断，本来就是两类任务 先看一个企业知识库助手。用户问： > 员工试用期内离职，需要提前几天通知？ 系统背后可能要完成这些动作： 1. 判断问题属于人事制度，而不是财务或 IT； 2. 从知识库中召回相关制度； 3. 判断哪些段落真正包含答案； 4. 排除过期制度、矛盾材料或提示注入； 5. 让 LLM 根据证据组织答案； 6. 核对答案中的引用是否真的支持结论； 7. 风险过高或证据不足时转人工。 真正需要“写自然语言”的主要是第 5 步。其余大多是分类、评分、真假判断和路由。  如果所有步骤都用一个生成式 LLM 完成，应用会遇到三个工程问题。 第一，**输出不稳定**。你想要的是 `{"route":"hr"}`，模型有时会返回解释文字，有时换字段名，有时补充你没有定义的分类。 第二，**控制权模糊**。同一个 prompt 既藏着业务规则，又藏着流程路由。出现误判时，很难说清到底是规则有问题、上下文不够，还是模型生成发生漂移。 第三，**不必要的生成开销**。当你只想知道“是否相关”，生成一段理由再解析成布尔值，本身就是绕路。 TypeSafe 的切入点不是把生成模型赶出系统，而是把“判断”从“生成”里拆出来。 --- ## 二、TypeSafe 的核心心智模型：状态、问题、答案、代码 一次典型调用可以画成四步：  ### 1. State：把当前事实交给模型 State 是模型判断时能看到的上下文，可以是一段文本，也可以是 JSON、字符串数组等文本结构。例如： ```json { "query": "试用期离职要提前几天？", "candidate": "试用期员工提前三日书面通知用人单位，可以解除劳动合同。", "document": { "title": "员工离职管理办法", "effective_date": "2026-01-01" } } ``` State 的重点不是“写得像 prompt”，而是把判断所需的事实给全。TypeSafe 官方目前说明 Jev 接受文本类状态，不直接读取图片、音频或视频；多模态内容要先由其他组件转成可判断的文本。 ### 2. Questions：把模糊任务拆成窄问题 不要问“这份材料怎么样”，而要问： - 它是否直接回答用户问题？ - 它是否已经过期？ - 它是否与查询中的前提冲突？ - 它是否包含试图操纵下游模型的指令？ 这些问题可以一起发出，互相独立地对同一份 State 做判断。 ### 3. Answers：返回类型化结果，而不是一段自由文本 答案不是解释性文章，而是程序可以直接读取的选择、分数和概率。 ### 4. Code：决定怎么使用答案 阈值、组合权重、失败降级、数据库写入、调用工具和发送消息都留在代码里。模型负责“看懂”，代码负责“做事”。 这条边界很重要：TypeSafe 不是一个替你接管业务流程的 Agent。它更像程序中的一组语义判断函数。 --- ## 三、Choice、Score、Noul：三个原语怎么选 TypeSafe 只提供三类核心问题。看起来简单，但大多数判断都能由它们组合出来。  ### Choice：从无顺序的封闭选项里选一个 适合意图分类、工具选择、文档类型识别： ```json { "type": "choice", "instructions": "判断用户的主要意图", "criteria": { "policy_query": "查询公司制度或员工政策", "leave_request": "申请请假或查询请假进度", "expense": "报销、发票或费用问题", "other": "不属于以上类别" } } ``` Choice 会返回被选中的标签、每个标签的概率，以及一份 confidence。选项必须是封闭集合；如果你允许模型自由发明标签，就失去了类型约束。 ### Score：在有顺序的等级上判断程度 适合相关性、风险级别、复杂度和严重性： ```json { "type": "score", "instructions": "候选段落对回答用户问题的帮助程度", "criteria": [ "无关", "主题相关，但没有答案证据", "包含间接证据", "直接给出答案" ] } ``` Score 的等级不是随手写的 1～5 分。每一级都要描述清楚业务语义，否则“3 分”和“4 分”对模型与人都没有稳定含义。 ### Noul：一个命题为真的概率 适合真假判断和排序打分： ```json { "type": "noul", "instructions": "该候选段落是否包含回答用户问题所需的直接证据？" } ``` 返回 `0.86`，表示模型对“是”的估计概率为 0.86。它不是一句硬编码的 Yes，也不是 86% 的程度。 这里最容易误解的是 0.5。Noul 的 0.5 表示真假难分，**不是中等相关、中等严重或完成了一半**。如果问题本身有程度，应改用 Score。 ### 一个实用选择法 | 你真正想问的 | 适合的原语 | | --- | --- | | “属于哪一类？” | Choice | | “程度有多高？” | Score | | “这个命题成立吗？” | Noul | | “哪个候选更值得排前面？” | 常用 Noul 或 Score 产生可比较分数 | --- ## 四、概率和置信度不是一回事 假设一个意图分类返回： ```text policy_query 0.46 leave_request 0.44 expense 0.06 other 0.04 ``` 最高概率是 `policy_query`，但它只比 `leave_request` 高一点。程序可以知道“模型选了什么”，也应该知道“这次选择是否足够稳定”。 再看另一份结果： ```text policy_query 0.92 leave_request 0.04 expense 0.03 other 0.01 ``` 两次都选择 `policy_query`，但第二次显然更适合自动执行。  可以把两者粗略记成： - **概率分布**：各个答案分别有多可能； - **置信度**：当前分布是否足够集中，是否值得据此行动。 Noul 只有一个真假概率，不再额外返回 confidence。越靠近 0 或 1，判断越明确；越靠近 0.5，越不确定。 但要注意：校准概率不是单条结果的“正确率凭证”。0.8 的含义需要放到一批相似样本中理解：理想情况下，这类 0.8 左右的判断长期约有八成成立。它不保证眼前这一条一定正确。 工程上真正有用的不是展示一个小数，而是据此设计三条路： ```python if confidence >= 0.80: auto_execute() elif confidence >= 0.55: use_safer_fallback() else: send_to_human_review() ``` 这里的 0.80 和 0.55 只是示意。退款、医疗、合规等高风险动作，阈值应更严格；文章推荐、标签补全等可逆动作，可以宽松一些。 --- ## 五、一次问多个问题：别把每个判断都做成一次往返 TypeSafe 支持在同一份 State 上同时提多个问题。比如一条客服消息，可以一次判断： - 意图是什么； - 复杂度多高； - 是否表达强烈不满； - 是否要求退款； - 是否包含可复现步骤。  有些问题最后用不上也没关系。若意图不是故障报告，代码忽略“是否有复现步骤”的答案即可。官方把这个模式叫 speculative fan-out。 它能省下重复发送长文档的成本。TypeSafe 的并行问题 cookbook 用一篇约 5.4 万字符的 GDPR 文章测试 13 个问题：在那组固定实验中，一次批量请求比 13 次串行单题请求便宜 12.2 倍、快 10.0 倍，答案没有因批处理发生系统性变化。 这不是“所有项目都提速 10 倍”。单题请求如果并发发送，速度差距会缩小；但长状态被重复传输的成本仍然存在。更稳妥的结论是：**同一份上下文上的独立判断，优先合并成一次请求。** --- ## 六、放回 RAG：BM25、向量、RRF、reranker 各做什么 讨论 TypeSafe 重排序之前，先把检索链路拆开。很多争论来自把召回、融合和重排混成一层。  ### BM25：按词项匹配做检索与排序 BM25 当然是排序算法，同时也经常被我们口头称作“关键词检索”。它根据词频、逆文档频率和文档长度等因素，为查询与文档计算相关性分数。 它擅长精确词、编号、专有名词和错误码。例如查询“劳动合同法第三十七条”，BM25 往往很有效。 ### 向量检索：按语义接近程度召回 Embedding 把查询和段落映射到向量空间，再按余弦相似度等指标找近邻。它更容易找出不同措辞表达的同一件事，例如“离职要提前多久”和“解除劳动合同的通知期”。  ### RRF：融合多路排名 RRF（Reciprocal Rank Fusion）不理解文本语义。它只看一个候选在各路结果中的名次，再用一个简单公式合并： ```text RRF(d) = Σ 1 / (k + rank_i(d)) ``` 它的优点是稳定、便宜、不需要把不同检索器的原始分数硬归一化。BM25 排第 2、向量检索排第 4 的文档，通常会比只在一路中偶然靠前的文档更稳。 ### 语义 reranker：重新判断候选与问题是否真的匹配 重排序器会读取查询与候选文本，给候选重新打分。传统方案常见 cross-encoder 或厂商自带的 rerank 模型；也有人让通用 LLM 打分。 TypeSafe 可以出现在这一层：把业务判断写成 Noul 或 Score，对每个候选产生可比较的概率/分数，再排序。  因此，RRF 和 TypeSafe 不是二选一。一个常见链路是： ```text BM25 召回 ─┐ ├─ RRF 融合 → Top 50 → TypeSafe/专用 reranker → Top 8 → LLM 向量召回 ──┘ ``` RRF 先便宜地融合，语义模型只处理较短候选集。若现有向量数据库已经自带 reranker，也不需要为了“用了 TypeSafe”就立刻替换。先在相同数据上比较效果、延迟、成本和可解释性，再决定它是替代、补充，还是只用于高价值请求。 --- ## 七、TypeSafe 重排序：提升的是 Top-K 效果，不是搜索速度 官方重排序 cookbook 做了一个法律检索实验： - 语料：3,565 个法院意见段落； - 查询：40 条； - 第一阶段：BM25 为每个查询召回 30 个候选； - 第二阶段：对 40 × 30 = 1,200 个 query-candidate 对分别询问一个 Noul； - 问题大意：该候选是否可能是查询中被隐去引用所指的判例？ 然后按 Noul 从高到低排序。  在这组实验里，正确段落的位置变化如下： | 指标 | 仅 BM25 快速搜索 | 加 TypeSafe 重排 | | --- | ---: | ---: | | Top-1 | 5% | 18% | | Top-5 | 15% | 35% | | Top-10 | 38% | 62% | 这里文档里的“performance”指的是检索效果：正确答案有没有被推到更靠前的位置，不是接口速度变快。更准确的中文说法是“Top-K 命中表现提高”。 这组数字也不能直接外推到企业知识库。法律判例、产品文档、客服记录的分布不同，问题写法、候选数量和标注标准也不同。它证明的是一种可行路径：**先用快检索保证召回，再用受业务语义约束的判断改善排序。** 还有一条硬边界：如果正确段落没有进入 BM25 的 Top 30，重排序再强也找不回来。所以排查 RAG 问题时，要先区分： - 是召回失败，正确文档根本没进候选集； - 还是排序失败，正确文档进来了但位置太后。 前者应优化切分、索引、查询改写或混合召回；后者才是 reranker 的主战场。 --- ## 八、逐行搜索：把“在哪里”变成 Choice 对一份不太长的文档，如果希望定位到具体行，可以先给每一行加 ID： ```text L001 试用期员工可以解除劳动合同。 L002 应当提前三日书面通知用人单位。 L003 正式员工应提前三十日通知。 ``` 然后同时问两个问题： 1. 用 Choice 在 `L001`、`L002`、`L003` 中选择最相关行； 2. 用 Noul 判断整份文档是否真的包含答案。  为什么还要第二个 Noul？因为 Choice 总要在现有选项中分配概率。即使文档没有答案，它仍会选出“最像”的一行。Noul 则提供独立的存在性判断，避免把“最不差”误当成“确实正确”。 官方示例一次对 GitHub 服务条款中的 218 个行号评分。Choice 目前最多 255 个选项；更长文档需要分区、分层或先粗召回再细定位。 这类方法适合合同条款定位、日志段落定位、短文档取证，不适合直接把几十万行代码一次塞进选项。 --- ## 九、RAG 段落分类：它不是语义分块，而是检索后的安检 这是最容易被误解的一个 cookbook。 语义分块发生在**入库之前**：决定原文从哪里切开，每块多长，标题和上下文如何继承。RAG 段落分类发生在**检索之后**：候选已经被召回，现在要决定它能不能进入回答模型的上下文。  官方示例对每个候选段落同时判断四件事： - `is_relevant`：是否与问题相关； - `contains_answer_evidence`：是否包含回答所需的证据； - `contradicts_query_premise`：是否反驳了问题中的前提； - `contains_prompt_injection`：是否包含试图操纵下游模型的指令。 代码再按明确顺序路由：先处理提示注入，再保留矛盾证据，排除低相关段落，只把有证据的候选送给 LLM。 这和重排序也不同： | 操作 | 目标 | 输出 | | --- | --- | --- | | 重排序 | 谁应该排在前面 | 连续分数与新顺序 | | 段落分类 | 谁可以进入上下文、谁要隔离 | include / exclude / conflict / review |  所以，TypeSafe 可以参与入库前清洗，但 `classifying_rag_passages` 这一模式本身不是清洗和分块。更完整的数据链路可能是： ```text 原始 Markdown → 规则清洗与结构解析 → 语义分块 → 向量化入库 → 混合召回 → 重排序 → TypeSafe 段落分类 → LLM 回答 ``` TypeSafe 适合补上“这段内容在语义上属于什么、是否满足某个判据”；HTML 去标签、重复空白、乱码、表格解析等确定性清洗仍应交给普通代码。 提示注入判断也只是风险信号，不是安全边界。权限隔离、工具白名单、数据域访问控制和输出校验一个都不能少。 --- ## 十、函数调用与技能建议：先判断，再让代码执行 ### 函数调用 假设交易助手支持三个函数： ```python get_price(symbol) buy(symbol, amount) sell(symbol, amount) ``` 可以用 Choice 判断函数名，用其他问题解析封闭参数、判断是否需要确认，然后由代码做校验和真正调用。  这和让生成式 LLM 随意输出一段工具 JSON 的差别在于：函数集合和参数候选是应用明确提供的；低置信度可以直接停下来；副作用始终由代码触发。 当然，开放参数仍需要其他解析手段。金额、邮箱和日期等字段可以先由正则或解析器找候选，再让 TypeSafe 选择正确候选；不要强迫 Choice 从无限空间里生成值。 ### 技能建议 Agent 的技能库越来越大时，把 182 个技能说明全部塞给主模型并不优雅。官方 skill suggestion 示例采用两阶段： 1. 先对技能候选做排名； 2. 再复核头部候选是否真的适合当前请求； 3. 最多建议一个技能，不合适就返回不调用。  它与检索很像：第一阶段追求别漏掉，第二阶段追求别选错。区别只是候选从文档段落变成了工具或技能。 ### 意图路由 不是每条消息都值得调用同一个大模型。一个更经济的入口可以先判断意图和复杂度：  - 查订单状态：直接查数据库； - 产品咨询：交给产品知识库 LLM； - 退款投诉：交给专用流程或人工； - 意图置信度低：不要猜，直接兜底。 这类路由能减少不必要的 LLM 调用，也让每条链路加载更小、更专门的上下文。 --- ## 十一、引用核对、护栏与模型级联 ### 引用核对：不是“找到同一句话”就够了 一条引用可能真实存在，但并不支持前面的结论。例如原文说“在特定条件下可以提前三日”，回答却概括成“任何员工都只需提前三日”。字面能对上，语义却被扩大了。 引用核对应把三样东西放在一起：主张、引用片段、原文上下文，然后判断上下文对主张是支持、部分支持、矛盾还是无关。  这一步适合放在生成之后、展示之前。低置信度或不支持的引用可以触发重新检索、删除该句或人工复核。 ### LLM 护栏：同时检查输入和输出 护栏不是在 prompt 末尾写一句“请遵守规则”。它应该是独立的检查与路由层：  ```text 用户输入 → 风险判断 → LLM → 输出风险判断 → 展示 ↓ ↓ 拦截/复核 改写/拦截/复核 ``` 风险类别、严重性和概率可以同时判断，代码决定通过、阻断或转人工。对于高风险行业，还应保留日志、版本和命中原因，便于审计。 ### 模型级联：便宜模型先做，TypeSafe 验证，难例再升级 结构化抽取常见一种浪费：无论输入简单还是困难，都调用最贵的推理模型。 更合理的级联是： 1. 小模型先抽取； 2. TypeSafe 对关键字段逐一判断是否与原文一致； 3. 全部通过就接受； 4. 某个字段风险过高，再升级到强模型或人工。  这里 TypeSafe 不是第二个生成器，而是验证器。字段级问题比一句“这个 JSON 对不对”更容易定位错误：姓名是否对应申请人、金额是否是总额、日期是否是生效日、单位是否匹配。 官方 SDE cascade 的图表来自 100 个 prompt 的内部历史实验，适合说明模式，不适合拿来承诺所有企业都能节省同样比例。 --- ## 十二、结构恢复、候选抽取与实体对齐 ### 结构恢复：把丢失格式的纯文本重新变成 Markdown PDF 或复制粘贴后的文本经常只剩下一堆硬换行。TypeSafe 的 autoformat cookbook 分两遍处理： 1. 对相邻行逐对判断：这个换行是否把一个句子错误拆开； 2. 合并后，对每个块判断它是标题、段落、列表、引用、代码还是 callout； 3. 代码根据类型重新渲染 Markdown。  为什么需要两次请求？因为第二遍的“块”要等第一遍合并后才知道。能并行的问题应批量，存在数据依赖的步骤则必须串行。 这类能力可以用于入库前整理，但最好保留原文并记录变换。对法律合同、财务凭证等材料，不应让语义修复悄悄改掉源词。 ### 候选值抽取：代码负责找，模型负责选 要从一封邮件里取出“收款邮箱”，更稳的流程不是让模型重新写一个邮箱： 1. 正则尽量多找出所有邮箱； 2. TypeSafe 从候选中选择哪个是收款邮箱； 3. 代码原样复制并规范化； 4. 候选里没有合适值时，允许选择 `none`。  这样可以避免一个字符被模型重写。电话、金额、订单号也适合这套办法；人名等难以用正则枚举的字段，需要先用 NER 或其他召回手段提供候选。 ### 实体对齐：先缩小候选对，再判断是不是同一个实体 知识图谱合并时，经常遇到： ```text 青岛啤酒 500ml 罐装 Tsingtao Beer Can 0.5L ``` 字符串不一样，但可能是同一商品。做法通常是： 1. 规则、倒排或向量先生成候选对； 2. TypeSafe 判断整体是否匹配； 3. 同时检查品牌、规格、产地等字段是否冲突； 4. 代码按阈值自动合并或转人工。  别让模型在整个数据库里两两比较。语义判断应该放在候选生成之后，否则组合数量会迅速爆炸。 --- ## 十三、企业落地时，TypeSafe 应该放在哪一层 一个比较现实的企业架构如下：  ```text 数据侧： 文档 → 规则清洗 → 结构恢复/语义标注 → 分块 → 索引 查询侧： 用户请求 → 意图路由 → BM25 + 向量召回 → RRF → 重排 → 段落分类/风险过滤 → LLM 生成 → 引用与输出核对 控制侧： 阈值、权限、审计、回退、人工复核、业务副作用全部由代码负责 ``` 这里的 TypeSafe 不是单独一条固定流水线，而是一组可以插入不同节点的判断原语： - 入库前：结构类型识别、实体对齐、候选值选择； - 检索中：语义重排、逐行定位； - 生成前：段落分类、矛盾识别、提示注入信号； - Agent 中：意图路由、工具选择、技能建议； - 生成后：引用核对、风险检查、级联验证。 如果企业已经使用 VikingDB、Elasticsearch、OpenSearch 或其他向量数据库，通常不需要改掉召回层。先把 TypeSafe 放到一个边界清楚、容易离线评测的节点，例如 Top 30 重排或检索后段落过滤。 至于它和某个商用 reranker 谁更强，公开资料里没有同数据集、同候选集、同预算条件下的可靠头对头结论。正确做法不是凭产品介绍站队，而是做 shadow test：同一批真实查询同时走旧链路和新链路，不影响线上结果，积累标注后再比较。 --- ## 十四、别只问“准不准”：评估至少看六类指标 一个判断模型上线前，我会把评估表拆成六组。  ### 1. 任务效果 - 分类：Accuracy、Macro-F1、混淆矩阵； - 排序：Recall@K、MRR、nDCG； - 护栏：危险内容漏放率与正常内容误杀率； - 抽取：字段级精确率、召回率和完全匹配率。 ### 2. 概率是否可信 不要只看最终标签。把 0.6～0.7、0.7～0.8 等概率区间分别统计实际正确率，看概率是否校准。阈值要从业务验证集上定，不要照抄 cookbook。 ### 3. 自动化覆盖率 高阈值会更稳，但更多样本进入人工。需要同时看： - 自动通过比例； - 自动拦截比例； - 人工复核比例； - 复核队列的真实错误密度。 ### 4. 风险成本 错放一条高危内容与错拦一条普通内容，代价不一样。阈值和损失函数应体现这种不对称。 ### 5. 延迟与吞吐 至少记录 P50、P95、P99，而不只看平均值。还要测候选数从 10 增加到 50 后，整条链路的变化。 ### 6. 成本与版本稳定性 记录每千次请求成本、平均输入长度、问题数量和升级模型后的指标漂移。TypeSafe 提供 `jev-latest` 这类移动别名，但生产阈值调好后，更稳的做法是固定具体版本，升级时重新跑评测。 中文场景尤其要单独验证。官方说明英语是主要训练语言，CJK 可以处理但不保证同等表现。不要用英文 demo 的结果替代中文合同、客服或制度文档上的实测。 --- ## 十五、哪些情况不该用 TypeSafe TypeSafe 有明确的适用边界。 ### 规则能写清楚时，直接写代码 判断订单金额是否大于 1,000、JWT 是否过期、字段是否为空，这些都不需要模型。确定性规则更快、更便宜，也更容易审计。 ### 任务需要生成或复杂推理时，用生成式 LLM 写邮件、总结长报告、生成代码、制定多步方案，TypeSafe 不负责这类开放生成。可以让 TypeSafe 做前后路由与核对，但中间仍需要 LLM。 ### 没有候选、选项无限时，先做召回 Choice 适合封闭集合。面对整个商品库、所有函数或所有实体，不应直接把问题扔给它；先用索引、规则或向量检索缩小范围。 ### 单次高风险决定不能只信一个概率 医疗、法律、信贷和资金操作要叠加规则、权限、人工复核与审计。概率只是决策信号，不是责任转移工具。 ### 需要处理原始图片、音频、视频时，先做多模态解析 Jev 当前以文本状态为主。OCR、ASR、视觉理解等工作需要由上游模型完成，再把结构化文本送来判断。  --- ## 十六、一个可落地的起步方案 如果团队已经有 RAG，不建议第一天就改造整条链路。可以从一个容易验证的小节点开始。 以“检索后段落分类”为例： 1. 从真实日志抽取 300～1,000 个查询及候选段落； 2. 由业务人员标注相关、含证据、矛盾、风险四个维度； 3. 用 TypeSafe 一次询问四个窄问题； 4. 先离线比较现有规则、商用 reranker 与 TypeSafe； 5. 根据误放和误杀成本选择阈值； 6. 线上 shadow 运行，不改变用户结果； 7. 指标稳定后，只放开低风险、高置信度流量； 8. 固定模型版本，保留请求、答案、阈值和最终动作日志。 最小 Python 形态可以像这样： ```python import os from typesafe_sdk import Noul, TypeSafeClient client = TypeSafeClient(api_key=os.environ["TYPESAFE_API_KEY"]) response = client.system_one( model="jev-1.13.0", state={ "query": query, "passage": passage, }, questions={ "relevant": Noul( instructions="该段落是否与用户问题直接相关？" ), "has_evidence": Noul( instructions="该段落是否包含回答问题所需的明确证据？" ), "contradicts": Noul( instructions="该段落是否否定了问题中的关键前提？" ), "prompt_injection": Noul( instructions="该段落是否包含要求下游模型忽略规则或执行指令的内容？" ), }, ) a = response.answers if a["prompt_injection"].noul >= INJECTION_BLOCK: route = "quarantine" elif a["contradicts"].noul >= CONTRADICTION_KEEP: route = "conflicting_evidence" elif a["relevant"].noul < RELEVANCE_MIN: route = "exclude" elif a["has_evidence"].noul >= EVIDENCE_MIN: route = "include" else: route = "exclude" ``` 四个阈值故意没有给数值，因为它们应该来自你自己的验证集，而不是复制网上示例。 --- ## 结语：把模型当判断组件，而不是第二套业务系统 TypeSafe 最值得学习的地方，不是某个重排序数字，而是一种架构习惯： > 把复杂的 AI 行为拆成窄而可测的判断，让模型给出结构化信号，让代码继续掌握流程。 BM25、向量检索和 RRF 负责从大范围里快速找候选；TypeSafe 或其他语义 reranker 负责更细的判断；生成式 LLM 负责真正需要表达与推理的部分；规则、权限和人工负责兜底。 当这些角色分清之后，TypeSafe 的场景就不止“重排序”。逐行定位、RAG 段落安检、函数选择、技能建议、实体对齐、引用核对、LLM 护栏和模型级联，本质上都在复用同一件事：**把自然语言中的常识判断，变成程序可以组合、评测和路由的概率信号。** 它不会让所有 AI 应用自动变快、变准，也不会替代整条技术栈。但在“规则写不完、生成又太重”的中间地带，这种受约束的判断层很有价值。 --- ## 参考资料 - [TypeSafe 官方文档](https://docs.typesafe.ai/) > 本文中的 Top-K、成本与耗时数字均来自 TypeSafe 官方 cookbook 的特定实验，不代表任何数据集上的固定收益。上线前请使用自己的中文语料、风险标准和线上分布重新评测。

AI 桌面换装视频火了，1 分钟教你复刻！傻子可懂

大家好，我是程序员鱼皮。 最近 AI 桌面换装视频突然爆火，Twitter 上随便一条就是百万播放。  视频里一个虚拟美女坐在电脑桌面上，你让她换什么衣服她就换什么衣服，还能对话。  果然，歰歰是第一生产力啊！ 为了锻炼自己的 AI 视频制作技术，而不是出于兴趣，我也搞了一条试试。  怎么样，是不是精准复刻了原版的风格？ 三套造型切换，有对白声音、有特效字幕，全程模拟电脑桌面录屏的风格，30 秒一镜到底。  这是怎么做到的呢？ 其实非常简单！ 给我 1 分钟的时间，我来教你如何复刻，保证一学就会。 ## 1、准备工作 首先，我用到的是知名傻狗 `程序员鱼皮` 开源的「AI 桌面换装视频」生成技能。 > 开源指路：https://github.com/liyupi/ai-desktop-outfit-video  这个技能的玩法很简单。你跟 AI 说一句话描述需求，AI 就会帮你自动生成一段完整的 AI 视频生成提示词。然后复制到任意 AI 视频工具里就能出片，不用自己写又臭又长的提示词。 ## 2、让 AI 帮你写提示词 演示一下，随便打开一个 AI 工具（比如 Cursor），使用技能，然后跟 AI 说： ```markdown 我想创作 30 秒的视频 ``` AI 就会像产品经理一样主动询问你的需求：  AI 会先问你主角是谁。默认是中国古典鹅蛋脸美人，你如果有自己喜欢的角色，可以直接描述，也可以上传一张参考图。 比如我先用 ChatGPT 生成了一张参考图，并提供给 AI：  然后 AI 会问你视频的场景。默认是深蓝灰色调的房间，我跟 AI 说把场景改成安静的小酒吧。  接着 AI 会问三套换装造型是什么。我就随便说了水手服、洛丽塔、白领制服，跟个人爱好完全无关：  然后 AI 还会问你视频里的台词。如果你不喜欢默认的台词，可以让 AI 帮你修改为适配你需求的文案。  最后 AI 会问你尺度档位，软、中、硬三档可选。 我知道你们想选什么，唉……  六个问题问完，AI 就直接输出了一段完整的提示词。在这个技能的开源项目中有完整版的参考提示词。 ## 3、复制提示词，生成视频 接下来只需要把这段提示词复制出来，丢到任意一个 AI 视频生成工具里就行了。即梦、豆包、MiniMax 等等都可以，只要支持 Seedance 模型或者同级别的视频模型就行。 生成之前，有几个注意事项： 1. 比例选 16:9，因为是模拟电脑桌面 2. 时长选 30 秒（Seedance 2.5 支持 30 秒） 3. 使用默认的全能参考模式就好，不要开任何运镜预设 建议先用 720p 来试，1080p 的积分消耗真的太贵了！等效果满意了再上高清。  然后等 AI 生成完，一段桌面换装大作就出来了。   ## 4、直接调 API 生成 除了手动复制提示词之外，这个技能还支持直接调用 Seedance 2.5 的 API 来生成视频。 > 当然，你换成其他 AI 视频生成模型的 API 也是 OK 的。  只需要去火山引擎官网获取一个 API Key，提供给 AI 就行了。  AI 会直接帮你调用 API 生成视频并下载到本地，全程不用你自己打开任何 AI 视频生成工具。  生成的效果也是非常理想的。但是由于生成的视频过于劲爆，这里就不给大家完整播放了。  怎么样，是不是很简单？ 有了这个技能，你可以自定义女主 / 男主，自定义场景、台词、造型。一个爆款视频就这样被轻轻松松复刻出来了！ ## 5、核心原理 那问题来了，这个技能是怎么做出来的呢？ 其实也很简单。 我直接找到爆火的原版视频，丢给 AI，让它帮我逐帧分析视频的画面和声音，并生成简单直接的提示词。  注意，这段提示词中，我用到了 `/grill-me` 技能，AI 如果没充分理解需求，就会主动找我人工确认。 看看，这是 AI 逐帧分析的画面：  AI 帮我拆出来了整条视频最核心的「机关」。比如镜头全程一动不动，人物站起来的时候镜头不跟，只拍到腰部以下，看起来就像真的是电脑桌面壁纸。还有每次换装前都要留一秒钟的空沙发镜头，避免衣服在身上直接变形。  AI 拆解明白之后，帮我生成了一段简洁的提示词模板：  然后我直接把提示词拿到即梦里测试。结果非常顺利，一把就出了满意的效果。  测试没问题之后，我就让 AI 把整个工作流封装成了一个可复用的 Skill 技能。AI 从提问流程、提示词模板到 API 调用脚本，全部自动生成好了。  最后我直接让 AI 帮我把这个技能开源到 GitHub 上，并且自动生成了一个有图有文、甚至有 GIF 动图演示的项目 README 文件。真的爽！  这也是得益于现在的 AI 模型 Agent 能力和视觉理解能力越来越强了。整个过程从拆片、写提示词、测试、封装技能到开源发布，全程几乎都是 AI 在干活，我只需要做决策和验收。 ## 最后哔哔 看到这儿你应该能 get 到本期精髓了。下次你在网上看到某个爆款视频，完全可以用同样的方法让 AI 帮你逐帧拆解、生成提示词、封装成可复用的技能。不光是换装，AI 互动壁纸、桌面宠物、动态直播间背景，都是一个思路。 这篇文章我也会收录到我的开源教程 [《AI 编程零基础入门教程》](https://ai.codefather.cn/vibe) 中。上千张图、几十万字，从 0 开始带你学会 AI 编程，做出自己的产品、跑通变现全流程，感兴趣的同学可以看看。 > 开源指路：[https://github.com/liyupi/ai-guide](https://github.com/liyupi/ai-guide)  我是鱼皮，持续分享 AI 编程干货。觉得有用的话记得点赞收藏和关注~

DeepSeek V4 Flash vs GLM-5.3 深度对比报告

# DeepSeek V4 Flash vs GLM-5.3 深度对比报告 > **报告日期**：2026年9月24日 > **数据来源**：官方公告、Artificial Analysis、OpenRouter、第三方实测（详见文末参考来源） > **免责声明**：AI 模型迭代极快，本报告数据截至 2026 年 9 月 24 日，后续版本更新可能导致数据变化 --- ## 目录 - [一、模型概览](#一模型概览) - [二、架构与参数对比](#二架构与参数对比) - [三、上下文与多模态能力](#三上下文与多模态能力) - [四、智能水平与基准测试](#四智能水平与基准测试) - [五、API 定价对比](#五api-定价对比) - [六、推理速度对比](#六推理速度对比) - [七、开源与生态](#七开源与生态) - [八、实测对比案例](#八实测对比案例) - [九、选型建议](#九选型建议) - [十、总结对比表](#十总结对比表) - [参考来源](#参考来源) --- ## 一、模型概览 ### DeepSeek V4 Flash 系列 DeepSeek V4 Flash 是杭州深度求索（DeepSeek）推出的 MoE 架构大语言模型，定位为**高性能低成本**的"Flash"档位。目前已经历两代迭代： | 版本 | 发布日期 | 定位 | 状态 | |------|----------|------|------| | DeepSeek-V4-Flash-preview | 2026年4月 | V4 系列轻量版 | 已下线 | | DeepSeek-V4-Flash-0731 | 2026年7月31日 | V4-Flash 正式版 | 旧模型名已下线，路由至 V4.1 Flash | | **DeepSeek-V4.1-Flash** | **2026年9月10日** | **全新架构系列最小尺寸模型** | **当前主力** | > **注**：V4 Pro 已于 2026年9月14日停止独立服务，请求路由至 V4.1 Flash。V4.1 Flash 在性能、费用、速度、总用时等各项指标上**全面超越 V4 Pro**。 ### GLM-5.3 Flash 系列 GLM-5.3 Flash 是北京智谱华章（智谱 AI）推出的 GLM-5 系列首个**原生多模态**模型，以"1/40 的价格打平 Claude Opus 4.8"引爆市场： | 版本 | 发布日期 | 定位 | 状态 | |------|----------|------|------| | **GLM-5.3-Flash (320B-A18B)** | **2026年8月26日** | **GLM-5 系列首个原生多模态模型** | **当前主力** | | GLM-5.3-FlashX | 2026年9月18日 | Flash 极速版，推理提速5倍 | 已上线 | > **注**：GLM-5.3-Flash 此前以匿名模型 "Ox-Alpha"（中文社区称"牛来"）在 OpenCode 和 OpenRouter 上盲测，曝光后引发广泛关注。 --- ## 二、架构与参数对比 | 维度 | DeepSeek V4.1 Flash | GLM-5.3-Flash | |------|-------------------|---------------| | **总参数量** | 552B | 320B | | **激活参数** | 输入 8B / 输出 16B（非对称） | 18B | | **架构类型** | MoE（混合专家） | MoE（混合专家） | | **核心架构创新** | Causal-Encoder-Decoder（CED）非对称结构 | GLM-5 标准MoE，45层 | | **注意力机制** | CSA（压缩稀疏注意力）+ HCA（重度压缩注意力）混合 | — | | **KV Cache 压缩** | 压缩至上一代 1/4；HBM 需求降至 1/4，SSD 降至 1/8 | — | | **思考模式** | 支持思考/非思考模式（默认非思考） | — | | **算力底座** | 华为昇腾 + 英伟达混合 | 10万张国产 AI 芯片集群 | ### 架构亮点解读 **DeepSeek V4.1 Flash 的非对称设计**是其成本优势的根源： - 输入侧每 token 仅激活 8B（预填充阶段），输出侧激活 16B（解码阶段） - 这种"输入重、输出轻"的设计**天然适配 Agent 场景**——Agent 每次调用需重发大量 system prompt + 历史对话（输入量大），但输出相对简短 - KV Cache 相对初代模型已缩小 **437 倍**，同等显存可装更长的上下文 **GLM-5.3-Flash** 采用 320B/18B 的 MoE 架构，激活比例约 5.6%，在参数效率和智能密度上表现优异。45层结构设计在编程和推理任务中展现出强竞争力。全部推理跑在 10万张国产芯片上，是**纯国产算力**的标杆案例。 --- ## 三、上下文与多模态能力 | 维度 | DeepSeek V4.1 Flash | GLM-5.3-Flash | |------|-------------------|---------------| | **上下文窗口** | 1M token | 100万 token（1M） | | **最大输出** | 384K token | — | | **原生多模态** | 是（视觉理解） | 是（文本/图像/视频/文件） | | **多模态深度** | 原生视觉理解，三种模式合一（自动检测） | GLM-5 系列首个原生多模态，文本+图像+视频一体化输入 | | **输出格式** | 文本、代码 | 文本、代码、Office 成品文档 | ### 多模态对比解读 - **DeepSeek**：2026年4月发布 V4-Flash-Vision-Exp 实验版，9月将快速/专家/识图三模式合一为"智能模式"，模型可自动检测查询复杂度、图片输入并调整处理能力，用户无需手动切换 - **GLM-5.3-Flash**：原生支持文本、图像、视频和文件等多种输入格式，不仅能输出代码，还能输出 Office 成品文档，在文档处理场景具有独特优势 --- ## 四、智能水平与基准测试 ### 4.1 Artificial Analysis 综合智能指数 | 模型 | AA Intelligence Index | 对标 | |------|----------------------|------| | **GLM-5.3-Flash** | **57分** | 与 Claude Opus 4.8 持平 | | DeepSeek V4.1 Flash | 约40分（第三方评测） | — | | Claude Opus 4.8 | 57分 | 前沿标杆 | | Kimi K3 | 约44分 | — | > **注**：AA 指数版本不同时期可能有更新。GLM-5.3-Flash 的 57 分为官方发布时数据，第三方后续评测中 DeepSeek V4.1 Flash 约为 40 分、GLM-5.3 约 45 分，差异可能源于评测版本和时间的不同。 ### 4.2 SuperCLUE-Terminal 智能体终端编程测评 | 模型 | 得分 | 成本/题 | 备注 | |------|------|---------|------| | GLM-5.3 (max) | 56.57分 | — | 榜单第二 | | GLM-5.3-Flash (max) | 48.48分 | 2.05元 | 并列第五，成本较 GLM-5.2 降 91.20% | | Qwen3.8-Flash (xhigh) | 48.48分 | 0.9元 | 并列第五 | ### 4.3 DeepSeek 官方 Agent 基准评测 DeepSeek 官方 9 项 Agent 基准评测中，V4.1 Flash **全面超越** V4-Flash-0731 正式版，并在多项指标上超越旗舰级 V4 Pro。 ### 4.4 智能水平总结 - **GLM-5.3-Flash** 在综合智能指数上领先，以 57 分追平 Claude Opus 4.8，是国产模型中智能水平最高的 Flash 档模型之一 - **DeepSeek V4.1 Flash** 智能指数虽略低，但凭借极低的成本在"性价比"维度形成差异化竞争力 - 在分类任务等特定场景实测中，GLM-5.3-Flash 准确率更高（见第八节实测案例） --- ## 五、API 定价对比 ### 5.1 DeepSeek V4.1 Flash 定价 > 采用**峰谷定价**机制，高峰时段价格为空闲时段的 2 倍 | 计费项 | 高峰时段（元/百万token） | 空闲时段（元/百万token） | |--------|----------------------|----------------------| | 输入（缓存未命中） | 2 | 1 | | 输入（缓存命中） | 0.04 | 0.02 | | 输出 | 8 | 4 | - **高峰时段**：周一至周五 9:00-12:00、14:00-18:00（北京时间） - **空闲时段**：其他所有时段（含周末全天） - **缓存折扣**：缓存命中比未命中便宜 **50 倍** - **缓存机制**：硬盘缓存（非内存），默认自动开启，无需修改代码 ### 5.2 GLM-5.3-Flash 定价 | 计费项 | 国际版（美元/百万token） | 约合人民币（元/百万token） | |--------|----------------------|----------------------| | 输入 | $0.15 | ≈1.08 | | 输出 | $0.50 | ≈3.60 | | 缓存命中 | $0.026 | ≈0.19 | **限时折扣**（曾推出）： - 输入：$0.075/百万 token（约0.54元） - 输出：$0.25/百万 token（约1.80元） ### 5.3 GLM-5.3-FlashX 定价（极速版） | 计费项 | 定价（元/百万token） | 备注 | |--------|-------------------|------| | 输入 | 2 | Flash 原版的 2.5 倍 | | 输出 | 7 | Flash 原版的 2.5 倍 | ### 5.4 定价对比分析 | 对比维度 | DeepSeek V4.1 Flash | GLM-5.3-Flash | GLM-5.3-FlashX | |---------|-------------------|---------------|----------------| | 输入（标准） | 2元（高峰）/ 1元（空闲） | ≈1.08元 | 2元 | | 输出（标准） | 8元（高峰）/ 4元（空闲） | ≈3.60元 | 7元 | | 缓存命中输入 | 0.04元（高峰）/ 0.02元（空闲） | ≈0.19元 | — | | 缓存折扣倍数 | 50倍 | 约5.7倍 | — | | 峰谷定价 | 有（2倍差距） | 无 | 无 | | 缓存类型 | 硬盘缓存（持久） | 内存缓存（TTL短） | 同 Flash | **关键发现**： - **DeepSeek 在缓存命中场景下成本极低**（0.02-0.04元/百万token），50倍折扣远超行业水平 - **GLM-5.3-Flash 标准定价更低**（输入约1元 vs 2元，输出约3.6元 vs 8元），但缓存折扣不如 DeepSeek 激进 - DeepSeek 的**峰谷定价**为成本优化提供了额外维度——将批量任务排到非高峰时段可再省一半 - GLM-5.3-FlashX 虽然提速5倍，但定价涨至2.5倍，性价比需根据场景权衡 --- ## 六、推理速度对比 | 维度 | DeepSeek V4.1 Flash | GLM-5.3-Flash | GLM-5.3-FlashX | |------|-------------------|---------------|----------------| | **峰值输出速度** | 197 tokens/s | ≈40 tokens/s | **200 tokens/s** | | **速度提升** | 较 V4 Pro 显著提升 | 基础版 | 较 Flash 提升 **5倍** | | **流式输出** | 流畅 | 基础版流畅 | 更连贯，长文本体验佳 | > DeepSeek V4.1 Flash 输出速度约 197 token/s，在开源模型中属于第一梯队。GLM-5.3-Flash 基础版速度约 40 token/s，FlashX 版本通过底层架构优化和 10万张国产芯片集群支撑，将速度提升至 200 token/s，与 DeepSeek 持平。 --- ## 七、开源与生态 | 维度 | DeepSeek V4.1 Flash | GLM-5.3-Flash | |------|-------------------|---------------| | **开源协议** | MIT | MIT | | **开源平台** | Hugging Face + 技术报告 | Hugging Face + 技术报告 | | **API 兼容** | OpenAI 格式 + Anthropic 格式 | OpenAI 格式 | | **部署需求** | 支持 2k 卡 GPU 大规模部署 | 8卡 H20 可跑通 512K 上下文 | | **合作伙伴生态** | WorkBuddy/CodeBuddy、OpenCode、七牛云、国家超算互联网、硅基流动等 | BigModel 平台、WorkBuddy、Cline、ZCode 等 | | **OpenRouter 调用量** | 上线三天杀进全球前六 | 曾登榜，后因竞争激烈有波动 | | **社区活跃度** | 极高（开源社区标杆） | 高（"牛来"事件出圈） | ### 生态亮点 - **DeepSeek**：API 兼容 OpenAI 和 Anthropic 双格式，迁移成本极低。硬盘缓存机制对 Agent 开发者特别友好——历史对话可长期存储在硬盘，多轮对话边际成本极低 - **GLM-5.3-Flash**：原生多模态能力（文本+图像+视频+文件）在文档处理场景独树一帜，能直接输出 Office 成品文档。Coding Plan 套餐提供夜间免费额度等灵活计费方案 --- ## 八、实测对比案例 ### 8.1 灵犀实测：13款模型智力大考 | 模型 | 任务结果 | 耗时 | 消耗灵点 | |------|---------|------|---------| | **GLM-5.3-Flash** | **原文件自动备份（满分夺冠）** | 2分22秒 | **4灵点** | | DeepSeek V4 Flash | 原文件自动备份 | 2分30秒 | 10灵点 | | DeepSeek V4 Pro | 原文件自动备份 | 8分15秒 | 82灵点 | > GLM-5.3-Flash 以最少消耗（4灵点）完成任务并夺冠，DeepSeek V4 Flash 紧随其后但消耗略高。 ### 8.2 四个 Flash 模型分类任务实测 > 任务：判断一条内容是否与 AI 相关（简单分类任务） | 模型 | 准确率 | 速度 | 成本 | |------|--------|------|------| | **GLM 5.3 Flash** | **100%（唯一全对）** | 最慢 | 最贵 | | DeepSeek V4.1 Flash | 部分 | 快 | 便宜 | | Qwen 3.7 Flash | 部分 | — | — | | Jev | 部分 | — | — | > 结论："准确率最高的那个，恰恰是最慢也最贵的"——GLM-5.3-Flash 在精度上领先，但速度和成本有代价。 ### 8.3 第三方标准任务成本实测 | 模型 | 单任务平均成本 | |------|--------------| | **DeepSeek V4.1 Flash** | **≈0.27美元** | | GLM-5.3 | ≈2美元 | | Kimi K3 | ≈2美元 | > DeepSeek V4.1 Flash 的单任务成本约为 GLM-5.3 的 **1/7**，极致性价比优势明显。 ### 8.4 AA 智能指数 vs 成本象限 根据 Artificial Analysis 数据，GLM-5.3-Flash 处于"**高智能-低成本**"的 Pareto 前沿——以 Claude Opus 4.8 四十分之一的价格达到同等智能水平。DeepSeek V4.1 Flash 则在"**低成本-高速度**"象限领先，走量策略明显。 --- ## 九、选型建议 ### 9.1 选 DeepSeek V4.1 Flash 的场景 | 场景 | 理由 | |------|------| | **多轮对话 Agent** | 硬盘缓存 + 50倍缓存折扣，多轮对话边际成本极低 | | **大规模批量处理** | 峰谷定价可将任务排到空闲时段，成本再降一半 | | **长上下文推理** | 1M token 上下文 + 384K 输出 + KV Cache 压缩 | | **成本敏感型应用** | 单任务成本约为 GLM 的 1/7，极致走量 | | **OpenAI/Anthropic API 迁移** | 双格式兼容，迁移成本为零 | | **可异步执行的任务** | 非高峰时段批量执行，成本最优 | ### 9.2 选 GLM-5.3-Flash 的场景 | 场景 | 理由 | |------|------| | **高精度要求** | AA 指数 57 分追平 Claude Opus 4.8，分类/推理任务准确率更高 | | **多模态文档处理** | 原生支持文本+图像+视频+文件，可输出 Office 文档 | | **编程/代码生成** | SuperCLUE-Terminal 48.48 分，Coding Plan 套餐灵活 | | **国产算力合规要求** | 100% 国产芯片推理，满足信创/自主可控要求 | | **与 Claude 对标替代** | 1/40 价格达到同等智能水平，替代性价比极高 | | **需要极速版** | FlashX 200 token/s 满足实时交互需求 | ### 9.3 综合决策矩阵 | 决策维度 | 推荐 | |---------|------| | 成本最低 | DeepSeek V4.1 Flash（缓存命中 0.02元/百万token） | | 智能最高 | GLM-5.3-Flash（AA 指数 57 分） | | 速度最快 | GLM-5.3-FlashX（200 token/s）≈ DeepSeek V4.1 Flash（197 token/s） | | 多模态最强 | GLM-5.3-Flash（文本+图像+视频+文件） | | Agent 开发最友好 | DeepSeek V4.1 Flash（硬盘缓存+峰谷定价+双API格式） | | 国产合规 | GLM-5.3-Flash（100% 国产芯片） | | 开源生态 | 两者均 MIT 开源，DeepSeek 社区更活跃 | --- ## 十、总结对比表 | 维度 | DeepSeek V4.1 Flash | GLM-5.3-Flash | |------|-------------------|---------------| | 发布日期 | 2026-09-10 | 2026-08-26 | | 总参数 | 552B | 320B | | 激活参数 | 8B/16B（非对称） | 18B | | 架构 | MoE + CED 非对称 | MoE | | 上下文 | 1M token | 1M token | | 最大输出 | 384K | — | | 多模态 | 视觉理解 | 文本+图像+视频+文件 | | AA 智能指数 | ~40 | **57** | | 输入价格（标准） | 2元（高峰）/ 1元（空闲） | ≈1.08元 | | 输出价格（标准） | 8元（高峰）/ 4元（空闲） | ≈3.60元 | | 缓存命中输入 | **0.04元（高峰）/ 0.02元（空闲）** | ≈0.19元 | | 缓存折扣 | **50倍** | ~5.7倍 | | 峰谷定价 | 有 | 无 | | 输出速度 | 197 token/s | ~40 token/s（FlashX: 200） | | 开源 | MIT | MIT | | 算力底座 | 昇腾+英伟达 | 100% 国产芯片 | | API 兼容 | OpenAI + Anthropic | OpenAI | | 核心优势 | **极致性价比 + Agent 友好** | **高智能 + 多模态 + 国产合规** | --- ## 参考来源 1. DeepSeek V4.1 Flash 发布公告（2026-09-10，深度求索官网） 2. DeepSeek-V4 技术报告（2026-04-24，百度百科收录） 3. DeepSeek V4.1 Flash 解析（2026-09-17，百家号） 4. GLM-5.3-Flash 官方发布（2026-08-26，智谱 AI / 百度百科） 5. GLM-5.3-FlashX 上线公告（2026-09-18，新浪科技 / 搜狐） 6. Artificial Analysis Intelligence Index（AA 综合智能指数） 7. 灵犀实测：13款模型智力大考（2026-09-15，微博） 8. 四个 Flash 模型分类任务实测（2026-09-18，网易） 9. GLM-5.3-Flash 深度测评（2026-09-18，什么值得买） 10. SuperCLUE-Terminal 智能体终端编程测评（2026-09，今日头条） 11. 智谱 GLM-5.3-Flash 部署实践（2026-09，CSDN / 知乎） 12. AGI 市场观察报告（2026-09，智能经济30人论坛） --- > **声明**：本报告基于公开信息整理，数据截至 2026 年 9 月 24 日。AI 模型迭代速度极快，建议决策前查阅最新官方数据。部分定价数据存在汇率换算误差，实际使用以官方实时报价为准。

AI Coding 已经改变开发方式了，程序员到底还该学什么？

# 关于 AI 应用和现在程序员就业的一些看法 前段时间有朋友问我： **“现在 AI 这么火，要不要从 Java 转 AI 应用？”** 我当时第一反应是，这两个东西其实就不应该放在一起比较。 有点像几年前问： **“我要不要从 Java 转电商？”** AI 应用是一个方向，Java 是后端的一门语言，本身就不是一个维度的东西。 借这个问题，说一下我目前对 AI 应用、技术栈和程序员就业的一些看法。 都是这两年工作下来的一些个人感受，略带主观。 --- ### 1. 单一技术栈已经不太够用了 国内 Java 的存量盘依旧很大，这个短时间内不会有什么变化。 但我觉得现在只会 Java，或者把自己完全定义成一个 Java 工程师，已经不太够了。 目前后端我比较建议接触的还是： **Java、Go、Python。** Java 主要还是国内大量存量项目、企业级应用和现有团队技术栈。以后很多传统业务做 AI 赋能，也不可能把原来的东西全部推倒重来。 Go 在高并发、云原生这些场景本身就有优势。现在很多 AI 应用又恰好涉及大量并发、流式输出和长连接，用 Go 也比较合适。 Python 就不用说了。 AI 应用继续往下走，不管是 PyTorch、训练、推理还是 AI Infra，基本都绕不开。 当然我不是说三门语言都要学到一样深。 **至少有一门是自己的主语言，真正熟练，其他的能用、能看、能改就行。** 现在有 AI 以后，第二门、第三门语言的学习成本其实已经低很多了。 前端也是一样。 以前如果有人问我国内学 Vue 还是 React，我可能会更建议 Vue。 现在我会更建议 **React + TypeScript**。 主要还是国外生态更大，而且现在 AI Coding 对 React/TS 的支持也更好。 当然结合国内就业，Vue 最好还是得会。 所以我现在对技术栈的看法比较简单： **主技术栈一定要有，但没必要再给自己贴死某一门语言的标签。** --- ### 2. 一定要高强度使用 AI 这个是我目前最确定的一点。 AI Coding 已经不是“以后会不会普及”的问题了。 已经发生了。 我们目前甚至有一个真实的企业项目，基本就是纯 Vibe Coding 驱动开发。 而且不是 Demo。 项目本身是一个比较复杂的 AI 应用平台，涉及多租户、异步任务、分布式并发控制、实时通信、向量检索、全文检索、消息网关、服务监控和 CI/CD 等。 AI 这块也不只是调一下大模型 API，还涉及 RAG、多模态、ASR、视觉检索，以及 PyTorch、CUDA 相关的推理服务。 并且整个架构从一开始就是按照服务拆分、异步化和后续横向扩展去设计的。 说这些不是想证明这个项目有多复杂。 主要是想说，**这是一个有真实工程复杂度、需要长期维护的企业项目，而且大量代码确实是 AI 完成的。** 到目前为止，也没有出现所谓“Vibe Coding 到最后完全没法维护”的情况。 所以我现在觉得： **Vibe Coding 本身不是问题，问题是使用 AI 的人有没有工程能力。** 前两天我负责对接一个渠道商做兼容性的 RAD 开发。 方案、编码、测试基本全部由 AI 完成。 大概半天。 这个事情如果按照以前的开发方式，我估计至少两三周。 所以对于 AI，我没什么“要不要用”的建议。 **一定要用，而且要高强度地用。** 方案、编码、测试、Debug、Review、CI/CD，能用就用。 这已经是生产力问题了。 再说句题外话。 我现在觉得 AI 已经不只是开发工具了。 生活里很多需要搜索信息、学习、分析、做决策的事情，我都会先问一下 AI。 不一定听它的，但至少多一个信息源，多一个思考角度。 开发就更不用说了。 现在越来越多公司已经把 AI Coding 当成正常的研发工具，AI 带来的提效也是实打实的。 所以如果你长期处在一些接触不到 AI 的开发环境里，比如部分外包、纯内网、对日或者 ToG 项目，我觉得需要注意一个问题： **你损失的不只是 AI 帮你写代码的那点效率，而是在慢慢错过一套新的研发方式。** 短期当然没什么。 但如果三年、五年一直处在这种环境里，而外面的工程师已经习惯用 AI 做方案、编码、测试、Review、Debug，甚至完成整个研发流程，那两边积累下来的工作方式和效率差距会越来越大。 所以如果工作环境确实用不了 AI，我反而更建议自己在工作之外保持使用。 **可以不用 AI 写公司的代码，但不要让自己长期脱离 AI。** 这也是为什么我一直强调高强度使用 AI。 不是因为现在 AI 火。 而是我觉得，**会不会把 AI 真正融入自己的工作流，很可能会逐渐变成工程师的基础能力。** --- ### 3. AI 越强，基本功反而越重要 这一点我最近感受也比较深。 24 年甚至更早的时候，我们是真的会为了一个环境折腾半天。 碰到一些难调的 Bug，就自己看日志、翻源码、抓包、排调用链，一点一点 Debug。 现在很多问题直接扔给 AI，可能几分钟就解决了。 所以有时候我反而觉得，26 年才开始学编程的人可能更难。 不是因为工具差，恰恰是因为**工具太好了。** 很多以前必须自己经历的过程，现在可以直接跳过去。但那些过程其实会慢慢形成一些工程直觉。 所以如果你是新人，问我要不要打好基础，我的答案是： **非常有必要。** 数据结构、操作系统这些基础该学还是得学。 同时至少选一门自己的主开发语言，真正学到熟练。不是会写几个接口、会调几个框架就叫熟练，而是真的拿它做过项目、调过问题，对它的运行机制和生态有足够的理解。 因为 AI 可以写代码，也可以 Debug。 **但 AI 给你的东西到底对不对，最后还是需要你判断。** 事务、并发、幂等、异常、性能、可观测性，包括系统出了问题应该从哪里开始查，这些东西不会因为 AI 出现就消失。 反而是 AI 把编码本身变得越来越便宜以后，**这些东西才是真正能拉开工程师深度的地方。** 以前没有 AI 的时候，大家卷框架、卷 API、卷谁记得多，我觉得没什么问题，因为当时这些东西确实直接影响开发效率。 但现在很多框架层面的东西，AI 比我们记得更全，写得也更快。 所以我现在反而更建议新人把时间往基础上放一点。 当然，这个建议也不只是给新人。 **包括我自己，现在也在重新花更多精力，更专业、更体系化地去学这些基础。** 以前很多东西可能是工作里遇到了再学，或者知道怎么用就够了。但现在有了 AI，我反而觉得可以把以前花在记框架、记 API 上的时间拿回来，真正去理解一些更底层、更长期的东西。 有几本书我一直比较推荐： 1. Clean Code 2. The Clean Coder 3. Understanding the Linux Kernel 4. Head First Design Patterns 5. Designing Data-Intensive Applications 当然，书只是一个载体。 我真正想表达的是： **AI 时代不是不需要基本功了，而是以前很多“会用框架”的价值正在被 AI 吃掉，基础和工程判断的价值反而更高了。** AI 可以替你少走很多弯路，但有些路你最好真的走过。 所以我现在越来越觉得，AI 真正放大的不是编码能力。 **是判断能力。** --- ### 4. AI 应用可以转，但现在已经不是做几个 Demo 就好找工作的阶段了 我自己其实算比较早转 AI 应用的。 **25 年 10 月，我就从传统开发转到 AI 赛道了。** 所以如果提前半年或者一年有人问我： “会 RAG、做几个 Agent 项目，能不能转 AI 应用？” 我会觉得问题不大。 但现在我的看法已经变了。 不是 AI 应用不值得做，恰恰是因为**这个方向太火了，进来的人太多了。** 现在很多简历翻来覆去都是： RAG 知识库、AI 客服、PDF 问答、LangChain、Embedding、Milvus、Rerank…… 这些东西当然要会，我自己也在做。 但问题是，**会这些东西的人已经太多了。** 更现实一点说，现在如果只是拿几个这种项目去找 AI 应用的工作，我觉得已经没有以前那么容易了。 而且关于项目这件事，我可以说得直接一点： **现在国内网上能看到的大量所谓 AI 应用项目，我觉得本质上还是玩具项目。** 换一个模型、接一个知识库、套一个 Agent 框架，最后做个聊天页面。 能跑。 但离真正的企业项目还很远。 所以如果现在还准备转 AI 应用，我更建议去看： **真实业务、真实客户、真实场景。** 我前公司是做 AI + 教育的。 国内这一块真正落地的东西，无非也是 AI 答疑、AI 批改、OCR/VLM、个性化学习这些。 AI 答疑底层一样可能是 RAG。 区别只是它最后真的要面对学生、老师和学校，真的要解决问题。 所以不是不要学 RAG，也不是不要学 Agent。 **这些东西该学还是得学，只是别再把“会 RAG、会调 Agent”本身当成竞争力了。** --- ### 5. 除了业务深度，还需要一点技术纵深 上面说的是业务。 但只解决“项目别做成 Demo”这一个问题，我觉得还不够。 现在 AI Application / Agent 这个方向已经很热了，而且这个趋势越来越明显。 当大量工程师都开始做 Agent、RAG、工作流、MCP 以后，应用层的技术差异一定会越来越小。 所以除了去做真实业务以外，我现在还有另外一个建议： **适当往下走，给自己增加一点技术纵深。** 这也是我自己接下来准备深入 AI Infra 的原因。 我目前比较看好： **后端 / 分布式 + AI Application / Agent + AI Infra。** 不是放弃应用层。 恰恰相反，我觉得上层的业务经验很重要，只是在这个基础上继续往模型推理和基础设施走一点。 当然，AI Infra 也别最后学成下一个 RAG。 不是会 Docker、K8s、vLLM，再部署一下 CUDA 环境，就叫 AI Infra。 继续往下还有 Inference Serving、Batching、Scheduling、KV Cache、GPU Memory、PyTorch、CUDA、NCCL、GPU Cluster，以及监控、扩缩容、容错、成本这些东西。 这一块我自己也还在继续学，所以不展开，也不装懂。 我现在的想法其实很简单： **应用层越来越拥挤，就不要只在应用层继续横向堆东西。** 业务上往真实场景走，技术上往深处走。 至少目前，我自己准备这么走。 --- 最后其实就两个建议。 **1. 高强度使用 AI，别和生产力过不去。** 不要只拿 AI 补两行代码。 方案、编码、测试、Debug、Review、CI/CD，能用就用。 **2. 如果准备转 AI，别再堆玩具 Demo。** 去看真实业务，解决真实问题，再给自己找一个方向往深了走。 至于 Java、Go、Python、React、Vue，该用什么就用什么。 **主技术栈要有，工程基本功别丢，AI 狠狠用。** 差不多就这些。 听不听随意。