Claude Code 使用洞察报告

151 个会话（共 180 个）的 1,184 条消息 | 2026-06-17 至 2026-06-25

一览
运转良好：你的运作方式严谨，以验证优先：通过分阶段 PRD 写作结合自动化写审循环来驱动迭代开发，由独立审核者审核代码直至通过 PASS 裁定。这种门控思路同样贯穿部署——精准隔离 web 安全提交，生产部署前要求明确再次确认，并逐一验证每个版本上线正常。你也会直接探查生产服务器来做出扎实的基础设施决策——比如识别出 RAM 才是真正瓶颈、提前标记出 ARM 架构陷阱。亮点成果 →
阻碍因素：Claude 方面，有时会在你纠偏前就假定错误的范围或执行模式——把「P3」理解成错误的路线图条目，把 changelog 写到根目录而非你已有的文件，或自己做渲染而非委托给笔记本。你自身方面，最大的阻力来自环境：反复的 API 过载和配额耗尽阻断了整个会话，安全分类器对你的批准理解也太窄（把「同意」当作仅批准代码计划而非生产部署），这些摩擦都可以通过提前更明确地界定范围来预防。常见问题 →
快速改进建议：你已经用 /wrloop 命令证明了可复用工作流的价值——可以进一步用自定义 Skills 将「从 git-HEAD 部署」的规范和再确认门控编码下来，保证每次都能稳定运行。通过 MCP 服务器将 Claude 连接到 GitHub Issue 可以收紧你的「分类-修复-关闭」闭环，Hooks 则可以在每次部署前自动快照 git 状态，防止并行进程文件回滚导致的静默损坏。可尝试的功能 →
更宏大的工作流：随着模型能力提升，你的 /wrloop 流水线可以真正实现自门控：一个写者 agent、一个完全独立的审核者，以及一个只有绿灯才发布的部署 agent——自动重试 529/429 错误、在模型网关之间故障转移、直接读取审核者 transcript 而非从空日志猜测。更进一步，你的笔记本+服务器组合可以进化为一个自愈 agent 网格：映射每个节点、绕过代理和 GFW 故障、从 OOM 构建和 SSH 连接问题中恢复、始终从已验证的提交部署——把今天脆弱的手动协调变成弹性编排的机群。未来展望 →
1,184
消息数
+50,005/-4,097
行数变化
946
涉及文件
9
天
131.6
消息/天

工作内容

小程序 PRD 与多 Agent 审核循环 约 12 个会话
用户通过分阶段 PRD/技术文档写作结合自动化写审循环（由独立的笔记本 Claude 审核员把关）来驱动 luying-miniapp 的迭代开发。Claude 将其封装为可复用的 /wrloop 命令，完成了多批次审核并达到 PASS 裁定，并纠正了跨机器审核中发现的真实设计缺陷（如 openid 账号互通误判）。部分会话因 GLM-5.2 配额耗尽而中止，或在 transcript 结束时仍处于审核中。
生产部署与功能交付 约 14 个会话
用户让 Claude 实现了多项 Web 功能（Prompt 保存、拖拽上传、图片压缩、VIP 弹窗、封面多样性），并随 changelog 更新和 git 提交从 106 测试服务器安全部署到 175 生产环境。Claude 精准隔离 web 安全提交，避免将未验证的小程序代码污染生产，处理了并行进程文件回滚问题（切换到 git-HEAD 作为部署源），并逐一验证部署成功。
Bug 诊断与 GitHub Issue 分类 约 10 个会话
Claude 诊断并修复了多个生产环境真实 Bug，包括一个关键 SQL INSERT Bug（缺少占位符）、通过客户端 Haversine 修复的 0KM 距离 Bug，以及标签刷新缓存问题。它批量分类 GitHub Issue，区分真实 Bug 与非 Bug，在测试和生产环境应用已验证的修复，并按用户授权关闭/评论 Issue。
服务器与基础设施运维 约 8 个会话
用户让 Claude 执行服务器健康检查、云配置选型（识别 RAM 为瓶颈并标记 ARM 陷阱），以及通过 API 重启和代理配置恢复一台无法访问的日本服务器。Claude 还将 CloudCLI 部署为 systemd 服务、配置 Beszel 监控、设置 Termius SSH 密钥认证，并管理 QQ Bot 会话重置以防止 529 过载错误。
战略分析与可视化 Artifacts 约 6 个会话
用户请求了多项数据驱动的战略分析，包括平台扩张方案、GLM-5.2 配额策略、黑客松作战计划，以及 AI 孵化器平面图概念。Claude 将分析与部署的交互式网页/仪表盘 Artifacts 配套呈现，并将策略决策持久化到 memory，偶尔受 API 过载限制。
需求类型分布
部署
18
功能开发
14
文档
14
版本控制
8
修复 Bug
4
服务器诊断
4
常用工具 Top
Bash
4121
Edit
1648
Read
1376
TaskUpdate
486
Write
374
TaskCreate
302
编程语言
TypeScript
1420
Markdown
1162
Python
297
JavaScript
98
HTML
58
JSON
38
会话类型
多任务
29
单任务
15
迭代优化
4
快速提问
1

