Git on 小盒子的技术分享

Postman 越来越臃肿了，我换了个开源的，还能让 AI 帮我写测试

Mon, 13 Apr 2026 03:56:46 +0000

Postman 我用了好几年了。

从最早的 Chrome 插件时代开始用的，那时候它还是个轻量小工具，打开就能测接口，干干净净。但最近这两年，怎么说呢，它开始「端着」了。

打开就让我登录。不登录不让用。

好不容易登录了，又弹窗让我升级 Team 版。

集合还给我存到云端去了。我就测个本地接口，你把我的请求数据往你服务器上传干嘛？

我一直忍着，直到有一天，团队里两个人同时改了同一个集合，Postman 云同步直接给合并冲突了，还没法像 Git 那样 diff 看变更。那天我就想，不行了，得换。

然后我遇到了 Bruno。

怎么形容呢，就像你一直在用一个越来越臃肿的 IDE，突然有人递给你一个 Vim，告诉你「够用了，而且是你的」。

Bruno 干了一件特别简单但特别对的事情，它把你的 API 请求存成 .bru 文件，放在你本地文件夹里。

就是普通的文本文件，打开长这样。

1meta { name: 用户登录 type: http seq: 1}post { url: {{baseUrl}}/auth/login body: json auth: none}headers { Content-Type: application/json}body:json { { "username": "{{username}}", "password": "{{password}}", "expiresInMins": 30 }}script:post-response { if (res.status === 200) { bru.setVar("authToken", res.body.accessToken); bru.setVar("userId", res.body.id); }}tests { test("登录应该返回 200", function() { expect(res.status).to.equal(200); }); test("响应中应该包含 accessToken", function() { expect(res.body.accessToken).to.be.a("string"); expect(res.body.accessToken.length).to.be.greaterThan(0); }); test("响应中应该包含用户基本信息", function() { expect(res.body.id).to.be.a("number"); expect(res.body.username).to.equal("emilys"); expect(res.body.email).to.be.a("string"); }); test("响应时间应该小于 3 秒", function() { expect(res.responseTime).to.be.lessThan(3000); });}

你看，GET 请求、Header、Body、断言，全都是纯文本。你用任何编辑器都能打开它，改完保存就行。

这玩意最不同的地方在哪？

它可以用 Git 管理。

以前团队共享 Postman 集合，那叫一个痛苦。谁改了什么不知道，版本对不对不确定，冲突了还没法 resolve。

现在用 Bruno，接口定义就是文件，扔进 Git 仓库，该 PR 就 PR，该 Code Review 就 Code Review。有人改了某个接口的 Header，diff 里看得一清二楚。

用程序员已经会的工具，解决程序员的问题。不用学新的协作方式，不用付费，不用担心数据被传到哪个云上。

Bruno 官网上有一句话我印象特别深，大意是**「我们不会同步你的任何数据到云端，甚至连登录的概念都没有。我们看不到你在 Bruno 里输入了什么，也不会用你的数据训练任何 AI 模型」。**

在这个年代，一个工具敢这么说，我觉得还是挺硬气的。

回到工具本身。说到这里，可能有朋友会想，开源 API 客户端一抓一大把，Insomnia、Hoppscotch、Thunder Client，凭什么是 Bruno？

我自己用下来，让我有「这玩意不一样」的瞬间，是发现它有 CLI。

但我说的不是「能在终端里跑测试」这种废话。Newman 也能跑，Postman 自己也有命令行。我说的是另一件事。

Bruno 的 CLI，让 Claude Code 和 Cursor 这种 AI 编程工具，第一次能真正帮你写和跑接口测试。

这话有点大，我用两件刚发生的真事讲一下。

回到 Bruno 的 CLI 本身。装它就一行，

1npm i -g @usebruno/cli

装完之后命令叫 bru，跑整个集合的测试是这样，

1bru run --env production

输出长这样。

干净、彩色、有 ✓ 和 ✗、有总耗时、有失败原因。最重要的是，这是一段普通的终端命令，输出是普通的文本。

为什么这件事重要？因为这两个特征，正好是 AI 编程 agent 工作的边界。

Claude Code、Cursor、Codex 这些工具，它们能干什么？它们能读你的代码文件，能写新的文件，能在终端里跑命令，能读命令的输出。它们不能干什么？它们不能点击 Postman 的按钮，不能在你 GUI 里输入 token，不能登录任何账号。(或者说不方便，成本高，效率低)

Postman 的核心数据存在云端、操作靠 GUI、协作靠登录，这三件事每一件都把 AI agent 挡在外面。

而 Bruno 的核心数据是 .bru 文本文件、操作靠 CLI、协作靠 Git。每一件都正好是 AI 最擅长的那种事。

抽象的说完了，说点具体的。

我前两天就让 Claude Code 帮我加了一个测试，过程是这样的。

我跟它说，「我刚加了一个搜索商品的接口，帮我在 bruno 集合里加个测试用例」。

它干了三件事，全程没问我任何问题。

第一步，读了我现有的一个 .bru 文件，就是为了搞清楚我用的格式。比如我习惯加哪些 test，断言风格是什么样的。

第二步，照着这个格式写了一个新的 06-搜索商品.bru 文件，放在我集合的根目录里。请求方法、URL、query 参数、4 条断言，全都给我加上了。

第三步，它直接执行 bru run 06-搜索商品.bru --env production，亲眼看着 4 个测试全绿，然后才回我一句「写完了，4/4 通过」。

整个过程我没碰 Bruno 的 GUI，没敲一个字符的代码，没解释什么是 .bru 格式。AI 自己读自己写自己跑自己验证。

你可能会问，这个事换成 Postman 不行吗？

我得先把话说清楚，Postman 不是没有 CLI。Newman 一直都在，Postman Collection 也是 JSON 文件，AI 理论上能读能写。这条路是通的。

但你真去试一下就会发现，那条路上全是石头。

Postman 的 Collection JSON 格式不是给人手写的。我做了个最朴素的对比，同一个 GET 请求加一条「状态码等于 200」的断言，写成 .bru 是 15 行，导出成 Postman Collection JSON 是 44 行。区别在哪？.bru 里 URL 就是一个字符串 https://api.example.com/users，Postman JSON 里 URL 被拆成 protocol、host 数组、path 数组三个字段。.bru 里测试代码就是普通 JS，Postman JSON 里测试代码以字符串数组的形式塞在 event 里，每一行 JS 都得加引号、转义、再 JSON 序列化一次。还有一堆 _postman_id、_exporter_id、schema 这种内部元数据，跟你的业务接口毫无关系，但你不写就报错。

让 AI 写 .bru，它跟写 markdown 一样轻松。让 AI 写 Postman JSON，它更像在翻译一份配置文件，token 烧得多，出错概率高，写完你自己 review 都费劲，git diff 出来三行业务变更夹在二十行格式噪音里。

所以不是 AI 不能写 Postman 的测试，是 Postman 的格式从一开始就没打算让人手写，更没打算让 AI 直接读写。它假设你有一个 GUI 在中间帮你管理这些内部细节。AI 进来之后，那个假设就有点尴尬了。

我说的还不是最炸的场景。

真正让我觉得 Bruno + AI 是 1 + 1 大于 10 的，是调试场景。

我又试了一次，让 Claude Code 帮我加一个购物车接口的测试。它写完跑了一遍，挂了。

错误信息是这样的。

 1✕ 购物车应该有 totalPrice 字段 expected undefined to be a number✕ 购物车应该有 products 数组 expected undefined to be an array
 2
 3```bash
 4
 5它猜错了字段名。这种事很正常，毕竟它没真的去看接口返回。但接下来才有意思。
 6
 7它没有问我、没有让我提供文档、也没有放弃。它自己执行了一条 curl 命令，把购物车接口的真实响应拉了下来。
 8
 9```bash
10curl -s https://dummyjson.com/carts/1

看到响应里字段是 total 和 products，不是 totalPrice 和 items。它马上把测试里的字段名改了，再跑一遍，全绿。

整个调试过程，我做了什么？我什么也没做。我只是看着它一步一步跑完。

这就是 Bruno + CLI + AI 的真正价值。你的 API 测试不再是一个孤立的、需要你手动维护的负担，而是变成了 AI 可以读、可以写、可以跑、可以调试的一种代码。

它和你的源码、你的 Git 历史、你的 CI/CD、你的 AI agent，全都是一体的。

写到这里我猜有人要拍桌子了。

「等等，国内程序员谁还用 Postman 啊？Apifox 它不香吗？」

发，我们专门聊聊 Apifox。

我必须先承认它真的很强。一体化平台，API 文档、调试、Mock、自动化测试、团队协作全在一个工具里搞定，相当于 Postman + Swagger + JMeter 三合一。界面是中文，文档是中文，国内团队几乎零学习成本。如果你的团队 20 人以上，需要权限管理、需要实时协作、需要统一的 API 文档管理，Apifox 是比 Bruno 更合适的选择。这点我不否认。

而且 Apifox 不傻，它也在跟上 AI 浪潮。它有 apifox-cli，能在终端里跑测试场景。它甚至专门做了 Apifox MCP Server，可以让 Cursor 和 Claude Desktop 读取 Apifox 项目里的 API 文档，帮你写代码。

那问题来了，Bruno 和 Apifox 在 AI 这件事上到底有啥不一样？

我读了一圈 Apifox 的官方文档，发现一个挺有意思的差别。

Apifox 接 AI 的方式，是让 AI 来连接 Apifox。Bruno 接 AI 的方式，是 Bruno 根本就是 AI 已经会读的格式。

具体说，Apifox 的 AI 工作流是这样的，你的测试数据躺在 Apifox 云端项目里，你装一个 Apifox MCP Server，配置 Cursor 去连这个 MCP，AI 通过 MCP 协议向 Apifox 服务发请求，把 API 文档拿下来，再帮你生成代码。

