工具与效率 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

如何在 mac 的 chrome 中开启 gemini 侧边栏

Sat, 31 Jan 2026 02:03:30 +0000

昨天折腾了半天，厕所都没上，没搞定，今天一分钟搞定了，其实非常简单。

前提条件什么的自不用说，主要是两步，我是 mac 系统，windows 的不知道。

第一步

把语言设置一下，注意是在操作系统中设置chrome 的自定义语言

第二步

打开终端，输入以后命令后回车

⚡ 代码片段open -n -a "Google Chrome" --args --variations-override-country=us

也可以用这个项目设置一下：https://github.com/lcandy2/enable-chrome-ai

然后重启 chrome 就可以了，location 如果不支持，你应该知道怎么办吧，哈哈。

Modern MD Editor 项目介绍

Sat, 16 Aug 2025 03:45:30 +0000

感谢

自 mdeditor 项目开源以来，陆续收到了大家的许多反馈，有提建议的、有提 bug 的，每一条评论我都认认真真地看了。

项目也得到了阮一峰大佬的 科技爱好者周刊 的支持，在最新的一期周刊（https://github.com/ruanyf/weekly/blob/master/docs/issue-361.md）进行了推荐

开源一周目前项目在 github 上也获得了 160+ star

非常感谢大家对项目的关注和支持。 🙏

回复疑问

在上篇文章的评论中很多网友说为什么不多介绍一下项目，哪怕放一张图出来?

其实这与我做这个项目的初衷有关系。

初衷

我是个开发者，同时也是内容创作者，平时会写公众号文章，文章内容是用 markdown 写的。目前市面上比较流行好用的 markdown 编辑器都用过，后来就只用 mdnice 和 md 这些了，因为他们对社交媒体友好，可以将预设的样式一键 copy 到微信公众号，很方便。

但这些工具我用的时间久了觉得总是不如我的意，比如我想设置颜色、间距、字号什么的，这些工具用起来总是不顺手。无论是 UI 样式还是功能设置，我都不那么满意，于是就越来越想做个让自己舒服、满意的工具。

这就是做这个项目的初衷，完全为了服务我自己，完全按照我自己的审美和功能取向来设计与开发的一个 markdown 编辑器。

开源的原因是我想可能也会有其他创作者有我类似的需求，也许能解决大家的问题就开源了，便人便已。

最开始也真没当回事儿，而且不想占太大篇幅来宣传，现在网上的信息太多了，很多人都信息过载，我想我就别添乱了，就没放图，也没怎么详细介绍。还有个原因是，其实项目的 readme 写的很清楚了，大家一看便知。

有必要展开说说

这几天随着关注项目的人数增多，通过大家反馈的意见，我觉得还是有必要再详细介绍一下项目。主要原因有以下几个：

●很多网友访问不了 github，看不到介绍（目前我也同步到了 gitee 一份，文末有地址）

●一图胜千言，颜值党很关注 UI

●一些在 readme 没说透的话，可以再细说说

所以，我借此机会就给大家展开介绍一下，如果已经了解过项目的朋友可以跳过了。

功能介绍

主界面

编辑 + 预览双栏

除了常规的 markdown 语法外，还支持 mermaid

预览窗口（桌面 / 平板 / 手机）

设置

设置页面目前可以设置的项目有：

●主题系统

●主题色

●代码样式

●字体

●字号

●间距

主题系统

目前有两个主题系统，一个是默认的，一个是 清风排版 ，我个人最喜欢后者，后续我将开发更多的主题系统，每个主题系统都是一套完全不同的样式风格。

主题色

预设了 8 个主题色

也可以自定义设置颜色

也支持 color picker,除了内置颜色，可以选取你看到的任何颜色

颜色选择并应用后，整个系统页面和 markdown 编辑器样式都会被应用，有一种统一感。

代码样式

预设了四种我喜欢的、常规的样式

字体

字体的选择如图所示

字号

可以从小到大，方便地选择你需要的字号大小，应用后在预览页以及复制到公众号以后都会变化

间距

与字号设置类似，支持字间距和行间距

一键复制

支持一键复制到微信公众号

安装和部署

Docker 一键部署