使用方式

你的工作方式更像一个编排自主 agent 的技术项目负责人，而非亲力亲为的编码者。你的标志性操作是写审循环：反复让 Claude 开发某项功能，然后由一台独立的笔记本 Claude Code 实例对代码进行审核，直到获得「PASS」裁定——这个模式如此核心，以至于你将其封装成了可复用的 /wrloop 技能。你大量授权并提前赋予自主权（「已批准自主执行」），倾向于在任务开始时锁定决策和约束条件（如「锁定决策后跑循环」），而非逐步微管理。如此庞大的工具调用量——4,121 次 Bash、486 次 TaskUpdate、302 次 TaskCreate——说明你信任 Claude 能在多台机器和服务器之间独立运行长达多步的部署与审核流程。

尽管给予了充分自主权，你对部署安全的掌控却十分强硬。你始终在测试（106）和生产（175）服务器之间划出清晰的界限，并明确隔离高风险变更——「仅部署 web 安全功能，排除小程序改动」或「按要求提交代码但不部署到 175」。当 Claude 的 Auto 模式分类器把你的「同意」理解为仅批准代码计划而非生产部署时，这种摩擦恰恰体现了你刻意的门控设计，而非粗心。你也会在 Claude 跑偏时及时纠偏：要求它把渲染任务委托给笔记本而非自己做、纠正 changelog 文件路径、在它过度设计时叫它「保持简单」。这些都是精准的干预——你放手让 Claude 跑，但能迅速发现错误方向。

你最大的痛点不是 Claude 的能力，而是基础设施脆弱性：反复出现的 529/429 API 过载和配额耗尽阻断了整个会话，迫使你输了 11 次「继续」或临时切换模型。值得注意的是，有时你比 Claude 更清楚更快的诊断路径——你建议直接读取笔记本 Claude 的 transcript，而 Claude 还在从空日志里低效推断进程状态。这体现了一个以系统思维运作、跨机器协调工作流、把 Claude 当作自己设计的验证框架中执行引擎的深度技术操作者。从结果看也正是如此：49 个分析会话中 38 个完全达成，失败原因几乎全部归咎于外部 API 阻断，而非理解偏差。

核心模式：跨多台机器编排自主「写-独立审」循环，赋予 Claude 充分执行自主权，同时严格执行测试-生产隔离部署门控。
用户响应时间分布
2-10 秒
25
10-30 秒
104
30秒-1分
108
1-2 分钟
155
2-5 分钟
175
5-15 分钟
134
>15 分钟
69
中位数：117.5 秒 • 平均值：311.8 秒
并行会话（Multi-Clauding）
106
重叠事件
103
涉及会话数
32%
消息占比