Bruno 的 AI 工作流是这样的，你的测试就是项目目录里的 .bru 文件，AI 直接 cat、edit、bru run。完了。

你看出区别了吗？Apifox 把 AI 当成一个外部工具来对接，所以需要 MCP 这一层中转。而 Bruno 根本不需要 MCP，因为它跟 AI 用的是同一种原生语言：文本文件加终端命令。

还有一个更现实的差别。Apifox 的 MCP Server 现在的能力，是让 AI 读取 API 文档来生成代码，它并不能让 AI 直接去编辑你的测试用例。AI 在 Apifox 这边的角色基本上是只读的。

而我前面演示的那两个场景，Claude Code 帮我写新测试、自动调试、修字段名，那是完整的读写跑改循环。AI 不光在读，还在写，还在跑，还在调试。这是因为 .bru 是普通文件，Edit 工具就能改，Bash 工具就能跑。它中间没有任何一层，所以也没有任何一层会卡住。

这不是说 Apifox 不好，是两条不同的路。Apifox 选的是「我是平台，AI 来连我」，Bruno 选的是「我什么都不是，我就是文件」。前者适合企业级场景，后者适合代码即测试的开发者工作流。

我自己是后者。我喜欢我所有的东西都能塞进 Git 仓库，喜欢 AI 直接读我硬盘上的文件，不喜欢任何账号、登录、云端中转。所以我选 Bruno。

如果你的工作场景更接近企业级 SaaS 那一套，那 Apifox 完全没问题，甚至更合适。但如果你跟我一样，希望让 AI 一句话把接口测试搞定，那 Bruno 这条路确实更顺。

聊完 Apifox 我们继续。顺便提一下 CI 集成，因为这块也很丝滑。Bruno CLI 支持输出 JUnit XML，GitHub Actions、GitLab CI、Jenkins 直接吃这个格式。我的工作流文件大概长这样。

1- name: 安装 Bruno CLI run: npm install -g @usebruno/cli- name: 跑接口测试 run: bru run --env production --reporter-junit junit.xml

两步。你的 PR 一提交，所有接口测试自动跑一遍，挂了直接拒绝合并。

生成的测试执行也挺好看的

整套东西免费、开源、本地、Git 友好、AI 友好，不用登录、不用付钱、不用担心数据上云。

安装很简单。桌面版，

1brew install bruno
2
3```bash
4
5CLI，
6
7```bash
8npm i -g @usebruno/cli

用了一周之后我把 Postman 卸了。

不是它不好，是我不再需要一个登录才能用、集合存在别人云上、免费版各种限制、AI 完全帮不上忙的接口测试工具了。

我只需要一个文件夹、几个 .bru 文件、一条终端命令，和一个能读懂这一切的 AI。

有时候工具的进步不是功能越加越多，而是把不该有的东西去掉。Bruno 去掉了登录、去掉了云端、去掉了 GUI 锁定，剩下的全是程序员真正需要的东西。

而当你把这些不需要的东西去掉之后，你会发现一个意外的副作用，AI 进来了。

好了就说这么多。

如果你也受够了 Postman，试试 Bruno。说不定你也会像我一样，用完就回不去了。

ps:我写的 demo 在这里，你可以拉下来试一下，可以 run 的：https://github.com/xiaobox/bruno-demo

全程0人工写代码！干掉低级码农的不是大模型

Tue, 24 Feb 2026 03:46:39 +0000

全程0人工写代码！干掉低级码农的不是大模型

在当前全行业的 AI 辅助编程浪潮中，大多数工具仍停留在“交互式伴游”阶段，而支付巨头 Stripe 却打造了一套完全无人值守的端到端代码智能体——“小黄人”（Minions）

小黄人是一个独立打工的“数字员工”。目前的惊人数据是：在 Stripe 内部，每周有超过 1300 个由小黄人完全生成的 Pull Requests（合并请求）被成功合并。这些代码在最终阶段会经过人类审查，但其中不包含任何人类编写的代码。

更具挑战的是，Stripe 的代码库高达数亿行，主要使用较冷门的带有 Sorbet 类型的 Ruby 语言，且包含大量 LLM 根本没见过的大型内部自研库。此外，这些代码每年要处理超过 1 万亿美元的支付量，合规与容错要求极高。

Stripe 是如何让 LLM 驾驭如此庞大且复杂的企业级代码库的？核心答案在于极其强大的定制化工程脚手架。

以下是小黄人能高效运转的四大核心技术拆解。

1 极致标准化的预热沙盒（Devboxes）

要让全自动 Agent 大规模并行工作，绝不能让它们跑在开发者杂乱的本地笔记本上。Stripe 的解法是直接复用为人类工程师打造的云端开发机（Devboxes）。

●10 秒极速“热启动”：这些 Devbox 是 AWS EC2 实例。Stripe 预先配置并预热了一个资源池，里面已经克隆好了巨大的 Git 仓库，预热了 Bazel 构建缓存和类型检查缓存，甚至启动了持续运行的代码生成服务。因此，只要 10 秒钟，小黄人就能拿到一台随时可以运行测试和修改代码的机器。

●免弹窗的完全提权：为了让小黄人在后台静默运行，它需要无缝执行各种 Shell 命令。因为 Devbox 运行在与生产资源和外部互联网隔离的 QA 环境中，爆炸半径被严格限制，所以系统敢于跳过人类权限确认弹窗，给予小黄人完整的执行自由。

●解决并发冲突：如果用本地环境，并发运行多个 Agent 需要处理复杂的 git worktrees（这在 Stripe 的庞大代码库中无法扩展）。而在云端，工程师可以轻易地同时为 6 个不同的任务启动 6 个分配了独立 Devbox 的小黄人，实现物理级别的完美隔离

2 “蓝图”编排（Blueprints）：将大模型装进确定性的盒子里

常规的 Agent 往往采用开放的循环机制，任由 LLM 自己决定下一步调什么工具，这极易导致出错和浪费 Token。 Stripe 创造性地引入了**“蓝图”（Blueprints）**状态机机制。蓝图将整个工作流视为一张图，将 LLM 的创造力与确定性的系统代码交织在一起：

●确定性节点 vs Agent 节点：在蓝图中，像“实现具体任务”或“修复 CI 失败”是让 LLM 自由发挥的 Agent 节点；但是，像“运行配置好的 Linter”或“推送 Git 变更”则是完全不调用 LLM 的纯代码确定性节点。

●底线兜底：这意味着小黄人无法绕过代码格式化等硬性规范。把大模型“关进受控的盒子里”，不仅极大地节省了 Token，还从系统层面提高了整体可靠性。各团队甚至可以编写自定义的蓝图，来处理复杂的、LLM 辅助的代码库迁移任务

3 极其克制的上下文投喂：规则文件与 Toolshed

面对上亿行代码，如果把所有全局规则都塞给大模型，上下文窗口瞬间就会被撑爆。

●按目录生效的局部规则：Stripe 几乎只使用作用于特定子目录或文件模式的规则文件。他们巧妙地复用了人类工程师为 Cursor 编写的规则格式。这样，工程师在日常开发中沉淀的最佳实践，小黄人（以及 Claude Code）在遍历文件系统时就能直接动态读取并学习。

●MCP 工具棚（Toolshed）：小黄人通过模型上下文协议（MCP）获取网络信息（工单、文档、代码搜索等）。Stripe 建立了一个包含近 500 个内部与 SaaS 工具的中央服务器 Toolshed。但为了防止 Agent 分心，系统每次只会为小黄人精心挑选一个“小巧而高度相关”

4 反馈左移（Shifting Feedback Left）：极速纠错循环

无人值守 Agent 成功的关键在于能否实现自我闭环修正。Stripe 为其构建了多层极速反馈循环：

●5 秒内的本地验证：在小黄人把代码推送到 CI 之前，Devbox 上的后台守护进程会通过启发式算法自动运行相关的 Linter 和类型检查。这个本地节点耗时不到 5 秒，让小黄人在本地极速完成语法纠错。

●克制的 CI 测试轮数：Stripe 的 CI 拥有超过 300 万个测试用例。推送到 CI 后，系统会运行相关测试，并自动应用已有的修复脚本（Autofixes）。如果还有未修复的错误，报错会发回给小黄人。但为了平衡算力成本、时间与边际收益，小黄人最多只被允许进行 1 到 2 次的 CI 循环试错。之后无论成败，都会将其移交给人类处理，防止其陷入昂贵的死循环

给我的启示

基于 Stripe 公开的这些技术细节，我得出了以下几点关于 AI 研发提效的深刻感悟：

1.“对人类工程师有益的基础设施，对 LLM 同样有益” 这是 Stripe 整个小黄人项目最核心的哲学。Stripe 并没有为了做 AI Agent 去凭空造一套新基建，而是直接将 AI 接入了他们多年打磨的 Devbox 环境、Pre-push hooks 和自动化测试管线中。这给所有企业的启示是：AI Agent 的天花板，取决于你现有工程基础设施的底座。如果你的人类工程师本地环境经常崩溃、缺乏单测覆盖率、文档陈旧，那么大模型也一样会在这些泥坑里寸步难行。过去在人类开发者体验（Developer Productivity）上的每一分投资，都会在 AI 时代转化为巨大的复利回报。

2.放弃追求纯粹的“全能 Agent”，用“蓝图”管控不确定性目前业界过度迷恋让一个 Agent 自主解决所有问题。但 Stripe 的蓝图（Blueprints）设计极其务实：能用一行 Bash 脚本或 Linter 稳定解决的问题（如代码格式化、Git 提交流程），就绝对不让 LLM 消耗 Token 去“推理”。在企业级生产环境中，**混合架构（确定性代码逻辑 + 局部受控的 LLM 节点）**才是保证系统高可靠性（SLA）的唯一出路。

