Claude Code 深度学习手册

主题

深度复盘：按工作类型看你的真实用法 ​

本页职责：把你的用法按 6 种工作类型归纳成规律（数字以 改进清单 为准）。

基础：扫了你 13 个项目、全部人工输入的 prompt（2026-05 快照），按工作类型分桶、引用你真实说过的原话。每类按 (a) 你怎么做 → (b) 该怎么做 → (c) 以后怎么做 → (d) 区别与对结果的影响展开。配套总览见 我的改进清单。

本页是按类型的归纳；想看逐条（每个项目每个会话每一条消息的七维点评 + 真实证据），见 逐条处理（按项目）。

你实际把 Claude 用在哪（类型分布） ​

类型次数一句话画像
超短放任（"可以/继续"）212最高频，把方向全交给模型
排错 / bug99开局信息密度低、晚纠偏
质量审查（"仔细审查确保没问题"）77仪式化模糊重灾区
部署 / 运维（多为交给 codex）44环境使然，但把验证也外包了
设计 / 审美18给参照物时好、用形容词时差
需求 / 功能17报 bug 很专业、提需求偶尔糊

下面 6 类逐一拆。结论先行：你的"工程纪律"（写测试、自验证、根因优先）已是大佬级；真正拖慢你的是三件事——信息密度低（超短/形容词）、验收无标准（仪式化审查）、纠偏太晚（事后"还是不行"）。

1. 质量审查类（77 次）—— 你最大的"仪式化模糊" ​

你真实说过：

  • 「再帮我仔细审查确保没有任何问题了」
  • 「再帮我仔细审查一遍。从 UI 专家的角度出发，考虑所有的边界情况以及极致的用户体验」
  • 「用专业的 skills，仔细评审桌面端和移动端，全部给我打分，任何细节都不要放过」
  • 「确保没有完全是最优方案，考虑所有边界情况」

(a) 你现在怎么做：用"仔细审查 / 确保没问题 / 考虑所有边界 / 做到极致 / 打分"这类咒语收尾，但没给范围、没给验收标准、没指明查哪些维度。77 次里大多如此。

(b) 你应该怎么做：给一个可勾选的 checklist + 明确范围 + 通过标准。例：

text
审查 src/views/ResearchRadar.vue 的历史会话切换逻辑，逐条给"通过/不通过 + 证据"：
1. busy 状态在所有退出路径（成功/报错/取消）都复位？
2. 切换会话时在途的推荐问题请求是否被取消？
3. 其他智能体页面是否同一模式、是否都修了？
只报影响正确性/鉴权的问题，不要风格建议。

(c) 以后怎么做：把"确保没问题"固定替换成 3–5 条具体验收项；高频审查直接做成一个 /review-checklist skill（你装了 skill-creator，一次成型、以后复用）。

(d) 区别与影响：

  • "确保没问题" → 模型只能泛泛扫一遍，给你一堆看似全面、实则没重点的反馈，还容易过度工程；你会忍不住再问"真的没问题吗"（你确实说过「定位到真实问题了吗」），来回好几轮。
  • 给 checklist → 它逐条验证、附证据，你一次就能确认覆盖到了，少 2–3 轮返工。

2. 排错 / bug 类（99 次）—— 开局信息密度低 + 晚纠偏 ​

你真实说过：

  • 「历史会话切换总是没反应，有这个问题吗，先帮我定位一下」
  • 「我觉得你方向跑偏了」（在它已经做错之后）
  • 「似乎还是不行」「还是不行」「还是不行，我需要你仔细审查代码」

(a) 你现在怎么做：先抛一个模糊现象让它"定位"，自己心里其实有更具体的观察（比如"要等推荐问题接口返回才行"）却没第一时间说；它跑偏了才纠正；修不好就重复"还是不行"。

(b) 你应该怎么做：第一句就给复现 + 你的观察 + 怀疑点，并让它先复现再改：

text
ResearchRadar 历史会话切换：在"推荐问题生成中"时点不动，要等接口返回才行。
先复现确认，再用 serena 定位控制 running/busy/allowOpenWhileBusy 的符号和所有引用，
加一行日志打印 busy 何时复位，给我根因再动手。

(c) 以后怎么做：

  • 复现 + 观察 + 期望，三件套一次给够（你装了 superpowers，systematic-debugging 会自动接管，但它也需要你的线索）。
  • 失败 2 次就 /rewind 回到改之前、补更尖的信息，别陷进"还是不行"循环。
  • 找代码用 serena（你真实记录里这类会话 serena=0、却把同一文件 Read 五遍）。

(d) 区别与影响：

  • 模糊开局 → 它盲目 grep+Read 大半天（真实那次读了 ResearchRadar.vue 5 遍、上百条命令），真相却是你第 4 轮自己观察出来的，前面全白跑。
  • "还是不行"循环 → 在错误路径上越改越乱、上下文越脏；/rewind + 新线索 → 干净重来、更快收敛。

3. 设计 / 审美类（18 次）—— 形容词 vs 参照物（你时好时坏） ​

你真实说过：

  • 差：「太 AI 化了，一点商业规范都没有，是没用组件库吗」「风格一点也不高级，没有眼前一亮的感觉」
  • 好：「https://kejizhuantifwu.netlify.app/ 这个是原型页面，按照 UI 的样式和原型页…」、「左侧菜单悬浮色不对，收起的样式完全不对」、「样式要遵守我们的设计文档」

