我是如何用 Claude Code 的

我用 Claude Code 大概有半年了。最近跑了一次它自带的使用分析（Insights），看到一组数字：191 个会话，2821 次命令调用，602 次子代理调度，191 次 git 提交。盯着这些数字看了一会儿，我意识到一件事——我早就不把它当聊天助手了。

它更像我团队里的一个初级成员。我给方向，它来执行。做得好就继续，跑偏了就拽回来。

这篇文章不是教程，就是聊聊我自己怎么用的，用下来什么感受。

我的核心玩法：写个清单，让它自己干

如果只能用一句话概括我怎么用 Claude Code，那就是：我写 TODO，它来执行。

操作很简单。我把一个项目拆成一串任务，写在 TODO.md 里。然后启动一个叫 Loop 的循环模式，给一句提示词："读 TODO，找到第一个没完成的任务，执行，标记完成，提交代码，然后找下一个。"

接下来我就去干别的事了。

Claude 会一个任务接一个任务地推进，每做完一个自动 commit 一次。有时候回来一看，十几个任务全绿了，git log 里整整齐齐排着一串提交记录，像一个勤恳的实习生交上来的作业本。

这个模式我跑过最长的一次是 5 个小时。一个 Stripe 支付集成项目，从创建配置、安装依赖、搭建产品页面，一直到部署上线，7 个阶段全部自主完成。中间我大概看了两三次进度，没怎么干预。

说实话，第一次跑通的时候挺震撼的。不是因为它写的代码有多好——中间当然有 bug，后面会说到——而是这种 "交代完就不用管" 的体验，在以前是不存在的。以前用 ChatGPT 那种对话模式，每说一句都得等回复，看完再决定下一步，整个过程是你推着它走。现在反过来了，是它自己在走，你只需要偶尔抬头看一眼方向对不对。

它干了什么：远不止写代码

"Claude Code"这个名字有点误导——让人以为它只是个编程工具。我的实际使用里，写代码大概只占三分之一，剩下的全是别的东西。

最密集的一段时间，我在做一个 AI 培训工作坊的材料。Marp 幻灯片、案例库、练习题、讲义——一整套东西。这些内容不适合手工一点一点打磨，因为每改一处措辞，相关的好几个地方都要跟着调整。我就把它设计成了一个 20 轮的自动化流水线：先生成骨架，然后进入 "生成—审稿—修订" 的循环，每一轮自动优化上一轮的问题。20 轮跑完，一整套材料就出来了。

学术写作那边更有意思。有一次我想研究一下顶级经济学家的写作风格，就让 Claude 去下载 Raj Chetty 的 19 篇发表论文，全部转成 Markdown，逐篇分析段落结构、论证模式、过渡词使用习惯，最后合成了一份完整的风格画像。这个画像后来我真的拿来指导自己写论文了——比自己模糊地"多读好论文"有效得多，因为它把风格拆解成了可操作的具体特征。

论文修订也是个高频场景。我有一篇文章在走审稿流程，需要对审稿意见逐条回应。我开了一个会话，派出多个并行子代理——一个分析引言结构，一个提取实验数据做一致性检查，一个对比审稿人提到的参考文献——最后汇总成修改方案。一个会话下来，8 次提交，效率非常高。

还有叙事 Wiki、技术博客、iOS 应用发布、课程网站搭建……项目类型跨度大到我自己都有点意外。回过头看，Claude Code 的能力边界其实不在于它会什么语言或框架，而在于 你愿不愿意花时间把任务拆清楚。只要任务描述足够明确，它几乎什么都能接。

翻车是常态

讲了这么多好听的，该说说翻车了。

Insights 报告里有一个数字让我印象很深：54 次 "方向错误" 事件。什么意思呢？就是 Claude 理解错了我的意图，往错误的方向跑了。

举几个典型的场景。

有一次我只是让它更新 TODO.md 里的任务状态——把某个任务标记为完成。结果它不光改了状态，还自己开始写代码实现下一个任务了，甚至在改 TODO 文件的过程中不小心删掉了文件里的一段工作流规则。我当时的反应大概就是：兄弟，我让你打个勾，没让你动手术。

还有一次修 CSS。一个很小的样式问题，它改了一版不行，又改一版还不行，来来回回试了好几轮。最关键的是，每改一次它就让我去浏览器里刷新检查——拜托，你是有终端的，你自己跑测试看效果啊。最后我忍不住说了一句："自己调试，不要每次都让我检查。"它立刻就学乖了，后面开始自己验证了。

29 次代码 bug，6 次过度修改。这些数字单看挺吓人的，但放在 191 个会话的总量里，其实就是百分之十几的出错率。而且关键是：几乎所有任务最终都完成了。70 次完全达成，只有 2 次没做成。

我后来想明白了一个道理：和 AI 协作，追求零失误是不现实的，也没必要。更好的策略是 接受它会犯错，然后在下一轮快速修正。就像带一个能力尚可但经验不足的新人，你不会期待他每一步都完美，但你会要求他能纠正、能迭代。

我把这种方式叫 "容错式协作"。不写滴水不漏的指令，而是给一个大方向，让它先跑起来，出了问题再纠偏。整体效率比事无巨细地写 prompt 高得多。

那个按门铃的故事

说一个最离谱的翻车。

有一次 Loop 在执行任务清单，所有任务都完成了。正常来说，它应该输出 "DONE" 然后停下来。但不知道哪里出了问题，它没停。

"检查 TODO.md，所有任务均已完成，没有待办事项。"

然后它又检查了一遍。

