Claude Code 使用洞察¶

139 个会话中的 860 条消息（总计 1,533 个会话） | 2026-03-20 至 2026-03-29

概览¶

做得好的方面： 你已经形成了将并行子代理作为力量倍增器的有效模式——同时调度 10+ 个代理进行批量翻译、研究小组和 Obsidian 库操作。你的结构化「研究到交付」工作流非常有效：从开放式代码库探索到精炼的规范文档和整合交付物，在单个会话中完成。

遇到的阻碍： 在 Claude 方面，它倾向于用不必要的参数和复杂度来过度工程化解决方案，并容易陷入 Docker/基础设施的反复试错循环，而不是提前提出澄清问题。在你方面，多代理工作流有时会因为速率限制或会话提前结束而丢失工作成果——更小、顺序执行的批次可以减少编排开销较高时浪费精力的风险。

可以快速尝试的改进： 试试使用 Headless 模式将批量翻译和文档生成流水线脚本化，让它们无需交互式操作即可自动运行。设置一个 hook 来自动为新建脚本添加执行权限，可以消除你经常遇到的权限错误。在启动代理团队之前，添加一个简短的确认步骤来定义范围和输出格式——仅这一步就能减少失败的多代理设置。

更有野心的方向： 随着模型的改进，你的多代理编排可以变得完全自主——一个主导代理分解复杂任务，调度 20+ 个带有重试逻辑的子代理，无需人工干预即可自我纠正。测试驱动的实现循环（Claude 先写失败的测试，然后迭代直到全部通过）可以消除你今天遇到的大部分有缺陷代码的摩擦。你的文档流水线也可以端到端自主运行：爬取项目、生成文档、翻译成中文、用 wikilink 交叉链接、验证一致性——全部无需人工干预。

关键数据¶

工作内容¶

Obsidian 库管理与知识图谱（~10 个会话）¶

使用 CODE 方法对 Obsidian 库进行大规模重构，构建 wikilink 网络以填充图谱视图，并创建 MOC（内容地图）枢纽文件。Claude 在数百个 Markdown 文件上运行并行子代理来添加双向 wikilink，将覆盖率从约 50% 提升到 70% 以上，链接数量显著增长。还创建了用于自动归档和链接维护的技能和命令。

XXPay 与 USDT 发票机器人开发（~8 个会话）¶

开发并部署与 XXPay 支付系统集成的 USDT 发票机器人，运行在 Docker 中。Claude 协助调试 Docker 网络（Host 头问题）、修复 Go 源代码损坏、创建 Dockerfile、生成结算统计的 SQL 查询，以及使用 Repomix 打包项目。脚本、配置和容器编排的迭代调试是反复出现的模式。

Telegram 机器人研究与 MISSION-599 设计（~5 个会话）¶

MISSION-599 的研究和设计阶段——一个定时每小时的 Telegram 推送通知功能，用于 USDT 业务数据统计。Claude 组织多代理研究团队调查 Telegram Bot API 模式和 XXPay 数据库结构，生成包含 SQL 时间逻辑的研究报告，并创建了带流程图的完整规范文档。代理团队用于并行代码库探索。

Markdown 翻译流水线 en2zh（~5 个会话）¶

使用 en2zh 技能流水线批量翻译项目文档目录，从英文到中文。Claude 编排 13+ 个并行子代理一次翻译 20+ 个 Markdown 文件，保留代码块和技术术语。部分会话遇到速率限制（429）错误和混合语言输出，需要手动重新翻译失败的文件。

项目文档与 CLAUDE.md 改进（~7 个会话）¶

使用代码库分析和专用改进技能插件，跨多个仓库系统化地创建和改进 CLAUDE.md 项目文档文件。Claude 探索项目结构、审计现有文档的准确性、减少重复，并将需求文档整合为统一的开发计划。还包括权限模式调整等配置变更。

使用统计¶

需求分布¶

最常用的工具¶

编程语言¶

会话类型¶

你如何使用 Claude Code¶

你是一个任务驱动的强力用户，将 Claude Code 视为项目管理和自动化引擎，而不仅仅是编码助手。在短短 10 天内完成了 139 个会话和 89 小时的工作，你运行着密集的、面向任务的工作流——批量翻译整个 Markdown 文件目录为中文、用数百个文件重构 Obsidian 库、编排多代理研究团队，以及构建自定义 Claude Code 技能和插件。你最常用的工具是 Bash（2,062 次）和 Read（1,060 次），表明你严重依赖 Claude 探索代码库和执行系统命令的能力。文档和知识管理是你的主要领域——Markdown 在语言使用中占 751 次，远超 TypeScript（356）或 Java（155），你的主要目标是文档、文件管理和文档创建。你显然正在围绕 Claude Code 构建一个复杂的个人知识系统和工具生态系统。

