Claude Code 使用报告
2026-04-11 至 2026-04-29：已分析 572 个会话、7,851 条消息（总计 2,221 个会话）
先看结论
做得好的地方： 你最会把 Claude Code 当成能落地干活的远程工程师用：查问题、改代码、跑测试、提交、部署、盯线上，而不是只让它吐几段代码。Dressio 上线、repricer 逻辑、服务器清理、卡住的通知、Buy Box 和调价长时间监控，这些都吃到了这个用法的红利。Claude 能沿着代码、日志和远程机器一路追证据。
看做成的事 → 卡住你的地方： Claude 这边主要是开头假设错、偶尔跑偏、没跑完真实端到端验证就想交差。你这边反复卡在环境：凭证缺失或加载方式不同、API 权限没开、SSH 会话差异、部署前置条件，以及 observer 会话目标不够硬。
看问题出在哪 → 最快能试的改进： 把重复流程做成自定义 Skills：Dressio 发版检查、repricer canary 监控、远程服务器排障、Amazon 论坛/内容发布、环境与安全审查。再加 Hooks，在提交前自动跑 lint、测试、typecheck。定时监控可以试 Headless 模式，不用一直手动叫 Claude 查状态。
看可试功能 → 更激进的玩法： 可以把 Claude 往长期线上可靠性 agent 方向推：盯价格异常、僵尸锁、认证失败、timer、部署和日志，过了信心门槛才提修复或发修复。模型继续变强后，还能开并行 agent 小队：一个实现、一个写测试、一个查安全/合规、一个专门盯有没有偏离你的原始需求。
看下一步玩法 →
你主要在做什么
你怎么用 Claude Code
做成的事
问题出在哪
可以试的功能
新的使用方式
接下来可以怎么玩
团队反馈
你主要在做什么
这部分主要围绕把 Dressio 推向生产：Chrome Web Store 准备、Vercel 部署、认证修复、dashboard 性能、Stripe/测试流程和扩展行为。你大量使用 Claude Code 做多文件 TypeScript 修改、带测试门禁的 bug 修复、安全加固、提交和上线前检查。
这些会话覆盖 repricer v3 监控、Buy Box canary 循环、过度降价修复、卡单通知、dry-run timer，以及 VPS 和 Mac 环境里的履约锁问题。Claude Code 负责看日志、改调价逻辑、更新测试、停 timer、部署修复，并验证线上行为。
Claude 帮你写 Amazon 卖家论坛回复、刷信誉帖子、开店建议、评价处理 SOP、广告效果分析，以及 listing/图片优化提示词。这里混合了调研、文档起草、合规检查、接口逆向和经你确认后的发帖。
这部分包括远程 Mac 和 VPS 排障、磁盘清理、损坏配置恢复、Porkbun/Vercel DNS 排查、认证和 API 权限问题，以及环境变量调试。Claude Code 基本就是运维助手：SSH 上机器、看状态、恢复文件、验证凭证、定位部署阻塞。
有几次会话在探索离线网页/帖子归档工具的市场机会，不过其中一些跑偏成了无关的 Dressio 实现工作。Claude Code 被用来做研究型探索和项目上下文收集，但结果不稳定：有些原本要做的分析并没有在记录里完成。
你怎么用 Claude Code
你把 Claude Code 当成一个能信任的线上系统执行者 来用。很多时候你不是要建议，而是要它直接做：在服务器上装插件、盯 repricer 几个小时、停 systemd timer、清满盘的 Mac、部署修复、发论坛帖、把 Dressio 的改动推上线。你的请求通常不写很细的步骤，而是给目标：问题是什么、想要什么结果。接下来你期待 Claude 自己查、选路径、跑命令、测试，然后汇报状态。Bash 用量很高、进度/状态检查很多、observer 会话也多，这说明你更像是在用一个远程工程师/SRE，而不是结对编程里的自动补全。
你纠偏很快。Claude 漏了上下文，你会直接拉回来。比如它给插件安装的手动步骤时，你一句“你直接帮我装好啊?”；商品名写成中文但 prep staff 需要英文时，你让它出 v2；图片提示词像 Midjourney 或不符合 Amazon 规则时，你把方向拉回自然的 ChatGPT 语言和规则核验。你也很在意交付前的真实验证 ：Dressio auth 那次 Claude 还没做 E2E 就让你验证，明显让你不爽；而做得好的会话通常都有 dry-run、线上测试、回归套件、canary 监控、commit 和部署检查。
一个很明显的模式是并行/observer 工作流 。不少会话不是直接实现，而是在观察主会话、沉淀记忆、追进度或找 blocker。你经常让 Claude 跑很久，比如 3 小时里做约 50 轮 repricer 监控，或者跑 4 小时 canary。但方向错了、看错会话了、工作从目标上滑走了，你会打断。离线网页市场研究被带偏到无关的 Dressio 修复，就是这种情况。总的来说，你务实、重执行，也愿意放权；但你要求 Claude 犯错后快速恢复，并用证据证明结果。
关键模式： 你把 Claude Code 当成真实运营工作的自主执行 agent：给宽目标，让它跑；一旦验证、上下文或方向不对，就立刻纠偏。
用户回复时间分布
中位数：15.6 秒 • 平均：73.2 秒
多 Claude 并行会话
你会同时运行多个 Claude Code 会话。系统通过会话时间重叠识别这种 multi-clauding，说明你确实在并行推进工作。
你做成的事
572 个会话、147 小时下来，你最有效的用法是把 Claude Code 当成自主工程、监控和排查伙伴。
自主推进生产发布
你经常交给 Claude 完整闭环，而不是只要代码片段：它查问题、改代码、跑测试、提交，有时还部署。这在 Dressio 和 repricer 上尤其有效：认证修复、dashboard 性能、链接修复、env 测试、定价逻辑改动，都带着回归覆盖一起交付。
长时间运营监控
你很会把 Claude Code 用在人工盯着很烦的长时间监控上。repricer 和 Buy Box canary 说明：Claude 可以连续几小时重复检查、总结稳定性，只在数据真的异常时再让你介入。
跨系统深挖问题
你很擅长让 Claude 跨服务器、日志、timer、数据库、浏览器扩展代码和本地机器追问题。卡住的订单通知、磁盘满导致 .claude.json 损坏、每小时告警 bug、dashboard 加载问题，这些都体现了一个好用的排障方式：沿着证据跨环境追到根因，再修掉。
问题出在哪
主要摩擦来自三类：访问/认证卡住，Claude 偶尔没对齐任务或上下文，以及修复做完后还得多跑几轮验证才算真的完成。
访问和环境阻塞
你经常遇到凭证缺失、API 权限没开、SSH/会话差异，或者部署环境缺口。很多本来简单的活因此变慢。可以给每个项目留一份短 runbook：需要哪些 key、shell 怎么初始化、API 是否开通、部署前要检查什么。
测试远程 Mac 上的 codex computer-use 插件时，非交互 SSH 没加载 ~/.zshrc，OPENAI_API_KEY 不存在，会话在确认成功前就结束了。 处理 dressio.app DNS 时，Porkbun 凭证有效，但域名没有开启 API 访问。结果有 key 也改不了 DNS。
任务和上下文没对齐
有些会话会偏离你的要求，或者一开始就误解你的意图。这很浪费时间，也容易让人火大。尤其是 observer 或多会话工作流，最好先让 Claude 复述目标交付物和当前上下文，再动手。
你要的是离线网页保存工具的市场研究，但被观察的主会话在做无关的 Dressio 扩展版本修复，原需求没有完成。 你让 Claude 直接安装 UZI-Skill 和 OpenCLI 插件，它一开始却给了手动 slash-command 步骤。你不满之后，它才切回直接安装。
第一轮验证不够
不少任务最后是解决了，但中间靠失败假设、不完整测试，或者你亲自抓错才暴露问题。可以要求 Claude 跑端到端检查，用真实数据验证假设；在最接近真实的路径测过之前，不要把工作甩回给你。
Dressio magic-link auth 修复前两次方案都失败了，最后才正确手动解析 URL hash。更糟的是，Claude 在没完成 E2E 前就让你验证，这点让你很不爽。 订单排查一开始用了错误的 ASIN 映射，于是看到了 $159.99 左右的错误 Buy Box 数据，而不是相关的约 $60 数据。直到你抓出来才修正。
可以试的 Claude Code 功能
建议加入 CLAUDE.md 的内容
把下面内容复制给 Claude Code，就能加到你的 CLAUDE.md。
复制选中项
把下面内容复制给 Claude Code，它会帮你配置。
自定义 Skills
把高频流程做成可复用的 slash command。
为什么适合你： 你反复要进度总结、代码 review、commit、测试 gate、observer 更新和部署/状态检查。做成 skill 后，不用每次重新解释，Claude 也更稳定。
mkdir -p .claude/skills/gate .claude/skills/progress .claude/skills/review
cat > .claude/skills/gate/SKILL.md <<'EOF'
发版前运行完整项目验证 gate。识别包管理器，运行标准 lint/typecheck/test 命令；如果安全就修复失败项，并总结具体命令和通过/失败数量。
EOF
cat > .claude/skills/progress/SKILL.md <<'EOF'
总结当前 repo/项目状态：近期提交、未提交改动、当前 blocker、接下来 3 个动作，以及哪些需要用户批准。
EOF
cat > .claude/skills/review/SKILL.md <<'EOF'
审查当前 diff：正确性、安全、认证/session 处理、边界情况、测试和部署风险。按优先级给出发现和建议修复。
EOF
复制
Hooks
在 Claude Code 生命周期事件里自动跑 shell 命令。
为什么适合你： 你做得好的会话通常有 gate、格式化、测试和回归检查；出问题的地方常是代码有 bug 或验证不完整。Hooks 可以在编辑后自动跑常见检查。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "if [ -f package.json ]; then pnpm -s lint || true; fi"
}
]
}
]
}
}
复制
Headless 模式
从脚本、cron 或 CI/CD 里非交互运行 Claude。
为什么适合你： 你跑过很长的 repricer 监控循环、重复状态检查和生产验证。相比开着交互会话盯几小时，Headless 模式更适合定时监控和批量修复。
claude -p "监控 v3 repricer 一轮：检查最新日志、Buy Box 结果、卡单或激进降价，并输出 JSON，包含 status/blockers/actions" --allowedTools "Read,Bash,Grep"
复制
Claude Code 的新用法
把下面提示词复制给 Claude Code，它会带你走完整流程。
交付前把验证说清楚
编码前先让 Claude 定义并执行验收测试，尤其是认证、浏览器扩展、部署和 repricer 行为。
很多真正完成的会话，都因为 Claude 跑了 dry-run、回归套件、线上测试或监控循环。最烦的会话则是 Claude 太早让你验证，或者认证/浏览器流程没做 E2E 就说修好了。更好的模式是：开工前要验证计划，收尾时要证据报告，包含命令、日志、截图或线上数据。Supabase auth、扩展流程、远程 Mac 测试和生产部署，都会少返工。
复制到 Claude Code：
改代码前，先定义验收标准，以及你会亲自跑哪些验证。修完后，不要先让我验证；除非你已经跑过 E2E，或者明确说明为什么你这边跑不了。
复制
observer 会话必须有明确目标
observer agent 能记录记忆和进度，但有几次会话跑偏，记录了和目标无关的主会话工作。
你在 Dressio、repricer canary 和记忆观察里大量使用 observer 会话。它们在跟踪 commit、测试、blocker 和部署状态时很有用；但如果原需求是市场研究，observer 却记录了无关代码重构，就没价值了。给 observer 一个很窄的观察合同，并要求它一旦跑偏立刻报。
复制到 Claude Code：
作为主会话的 observer，只跟踪这个目标：<目标>。每次更新都必须包含：当前任务、观察到的证据、主会话是否仍对齐目标、blocker、下一步预期动作。如果主会话跑偏，立刻告诉我。
复制
把远程服务器排障标准化
做一份可重复使用的 checklist，覆盖 SSH、环境变量、磁盘空间、timer、锁、日志和部署状态。
很多运维成果都来自远程诊断：清磁盘、恢复损坏的 .claude.json、处理陈旧锁目录、停 timer、修认证环境、定位 VPS 部署 blocker。反复摩擦的不是排查本身，而是对 shell 环境、SSH key、磁盘、rm 静默失败或服务状态的假设。标准预检能更早抓住这些问题，也让长时间生产操作更安全。Mac mini、OCI VPS、repricer 和履约自动化尤其需要。
复制到 Claude Code：
调试这个远程问题前，先跑预检：hostname、pwd、git branch/status、磁盘使用、相关 env 是否存在（不要打印 secret）、systemd timers/services、近期日志、锁文件和部署方式。然后提出最小安全修复。
复制
研究任务和编码任务分开
做市场研究或策略问题时，明确告诉 Claude：除非你要求，不要碰 repo。
几次离线网页归档市场研究，最后变成无关的 Dressio 代码工作，或结果不清楚。这说明 Claude 可能继承了当前 repo 上下文，于是本能地去写代码，而不是回答商业问题。非编码任务要限制工具和输出格式，让会话留在分析上。也可以一开始就要求来源、竞品表、ICP、定价和风险。
复制到 Claude Code：
这是研究任务，不是编码任务。除非我明确要求，不要检查或修改 repo。请输出：市场地图、目标用户、主要竞品、付费意愿、差异化想法、分发渠道，以及 go/no-go 建议。
复制
把重复的 Amazon 流程做成 SOP
把 repricer、Buy Box、listing、prep center 和论坛发帖流程固化成可复用提示词或 skills。
你的会话反复碰到 Amazon 运营：repricer 调参、Buy Box 监控、卡单通知、PO 创建、卖家社区回复、评价 SOP 和 listing 优化。这些流程有固定约束：平台合规、ASIN/SKU 准确、给 prep center 的英文商品名、dry-run/live-run 区分、监控间隔。写成 SOP 能减少重复错误，比如 ID 搞错、图片建议违规、语言不匹配，也能让 Claude 在日常操作里更快、更自主。
复制到 Claude Code：
使用 Amazon 运营 SOP：从源数据核对 ASIN/SKU/order ID；区分 dry-run 和 live；内容建议前先查平台规则；prep center 面向字段使用英文商品标题；可 dry-run 时先 dry-run；最后总结证据和下一步。
复制
接下来可以怎么玩
AI 辅助开发正在从单任务 copiloting，走向长期自主工程系统：盯生产、跑实验、修回归，并协调多个 agent 并行工作。
自主生产可靠性循环
反复出现的监控、排障和 repricer 会话说明，Claude Code 很适合升级成长期运行的生产可靠性 agent。不用每次手动问状态或每 10 分钟查一次；agent 可以持续盯日志、指标、timer、陈旧锁、认证失败、价格异常和部署漂移。发现问题后先开修复、跑测试，过了信心门槛再发。
怎么开始： 把 Claude Code 和定时 Bash 脚本、systemd timers、日志访问、测试命令、清晰部署手册配在一起。repo 里放一份短 runbook，写清楚哪些动作可自主执行、什么时候升级给人、怎么回滚、必须验证什么。
复制到 Claude Code：
作为这个 repo 及相关服务器的自主生产可靠性工程师。先阅读 README、部署文档、package scripts、近期 git 历史、systemd timers、cron jobs 和可用日志。整理一份简洁可靠性地图，覆盖关键流程，尤其是 repricing、fulfillment、auth、notifications、background jobs 和 deployment。然后在接下来 2 小时内每 10 分钟跑一轮监控：检查日志、进程健康、陈旧锁、timer 状态、近期错误、API/auth 失败和业务不变量。如果发现低风险且修复明确的 bug，创建分支、实现修复、添加或更新回归测试、跑完整相关 gate、提交清晰 commit；只有 runbook 明确安全时才部署。如果部署被凭证、SSH key、外部权限或模糊业务风险阻塞，停下来报告具体 blocker、证据和最安全下一步。维护一条运行时间线，记录观察、命令、决策和验证结果。复制
并行 Agent Review 小队
数据里能看到：review 循环、observer agent 和代码库探索用得好时，结果很好；但误解需求或上下文不完整时，也会走歪。下一步高杠杆用法是并行跑多个专职 agent：一个实现、一个写测试、一个查安全、一个验证产品需求、一个专门盯有没有偏离你的原始要求。
怎么开始： 用 Claude Code subagents 或多个 Claude 会话，给每个会话明确角色和共享任务说明。要求每个 agent 产出可检查的发现，再由 lead agent 在编辑或发布前处理冲突。
复制到 Claude Code：
为以下任务协调并行 agent 工程流程：[粘贴任务]。创建五个角色：实现者、测试工程师、安全审查者、产品/需求审查者、偏移观察者。编码前，每个角色独立检查相关文件，并给出短计划、风险和验收标准。只有验收标准达成一致后，实现者才能改代码。测试工程师在可行时必须添加或更新先失败后通过的测试。安全审查者检查 auth、secrets、注入、数据访问和外部 API 风险。产品/需求审查者确认方案符合用户真实业务需求，包括语言、合规和运营限制。偏移观察者持续把所有工作和原始请求对比，发现无关转向就标记。实现后，跑完整相关 gate，总结每个 agent 的结论，解决分歧；只有测试通过且关键 reviewer 批准时才提交。如果 blocker 涉及凭证、权限、外部服务或不清楚的需求，暂停并询问最小必要输入。复制
测试驱动的自愈 backlog
很多成功会话都把 bug 变成测试，跑 gate，再提交定向修复。摩擦点则常来自反复认证问题、环境漂移、缺少可复用脚本，以及对 schema 或配置的错误假设。可以把这变成一个自动挖 backlog 的流程：Claude 扫 transcript、日志、失败记录和 TODO，把反复疼的点变成回归测试和脚本，然后迭代到测试套件能证明问题不会再出现。
怎么开始： 让 Claude Code 看最近的会话总结、issue 记录、日志和 repo 测试框架。让它列一个可重复失败的优先级 backlog，一次只做一项，先写测试；能做 mutation 或 sentinel check 的地方就做。
复制到 Claude Code：
作为测试驱动的自愈维护 agent。分析最近会话总结、摩擦记录、git 历史、失败日志、TODO 和当前测试套件。找出 10 个可以用代码、测试、脚本、runbook 或环境检查预防的重复失败模式，比如 auth callback 回归、陈旧锁处理、env var 漂移、schema 假设错误、部署 key 失败、注释掉的 .env.example 解析、timer 重复和任务跑偏。按影响、复现频率和验证难度排序。然后选择当前安全可改、优先级最高的一项。先写失败的回归测试或 sentinel check；如果可行，证明它在当前行为下失败；再实现最小稳健修复，跑目标测试，然后跑完整 gate。只有能防止未来操作错误时才更新文档。提交时在 commit message 里写清楚消除的失败模式。最后更新 backlog：已修什么、还剩什么、哪些后续项适合自主 agent，哪些需要人工批准。复制
“你直接帮我装好啊?”——你一句话砍掉 Claude 的保守说明，让它直接安装
在插件安装会话一开始，Claude 先给了 UZI-Skill 和 OpenCLI 的手动 slash-command 步骤。你用中文怼回去后，Claude 改了路线，绕过 slash-command 流程，直接在服务器上把两个插件装好。