3.工程师的日常工作流正在被重塑，在 Stripe，触发小黄人的方式极度符合人体工程学：工程师可以直接在 Slack 的讨论线程里@小黄人，或者在内部的“CI 间歇性失败（Flaky test）”工单中点击一个按钮启动它。我们可以预见，未来的高级工程师将越来越像一个“包工头”：他们在值班（On-call）时并行启动几十个小黄人去处理琐碎的 Bug，自己则专注于审查 PR、设计架构，以及维护和编写能够指导小黄人的局部规则（Cursor rules）。工程师不再逐行敲击代码，而是定义意图并管理基础设施。

参考

●https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents

●https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2

Claude 新王牌 “Skills” 深度解析：让你的 AI 秒变行业专家，告别重复劳动

Tue, 28 Oct 2025 12:13:19 +0000

TLDR

Claude Skills 就像是给 Claude 安装的 “专家记忆包”，能将它从一个通用 AI 变为精准执行特定任务的专家。

●核心功能：将重复性工作流程（如公司品牌风格、代码规范、报告格式）打包成可复用的指令，让 Claude 能自动、可靠地完成任务，无需每次都重复提醒。

●工作原理：一个 Skill 就是一个带说明书 (SKILL.md) 的文件夹。Claude 只在需要时才会加载完整的指令，平时只记忆一个简短的描述。这种设计 极其节省 Token，让你可以安装大量 Skills 而不影响性能。

●与工具 (Tools / APIs) 的区别：Skills 教会 Claude “如何做” 一件事（内部知识和流程），而工具让 Claude “去做” 一件事（调用外部数据或执行动作）。两者可以互补。

●最大优势：简单、高效、实用。它将复杂的 AI 定制过程简化为写文档，让 AI 能真正融入并标准化你的日常工作。

Claude Skills 的定位

核心理念：Skills 将通用模型转变为领域专家

它是面向具体任务的“技能包”，以文件夹形式存在，通过轻量的说明与可执行工具，让 Claude 在需要时加载并执行，从而实现可重复、可定制的工作流。它们既“简单”（就是 Markdown 和脚本）、又“复杂”（能驱动多步的智能代理任务）。

Skills 工作原理

Skills 的设计核心是简洁与高效，它通过一种名为 “渐进式披露”（Progressive Disclosure）的机制，在不牺牲性能的前提下，赋予 Claude 强大的扩展能力。

一个 Skill 就是一个包含指令的简单文件夹

一个 Skill 的核心是一个包含 SKILL.md 文件的文件夹。这个 Markdown 文件使用 YAML Frontmatter 来定义元数据（如名称和描述），文件的主体部分则包含了清晰、分步的任务指南和示例。

举例： https://github.com/anthropics/skills/blob/main/document-skills/pptx/SKILL.md

Claude 会自动发现并加载相关的 Skill

无需手动触发 Skill。在会话开始时，Claude 会扫描所有已安装 Skills 的元数据（名称和描述），并将这些简短信息加载到其系统提示中。当你的请求与某个 Skill 的描述相匹配时，Claude 会自动读取并加载该 Skill 的完整指令。

“渐进式披露” 机制使 Skills 极为高效

Skill 通过三层结构（YAML 前言、正文、文件引用）逐步、按需地把信息送入模型上下文，避免一次性塞满，提升效率与 token 经济性。

Skills 的设计极其注重 Token 效率。初始加载时，每个 Skill 只占用几十个 Token 来存储其元数据。只有在被触发时，Skill 的详细指令才会进入上下文窗口。这种按需加载的机制意味着您可以安装大量的 Skills，而不会因为上下文窗口被占满而影响模型性能。对于更复杂的 Skill，还可以将不同的指令拆分到多个文件中，Claude 只会读取当前任务所需的部分，进一步节省了 Token。

Skills 可包含代码以确保任务执行的可靠性

除了文本指令，Skills 还可以捆绑可执行的 Python 脚本。对于需要确定性和高可靠性的任务（例如，数据排序或格式验证），让 Claude 直接运行预先写好的代码比实时生成代码更高效、更可靠。例如，一个用于创建 Slack GIF 的 Skill 包含了一个 Python 脚本，该脚本不仅能生成动图，还能验证其文件大小是否符合 Slack 的上传限制。

应用平台：Skills 可跨所有 Claude 产品使用

Skills 的设计具有良好的可移植性，一次构建，即可在 Claude 的多个产品中使用。

●在 Claude.ai 网页版中使用

○付费用户（Pro, Max, Team, Enterprise）可以在设置中启用和上传自定义 Skills。 Anthropic 也提供了一些预置的 Skills 用于处理常见的文档格式（如 Word, Excel, PowerPoint, PDF）。

●通过 Claude API 为开发者所用

○开发者可以通过 Skills API 上传和管理自定义 Skills，并在调用 Messages API 时指定使用。这使得企业可以将封装了特定业务逻辑的 Skills 集成到自己的应用程序中。

●在 Claude Code 中用于本地开发

○在 Claude Code（一个集成开发环境）中，Skills 以本地文件系统的形式存在。开发者可以将 Skills 放在特定目录（~/.claude/skills）下，Claude 会自动发现并使用它们，这非常适合团队通过版本控制系统（如 Git）共享和协作开发 Skills。

应用场景：Skills 擅长自动化内部工作流

Skills 的核心价值在于自动化那些有固定流程和规范的重复性任务，从而大幅提升效率。

●案例一：确保文档的品牌风格一致

○你可以创建一个 Skill 来封装公司的品牌指南。当要求 Claude 创建演示文稿或新闻稿时，它会自动调用这个 Skill，确保所用颜色、字体、徽标和行文语气都符合公司标准，无需人工检查和修改。

●案例二：自动化财务报告流程

○日本电商巨头乐天（Rakuten）使用 Skills 将一项原先需要一整天时间的财务报告流程缩短到了一个小时。该 Skill 封装了处理多份电子表格、发现异常数据以及根据公司内部流程生成报告的全部逻辑。

●案例三：标准化软件开发任务

○一个开发团队可以创建 Skills 来统一代码审查标准、生成符合特定架构的样板代码，或指导如何与内部 API 交互。例如，一个 mcp-builder Skill 可以指导 Claude 如何创建高质量的 MCP 服务器。

Skills 与模型上下文协议（MCP）的关键区别

虽然 Skills 和 MCP（Model Context Protocol）都是扩展 AI 能力的方式，但它们的设计哲学和适用场景截然不同。

两者的本质区别是：Skills把“人类流程/SOP”转为可触发的模块；MCP把“外部工具/API/数据源”转为可调用的标准接口。

Skills擅长程序化写作、格式化、合规、数据整理等“内部可编码”的流程；MCP擅长访问GitHub、CI/CD、Slack、数据库等外部系统、实时数据与动作。

●Skills 重点在于 “如何完成任务” 的内部指令

○Skills 更像是给 Claude 的一本 “操作手册”，它告诉模型完成某项任务的具体步骤、最佳实践和注意事项。它关注的是过程和方法。

●MCP 重点在于连接外部工具与数据源

○MCP 是一个开放协议，旨在标准化 AI 与外部世界（如数据库、SaaS 工具、API）的交互方式。它关注的是访问和行动，让 Claude 能够调用外部工具来获取实时信息或执行操作。

●Skills 轻量且高效；MCP 可能消耗大量 Tokens

○如前所述，Skills 通过 “渐进式披露” 机制实现了极高的 Token 效率。相比之下，一些 MCP 的实现可能需要在提示中加载数万 Token 的 API 文档和定义，这会严重挤占模型处理实际任务的上下文空间。

●Skills 和 MCP 可以协同工作

○Skills 和 MCP 并非相互排斥，而是互补的。在一个复杂的工作流中，您可以使用 MCP 从 GitHub 或公司的数据库中获取实时数据，然后利用 Skill 来分析这些数据并生成符合特定格式的报告。

快速上手：用一个简单的 Markdown 文件创建你的第一个 Skill

创建一个基础 Skill 非常简单，您只需要创建一个包含 SKILL.md 文件的文件夹即可。

以下是一个模板：

 1⚡ markdown片段---
 2name: my-first-skill
 3description: 这是一个关于此 Skill 能做什么以及何时使用它的清晰描述。
 4---
 5# 我的第一个 Skill
 6
 7[在这里添加您的指令，Claude 在激活此 Skill 时会遵循这些指令]
 8
 9## 示例
10- 用法示例 1
11- 用法示例 2

只需填写 name 和 description 字段，然后在 Markdown 主体中用自然语言描述操作步骤，一个可用的 Skill 就完成了。

安全须知：使用第三方 Skills 时需保持谨慎

Skills 可以执行代码，这意味着它们拥有强大的能力，同时也带来了安全风险。 一个恶意的 Skill 可能会被设计用来执行非预期的操作，例如访问敏感文件或泄露数据。因此，强烈建议只使用来自可信来源的 Skills，例如由你自己或 Anthropic 创建的。在使用任何第三方 Skill 之前，请务必仔细审查其包含的所有文件（包括脚本和说明）。

Skills 使 AI 更实用、更具组合性

Claude Skills 的核心价值在于其设计的简洁性和强大的实用性。 它将复杂的 AI 定制过程简化为编写结构化的文本文档，极大地降低了使用门槛。通过将程序性知识和工作流程封装为可组合、可重用、可共享的模块，Skills 让 Claude 能够真正融入个人和组织的日常工作中，成为一个高效、可靠的专家级助手。正如一些开发者所言，Skills 这种简单而强大的模式，可能会比更复杂的协议（如 MCP）产生更深远的影响，因为它更贴近 LLM 的工作本质：给出文本，让模型去理解和执行。

对产品与组织的启示

●把隐性知识产品化：将“新人指南”“最佳实践”沉淀为可执行的技能包，而非散落的文档。这样可提升一致性、可复用性与审计可见性，减少人依赖与输出波动。