你的交互风格是指令式和迭代式的——你给出清晰的高层指令，让 Claude 运行，但当输出不符合你的设想时，你会果断干预。你多次要求 Claude 简化过度工程化的设计（剥离命令参数、将文件夹深度从 3 层减到 2 层、缩小功能范围），表明你重视优雅和简洁胜过全面性。当 Claude 走错方向时——修改 Go 代码而不是改配置、写 HTML 而不是 Markdown、设计累计统计而非按小时统计的 SQL——你会用具体反馈纠正方向，有时需要两三轮才能得到正确结果。值得注意的是，你至少两次中断了会话，当 Claude 在设置上花费太长时间时（多代理股票研究和 Telegram 深度研究），表明你对冗长的前言容忍度很低，偏好结果胜过过程。你 94.4% 的任务完成率和 83% 的满意度评分证实了这种方法对你非常有效。

关键模式： 你是一个指令式、以结果为导向的操作者，发出高层命令，并在 Claude 过度工程化解决方案或偏离你的设想时果断纠正方向。

用户响应时间分布¶

中位数：68.8 秒 | 平均值：185.2 秒

多实例并行使用¶

你同时运行多个 Claude Code 会话。当会话在时间上重叠时，会被检测为多实例并行使用，表明你在进行并行工作流。

按时段分布¶

工具错误统计¶

令人印象深刻的成果¶

你是一个利用 Claude Code 进行雄心勃勃的项目的强力用户——跨多代理研究、Obsidian 知识管理和跨语言文档，规模令人印象深刻。

并行代理编排¶

你经常启动多代理团队——调度 13 个并行子代理翻译 20+ 个文件，组织研究小组调查 Telegram API 和 SQL 模式，以及启动后台代理系统地构建库的 wikilink 网络。你已经习惯将代理作为力量倍增器，取得了诸如在多轮中将 Obsidian wikilink 从 739 增加到 1,800 的成果。

Obsidian 库工程¶

你已将 Obsidian 库管理变成了可重复的、技能驱动的工作流——使用 CODE 方法重构 798 个文件、构建自动归档系统、创建 MOC 枢纽文件，并在知识库中实现了 94.4% 的 wikilink 覆盖率。你设计自定义技能并迭代优化，将临时任务转化为无需参数的命令，只需执行即可。

结构化「研究到交付」流水线¶

你持续从开放式研究推进到精炼的交付物——调查 XXPay 的结算系统、迭代 SQL 查询直到满足精确的按小时时间要求，然后将所有内容整合为面向领导的文档。你的 MISSION-599 工作流在单个线程中完成了从代码库探索到代理驱动研究再到带流程图的完整规范。

最有帮助的能力¶

任务完成情况¶

问题出在哪里¶

你的主要摩擦模式来自于 Claude 在理解你简单意图之前就过度工程化解决方案、在 Docker 和基础设施配置中陷入过多的试错循环，以及因多代理设置不完整或会话中断而丢失工作成果。

在理解简单需求之前就过度工程化¶

当你实际想要简单的东西时，Claude 频繁构建复杂的、参数过多的解决方案，迫使你反复要求简化。你可以通过提前说明最小可行期望来节省迭代次数，比如「保持简单，不要参数」。

• Claude 设计了一个带多个参数和三种模式的 Obsidian 命令文件，但你不得不明确要求将其精简为只有 wikilink 且无参数——初始设计过度工程化了。
• Claude 创建了一个 3 层深的 Obsidian 文件夹结构被你拒绝，你要求最多 2 层，而且它最初将计划文件写到了错误的目录，而不是你建议的 000-Planning/ 位置。

Docker 和基础设施的试错循环¶

在处理 Docker Compose、网络和部署配置时，Claude 会陷入冗长的试错循环，而不是提前提出澄清问题。在开始时提供明确的基础设施约束和期望方法会有帮助，而不是让 Claude 迭代错误的解决方案。