你频繁同时运行多个 Claude Code 会话。当多个会话在时间上发生重叠时即检测到并行工作流。

一天中消息发送时段
工具报错类型
命令失败
250
其他
158
用户拒绝
29
文件未找到
9
编辑失败
5
文件已更改
2

亮点成果

在 9 天、151 个会话的高强度工作中，你运行了一套复杂的跨机器开发体系，横跨小程序构建、生产部署和自动化审核循环。

自动化写审开发闭环
你构建并封装了可复用的 /wrloop 命令，驱动多轮写审循环，由笔记本的无头 Claude 独立审核代码直至获得 PASS 裁定。这个门控工作流捕获了真实缺陷——如 openid 账号互通误判和安全问题——让你能以经过验证的信心关闭 GitHub Issue，而非盲目信任。
精准安全的生产部署
你始终精准隔离要部署到 175 生产服务器的 web 安全提交，同时排除未验证的小程序代码，甚至通过切换到 git-HEAD 作为部署源解决了并行进程文件回滚问题。你要求生产推送前明确再次确认，并逐一验证每次部署成功，在真实压力下展现了严格的发布纪律。
数据驱动的基础设施决策
你直接探查生产服务器来做出扎实的决策——比如识别出 RAM 而非 CPU 是迁移瓶颈，并在确定 2C8G x86 配置前标记出 ARM 架构陷阱。你将此与精准的根因调试相结合：精确定位 SQL Bug（VALUES 中缺少 ?），并在提交精准 GitHub Issue 前诊断浏览器缓存与服务器缓存问题。
最有帮助的 Claude 能力
出色的调试
17
多文件修改
10
主动协助
10
清晰解释
6
代码编辑正确
3
任务完成情况
未完成
3
部分完成
4
基本完成
4
完全完成
38

常见问题

你的会话效率很高，但遇到了几个反复出现的阻力：API 过载错误阻断工作、自动安全分类器误判你的批准，以及 Claude 在委托执行和文件路径约定上需要被纠偏。

API 过载与配额耗尽
你的大部分阻力来自 529「过载」错误和 GLM-5.2 配额耗尽，这些问题会彻底中断工作，往往迫使你多次重试或切换模型。考虑在非高峰时段安排繁重的自动化循环，并设置备用模型路由，这样单个网关中断就不会完全阻断你。
  • 重复的 529 错误阻止了定时任务的创建，并彻底阻断了一个 Logo 生成会话，什么都没完成（not_achieved）。
  • 你对着持续不断的 529 错误输了 11 次「继续」，Claude 才终于能开始工作；在其他会话中也不得不临时切换模型。
安全/权限分类器误判批准意图
自动分类器反复阻断合法操作或对你的批准理解过窄，增加了额外的确认轮次。批准时明确说明范围（如写「生产部署」而非仅说「同意」）可以预防这类打断。
  • Auto 模式分类器把你的「同意」理解为仅批准代码计划，阻断了生产部署，直到你再次明确确认。
  • 权限和安全分类器阻断了全局 npm install 和 git reset --hard，迫使你授权替代方案。
需要纠偏的默认行为偏差
Claude 有时会假定错误的范围、文件路径或执行模式，并在你纠正前就开始执行，造成返工。提前说明约定——用哪个 changelog 文件、谁驱动渲染、「P3」是什么意思——可以减少这类弯路。
  • Claude 创建了根目录的 CHANGELOG.md，后来又写到了错误的路径，而非更新 content/docs/changelog.md，导致部署前需要你纠正。
  • Claude 一开始自己做渲染，还把「P3」误读为抖音端口，需要你重新引导它委托给笔记本 Claude 并说明是微信小程序范围。
主要阻力类型
API 报错
13
代码有 Bug
9
方向错误
7
误解需求
3
用户拒绝操作
3
外部阻断
1
推断满意度（模型估算）
受挫
2
不满意
3
可能满意
104
满意
15

