从把 Claude Code 当"更聪明的 Cursor",到现在把它当一个靠谱的外包团队在管——这篇是 20000 次对话后的真实复盘。token 消耗量排在全球前 1%。
刚开始用 Claude Code 的时候,觉得它就是编程准确度更高的 Cursor,没什么特别的。
后来才慢慢想明白:它不是 AI 助手,是一个经验丰富、成本极低的 AI 团队。
这一句话换掉之后,用法完全不一样了。
这 20 天我用 Claude Code 独立做了三个产品:
三个产品全部 Vibe Coding,没有手写过一行代码。Opus 4.5 时代还会看一眼代码,到了 Opus 4.6,代码我都不看了。
GroAsk 是我自己用 Claude Code 开发过程中,实在受不了反复切终端、不知道哪个 Session 在干嘛、上下文爆了还不知道,才自己动手做的。一个人的 AI 团队,也需要自己的调度系统。
这些不是演示,是我日常在用的流程。
小需求:一句话到上线
描述需求 → Claude Code 自动完成 → 直接上线 → 发现问题一句话修复
大版本:结构化流程
需求收集 → PRD 产出 → 市场调研验证 → 技术方案 → 执行规划 → 按计划开发
具体来说:先把原始需求描述给 Claude Code,让它产出 PRD,再调研验证;然后让它写技术方案,再用市场调研 review;最后用 TDD + Subagent 拆任务,按计划执行。
一个 3000 字的需求描述 → 10000 字的技术方案 → 40000 字的执行规划。
核心原则:
产品决策和技术决策是人最重要的工作。完全交给 AI 决策,面对复杂任务时仍然不可靠——看似实现了需求,维护起来是地狱级难度。
让 AI 实现一个小的需求点,远比让 AI 一次性完成大而全的需求,更容易、更可靠、效率也更高。
Skill 是我觉得最强大的能力,核心就是把个人工作流程固化。
两个关键部分:
我常用的 Skill:自动提交代码、自动运行工程、拉取运营数据、自动发帖、自动写文章……
这些流程固化下来之后,每次只需要触发一个命令,AI 帮你把整个链路跑完。
Subagent 让你在一个会话内使用多个 Agent 分担工作。Claude 自带的 Task 工具就是这个——主 Session 把部分任务拆出去,自己只关注输入和输出。
复杂任务就这么拆,上下文也好控制。
我个人用了 8 个 MCP,但强烈建议用更少的。MCP 占用大量原始上下文。优先选 Rust/Go 编译的 MCP,内存占用比 Node 的小很多。
目前最值得配的 Hook:让 Claude Code 在删除任何未备份的东西之前先备份。
让 AI 把日志写到本地,再根据日志排查。这是最有效的 bug 解决方式,没有之一。觉得 AI 搞不定了,就让它先加日志,结果往往超出你的预期。
长期记忆是很多人的痛点。我的做法:
| 策略 | 说明 |
|---|---|
| MCP 工具按需引入 | 精简接口暴露 |
| CLAUDE.md 分层分组 | 避免信息过载 |
| 上下文阈值 200k | 超过就换 Session |
| 避免压缩上下文 | 开新 Session 远优于压缩 |
| 实时监控 | 了解每个 Session 的上下文消耗 |
上下文不推荐超过 200k(1M 窗口的 20%)。区别就像工作日上午 vs 加班到深夜的同事——到了晚上,脑子已经乱了。永远用最智能的状态。
最后一条"实时监控"最容易被忽略。很多人用着用着上下文爆了还不知道,等到回答质量断崖下降才发现。这也是我做 GroAsk 的核心动机——菜单栏一眼看到每个 Claude Code 终端的上下文用量、当前状态、排队情况,不用一个个切终端去查。
不要同时只开一个 Claude Code 进程,盯着它干活太低效了。
但实际问题是:开了 5 个以上终端,光是找"哪个 Session 在等我"就够烦的了。
我现在用 GroAsk 的调度面板集中管理——哪个在跑、哪个等输入、哪个上下文快满了,一目了然。⌥Space 呼出面板,点一下跳到对应终端。作为独立开发者,一个人管一支 AI 团队,调度面板是刚需。
模型的边界在于完全创新的能力。
做没有人做过的东西——训练数据里没有,只能推测。这时候,需要发挥的是人的创造力和判断力。AI 团队再强,方向还是得人来定。
我平时用 Claude Code 开发 GroAsk——macOS 菜单栏 AI 启动器,⌥Space 直达所有 AI,同时监控多个 Claude Code 终端状态。如果你也在多 Session 跑 Claude Code,欢迎试试。