• Claude 在 Docker Compose YAML 锚点语法、构建上下文路径和 Dockerfile COPY 路径上经历了多次失败尝试，最终你们回退到更简单的 shell 脚本方式来管理应用服务。
• 在修复 USDT 发票机器人的 Docker 网络 Host 头问题时，Claude 尝试修改 Go 代码添加 Host 头，而不是简单地按你的要求更改配置 IP，还做了一个不正确的默认行为编辑需要回退。

多代理和长时间运行的设置失败¶

当 Claude 生成子代理或设置复杂的多步工作流时，编排的开销有时会导致工作丢失、速率限制失败或在结果交付前会话结束。你可以通过请求更小的、顺序执行的任务而不是大型并行批次来减少这种情况。

• 在使用 13 个并行子代理批量翻译 20+ 个文件时，部分遇到速率限制错误（429）并产生乱码的混合语言输出，需要事后手动重新翻译这些文件。
• Claude 花了大量时间设置多代理研究团队并通过多个 Bash 命令生成代理，但你在完成前中断了过程——表明编排开销太慢或与你的期望不符。

主要摩擦类型¶

推断满意度¶

值得尝试的 Claude Code 功能¶

建议添加到 CLAUDE.md 的内容¶

1. 输出格式

## 输出格式
- 默认使用 Markdown 格式输出文档，不要使用 HTML。
- 完成任务后，主动给出明确的完成总结，说明做了什么、结果是什么。
- 保持设计简单，优先无参数命令，不要过度工程化。

用户多次纠正格式问题（HTML→Markdown），多次问「处理完毕？」催促完成总结，多次要求简化命令和减少参数。

2. 文件操作规则

## 文件操作规则
- 写文件前确认目标目录存在，写完后验证文件在正确路径。
- 目录结构最深不超过 2 层。
- 修改多字节字符（中文）文件时，使用更短、更精确的匹配字符串进行编辑。

多次出现文件写入错误路径、目录结构过深被拒绝、UTF-8 多字节字符编辑失败等问题。

3. Docker & 部署

## Docker & 部署
- 优先使用简单的 shell 脚本管理服务，避免过度复杂的 Docker Compose 配置（anchors、多服务编排）。
- 修改配置前先理解现有架构，优先改配置而非改代码（如 IP/Host 问题优先改配置文件）。
- 给脚本和 hook 文件添加执行权限（chmod +x）。

Docker Compose YAML 反复失败最终回退到 shell 脚本；多次走弯路改代码而用户要求改配置；多次出现权限错误。

4. SQL & 数据统计

## SQL & 数据统计
- 时间维度的统计需求要明确确认：是累计值还是区间值？粒度是小时还是天？执行时间点是什么？
- 使用 Python 而非 awk/sed 解析 YAML 或复杂结构化数据。
- SQL 写完后保存到指定文档路径。

SQL 统计需求被用户纠正两次（累计→每小时→上一小时数据）；awk 解析 frontmatter 出现重复行问题；用户多次要求将 SQL 结果写入文档。

5. 翻译工作流 (en2zh)

## 翻译工作流 (en2zh)
- 批量翻译任务使用并行 Agent 执行，每个 Agent 处理 2-3 个文件以减少 rate limit 错误。
- 翻译时保留代码块、技术术语（如 API 名称、协议名）不翻译。
- 翻译完成后检查是否有混合语言（中英混杂）的输出，如有则重新翻译该文件。

翻译项目是高频任务（5+ sessions），多次出现 rate limit 429 和混合语言输出需要手动修补。

推荐功能¶

自定义技能（Custom Skills）¶

一键调用翻译、归档、文档生成等常用工作流

为什么适合你： 你频繁执行批量翻译（en2zh）、Obsidian 归档、CLAUDE.md 改进等重复性任务，Custom Skills 可以把多步流程封装成 /en2zh、/archive、/improve-md 等单命令调用，避免每次重复描述流程。

钩子（Hooks）¶

自动给新建脚本加执行权限，自动验证输出格式

为什么适合你： 多次出现脚本缺少执行权限（chmod +x）的问题，还有 HTML/Markdown 格式混淆。Hooks 可以在文件写入后自动修复权限，或在特定操作后运行格式检查。

无头模式（Headless Mode）¶

脚本化批量执行翻译和文档生成任务

为什么适合你： 你的翻译任务和 Obsidian 维护任务模式固定，可以用 Headless Mode 编入 cron 或脚本流水线自动执行，省去每次手动启动会话的步骤。

# 批量翻译所有未翻译的 markdown 文件
claude -p "Find all English .md files in ./docs that don't have a corresponding Chinese version in ./docs/zh, and translate them using the en2zh pipeline" --allowedTools "Read,Write,Edit,Bash,Glob"

