1. 项目概述：一个为开发者打造的智能记忆助手

最近在GitHub上看到一个挺有意思的项目，叫 zero8dotdev/smriti 。光看名字，可能有点摸不着头脑， smriti 这个词源自梵语，有“记忆”、“回忆”的意思。点进去一看，果然，这是一个为开发者量身定制的智能记忆助手。它的核心目标很简单，却直击痛点： 帮你记住那些你曾经知道，但一时半会儿想不起来的代码片段、命令、配置，甚至是某个复杂问题的解决思路。

作为写了十几年代码的老兵，我太懂这种感受了。你肯定遇到过这种情况：上周刚解决了一个诡异的 Docker 网络问题，用了一串精妙的 iptables 命令配合 docker network inspect 才搞定。这周类似问题又来了，你只记得“好像是改了个什么规则”，具体命令怎么敲的？参数顺序是什么？全忘了。或者，三个月前你为项目写过一个非常优雅的 Python 装饰器来处理日志和异常，现在新项目需要类似功能，你只记得“用了个装饰器”，具体实现细节却一片模糊。传统的做法是，要么在本地建一堆乱七八糟的 txt 文件，要么在笔记软件里记录，但检索起来效率极低，上下文也容易丢失。

Smriti 就是为了解决这个问题而生的。它不是一个简单的笔记应用，而是一个 命令行优先、上下文感知、支持自然语言检索的开发者知识库 。你可以把它想象成你终端里的一个“第二大脑”，专门用来存储和召回那些碎片化但至关重要的技术知识。它通过 AI 嵌入技术，将你保存的代码片段、命令、笔记（统称为“记忆”）转化为向量，存储在本地的向量数据库中。当你需要回忆时，直接用自然语言描述你的问题，比如“如何清理 Docker 占用的磁盘空间”，它就能从你的历史记忆中，找到最相关的内容呈现给你，并且会附上当时的上下文（比如是在哪个项目目录下执行的、相关的文件是什么等）。

这个项目特别适合那些日常工作在终端里、项目多、技术栈杂的中高级开发者、运维工程师和系统管理员。它不追求大而全，而是聚焦于提升开发者在具体工作场景下的信息检索效率，把个人经验真正转化为可随时调用的资产。

2. 核心设计思路与技术选型解析

2.1 为什么是命令行工具（CLI）？

Smriti 选择以 CLI 作为主要交互界面，这是一个非常务实且高效的设计决策。开发者的核心工作流大量集中在终端。无论是写代码、构建、测试还是部署，终端是离“战场”最近的地方。当你在调试一个 Kubernetes Pod 启动失败的问题时，思路是连贯的，你需要在终端里不断尝试命令、查看日志。如果此时记忆的保存和检索需要你切出终端，打开一个 Web 页面或 GUI 应用，再手动分类、打标签，这个流程就被打断了，认知负担很重，很多人最终会选择放弃记录。

CLI 工具完美地嵌入了这个工作流。想象一下这个场景： 

# 你刚刚解决了一个复杂问题
$ kubectl logs -f pod/my-app-xyz --tail=50 | grep -A 10 -B 5 “Connection refused”
# 发现是服务发现的问题，经过一番排查，最终通过修改配置解决
# 此时，你可以立刻将这段“战斗经验”保存下来
$ smriti add --content “问题：新部署的Pod无法连接核心服务A，日志报Connection refused。原因：服务A的K8s Service名在新命名空间中被错误覆盖。解决：检查并修正service的selector标签，确保与Pod的label匹配。” --tags “kubernetes, networking, service-discovery”

整个过程在几秒钟内完成，无需离开终端。检索时也同样方便： $ smriti find “pod连不上服务怎么办” 。这种“所想即所得”的流畅感，是 GUI 工具难以提供的。

2.2 本地化与隐私优先的架构

在 AI 时代，数据隐私是开发者非常敏感的一点。 Smriti 采用了彻底的本地化架构，这是它的另一个关键优势。所有“记忆”数据、生成的向量嵌入（ Embeddings ），都存储在你自己的机器上，通常是 ~/.smriti 目录下。它使用的向量数据库（如 ChromaDB 或 LanceDB ）也是本地运行的。