●逐步披露是上下文治理的关键：通过轻量前言、正文指令与按需文件引用，控制信息进入模型的节奏与粒度，显著提升效率与可预测性，降低 token 与推理成本。

●流程模块化与组合式设计：用 Skills 编排“怎么做”，用 MCP 连接“可用资源”，形成可插拔的自动化生产线。模块边界清晰，更易维护与演进。

●标准化驱动品牌与指标口径统一：把品牌规范、度量模型（如 LTV/CAC/流失率）和任务拆解统一到技能包，避免临场解读差异，确保跨团队输出一致。

●从规格到实现的闭环：将 PRD→用户故事→验收标准→开发任务→代码的链路自动化，压缩交付周期，同时让变更可追踪、可回滚、可复盘。

思维方式的转变

●从“写提示”到“设计流程”：把提示工程升级为流程工程，关注输入结构、工具链、状态管理与容错。

●从“一次性产物”到“可维护系统”：每个技能都是可版本化的流程单元，像软件一样测试、发布与回滚。

●从“智能补充”到“智能基建”：将 Skills 视为组织的智能基础设施，承载标准、权限、日志与治理。

附录

●官方提示的 skills : https://github.com/anthropics/skills

快速安装 ClickHouse

Thu, 17 Jul 2025 09:33:05 +0000

概述

我们使用 docker compose 来安装 ClickHouse

但我们不是裸装 ClickHouse，实际上我们安装的是 ClickStack。有点儿像 elastic-stack 与 elastic search 的关系，但并不完全一样。

ClickStack 是基于 ClickHouse 构建的完整观察性平台，集成了日志、指标、追踪和会话回放功能，提供统一的用户界面和查询能力。因此，ClickStack 是在 ClickHouse 的基础上，结合 HyperDX 提供的前端界面和 OpenTelemetry Collector 实现的完整解决方案。它不仅仅是一个数据库，而是一个集成的观察性平台。

安装步骤参考官方文档：https://clickhouse.com/docs/zh/use-cases/observability/clickstack/getting-started?loc=use-case-observability

安装

克隆 HyperDX 仓库

1git clone https://github.com/hyperdxio/hyperdx.git
2
3cd hyperdx
4
5# switch to the v2 branch
6git checkout v2

根据自身情况修改配置文件 .env

我将 HDX_IMAGE_REPO=docker.hyperdx.io 修改为 HDX_IMAGE_REPO=docker.io 不然镜像拉不下来

 1# Used by docker-compose.yml
 2HDX_IMAGE_REPO=docker.hyperdx.io
 3IMAGE_NAME=ghcr.io/hyperdxio/hyperdx
 4IMAGE_NAME_DOCKERHUB=hyperdx/hyperdx
 5LOCAL_IMAGE_NAME=ghcr.io/hyperdxio/hyperdx-local
 6LOCAL_IMAGE_NAME_DOCKERHUB=hyperdx/hyperdx-local
 7ALL_IN_ONE_IMAGE_NAME=ghcr.io/hyperdxio/hyperdx-all-in-one
 8ALL_IN_ONE_IMAGE_NAME_DOCKERHUB=hyperdx/hyperdx-all-in-one
 9OTEL_COLLECTOR_IMAGE_NAME=ghcr.io/hyperdxio/hyperdx-otel-collector
10OTEL_COLLECTOR_IMAGE_NAME_DOCKERHUB=hyperdx/hyperdx-otel-collector
11CODE_VERSION=2.0.5
12IMAGE_VERSION_SUB_TAG=.0.5
13IMAGE_VERSION=2
14IMAGE_NIGHTLY_TAG=2-nightly
15IMAGE_LATEST_TAG=latest
16
17# Set up domain URLs
18HYPERDX_API_PORT=8000 #optional (should not be taken by other services)
19HYPERDX_APP_PORT=8080
20HYPERDX_APP_URL=http://localhost
21HYPERDX_LOG_LEVEL=debug
22HYPERDX_OPAMP_PORT=4320
23
24# Otel/Clickhouse config
25HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=default

docker compose 启动

1docker-compose up -d

Docker-compose 文件如下：

 1name: hdx-oss
 2services:
 3 # ONLY USED FOR DEMO SSL SETUP
 4 # nginx:
 5 # image: nginx:1.27.3
 6 # volumes:
 7 # - ./docker/nginx/nginx.conf:/etc/nginx/nginx.conf
 8 # - ./docker/nginx/ssl:/etc/nginx/ssl
 9 # - .volumes/nginx_logs:/var/log/nginx
10 # ports:
11 # - 80:80
12 # - 443:443
13 # networks:
14 # - internal
15 # depends_on:
16 # - app
17 db:
18 image: mongo:5.0.14-focal
19 volumes:
20 - .volumes/db:/data/db
21 # WARNING: Exposing the database port will make it accessible from outside the container,
22 # potentially allowing unauthorized access. If you uncomment the ports below,
23 # ensure to secure your database (e.g., with strong authentication, proper network rules, and firewalls).
24 # ports:
25 # - 27017:27017
26 networks:
27 - internal
28 otel-collector:
29 image: ${HDX_IMAGE_REPO}/${OTEL_COLLECTOR_IMAGE_NAME_DOCKERHUB}:${IMAGE_VERSION}
30 environment:
31 CLICKHOUSE_ENDPOINT: 'tcp://ch-server:9000?dial_timeout=10s'
32 HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE: ${HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE}
33 HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
34 OPAMP_SERVER_URL: 'http://app:${HYPERDX_OPAMP_PORT}'
35 ports:
36 - '13133:13133' # health_check extension
37 - '24225:24225' # fluentd receiver
38 - '4317:4317' # OTLP gRPC receiver
39 - '4318:4318' # OTLP http receiver
40 - '8888:8888' # metrics extension
41 restart: always
42 networks:
43 - internal
44 depends_on:
45 - ch-server
46 app:
47 image: ${HDX_IMAGE_REPO}/${IMAGE_NAME_DOCKERHUB}:${IMAGE_VERSION}
48 ports:
49 - ${HYPERDX_API_PORT}:${HYPERDX_API_PORT}
50 - ${HYPERDX_APP_PORT}:${HYPERDX_APP_PORT}
51 environment:
52 FRONTEND_URL: ${HYPERDX_APP_URL}:${HYPERDX_APP_PORT}
53 HYPERDX_API_KEY: ${HYPERDX_API_KEY}
54 HYPERDX_API_PORT: ${HYPERDX_API_PORT}
55 HYPERDX_APP_PORT: ${HYPERDX_APP_PORT}
56 HYPERDX_APP_URL: ${HYPERDX_APP_URL}
57 HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
58 MINER_API_URL: 'http://miner:5123'
59 MONGO_URI: 'mongodb://db:27017/hyperdx'
60 NEXT_PUBLIC_SERVER_URL: http://127.0.0.1:${HYPERDX_API_PORT}
61 OPAMP_PORT: ${HYPERDX_OPAMP_PORT}
62 OTEL_SERVICE_NAME: 'hdx-oss-api'
63 USAGE_STATS_ENABLED: ${USAGE_STATS_ENABLED:-true}
64 DEFAULT_CONNECTIONS:
65 '[{"name":"Local
66 ClickHouse","host":"http://ch-server:8123","username":"default","password":""}]'
67 DEFAULT_SOURCES:
68 '[{"from":{"databaseName":"default","tableName":"otel_logs"},"kind":"log","timestampValueExpression":"TimestampTime","name":"Logs","displayedTimestampValueExpression":"Timestamp","implicitColumnExpression":"Body","serviceNameExpression":"ServiceName","bodyExpression":"Body","eventAttributesExpression":"LogAttributes","resourceAttributesExpression":"ResourceAttributes","defaultTableSelectExpression":"Timestamp,ServiceName,SeverityText,Body","severityTextExpression":"SeverityText","traceIdExpression":"TraceId","spanIdExpression":"SpanId","connection":"Local
69 ClickHouse","traceSourceId":"Traces","sessionSourceId":"Sessions","metricSourceId":"Metrics"},{"from":{"databaseName":"default","tableName":"otel_traces"},"kind":"trace","timestampValueExpression":"Timestamp","name":"Traces","displayedTimestampValueExpression":"Timestamp","implicitColumnExpression":"SpanName","serviceNameExpression":"ServiceName","bodyExpression":"SpanName","eventAttributesExpression":"SpanAttributes","resourceAttributesExpression":"ResourceAttributes","defaultTableSelectExpression":"Timestamp,ServiceName,StatusCode,round(Duration/1e6),SpanName","traceIdExpression":"TraceId","spanIdExpression":"SpanId","durationExpression":"Duration","durationPrecision":9,"parentSpanIdExpression":"ParentSpanId","spanNameExpression":"SpanName","spanKindExpression":"SpanKind","statusCodeExpression":"StatusCode","statusMessageExpression":"StatusMessage","connection":"Local
70 ClickHouse","logSourceId":"Logs","sessionSourceId":"Sessions","metricSourceId":"Metrics"},{"from":{"databaseName":"default","tableName":""},"kind":"metric","timestampValueExpression":"TimeUnix","name":"Metrics","resourceAttributesExpression":"ResourceAttributes","metricTables":{"gauge":"otel_metrics_gauge","histogram":"otel_metrics_histogram","sum":"otel_metrics_sum","_id":"682586a8b1f81924e628e808","id":"682586a8b1f81924e628e808"},"connection":"Local
71 ClickHouse","logSourceId":"Logs","traceSourceId":"Traces","sessionSourceId":"Sessions"},{"from":{"databaseName":"default","tableName":"hyperdx_sessions"},"kind":"session","timestampValueExpression":"TimestampTime","name":"Sessions","displayedTimestampValueExpression":"Timestamp","implicitColumnExpression":"Body","serviceNameExpression":"ServiceName","bodyExpression":"Body","eventAttributesExpression":"LogAttributes","resourceAttributesExpression":"ResourceAttributes","defaultTableSelectExpression":"Timestamp,ServiceName,SeverityText,Body","severityTextExpression":"SeverityText","traceIdExpression":"TraceId","spanIdExpression":"SpanId","connection":"Local
72 ClickHouse","logSourceId":"Logs","traceSourceId":"Traces","metricSourceId":"Metrics"}]'
73 networks:
74 - internal
75 depends_on:
76 - ch-server
77 - db
78 ch-server:
79 image: clickhouse/clickhouse-server:24-alpine
80 # WARNING: Exposing the database port will make it accessible from outside the container,
81 # potentially allowing unauthorized access. If you uncomment the ports below,
82 # ensure to secure your database (e.g., with strong authentication, proper network rules, and firewalls).
83 ports:
84 - 8123:8123 # http api
85 - 9050:9000 # native
86 # environment:
87 # default settings
88 # CLICKHOUSE_DEFAULT_ACCESS_MANAGEMENT: 1
89 volumes:
90 - ./docker/clickhouse/local/config.xml:/etc/clickhouse-server/config.xml
91 - ./docker/clickhouse/local/users.xml:/etc/clickhouse-server/users.xml
92 - ./empty.xml:/etc/clickhouse-server/users.d/default-password.xml
93 - .volumes/ch_data:/var/lib/clickhouse
94 - .volumes/ch_logs:/var/log/clickhouse-server
95 restart: on-failure
96 networks:
97 - internal
98networks:
99 internal:

