docs: 更新 Claude Code 插件指南 + 新增开发参考文档
Claude Code插件高效运用指南.md： 1、补充遗漏的内置 Skills（schedule/update-config/keybindings-help） 2、新增第三方 Skills 记录（find-skills/tmux/summarize/tavily-research/embedded-systems） 3、新增第八章：新电脑环境恢复指南（含 ESP-IDF v5.4.2 安装步骤） 4、新增步骤 3.1：第三方 Skills 安装命令 新增文档： 5、Claude Code 十个最值得装的 Skills copy.md — 微信文章内容存档 6、资深嵌入式工程师开发思维.md — 嵌入式开发核心思维与注意事项 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
parent
0bdf7be875
commit
b35d86f84c
281
Claude Code 十个最值得装的 Skills copy.md
Normal file
281
Claude Code 十个最值得装的 Skills copy.md
Normal file
@ -0,0 +1,281 @@
|
||||
我已将整理好的内容保存为 Markdown 文档。您可以直接复制以下内容，或通过 sandbox:/mnt/data/Claude_Code_十个最值得装的_Skills.md 下载该文件。
|
||||
|
||||
# Claude Code 十个最值得装的 Skills：不是越多越能打，是这 10 个最能打！
|
||||
|
||||
很多人以为，Claude Code 好不好用，主要取决于模型够不够强。但用久了你会发现，真正把人和人拉开差距的，往往不是模型本身，而是另一层东西：**你有没有把一批高频、稳定、可复用的 skills 装进自己的工作流。**
|
||||
|
||||
同样一个 Claude Code，有的人拿它写几个函数、改几段文案；有的人已经让它跑浏览器、查资料、整理文档、控制终端、维护测试、辅助重构。差别不只是会不会写提示词，而是有没有把外部能力接进来，让它从“会回答”变成“会做事”。
|
||||
|
||||
所以这篇文章不想讨论哪个模型分数更高，也不想给你堆一串目录。我只想回答一个更实际的问题：**如果你在用 Claude Code，最值得优先装的 10 个 skills 到底是什么？**
|
||||
|
||||
**我的筛选标准很简单，就三个：**
|
||||
|
||||
1. 是不是真的能装进 Claude Code 生态
|
||||
2. 会不会高频用到
|
||||
3. 能不能明显提升结果，而不只是看起来很酷
|
||||
|
||||
按这个标准，下面这 10 个最值得优先配。
|
||||
|
||||
## Part.01 agent-browser：把 Claude Code 从代码编辑器里放出来
|
||||
|
||||
如果只选一个最值得优先装的 skill，我会把票投给它。
|
||||
|
||||
原因很简单。很多真实工作，根本不发生在终端里，也不发生在代码文件里，而是发生在网页上。你要登录后台、点按钮、填表单、截图、抓页面信息、测试 Web App、跑自动化流程，这些事都离不开浏览器。
|
||||
|
||||
大多数人对 Claude Code 的理解还停留在“会写代码”。但一旦你接上浏览器能力，它就不只是会写，还能执行。它可以先打开页面，再识别交互元素，然后点击、输入、等待页面更新，最后把结果拉回来。这种能力一接上，Claude Code 才真正从一个 coding assistant 开始往 agent 走。
|
||||
|
||||
它的价值不在“会打开网页”，而在于它把网页操作变成了 Claude Code 可以连续执行的一条工作流。做测试的人会用到，做调研的人会用到，做运营、抓取、后台操作的人也会用到。只要你的工作里有网站，这个 skill 就很难闲着。
|
||||
|
||||
**推荐入口：**
|
||||
|
||||
页面：https://skills.sh/vercel-labs/agent-browser/agent-browser
|
||||
|
||||
安装命令：
|
||||
```bash
|
||||
npx skills add vercel-labs/agent-browser@agent-browser -g -y
|
||||
```
|
||||
|
||||
## Part.02 find-skills：先别急着造轮子，先学会找轮子
|
||||
|
||||
很多人 skill 装得少，不是因为不需要，而是因为不知道有什么能装。
|
||||
|
||||
这就是这种 skill 的意义。它像 Claude Code 生态里的技能搜索入口。你想做某件事，但不确定有没有现成方案，它能帮你从 skills 生态里先把答案翻出来。这个能力看起来不直接，但长期特别值钱。
|
||||
|
||||
因为使用 AI 工具最浪费时间的一件事，不是执行，而是“重复摸索”：
|
||||
* 这个事到底有没有现成 skill？
|
||||
* 我要不要自己写？
|
||||
* 有没有别人已经沉淀好的流程？
|
||||
* 这个方向是不是已经有成熟模板？
|
||||
|
||||
`find-skills` 解决的就是这个问题。它本身不直接产出网页、代码或文档，但它会极大降低你探索生态的成本。你可以把它理解成“技能层的搜索引擎”。对于想把 Claude Code 用深的人来说，这个 skill 不是锦上添花，而是效率入口。
|
||||
|
||||
页面：https://skills.sh/vercel-labs/skills/find-skills
|
||||
|
||||
安装：
|
||||
```bash
|
||||
npx skills add vercel-labs/skills@find-skills -g -y
|
||||
```
|
||||
|
||||
## Part.03 summarize：信息时代最稀缺的，不是内容，是压缩能力
|
||||
|
||||
它是那种非常实用、但又经常被低估的 skill。
|
||||
|
||||
**很多人高估了生成，低估了压缩。** 但现实工作里，你真正缺的往往不是“多写一段”，而是“把一堆杂乱信息压成能用的结论”。
|
||||
|
||||
网页太长，读不完。播客太长，听不完。文档太多，筛不完。会议记录太碎，理不顺。这时候 `summarize` 的价值就出来了。
|
||||
|
||||
它最适合处理：
|
||||
* 长网页
|
||||
* 长文档
|
||||
* 播客或视频转录
|
||||
* 研究材料
|
||||
* 多篇资料汇总
|
||||
* 会议纪要整理
|
||||
|
||||
对开发者来说，它能帮你快速读文档、读 RFC、读 issue 讨论；对产品和内容工作者来说，它能帮你快速提炼观点、抽出框架、形成判断。一个好用的 Claude Code，不应该只会写，而应该会读、会压、会提炼。`summarize` 让这件事变得更稳定。
|
||||
|
||||
页面：https://skills.sh/steipete/clawdis/summarize
|
||||
|
||||
安装：
|
||||
```bash
|
||||
npx skills add steipete/clawdis@summarize -g -y
|
||||
```
|
||||
|
||||
## Part.04 skill-creator：真正高阶的用法，是把自己的工作流做成 skill
|
||||
|
||||
所有会长期用 Claude Code 的人，最后都会走到这一步：不再满足于只装别人做好的东西，而开始把自己的工作方式沉淀成 skill。这就是它的价值。
|
||||
|
||||
今天你可能反复在做这些动作：
|
||||
* 写提纲
|
||||
* 改标题
|
||||
* 统一格式
|
||||
* 补测试
|
||||
* 生成 release notes
|
||||
* 拆分任务步骤
|
||||
|
||||
如果某个动作一周会重复很多次，那它就值得被固化。`skill-creator` 做的，就是把这些重复动作从“零散经验”变成“可复用流程”。
|
||||
|
||||
这件事的意义很大。因为当 Claude Code 开始复用你的工作流，它就不再只是一个会听命令的助手，而更像一个逐渐熟悉你做事方式的同事。你沉淀得越多，它的产出越稳定。对重度用户来说，`skill-creator` 不只是一个工具，而是把经验转化成资产的开始。
|
||||
|
||||
页面：https://skills.sh/anthropics/skills/skill-creator
|
||||
|
||||
安装：
|
||||
```bash
|
||||
npx skills add anthropics/skills@skill-creator -g -y
|
||||
```
|
||||
|
||||
## Part.05 tmux：真正的深度使用者，迟早要接管终端会话
|
||||
|
||||
如果你平时只做轻量任务，那它可能没那么显眼。但如果你开始跑长任务、远程机、交互式 CLI、持续观察日志，`tmux` 的价值会一下子变得很大。
|
||||
|
||||
Claude Code 最大的问题之一，不是它不会执行，而是很多复杂工作并不是“一条命令跑完就结束”。现实里你经常会遇到：
|
||||
* 命令要跑很久
|
||||
* 过程要持续观察
|
||||
* 中途要交互输入
|
||||
* 多个任务要并行
|
||||
* 远端环境不能轻易断开
|
||||
|
||||
这时候，`tmux` 这种 skill 就不是可有可无，而是稳定性保障。它让 Claude Code 不只是“执行一次”，而是可以持续控制一个已经存在的终端环境。这种能力特别适合开发、运维、远程任务、批处理场景。对高级用户来说，收益非常高。
|
||||
|
||||
页面：https://skills.sh/steipete/clawdis/tmux
|
||||
|
||||
安装：
|
||||
```bash
|
||||
npx skills add steipete/clawdis@tmux -g -y
|
||||
```
|
||||
|
||||
## Part.06 testing / e2e / playwright 类 skills：让 Claude Code 不只是写代码，还能写可靠代码
|
||||
|
||||
如果你做前端、Web 应用、自动化测试，那么 `testing` / `e2e` / `playwright` 这一类 skill 很值得优先配。
|
||||
|
||||
Claude Code 本来就擅长写和修改测试，但裸用模型有个常见问题：能写出来，不代表写得稳定、清晰、可维护。加上这类 skill 之后，它在下面这些事情上通常会稳很多：
|
||||
* 测试结构怎么组织
|
||||
* 断言怎么写更有意义
|
||||
* 边界条件怎么覆盖
|
||||
* Playwright 用例怎么更像真实场景
|
||||
* 哪些测试值得保留，哪些测试只是噪音
|
||||
|
||||
你可以把这类 skill 理解成“给 Claude Code 加了一层测试工程经验”。如果你的项目本身依赖自动化测试，这类 skill 的收益会非常直接，而且是长期收益。
|
||||
|
||||
页面：https://skills.sh/anthropics/skills/webapp-testing
|
||||
|
||||
安装：
|
||||
```bash
|
||||
npx skills add anthropics/skills@webapp-testing -g -y
|
||||
```
|
||||
|
||||
备选：https://skills.sh/supercent-io/skills-template/testing-strategies
|
||||
|
||||
## Part.07 docs / readme / api-docs 类 skills：技术文档不是附属品，是项目可维护性的一部分
|
||||
|
||||
这类 skill 特别适合 Claude Code。因为 Claude Code 很擅长理解已有代码和结构，再把它整理成文档。问题在于，如果没有一套约束，它写出来的文档很容易“看着完整，实际上没重点”。`docs` / `readme` / `api-docs` 这类 skill 的价值，就是给它一套文档组织框架，让它更像一个靠谱的技术写作者，而不是只会堆字。
|
||||
|
||||
这类 skill 很适合以下场景：
|
||||
* 补 README
|
||||
* 整理 API 文档
|
||||
* 给项目写上手说明
|
||||
* 给团队补内部文档
|
||||
* 把零散说明统一格式
|
||||
|
||||
文档类工作很少有人喜欢做，但项目往往因为文档差而掉效率。Claude Code 在这个方向上本来就有天赋，只是需要一套更像样的模板去约束。装上这一类 skill，收益非常稳定。
|
||||
|
||||
> **注意**：这一类不是一个统一 skill 名，得按你写什么文档来选。
|
||||
|
||||
**推荐入口：**
|
||||
页面：https://skills.sh/googleworkspace/cli/gws-docs
|
||||
安装：
|
||||
```bash
|
||||
npx skills add googleworkspace/cli@gws-docs -g -y
|
||||
```
|
||||
|
||||
**更佳建议**：`docs` 这一类我建议你按语言/场景再细分搜，比如：
|
||||
* `api docs`
|
||||
* `readme`
|
||||
* `java docs`
|
||||
* `python docs`
|
||||
|
||||
## Part.08 refactor / review / best-practices 类 skills：让它更像资深工程师，而不只是补代码的人
|
||||
|
||||
这类 skill 的意义在于，它给 Claude Code 增加了一层“工程判断模板”。平时你让模型改代码，它可能能改对，但不一定改得像团队里的资深工程师。它可能修了 bug，却没顺手整理结构；可能完成了功能，却留下了可读性和维护性问题。`refactor` / `review` / `best-practices` 这类 skill，就是在把“能用”往“更专业”推一步。
|
||||
|
||||
它们通常会强化这些能力：
|
||||
* 识别代码坏味道
|
||||
* 拆大函数
|
||||
* 收敛重复逻辑
|
||||
* 改善命名
|
||||
* 降低复杂度
|
||||
* 按最佳实践做结构调整
|
||||
|
||||
如果你的工作不是一次性写 demo，而是长期维护代码库，这类 skill 很值得长期挂着。因为它们解决的不是“做不做得出来”，而是“做出来以后能不能长期维护”。
|
||||
|
||||
页面：https://skills.sh/supercent-io/skills-template/code-refactoring
|
||||
|
||||
安装：
|
||||
```bash
|
||||
npx skills add supercent-io/skills-template@code-refactoring -g -y
|
||||
```
|
||||
|
||||
备选：https://skills.sh/github/awesome-copilot/refactor
|
||||
|
||||
## Part.09 git-workflow / changelog / release 类 skills：把那些烦但必须做的事交给它
|
||||
|
||||
如果你经常提 PR、写提交、发版本、整理 changelog，那么这类 skill 会特别省时间。
|
||||
|
||||
Claude Code 做这类工作有天然优势：它能读 diff、能理解改动范围、能总结重点、能按结构输出。很多时候真正烦人的不是开发本身，而是开发之后那一串“必须做、但没人爱做”的环节：
|
||||
* commit message 怎么写更规范
|
||||
* changelog 怎么整理
|
||||
* release note 怎么写给人看
|
||||
* PR 描述怎么说清楚影响范围
|
||||
* 分支和提交流程怎么更统一
|
||||
|
||||
这类 skill 的价值就在于，它让 Claude Code 不只是参与“写代码”，还参与“交付代码”。对于团队协作来说，这是很实用的一层。
|
||||
|
||||
页面：https://skills.sh/supercent-io/skills-template/changelog-maintenance
|
||||
|
||||
安装：
|
||||
```bash
|
||||
npx skills add supercent-io/skills-template@changelog-maintenance -g -y
|
||||
```
|
||||
|
||||
备选：https://skills.sh/wshobson/agents/changelog-automation
|
||||
|
||||
## Part.10 research / web-search / extract 类 skills：别把 Claude Code 只当 coder，它其实也是研究助理
|
||||
|
||||
Claude Code 常被看作 coding agent，但实际上，它在调研型任务上也很强。特别是当你给它配上 `research` / `web-search` / `extract` 这类 skill，它就不只是“写代码”，而是开始承担：
|
||||
* 查资料
|
||||
* 读网页
|
||||
* 提取信息
|
||||
* 比较方案
|
||||
* 形成结构化判断
|
||||
|
||||
这对开发者特别有价值。你做技术选型的时候，要比较框架；你接新库的时候，要读文档；你判断方案时，要看 issue、看经验贴、看不同实践。Claude Code 如果只会写，它的价值只发挥了一半；一旦它会搜、会读、会摘、会比，它才真正变成一个研究助理。
|
||||
|
||||
**推荐（优先用 Tavily）：**
|
||||
页面：https://skills.sh/tavily-ai/skills/research
|
||||
|
||||
安装：
|
||||
```bash
|
||||
npx skills add tavily-ai/skills@research -g -y
|
||||
```
|
||||
|
||||
备选：https://skills.sh/199-biotechnologies/claude-deep-research-skill/deep-research
|
||||
|
||||
## 最后：别先追求“装很多”，先追求“装进去之后会反复用”
|
||||
|
||||
如果只给一个建议，我会说：**别把 skill 当收藏夹，先把高频用得上的装起来。**
|
||||
|
||||
很多人最容易走两个极端：
|
||||
* 一个是完全不装
|
||||
* 一个是装一堆，结果十天半个月都不调一次
|
||||
|
||||
真正有价值的 skill，一般都有一个共同点：**你装进去之后，会在很多不同任务里反复调用。**
|
||||
|
||||
从这个角度看：
|
||||
* `agent-browser` 解决网页执行
|
||||
* `summarize` 解决信息压缩
|
||||
* `find-skills` 解决技能发现
|
||||
* `skill-creator` 解决工作流沉淀
|
||||
* `tmux` 解决长会话控制
|
||||
* `testing` / `docs` / `refactor` / `git` / `research` 这些，则是在把 Claude Code 从“会写代码”推向“能承担完整工作流”。
|
||||
|
||||
所以，Claude Code 的 skill 体系，不该被理解成一个插件市场。**更准确地说，它是一套外置能力系统。你装进去的，不只是功能，而是你希望 Claude Code 以后替你承担的那部分工作方式。**
|
||||
|
||||
如果你现在刚开始配，我建议优先顺序就按这三个梯队来：
|
||||
|
||||
**第一梯队**
|
||||
* `agent-browser`
|
||||
* `summarize`
|
||||
* `find-skills`
|
||||
（一个负责执行网页任务，一个负责压缩信息，一个负责扩展生态。先把这三件事跑顺，Claude Code 的可用性会立刻上一个台阶。）
|
||||
|
||||
**第二梯队**
|
||||
* `skill-creator`
|
||||
* `tmux`
|
||||
|
||||
**第三梯队**
|
||||
* `testing` / `docs` / `refactor` 类 skills
|
||||
* `git-workflow` 类 skills
|
||||
* `research` 类 skills
|
||||
（前者解决“能不能用”，后者解决“能不能用深”。）
|
||||
|
||||
总之，Claude Code 的上限，不只是模型决定的，更是你给它配了哪一组 skills 决定的。
|
||||
@ -1,6 +1,6 @@
|
||||
# Claude Code 插件高效运用指南
|
||||
|
||||
> 更新日期: 2026-03-19（skill-creator 补充）
|
||||
> 更新日期: 2026-04-01（补充遗漏的内置 Skills 和命令）
|
||||
> 适用环境: macOS / Claude Code 2.1.37+ / ESP32 嵌入式开发
|
||||
|
||||
---
|
||||
@ -11,8 +11,9 @@
|
||||
|------|------|------|
|
||||
| 官方插件 (claude-plugins-official) | 7 个 | Git 工作流、代码审查、功能开发、迭代循环、规则维护、Skill 创建 |
|
||||
| 社区插件 (claude-code-settings) | 2 个 | 长时任务自主执行、规格驱动开发 |
|
||||
| 自定义 Skills (~/.claude/skills/) | 10 个 | ESP32 专用 6 个 + RK3588/Linux 驱动 4 个 |
|
||||
| 内置 Skills | 3 个 | simplify、loop、claude-api |
|
||||
| 自定义 Skills (~/.claude/skills/) | 11 个 | ESP32 专用 6 个 + RK3588/Linux 驱动 4 个 + 硬件驱动工作流 1 个 |
|
||||
| 第三方 Skills (~/.claude/skills/) | 5 个 | find-skills、tmux、summarize、tavily-research、embedded-systems |
|
||||
| 内置 Skills | 6 个 | simplify、loop、claude-api、schedule、update-config、keybindings-help |
|
||||
|
||||
---
|
||||
|
||||
@ -35,6 +36,10 @@
|
||||
| `/skill-creator` | skill-creator | **元技能**：交互式创建、测试、优化自定义 Skills |
|
||||
| `/simplify` | 内置 | 审查代码复用性、质量和效率 |
|
||||
| `/loop` | 内置 | 定时循环执行命令（如每 5 分钟检查一次） |
|
||||
| `/schedule` | 内置 | 创建/管理定时远程 Agent（cron 定时任务） |
|
||||
| `/update-config` | 内置 | 配置 settings.json 的 hooks 自动化行为 |
|
||||
| `/keybindings-help` | 内置 | 自定义 Claude Code 键盘快捷键 |
|
||||
| `/ralph-loop help` | ralph-loop | 查看 Ralph Loop 插件说明和可用命令 |
|
||||
|
||||
---
|
||||
|
||||
@ -393,6 +398,87 @@ allowed-tools: Bash, Read, Grep, Glob # 可选，限制可用工具
|
||||
|
||||
---
|
||||
|
||||
### 场景 8：定时任务与远程 Agent
|
||||
|
||||
#### `/schedule` — 定时远程 Agent
|
||||
|
||||
**何时用**：需要周期性自动执行任务（如定时检查构建状态、定期代码审查、自动同步等）
|
||||
|
||||
**使用方式**：
|
||||
```
|
||||
你：/schedule # 查看和管理定时任务
|
||||
你：/schedule create # 创建新的定时 Agent
|
||||
你：/schedule list # 列出所有已创建的定时任务
|
||||
你：/schedule run <trigger-name> # 手动触发执行一次
|
||||
```
|
||||
|
||||
**工作原理**：
|
||||
- 基于 cron 表达式定义执行周期
|
||||
- 每次触发时启动一个远程 Agent（headless 模式）
|
||||
- Agent 执行完毕后自动停止，下次 cron 时间到达再启动
|
||||
|
||||
**ESP32 项目实际用例**：
|
||||
```
|
||||
# 每天早上 9 点自动检查代码规范
|
||||
你：/schedule create "每天 9:00 运行 /code-review 检查未提交的代码"
|
||||
|
||||
# 每周一自动审计 CLAUDE.md
|
||||
你：/schedule create "每周一 /claude-md-improver"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 场景 9：配置自动化与快捷键
|
||||
|
||||
#### `/update-config` — 配置 hooks 自动化行为
|
||||
|
||||
**何时用**：需要设置自动化行为，如"每次提交前自动运行 lint"、"每次保存文件后自动格式化"
|
||||
|
||||
**使用方式**：
|
||||
```
|
||||
你：/update-config
|
||||
你：帮我配置一个 hook，每次执行 Edit 工具后自动检查代码风格
|
||||
```
|
||||
|
||||
**工作原理**：
|
||||
- 修改 `~/.claude/settings.json` 中的 hooks 配置
|
||||
- Hooks 是 Claude Code 的事件钩子系统，在特定事件（工具调用前/后、会话开始/结束等）自动执行 shell 命令
|
||||
- 与 Skills 的区别：Skills 影响 Claude 的行为，Hooks 是在 Claude 行为之外自动执行的外部命令
|
||||
|
||||
**配置示例**：
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"PostToolUse": [
|
||||
{
|
||||
"matcher": "Edit",
|
||||
"command": "echo '文件已修改'"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### `/keybindings-help` — 自定义键盘快捷键
|
||||
|
||||
**何时用**：想修改 Claude Code 的默认快捷键，或添加自定义快捷键组合
|
||||
|
||||
**使用方式**：
|
||||
```
|
||||
你：/keybindings-help
|
||||
你：帮我把提交快捷键改为 Ctrl+S
|
||||
你：添加一个 chord 快捷键
|
||||
```
|
||||
|
||||
**工作原理**：
|
||||
- 修改 `~/.claude/keybindings.json` 文件
|
||||
- 支持单键绑定和 chord 组合键（如 `Ctrl+K, Ctrl+C`）
|
||||
- 可覆盖默认快捷键或新增自定义绑定
|
||||
|
||||
---
|
||||
|
||||
## 四、ESP32 项目推荐工作流
|
||||
|
||||
### 日常开发流程
|
||||
@ -468,7 +554,16 @@ allowed-tools: Bash, Read, Grep, Glob # 可选，限制可用工具
|
||||
| rk3588-troubleshoot | 你描述驱动不工作、设备不识别、内核崩溃 |
|
||||
| simplify | 通过 /simplify 调用 |
|
||||
| loop | 通过 /loop 调用 |
|
||||
| claude-api | 涉及 Anthropic SDK 开发 |
|
||||
| claude-api | 涉及 Anthropic SDK 开发（import anthropic / @anthropic-ai/sdk） |
|
||||
| schedule | 通过 /schedule 调用，或提到"定时任务"、"cron"、"定期执行" |
|
||||
| update-config | 通过 /update-config 调用，或提到"配置 hooks"、"自动化行为"、"settings.json" |
|
||||
| keybindings-help | 通过 /keybindings-help 调用，或提到"快捷键"、"键盘绑定"、"rebind" |
|
||||
| **hw-driver-workflow** | 提供原理图/数据手册/参考代码，或说"帮我写驱动"、"适配芯片"、"分析原理图" |
|
||||
| **find-skills** | 说"有没有xxx的Skill"、"找一个Skill" |
|
||||
| **summarize** | 说"总结"、"压缩"、提供长文档/URL 要求提取关键信息 |
|
||||
| **tavily-research** | 说"调研"、"搜索"、"查一下xxx的资料"、需要在线查找技术方案 |
|
||||
| **tmux** | 需要监控终端日志、长时间编译、远程会话管理 |
|
||||
| **embedded-systems** | 涉及固件开发、RTOS、中断处理、DMA、功耗优化、裸机编程、volatile 声明等通用嵌入式工程原则 |
|
||||
|
||||
### ESP32 Skills 与插件配合
|
||||
|
||||
@ -501,3 +596,138 @@ allowed-tools: Bash, Read, Grep, Glob # 可选，限制可用工具
|
||||
5. **插件更新**：运行 `claude plugins update` 可更新所有插件到最新版本
|
||||
6. **`/skill-creator` 资料质量决定 Skill 质量**：喂入的文档越专业、越详细，生成的 Skill 审查清单和排障表越准确。建议提供官方文档 + 实战踩坑经验的组合
|
||||
7. **Skill 持续迭代**：首次创建的 Skill 不一定完美，随着实际开发中遇到新问题，持续补充更新 SKILL.md（类似你现有 ESP32 Skills 的演进过程）
|
||||
8. **`/schedule` 定时任务**：需要网络连接才能触发远程 Agent，离线环境下无法使用
|
||||
9. **`/update-config` 修改 hooks**：hooks 配置错误可能阻塞工具调用，修改前建议备份 `settings.json`
|
||||
10. **快捷键配置文件**：位于 `~/.claude/keybindings.json`，格式错误会导致快捷键失效
|
||||
|
||||
---
|
||||
|
||||
## 七、文件路径速查
|
||||
|
||||
| 文件 | 路径 | 说明 |
|
||||
|------|------|------|
|
||||
| 全局规则 | `~/.claude/CLAUDE.md` | 所有项目通用的指令规则 |
|
||||
| 插件配置 | `~/.claude/settings.json` | enabledPlugins、hooks、permissions |
|
||||
| 快捷键 | `~/.claude/keybindings.json` | 自定义键盘快捷键 |
|
||||
| 自定义 Skills | `~/.claude/skills/<name>/SKILL.md` | 个人全局 Skills |
|
||||
| 项目级 Skills | `.claude/skills/<name>/SKILL.md` | 仅当前项目生效 |
|
||||
| 项目级规则 | `.claude/CLAUDE.md` 或项目根 `CLAUDE.md` | 项目专属指令 |
|
||||
| 自动记忆 | `~/.claude/projects/<path>/memory/` | 跨会话持久化记忆 |
|
||||
| 官方插件缓存 | `~/.claude/plugins/cache/claude-plugins-official/` | 下载的插件文件 |
|
||||
| 社区插件缓存 | `~/.claude/plugins/cache/claude-code-settings/` | 第三方插件文件 |
|
||||
|
||||
---
|
||||
|
||||
## 八、新电脑环境恢复指南
|
||||
|
||||
### 8.1 开发环境信息
|
||||
|
||||
| 环境 | 版本 | 说明 |
|
||||
|------|------|------|
|
||||
| **ESP-IDF** | **v5.4.2** | 路径：`~/esp/esp-idf/v5.4.2/esp-idf/` |
|
||||
| Claude Code | 最新版（npm 安装） | 当前 v2.1.79 |
|
||||
| Node.js | 16+ | Claude Code 运行依赖 |
|
||||
| Python | 3.8+ | ESP-IDF 构建依赖 |
|
||||
| 操作系统 | macOS | ESP-IDF 通过 `export.sh` 激活环境 |
|
||||
|
||||
### 8.2 恢复步骤
|
||||
|
||||
#### 步骤 1：安装 Claude Code
|
||||
|
||||
```bash
|
||||
npm install -g @anthropic-ai/claude-code
|
||||
```
|
||||
|
||||
#### 步骤 2：恢复用户数据
|
||||
|
||||
如果 `~/.claude/` 目录已通过 Git 备份：
|
||||
|
||||
```bash
|
||||
# 方式 A：直接 clone 到 ~/.claude/
|
||||
git clone <你的仓库地址> ~/.claude
|
||||
|
||||
# 方式 B：已有 ~/.claude/ 目录（Claude Code 安装后自动创建）
|
||||
cd ~/.claude
|
||||
git init
|
||||
git remote add origin <你的仓库地址>
|
||||
git fetch origin
|
||||
git checkout -f main
|
||||
```
|
||||
|
||||
恢复后自动生效的内容（无需额外操作）：
|
||||
- `CLAUDE.md` — 全局规则（ESP32/LVGL/BLE/RTC 开发经验）
|
||||
- `skills/` — 11 个自定义 Skills（ESP32×6 + RK3588×3 + Android HAL + 硬件驱动工作流）
|
||||
- `settings.json` — 插件开关配置
|
||||
- `projects/*/memory/` — 各项目跨会话记忆
|
||||
|
||||
#### 步骤 3：重新安装插件
|
||||
|
||||
`settings.json` 中记录了插件开关，但插件代码（`plugins/cache/`）未纳入 Git 备份，需要重新下载：
|
||||
|
||||
```bash
|
||||
# 官方插件（7 个）
|
||||
claude plugins install commit-commands@claude-plugins-official
|
||||
claude plugins install code-review@claude-plugins-official
|
||||
claude plugins install pr-review-toolkit@claude-plugins-official
|
||||
claude plugins install feature-dev@claude-plugins-official
|
||||
claude plugins install ralph-loop@claude-plugins-official
|
||||
claude plugins install claude-md-management@claude-plugins-official
|
||||
claude plugins install skill-creator@claude-plugins-official
|
||||
|
||||
# 社区插件（2 个）
|
||||
claude plugins install autonomous-skill@claude-code-settings
|
||||
claude plugins install spec-kit-skill@claude-code-settings
|
||||
```
|
||||
|
||||
#### 步骤 3.1：重新安装第三方 Skills
|
||||
|
||||
第三方 Skills 通过 `npx skills add` 安装，不在 Git 备份中，需要重新下载：
|
||||
|
||||
```bash
|
||||
# 第三方 Skills（5 个）
|
||||
npx skills add vercel-labs/skills@find-skills -g -y
|
||||
npx skills add steipete/clawdis@tmux -g -y
|
||||
npx skills add steipete/clawdis@summarize -g -y
|
||||
npx skills add tavily-ai/skills@tavily-research -g -y
|
||||
npx skills add https://github.com/jeffallan/claude-skills --skill embedded-systems -g -y
|
||||
```
|
||||
|
||||
#### 步骤 4：配置 API Key
|
||||
|
||||
```bash
|
||||
# 设置 Anthropic API Key（环境变量，不在配置文件中）
|
||||
export ANTHROPIC_API_KEY=你的密钥
|
||||
|
||||
# 建议写入 shell 配置文件持久化
|
||||
echo 'export ANTHROPIC_API_KEY=你的密钥' >> ~/.zshrc
|
||||
```
|
||||
|
||||
#### 步骤 5：安装 ESP-IDF v5.4.2
|
||||
|
||||
```bash
|
||||
mkdir -p ~/esp && cd ~/esp
|
||||
git clone -b v5.4.2 --recursive https://github.com/espressif/esp-idf.git v5.4.2/esp-idf
|
||||
cd v5.4.2/esp-idf
|
||||
./install.sh esp32s3 # 按需安装目标芯片（esp32s3/esp32c3 等）
|
||||
|
||||
# 激活环境
|
||||
source ~/esp/esp-idf/v5.4.2/esp-idf/export.sh
|
||||
|
||||
# 验证
|
||||
idf.py --version # 应输出 ESP-IDF v5.4.2
|
||||
```
|
||||
|
||||
### 8.3 恢复内容清单
|
||||
|
||||
| 内容 | 来源 | 需要下载 | 说明 |
|
||||
|------|------|:---:|------|
|
||||
| 全局规则 `CLAUDE.md` | Git 备份 | ❌ | clone 后自动生效 |
|
||||
| 自定义 Skills（11 个） | Git 备份 | ❌ | clone 后自动生效 |
|
||||
| 插件配置 `settings.json` | Git 备份 | ❌ | clone 后自动生效 |
|
||||
| 项目记忆 `memory/` | Git 备份 | ❌ | clone 后自动生效 |
|
||||
| 本指南文档 | Git 备份 | ❌ | clone 后自动生效 |
|
||||
| 插件代码（9 个插件） | 远程下载 | ✅ | 执行 `claude plugins install`（步骤 3） |
|
||||
| 第三方 Skills（5 个） | 远程下载 | ✅ | 执行 `npx skills add`（步骤 3.1） |
|
||||
| Claude Code 程序 | npm 远程 | ✅ | 执行 `npm install -g` |
|
||||
| ESP-IDF v5.4.2 | GitHub | ✅ | 执行 `git clone` + `install.sh` |
|
||||
| API Key | 手动配置 | ✅ | 写入环境变量 |
|
||||
|
||||
92
资深嵌入式工程师开发思维.md
Normal file
92
资深嵌入式工程师开发思维.md
Normal file
@ -0,0 +1,92 @@
|
||||
作为拥有10年以上经验的嵌入式软件开发工程师，在启动一个新项目时，其思维模式和工作流程已高度系统化、工程化，并深刻融入了对**可靠性、可维护性、可测试性**以及**资源极限利用**的追求。
|
||||
|
||||
以下是我为您梳理的，从拿到硬件到交付固件的完整开发思维与注意事项清单：
|
||||
|
||||
### **第一部分：项目启动与基础构建（占时20%，决定80%的后期效率）**
|
||||
|
||||
1. **深度硬件交底与验证**
|
||||
* **原理图精读**：不只看功能部分，重点关注电源树、复位电路、时钟源、外部存储器接口、未使用引脚的处理（上拉/下拉）。找出所有可能影响软件的硬件设计细节。
|
||||
* **硬件验证**：在写任何业务代码前，先编写最基础的“硬件体检程序”。测试所有GPIO（输入/输出）、通信接口（UART, I2C, SPI的Loopback测试）、ADC/DAC精度、外部存储器读写完整性。**确保硬件平台本身是稳定可靠的**。
|
||||
* **数据手册标记**：将芯片数据手册中关于外设寄存器、电气特性、时序要求的关键页打印或高亮标记，形成你的“硬件圣经”。
|
||||
|
||||
2. **环境与工具链的“一次搞定”**
|
||||
* **固化工具链**：选择并固定编译器（如GCC）、调试器（如J-Link）的版本。在团队内统一，并编写详细的《环境搭建手册》，避免“在我机器上是好的”问题。
|
||||
* **构建系统自动化**：使用 `CMake` 或 `Makefile` 管理项目，确保一键编译、链接、生成多种格式的固件（如Hex, Bin, 带调试信息的Elf）。
|
||||
* **版本控制即起点**：在写第一行代码前，就建立Git仓库。`.gitignore` 文件要精心配置，忽略所有编译中间文件、IDE工程文件。
|
||||
|
||||
3. **项目骨架与架构设计**
|
||||
* **清晰的分层目录结构**，例如：
|
||||
```
|
||||
firmware/
|
||||
├── CMakeLists.txt
|
||||
├── docs/ # 设计文档、硬件笔记
|
||||
├── drivers/ # 芯片外设驱动（与硬件强耦合）
|
||||
│ ├── inc/
|
||||
│ └── src/
|
||||
├── bsp/ # 板级支持包（开发板特定配置、传感器驱动）
|
||||
│ ├── inc/
|
||||
│ └── src/
|
||||
├── middlewares/ # 中间件（RTOS, FileSystem, Protocol Stack）
|
||||
├── application/ # 纯应用逻辑（与硬件无关的业务代码）
|
||||
│ ├── modules/ # 功能模块
|
||||
│ └── tasks/ # RTOS任务（如果使用）
|
||||
├── utilities/ # 通用工具（队列、环形缓冲区、日志系统）
|
||||
├── tests/ # 单元测试、集成测试代码
|
||||
└── build/ # 编译输出目录（被.gitignore忽略）
|
||||
```
|
||||
* **定义接口，而非实现**：`drivers` 层为 `bsp` 层提供稳定的API（如 `i2c_write(device_addr, reg, data)`），`bsp` 层为 `application` 层提供更抽象的API（如 `sensor_read_temperature()`）。**下层不知道上层的存在**，实现依赖反转。
|
||||
|
||||
### **第二部分：编码与实现的核心思维（贯穿全程）**
|
||||
|
||||
4. **资源意识深入骨髓**
|
||||
* **RAM是黄金，Flash是白银**：
|
||||
* 全局变量使用前，思考“它真的需要全程存在吗？” 优先使用栈变量或动态分配（如有OS）。
|
||||
* 常量数据务必加 `const` 修饰，让编译器将其放入Flash。
|
||||
* 仔细规划内存池和缓冲区大小，避免“大概够用”的随意定义。使用 `sizeof` 计算结构体大小。
|
||||
* **CPU周期要计较**：
|
||||
* 在中断服务程序（ISR）中，**只做最紧急的事**（置标志、读数据），将处理逻辑抛给后台任务。
|
||||
* 避免在循环中调用阻塞函数或进行复杂计算。合理使用查表法替代实时计算。
|
||||
* 对性能关键路径进行代码剖析（Profiling）。
|
||||
|
||||
5. **防御性编程与鲁棒性**
|
||||
* **断言（Assert）无处不在**：在函数入口检查参数有效性，在假设成立的地方使用断言。在发布版本中，可通过宏将其定义为空，但开发阶段它是致命的错误捕捉器。
|
||||
* **全面处理错误**：所有函数都应设计返回值或状态码，指示成功或失败原因。**即使一个函数今天看起来永远不会失败，也要为明天的变化留出处理路径。**
|
||||
* **考虑边界与极端情况**：数据溢出、下溢、通信超时、异常输入、电源抖动。思考“如果…会怎样？”
|
||||
|
||||
6. **可调试性设计**
|
||||
* **统一的日志系统**：设计分等级（Error, Warn, Info, Debug）的日志输出，可通过宏在编译时全局关闭或开启特定级别。日志信息要包含模块名、行号，关键数据要格式化输出。
|
||||
* **丰富的状态信息**：提供命令或接口，能实时输出内部关键变量、任务堆栈使用率、内存池状态等。
|
||||
* **预留测试点**：在关键流程中埋下“软件探针”（如翻转某个测试用GPIO），方便用示波器测量代码执行时间。
|
||||
|
||||
7. **代码规范即纪律**
|
||||
* **命名自解释**：变量、函数名清晰表达其用途（如 `getBatteryVoltage()` 而非 `getVolt()`）。采用团队统一的命名风格（如CamelCase, snake_case）。
|
||||
* **函数短小精悍**：一个函数只做一件事，长度最好控制在一屏内（约50行）。
|
||||
* **注释说明“为什么”，而非“是什么”**：代码本身应清晰表达“做什么”。注释应解释复杂的算法逻辑、非常规做法的原因、参考的文档或芯片勘误表。
|
||||
|
||||
### **第三部分：项目推进与维护的工程习惯**
|
||||
|
||||
8. **文档与代码同步**
|
||||
* **README.md是门户**：说明项目目标、硬件依赖、如何构建、如何烧录、如何测试。
|
||||
* **API文档自动化**：使用Doxygen等工具，从代码注释中自动生成驱动和模块的API文档。
|
||||
* **设计决策记录（ADR）**：当做出重要架构或技术选型决定时，写一个简短的文档记录背景、考虑过的方案、最终决定及理由。这对未来维护者和你自己至关重要。
|
||||
|
||||
9. **持续集成与测试**
|
||||
* **单元测试**：对关键算法、数据结构、硬件抽象层进行单元测试，确保逻辑正确。可以使用Unity、CppUTest等框架。
|
||||
* **硬件在环测试**：编写自动化测试脚本，通过串口、网络等方式向设备发送命令，验证功能并记录结果。
|
||||
* **回归测试**：任何修改后，运行已有的测试集，确保没有破坏原有功能。
|
||||
|
||||
10. **版本管理与发布**
|
||||
* **语义化版本**：采用 `主版本.次版本.修订号`（如1.2.3）的版本规则，并严格执行。
|
||||
* **详细的发布说明**：每个固件发布版本，都附带说明新增功能、修复的缺陷、已知问题。
|
||||
* **分支策略**：如Git Flow，明确 `main`（主发布）、`develop`（开发）、`feature/*`（功能分支）、`hotfix/*`（热修复）的用途。
|
||||
|
||||
### **十年经验工程师的终极思维模式**
|
||||
|
||||
* **从“实现功能”到“构建系统”**：思考的重点从单个函数、模块，转移到模块间通信、系统状态机、启动顺序、错误恢复的整体系统行为。
|
||||
* **“假设”是万恶之源**：不假设硬件永远正常，不假设数据永远有效，不假设调用者会遵守规则。用代码验证一切。
|
||||
* **拥抱变化，保持抽象**：硬件可能会改，需求肯定会变。通过良好的分层和抽象，将变化隔离在最小范围内。
|
||||
* **复利思维**：在工具、脚本、代码框架上的每一分投入，都会在整个项目周期乃至职业生涯中产生复利回报。花一天时间写个自动化烧录脚本，可能节省未来上百小时。
|
||||
* **教是最好的学**：乐于进行代码审查，乐于向同事解释你的设计。在阐述的过程中，你会发现自己逻辑的漏洞，并巩固知识。
|
||||
* **敬畏硬件，尊重物理**：深刻理解软件指令最终是如何变成电子信号的，时序、中断延迟、电磁兼容性（EMC）都是需要考虑的“软件问题”。
|
||||
|
||||
**总结**：资深嵌入式工程师的思维，是将**严谨的工程方法**、**深刻的资源约束认知**和**对不确定性的防御意识**，融合成一种近乎本能的开发习惯。其目标不仅是让代码工作，更是构建一个**易于理解、易于修改、经得起时间考验**的可靠系统。
|
||||
Loading…
x
Reference in New Issue
Block a user