波仔
🧡 第一章 为什么选择Claude Code
📄 一句话概括

一次任务里真正敲代码的只占一小撮，大头是找文件、读代码、跑命令、看报错、再回修——它接走的正是这些【看不见的活】。

📝 本节和前面几节的关系

上一节把它和编辑器工具区分开了，这一节拆开它干活的过程，看清它到底在替你做哪些事。

一、把一次任务拆开记账

假设交给它一件事：把项目里所有日期格式统一成 2026-10-15 这种写法。 它实际做的事是：搜出哪些文件提到日期（3 次）、打开相关的源文件读明白（6 次）、逐处改（5 次）、跑测试与格式化（2 次）、读懂输出（4 次）、按反馈回修（2 次）。 合计 22 步，其中真正改代码只有 5 步。

二、那 17 步才是真正的活

找、读、跑、看、回修——这五类动作占了近八成。 自己写过项目的人最清楚：难的不是敲，是想清楚敲哪儿、以及敲完有没有崩。 这五类动作恰好是最耗时、最琐碎、最需要耐心的部分，也最适合交出去。

三、所以它的定位是什么

它不是一个更快的打字员，而是一个愿意跑腿的搭子：你说清目标，它去把收集信息、动手修改、验证结果这一串跑完。 这也解释了为什么描述需求的能力变得比写代码的能力更重要——第 6 章整章讲这件事。 你剩下的活是：判断要做什么、检查它做得对不对。这两件事一步都省不掉。

四、动手 Demo：一次任务的 22 步动作账本

把上面那次任务的每一步按类型数出来，看大头落在哪里。

acts = [("读文件", 6), ("搜索", 3), ("改代码", 5),
        ("跑命令", 2), ("看输出", 4), ("再修改", 2)]
total = sum(n for _, n in acts)
P(u"合计 %d 步，其中真正写代码的只有 5 步，占 %.1f%%" % (total, 5 * 100.0 / total))

实跑输出：

--------------------------------------------------------------------
Claude Code 其实不是在帮你写代码
--------------------------------------------------------------------

把一次真实任务拆开记账。任务是：把全项目里的日期格式统一成 2026-10-15 这种写法。

  动作类型     次数     它到底在干什么
  ---------------------------------------------------
  读文件       6        打开相关源文件，先看懂现状
  搜索         3        全项目找哪些文件里出现了日期
  改代码       5        逐个替换并保持格式一致
  跑命令       2        执行测试与格式化工具
  看输出       4        读懂报错与测试结果
  再修改       2        按反馈回修，直到通过

合计 22 步，其中真正「写代码」的只有 5 步，占 22.7%。
其余 17 步是读、找、跑、看、回修——**干活的大头从来不是敲键盘**。
这些步骤原本每一样都要人手动做，现在被一并接走了。

输出里最关键的两个数：22 步和22.7%。写代码只占两成出头。 也就是说，如果只把 AI 当打字员用，近八成的工作量被浪费掉了。

30 秒实验

  1. 把【跑命令】和【看输出】的步数改成 0（想象一个不能执行命令的工具），它还剩下什么能力？
  2. 数一数你最近一次改代码的实际步骤，看看这个 22 步的比例是否接近。

常见误区

  1. 只把它当【更快的自动补全】。补全只做写这一步，剩下的找读跑验它一样不干。
  2. 以为可以完全撒手。判断做什么、检查对不对这两件事永远是你的。
自测三问（点开对答案） 1. 一次任务里，敲代码大约占多少比例？ —— 约两成出头（示例中 5/22 约 22.7%），大头是找、读、跑、看、回修。 2. 哪五类动作最适合交出去？ —— 搜索、读文件、跑命令、看输出、按反馈回修——耗时琐碎又需要耐心。 3. 为什么描述需求的能力变得更值钱了？ —— 因为它接走的是执行链，你留下的恰恰是把目标说清楚、以及在结果上做判断。

相关笔记