Claude Code 工作流实例 (2026): 12 个仓库实测的 Plugins、Memory 与 Hooks

速览

保留下来的: 6 个我每天在跑的 .claude/skills/ 组合 — newword-hunter 做 SEO, gsd 做分阶段计划, code-reviewer 做 PR 审查, brainstorming 做特性梳理, debugging 做根因追踪, claude-md-improver 做新仓库 onboarding
退掉的: 4 个看起来很有用但其实成本高过收益的设置 — 过激的 memory 自动写入, 琐事的 parallel-agent 扇出, hook 自动 commit, 自定义 statusline 偶尔卡住输入
Memory 路由: 项目 memory (CLAUDE.md + memory/*.md) 占 95%, 自动 memory 在 ~/.claude/projects/ 用作跨会话偏好. 三层加载 (intent → top-2 文件 → 按需 interleave) 减少 60% 读 token
保留的 hooks: SessionStart 上下文加载, PreToolUse 危险 bash linter, UserPromptSubmit 交付物清晰度检查. 其他全部移除
诚实对比: 任何涉及 3+ 文件的任务 Claude Code 胜过 Copilot/Tabnine/Augment. 单文件内联补全 GitHub Copilot 还是更快. 不要选一个 — 按任务选合适的

我是谁

我是 Jim Liu, 悉尼的开发者, 跑一个 SEO + AI 工具组合横跨 12 个仓库: 9 个生产站点 (3 个金融, 2 个 AI 目录, 1 个 3 款游戏的矩阵, 2 个宠物/植物垂直, 1 个订阅追踪) 加 3 个内部工具仓库. 我在 2025 年 10 月用了 14 个月 Cursor 后全面切换到 Claude Code. 这篇文章记录的是 2026 年 5 月这 12 个仓库实际接进去的设置 — 不是"可以做什么", 是"留下来的是什么".

我付了 Anthropic 1M context tier (Claude Code 里叫 Opus 4.7 1M). 下面每一个例子都来自真实代码库、真实 .claude/ 目录、真实 commit 历史. 工作流哪里在烧 token、哪里在省 token, 我两边都给数字.

为什么"工作流实例"需要一篇专门的文章

大部分 Claude Code 内容讲的是 CLI 是什么. Anthropic 官方文档讲得不错 — 见我们的 Claude Code CLI 文档解读. 2026 年缺的是 能跑通的设置实际怎么搭: 哪个 plugin 在什么时刻加载, 哪些 hook 划算, 哪些组合互相抵消.

我看过 4 位同事在第一周装了 12+ 插件, 之后花 3 周在拆冲突. 这件事让我留了个习惯: 没装的插件就是没要 debug 的插件. 下面是 6 个月留存下来的.

Workflow 1 — SEO 长尾发现 (newword-hunter + GSC)

横跨我的金融和 AI 工具站, 我每周跑一次 /newword-hunter. 这个 skill 通过 CDP 端口 9222 驱动 Chrome 抓 Google Trends、allintitle、SEMrush 30+ 个候选 keyword. 输出是按 keyword 一份 JSON verdict, 写入一个 SQLite seo.db.

具体组合:

/newword-hunter Mode B (trending now 扫描, 扩 pool 300+)
  → 557 raw → 35 seeds → 15 surviving (Trends NO_DATA 过滤)
  → SERP top 10 + allintitle + SEMrush + KGR/KDRoi verdict

5 月 2 日上午跑出真实数据: 0 个 P0 候选过. 同一天晚上重跑: 还是 0. 这不是 bug — 是 trending 池对任何 DR < 30 的 portfolio 都饱和的真相. 正确反应是切到 Mode C (GSC golden mining), 找已经 rank 在 8-30 但 0 click 的长尾. 那里改一次 title 比新写 10 篇文章值钱.

这 skill 占我大约 50 分钟 agent 时间, 0 分钟我自己时间. 这只在 verdict 带时间戳存进 seo.db 时才划算 — 我无法在 14 天内重测同一 keyword, 这避免了 2026 年初我经历过的"每周翻同一个 title"故障模式.

Workflow 2 — Memory 路由 (三层加载)

Claude Code 默认行为是会话开始时读 memory/ 目录里所有 .md. 我这有 126 个文件, 第一个 prompt 之前就 800K+ token. 我用三层路由把这砍下来:

Layer 1 — intent 分类 (0 读取). 用户 prompt 来时, 我匹配关键词 (backlink、blog、seo-check、forum、affiliate、browser、code) 给 intent 打标. 这一步在系统提示里完成, 不读文件.

Layer 2 — top-2 文件加载 (~每个 20 行). 每种 intent 我在 CLAUDE.md 里预先声明了最相关的 2 个 memory 文件. Layer 2 只读相关段落 (TL;DR + 结构), 不读全文. 如果有 .compact.md (用 python -m src.autoloop.memory_tools compact 自动生成), 优先读 compact — 大约 10 倍压缩.

Layer 3 — 按需 interleave. 会话中遇到不知道的 (表单填不进去、部署失败), 动态读相关段落. 模式:

Layer 1 (0 读) → Layer 2 (~20 行) → 开始干活
  ↓ 撞上问题
  Layer 3 (~10 行) → 继续
  ↓ 又撞问题
  Layer 3 (~5 行) → 完成

总 context: ~~35 行 vs "全部加载"~~80 行. 一般会话 token 节省 60-65%.

3 个文件的小仓库这没啥用. 12 仓库 6 个月累积 memory 用处大. 详见我们关于大型代码库 memory plugin 的深度分析.

Workflow 3 — Plan 模式 + GSD 处理多阶段工作

只要涉及 3+ 文件或影响 1+ 仓库, 我先 Plan Mode (Shift+Tab) 再调 /gsd:plan-phase. GSD skill 把我的大纲变成结构化的 PLAN.md, 含任务拆分、依赖分析、目标反推验证.

具体例子上周: LRTS 博客读取从文件系统迁到 DB-first. GSD 拆成:

Phase 1: schema 设计 (3 任务, 1 小时)
Phase 2: 读路径 (4 任务, 2 小时)
Phase 3: 写路径通过 publish_blog.py (5 任务, 2 小时)
Phase 4: 47 个现有 .md 的迁移脚本 (2 任务, 1 小时)

Phase 1-3 我花两天执行完. verifier agent 在 merge 前抓到一个 bug: filesystem 读取的回退需要显式 existsSync 检查, 不能只 try/catch. 没有 GSD 的验证步骤, 我会 ship 一个静默回归.

Workflow 4 — 代码审查 (PR + Pre-Commit)

两种: /code-review 做整个 PR vs base branch 审查, /superpowers:requesting-code-review 做 push 前自审. 第一个跑 agent 对 diff 报严重度分级问题. 第二个更对话式 — 想要个常识检查而非正式审计时有用.

2026 年 4 月一次具体抓到的: 我的 kdroi_calc.py 有个 bug, 带 \r 后缀的 keyword (Windows 上 CRLF 拼接 seed 文件来的) 静默无法匹配 allintitle.json 的 key. 审查 agent 标"高置信度: 输入文件间 keyword 序列化不一致". 我会把那个污染 ship 进 seo.db. 一个对字符串规范化偏执的 agent 救了我.

Workflow 5 — 我保留的 Hooks (以及大部分被我移掉的原因)

我今天只跑 3 个 hook:

SessionStart: 加载 MEMORY.md (auto-memory 索引) 加 freshness 检查. 输出作为 system-reminder 进系统 context
PreToolUse on Bash: 阻止链式 sleep 命令, 拒绝 --no-verify git flag (除非我明确授权)
UserPromptSubmit: 一个"长 prompt 没明确交付物"的 linter, 在我写得啰嗦时让我澄清. (这个 hook 在我写这篇文章时实际触发过 — 我得收紧大纲.)

我移掉的:

自动 commit hook (太多次 commit 了破损状态)
自定义 statusline 渲染 (在我不想要时渲染, 偶尔卡输入)
长任务通知 hook (音效成噪音)
每次按键都跑的预提交 linter (50ms 延迟堆起来)

Hook 的价值跟它"每次有用抓到 / 总触发次数"的比例挂钩. 我留的 3 个每次会话最多触发 3 次, 每次都抓到真问题. 每分钟触发一次但每周抓到一次真问题的 — 移除.

Workflow 6 — 诚实对比: Claude Code 输的时候

Claude Code 是我的日常. 它不总是对的工具.

任务	最佳工具	为什么
单文件内联补全 (打字速度)	GitHub Copilot	亚 100ms 延迟, 不切换 context
跨 5+ 文件重构	Claude Code	1M context 理解整个图
9 个站点轮换 API key	Claude Code (带自定义 skill)	多仓库编排
快速 regex 查找替换	直接 `sed`/`rg`	确定性任务比任何 AI 都快
从现有代码生成文档	Claude Code	结构更好, 注意力跨度更长
样板代码生成 (CRUD、表单)	Cursor / GitHub Copilot	模式匹配生成更快
架构审查	Claude Code (Opus 4.7)	抓得到跨文件设计问题

定价也是: Claude Code 1M tier 我用量大约 $200/月; GitHub Copilot $20/月. 想看哪个在哪种场景算账划算, 见 GitHub Copilot Pricing — A Real Week 和 Tabnine vs GitHub Copilot. 团队规模对比见 Claude Code vs GitHub Copilot Teams.

4 个我撞过的坑 (以及怎么修)

坑 1 — Chrome 8+ 标签时 DrissionPage 卡死. 长 pipeline 跑完后 tab 累积, page.tab_ids 对每个 target (含 iframe 和 worker) 调 Page.getFrameTree. 任一 target 卡住, 整个迭代挂掉. 修法: 抛掉 DrissionPage, 用 raw CDP via urllib + websocket (cdp_drive.py 模式). 卡死消失, 10 倍快. 昨晚 SEMrush 量级抓取冻 30 分钟时学到的.

坑 2 — 跨输入文件的 keyword 规范化. 我的 SEO pipeline 从 Python 写 seed 到 surviving_seeds.txt, bash 读, 再传给 Python. 每次过渡都可能引入 CRLF 失配. 修法: 每个 JSON key 访问处显式 .rstrip('\r\n').strip(), bash 数组里 tr -d '\r'. 被 code-review agent 在生产前抓到.

坑 3 — 多个 Claude Code 会话共享同一个 Chrome 9222 端口. 两个 agent 同时驱动同一个浏览器会静默互相破坏状态. 第二个 agent 的 tab 在动作中关掉 — 因为第一个 agent 的 close_tab 清理在共享 target 上跑. 修法: 硬规则 — 一次只一个 agent 拥有 9222, 第二个 agent 用 9223 加自己的 profile. 我丢了一次 90 分钟的 pipeline 才学会.

坑 4 — 过激的 auto-memory 写入. 我让 Claude Code 每次会话后写 ~/.claude/projects/.../memory/. 两个月内 315 个文件, 一半重复, 一半过时. 修法: 在 CLAUDE.md 里明确"值得保存的 memory"标准 (经验法则: 出乎意料、非显而易见、未来相关). 加每月一次的 compact + staleness 扫描 python -m src.autoloop.memory_tools report.

这套工作流不适合你的时候

3 种我会跳过大部分的情况:

1000 LOC 以下的单人项目: plugin/memory/hook 的 overhead 超过收益. 直接和模型聊就好
严格合规环境: 仓库不能有仓库外的文件 (没 ~/.claude/), plugin 模型就破了. 用容器化设置或回退到直接 API
结对编程是主模式: 已经在和真人结对, 加 AI 伙伴造成三方对话 overhead. 选一个

方法论

本文数字来自:

6 个月 Claude Code 日常使用, 2025 年 10 月到 2026 年 5 月
Token 用量通过 Anthropic Console 跟踪 (典型一天: 800K-1.2M 输入, 50K-150K 输出)
Plugin 装/卸日志 (留在 ~/.claude/install-history.md)
前/后 hook 延迟用 time wrapper 手动测
12 个仓库: openaitoolshub.org, lowrisktradesmart.org, alphagaindaily.com, levelwalks.com, subsaver.click, pawaihub.com, aiplanthub.com, oilempire.click, aotrevolution.click, 加 3 个内部工具仓库

我没有其他 Claude Code 用户的匿名聚合数据 — 这些模式是我自己的, 可能不通用. 如果你有撑过 6+ 个月的工作流想交流, 联系表里找我.

FAQ

应该装多少 plugin?

我跑 6 个. 看过同事跑 0 个 (光裸 CLI) 也看过 12 个. 6 个差不多 — 想要的能力总是一个 slash 命令外, 12 个有发现问题, 我会忘了我有什么. 从 3 个开始, 只在你两次缺某具体能力时再加.

没 GSD Plan 模式还能用吗?

能 — Plan Mode 是内置的 (Shift+Tab 切换). GSD 加上结构化 PLAN.md 和验证循环. 3 个 phase 以下的项目, 纯 Plan Mode 够了. GSD 在你同时管多个 phase 或停几周再回来时回报最大.

为什么是 CDP 端口 9222?

它是带界面 Chrome 的标准远程调试端口. browser-harness 类 skill 都假设是它. Chrome 用 --remote-debugging-port=9222 跑过一次后, 后续所有 skill 调用都能找到它. 端口冲突变成主要失败模式 — 见坑 3.

用 auto-memory 还是 project memory?

都用. Project memory (memory/ 在你仓库, 通过 CLAUDE.md 索引) 给该代码库特定的内容. Auto-memory (~/.claude/projects/.../memory/) 给跨会话偏好和模式. 不要混. 我把项目 context 放进 auto-memory 那天, 就是我开始在邻近项目上拿到 wrong-context 幻觉那天.

Claude Code 比 GitHub Copilot Teams 值得吗?

跨多仓库 > 100K LOC 每仓的工作, 是的 — 1M context 处理 Copilot 处理不了的全代码库推理. 小仓库和内联补全, Copilot 仍然有竞争力. 完整对比见 Teams 对比.

速览

我是谁