注意：environment 部分我注释掉了，另外加了一行：./empty.xml:/etc/clickhouse-server/users.d/default-password.xml 作用是解决 clickhouse 连接异常的问题。

通过 /data/clickhouse/hyperdx/docker/clickhouse/local/users.xml 可以看到 clickhouse 的账户信息：

 1<?xml version="1.0"?>
 2<clickhouse>
 3 <profiles>
 4 <default>
 5 <max_memory_usage>10000000000</max_memory_usage>
 6 <use_uncompressed_cache>0</use_uncompressed_cache>
 7 <load_balancing>in_order</load_balancing>
 8 <log_queries>1</log_queries>
 9 </default>
10 </profiles>
11
12 <users>
13 <default>
14 <password_sha256_hex>2d964690ad5ac2d2f78bebadc30895bc519969ffcef4d3c9e7ff04ee1c765d96</password_sha256_hex>
15 <profile>default</profile>
16 <networks>
17 <ip>::/0</ip>
18 </networks>
19 <quota>default</quota>
20 </default>
21 <api>
22 <password>api</password>
23 <profile>default</profile>
24 <networks>
25 <ip>::/0</ip>
26 </networks>
27 <quota>default</quota>
28 </api>
29 <worker>
30 <password>worker</password>
31 <profile>default</profile>
32 <networks>
33 <ip>::/0</ip>
34 </networks>
35 <quota>default</quota>
36 </worker>
37 </users>
38
39 <quotas>
40 <default>
41 <interval>
42 <duration>3600</duration>
43 <queries>0</queries>
44 <errors>0</errors>
45 <result_rows>0</result_rows>
46 <read_rows>0</read_rows>
47 <execution_time>0</execution_time>
48 </interval>
49 </default>
50 </quotas>
51</clickhouse>

密码用 sha256sum 处理过

可以这样生成：

1echo -n '你的密码' | sha256sum

运行

点击登录跳转至首页

客户端连接

用户名：default
密码：你的密码
端口：8123

数据库初始化

初始化 sql 脚本

 1/* 1. 创建数据库（如已存在可先 DROP DATABASE IF EXISTS testdb） */
 2CREATE DATABASE IF NOT EXISTS testdb;
 3
 4/* 2. 维度表：用户 */
 5CREATE TABLE IF NOT EXISTS testdb.users (
 6 user_id UInt32,
 7 user_name String,
 8 signup_date Date
 9) ENGINE = MergeTree
10ORDER BY user_id;
11
12/* 3. 维度表：页面 */
13CREATE TABLE IF NOT EXISTS testdb.pages (
14 page_id UInt32,
15 page_url String,
16 category String
17) ENGINE = MergeTree
18ORDER BY page_id;
19
20/* 4. 事实表：页面访问日志 */
21CREATE TABLE IF NOT EXISTS testdb.pageviews (
22 event_date Date,
23 event_time DateTime,
24 user_id UInt32,
25 page_id UInt32,
26 duration UInt32 -- 停留秒数
27) ENGINE = MergeTree
28PARTITION BY toYYYYMM(event_date)
29ORDER BY (event_date, user_id, page_id);
30
31/* 5. 物化视图：每日 PV / UV 聚合 */
32CREATE MATERIALIZED VIEW IF NOT EXISTS testdb.pv_uv_daily
33ENGINE = SummingMergeTree
34PARTITION BY toYYYYMM(event_date)
35ORDER BY event_date
36AS
37SELECT
38 event_date,
39 count() AS pv,
40 uniqExact(user_id) AS uv
41FROM testdb.pageviews
42GROUP BY event_date;
43
44/* 6. 演示数据插入 ---------------------------------------- */
45
46/* 用户维度 */
47INSERT INTO testdb.users (user_id, user_name, signup_date) VALUES
48 (1, 'Alice', '2024-06-01'),
49 (2, 'Bob', '2024-07-15'),
50 (3, 'Cathy', '2024-11-30');
51
52/* 页面维度 */
53INSERT INTO testdb.pages (page_id, page_url, category) VALUES
54 (10, '/home', 'landing'),
55 (11, '/pricing', 'info'),
56 (12, '/blog', 'content');
57
58/* 页面访问日志 */
59INSERT INTO testdb.pageviews (event_date, event_time, user_id, page_id, duration) VALUES
60 ('2025-07-13', '2025-07-13 09:17:00', 1, 10, 35),
61 ('2025-07-13', '2025-07-13 09:18:07', 1, 11, 50),
62 ('2025-07-13', '2025-07-13 09:19:02', 2, 10, 15),
63 ('2025-07-14', '2025-07-14 10:03:45', 3, 12, 120),
64 ('2025-07-14', '2025-07-14 10:05:22', 1, 12, 90);
65
66/* 7. 快速验证 --------------------------------------------- */
67
68/* 查看当前数据库已创建的表 */
69SHOW TABLES FROM testdb;
70
71/* 查询物化视图结果 */
72SELECT * FROM testdb.pv_uv_daily ORDER BY event_date;
73
74/* 联表查询示例 */
75SELECT
76 u.user_name,
77 p.page_url,
78 v.event_time,
79 v.duration
80FROM testdb.pageviews AS v
81LEFT JOIN testdb.users AS u ON v.user_id = u.user_id
82LEFT JOIN testdb.pages AS p ON v.page_id = p.page_id
83ORDER BY v.event_time DESC;

想要提高命令行编写效率，快来试试这几个快捷键！

Sat, 16 Nov 2024 11:18:48 +0000

最近看到一些同学在命令行写命令时的一些低效行为，比如长按左右箭头定位光标、长按 delete 删除字符等。其实只需要掌握几个常用的快捷键就能够大幅提高你写命令的效率。今天我们介绍几个常用的快捷键。

移动和删除

移动

ctrl + a : 可以直接将移动光标到命令行首
ctrl + e : 可以直接移动光标到命令行尾

ctrl + b : 光标向后移动一个字符
ctrl + f : 光标向前移动一个字符

alt + b : 光标向后移动一个单词
alt + f : 光标向前移动一个单词

删除

ctrl + u : 清除光标前的内容
ctrl + k : 清除光标后的内容

历史命令

只推荐一个：ctrl + r : 不但可以查找历史命令，还可以按字符串寻找历史命令