(a) 你现在怎么做：给原型 URL / 设计文档 / 指出具体元素（"悬浮色""收起样式"）时很到位；但很多时候用"高级 / 眼前一亮 / 太 AI 化"这种纯形容词，模型只能猜。

(b) 你应该怎么做：把"好不好看"翻译成可执行的锚——喂设计稿 + 指定组件库 + 给色值/间距 + 贴参考截图：

text
参考 design-assets/pencil/科技专题服务系统.fig（用 figma 读 get_design_context+截图），
按它重做这个页面：组件库用 ant-design-vue，主色 #1677ff，8px 栅格；改完截图和设计稿对比差异并修。

(c) 以后怎么做：审美需求一律带"参照物"——figma 源稿（你有 .fig/.pen + figma MCP）、某个你喜欢的产品 URL、或一张截图。把"设计文档要遵守"具体到文件路径。

(d) 区别与影响：

  • 形容词不可验证 → 来回三五轮还是"不对"（你真实地反复说"还是太 AI 化"）。
  • 给锚（图/组件库/色值）→ 一次到位且可对比验收。Product Design 团队就是直接把 Figma 稿喂给 Claude，让它写+测+迭代，不靠形容词。

4. 部署 / 运维类（44 次）—— codex 接力（环境使然，但别外包"验证"） ​

你真实说过：

  • 「我会让 codex 执行，你直接给出命令 / 提示词」「给我一个让 codex 执行的提示词」
  • 「我 codex 是在 mac 中，之前完全配置好的，你没改仓库吧」

(a) 你现在怎么做：在 /workspace 容器里让 Claude 规划/出提示词，把命令交给 Mac 上的 codex执行和部署——因为容器碰不到你的 Mac/服务器。这是合理的环境隔离，不是偷懒。

(b) 你应该怎么做：部署到外部环境交给 codex 没问题；但凡是容器内能验证的（mvn compile、pnpm type-check、vitest、起 dev）让 Claude 先自验证再交付提示词——别把"验证"也外包出去。

(c) 以后怎么做：要求 Claude 给 codex 的提示词里附上"已在容器内 type-check / 测试通过"的证据；容器内能直接验的就别等 codex 回来才发现错。

(d) 区别与影响：

  • 全外包（Claude 只出提示词）→ codex 拿到的可能是没验证过的代码，错了要在 Mac 上来回，反馈链很长。
  • 半外包（Claude 验证 + codex 只部署）→ 交付的是已验证代码，codex 那边一把过。

5. 超短放任类（212 次！）—— 最高频，最该改 ​

你真实说过：「可以」「继续吧」「完成了吗」「开始吧」「写进去吧」「你确定这样可以吗」

(a) 你现在怎么做：大量用单字/单词推进，把方向完全交给模型。212 次——这是你最频繁的交互方式。"你确定这样可以吗"这种反问，恰恰说明你其实没把握它在干嘛。

(b) 你应该怎么做：关键节点别只说"继续"——

  • 要么先看计划再放行（plan mode：它列出要做什么，你批了再跑）；
  • 要么真想放手就开 auto-accept + 给一个可验证目标（"实现 X，跑通 pnpm type-check 和这条测试再停"），让它自己判停，而不是你手动"继续"。

(c) 以后怎么做：长任务开头用一次 plan / opusplan 把方向定死，中途"继续"自然就少；放手时给验证条件让它自闭环。

(d) 区别与影响：

  • 盲目"继续" → 你失去对方向的控制，等发现跑偏（你说过「我觉得你方向跑偏了」）已经晚了、改动也铺开了。
  • plan 先行 / auto + 验证 → 要么你掌控方向、要么它自验自停，两种都比"盲目继续"可靠。

6. 需求 / 功能类（17 次）—— 报 bug 很专业，提需求偶尔糊 ​

你真实说过：

  • 专业：「邀请码管理菜单，点击【自定义创建】按钮，弹窗里必填项字段缺少 * 号标识」（精确复现，赞）
  • 偏糊：「帮我做一下登陆功能」

(a) 你现在怎么做：报具体 bug 时给得很准、可直接复现；但提新功能时有时太笼统。

(b) 你应该怎么做：新功能也按"用户故事 + 验收标准 + 边界"描述；或先让 Claude 用 AskUserQuestion 采访你、产出 SPEC.md，你确认后再开新会话实现。

(c) 以后怎么做：大功能先 /office-hours 或 plan 出 SPEC 落盘，再实现——别一句"帮我做登录"就让它猜你要哪种（账号密码？短信？Tenant 多租户？记住登录？）。

(d) 区别与影响：

  • 笼统需求 → 它按自己理解做，方向/边界对不上你预期，返工。
  • SPEC 先行 → 边界和验收一开始就对齐，一次做对。

你的画像 & 三个肌肉记忆 ​

画像：你是高纪律、高产出的重度用户（TDD、自验证、根因优先都到位），但交互上偏反应式、低信息密度——靠"继续/再审查一遍/还是不行"推进，把方向和标准留给模型猜。

把这三件事变成习惯，比改任何配置都提升大：

  1. 开局把信息一次给够：复现 + 观察 + 文件（@path）+ 参照物（图/URL）。（治你的"超短""形容词""晚纠偏"）
  2. 审查/验收给标准：用 3–5 条可勾 checklist 代替"确保没问题"。（治你 77 次的"仪式化审查"）
  3. 失败就 /rewind 重描述，别"还是不行"循环；找代码用 serena、查文档用 context7。

重看时可挑一个最近会话，对照这 6 类自检：我这次属于哪类？开局信息够吗？审查给标准了吗？纠偏及时吗？