可尝试的现有 CC 功能

建议添加到 CLAUDE.md 的内容

直接复制到 Claude Code 即可添加到 CLAUDE.md。

多个会话在 106→175 部署时出现文件回滚 Bug 和生产批准歧义，造成了摩擦。
至少在两个会话中 Claude 写到了错误的 changelog 路径，需要用户纠正。
Claude 反复从日志误判审核进程状态，还曾启动重复的并发审核进程需要清理。
服务器角色和可达性假设在多个部署和 SSH 会话中造成了反复混淆。

直接粘贴到 Claude Code，它会帮你设置好。

自定义 Skills
以 Markdown 文件定义的可复用 /命令。
适合你的理由：你已经构建了 /wrloop 和 /wrap——将 /deploy 和 /commit 正式化将会标准化你最频繁的工作流（82 次提交、18 个部署会话）。
Create .claude/skills/deploy/SKILL.md: # Deploy Deploy from git-HEAD only. Test on 106, verify green, then ask explicit confirmation before pushing to 175 prod. Update content/docs/changelog.md and commit.
Hooks（钩子）
在生命周期事件时自动运行的 Shell 命令。
适合你的理由：大量编辑 TypeScript/Markdown，提交前的格式化/类型检查钩子可以在提交前捕获不存在的 SCSS token 等问题。
// .claude/settings.json { "hooks": { "PostToolUse": [{"matcher": "Edit|Write", "hooks": [{"type": "command", "command": "npx tsc --noEmit || true"}]}] } }
MCP 服务器
通过 MCP 将 Claude 连接到 GitHub Issue 和 API。
适合你的理由：你频繁分类/修复/关闭 GitHub Issue（#48、#75、#103-107）并管理服务器 API——MCP GitHub 服务器可以省去手动查询 Issue 的步骤。
claude mcp add github -- npx -y @modelcontextprotocol/server-github

新的使用方式

直接粘贴到 Claude Code，它会引导你完成。

防范 API 过载卡顿
多个会话被反复出现的 529/429 过载错误完全阻断，白白消耗了大量重试次数。
你有多个未完成（not_achieved）的会话（Logo 设计、拖拽上传、定时任务）是因为 GLM 网关/中继 API 过载导致 11 次以上重试全部失败。建议内置备用模型切换，避免将关键自动化任务绑定到配额受限的端点。在启动笔记本审核循环前先检查配额。
粘贴到 Claude Code：
Before starting this task, check the current API/quota status of the gateway. If overloaded or near quota limit, tell me immediately and suggest switching models rather than retrying repeatedly.
控制响应长度不超出 token 限制
Claude 的响应反复超出 500 token 输出上限，触发 API 报错。
在写审循环会话中你的输出预算受限，但 Claude 生成了过长的响应触发了报错。指示 Claude 保持状态更新简短，对较长的交付物进行分块。这在自动化 wrloop 运行中尤其重要。
粘贴到 Claude Code：
Keep all status responses under 400 tokens. For long deliverables, write to a file and report only a 2-line summary.
始终从 git-HEAD 部署，而非工作区文件
并行开发进程静默回滚了工作区文件，导致错误文件被部署。
一个反复出现的部署失败模式是：scp 了被并发进程回滚的工作区文件。切换到 git-HEAD 作为部署源解决了这个问题。让这成为默认做法，这样在你 18 个部署会话中就不会再出现了。
粘贴到 Claude Code：
Deploy using files from git HEAD only (git archive or checkout to a clean dir), never the live working tree, since parallel processes may revert files.

未来展望

AI 辅助开发正在从单会话编程帮助转向完全自主的写审部署循环，由监督 agent 在多台机器上门控工作。