此外，历史命令查询还有一个更牛的命令行工具 fzf (https://github.com/junegunn/fzf)

它是一个交互式过滤程序，可过滤文件、命令历史记录、进程、主机名、书签、git 提交等类型

上文中关于 ctrl + r 的演示如果你在你的机器上尝试效果不一样，其实就是因为安装了 fzf ，是 fzf 带给我了更友好的交互体验。

许多高手都在用，有许多集成和增强的历史命令查询功能，非常牛！强烈推荐！

RAG 实践- Ollama+RagFlow 部署本地知识库

Tue, 18 Jun 2024 15:15:04 +0000

前言

上一篇文章我们介绍了如何利用 Ollama+AnythingLLM 来实践 RAG ，在本地部署一个知识库。借助大模型和 RAG 技术让我可以与本地私有的知识库文件实现自然语言的交互。

本文我们介绍另一种实现方式：利用 Ollama+RagFlow 来实现，其中 Ollama 中使用的模型仍然是Qwen2

我们再来回顾一下 RAG 常见的应用架构

RagFlow的安装和部署

前置条件

CPU >= 4 核
RAM >= 16 GB
Disk >= 50 GB
Docker >= 24.0.0 & Docker Compose >= v2.26.1

安装

克隆仓库

$ git clone https://github.com/infiniflow/ragflow.git

进入 docker 文件夹，利用提前编译好的 Docker 镜像启动服务器：

$ cd ragflow/docker $ chmod +x ./entrypoint.sh $ docker compose -f docker-compose-CN.yml up -d

这一步注意docker 下载的镜像比较大，要留有足够的存储空间，我这边观察下载了约 10 个 G 左右。

服务器启动成功后再次确认服务器状态:

$ docker logs -f ragflow-server

这里注意，安装完成后并不是要进入下面两个地址

http://127.0.0.1:9380
http://172.18.0.6:9380

而是要进入：http://localhost:80 先注册账号，是下面这个页面

注册登录

在上图的界面中注册，然后登录就来到下面这个页面了

配置 Ollama 连接大模型

如下图我们先配置模型，点击右上角头像，再点击模型提供商

这里我是想连接我本地已经安装部署好的 Ollama ，通过 Ollama 我安装了 Qwen2 大模型，具体的安装步骤在之前的那篇文章里，有需要的可以移步到那里看。

打开Ollama 后，我是通过服务器模式启动的大模型

ollama serve

当然你也可以选择其他平台和其他模型，需要提供 API key，API key 的获取就去你所选模型的网站，现在有很多模型的 API 是有免费额度的。

接着我们在 RagFlow 中配置模型，注意由于 RagFlow 我是在 docker 中安装的，所以请求本地部署的 Ollama 地址要用：http://host.docker.internal:11434

创建知识库

接下来我们就可以创建知识库了

注意这里的文件类型没有 markdown,但我实测 markdown 是可以的。其他的选项，根据你的情况自行设置就好，很简单。

接下来就是上传你的文件了，也比较简单，但我发现上传后文件处理的比较慢，应该是我电脑配置的原因

文件上传并处理完成后，可以通过检索测试看一下文件有没有被正确检索。

至此，如果你上传完成全部的文件，知识库就算创建完毕了。

聊天

接着就到了展示成果的时候了，我们可以根据自己的知识库与模型进行自然语言交互了。

首先注意，在聊天配置中要把 token 设置的大一些，不然回复的内容会很少！我这里把它拉到最大值了。

展示一下成果：

我觉得还算满意。但是由于我笔记本配置一般，也没有显卡支持，所以跑的很慢，真的很慢。但如果部署在有 GPU 的服务器上，企业私有化部署供内部使用，应该会比较快的。

思考

我这里的例子是用个人笔记本电脑上的资料做的个人知识库，对于文档的提问，无论是围绕着摘要总结来做，还是围绕着全文检索，答案看起来还行，也基本能用。但是这是面向个人的或者说面向 C 端，如果面向 B 端面向企业单靠向量检索就力不从心了，一来无法对精确信息召回，二来无法与企业内部信息系统集成（大量结构化数据）。所以必须在检索阶段引入多路召回和重排序，保证数据查询的准确度。

企业内部的数据包含各种格式，更复杂的还包含各类图表等，如果在没有理解这些语义的基础之上直接提供 RAG 方案，例如简单的根据文字空白就来切分段落，就会导致语义丢失从而让最终查询的结果也是混乱不堪。

如果解决这个问题呢，除了之前说的多路召回（多跳）和重排序这种方案，目前业界还有其他思路，比如 infiniFlow提出的 Infinity AI原生数据库（https://github.com/infiniflow/infinity）

从上图可以看到，AI原生数据库不仅涵盖非结构化的内容如文档和图片，也包括结构化的信息系统。对这些信息进行有效整合，并在此基础上实现多路召回机制和最终的融合排序解决方案。

此外，很多AI 产品的上下文现在是越来越长，可能有人会说现在上下文都这么长了，还用得着 RAG 吗？我认为，RAG在知识库问答场景依然是非常必要的。LLM 的长上下文能力，对于 RAG 来说应该是很大的促进。用 OpenAI 联创 Andrej Karpathy 的一张图做个类比，他把 LLM 比喻为一台计算机的 CPU，把上下文类比为计算机的内存，那么以向量为代表的数据库，就可以看作是这台计算机的硬盘

显然你不可能买一台只有内存的电脑。内存可以很大，但也意味着很贵，并且短时间内替代不了硬盘的作用。

最后是准确性问题，关于这个问题一般有两个方向的解决思路，一种是从 RAG 下手，比如做 Embedding 模型的微调。一种是从 LLM 下手，做 LLM 微调。虽然两种我都没真正做过，但从研读的资料上得知RAG系统在实时性和成本方面相较于LLM微调具有优势，因此更受青睐。这点跟我的直觉一致。

参考

git flow

Fri, 22 Mar 2024 08:52:42 +0000

一什么是 git flow

就像代码需要代码规范一样，代码管理同样需要一个清晰的流程和规范。Git 作为一个源码管理系统，不可避免涉及到多人协作。协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。“工作流程"在英语里，叫做"workflow"或者"flow”，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。

Gitflow 工作流定义了一个围绕项目发布的严格分支模型。下图能说明整个流程，该模式来自 Nvie

解释上图

master 默认分支，只能用来包括产品代码（线上生产环境代码），不许提交，只能合并。
develop 最新的开发状态，是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是_开发_的基础。另外，该分支也汇集所有已经完成的功能，并等待被整合到 master 分支中。develop 上的代码总是从 feature 上合并过来的。不许提交，只能合并。
master develop 这两个分支被称作为长期分支。它们会存活在项目的整个生命周期中，而其他的分支，例如针对功能的分支，针对发行的分支，仅仅只是临时存在的
feature 开发新功能的分支，基于 develop, 完成后 merge 回 develop
release: 准备要发布版本的分支，用来修复 bug. 基于 develop, 完成后 merge 回 develop 和 master
hotfix: 修复 master 上的问题，等不及 release 版本就必须马上上线。基于 master, 完成后 merge 回 master 和 develop
hotfix 分支是基于 “master” 分支。这也是和 release 分支最明显的区别，release 分支都是基于 “develop” 分支的

二为什么要使用 git flow

虽然大多数团队已由 svn 切换到 git，但代码控制方式仍然是“集中式”的，没有发挥 git 的强大功能。
在团队开发中使用版本控制系统时，商定一个统一的工作流程是至关重要的，git flow 有着清晰的流程和规范。
简单并可定义适合各自团队的 flow

三如何使用

初始分支，所有在 Master 分支上的 Commit 应该 Tag，目前只有 master 角色可提交，其它角色提交不了，被保护了

Feature 分支 Feature 分支做完后，必须合并回 Develop 分支，合并完分支后一般会删点这个 Feature 分支，但是我们也可以保留

Release 分支 Release 分支基于 Develop 分支创建，打完 Release 分之后，我们可以在这个 Release 分支上测试，修改 Bug 等。同时，其它开发人员可以基于开发新的 Feature （记住：一旦打了 Release 分支之后不要从 Develop 分支上合并新的改动到 Release 分支）发布 Release 分支时，合并 Release 到 Master 和 Develop，同时在 Master 分支上打个 Tag 记住 Release 版本号，然后可以删除 Release 分支了。

维护分支 Hotfix hotfix 分支基于 Master 分支创建，开发完后需要合并回 Master 和 Develop 分支，同时在 Master 上打一个 tag

四命令规范

| | | |


分支名称	规则	示例	说明
master
master	默认不可变
develop
develop	默认不可变
feature	feature_*	feature_order-detail	* 为功能简述，如多个单词，中间用横线连接
release	release_*.rc	release_1.0.1.rc	* 为版本号，版本号规则如下所述
hotfix	hotfix_*	hotfix_1.0.1	* 为版本号，版本号规则如下所述
tag	（对应项目名，全部大写拼写）_ tag _ V *	JARVISPMS_tag_V1.0.1	* 为版本号，版本号规则如下所述

大版本号更新表示一次里程碑开发的完成，包含了若干个 feature 的实现。
小版本号更新表示一个 feature 的完成。
补丁号更新表示发布的 feature 不变，只是修改 bug

举例：

某次发布是里程碑开发的结束，版本号为 1.0.0
很快，上次发布的版本发现了 bug，紧急修复，再次发布，版本号为 1.0.1
再次发现 bug，修复，重新发布，版本号为 1.0.2
几个星期后，新增了几个功能，再次发布，版本号为 1.1.0
几天后发现新增的功能有 bug，紧急修复，发布，版本号为 1.1.1
再次新增功能发布，版本号为 1.2.0
发现 bug，修复并发布，版本号为 1.2.1
再次完成一次里程碑开发，发布，版本号为 2.0.0
……以此类推

五 code review

由于使用了 git flow ，可以将 code review 机制很好的结合起来，当我们合并代码的时候，是需要 MR（merge request）的，这时候需要向代码审核人提交你的合并请求。具体流程可参考 GitLab Flow 里的最后一部分。

六使用 git flow 开发流程简述

从 develop 打 feature 分支，确定 feature 分支负责人（今后这个分支分出去的其它分支都由他负责，他负责 MR 时的代码评审）。
在 feature 分支上开发，如其它同事的其它 feature 分支合并回了 develop, 会要求通过大家。如需要（一般是公共影响部分）在你自己的 feature 分支上合并 develop 上的代码。
开发完 feature 分支代码，提交合并请求，合并至 develop, 由代码评审人评审通过后合并。合并完成后，删除 feature 分支。
提测前，从 develop 中打出 release 分支给测试使用，如测试通过不需要修改，则合并回 master 和 develop 并删除；如有问题，可以在 release 分支上修改，修改完毕后，再合并回 master,develop, 并删除 release 分支。
上线前，在 maser 分支上打出 tag
线上有 bug，从 master 打出 hotfix 分支修复，完成后，合并回 master 和 develop , 删除 hotfix 分支。

令人困惑的 git 术语

Thu, 30 Nov 2023 09:14:40 +0000

HEAD and “heads”

一些人表示他们对术语 HEAD 和 refs/heads/main 感到困惑

其实 “头”就是“枝”。在 git 内部，分支存储在名为 .git/refs/heads 的目录中

而 HEAD 是当前分支。它存储在 .git/HEAD 中。

“a head 是一个分支， HEAD 是当前分支” 这绝对是 git 中最奇怪的术语之一。

Your branch is up to date with ‘origin/main’

你的分支已更新为 ‘origin/main’ ?

此消息看起来很简单 - 它表示你的 main 分支已与源保持同步！

但这实际上有点误导。你可能认为这意味着你的 main 分支是最新的。事实并非如此。

它实际上意味着 – 如果你上次运行 git fetch 或 git pull 是在 5 天前，那么 5 天前你的 main 分支是最新的（包含 5 天前的所有更改）

说白了，只是上次同步过，但上一次是什么时候可不好说了，如果你没有意识到这一点，它可能会给您一种错误的安全感。

我认为 git 理论上可以给你一条更有用的消息，比如“截至 5 天前最后一次获取，源的 main 是最新的”

HEAD^, HEAD~ HEAD^^, HEAD~~, HEAD^2, HEAD~2

我知道 HEAD^ 指的是之前的提交，但我对 HEAD~ 和 HEAD^ 的区别困惑了很久。

我查了一下，以下是它们之间的关系：

HEAD^ 和 HEAD~ 是一样的（1 次提交前）
HEAD^^^ 和 HEAD~~~ 和 HEAD~3 是一样的（3 次提交前）
HEAD^3 指提交的第三个父级，与 HEAD~3 不同

这看起来很奇怪——为什么 HEAD~ 和 HEAD^ 是一样的？

“第三父级” 又是什么呢？

^ 和 ~ 在 Git 中用于导航提交树。

^ 用于访问合并提交的不同父提交
~ 用于访问当前提交的祖先提交

大多数提交只有一个父提交。在 Git 中 HEAD^ 表示“HEAD 提交的父级”。

但是如果 HEAD 是合并提交， HEAD^ 指的是合并的第一个父级， HEAD^2 是第二个父级， HEAD^3 是第三个父级，依此类推。

“

通常，这种语法在合并提交（merge commit）时使用，其中有多个父提交。例如，一个合并提交可能有两个父提交，通过 HEAD^1 和 HEAD^2 可以访问这两个父提交。HEAD^3 就表示第三个父提交。

”

HEAD~3：表示从 HEAD 开始往上数的第三个祖先提交。它指的是当前分支的前第三个提交，不考虑合并提交。这在查看历史记录时很有用。

“reset”, “revert”, “restore”

很多人提到 “reset”、“revert” 和 “restore” 是非常相似的词，很难区分它们。

手册也没有提供非常有用的信息：

git reset : “重置当前 HEAD 到指定状态”
git revert ：“恢复一些现有的提交”
git restore ：“恢复工作树文件”

以下是它们各自的作用的一些简短描述：

git revert COMMIT ：在当前分支上创建一个与 COMMIT “相反”的新提交（如果 COMMIT 添加了 3 行，则新提交将删除这 3 行）
git reset --hard COMMIT ：强制当前分支返回到 COMMIT 时的状态，删除自 COMMIT 以来的所有新更改。非常危险的操作。
git restore --source=COMMIT PATH ：将 PATH 中的所有文件恢复到 COMMIT 时的状态，而不更改任何其他文件或提交历史记录。

main 和 origin/main

在 Git 中，main 和 origin/main 分别表示不同的引用。

main：这是本地分支的名称，通常表示你当前所在的本地分支，例如，如果你切换到主分支，那么 main 就代表本地主分支。

git checkout main

这表示你正在引用本地仓库中的 main 分支。

origin/main：这是远程仓库的引用，通常表示远程主分支。origin 是默认的远程仓库名称，而 main 则表示在该远程仓库上的主分支。

git fetch origin git checkout origin/main

这表示你正在引用远程仓库 origin 上的 main 分支。请注意，你不能在 origin/main 上直接进行修改，因为它是只读的，你需要在本地分支上进行工作。

在典型的 Git 工作流中，你通常会从远程仓库克隆（clone）代码，本地会自动创建一个名为 main 的主分支，并在远程仓库上创建一个名为 origin/main 的引用。在进行协作开发时，你可能会通过 git pull 或 git fetch 来同步远程仓库的最新更改，这时就会涉及到本地的 main 分支和远程的 origin/main 引用。

checkout

git checkout BRANCH 切换分支
git checkout file.txt 放弃对 file.txt 的更改，恢复为上一次提交（最新提交）的版本。

checkout 后面跟分支名和文件名作用是不一样的，呵呵。

git checkout file.txt 这条命令的效果相当于取消对 file.txt 的本地修改，将其还原为最新提交的状态。不过，git checkout 在 Git 2.23 版本之后的版本中被 git restore 和 git switch 命令替代，因此你也可以使用以下等效的命令：

# 使用 git restore git restore file.txt # 或者使用 git switch git switch --discard-changes file.txt

Make Jar, Not War.

Tue, 05 Jul 2022 09:51:29 +0000

大约在 4 年前，关于 java 应用最终打成 jar 包还是 war 包的选择令我比较疑惑。

那时候更多的应用是打成 war 包的，即使我们知道可以打成 jar 包，但之前都是打成 war 包，并且好像打成 jar 包并没有什么特别明显的好处。

但当时令我困惑的是越来越多的实践正在不怎么说明理由的情况下转而打 jar 包，于是我开始思考……

war 包的理由

在某大型 OTA 企业内部，应用仍然打成 war 包, PaaS 平台会自动安装并配置好 tomcat，我知道这对于 web server 的统一配置和运维来说是有好处的。基于 war 背后的一系列 CI/CD 、DevOps 流程都一定有相应的适配，且就算 jar 包有我不知道的某些优势也不可能一夜之间在大型企业内部使用，需要平台和系统做出调整。

SpringBoot 在当时并未像现在这样流行，这并不意味着大家不用它，我的意思是相对新的项目来说，企业内部会有非常多 “老系统” 需要维护，我们不能指望一下子把这些老系统都用新的技术栈替换掉，就像你知道现在 web application 一般是前后端分离开发，但如果接手一个使用 jsp 的老家伙，你还得维护不是？

jar 的时代

时代不同了，说得好像过了几十年的样子，但其实也就几年光阴而已。不过仅仅是这几年的光阴却足以改变一些事情的面貌。

如今，云原生、微服务大行其道，大家好像已经非常适应这种开发模式，没有人纠结要不要用 SpringBoot，只会讨论使用的版本高还是低。更不用说打包的事情，很自然的会使用 jar,虽然这种看起来的 “最佳实践”，在长期开发的过程中会形成 “肌肉记忆”，但我们还是要讨论一下为什么。

方便

可运行 Jar 是打包自包含可运行应用程序的便捷方法。这样，我们可以最大限度地减少依赖关系。可以通过 Spring boot Maven 和 Gradle plugin 来管理依赖。

云原生友好

在自备容器的情况下（docker,k8s), jar 包可以直接作为一个 single application 来管理。