方式一：Docker（推荐最简）

1$ terminal# 拉取并运行（默认暴露到本机 8080）
2docker run -d --name mdeditor -p 8080:80 helongisno1/mdeditor:latest
3
4# 访问
5open http://localhost:8080

方式二：Docker Compose

 1$ terminalversion: "3.9"
 2services:
 3 mdeditor:
 4 image: helongisno1/mdeditor:latest
 5 ports:
 6 - "8080:80"
 7 restart: unless-stopped
 8
 9$ terminaldocker compose up -d
10open http://localhost:8080

安装与本地运行

 1$ terminal# 克隆
 2git clone https://github.com/xiaobox/mdeditor.git
 3cd modern-md-editor
 4
 5# 安装依赖（任选其一）
 6npm install
 7# 或
 8yarn
 9# 或
10pnpm install
11
12# 本地开发
13npm run dev
14
15# 生产构建
16npm run build
17
18# 本地预览构建产物
19npm run preview
20
21# 测试（可选）
22npm run test
23npm run test:ui
24npm run test:coverage

后续规则

目前是想先把大家关注的一些功能做完，比如：

●所见即所得

●导入导出

当然还有 bug 修复，大家如果有类似 bug 或功能方面的意见，欢迎到 github 中提 issue

补充信息

Modern MD Editor 是一款面向创作者与内容团队的「高颜值 Markdown 编辑器 + 社交平台发布器」。它以极致的界面与交互为基础，提供所见即所得的实时预览与多端视口切换，并通过一键复制将 Markdown 转为适配微信公众号/社交平台的高保真富文本（自动内联样式、字体/行高/字距与主题化适配），让创作到发布的最后一步变得优雅、高效、可控。

项目地址

平台	地址
GitHub	https://github.com/xiaobox/mdeditor
Gitee	https://gitee.com/xiao-box/mdeditor

嘿，朋友，做了个 Markdown 编辑器，想请你来试试

Sun, 10 Aug 2025 08:49:50 +0000

大家好，我是小盒子。

写了快十五年代码，从当年的 Dreamweaver、FrontPage 一路玩到现在的 VS Code、JetBrains 全家桶。工具换了一茬又一茬，但有件事一直没变：我们总得写东西。写文档、写博客、写笔记，而 Markdown，就是我们这群人的“笔”。

说实话，市面上的 Markdown 编辑器，我用过的没有一百也有八十。但用着用着，总有点别扭。就像一把用了很久的锤子，总感觉重心不太对，握着也不够舒服。

不知道你有没有同感：

●有些编辑器，功能强大，但打开它就像启动了一艘星际战舰，吃内存、慢吞吞，打个字都感觉有延迟，写长文更是煎熬。

●有些呢，又太“极简”了，干净是干净，可连个基本的字体、行间距都不能调，总感觉是在将就，而不是享受。

●最关键的是，它们都是“别人”的工具。我们开发者，总有点小小的控制欲，总想让工具能完完全全地贴合自己的习惯。

就因为这些“别扭”，前段时间，我干脆撸起袖子，决定给自己、也给和我有同样困扰的朋友们，做一把“趁手的兵器”。

于是，mdeditor 就这么诞生了。

它没啥宏大的目标，初心很简单：做一款快、好用，而且能让你觉得“这是我的编辑器”的工具。

代码都在这儿了，开诚布公，欢迎随时来坐坐：

**GitHub:**https://github.com/xiaobox/mdeditor

（要是觉得还行，顺手点个 Star，就是对我最大的肯定。）

这把“锤子”，我花了些心思去打磨

我不想只做个“能用”的工具，我希望它能“好用”，甚至让你“爱用”。所以，我在几个自己最看重的地方下了点功夫。

1. 首先，它得听你的话：真正意义上的“深度定制”

我始终觉得，工具应该适应人，而不是人去适应工具。所以，我给了 mdeditor 一套非常彻底的定制系统。

你可以像装修自己家一样，去“装修”你的编辑器。从整体的界面风格，到每一个按钮、每一行代码的颜色，再到你习惯的字体和阅读排版……所有这些，都由你掌控。你完全可以把它调校成你最舒服、最高效的样子。对我来说，这是一种底层的安全感。

