从"更智能的 Cursor"到"靠谱的外包团队"，这中间发生了什么？这篇文章是我20000次对话后的真实记录，包括踩过的坑、跑通的工作流，以及一些没人明说但很重要的使用细节
从"更智能的 Cursor"到"靠谱的外包团队"，这中间发生了什么？这篇文章是我20000次对话后的真实记录，包括踩过的坑、跑通的工作流，以及一些没人明说但很重要的使用细节。
我11月开始用 Claude Code，最初的定位很简单——比 Cursor 更准的编程助手。代码补全更聪明，bug 修得更干净，仅此而已。
这个认知在一两周后被彻底打破。
触发点来自外部：看到有人在一个 Claude Code Session 里跑完整的 PRD → 技术方案 → 代码实现全流程，产出是一个可以直接上线的小产品。我当时的反应是：等等，它能做这个？
回头看，那时候我的用法本质上是在用一把锤子敲螺丝——工具对了，但用法全错了。
Claude Code 不是 AI 助手，是 AI 团队。 它能独立完成的工作单元，不是一段代码、一个函数，而是一个完整的功能模块、一个独立产品。这个认知差距，决定了你能从它身上拿到什么。
说清楚这个认知之后，我用20天做了三个产品：
| 产品 | 技术栈 | 用时 |
|---|---|---|
| AI 对话 ChatBot | Flutter | 2天 |
| iOS 启动器 App | iOS 原生 | 2天 |
| GroAsk（macOS 菜单栏工具） | macOS 原生 Swift | 2周 |
这三个产品有一个共同点：全程 Vibe Coding，没有手写一行代码。 早期用 Opus 4.5 时我还会瞄一眼代码逻辑，到 Opus 4.6 以后，代码我基本不看了——因为发现看了也不会比它写得更好。
GroAsk 是这三个里花时间最长的，也是我日常工具链里用得最频繁的。它的出发点很简单：我自己在用 Claude Code 的过程中，烦透了反复切终端、忘记哪个 Session 在干什么、上下文爆了还不知道这些问题，所以动手做了一个。后面会专门讲它解决了什么问题。
描述需求 → Claude Code 自动完成 → 直接上线 → 发现问题一句话修复
这个链路的速度快到你很难习惯。我现在的节奏基本是：想到一个小功能，30秒描述清楚，5分钟后代码写完，跑一遍没问题就推上线。
重点不是"快"，而是反馈循环短到你敢随时改。以前改个功能要想半天"这值不值得动"，现在几乎没有这个心理成本。
大需求不能直接说"帮我做X"，这是最容易踩的坑。Claude Code 会给你一个看起来能用的东西，但底层设计是一团糟——需求稍微变一下就要重写，维护成本极高。
我现在的大版本流程：
需求收集 → PRD 产出 → 市场调研验证 → 技术方案 → 执行规划 → 按计划开发
具体拆开来看：
这个流程的产出密度是真实的：一个功能模块，可以从3000字的 PRD 生成10000字的技术方案，再展开成40000字的执行规划。这不是在堆字数——这是把模糊的想法变成可执行的工程细节的过程。
核心原则：产品决策和技术决策是人最重要的工作。 让 AI 实现一个清晰定义的小需求点，比让它一次性完成模糊的大需求，更容易、更可靠，效率也更高。
Skill 是 Claude Code 里我觉得被低估最严重的功能。
本质上，Skill 是你个人工作流的代码化版本。它分两部分：
判断标准很简单：这一步需要"理解"吗？需要就写进 Prompt，不需要就写成 Script。比如"分析这次提交的代码质量"是 Prompt 的事，"git add && git commit"是 Script 的事。
我现在常用的 Skill 有：自动原子化提交、自动拉取运营数据、自动多平台发帖、自动写文章。这篇文章本身，就是通过我的发帖 Skill 触发生成的。
一旦跑通，Skill 的复利效应很明显——每次调用都是在走一条已经验证过的路，不需要重新思考流程。
Claude Code 自带一个 Task 工具，本质是 Subagent——主 Session 把子任务分发给内部独立的 Session 执行，自己只关注输入和输出。
用 Subagent 的场景：任务可以并行、子任务之间相互独立、需要隔离上下文。
比如我让 Claude Code 做市场调研，它会自动拆成多个方向并行调研，每个方向是一个独立的 Subagent，最后把结果汇总到主 Session。单靠一个 Session 线性执行，速度和质量都差远了。
MCP 是 Claude Code 的能力扩展接口，理论上可以无限叠加工具。但我的实际经验是：MCP 越少越好。
原因是 MCP 的接口描述会直接占据系统 prompt 的空间，工具越多，原始上下文消耗越大，留给实际任务的空间越少。
两个实践建议：
我常用8个 MCP，但我会告诉别人：从2-3个开始，够用了再加。
Hooks 是在特定操作前后触发的脚本。目前对我最有价值的一个 Hook：让 Claude Code 在删除任何未被版本控制的内容之前先备份。
这条规则救过我几次。Claude Code 在执行清理任务时有时会删掉你没想到的东西，有了这个 Hook，最坏情况只是多了一个备份文件，而不是数据丢失。
调试经验里有一条被我反复验证的规律：当你觉得 AI 搞不定某个 bug 的时候，让它把日志写到本地，再根据日志排查。
这个方法的有效率超出我的预期。原因在于：很多 bug 在代码层面看起来像是逻辑问题，但实际上是数据在某个环节的状态不符合预期。日志把这个中间状态显式化之后，问题往往一眼就能看到。AI 也一样——它看到具体的日志比看到抽象的"哪里出错了"更能定位问题。
很多人用 Claude Code 的体验是：今天讲清楚了，明天又要重新说一遍。这个问题不是模型的问题，是记忆管理的问题。
我的解决方案是分层知识管理：
这个体系搭起来以后，确实是越用越顺手——因为每次积累的经验都留在了文件里，不会随着 Session 结束消失。
这是我认为最重要、也最容易被忽略的部分。
Claude Code 的上下文窗口是1M token，看起来很大。但实际上，我建议把200k当成实际上限，超过就开新 Session。
原因不复杂：上下文越长，模型的注意力越分散。一个刚开始的 Session 和一个跑了150k token 的 Session，回答质量差距是肉眼可见的。类比工作状态——早上精力充沛的同事和加班到凌晨的同事，你会找谁处理重要问题？
具体策略：
| 策略 | 说明 |
|---|---|
| MCP 工具按需引入 | 用配置精简接口暴露，不用的工具不要加载 |
| CLAUDE.md 分层分组 | 避免一次性加载所有项目信息 |
| 上下文阈值 200k | 超过就开新 Session，不压缩 |
| 避免压缩上下文 | 开新 Session 远优于让模型"总结之前的内容继续" |
| 实时监控各 Session 状态 | 知道每个 Session 现在在哪个阶段 |
最后这条"实时监控"是我最容易被问到的：你怎么知道哪个 Session 快满了？
我现在的做法是用 GroAsk。菜单栏常驻，⌥Space 呼出面板，能看到每个 Claude Code 终端当前的 token 消耗、运行状态、是否在等我输入。不用一个个切终端去查，也不用等到模型回答质量变差才意识到上下文爆了。这个功能是我做 GroAsk 最核心的动机——解决我自己每天都在碰的问题。
不要同时只开一个 Claude Code 进程。 这句话我现在看到有人只开一个终端在等 Claude Code 完成，就想说。
等待是最大的时间浪费。Claude Code 在跑任务的时候，你完全可以在另一个 Session 里推进另一个任务。
我的实际状态：
这里有一个实际问题：当你开了5个以上的终端，光是找"哪个 Session 现在在等我"就很烦。Cmd+Tab 在一堆窗口里翻找，效率很低。
这正是 GroAsk 调度面板存在的理由。所有 Claude Code 终端集中在一个面板里，哪个在跑、哪个等输入、哪个上下文快满了，一目了然。点一下就能跳到对应终端。这个工具本身也是用 Claude Code 开发的，算是一个自我指涉的例子。感兴趣可以看看：groask.com/zh
这个问题值得认真回答。
在有参照的领域里，Claude Code 的能力已经非常强——有足够的训练数据支撑它做出合理的判断和实现。你描述一个业界常见的功能，它大概率能给出一个可用的方案。
但做没有人做过的东西，这是它真正的边界。
训练数据里没有参照，它只能推测。这时候，模型会给你一个"看起来合理"的答案，但合不合适你不看是不知道的。创新本身的方向选择、价值判断、取舍——这些交不出去。
所以那个分工最终是：人负责"做什么"和"为什么"，AI 负责"怎么做"。 前者是决策，后者是执行。把决策也交出去，就会在复杂场景下翻车。
作者在用 Claude Code 开发 GroAsk——一个 macOS 菜单栏工具，⌥Space 直达多个 AI，同时监控所有 Claude Code 终端的状态和上下文用量。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。