在过去我们使用 war 是为了让多应用共享 web server，现在是容器的天下，在容器内，一般情况只跑一个应用进程。由于只有一个进程，我们就可以轻松地管理它，比如重启（不会影响其他的应用，因为没有其他应用）。

版本控制

利用 git 等版本控制软件，可以控制程序运行所需要的一切（比如配置文件）

易于扩展

例如，将其复制到另一台服务器，然后“ just run it!” 无需安装和/或配置容器

参考

https://medium.com/@satyajit.nalavade/make-jar-not-war-josh-long-d6ce5fbb8a23

扒一下一直不求甚解的 iptables

Wed, 01 Sep 2021 10:00:28 +0000

基本概念

iptables 是什么？

在 netfilter 的官网找到的如下解释：

“

iptables is the userspace command line program used to configure the Linux 2.4.x and later packet filtering ruleset. It is targeted towards system administrators.

Since Network Address Translation is also configured from the packet filter ruleset, iptables is used for this, too.

The iptables package also includes ip6tables. ip6tables is used for configuring the IPv6 packet filter.

”

iptables 是用于配置 Linux 2.4.x 及更高版本包过滤规则集的用户空间命令行程序。它针对系统管理员。
由于网络地址转换 (NAT) 也是从包过滤规则集配置的，iptables 也用于此。
iptables 包还包括 ip6tables。ip6tables 用于配置 IPv6 包过滤器。

iptables 源码地址：https://git.netfilter.org/iptables

netfilter 是什么？

来自维基百科的解释：

“

netfilter，在 Linux 内核中的一个软件框架，用于管理网络数据包。不仅具有网络地址转换（NAT）的功能，也具备数据包内容修改、以及数据包过滤等防火墙功能。利用运作于用户空间的应用软件，如 iptables、nftables、ebtables 和 arptables 等，来控制 netfilter，系统管理者可以管理通过 Linux 操作系统的各种网络数据包。1990 年代，netfilter 在 Linux 2.3.15 版时进入 Linux 内核，正式应用于 Linux 2.4 版。

”

netfilter 的主要功能包括：

网络地址转换 (Network Address Translate)
数据包内容修改
以及数据包过滤的防火墙功能

linux 的绝大多数功能都是以模块的形式扩充出来的，netfilter 也是以模块的形式存在于 linux 中，当 linux 多了一个 netfilter 模块，linux 防火墙功能也就多了一项。

netfilter 本身并不对数据包进行过滤，它只是允许过滤的数据包的函数挂接到内核中合适的位置。netfilter 项目在内核中还提供了一些基础设施，比如链接跟踪和日志记录，任何 iptables 策略都可以使用这些设施来执行特定数据包的处理。

netfilter 模块存放的目录：

/lib/modules/<uname -r>/kernel/net/ipv4/netfilter/
/lib/modules/<uname -r>/kernel/net/ipv6/netfilter/

不仅是 netfilter 有模块，iptables 也有模块，这些模块就位于/lib64/xtables/(32bit 系统在/lib/xtables/) 目录下，其中以 libxt 开头的是 iptables 模块，这些模块与 netfilter 模块是一一相对应的。例如/lib/modules/<uname -r>/kernel/net/netfilter/xt_conntrack.ko模块，在/lib64/xtables/libxt_conntrack.so与之相对应。当下达与 xt_conntrack.ko 相关的指令时，iptables 会根据 libxt_conntrack.so 模块的指示去检查语法是否正确。并将 netfilter 相应模块载入到系统内存，iptables 最后将规则写入到规则数据库中。