这意味着：

  1. 绝对的数据控制权 ：你的所有代码片段、内部命令、服务器配置、故障排查记录，都不会离开你的设备。这对于处理公司内部项目、涉及敏感信息的操作记录至关重要。
  2. 离线可用 ：在没有网络的环境下（比如在飞机上、某些隔离的开发环境），你依然可以检索你所有的历史记忆。
  3. 零成本 ：不需要为 API 调用（如 OpenAI 的嵌入接口）付费，也没有使用量限制。

为了实现本地 AI 能力， Smriti 需要依赖一个本地运行的嵌入模型。它通常会集成像 all-MiniLM-L6-v2 这类轻量级但效果不错的开源模型。虽然这些模型在理解能力的深度上可能略逊于 GPT-4 等大型商用模型，但对于代码片段、命令和技术笔记的语义相似度计算，已经完全够用，且推理速度在本地 CPU 上也能接受。

2.3 上下文感知：不仅仅是文本

一个优秀的记忆系统，必须能还原记忆的“场景”。 Smriti 在保存记忆时，会自动捕获丰富的上下文元数据（ Metadata ），这大大提升了后续检索的准确性和实用性。这些元数据可能包括：

  • 工作目录（ CWD ） ：这条记忆是在哪个项目路径下产生的？这对于项目特定的配置、脚本尤其重要。
  • Git 信息 ：当前所在的 Git 分支、最近的提交 Hash 。这能帮你将记忆与特定的代码版本关联起来。
  • 时间戳与命令历史 ：自动记录保存时间，并可选择关联触发此次保存的前几条终端命令。
  • 自定义标签 ：用户可以通过 --tags 手动添加标签，进行粗粒度分类。

当你检索时，这些元数据会一并展示。例如，你搜索“如何配置 Nginx 反向代理 WebSocket ”，返回的结果不仅会显示你曾经记录的配置片段，还会告诉你：“这是你在2023年10月，在 ~/projects/chat-app 目录下， deploy 分支上记录的。” 这种场景还原能力，能瞬间激活你更多的关联记忆。

3. 从零开始部署与配置 Smriti

3.1 环境准备与安装

Smriti 是一个 Rust 项目，这保证了其出色的性能和跨平台能力。安装方式非常灵活。

对于大多数用户，最推荐的方式是通过 Cargo （Rust的包管理器）安装： 

# 确保已安装Rust工具链（rustc, cargo）
$ cargo install smriti

这条命令会从 crates.io 下载、编译并安装最新的 Smriti 版本。编译过程可能需要几分钟，取决于你的机器性能。安装成功后，直接在终端输入 smriti --help 即可验证。

对于想体验最新开发版或参与贡献的用户，可以从源码编译： 

$ git clone https://github.com/zero8dotdev/smriti.git
$ cd smriti
$ cargo build --release
# 编译产物位于 ./target/release/smriti，可以将其移动到你的PATH路径下，如
$ sudo cp ./target/release/smriti /usr/local/bin/

对于 macOS 用户，也可以使用 Homebrew ： 

$ brew tap zero8dotdev/tap
$ brew install smriti

注意 ：首次运行 smriti 时，它会初始化本地数据库和配置文件（通常在 ~/.config/smriti/config.toml ）。如果项目依赖本地嵌入模型，它可能会在首次运行时自动下载模型文件（几百MB大小），请确保网络通畅。

3.2 核心配置文件详解

Smriti 的配置采用 TOML 格式，清晰易读。理解其配置项是进行高级定制的基础。默认配置文件路径为 ~/.config/smriti/config.toml 。 

# ~/.config/smriti/config.toml 示例
[storage]
# 记忆数据（包括元数据和向量）的存储路径
path = "~/.local/share/smriti"

[embedding]
# 使用的嵌入模型提供商。`local` 表示使用本地模型。
provider = "local"
# 本地模型的具体名称，all-MiniLM-L6-v2 是一个平衡了速度与精度的通用选择
model = "all-MiniLM-L6-v2"
# 嵌入向量的维度，通常由模型决定，无需修改
dimension = 384

[vector_db]
# 向量数据库类型，`chroma` 是轻量级且流行的选择
type = "chroma"
# 向量数据库的持久化路径
path = "~/.local/share/smriti/vector_db"

[ui]
# 命令行输出的颜色主题，可选 `auto`, `light`, `dark`
theme = "auto"
# 检索结果默认显示的最大数量
default_limit = 10