自门控写审部署流水线
你的 /wrloop 技能已经能驱动多轮写审循环直至 PASS 裁定，但审核步骤一直在外部配额和进程健康盲点上卡顿。想象一条弹性流水线：主 agent 写代码，完全独立的审核 agent 对照 PRD 和测试进行审核，部署 agent 只有在绿灯后才发布——自动重试 529/429 错误、在模型网关之间故障转移，并直接读取审核者 transcript 来诊断卡顿，而不是从空日志中猜测。
入门：在审核步骤外包裹重试退避和网关故障转移逻辑，扩展你的 /wrloop 技能；添加一个 Task 子 agent，通过直接读取审核者 transcript 而非 pgrep 来检查进程健康。
粘贴到 Claude Code：
Upgrade my /wrloop skill into a resilient autonomous write-review-deploy pipeline. Requirements: (1) a writer agent implements the next batch against the PRD; (2) an independent reviewer subagent audits the code against the PRD and existing tests and emits a PASS/FAIL verdict; (3) on any 429/529/overload error, automatically retry with exponential backoff and fail over to an alternate model gateway instead of stopping; (4) diagnose reviewer health by reading its transcript directly, never inferring from empty logs or pgrep; (5) only deploy on a confirmed PASS, and require explicit prod re-confirmation before pushing to the 175 server. Show me the updated skill definition before running it.
部署并行进程冲突守卫
多个会话因并行开发进程静默回滚工作区文件而损失时间，导致提交失败、scp 部署过时代码，直到你切换到 git-HEAD 作为部署源才得以解决。一个常驻守卫 agent 可以检测同时修改同一仓库的并发进程、在每次部署前快照 git 状态、始终从已验证的提交而非工作区发布，并在现实偏离时附清晰 diff 中止——彻底消除一类静默的部署损坏。
入门：构建一个部署前钩子或技能，扫描竞争进程，严格从 git HEAD 部署，并在宣布成功前验证已部署文件哈希与提交树是否匹配。
粘贴到 Claude Code：
Create a /safe-deploy skill that prevents the parallel-process file-reversion bug we keep hitting. Before deploying: detect any other running processes that may modify this repo and warn me; create a git snapshot of current state; deploy ONLY from a specific verified git commit (never the working tree); after deploy, verify the remote file hashes match the committed versions and abort with a clear diff if they don't. Isolate exactly which commits should ship (e.g. web-safe changes only, excluding miniapp work) and require my confirmation before touching the 175 prod server.
跨机器 Agent 机群编排
你已经在笔记本上运行无头 Claude 来驱动跨 106 测试和 175 生产服务器的独立审核和视频渲染，但在代理、SSH 和进程发现方面的协调是手动且脆弱的。一个机群编排器可以映射每个 Claude 窗口和机器、将渲染或审核任务委托到正确节点、自动绕过 GFW/代理故障，并从 OOM 构建和 SSH 密钥交换问题中优雅恢复——把你的笔记本和服务器变成一个自愈 agent 网格。
入门：用 Agent 工具为每台机器生成委托子 agent，在 memory 中持久化实时拓扑图，并在编排技能中内置健康检查和代理故障转移。
粘贴到 Claude Code：
Build a cross-machine orchestration skill that treats my laptop, 106 test server, and 175 prod server as a coordinated agent fleet. It should: (1) discover and map all running Claude Code windows/processes and correct any misconceptions about how many exist; (2) delegate independent review and video-rendering work to the laptop's own Claude Code rather than doing it locally; (3) automatically handle proxy/SSH issues—retry OOM-killed builds (exit 137), recover from SSH key-exchange failures, and fall back to direct connection if a proxy returns 503; (4) maintain a persistent topology and health map in CLAUDE.md memory. Start by mapping the current fleet state.
「用户对着一片沉默连输了 11 次『继续』——彼时 Claude 被 529『服务过载』错误完全瘫痪，什么事也做不了。」
那次会话目标是添加拖拽上传图片功能，但反复出现的 API 过载错误彻底阻断了所有进展。用户不停重试——整整 11 次『继续』——记录下了人类不肯向无响应助手认输的那份执拗。