2026-01-19 14:00:00
随着 AI 编程助手的快速发展，[[Claude Code]]、[[Codex]]、[[Gemini CLI]] 等工具已经成为开发者日常工作中不可或缺的伙伴。然而，这些工具的默认功能往往只是冰山一角。通过安装和配置 Agent Skills，我们可以大幅扩展这些 AI 助手的能力，让它们更加智能、更加专业。
在使用 AI 编程助手的过程中，我发现 Anthropic 官方的 Skills 仓库提供了一个很好的学习起点。通过安装 skill-creator，我们可以学习如何创建自定义的 Skill，进而根据自己的需求定制专属的 AI 助手能力。
本文将分享我在日常开发中常用的 Agent Skills，并详细介绍它们的安装和使用方法。
superpowers 是我最常使用的 Agent Skills 集合，也是功能最全面的专业开发工作流增强套件。这个仓库的设计理念是将软件开发中的最佳实践融入到 AI 助手的行为模式中，让 AI 不仅能写代码，更能以专业开发者的思维方式工作。
该仓库包含了多个核心开发技能，涵盖了从代码编写、调试、测试到审查的完整开发生命周期。每个技能都经过精心设计，遵循行业标准和最佳实践。比如 systematic-debugging 技能实现了结构化的调试流程，test-driven-development 技能则引导 AI 助手先写测试再写实现代码。这些技能不是简单的提示词模板，而是完整的工作流程，能够确保代码质量和开发效率。
在 [[Claude Code]] 中，使用插件市场安装：
/plugin marketplace add obra/superpowers
安装完成后，所有的 superpowers 技能都会自动加载。
superpowers 提供了多个专业技能，每个技能都针对特定的开发场景：
使用时，只需在对话中提到相关场景，Claude Code 会自动激活对应的技能。例如，当你说”帮我调试这个问题”时，systematic-debugging 技能会自动启用。
agents 是一个功能全面的 Agent Skills 插件集合，采用了模块化的架构设计，涵盖了从前端到后端、从基础设施到安全的各个开发领域。这个仓库的特点是将不同技术栈和开发场景的专业知识封装成独立的插件，让开发者可以按需加载。
与 superpowers 注重开发流程不同，agents 更侧重于技术栈的深度。每个插件都包含了该领域的专业知识、最佳实践和常见问题的解决方案。比如 python-development 插件包含了 Python 的类型提示、异步编程、包管理等专业技能；kubernetes-operations 插件则涵盖了 K8s 的部署、配置、监控和故障排查。这种设计让 AI 助手能够在特定技术领域表现得像一个资深专家。
首先添加插件市场：
/plugin marketplace add wshobson/agents
然后根据需要安装特定领域的插件：
# 基础开发插件
/plugin install python-development # Python 开发，包含 5 个专业技能
/plugin install javascript-typescript # JS/TS 开发，包含 4 个专业技能
/plugin install backend-development # 后端 API 开发，包含 3 个架构技能
# 基础设施和运维
/plugin install kubernetes-operations # K8s 部署，包含 4 个部署技能
/plugin install cloud-infrastructure # AWS/Azure/GCP 云服务，包含 4 个云技能
# 安全和质量
/plugin install security-scanning # SAST 安全扫描技能
/plugin install code-review-ai # AI 代码审查
# 全栈编排
/plugin install full-stack-orchestration # 多 Agent 工作流
agents 采用模块化设计，你可以只安装需要的插件，避免加载不必要的功能。每个插件都是独立的，互不干扰。
建议根据你的技术栈选择相应的插件。例如，如果你主要做 Python 后端开发，可以安装 python-development 和 backend-development；如果涉及 DevOps 工作，则加装 kubernetes-operations 和 cloud-infrastructure。
如果你和我一样使用 [[Obsidian]] 来管理知识库，那么 Obsidian Agent Skills 将是一个非常实用的扩展。这个技能集专门为 Obsidian 生态设计，让 AI 助手能够深度理解和操作 Obsidian 的特有语法和功能。
Obsidian 有自己独特的 Markdown 方言，包括双向链接（wikilinks）、可折叠的 callouts、YAML frontmatter properties、JSON Canvas 画布文件、Obsidian Bases 数据库等特性。这些功能虽然强大，但语法复杂，手动编辑容易出错。Obsidian Agent Skills 通过系统化的语法规则和示例，让 AI 助手能够正确生成和修改这些内容，相当于为 AI 配备了 Obsidian 专家的知识。无论是创建符合规范的笔记、建立知识网络，还是维护数据库视图，AI 都能准确完成。
npx skills i kepano/obsidian-skills
安装后，AI 助手将能够：
这对于维护 Obsidian 知识库的开发者来说非常方便，AI 助手能够直接帮你创建和编辑笔记，而不需要手动调整格式。
Vercel Agent Skills 专为使用 [[Vercel]] 平台的开发者设计，提供了部署、配置和优化 Vercel 项目的能力。作为目前最流行的前端应用部署平台之一，Vercel 有着丰富的配置选项和最佳实践。
这个技能集整合了 Vercel 官方文档中的关键知识点，包括 vercel.json 配置文件的各种选项、环境变量的管理、自定义域名的设置、边缘函数（Edge Functions）的使用、性能优化建议等。它特别针对 Next.js 应用进行了优化，因为 Vercel 是 Next.js 的母公司，两者的集成度最高。有了这个技能，AI 助手能够帮你快速解决部署问题，优化构建配置，甚至预测可能出现的部署错误。
npx add-skill vercel-labs/agent-skills
该技能集成了 Vercel 的最佳实践，能够帮助你：
特别适合使用 Next.js 和 Vercel 部署的项目。
UI UX skill 是前端开发的利器，专门用于创建美观、可访问、符合现代设计标准的用户界面。这个技能将 UI/UX 设计的专业知识和前端开发的最佳实践结合在一起，让 AI 助手能够生成生产级别的界面代码。
该技能涵盖了现代 Web 开发中的多个关键领域：设计系统的实现、组件库的构建、响应式设计的最佳实践、无障碍访问（WCAG）标准的遵循、性能优化策略等。它不仅关注代码的功能性，更注重用户体验的细节，比如动画的流畅性、交互的反馈、布局的和谐等。对于需要频繁开发 UI 组件的前端工程师来说，这个技能能显著提升开发效率和代码质量。
/plugin marketplace add nextlevelbuilder/ui-ux-pro-max-skill
这个技能非常适合前端开发，能够：
当你需要实现复杂的 UI 组件时，这个技能能够提供专业的指导和代码生成。它理解现代前端框架（[[React]]、[[Vue]]、[[Angular]]）的设计模式，并能生成高质量的组件代码。
这是我自己维护的 SEO 相关技能集合，专注于帮助开发者优化网站的搜索引擎表现。作为一个技术型内容创作者，我深知 SEO 对于网站流量的重要性，因此整理了这套技能来自动化 SEO 优化工作。
这个技能集整合了搜索引擎优化的核心知识，包括语义化 HTML 的使用、meta 标签的优化、Open Graph 和 Twitter Card 的配置、结构化数据（JSON-LD）的生成、sitemap 的创建、robots.txt 的配置等。它还包含了针对不同类型网站（博客、电商、企业站）的 SEO 策略建议。通过这个技能，AI 助手能够在你开发网站时自动考虑 SEO 因素，从技术层面提升网站的搜索可见性。
/plugin marketplace add einverne/agent-skills
该技能能够：
特别适合开发营销型网站或需要注重 SEO 的项目。
Claude Code Templates 提供了一系列实用的项目模板和工作流模板，是学习如何构建自定义 Agent Skills 的优秀范例集。这个仓库收集了各种场景下的最佳实践模板，展示了如何将具体的工作流程转化为可复用的技能。
仓库中的模板涵盖了软件开发的多个环节，从项目初始化、代码规范设置，到文档生成、代码审查流程。每个模板都经过实战检验，包含了详细的步骤说明和示例。特别值得一提的是 content-creator 模板，它展示了如何为内容创作这种非传统开发场景定制 AI 助手，包括文章结构规划、SEO 优化建议、多语言支持等功能。通过研究这些模板，你可以学会如何针对自己的工作流程创建专属技能。
这个仓库中的 content-creator 模板特别值得参考，它展示了如何为内容创作工作流定制 AI 助手的能力。你可以基于这些模板创建自己的工作流。
模板涵盖了多种场景：
通过学习这些模板，你可以更好地理解如何定制 Agent Skills。
Planning with Files 是一个独特的技能，它的核心理念是”文档驱动开发”，即为每个任务生成相应的规划文档，让开发过程更加透明和可追溯。与传统的敏捷开发方法不同，这个技能强调将计划以文件形式持久化保存。
这种方法特别适合复杂项目和团队协作场景。AI 助手在接到任务后，会首先创建一个详细的规划文档，包括任务背景、技术方案、实施步骤、风险评估等内容。随着项目推进，这些文档会不断更新，记录决策过程、遇到的问题和解决方案。这样不仅确保了开发的系统性，还为项目留下了完整的历史记录，方便日后回顾和知识传承。对于需要严格文档管理的项目（如企业应用、开源项目），这个技能尤为有价值。
/plugin marketplace add OthmanAdi/planning-with-files
使用这个技能后，AI 助手会：
这种方法特别适合复杂的项目，能够确保开发过程有条不紊。规划文档也成为了项目的宝贵资料，方便日后回顾和维护。
Prompt Generator 是一个元技能（meta-skill），它的作用不是直接解决开发问题，而是帮助你更好地与 AI 助手交流，生成更高质量的提示词。可以把它理解为”教你如何提问的技能”。
提示词工程（Prompt Engineering）是使用 AI 工具的关键能力。一个好的提示词应该清晰、具体、包含必要的上下文，并能引导 AI 产生期望的输出。Prompt Generator 集成了提示词工程的最佳实践，包括如何构建清晰的指令、如何提供有效的示例、如何设置合适的约束条件等。它还能分析你的需求，识别模糊或不完整的地方，并建议如何改进。对于想要深入学习 AI 助手使用技巧的开发者来说，这个技能是一个很好的学习伙伴，能够帮助你逐步掌握与 AI 高效协作的艺术。
/plugin marketplace add huangserva/skill-prompt-generator
这个技能能够：
对于想要深入学习如何更好地使用 AI 编程助手的开发者来说，这是一个很好的学习工具。
Agent Skills 极大地扩展了 AI 编程助手的能力边界。通过合理选择和配置这些技能，我们可以将 AI 助手打造成真正的开发伙伴。
在选择 Agent Skills 时，我的建议是：
superpowers 提供了最基础和最通用的能力增强最后，记住 Agent Skills 是一个不断发展的生态。关注这些仓库的更新，尝试新的技能，找到最适合自己工作流的组合。
如果你有其他好用的 Agent Skills 推荐，欢迎在评论区告诉我。
2026-01-15 14:00:00
2026 年 1 月 14 日，[[Google]] 为其 AI 驱动的开发工具 [[Antigravity]] 推出了 Agent Skills 功能。这个开放标准的技能系统让开发者可以将专业知识打包成可复用的技能包，极大地扩展了 AI 智能体的能力边界。
Agent Skills 是一套开放标准，用于将 AI 指令打包成可复用的技能包。你可以把它理解为给 AI 智能体安装的专业插件或知识模块。
每个 Skill 本质上是一个包含定义文件和可选资源的目录结构，其中核心是 SKILL.md 文件，它使用 YAML 前置元数据和自然语言指令告诉 AI 如何执行特定任务。
Agent Skills 采用渐进式披露设计：
这种设计保持了上下文窗口的高效利用，避免无关信息干扰 AI 的判断。
最早，Skills 是由 Anthropic 在 Claude 中推出，现在 Skills 已经称为了 CLI 的标准，Codex 率先支持，现在 Gemini CLI，Antigravity 都跟进了。[[Cursor]] 有类似的规则系统，但格式不同。
存储路径：.agent/skills/<skill-name>/SKILL.md
特点：
使用场景：
存储路径：~/.gemini/antigravity/skills/<skill-name>/SKILL.md
特点：
使用场景：
当项目级和全局技能同名时：
一个标准的 SKILL.md 文件包含两部分：
---
name: skill-name
description: 简短描述，Agent 用它判断是否需要激活此技能
---
# 技能标题
详细的执行指令，使用自然语言、代码片段或分步指南。
必需字段：
---
name: deploy-staging
description: 将当前分支部署到测试环境。当用户要求部署或在测试环境测试时使用
---
可选字段：
---
name: skill-name
description: 技能描述
version: 1.0.0
author: your-name
tags: [deployment, automation]
dependencies: [git, docker]
---
使用强制性语言确保 Agent 严格执行：
## 执行清单
审查代码时，必须按顺序遵循此检查清单，明确覆盖每个要点：
1. 验证所有变量命名遵循 camelCase 规范
2. 检查是否存在未处理的异常
3. 确认所有函数都有 JSDoc 注释
4. 验证单元测试覆盖率达到 80% 以上
关键原则：
在 description 中使用明确的触发词：
# 好的示例
description: 生成符合 Conventional Commits 规范的提交信息。当用户要求生成提交、创建 commit 或写提交信息时使用
# 不好的示例
description: 帮助处理 Git 相关操作
技巧：
Agent 可以同时激活多个相关技能：
# 技能 A：Git 提交
name: git-commit-formatter
description: 格式化 Git 提交信息
# 技能 B：代码审查
name: code-reviewer
description: 审查代码质量
# 工作流：审查通过后自动生成提交
为了让你快速上手，我整理了四个常用的 Agent Skills 示例：
这些示例都已经保存在我的 dotfiles 仓库中，你可以直接查看完整的 SKILL.md 定义：
查看完整示例：einverne/dotfiles/skills
你可以直接克隆或复制这些技能到你的项目中：
# 克隆整个 skills 目录
git clone https://github.com/einverne/dotfiles.git
cp -r dotfiles/skills/* .agent/skills/
# 或者只复制特定技能
cp -r dotfiles/skills/git-commit-formatter .agent/skills/
也可以将这些技能安装为全局技能：
# 安装到全局
cp -r dotfiles/skills/* ~/.gemini/antigravity/skills/
然后在 [[Antigravity]] 中直接使用：
# 使用 git 提交格式化器
"帮我生成一个提交信息"
# 使用代码审查助手
"审查这个文件的代码质量"
# 使用部署助手
"部署到 staging 环境"
# 使用组件生成器
"创建一个 Button 组件"
每个技能专注一个明确的任务：
# 好的示例
name: git-commit-formatter
description: 格式化 Git 提交信息
name: code-reviewer
description: 审查代码质量
# 不好的示例
name: git-helper
description: 帮助处理各种 Git 操作（过于宽泛）
描述应该包含明确的使用场景：
# 好的示例
description: 将当前分支部署到测试环境。当用户要求部署、发布到测试或在 staging 环境测试时使用
# 不好的示例
description: 部署功能
鼓励 Agent 通过 --help 了解脚本用法，而不是直接读取源代码：
## 使用部署脚本
运行 `./scripts/deploy.sh --help` 查看可用选项
常用命令：
- `./scripts/deploy.sh --env staging` - 部署到测试环境
- `./scripts/deploy.sh --env production` - 部署到生产环境
根据实际使用情况不断完善技能：
创建测试场景验证技能效果：
## 测试场景
### 场景一：标准流程
输入：生成提交信息
前置条件：暂存区有变更
预期：生成符合规范的提交信息
### 场景二：边界情况
输入：生成提交信息
前置条件：暂存区为空
预期：提示用户先添加文件
### 场景三：错误处理
输入：生成提交信息
前置条件：不在 Git 仓库中
预期：友好的错误提示
使用 [[Git]] 管理技能：
# 项目技能
cd .agent/skills
git add .
git commit -m "feat(skills): 添加代码审查技能"
# 全局技能
cd ~/.gemini/antigravity/skills
git init
git remote add origin https://github.com/username/my-skills.git
好处：
通过 Git 仓库共享团队技能：
# 克隆团队技能库
git clone https://github.com/team/antigravity-skills.git
# 链接到项目
cd your-project
mkdir -p .agent/skills
cp -r ../antigravity-skills/* .agent/skills/
团队应制定统一规范：
# 技能命名规范
- 使用 kebab-case
- 动词-名词结构
- 例如：deploy-staging, review-code, format-commit
# 文件组织规范
skill-name/
├── SKILL.md # 必需
├── README.md # 可选，详细说明
├── scripts/ # 可选，脚本文件
└── templates/ # 可选，模板文件
# 文档规范
- 每个技能必须有清晰的描述
- 必须说明使用场景和触发条件
- 必须提供示例输出
- 必须说明错误处理方式
创建工作流技能，组合多个基础技能：
---
name: pr-workflow
description: 完整的 Pull Request 工作流。当用户要求创建 PR、提交审查或准备合并时使用
---
# Pull Request 完整工作流
## 工作流程
执行以下步骤，按顺序完成 PR 准备：
1. 代码审查（使用 code-reviewer 技能）
- 如发现严重问题，停止流程并要求修复
2. 运行测试套件
- `npm test`
- 如测试失败，停止流程
3. 生成提交信息（使用 git-commit-formatter 技能）
- 格式化最终的提交
4. 推送到远程
- `git push origin HEAD`
5. 创建 Pull Request
- 运行 `gh pr create`
- 填充审查清单
- 添加相关标签
6. 通知团队
- 在团队频道发送 PR 链接
在技能中实现条件逻辑：
## 部署决策树
根据目标环境执行不同流程：
如果目标是测试环境：
1. 运行快速测试：`npm run test:unit`
2. 构建：`npm run build:staging`
3. 部署：`./scripts/deploy-staging.sh`
如果目标是生产环境：
1. 确认用户意图：询问"确认要部署到生产环境吗？"
2. 运行完整测试：`npm run test:all`
3. 检查代码覆盖率：必须 ≥80%
4. 构建：`npm run build:production`
5. 创建备份：`./scripts/backup-production.sh`
6. 部署：`./scripts/deploy-production.sh`
7. 验证：运行健康检查
8. 通知：发送部署通知
处理用户提供的参数：
## 参数处理
支持以下占位符：
- `{filename}`: 用户指定的文件名
- `{directory}`: 用户指定的目录
- `{branch}`: 目标分支名称
- `{environment}`: 部署环境（staging/production）
示例：
用户输入："审查 src/api/user.ts"
解析为：filename = "src/api/user.ts"
用户输入："部署到 staging"
解析为：environment = "staging"
调用命令行工具：
## 工具集成
### 代码格式化
运行 Prettier：
```bash
prettier --write {files}
```
运行 ESLint：
eslint {files} --fix
运行 TypeScript：
tsc --noEmit
生成覆盖率报告：
npm test -- --coverage
每个工具调用后检查退出码：
## 常见问题
### 技能不生效
可能原因和解决方案：
1. 路径配置错误
- 确认技能位于正确的目录
- 项目级：`.agent/skills/`
- 全局：`~/.gemini/antigravity/skills/`
2. YAML 格式错误
- 验证前置元数据格式
- 使用 YAML 验证工具检查语法
- 确保 name 和 description 字段存在
3. 描述不够明确
- 添加更多触发关键词
- 说明具体使用场景
- 使用用户可能输入的自然语言
4. 技能名称冲突
- 检查是否存在同名技能
- 项目级技能会覆盖全局技能
- 重命名技能避免冲突
### 调试技能
启用详细日志查看执行过程：
```bash
# 查看 Antigravity 日志
antigravity --verbose
# 检查哪些技能被加载
antigravity skills list
# 验证技能格式
antigravity skills validate
分析 Agent 行为：
精简技能描述
避免冗余指令
使用缓存
并行执行
推荐的社区技能仓库：
领域分类：
Agent Skills 为 [[Antigravity]] 带来了强大的可扩展性，让开发者可以：
关键要点：
开始创建你的第一个 Agent Skill，让 AI 成为真正理解你项目和团队的智能助手。
2026-01-14 14:00:00
[[Gemini CLI]] 最近推出了一个非常强大的新功能，名为 [[Agent Skills]]。这个功能极大地扩展了命令行 AI 助手的边界，允许用户根据自己的需求定制专业的技能包。
Agent Skills 是 [[Gemini CLI]] 的一个强大扩展机制，它允许用户为 AI 助手定制专门的能力和工作流程。可以将 Skills 理解为给 AI 安装的专用插件或知识包。
默认情况下，通用大语言模型虽然知识广博，但在处理特定领域的复杂任务时，往往缺乏：
Agent Skills 通过以下方式解决这些问题：
当你在对话中提出需求时，[[Gemini CLI]] 会：
这种机制让 AI 助手从通用工具进化为领域专家，能够深入理解你的工作场景并提供专业化的支持。
使用 Agent Skills 功能主要涉及安装配置、创建自定义技能和日常使用三个环节。
首先确认你的 [[Gemini CLI]] 版本支持 Agent Skills 功能。你可以通过以下命令检查：
gemini --version
[[Gemini CLI]] 会在特定目录中查找 Skills 定义。通常位于：
~/.config/gemini/skills/
%APPDATA%\gemini\skills\
你也可以在配置文件中自定义 Skills 目录位置。
一个标准的 Skill 由一个目录组成，基本结构如下：
skill-name/
├── SKILL.md # 必需：技能定义文件
├── script.py # 可选：Python 脚本
├── script.sh # 可选：Shell 脚本
├── config.yaml # 可选：配置文件
└── resources/ # 可选：资源文件夹
└── template.txt
SKILL.md 是技能的核心，使用 YAML 前置元数据定义技能属性：
---
name: skill-name
description: 简短描述这个技能的用途
triggers:
- 触发关键词1
- 触发关键词2
version: 1.0.0
author: your-name
---
# Skill 名称
## 功能描述
详细说明这个 skill 要解决什么问题。
## 执行流程
1. 第一步操作说明
2. 第二步操作说明
3. 第三步操作说明
## 输出格式
说明期望的输出格式和内容。
## 注意事项
- 特殊情况处理
- 错误处理方式
如果 Skill 需要执行复杂操作，可以编写配套脚本：
# script.py 示例
import sys
def process_data(input_data):
# 处理逻辑
return result
if __name__ == "__main__":
input_data = sys.argv[1]
result = process_data(input_data)
print(result)
在 SKILL.md 中引用脚本：
## 执行步骤
1. 读取用户输入
2. 执行脚本：`python script.py {input}`
3. 返回处理结果
使用以下命令查看当前可用的技能列表：
/skills list
或查看特定技能的详细信息：
/skills info skill-name
在日常对话中，你不需要显式调用技能。[[Gemini CLI]] 会根据以下因素自动激活相关技能：
当技能被激活时，AI 会：
如果需要强制使用特定技能，可以在对话中明确指定：
使用 git-commit-helper 技能帮我生成提交信息
或使用命令：
/skills use skill-name
这个技能可以根据代码变动自动生成符合 [[Conventional Commits]] 规范的提交信息。
在 Skills 目录下创建 git-commit-helper 文件夹：
mkdir -p ~/.config/gemini/skills/git-commit-helper
cd ~/.config/gemini/skills/git-commit-helper
创建 SKILL.md 文件，内容如下：
---
name: git-commit-helper
description: 根据 git diff 生成符合 Conventional Commits 规范的提交信息
triggers:
- 提交信息
- commit message
- git commit
- 生成提交
version: 1.0.0
author: einverne
---
# Git 提交信息生成助手
## 功能说明
分析 git 暂存区的代码变动，生成符合 Conventional Commits 规范的提交信息。
## Conventional Commits 规范
提交信息格式：`<type>(<scope>): <subject>`
类型（type）：
- feat: 新功能
- fix: 修复 bug
- docs: 文档更新
- style: 代码格式调整
- refactor: 重构代码
- perf: 性能优化
- test: 测试相关
- chore: 构建工具或辅助工具的变动
## 执行流程
1. 执行 `git diff --cached` 查看暂存区变更
2. 分析变更内容，识别修改类型和影响范围
3. 确定合适的 type 和 scope
4. 生成简洁明了的 subject
5. 如有必要，添加详细的 body 和 footer
## 输出格式
2026-01-05 14:00:00
最近为了提升移动拍摄时的收音质量，我入手了 DJI Mic Mini。虽然大疆提供了带充电盒的套装，但我只购买了单机版本（发射器+接收器，2 TX 1 RX 版本），因为对于我日常的拍摄需求来说，本体的续航已经完全足够了。
之前我在室内录音主要使用 Blue Yeti，它的音质非常出色，但缺点也很明显——只能固定在室内使用，无法带出门。而当我尝试在户外使用手机直接录音时，往往会收录进大量周围的环境噪音，风声、车流声让素材的可用性大打折扣。为了解决这个痛点，轻便小巧且音质有保障的 DJI Mic Mini 就成了我的首选。
DJI Mic Mini 是一款主打轻量化的无线麦克风系统。它的发射器重量极轻，佩戴在领口几乎感觉不到重量，非常适合长时间的 Vlog 拍摄或采访。
虽然体积小巧，但它的续航能力却非常惊人。发射器单次充电可以工作约 11.5 小时，接收器也能支持约 10.5 小时。这也是我没有购买充电盒的原因——对于一天的拍摄任务来说，这个续航完全绰绰有余。而且它支持快充，充电 5 分钟就能录制 1 小时，即使偶尔忘记充电也能快速回血。
另外需要注意的是，DJI Mic Mini 有一个重要的限制：和它的姐妹产品 DJI Mic 2 不同，DJI Mic Mini 发射器没有内置存储，所以无法完全脱离接收设备独立运行。
但这并不意味着它无法独立使用，你只需要某种接收设备作为中介即可。
DJI Mic 2 内配置了存储容量，大约可以录制 14 小时 32 位浮点音频，可以完全作为独立的录制设备工作。Mic Mini 则被设计为轻量级传输设备。
让 Mic Mini 直连电脑是最佳的使用方法，可以使用 USB-C 线缆或者直接将接收器连接到电脑，在电脑中选择输入音频，选择 DJI Mic Mini 即可将电脑变成录音设备。任何支持麦克风输入的应用都可以使用，Audacity，OBS Studio，Adobe Audition，GarageBand 或 QuickTime 等等。非常适合作为播客录制，YouTube 配音，在线会议录制等等。
DJI Mic Mini 虽然可以通过蓝牙连接到手机，但是只能录制 16 bit 音频，比特深度减少意味着动态范围和音色细节显著下降。iPhone 的默认相机完全不支持蓝牙麦克风输入。必须借助第三方相机比如 Blackmagic Camera，Filmic Pro，DJI Mino 等。另外如果通过蓝牙连接那么实际传输范围缩小到 3 ~ 4 米，超过 4 米音质就会出现明显下降，需要借助接收器 2.4 GHz 无线连接才能做到 100 米收音。
DJI Mic Mini 的操作逻辑非常直观。
DJI Mic Mini 的发射器支持直接通过蓝牙连接手机，这对于手机摄影用户来说非常方便。
DJI Mic Mini-XXXXXX 并点击连接。注意：部分手机的原生相机 App 可能不支持蓝牙麦克风收音，此时可以使用第三方 App（如 Blackmagic Camera）或配合接收器使用。
如果你使用相机进行拍摄，需要配合接收器使用。
OUT 接口，另一头连接相机的麦克风输入接口（MIC）。如果你手持的是 DJI 的其他拍摄设备，Mic Mini 的体验会更加无缝。
DJI Mic Mini 以其极简的设计和可靠的性能，完美补足了我户外拍摄收音的短板。如果你也在寻找一款轻便的无线麦克风，它绝对值得考虑。
2026-01-03 14:00:00
在上一篇文章 《Vibe Kanban：当 AI 开始并行协作，我们的开发方式变了》 中，我分享了一种利用 [[Vibe Kanban]] 和 AI Agent 实现并行开发的工作流理念。我们可以利用 Vibe Kanban 来统一管理多个并行任务。
然而，除了 Vibe Kanban，我还就发现了另外一个类似的开源项目，也完美地实现了，它就是 Auto Claude。
[[Auto Claude]] 是一个自主的多 Agent 编码框架，旨在规划、构建和验证软件。简单来说，它不仅仅是一个 AI 聊天窗口，而是一个能够自主管理多个 Claude Code 实例，并让它们并行工作的桌面应用程序。
它的核心功能简直就像是照着 Vibe Kanban 的需求文档写的一样：
在之前的文章中，我描述了手动创建 Git Worktree，然后在不同目录打开 Claude Code 的繁琐过程。Auto Claude 把这个过程完全自动化了。
在 Auto Claude 中，你可以创建多个 Session（会话）。每一个 Session 实际上就是一个独立的 Agent 在工作。
这些 Agent 运行在相互独立的 Git Worktree 中，互不干扰。你不需要手动敲命令去 git worktree add，Auto Claude 会在后台帮你搞定这一切。
Auto Claude 不仅仅是写代码，它还引入了 QA Loop（质量保证循环）。
Agent 在写完代码后，会尝试运行测试或验证脚本。如果发现错误，它会自我修正，而不是把一堆报错的代码扔给你。这极大地减轻了人类 Reviewer 的负担。
它还有一个 Memory Layer（记忆层），这意味着 Agent 可以在不同的会话中保留对项目的洞察。通过 “Insights” 功能，你还可以像与技术顾问聊天一样，探索代码库、发现潜在的改进点、性能问题或安全漏洞。
Auto Claude 作为一个桌面应用，使用门槛相对较低，但由于它深度集成了 Claude Code CLI，所以还是需要一些前置条件：
npm install -g @anthropic-ai/claude-code)。安装好应用并连接项目后，你就可以体验到那种“看着一群 AI 为你打工”的快感了。界面上直观地展示了各个 Agent 的状态、当前的 Plan、以及执行的终端输出。
你不再是一个人在等待 AI 一个字一个字地吐代码，你是在管理一个团队。当一个 Agent 在思考时，你可以去检查另一个 Agent 的产出，或者去规划下一个 Feature。
虽然我们也可以手动实现 Vibe Kanban，但 Auto Claude 解决了几个痛点：
虽然 Auto Claude 看起来很美好，但在我实际使用的过程中，也发现了一些相比于手动 Vibe Kanban 的局限性，大家在入坑前需要做好心理准备：
这是 Auto Claude 目前最大的短板。它完全依赖于 Claude Code CLI 和 Anthropic 的生态。
自动化是一把双刃剑。在 Vibe Kanban 中，每一个 Agent 都是我手动启动的，我清楚地知道我喂给了它什么上下文。 而在 Auto Claude 中，Agent 的规划和执行是自主的。有时候你会发现它陷入了死循环，或者在不需要修改的文件里乱改一通。虽然有 QA Loop，但这种“不知它在干什么”的黑盒感，对于控制欲强的开发者来说可能是一种折磨。
虽然它是桌面应用，但它依赖 Python 3.12+、Node.js 环境以及特定的 Git 配置。社区中也有不少用户反馈安装失败或环境冲突的问题。相比之下，Vibe Kanban 只需要你懂 git worktree 和任意一个 AI 聊天窗口，几乎零成本启动。
如果说 Vibe Kanban 是一种道（方法论），那么 Auto Claude 就是一把趁手的器（工具），但目前这把器还需要打磨。
它通过将 Git Worktree 的隔离能力 与 Claude 的推理能力 以及 自动化脚本 完美结合，让单人开发团队的生产力倍增成为可能。但它也牺牲了灵活性，增加了对特定供应商的依赖。
我的建议是：
无论如何，“Human-in-the-loop, AI-driven parallel development” （人在环中，AI 驱动的并行开发）无疑是未来的方向。
2026-01-01 14:00:00
在我之前的视频当中，我介绍过在 Claude Code 中使用子代理（Subagents）机制和 Git Worktree 来实现并行工作流。我们可以创建子代理来并行执行任务，但是 Subagents 的配置和使用都还需要我们在 Claude Code 中等待。那如果我们有完全独立的两个任务要执行呢，我们可以开两个 Claude Code 分别在两个 Claude Code 中提交任务，然后让 Claude Code 完成。此时我们依然会遇到一些问题，比如说两个 Claude Code 的代码可能产生冲突。并且如果我们有超过两个独立任务时，我们在管理 Claude Code 的成本就会指数级上升。
那么今天要介绍的这个工具就是为了解决上述的问题而诞生的，它的名字叫做 [[Vibe Kanban]]。
简单来说，Vibe Kanban 是一种将 AI Agent（如 Claude Code、Codex、Aider 等）与 Git Worktree 技术深度结合的开发工作流方案。
它的核心理念是将“看板管理”引入 AI 开发：
这让开发者从“写代码的人”转变为“指挥官”，从排队等待 AI 生成代码，进化到多线程并行推进项目进度。
传统的 Claude Code，Codex 使用本质上还是「结对编程」（Pair Programming）的概念，也就是和 AI 同坐在同一台电脑前，如果 AI 不结束当前的任务，就没有办法开始下一个。Claude Code 虽然已经非常强大可以快速实现代码，但在同一个时间窗口内只能等待。
而 Vibe Kanban 的引入，通过一种巧妙的方式解决了这个问题：完全并行。
我可以在看板中创建多个任务，例如：
它们相互不干扰，可以同时进行。这不仅是效率的提升，更是工作流的质变。
其实在我之前的文章当中，我也介绍过非常多的 Claude Code 实例管理器，比如 Claudia，Crystal，但每一个用起来都或多或少有一些小问题，使用体验远远不如 Vibe Kanban。
那么接下来我们就详细介绍一下 Vibe Kanban。
在传统的软件开发流程中，我们习惯了线性工作。改完代码 -> 跑测试 -> 提交。即使是人类团队协作，也往往需要通过 Git 分支来隔离工作，避免互相踩脚。
而目前的 AI 编程工具，大多是基于单个上下文的。你打开一个 IDE 窗口，AI 就只能”看到”和”操作”这个窗口里的文件。如果你想让它同时干两件事，通常得打开两个 IDE 窗口，分别手动切换分支，还得小心翼翼地管理它们，非常麻烦。
Vibe Kanban（或者说这类理念）的核心在于结合了两个关键技术：
通过将每一个 AI Agent 分配到一个独立的 Git Worktree 中，我们实际上是为每一个 AI 创造了一个”平行的时空”。它们共享同一个 .git 历史，但拥有完全独立的文件系统工作区。
Vibe Kanban 的核心优势在于环境隔离。
以往我们尝试让 AI 并行，最大的痛点是文件锁冲突或者 Git 索引冲突。但在 Vibe Kanban 的架构下：
/workspace/frontend-feature 目录（对应 git worktree A）/workspace/backend-api 目录（对应 git worktree B）/workspace/test-runner 目录（对应 git worktree C）它们可以在同一时间修改同一个项目，而不会因为文件被占用而报错。
之所以叫 “Kanban”（看板），是因为这种模式通常配套一个可视化的任务管理界面。
在这个界面上，你不再是写代码的人，你是 Product Manager (PM) 兼 Tech Lead。
这种感觉非常奇妙，你是在指挥一场战役，而不是在亲自拼刺刀。
刚开始尝试这种模式时，最直观的感受是速度。不是代码生成速度变快了，而是等待时间被填满了。
以前 AI 写后端逻辑时，我只能干等着。现在，我把它丢给 Backend Agent，转头就去告诉 Frontend Agent 页面该怎么画。等我布置完前端任务，后端代码可能已经写好提交了。
想自己动手尝试一下？虽然 Vibe Coding 还没有完全普及的开箱即用工具，但我们可以通过手动组合现有工具来复刻这个流程。
首先，不要在主目录直接干活，我们要为不同的角色创建各自的”办公室”（Worktree）。
假设你的项目叫 my-app，你可以这样组织目录：
# 1. 创建主项目目录
mkdir my-app-vibe
cd my-app-vibe
# 2. 克隆你的项目到 base 目录
git clone [email protected]:username/my-app.git base
cd base
现在，我们要分配任务了。假设你要开发一个”用户评论功能”，需要同时动前端和后端。
# 为后端任务创建分支和 worktree
git worktree add ../backend-task feature/comments-api
# 为前端任务创建分支和 worktree
git worktree add ../frontend-task feature/comments-ui
此时，你的 my-app-vibe 目录下会有三个文件夹：
base/：主仓库，用于合并代码。backend-task/：给后端 AI 用的独立工作区。frontend-task/：给前端 AI 用的独立工作区。现在是最酷的部分。你可以打开两个终端窗口，或者两个 IDE 实例（VS Code 支持 code folder_path）。
对于后端 AI (在 backend-task 目录)：
“请基于当前的数据库结构，在
src/api中添加评论相关的 CRUD 接口。请确保遵循 RESTful 规范，并添加单元测试。”
对于前端 AI (在 frontend-task 目录)：
“我需要一个评论组件，请在
src/components下创建。API 接口假设为POST /api/comments，具体字段参考我给你的这个 JSON 结构…”
这时候，两个 AI 就像两个坐在不同工位的同事，互不干扰地修改代码。Git Worktree 保证了后端 AI 修改 API 文件时，前端 AI 的目录里文件并不会变，避免了实时的冲突。
当两个 AI 都汇报”任务完成”后：
backend-task 跑测试，确认 API 正常，提交代码 (git commit)。frontend-task 运行 Storybook 或 dev server，确认 UI 正常，提交代码。cd ../base
git merge feature/comments-api
git merge feature/comments-ui
如果有冲突（通常在 routes 注册或公共配置文件上），这时候才是你这个 Tech Lead 出手解决冲突的时候。
要实现或者模拟 Vibe Kanban 的工作流，其实不一定非要等到成熟的商业软件，我们利用现有的工具也可以尝试这种 workflow。
这里分享几个我在实践中的具体操作建议：
如果你也是命令行重度用户，可以先习惯 Git Worktree。比如，当你需要修复一个 Bug，但当前分支的工作还没做完：
# 以前的做法：git stash -> git checkout -> fix -> commit -> git checkout -> git stash pop
# 现在的做法：
git worktree add ../hotfix-branch hotfix/login-bug
cd ../hotfix-branch
# 在这个新目录里让 AI 尽情修改，原目录不受任何影响
对于 AI Agent 工具，确保它们能指定”工作目录”（Working Directory）。
并行开发最大的挑战是前后端协作。如果 Frontend Agent 和 Backend Agent 同时开工，它们怎么知道 API 长什么样？
我的经验是：先定接口，再并行。
api-spec.json 或者 Swagger 文档。这样两个 AI 才能在最后顺利会师（Merge）。
给负责测试的 AI 分配 Worktree 时，要注意数据库等外部依赖的隔离。如果所有 Agent 都连同一个本地数据库，跑测试的 AI 可能会把开发 AI 刚写入的数据清空，导致混乱。使用 Docker 容器为每个 Worktree 起独立的数据库实例是一个好办法。
因为使用了可视化的 Vibe Kanban，这也就意味着放弃了在 CLI 当中的一些优势。比如说，我们可以在 Claude Code 当中：使用 Slash Commands，或者调用增强的 Plan 模式，在Vibe Kanban 当中是不能执行的。
Vibe Kanban 给我们展示的不仅仅是一个新工具，而是一种新的人机协作形态。
在这个形态下，程序员的职责发生了根本性的转移：
我们不再纠结于具体的语法细节，而是专注于架构设计、任务拆解和质量把控。每一个独立的 Git Worktree 里，都有一个不知疲倦的数字员工在为你工作。这种”指挥千军万马”的感觉，或许就是 AI 时代赋予开发者的终极浪漫。这仅仅是个开始，期待未来能有更多原生支持这种模式的 IDE 出现。