关键配置解析与调优建议：

  1. embedding.model ：这是影响检索质量的核心。 all-MiniLM-L6-v2 是默认的稳妥之选。如果你主要处理代码，可以尝试更偏向代码理解的模型，如 microsoft/codebert-base 。更换模型需要重新为所有已有记忆生成嵌入向量， Smriti 通常提供 reindex 命令来完成。
  2. storage.path ：如果你的记忆库变得非常庞大，可以考虑将其放在 SSD 硬盘上以提升检索速度，或者放在同步盘（如 iCloud Drive , Dropbox 的特定文件夹）以实现跨设备同步（需注意同步可能带来的冲突风险）。
  3. ui.default_limit ：如果你发现每次检索结果太多，可以调小此值；如果总是找不到，可以适当调大。

3.3 嵌入模型的选择与本地管理

Smriti 的智能检索能力根基在于嵌入模型。本地运行模型，避免了网络延迟和隐私问题，但也带来了模型管理的责任。

首次运行与模型下载： 当你第一次执行需要嵌入功能的命令（如 smriti add 或 smriti find ）时， Smriti 会根据配置自动从 Hugging Face Hub 或其他模型源下载指定的模型。下载的模型文件会缓存到本地（例如在 ~/.cache/huggingface/hub 目录下），后续使用无需重复下载。

模型选择考量：

  • 精度 vs 速度 ：更大的模型（如 all-mpnet-base-v2 ，维度768）通常理解能力更强，检索更精准，但生成嵌入向量的速度更慢，占用内存更多。较小的模型（如 all-MiniLM-L6-v2 ，维度384）速度飞快，内存友好，精度稍有妥协。对于开发者记忆场景，后者在绝大多数情况下已经足够。
  • 领域适配性 ：通用句子模型对技术文本效果不错。如果你有极致的需求，可以寻找在代码数据集上训练过的模型，它们对变量名、函数名、语法结构的语义捕捉可能更好。

管理本地模型： 有时你可能需要清理缓存或切换模型。 

# 查看当前使用的模型和路径（具体命令可能因版本而异，可查看help）
$ smriti status
# 如果切换了配置中的模型，通常需要重建向量索引
$ smriti reindex --all

实操心得 ：对于个人使用，坚持默认的 all-MiniLM-L6-v2 模型是最省心的选择。除非你的记忆库超过数千条，并且明显感到检索不准，否则不需要折腾模型。模型的下载可能会因为网络问题失败，如果遇到，可以尝试手动从 Hugging Face 镜像站下载模型文件，并放到 Smriti 预期的缓存目录中。

4. 日常使用工作流与高级技巧

4.1 记忆的添加：多种姿势捕获灵感

添加记忆是构建知识库的第一步。 Smriti 提供了多种灵活的方式。

1. 直接添加内容： 这是最基础的方式，适合在问题解决后立刻记录。 

$ smriti add --content “在Ubuntu 22.04上，解决`apt-get update`报`NO_PUBKEY`错误的方法：`sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys <缺失的密钥ID>`。通常密钥ID在错误信息中给出。” --tags “ubuntu, apt, gpg-error”

使用 -c 或 --content 直接传入文本。 -t 或 --tags 可以添加多个标签，用逗号分隔，便于后期过滤。

2. 从文件添加： 当你有一个写好的脚本、配置文件或日志片段时，直接添加文件内容。 

# 添加整个文件内容作为一条记忆
$ smriti add --file ~/scripts/deploy.sh --tags “bash, deployment, script”
# 添加文件的一部分（需要结合其他命令行工具）
$ tail -n 50 /var/log/nginx/error.log | smriti add --tags “nginx, error, debug”

3. 从标准输入（stdin）添加： 这赋予了 Smriti 极强的管道集成能力。你可以将任何命令的输出直接保存为记忆。 

# 保存当前复杂的Docker状态
$ docker compose config | smriti add --tags “docker-compose, config”
# 保存一个刚查出来很有用的命令用法
$ tldr tar | grep -A 5 “compress” | smriti add --tags “tar, cheatsheet”

这种方式特别适合保存那些“一次性”但又有参考价值的命令输出。