"检查 TODO.md，所有任务均已完成，没有待办事项。"

又来。

"检查 TODO.md，所有任务均已完成，没有待办事项。"

同一句话重复输出了大约 100 遍，直到我手动按了 Ctrl+C 终止。就像一个快递员按门铃按了一百下，所有人都下班了他还在按——非常敬业，但也非常傻。

这件事让我笑了很久，但也让我开始认真思考 Loop 的终止条件问题。后来我给 Loop 加了更明确的退出逻辑，也开始考虑用 Headless Mode 替代简单的 Loop，用脚本来控制执行流程。

工具的边界，往往是在这种荒诞的时刻才看得最清楚。

我搭了一整套"基础设施"

半年用下来，我围绕 Claude Code 搭建了一整套基础设施。这些东西的投入成本不低——有些 Skill 我花了二十多个小时才调通——但回报也很可观，因为它们每天都在省时间。

CLAUDE.md 是最基础的一层。每个项目根目录放一个，告诉 Claude 这个项目的背景、文件结构、写作风格、做事规矩。就像给新员工的入职手册，读完它就知道在这个项目里该怎么干活。我的全局 CLAUDE.md 已经迭代了很多版，核心原则是"少即是多"——只放每次会话都要用的规则，低频的东西封装到 Skill 里。

Skills 是第二层。把高频工作流封装成一个个可复用的模块，Claude 能根据任务自动识别该用哪个。比如我有一个中文引号转换的 Skill，有一个笔记归档的 Skill，有一个论文修订的 Skill。每个 Skill 背后是一套完整的处理逻辑和质量标准，但对我来说只需要一句话就能触发。

并行子代理 是最让我兴奋的部分。复杂任务不一定要串行做，很多时候可以同时派出好几个 Agent，各管一摊，最后汇总。论文修订的时候，我同时派出了 11 个文档处理代理，这在传统工作流里完全不可想象。

这些基础设施叠加起来的效果是：Claude Code 不再是一个 "我打开来用" 的工具，而是整个工作环境的一部分。它嵌在我的编辑器里、连着我的文件系统、读着我的项目文档、按着我设定的规则干活。这种感觉和打开一个网页聊天框完全不同。

我和 Claude Code 的"关系"

用了半年之后，如果有人问我和 Claude Code 是什么关系，我会说：它是我团队里最勤奋但最需要管理的那个人。

勤奋体现在：给它活它就干，不抱怨不拖延，24 小时随叫随到，遇到问题会自己尝试解决（虽然有时候越解决越乱）。

需要管理体现在：它经常理解偏你的意思，有时候好心办坏事，偶尔会在不该发挥的地方过度发挥。你不能完全放手不管，但也不能事事盯着——最佳状态是一种 松紧适度的信任。

我很少中途打断它——191 个会话里只有 2 次直接中断。大部分时候我选择让它先做完，做错了再纠。这跟我在学校带学生的方式有点像：给一个方向，让他们先试，犯了错一起复盘，比你手把手教的效果好。

当然，这种方式的前提是你能承受错误的成本。如果是生产环境的关键代码，我不会这么放手；但对于内容生产、文档写作、原型开发这类场景，试错成本很低，自主执行的效率优势就很明显了。

半年下来的几点感受

第一，规划是人的活，执行是 AI 的活。 把一个大目标拆成清晰的任务列表，这件事目前还是人做更靠谱。但列表一旦拆好，逐个执行这件事，AI 比人快很多，也更不容易分心。

第二，约束边界比详细指令更有效。 与其告诉 Claude 每一步怎么做，不如告诉它 "只做这个，不要碰那个"。我吃过很多次亏之后发现，限定范围比规定动作省事得多。

第三，基础设施投入值得。 前期花时间搭 CLAUDE.md、写 Skill、调 Hook，后面每次使用都在吃红利。这是一个很典型的边际成本递减的事情，经济学家不需要别人来解释这个道理。

第四，用 AI 是一种管理能力。 这一点我越来越确信。用好 AI 和用好团队需要的能力是高度重叠的：能拆任务、能定标准、能容错、能给有效反馈、知道什么时候该介入什么时候该放手。反过来说，如果一个人管理能力本身就弱，给他再好的 AI 工具也用不出效果来。

第五，AI 改变的不是你做什么，而是你做事的方式。 我还是在写论文、做课件、搭网站、管笔记——做的事没变。变的是 我花多少时间在执行层面，花多少时间在思考层面。以前写一份材料，60% 的时间在打字排版，40% 在构思内容。现在反过来了，80% 的时间在想清楚要什么、怎么拆，20% 的时间在审核 AI 的产出。

这种比例的变化，日积月累下来，影响是很大的。

最后

有人可能会觉得，一个经济学教授为什么要花这么多时间折腾 AI 工具。我的回答是：这和研究方向无关，和工作效率有关。任何需要大量文本处理、项目管理、内容生产的工作，都能从这种人机协作模式里获益。

更深一层说，我觉得 理解 AI 怎么工作、怎么用好 AI，本身就是这个时代的一项基本素养。不管你是做学术、做产品还是做教育，和 AI 协作的能力会越来越决定你的产出上限。

我不觉得我的用法有多了不起——191 个会话里有 40 次不满意和 5 次沮丧呢。但这半年确实让我体会到了一种新的工作节奏：想清楚，交出去，盯结果，快纠偏。

如果你也在用 Claude Code，可以跑一次 Insights 看看自己的使用画像。也许你会像我一样，从数据里发现一些自己没意识到的使用习惯。

李学恒，中山大学岭南学院