• 时间:
  • 分类:

Claude Code 官方认证的重度用户，token 消耗量排在前1%。这篇文章是20天、20000次对话之后的完整复盘，从工作流到上下文管理，以及我在这个过程中真正踩过的坑。

一、认知转变：它不是 AI 助手，是 AI 团队

11月份刚用 Claude Code 时，我的定位是"更智能的 Cursor"——编程准确度更高，代码补全更准，仅此而已。

但用了一段时间之后，这个认知完全崩塌了。

Claude Code 不再是知识广泛的实习生，而是一个经验丰富、成本低廉的靠谱团队。区别在哪？实习生你得手把手教，团队你只需要说清楚要什么、验收结果。

这个认知转变直接影响了我之后的用法。

二、20天做了3个产品

Claude Code 已经具备独立闭环一个完整产品的能力。这20天我用它交付了：

产品技术栈用时说明
AI 对话 ChatBotFlutter2天支持语音文字、简历上传、AI 面试官
iOS 启动器 AppiOS 原生2天-
GroAskmacOS 原生2周Claude Code 调度面板

三个产品全部 Vibe Coding，没有手写过一行代码。 Opus 4.5 时代我还会看一下生成的代码，到了 Opus 4.6，我没有看过一行代码。

GroAsk 是我自己日常使用 Claude Code 过程中，实在受不了反复切终端、忘记哪个 Session 在干什么、上下文爆了还不知道，才动手做的工具。后面会反复提到它。

三、编程之外，Claude Code 还能干什么

很多人把 Claude Code 只当编程工具在用，但它的边界远不止于此：

  • 自动发推特——借助浏览器 MCP 与 Skill，我现在不手动发推特
  • 自动写文章 & 多平台分发——自定义 Skill，这篇文章的思否版本就是这样生成的
  • 产品数据分析——接入真实运营数据，自动产出分析报告
  • 深度市场调研——调研需求、收集用户痛点、竞品对比

核心逻辑是：任何可以描述清楚的工作流，都可以交给它。

四、我的产品迭代流程

小需求：一句话到上线

描述需求 → Claude Code 自动完成 → 直接上线 → 发现问题一句话修复

这种模式适合改 bug、加小功能。节点少，验收快，出了问题一句话描述现象，它自己排查修复。

大版本需求：结构化流程

需求收集 → PRD 产出 → 市场调研验证 → 技术方案 → 执行规划 → 按计划开发

具体步骤：

  1. 需求收集：个人使用痛点 + 社区反馈收集
  2. PRD 产出：描述原始需求，让 Claude Code 产出 PRD，再用市场调研验证
  3. 技术方案：Claude Code 编写技术方案，市场调研 review
  4. 执行规划：Claude Code 使用 TDD + Subagent 拆分任务
  5. 开发执行：Claude Code 按计划开发

实际比例大概是：一个3000字的 PRD → 10000字的技术方案 → 40000字的执行规划。

看起来很重，但这个前期投入是值得的。产品决策和技术决策是人最重要的工作，完全交给 AI 决策，面对复杂任务时不可靠——看似实现了需求，但维护难度是地狱级的。

另一个核心原则：让 AI 实现一个小的需求点，远比让 AI 一次性完成大而全的需求更可靠，效率也更高。别想着一口气把所有需求塞进一个 Session，拆小、交付、验收、再拆。

五、深度使用技巧

5.1 Skill：最强大的能力

Skill 的核心理念是个人工作流程的固化。

Skill 由两部分组成：

  • Prompt：用自然语言描述需要模型理解和判断的部分
  • Scripts：用代码描述确定性的部分（代码能搞定的不要用 Prompt）

一个发帖 Skill 的结构大概是这样：

#!/bin/bash
# scripts/post-to-platform.sh
# 确定性部分：读取文章、调用 API、记录状态

PLATFORM=$1
ARTICLE_PATH=$2

# 读取文章内容
CONTENT=$(cat "$ARTICLE_PATH")

# 调用平台 API（确定性，不需要模型判断）
curl -X POST "https://api.${PLATFORM}.com/articles" \
  -H "Authorization: Bearer $TOKEN" \
  -d "{\"content\": \"$CONTENT\"}"

# 记录发布状态
echo "$(date): Published to $PLATFORM" >> publish.log
# Prompt 部分（skill 定义文件）
根据目标平台的受众和调性，对文章进行适配改写：
- 思否：技术深度优先，加代码片段，≥1500字
- 即刻：碎片化，150字以内，口语化
- 推特：英文，280字以内，带链接

改写完成后调用 post-to-platform.sh 执行发布。

我常用的 Skill：自动代码提交、自动运行工程、自动拉取运营数据、自动发帖、自动写文章……

5.2 Subagent：复杂任务的上下文隔离

Subagent 允许你在一个主会话内使用多个 Agent。Claude 自带的 Task 工具就是 Subagent 实现——主 Session 把部分工作交给内部 Session，自己只关注输入和输出。

典型场景：同时调研5个竞品，每个竞品开一个 Subagent，主 Session 汇总结论。如果全塞在一个 Session 里，上下文会爆，而且互相干扰。

5.3 MCP：扩展能力，但要克制

我个人常用8个 MCP，但强烈建议用更少的。