4. 交互式添加： 如果不提供 --content 或 --file ， Smriti 会启动一个交互式编辑器（由 $EDITOR 环境变量指定，如 vim , nano , code -w ），让你在一个临时文件中编写更长的、格式化的记忆内容，保存退出后即完成添加。

注意事项 ：为了让记忆更易于检索，在添加时尽量用完整的句子描述“问题-解决方案”上下文，而不仅仅是贴代码。例如，比起只贴一段 SQL ，更好的方式是：“ 目标 ：从用户表中查询最近7天活跃且消费超过100元的用户。 难点 ：需要关联订单表并计算总和。 SQL ：（这里是代码）”。这种结构化的记忆，在后续用自然语言检索时，命中率会高得多。

4.2 智能检索：用你的话找到你的代码

检索是 Smriti 的核心价值所在。其 find 命令强大而直观。

基础检索： 

# 用自然语言描述你的需求
$ smriti find “如何用awk提取日志文件的时间戳和错误信息”
# 使用关键词
$ smriti find “docker clean disk space”
# 结合标签过滤
$ smriti find “python exception” --tags “decorator”

Smriti 会将你的查询语句也转化为向量，然后在你的记忆向量空间中寻找余弦相似度最高的前N条（默认10条）记忆，并按相关性排序返回。

高级检索与输出控制： 

# 限制返回数量
$ smriti find “kubernetes pod crash” --limit 5
# 输出更详细的信息，包括完整的元数据（时间、路径等）
$ smriti find “nginx config” --verbose
# 以纯文本（而非表格）格式输出，便于复制或重定向
$ smriti find “ssh tunnel command” --plain
# 检索特定时间之后的记忆
$ smriti find “git alias” --after “2024-01-01”

检索结果解读： 执行 find 后，通常会返回一个表格，包含以下列：

  • ID : 记忆的唯一标识。
  • Preview : 记忆内容的缩略。
  • Tags : 关联的标签。
  • Score : 相关性分数（0-1之间），分数越高越相关。通常高于0.7的结果就非常值得看了。
  • Date : 创建日期。

你可以根据 ID 来查看记忆的完整内容，或进行更新、删除操作。 

$ smriti show <memory_id>

4.3 记忆的管理与维护

一个健康的知识库需要定期维护。

更新记忆： 发现某条记忆不准确或不完整了，可以更新它。 

$ smriti update <memory_id> --content “新的、更完整的内容” --tags “updated, new-tag”

更新内容后， Smriti 会自动为其重新生成嵌入向量。

删除记忆： 

# 删除单条记忆
$ smriti delete <memory_id>
# 批量删除（谨慎操作！）
$ smriti find --tag “obsolete” | awk ‘{print $1}’ | xargs -I {} smriti delete {}

导出与备份： 你的记忆库是宝贵的资产，定期备份很重要。数据存储在配置的 storage.path 下，直接备份整个目录即可。 Smriti 也可能提供导出功能： 

# 导出所有记忆为JSON格式（如果支持）
$ smriti export --format json > my_memories_backup.json

最简单的备份方式就是复制 ~/.local/share/smriti （或你自定义的路径）到云存储或其他硬盘。

重建索引： 如果你更改了嵌入模型配置，或者怀疑检索质量下降，可以重建整个向量索引。 

$ smriti reindex --all

这个过程会遍历所有记忆文本，用新的模型重新生成向量，可能会花费一些时间。

5. 集成到开发者工作流与自动化

5.1 与Shell环境深度集成

要让 Smriti 发挥最大威力，必须把它“编织”进你的日常 Shell 工作流。

创建常用别名（Alias）： 在 ~/.bashrc 或 ~/.zshrc 中添加： 

# 快速添加当前目录和git分支为上下文的记忆
alias memadd=‘smriti add --content “$(echo “In $(pwd) on branch $(git branch --show-current 2>/dev/null || echo “no-git”): “; cat)”’
# 用法：`some-command | memadd --tags “some-tag”`， 或者先执行memadd，再在编辑器中输入内容。
# 超级快速的检索，并直接显示最相关的一条完整内容
alias memgrep=‘smriti find --limit 1 --plain’

这样，你可以用 memgrep “报错xxx” 来快速查找解决方案。

利用Shell函数实现复杂逻辑： 可以编写一个函数，将最后一条成功的命令及其输出自动保存为记忆。 

