2025-12-05 14:00:00
之前 Devin 团队推出了一款 DeepWiki 的网站，可以用来解释 GitHub 的代码仓库。今天偶然发现 Google 也推出了类似的产品，叫做 Code Wiki。
当我们去接受一个新的开源项目的时候，最痛苦的莫过于如何开始阅读代码和理解整个代码仓库的架构，对于一些 README 编写得比较好的仓库，我们可能还能手把手地将项目在本地跑起来。但是，如果对于一个文档缺失、变更严重滞后的一些开源项目，可能很大一部分的知识还停留在一些项目成员的大脑，或者是最初的落后的文档当中。那这个时候我们去阅读代码的时候，可能不知道如何下手。
DeepWiki 和 Code Wiki 这样的服务恰好解决了这一个痛点，当我们去阅读一个复杂项目的时候，可以通过 Code Wiki 首先来了解一下项目整体架构。
Code Wiki 还会根据项目内容生成一些媒体资源，比如说视频、图片、架构图、时序图等。通过这样的一个方式，让我们对整个项目有一个初步的了解，然后可以根据自己关心的点去阅读。
简单来说，Code Wiki 是一个能把任何公开的 GitHub 仓库自动变成一本实时更新的“代码百科全书”的工具。
它不像传统的文档工具那样需要开发者手动编写，而是利用 Gemini 的能力自动扫描和理解代码。
Code Wiki 带来的改变主要体现在这几个方面：
自动化文档与图表： 它会在每次代码变更（Commit/Merge）后自动重新扫描仓库。不仅生成清晰的文字文档，还能自动生成架构图和时序图。这一点对于理解复杂系统的调用链路非常有价值。
Gemini 聊天助手： 这可能是最实用的功能。它内置了一个基于 Gemini 的 Chatbot，能够“读懂”整个代码库。你可以像问身边的 Senior Engineer 一样问它：
实时性： 解决了“文档过时”这个千古难题。只要代码变了，Wiki 就跟着变。
其实在 Google Code Wiki 推出之前，开发者社区已经诞生了许多试图解决“代码理解难”这一问题的工具。Code Wiki 更像是一个集大成者，将它们的核心能力整合在了一起。
由 Cognition AI 团队在 2025 年 4 月推出的 DeepWiki，是一个与 Google Code Wiki 功能非常相似的产品。它能够将公共 GitHub 仓库转化为交互式的百科全书，提供 AI 生成的文档、图表，以及一个用于帮助用户理解代码的聊天助手。
Sourcegraph 一直是代码搜索领域的霸主，其推出的 Cody 助手利用代码图谱（Code Graph）实现了对大规模代码库的精准检索和问答。Greptile 则更专注于为 Code Review 提供深度的上下文理解，能够回答“认证逻辑是如何实现的”这类复杂问题。
Mintlify 和 Swimm 是“文档即代码”的先行者。Mintlify 擅长通过分析代码结构自动生成精美的 API 文档；Swimm 则强调“Continuous Documentation”，确保文档随着代码变更自动同步，不会过时。
CodeSee（已被 GitKraken 收购）曾经是代码可视化领域的佼佼者，它能自动生成代码依赖图和服务调用图。
对于个人开发者而言，它是一个极佳的学习工具。面对海量的开源代码，我们不再需要通过 grep 或者是层层跳转去硬啃源码。对于一个团队项目而言，Code Wiki 可以在短短几分钟之内分析出代码的框架，大大减少了团队新成员的 Onboarding 时间。
我们在 Claude Code、Gemini CLI 之外，又多了一个可以让我们快速了解项目整体架构的工具。大家不妨去 codewiki.google 体验一下，看看它是否能成为你阅读源码的第二大脑。
2025-12-04 14:00:00
看过我博客的人会发现，我在这半年的时间里面体验了非常多的语音转文字工具，可以说，这样的工具极大地提升了我的生产效率。不仅搭配 Obsidian 可以更快地写笔记，搭配 Claude Code 等编程工具也可以让我更快地输入提示词。体验到后面，遇到类似的产品，我一般也不会单独地出一篇文章，但是今天体验完了 Typeless，我觉得它值得写一篇文章，单独介绍一下。
Typeless是一款专为 macOS 设计的 AI 语音输入工具，试用下来感觉非常不错。首先，Typeless 的新手入门流程，做的就是我所有体验过的产品当中最简洁、最完善的。一般来说，工具都会让你去默认设置快捷键，然后在新手流程当中，让你按下 Fn 去体验一下语音输入的快速。但是 Typeless 追加了更多的使用场景，就比如说我们可以在 Gmail、Notion 等等中，选择一段我们需要修改的内容，让它生成更正式的邮件内容，或者是说选中一段文本，让它翻译成另外的语言。这一下子就拓宽了 Typeless 的使用场景。更甚至后面我去看 Typeless 的设置时，发现 Typeless 还可以让我们说中文，但是输出英文。另外一个让我非常惊讶的是它的识别速度和准确度。
在我之前体验过的本地离线的，比如说闪电说、Spokenly 等等语音识别软件中，经常让我困扰的是识别准确度的问题。可能受限于本地离线模型的能力，在一些中文同音词的情况下，经常会发生错别字，比如“绘画”和“会话”。但让我惊讶的是，Typeless 竟然可以完美地处理这一部分的内容。另外就是一些专有名词的使用上面，一些本地离线模型通常也不能无法识别。比如说，我经常使用的 Claude Code。
最让我惊讶的是，Typeless 它没有宣称它是纯本地离线识别，但是它的识别速度依然可以媲美所有的离线模型。Typeless 也真正做到了，我松开 Fn 键就可以立即获得结果。
在如今这个时代，对于经常需要码字的朋友来说，Typeless 绝对是一个提升生产力的好帮手。
极速且精准的语音识别
Typeless 最直观的体验就是速度极快。官方宣称其输入速度比传统打字快 4 倍。它利用先进的 AI 模型（如 OpenAI Whisper 等技术）进行实时语音转文字，不仅响应延迟极低，而且在识别准确率上表现优异。无论是日常对话、会议记录，还是长篇大论的写作，Typeless 都能精准捕捉每一个字，大幅减少了后期校对和修改的时间。
根据对话内容自动格式化
Typeless 会自动根据语音的内容对输出的文本进行自动格式化。比如，当我的语音输入是一个列表时，它会自动格式化成一个列表。
还会根据我当前所在的输入框识别。比如说，当发邮件时，它会自动格式化成邮件的格式。
Typeless 还能够自动帮我们修正出对话当中多余以及错误的部分，自动帮我们把最正确的部分告诉对方。
当我们小声 whisper 的时候，Typeless 依然可以非常精准地识别到我们的语音。
智能润色：不仅仅是听写
除了基本的听写功能，Typeless 更像是一个智能的“文字编辑”。在完成输入后，你可以选中一段文本，利用 Typeless 内置的 AI 功能进行润色和重写。它能够自动检测并修复口语中可能出现的语法错误，还能根据需要调整语气，将口语化的表达转换为更正式的商务风格，或者更轻松的社交风格。甚至还能去除冗余的词汇，让表达更加干练清晰。这一功能极大地弥补了语音输入往往过于口语化、逻辑松散的短板。
我们可以选中一段文本，再按下 Fn，然后告诉它将我们选中的这部分内容转变为更正式的邮件，那么 Typeless 就会自动进行重写。
比如对于一段日语，我们想要它的翻译，我们也可以直接选中它的文本内容，然后直接和 Typeless 说，帮我翻译成中文。
我们就可以立即得到中文翻译
多语言翻译
对于需要跨语言工作的用户，Typeless 还提供了便捷的翻译功能。你可以直接用母语口述，然后让 Typeless 将其转换为目标语言的文本；或者选中已有的文本，快速将其翻译成你需要的语言。这使得它不仅是一个输入工具，更是一个实时的多语言沟通助手。
Typeless 支持 100 多种语言。
Typeless 目前提供了免费版和 Pro 专业版两种方案。
免费版适合轻度使用者，每周有 4,000 字的语音输入额度，包含极速语音输入、AI 自动润色、自定义词典以及支持 100+ 种语言的核心功能。新用户通常还可以获得 30 天的 Pro 版免费试用体验。
Pro 专业版则适合重度用户，没有字数限制，并且享受优先的客户支持。价格方面，年付大约 $12/月，而月付则要 $30/月。可以看到，年付方案相比月付有非常大的优惠幅度，如果你是重度依赖语音输入的用户，年付显然是更具性价比的选择。
总的来说，Typeless 是一款将“语音识别”与“AI 文本处理”完美结合的工具。如果你是一个需要在电脑前长时间编写文字的工作者，或者是说你需要长时间进行代码的输入，你都可以去尝试一下 Typeless。
2025-12-02 14:00:00
看过我博客的人会发现，我过去分享了非常多 Claude Code 下的使用小技巧，Claude Code 提供了非常好用的 Clash Commands，可以让我们直接通过快捷方式调用我们预先定义好的 prompt。最近我在使用 Gemini CLI 时，也发现我需要类似的功能。但幸好，Gemini CLI 已经帮我们实现了 slash commands，我们只需要定义好一个函数，就可以非常轻松地通过斜杠命令来调用。
今天就来聊聊怎么配置这套”快捷指令”。
简单来说，Slash Commands 就是你在聊天窗口输入 / 时弹出的那些快捷指令。在 Slack、Discord 甚至现在的 ChatGPT 中都很常见。但在 Gemini CLI 这样的本地终端环境中，它的意义更进了一步：它允许你将复杂的系统提示词（System Prompt）和参数模板化，并以配置文件的形式持久化保存。
这就好比你给 AI 预设了无数个”分身”。输入 /translator，它就是精通多语言的翻译官；输入 /code-review，它就变成了严厉的代码审查员。你不需要每次都啰嗦一大堆背景设定，一个命令，它就懂了。
既然市面上有很多现成的 AI 工具，为什么还要自己在 CLI 里折腾这个？
.gemini/ 目录下，版本控制、备份迁移都随你，不用担心云端服务改版把你的习惯改没了。/research 加上关键字，直接回车，调研任务就开始了。接下来，我以我常用的”代码审查助手”为例，带大家手把手配置一个 Slash Command。
Gemini CLI 的所有自定义命令都存放在项目根目录下的 .gemini/commands/ 文件夹中。如果没有，你可以手动创建它：
mkdir -p .gemini/commands
命令的名称就是文件名的前缀。比如我想用 /code-review 来触发，我就需要创建一个 code-review.toml 文件。注意，这里使用的是 TOML 格式，非常清晰易读。
touch .gemini/commands/code-review.toml
打开这个文件，我们需要填入两部分核心内容：description（描述）和 prompt（提示词模板）。
看看我是怎么配置我的代码审查助手的：
# .gemini/commands/code-review.toml
description = "对输入的代码进行 Code Review"
prompt = """
你是一位资深的软件工程师和代码审计专家。
请对以下代码进行审查：
关注点：
1. 潜在的 Bug 和安全漏洞
2. 代码可读性和命名规范
3. 性能优化建议
请用中文列出具体的修改建议。
"""
这里有个关键点：``。
当我在终端输入 /code-review 并粘贴一段代码时，Gemini CLI 会自动把这段代码填入 `` 的位置。这样，一段通用的 Prompt 就瞬间变成了针对特定代码的指令。
配置保存后，重启，然后在 Gemini CLI 中输入 /，你应该就能看到 code-review 出现在自动补全列表里了。
我试着输入了：
> /code-review function add(a, b) { return a + b; }
AI 立马进入了角色：”这段代码虽然简单，但缺乏类型检查…” 看着它按照我预设的标准给出反馈，那种掌控感真的很棒。
除了代码 Review，我还配置了一个 /research 命令，专门用来做技术调研。我希望它不仅是回答问题，而是帮我搜索、整理、生成一份带有引用的 Draft。
在 .gemini/commands/research.toml 中，我结合了工具调用的逻辑：
description = "深度调研指定关键字并生成报告"
prompt = """
你是一位技术研究员。请对关键字 "" 进行调研。
步骤：
1. 使用 google_web_search 搜索相关定义、最新趋势。
2. 整合信息，对比同类技术。
3. 将结果保存为 Markdown 文件到 Draft/ 目录下。
"""
这样，当我遇到不懂的名词，直接 /research 向量数据库，就可以去喝杯咖啡，回来就能在 Draft/ 目录下看到一份整理好的文档。
除了基础的 `` 参数传递，Gemini CLI 还支持两种更强大的上下文注入方式，这在官方文档中被称为 Magic Placeholders。
你可以在 Prompt 中直接嵌入 Shell 命令，Gemini CLI 会先执行这些命令，然后把输出结果填入 Prompt。这对于需要动态获取系统状态的场景非常有用。
比如，我们可以升级上面的 /code-review，让它直接读取 Git 暂存区的变动，而不需要手动粘贴代码：
description = "审查 Git 暂存区的代码变动"
prompt = """
请审查以下 Git 变更：
!{git diff --staged}
"""
当你输入 /code-review 时，CLI 会先运行 git diff --staged，把 diff 结果抓取过来，再发送给 AI。不用担心安全问题，执行前 CLI 会要求你确认。
如果你需要把某个文件（比如 README 或 配置文件）作为上下文发给 AI，可以使用 @{path/to/file}。
prompt = """
根据 @{README.md} 的内容，为我生成一份发布日志。
"""
甚至支持文件夹 @{src/}（会读取目录下所有文件）以及图片等多模态文件！
Slash Commands 看似只是一个小功能，但它体现了一种”将 AI 能力代码化”的趋势。通过 .gemini/commands 目录，我们实际上是在构建自己的 Prompt Library（提示词库）。
这种方式让我从繁琐的 Prompt 搬运工中解脱出来，专注于思考”我要解决什么问题”，而不是”我要怎么跟 AI 说话”。
如果你也在使用 Gemini CLI，我强烈建议你花点时间审视一下自己的日常工作流，把那些高频出现的对话场景，都封装成一个个 .toml 文件。
2025-12-02 14:00:00
本文记录 Gemini CLI 使用过程中一些容易被忽略的问题，以及使用小技巧。
对于常用的 Gemini CLI 命令比如操作符 @ / 等，可以参考官方文档完成入门学习。
GEMINI.md 和 CLAUDE.md 文件作用类似，它们被设计用来存储项目特定的上下文信息。每次你在项目目录中启动 Gemini CLI 时，它都会自动加载这个文件的内容。这相当于给 AI 预设了一个“出厂设置”，让它迅速了解项目的规范、常用命令和注意事项。
你可以在 GEMINI.md 中定义以下内容：
示例 GEMINI.md 文件内容：
# Project Context for Gemini
## Build & Run
- Build: `npm run build`
- Dev Server: `npm run dev`
- Test: `npm test`
- Lint: `npm run lint`
## Coding Standards
- Use TypeScript for all new files.
- Prefer functional components with Hooks for React.
- Use `styled-components` for styling.
- Error handling: Wrap async calls in try/catch blocks.
## Architecture
- `/src/components`: Reusable UI components.
- `/src/pages`: Next.js pages.
- `/src/lib`: Utility functions and API clients.
有了这个文件，当你问“怎么运行测试？”或者“帮我写一个新组件”时，Gemini 就能根据预设的规范给出更准确的回答，而不需要你每次都重复一遍背景信息。
在 Gemini CLI 下，可以在命令前增加一个 ! 来执行命令
!ls -al
!agy .
# 单个命令执行
!find . -name "*.tsx" -mtime -7
# 查看 git 差异
!git diff --stat
# 获取文件信息
!wc -l src/components/*.tsx
# 进入 Shell 模式（所有输入作为命令）
!
# 现在输入的都是 shell 命令
find . -type f -name "*.json" | head
git log --oneline -10
Gemini CLI 中如果 Gemini 要写入文档，WriteFile 这个工具写入文档，写入之前会显示 Diff 让用户审批是否允许更改，但是 Gemini CLI 在终端中默认会截断过长的输出，导致 Diff 显示不全，无法 Review 具体的修改内容。
这里有三种方式可以解决这个问题：
这是最直接的方法，通过修改 Gemini CLI 的配置文件，允许终端输出完整的 Diff 信息。
在配置文件（通常位于 ~/.gemini/settings.json 全局配置或 .gemini/settings.json或通过命令修改）中调整以下设置：
| 配置项 | 默认值 | 建议值 | 说明 |
|---|---|---|---|
tools.enableToolOutputTruncation |
true |
false |
彻底禁用截断功能，显示完整输出 |
tools.truncateToolOutputThreshold |
10000 字符 | -1 | 设置为 -1 禁用字符数量限制 |
tools.truncateToolOutputLines |
100 行 | 10000 | 或者大幅增加允许显示的行数 |
可以直接在 Gemini CLI 中执行 /settings
Gemini CLI 提供了与 VS Code 的深度集成，可以直接在编辑器中打开 Diff 视图，体验更好。
/ide install
/ide enable
如果上述方法都不适用，或者你更习惯使用 Git 工具：
git status clean）。git diff 查看修改内容。git checkout <file> 撤销更改。这种方法虽然不是“预览”，但利用版本控制系统作为安全网，是最稳妥的方式。
添加持久化知识到全局上下文
# 添加到内存
/memory add "我们的 API 使用 GraphQL + Apollo Server，所有查询需要错误处理"
# 查看当前内存
/memory show
# 刷新重新加载所有 GEMINI.md
/memory refresh
Gemini CLI 允许你通过 .toml 配置文件自定义 Slash Commands（如 /my-command），将复杂的 Prompt 和逻辑封装成简单的指令。这对于团队协作和个人工作流标准化非常有帮助。
你可以定义两类命令：
~/.gemini/commands/。所有项目通用的指令，例如通用的代码解释或翻译命令。.gemini/commands/。仅在该项目生效，适合项目特定的规范检查或部署指令。此目录建议提交到 Git。注意：文件名即为命令名。例如 commit.toml 会生成 /commit 命令。
一个基本的命令文件至少包含 prompt 字段。
# 文件名: ~/.gemini/commands/hello.toml
# 调用方式: /hello
description = "一个简单的问候命令"
prompt = "你好，Gemini！请给我讲一个关于程序员的简短笑话。"
Gemini CLI 的强大之处在于它支持动态参数和 Shell 命令注入。
!{cmd}：执行系统命令并将结果插入 Prompt。实战示例：智能 Git Commit 生成器
创建一个名为 git/commit.toml 的文件（支持子目录命名空间，调用时使用 /git:commit）：
# 文件名: .gemini/commands/git/commit.toml
# 调用方式: /git:commit
description = "根据暂存区的变更生成符合 Conventional Commit 规范的提交信息"
prompt = """
你是一个 Git 专家。请根据以下 `git diff --staged` 的输出，生成一个符合 Conventional Commits 规范的提交信息。
输出要求：
1. 第一行是简短的描述（<type>: <subject>）。
2. 空一行。
3. 详细的变更说明列表。
Diff 内容：
!{git diff --staged}
"""
当你运行 /git:commit 时，Gemini 会自动执行 git diff --staged，读取变更内容，然后按照你的要求生成 Commit Message。
实战示例：需求拆解助手
# 文件名: .gemini/commands/split.toml
# 调用方式: /split "用户登录功能"
description = "将一个大需求拆解为小的技术任务"
prompt = """
请将以下需求拆解为具体的开发任务列表。每个任务应包含简要的技术实现思路。
需求描述：
"""
通过这种方式，你可以将原本需要反复复制粘贴的 Prompt 变成一行简单的命令，极大地提升效率。
灵活运用 Checkpointing 与 /restore：
当你让 Gemini CLI 修改文件时，它会在执行前创建一个检查点 (Checkpoint)。这个功能允许你随时回溯到之前的状态，就像 Git 的版本控制一样，为你的操作提供了安全保障。
settings.json 配置文件中启用。具体设置请参考官方文档。write_file 或 replace）即将被批准执行时，CLI 会自动拍摄一个项目文件的快照（存储在一个独立的 Git 仓库中，不影响你的项目 Git 仓库）、保存当前的对话历史以及即将执行的工具调用。/restore 可以列出所有可用的检查点。/restore [tool_call_id] 可以回溯到特定的检查点。这个功能在你进行实验性修改、或者不确定 AI 提议是否最佳时，提供了强大的“撤销”能力。
在 Gemini CLI 中可以同时处理多个项目文件
/directory add src/backend,src/frontend,src/shared
/directory show # 列出所有已添加目录
# 现在可以同时引用它们
@src/backend/api.ts @src/frontend/components.tsx
"保证后端 API 和前端组件的类型对齐"
2025-12-01 14:00:00
从 2020 年开始使用 Obsidian 算起，到今天也已经快 5 年了，这个过程中我将过去将近 10 年的笔记，包括 Evernote，WizNote 中的笔记，豆瓣上的笔记全部转成了 Markdown 保存到了本地，后来陆陆续续使用的比如 [[Voicenotes]] 也都转成 Markdown 存如 Obsidian。虽然过去纪念陆陆续续在整理，但是实际上每天添加到笔记库中的内容要远多于要整理阅读的内容，笔记仓库也是越来越大，所以我越来越想使用一个工具可以帮助我真正地理解我写下的东西，并且在我想使用的时候能快速的找回。
现状是当我想要回溯笔记中的内容时，我使用 Obsidian 本地的搜索，非常快，能满足我 80% 的需求，但是往往有一些关键字，搜索出来的笔记条目非常多，这个时候我就会迷失在历史的笔记中。
而我突然想到，我几乎每天都在使用 Claude Code / Gemini CLI 这样基于命令行的工具来理解代码和生成代码，Obsidian 中的笔记何尝不是另外一种意义上的「Code」。Gemini CLI 拥有超大的上下文，他们本地检索的能力很强，文本生成的能力也很强，天然的适合作为 Obsidian 的辅助工具。
我在 Obsidian 中积累了大量的笔记，但需要借助外部的工具来：
让 AI 介入重要的本地数据需要谨慎，建议实时备份 Obsidian 仓库，或在测试的仓库中运行无误之后再在主笔记库中配置。
Zettelkasten（卡片盒笔记法）是由德国社会学家 Niklas Luhmann 发展出的一种知识管理方法。它的核心理念非常简单：一个笔记只记录一个想法（Atomic Note），并通过链接将这些笔记编织成一个巨大的知识网络。
根据 Obsidian 与 Gemini CLI 的实践分享，Zettelkasten 不仅仅是存储信息，更是为了产生新想法。其核心原则包括：
它的好处是显而易见的：它强制你进行“思考”而非简单的“复制粘贴”，帮助你理清思路；随着时间的推移，这个笔记库会成为你的“第二大脑”，在你需要写作或输出时提供源源不断的灵感组合。
结合 Zettelkasten 的理念，我构建了一套适合自己的 Obsidian 工作流。对于我来说，整理的过程就是从笔记转换成知识的过程。
Zettelkasten 目录。在这个过程中，Gemini CLI 成为了我最得力的助手。它可以帮助我快速处理从“输入”到“加工”的繁琐环节，让我更专注于“思考”和“输出”。
Obsidian 的核心优势之一是本地化和纯文本 (Markdown)。这意味着你的笔记本质上和一个软件项目的代码库（Codebase）没有区别。
作为一名开发者，我们习惯使用命令行工具（CLI）来管理代码、重构代码、搜索代码。既然笔记也是代码，为什么不能用同样的逻辑来处理它们呢？
使用 Gemini CLI (或者类似的 LLM CLI 工具) 有以下几个独特的优势：
详细的安装和配置教程可以参考我之前的文章 Google Gemini CLI 使用初体验。
简而言之，Gemini CLI 是一个基于 TypeScript 的开源项目，确保你的环境中安装了 Node.js 后，你可以通过以下方式快速开始。
推荐使用 npx 直接运行，这样可以让你永远体验最新的功能：
npx https://github.com/google-gemini/gemini-cli
或者，你也可以选择全局安装：
npm install -g @google/gemini-cli
不再依赖僵硬的关键词搜索，而是直接向你的笔记提问，Gemini 会自动根据上下文推测来检索笔记内容。
示例：
gemini -p "读取 /Journal 目录下最近一周的日记，总结我这周的主要情绪变化和完成的关键任务"
或者：
gemini -p "基于我关于 '系统设计' 的所有笔记，帮我列出一个学习提纲，并指出我还缺失哪些知识点"
这种全局视角的总结，是传统笔记软件很难做到的。
下面附上一个我直接在 Gemini 中询问「利率和汇率」关系以及相互影响的回答。
当你的 Inbox 堆积了大量杂乱的随笔时，可以使用 CLI 快速整理。
示例：
gemini -p "读取 inbox/draft.md，整理它的格式，修复拼写错误，提取出 3 个核心观点，并生成 Tags"
你甚至可以要求它输出符合 Obsidian 语法的 Markdown，包括 [[WikiLinks]]。
Obsidian 的图谱功能很酷，但有时太乱了。Gemini 可以帮你找到逻辑上的联系。
示例
gemini -p "对比 '哲学/斯多葛学派.md' 和 '心理学/CBT.md'，找出它们在核心理念上的异同点"
.geminiignore：就像 .gitignore 一样，你肯定不希望 AI 去读取你的 .git 目录，或者巨大的附件文件夹 assets/。配置好忽略文件可以加快速度并节省 Token。[[链接]] 包裹”。alias ask-notes='gemini --context ./KnowledgeBase'，这样每次只需要输入 ask-notes "问题" 即可。将 AI 引入个人知识库 (PKM) 是必然的趋势。虽然现在市面上有很多“AI 笔记软件”，但对于已经拥有成熟 Obsidian 工作流的用户来说，使用 CLI 工具是一种最轻量、最可控、也最 Geek 的升级方式。它不需要你迁移数据，不需要你改变存储格式，只是多了一个强大的“外脑”助手，随时待命。
2025-11-29 14:00:00
在 k3s 中使用 Helm 安装的应用，更新流程非常标准化。基本公式是：更新仓库 -> (可选)修改配置 -> 执行 Upgrade。
以下是通用步骤，假设你要更新名为 gitea 的应用：
首先必须告诉 Helm 获取最新的 Chart 版本列表，否则它只知道旧版本。
helm repo update
如果你想知道现在有什么版本可供升级：
# 搜索仓库里的版本
helm search repo gitea/gitea
# 或者查看你当前安装版本的状态
helm list -n gitea
升级时，最重要的原则是保持配置一致。 如果你当初安装时用了一个 values.yaml 文件（比如 gitea-values.yaml），请直接复用它。
如果你搞丢了当初的配置文件，或者你是用 --set 参数瞎装的，可以先把当前的配置导出来：
# 把当前运行的配置导出为 my-current-values.yaml
helm get values gitea -n gitea > my-current-values.yaml
检查一下导出的文件，确认里面的配置是你想要的。
使用 helm upgrade 命令。这个命令非常智能：如果应用没装，它会报错（除非加 --install）；如果装了，它会对比版本差异进行升级。
语法： helm upgrade [Release名字] [Chart名字] -n [命名空间] -f [配置文件]
示例：
helm upgrade gitea gitea/gitea \
-n gitea \
-f gitea-values.yaml \
--version 10.0.0 # <--- 可选：指定特定版本。不加这行默认升到最新版
升级命令执行完后，Pod 通常会重启（滚动更新）。
# 观察 Pod 重启过程
kubectl get pods -n gitea -w
# 检查 Helm 状态，确认 Revision（修订版本号）增加了
helm list -n gitea
# 回滚到上一个版本
helm rollback gitea -n gitea
HelmChart CRD 管理的。 通常不需要你手动用 helm upgrade 去动它们。升级 k3s 本身（二进制文件）时，这些内置组件会自动更新。 如果你手动去 upgrade traefik，可能会和 k3s 的自动管理器冲突，导致配置被覆盖回来。
values.yaml 里的配置，版本号没变，能用 upgrade 吗？ A: 可以！ helm upgrade 不仅仅是“升级版本”，它的本质是“应用新状态”。即使 Chart 版本没变，只要你的 values.yaml 变了（比如开启了 ingress），执行 upgrade 就会应用这些配置变更。