MCP 占据大量原始上下文——每次对话开始，MCP 的工具描述就会占满上下文配额的一大块。实际建议：

  • 使用参数让 MCP 只暴露必要接口，而不是全量工具
  • 优先选 Rust/Go 编译的 MCP，而不是 Node.js 的，内存占用差距显著
  • 按项目配置，不要全局开一堆 MCP

5.4 Hooks：安全网

Claude Code 的 Hooks 允许你在特定操作前后执行自定义脚本。

目前最有价值的 Hook：让 Claude Code 在删除任何未被备份的文件之前先备份。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "node scripts/backup-before-delete.js"
          }
        ]
      }
    ]
  }
}

这个 Hook 已经救过我好几次——AI 有时候会很自信地把一个"没用的"文件删掉，结果那个文件里有关键配置。

5.5 调试技巧：日志优先

遇到难以复现的 bug，标准思路是让 AI 看代码 + 分析 + 猜原因。这条路往往很慢。

更有效的做法：让 AI 把日志写到本地，再根据日志排查。

// 让 Claude Code 在关键路径加日志
func fetchData() async {
    Logger.debug("fetchData called, timestamp: \(Date())")
    Logger.debug("Current state: \(self.state)")

    do {
        let result = try await api.fetch()
        Logger.debug("fetch success, result count: \(result.count)")
    } catch {
        Logger.error("fetch failed: \(error)")
        Logger.error("Stack trace: \(Thread.callStackSymbols)")
    }
}

日志在本地，你把日志喂给 Claude Code，它能精准定位问题。这是最有效的 bug 解决方式，没有之一。 很多看起来 AI 搞不定的 bug，用日志能在5分钟内解决。

六、长期记忆：解决"今天说明天忘"

Claude Code 没有原生的长期记忆，每个 Session 都是全新开始。我的解决方案是知识分组：

  1. 分层的 Knowledge 文件夹：告诉 Claude Code"有价值的信息存储到知识库"。踩过的坑、做过的决策、调研结论——全部沉淀在文件里，下次用 @knowledge/xxx.md 引入
  2. CLAUDE.md 分组管理：主 CLAUDE.md 保持精简，只放全局规则；子项目各自维护 CLAUDE.md，按需加载
  3. Rules 管理：把反复重复的规范提炼成 Rules，比手动每次提醒可靠得多

这套体系的好处是越用越顺手——积累的越多，Claude Code 对你的项目和工作方式理解越深。

七、上下文管理：保持模型智能的关键

这是很多人忽略的环节，也是影响输出质量最大的单一因素。

策略说明
MCP 工具按需引入使用参数精简接口暴露
CLAUDE.md 分层分组避免信息过载
上下文阈值 200k超过就换 Session
避免压缩上下文开新 Session 远优于压缩
实时监控了解每个 Session 的上下文消耗

上下文不推荐超过200k（1M 窗口的20%）。上下文爆了之后的 Claude Code，和上下文干净时的 Claude Code，质量差距类似于工作日上午 vs 加班到深夜——思维混乱，容易犯低级错误，建议无条件开新 Session。

最后一条"实时监控"是最容易被忽略的。很多人用着用着上下文爆了还不知道，模型回答质量断崖式下降才发现。

我用 GroAsk 解决这个问题——菜单栏一眼能看到每个 Claude Code 终端的上下文用量、当前状态、是否在等待输入。不用一个个切终端去查。

八、多 Session 管理：并行才是正确姿势

不要只开一个 Claude Code 进程，盯着它干活太低效了。

Claude Code 在运行的时候，很多时间是在思考、在调用工具、在等待。这段时间你完全可以在另一个 Session 里推进另一件事。

我的经验：

  • 舒适区：2-3个 Claude Code 进程并行，大多数场景够用
  • 高强度场景：5-10个，每个 Session 对应一个独立任务
  • 核心原则：只维护需要用户输入的 Session，其他的让它跑

多 Session 的实际问题是管理成本。开了5个以上终端之后，Cmd+Tab 找"哪个 Session 在等我回复"就很烦——经常扫完一圈发现其实3个都在等，错过了最优先的那个。

我现在的做法是用 GroAsk 的调度面板集中管理。所有 Claude Code 终端聚合在一个面板里，哪个在跑、哪个等输入、哪个上下文快满了，⌥Space 呼出之后一眼看完，点一下跳到对应终端，不用在窗口堆里翻找。

多 Session 工作流对生产效率的提升是非线性的——从1个到3个，效率大概翻2-3倍，不只是翻3倍，因为切换成本下降了。

九、模型的边界

模型的边界在于完全创新的能力。

做没有人做过的东西——训练数据里没有，只能推测——这时候，准确率会显著下降。模型善于综合已有模式产出结果，不善于在完全空白的地方创造。

这个边界意味着：在0-1的创新阶段，人的判断不可被替代。1-N的执行交给 AI，0-1的方向由人来定。

十、三句话总结

  1. Claude Code 不是 AI 助手，是 AI 团队。 用管理团队的方式去用它：说清楚要什么，给足上下文，验收结果。
  2. 人的核心价值是决策。 产品决策、技术决策、0-1的创新——这些交不出去。
  3. 工程化使用 AI。 Skill 固化流程、Subagent 管理复杂度、知识分组实现记忆、上下文管理保持智能。

作者日常用 Claude Code 开发 GroAsk——一个 macOS 菜单栏 AI 启动器，⌥Space 直达所有 AI，同时监控多个 Claude Code 终端状态。如果你也在重度用 Claude Code，欢迎试试。

标签: none

添加新评论