# 在.zshrc中（bash语法略有不同）
function save-last-success() {
    if [ $? -eq 0 ]; then # 上一条命令执行成功
        local cmd=$(history -1 | sed ‘s/^[[:space:]]*[0-9]*[[:space:]]*//’)
        echo “Command: $cmd\nOutput: \n$(tail -n 20 ~/.zsh_history)” | smriti add --tags “auto-saved, success-cmd”
        echo “Last successful command saved to Smriti.”
    fi
}
# 然后可以绑定到快捷键，或定期执行

5.2 与编辑器（VS Code）集成

虽然 Smriti 是 CLI 工具，但我们可以通过 VS Code 的任务（ Tasks ）或扩展（ Extension ）来桥接。

方法一：使用 VS Code 任务 在项目目录的 .vscode/tasks.json 中定义任务： 

{
    “version”: “2.0.0”,
    “tasks”: [
        {
            “label”: “Search Smriti”,
            “type”: “shell”,
            “command”: “smriti”,
            “args”: [“find”, “${input:query}”, “--plain”],
            “problemMatcher”: []
        }
    ],
    “inputs”: [
        {
            “id”: “query”,
            “type”: “promptString”,
            “description”: “Enter your search query for Smriti:”
        }
    ]
}

然后通过 Cmd/Ctrl + Shift + P 运行任务 “Search Smriti”，输入查询即可，结果会显示在集成终端。

方法二：使用简单的自定义扩展或脚本 可以编写一个 Python 或 Node.js 脚本，调用 Smriti 的 CLI ，然后通过 VS Code 的扩展 API 创建一个侧边栏或快速搜索面板。对于动手能力强的开发者，这是一个不错的周末项目。

5.3 自动化记忆捕获场景示例

自动化能极大降低记录负担，让知识积累成为一种无感的行为。

场景一：终端错误自动归档 通过 Shell 的 trap 或 PROMPT_COMMAND （ bash ） / precmd （ zsh ） 钩子，检查上一条命令的退出状态码（ $? ），如果非零（表示失败），则自动将命令、错误输出和工作目录保存到 Smriti ，并打上 auto-error 标签。 

# Zsh示例（简化版）
autoload -Uz add-zsh-hook
function _smriti_auto_capture_error() {
    local last_exit_code=$?
    if [[ $last_exit_code -ne 0 ]]; then
        local last_cmd=$(history -1 | sed ‘s/^[[:space:]]*[0-9]*[[:space:]]*//’)
        # 这里需要更精细地捕获上一条命令的错误输出，可能需要借助script命令或重定向历史
        # 此处仅为概念展示
        echo “Exit Code: $last_exit_code\nCommand: $last_cmd\nPWD: $(pwd)” | smriti add --tags “auto-error, exit-$last_exit_code” &
    fi
}
add-zsh-hook precmd _smriti_auto_capture_error

注意 ：自动化保存错误需要谨慎处理，避免保存包含密码、密钥等敏感信息的命令。可以通过设置忽略列表（如忽略包含 sshpass , -p password 的命令）来规避。

场景二：Git提交钩子（Hook）关联记忆 在 Git 的 post-commit 钩子中，可以提示开发者是否为这次提交关联一条记忆，记录本次提交解决的核心问题或引入的重要变更。这能将代码变更与上下文知识强关联。

6. 常见问题、排查与效能优化

6.1 安装与初始化问题

问题1： cargo install 编译失败，提示链接错误或找不到某些库。

  • 原因 ： Smriti 可能依赖一些系统级的 C 库，如 OpenSSL , SQLite3 等。
  • 解决 ：
    • Ubuntu/Debian : sudo apt-get install build-essential pkg-config libssl-dev
    • macOS : brew install openssl pkg-config ，并确保 openssl 的 pkg-config 路径被正确设置。
    • 通用 ：仔细阅读编译错误信息，安装对应的系统开发包。

问题2：首次运行 smriti find 非常慢，或者卡住。

  • 原因 ：很可能是在下载嵌入模型。模型文件通常有几百MB，网络不好时会很慢。
  • 解决 ：耐心等待首次下载完成。可以通过查看 ~/.cache 目录下的相关文件夹大小变化来判断。也可以考虑使用国内镜像源来加速 Hugging Face 模型的下载（通过设置环境变量 HF_ENDPOINT=https://hf-mirror.com ）。

6.2 检索效果不理想

问题1：搜索的关键词明明记忆里有，却搜不出来。

  • 原因A ：查询语句和记忆文本的语义相似度低。例如，你搜索“ Python 列表去重”，但记忆里写的是“消除 list 中的重复元素”。
  • 解决 ：尝试用更口语化、更接近你记忆中描述方式的句子来搜索。或者，在添加记忆时，在内容中多补充一些同义词和上下文。
  • 原因B ：嵌入模型不适合你的知识领域。
  • 解决 ：考虑在配置中更换一个模型（如从 all-MiniLM-L6-v2 换成 all-mpnet-base-v2 ），然后执行 smriti reindex --all 。注意，更大的模型会更慢。
  • 原因C ：记忆内容太短或太模糊。
  • 解决 ：养成好习惯，添加记忆时使用“场景-问题-方案”的结构，让内容更丰富。

问题2：搜出来的结果太多，且不精确。

  • 原因 ：查询太宽泛。
  • 解决 ：
    1. 使用 --limit 参数限制返回数量。
    2. 结合 --tags 进行过滤。在添加记忆时，有意识地使用标签进行粗分类（如 python , debug , database , config ）。
    3. 使用更具体、更长的查询语句。

6.3 性能与资源优化

问题：记忆库越来越大，检索速度变慢。

  • 分析 ：向量检索的速度通常与向量数量呈亚线性增长。当记忆条数超过数万时，可能会感知到延迟。
  • 优化建议 ：
    1. 定期清理 ：使用 smriti find --tag “obsolete” 找出并删除过时、无用的记忆。
    2. 使用更高效的向量数据库 ： Smriti 未来可能支持更多后端，如 Qdrant , Weaviate 等，它们针对大规模向量搜索有更好的优化。
    3. 硬件层面 ：确保 Smriti 的数据目录在 SSD 上。如果模型和数据库都在内存中运行，增加系统内存会有帮助。
    4. 索引策略 ：关注项目更新，看是否引入了更快的索引算法（如 HNSW ）。

6.4 数据备份与迁移

备份 ：最简单直接的方式就是定期压缩备份整个 ~/.local/share/smriti 目录。 

$ tar -czf smriti_backup_$(date +%Y%m%d).tar.gz ~/.local/share/smriti

迁移到新机器 ：

  1. 在新机器上安装相同（或兼容）版本的 Smriti 。
  2. 将备份的整个 smriti 数据目录解压到新机器的对应路径（通常是 ~/.local/share/smriti ）。
  3. 确保配置文件 ~/.config/smriti/config.toml 中的模型设置与旧机器一致。如果模型路径不同，可能需要运行一次 smriti reindex 来确保向量数据与模型匹配。

与其他工具的交互 ：目前 Smriti 是一个相对独立的个人知识库。与团队共享记忆是一个更复杂的需求，可能需要通过定期导出、导入 JSON ，或未来可能出现的“共享记忆库”功能来实现。现阶段，它可以完美地作为你个人生产力提升的利器。

我个人使用 Smriti 几个月下来，最大的体会是它改变了我处理“临时知识”的方式。以前那些散落在终端历史、临时笔记文件里的珍珠，现在都被系统地串了起来。当同一个坑第二次出现时，我不再需要慌乱地搜索浏览器历史或公司 Wiki ，一个 memgrep 就能立刻找到自己当初最有效的解决方案。它可能不会每天都被用到，但一旦用到，节省的时间和减少的思维中断，价值巨大。对于追求效率、厌恶重复工作的开发者来说，这类工具不是锦上添花，而是实实在在的“脑力外挂”。

# 开发者工具
Logo
码道开发者社区

码道开发者社区，聚焦华为云码道 CodeArts 代码智能体，沉淀 Agent、Skill、鸿蒙开发实战内容，供开发者查阅资料、交流技术、分享工程实践

更多推荐

cover

状态丢失排障：Claude 持久记忆的跨会话局限与知芽 Notebook Skill 单元记忆如何沉淀可复用知识资产

avatar 码道开发者社区
cover

vs code 下载安装 以及 如何配置 claude code 和codex

avatar 码道开发者社区
cover

GitHub不再让一个模型写到底：HydraFusion多模型编排，官方评测成本降低67%

avatar 码道开发者社区