netfilter 和 iptables 是什么关系？

在很多场景下，大家用 iptabes 配置防火墙规则，而实际上 iptables 其实不是真正的防火墙，我们可以把它理解成一个客户端代理，用户通过 iptables 这个代理，将用户的安全设定执行到对应的”安全框架”中，这个”安全框架”才是真正的防火墙，这个框架的名字叫 netfilter

netfilter 才是防火墙真正的安全框架（framework），netfilter 位于内核空间。
iptables 其实是一个命令行工具，位于用户空间，我们用这个工具操作真正的框架。

iptables 基础概念

链

iptables 在普遍的应用场景中被用作配置防火墙，如果我们想要防火墙能够达到”防火”的目的，则需要在内核中设置关卡，所有进出的报文都要通过这些关卡，经过检查后，符合放行条件的才能放行，符合阻拦条件的则需要被阻止，于是，就出现了 input 关卡和 output 关卡，但是，这个关卡上可能不止有一条规则，而是有很多条规则，当我们把这些规则串到一个链条上的时候，就形成了”链”。

总结下 5 链：

PREROUTING 数据包刚进入网络层 , 路由之前
INPUT 路由判断，流入用户空间
OUTPUT 用户空间发出，后接路由判断出口的网络接口
FORWARD 路由判断不进入用户空间，只进行转发
POSTROUTING 数据包通过网络接口出去

根据实际情况的不同，报文经过”链”可能不同。如果报文需要转发，那么报文则不会经过 input 链发往用户空间，而是直接在内核空间中经过 forward 链和 postrouting 链转发出去的。

所以，根据上图，我们能够想象出某些常用场景中，报文的流向：

到本机某进程的报文：PREROUTING –> INPUT
由本机转发的报文：PREROUTING –> FORWARD –> POSTROUTING
由本机的某进程发出报文（通常为响应报文）：OUTPUT –> POSTROUTING

每个经过这个”关卡”的报文，都要将这条”链”上的所有规则匹配一遍，如果有符合条件的规则，则执行规则对应的动作。

表

为什么称为 ip"tables" 呢？因为这个防火墙软件里面有多个表格 (table) ，每个表格都定义出自己的默认政策与规则，且每个表格的用途都不相同。每个“表”指的是不同类型的数据包处理流程。

预设的情况下，Linux 的 iptables 至少就有三个表。

表链关系

每个”链”上都放置了一串规则，但是这些规则有些很相似，比如，A 类规则都是对 IP 或者端口的过滤，B 类规则是修改报文。我们是不是能把实现相同功能的规则放在一起呢？可以的，我们把具有相同功能的规则的组成一个集合，也就是上文说的“表”。

iptables 为我们提供了如下规则的分类，或者说，iptables 为我们提供了如下”表”

filter 表：负责过滤功能，防火墙；内核模块：iptables_filter
nat 表：network address translation，网络地址转换功能；内核模块：iptable_nat
mangle 表：拆解报文，做出修改，并重新封装的功能；iptable_mangle
raw 表：关闭 nat 表上启用的连接追踪机制；iptable_raw

我们自定义的所有规则，都是这四种分类中的规则，或者说，所有规则都存在于这 4 张”表”中

具体来说：

链	表
PREROUTING 的规则可以存在于	raw 表，mangle 表，nat 表。
INPUT 的规则可以存在于	mangle 表，filter 表，（centos7 中还有 nat 表，centos6 中没有）
FORWARD 的规则可以存在于	mangle 表，filter 表。
OUTPUT 的规则可以存在于	raw 表 mangle 表，nat 表，filter 表。
POSTROUTING 的规则可以存在于	mangle 表，nat 表。

我们在实际的使用过程中，往往是通过”表”作为操作入口，对规则进行定义的，之所以按照上述过程介绍 iptables，是因为从”关卡”的角度更容易从入门的角度理解，但是为了以便在实际使用的时候，更加顺畅的理解它们，此处我们还要将各”表”与”链”的关系罗列出来：

表（功能）	链（钩子）：
raw	表中的规则可以被哪些链使用：PREROUTING，OUTPUT
mangle	表中的规则可以被哪些链使用：PREROUTING，INPUT，FORWARD，OUTPUT，POSTROUTING
nat	表中的规则可以被哪些链使用：PREROUTING，OUTPUT，POSTROUTING（centos7 中还有 INPUT，centos6 中没有）
filter	表中的规则可以被哪些链使用：INPUT，FORWARD，OUTPUT

优先级

数据包经过一个”链”的时候，会将当前链的所有规则都匹配一遍，但是匹配时总归要有顺序，我们应该一条一条的去匹配，而且相同功能类型的规则会汇聚在一张”表”中，哪些”表”中的规则会放在”链”的最前面执行呢？这时候就需要有一个优先级的问题

优先级次序（由高而低）：

raw –> mangle –> nat –> filter

数据经过防火墙的流程

规则

规则：根据指定的匹配条件来尝试匹配每个流经此处的报文，一旦匹配成功，则由规则后面指定的处理动作进行处理；

规则由匹配条件和处理动作组成。

匹配条件

匹配条件分为基本匹配条件与扩展匹配条件

基本匹配条件：源地址 Source IP，目标地址 Destination IP 上述内容都可以作为基本匹配条件。
扩展匹配条件：除了上述的条件可以用于匹配，还有很多其他的条件可以用于匹配，这些条件泛称为扩展条件，这些扩展条件其实也是 netfilter 中的一部分，只是以模块的形式存在，如果想要使用这些条件，则需要依赖对应的扩展模块。源端口 Source Port, 目标端口 Destination Port 可以作为扩展匹配条件

处理动作

处理动作在 iptables 中被称为 target（这样说并不准确，我们暂且这样称呼），动作也可以分为基本动作和扩展动作。此处列出一些常用的动作，之后的文章会对它们进行详细的示例与总结：

ACCEPT：允许数据包通过。
DROP：直接丢弃数据包，不给任何回应信息，这时候客户端会感觉自己的请求泥牛入海了，过了超时时间才会有反应。
REJECT：拒绝数据包通过，必要时会给数据发送端一个响应的信息，客户端刚请求就会收到拒绝的信息。
SNAT：源地址转换，解决内网用户用同一个公网地址上网的问题。
MASQUERADE：是 SNAT 的一种特殊形式，适用于动态的、临时会变的 ip 上。
DNAT：目标地址转换。
REDIRECT：在本机做端口映射。
LOG：在/var/log/messages 文件中记录日志信息，然后将数据包传递给下一条规则，也就是说除了记录以外不对数据包做任何其他操作，仍然让下一条规则去匹配。

DROP 和 REJECT 的区别：DROP 是直接把匹配到的报文丢弃，REJECT 除了把报文丢弃还会给该报文中的源 IP 发一个 ICMP 报文说明目的不可达（直接回复不可达，更强硬）。前者报文发送方只能等超时，而后者发送方因为收到了 ICMP 不可达所以马上就给出了提示。

参考

https://www.zsythink.net/archives/1199
https://borosan.gitbook.io/lpic2-exam-guide/2121-configuring-a-router
http://cn.linux.vbird.org/linux_server/0250simple_firewall_3.php
https://www.xiebruce.top/1071.html
http://kuring.me/post/iptables/

Git on 小盒子的技术分享

Postman 越来越臃肿了，我换了个开源的，还能让 AI 帮我写测试

全程0人工写代码！干掉低级码农的不是大模型

全程0人工写代码！干掉低级码农的不是大模型

1 极致标准化的预热沙盒（Devboxes）

2 “蓝图”编排（Blueprints）：将大模型装进确定性的盒子里

3 极其克制的上下文投喂：规则文件与 Toolshed

4 反馈左移（Shifting Feedback Left）：极速纠错循环

给我的启示

参考

Claude 新王牌 “Skills” 深度解析：让你的 AI 秒变行业专家，告别重复劳动

TLDR

Claude Skills 的定位

Skills 工作原理

一个 Skill 就是一个包含指令的简单文件夹

Claude 会自动发现并加载相关的 Skill

“渐进式披露” 机制使 Skills 极为高效

Skills 可包含代码以确保任务执行的可靠性

应用平台：Skills 可跨所有 Claude 产品使用

应用场景：Skills 擅长自动化内部工作流

Skills 与模型上下文协议（MCP）的关键区别

快速上手：用一个简单的 Markdown 文件创建你的第一个 Skill

安全须知：使用第三方 Skills 时需保持谨慎

Skills 使 AI 更实用、更具组合性

对产品与组织的启示

思维方式的转变

附录

快速安装 ClickHouse

概述

安装

克隆 HyperDX 仓库

docker compose 启动

运行

客户端连接

数据库初始化

想要提高命令行编写效率，快来试试这几个快捷键！

移动和删除

移动

删除

历史命令

RAG 实践- Ollama+RagFlow 部署本地知识库

前言

RagFlow的安装和部署

前置条件

安装

注册登录

配置 Ollama 连接大模型

创建知识库

聊天

思考

参考

git flow

一 什么是 git flow

二 为什么要使用 git flow

三 如何使用

四 命令规范

五 code review

六 使用 git flow 开发流程简述

令人困惑的 git 术语

HEAD and “heads”

Your branch is up to date with ‘origin/main’

HEAD^, HEAD~ HEAD^^, HEAD~~, HEAD^2, HEAD~2

“reset”, “revert”, “restore”

main 和 origin/main

checkout

Make Jar, Not War.

war 包的理由

jar 的时代

方便

云原生友好

版本控制

易于扩展

参考

扒一下一直不求甚解的 iptables

基本概念

iptables 是什么？

netfilter 是什么？

netfilter 和 iptables 是什么关系？

iptables 基础概念

链

一什么是 git flow

二为什么要使用 git flow

三如何使用

四命令规范

六使用 git flow 开发流程简述