2. 其次，性能是基本功：绝不拖泥带水

一个编辑器，快，是本分。为了这个“快”字，我放弃了几个现成的轮子，自己写了 Markdown 解析的核心。这么做的好处是，mdeditor 的响应速度非常跟手，无论是打字、滚动还是处理几万字的大文件，都能保持流畅。写东西就该行云流水，不应该被工具打断思路。

3. 最后，是给开发者朋友的“彩蛋”：一个干净的架构

mdeditor 是用 Vite + Vue 3 写的，代码组织上遵循了最朴素的“高内聚、低耦合”原则。如果你也玩 Vue，可以看看源码。我把很多功能逻辑都抽离成了独立的 Composables，整个项目的结构清晰明了，很适合拿来做二次开发，或者作为学习 Vue 3 Composition API 的一个实践参考。

这只是个开始

想邀请你一起来添砖加瓦

现在 mdeditor 已经有了一个不错的底子，但它离“完美”还差得很远。一个人的力量终究有限，一个好的开源项目，生命力在于社区。

所以，我诚心地邀请你，无论你是谁，都可以来参与这件事：

●如果你只是想找个好用的工具：欢迎你下载使用。你的使用本身，就是对它最好的检验。如果能顺手在 GitHub 上点个 Star，我会非常开心。

●如果你和我一样，是个爱折腾的开发者：欢迎你来读它的源码，给我提 Issue，或者直接甩个 PR 过来。无论是发现一个 Bug，还是有个绝妙的点子，都请不要吝啬。

●如果你是位设计师，对 UI/UX 有自己的见解：欢迎你来设计新的主题，或者对现有的交互提出建议。你的审美，能让它变得更美。

一个优秀的开源项目，就像一场漫长的篝火晚会，需要不断有人添柴，才能一直燃烧下去。

mdeditor 就是我点起的第一根火柴。

好了，就说这么多。感谢你耐心听我这个老家伙唠叨。

如果你对 mdeditor 有一点点兴趣，就去 GitHub 看看吧。期待在那里，看到你的身影。

GitHub传送门：https://github.com/xiaobox/mdeditor

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

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 带给我了更友好的交互体验。

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

HTML 中的


分支名称	规则	示例	说明
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	* 为版本号，版本号规则如下所述

工具与效率 on 小盒子的技术分享

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

如何在 mac 的 chrome 中开启 gemini 侧边栏

第一步

第二步

Modern MD Editor 项目介绍

感谢

回复疑问

初衷

有必要展开说说

功能介绍

主界面

编辑 + 预览双栏

预览窗口（桌面 / 平板 / 手机）

设置

主题系统

主题色

代码样式

字体

字号

间距

一键复制

安装和部署

Docker 一键部署

方式一：Docker（推荐最简）

方式二：Docker Compose

安装与本地运行

后续规则

补充信息

项目地址

嘿，朋友，做了个 Markdown 编辑器，想请你来试试

这把“锤子”，我花了些心思去打磨

这只是个开始

想邀请你一起来添砖加瓦

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

移动和删除

移动

删除

历史命令

什么是 <template> 元素？

为什么使用 <template> 元素？

如何使用 <template> 元素？

实际应用中的例子

浏览器支持情况

为什么不使用隐藏元素？

总结

无损图像格式比较：PNG、WebP、AVIF 和 JPEG XL

什么是无损压缩？

何时使用无损压缩？

PNG

WebP

AVIF

JPEG XL JPEGXL

对比结果

文件大小

编码速度

总结

png

webp

AVIF

JPEG XL

bash 为什么叫 bash？

回顾

bash 名字的由来

shell

bash

Bourne Shell

总结

git flow

一 什么是 git flow

二 为什么要使用 git flow

三 如何使用

四 命令规范

五 code review

六 使用 git flow 开发流程简述

我有罪啊--用了这么多年 mac 不知道访达有标签页

什么是 `<template>` 元素？

为什么使用 `<template>` 元素？

如何使用 `<template>` 元素？

一什么是 git flow

二为什么要使用 git flow

三如何使用

四命令规范

六使用 git flow 开发流程简述