diff --git a/06-AI对话和电子吧唧双模式适配说明.md b/06-AI对话和电子吧唧双模式适配说明 copy.md similarity index 100% rename from 06-AI对话和电子吧唧双模式适配说明.md rename to 06-AI对话和电子吧唧双模式适配说明 copy.md diff --git a/Claude Code 十个最值得装的 Skills copy.md b/Claude Code 十个最值得装的 Skills copy.md new file mode 100644 index 0000000..1f53af7 --- /dev/null +++ b/Claude Code 十个最值得装的 Skills copy.md @@ -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 决定的。 \ No newline at end of file diff --git a/Claude Code插件高效运用指南.md b/Claude Code插件高效运用指南.md index 73348c8..fd6e632 100644 --- a/Claude Code插件高效运用指南.md +++ b/Claude Code插件高效运用指南.md @@ -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 # 手动触发执行一次 +``` + +**工作原理**： +- 基于 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//SKILL.md` | 个人全局 Skills | +| 项目级 Skills | `.claude/skills//SKILL.md` | 仅当前项目生效 | +| 项目级规则 | `.claude/CLAUDE.md` 或项目根 `CLAUDE.md` | 项目专属指令 | +| 自动记忆 | `~/.claude/projects//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 | 手动配置 | ✅ | 写入环境变量 | diff --git a/资深嵌入式工程师开发思维.md b/资深嵌入式工程师开发思维.md new file mode 100644 index 0000000..0557489 --- /dev/null +++ b/资深嵌入式工程师开发思维.md @@ -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）都是需要考虑的“软件问题”。 + +**总结**：资深嵌入式工程师的思维，是将**严谨的工程方法**、**深刻的资源约束认知**和**对不确定性的防御意识**，融合成一种近乎本能的开发习惯。其目标不仅是让代码工作，更是构建一个**易于理解、易于修改、经得起时间考验**的可靠系统。 \ No newline at end of file