Claude Code 的新使用方式¶

批量翻译流水线¶

将你的 en2zh 翻译流程标准化为 Custom Skill，配合 Headless Mode 实现自动化。

你有 5+ 个会话在做英文到中文的 Markdown 批量翻译，流程高度一致：扫描目录→并行 Agent 翻译→检查质量→修补问题。将其封装为 /en2zh skill 后，每次只需指定目录即可。还可以结合 Headless Mode 做定时翻译任务。

Agent 团队研究模式¶

在启动多 Agent 研究团队前，先用简短 prompt 确认研究范围和输出格式。

你多次使用 Agent 团队进行代码库研究（Telegram API、XXPay 架构、股票分析），但有时因设置耗时过长被中断。建议在启动前先花 30 秒确认：研究目标、输出格式（Markdown 报告？SQL？）、时间预算。这样 Agent 可以更快进入执行阶段。

Obsidian 知识图谱构建¶

将 wikilink 构建和归档任务参数化，减少每次的来回沟通。

你有 6+ 个会话在做 Obsidian wikilink 构建和归档，每次都需要描述需求（覆盖率目标、排除目录、链接策略）。将这些参数固化到 CLAUDE.md 或 skill 中，以后只需说「运行 wikilink 构建」即可自动执行。

减少试错的先确认策略¶

对涉及 Docker、SQL、文件结构的任务，先做简短方案确认再执行。

最大的摩擦来源是反复试错：Docker Compose 失败多次后回退、SQL 被纠正两次、文件结构被拒绝。这些都可以通过执行前花 1 分钟确认方案来避免。在 CLAUDE.md 中加入「先确认后执行」的规则，对配置变更和架构决策尤其重要。

未来展望¶

AI 辅助开发正在从交互式结对编程快速演变为自主多代理工作流——由专门的代理团队并行研究、编码、测试和迭代——你的 139 个会话数据揭示了为这一跨越做好准备清晰模式。

自主并行研究代理团队¶

无需逐个会话手动编排代理团队，你可以启动一个自协调的研究集群——一个主导代理分解复杂问题，调度 10-20 个具有特定调查范围的并行子代理，将发现汇总为结构化报告，并迭代优化薄弱环节——全部无需人工干预。

如何开始： 使用 Claude Code 的 Agent 工具配合协调器提示，批量生成子代理，将中间结果保存到文件作为检查点，并让每个代理在返回前验证自己的输出。结合自定义技能命令如 /research-deep。

迭代式测试驱动功能实现¶

你的数据显示了 16 次有缺陷的代码和 8 次错误方法的摩擦事件——几乎都可以通过反转工作流来修复：先写测试，然后让自主代理循环实现尝试直到每个测试通过。代理可以编写失败的测试套件、实现功能、运行测试、阅读失败输出、自我纠正并重复——直到全部通过——交付经过验证的、可工作的代码，无需人工调试会话。

如何开始： 构建你的提示，让 Claude 先写测试，然后用 Bash 循环运行测试运行器来实现。特别适合你项目中已有的 jest、go test 或 JUnit 流水线。

多项目自主文档流水线¶

你的首要目标是文档（6 个会话），有大量的 Markdown 使用（751 次文件操作）和成功的 CLAUDE.md 创建模式——这非常适合一个完全自主的流水线，爬取工作区中的每个项目、生成或更新文档、使用你验证过的 en2zh 流水线翻译成中文、创建跨项目的 wikilink，并在所有文件中保持一致性，无需任何人工干预。

如何开始： 构建一个自定义 Claude Code 技能命令，将你现有的 CLAUDE.md 改进器、en2zh 翻译器和 Obsidian wikilink 构建器链接为一个由单个命令触发的自主流水线。使用 TaskUpdate 跟踪各阶段进度。

"Claude 使用 CODE 方法将 798 个文件的整个 Obsidian 库重构为 9 个区域，然后在多个会话中执着地为库编织 wikilink，将覆盖率从 49.7% 提升到 94.4%——本质上是从头为用户构建了一个活的知识图谱。"

在多个会话中，Claude 成了用户的个人知识管理顾问：归档 178 个文件、修复 149 个标签、添加 739+ 个 wikilink、创建 MOC（内容地图）枢纽文件，甚至设计了自动归档系统。仅一个会话就修改了 104 个文件，追求完美的图谱视图。