波仔
🧡 第四章 核心工作模式：把Claude Code变成真正的【生产力工具】
📄 一句话概括

先要计划、点头再动手；计划的价值不在完美，在于它是行文字——读错一行改一行，比回退一堆落盘的改动便宜得多。

📝 本节和前面几节的关系

第三章末尾预告过这一招，这里展开：这一章讲的都是【怎么用】，而这一节是最该先掌握的那一招。

一、两种顺序，代价差在哪

先讨论：它出计划 → 你点头 → 它执行。出问题时，你要重来的是那份计划。 直接开工：它做完你才发现不对 → 要重来的是已经落盘的全部改动。 同样的错误，在计划里改一行，在文件里改一片。这就是这一模式的全部意义。

二、一份典型计划长什么样

五步左右，每步都能单独判断对错：确认要改的文件清单、先补一个能失败的测试、改一处跑一次测试、全过了再整理格式、你自己复看一遍改动。 注意第二步——先让它写一个会失败的测试。这是把【做完怎么算对】变成代码的最直接办法。

三、计划要你自己过一眼

计划不是批件，是你要负责看的东西。你点头的那一刻，是在为它的方向背书。 看的时候重点问三句：有没有动我说了不要动的地方？有没有漏掉我说了要做的？做完怎么验？ 三句都没问题，再放行。

四、动手 Demo：先讨论再执行——两种顺序的代价

下面把两种做法并排放，再给出一份典型计划。

TH([u"做法", u"流程", u"出问题时你要重来的东西"], [12, 28, 28])
T([u"先讨论", u"出计划 -> 你点头 -> 执行", u"计划（通常 3 到 5 行）"], [12, 28, 28])
T([u"直接开工", u"开口就做 -> 做完才发现不对", u"已经落盘的全部改动"], [12, 28, 28])

实跑输出：

--------------------------------------------------------------------
先讨论再执行——两种顺序的代价
--------------------------------------------------------------------

同一件活，两种做法。用步骤数算一下改一次的代价：

  做法         流程                           出问题时你要重来的东西
  -------------------------------------------------------------------
  先讨论       出计划 -> 你点头 -> 执行       计划（通常 3 到 5 行）
  直接开工     开口就做 -> 做完才发现不对     已经落盘的全部改动

一份典型计划长这样：
    1. 确认要改的文件清单
    2. 先补一个能失败的测试
    3. 改一处、跑一次测试
    4. 全部通过后再回头整理格式
    5. 你自己复看一遍 diff

关键不在计划有多完美，而在**它是行文字**——读错一行，改一行的成本远低于回退一堆文件。

第三列就是这一节的全部：出错时重来的是一行字，还是一堆文件。 计划第二步【先补一个会失败的测试】，是把验收标准写进代码的最直接办法。

30 秒实验

  1. 下一件事就先用这一招：让它出计划，你看完再放行——记录一下你改了几处计划。
  2. 比较一下：先看计划花的时间，和省下的返工时间，差多少。

常见误区

  1. 把计划当形式，直接回一句【可以】。那就要真的看——三句必问：有没有动不要动的？有没有漏要做的？怎么验？
  2. 嫌它出计划啰嗦，自己写一个敷衍的。计划的价值在于它列全了步骤，敷衍的计划等于没有。
自测三问（点开对答案） 1. 先讨论再执行省下的是什么？ —— 出错时重来的是那份计划（一行字），而不是已经落盘的一堆改动。 2. 典型计划的第二步为什么是先写一个失败的测试？ —— 因为它把【做完怎么算对】直接变成了可执行的代码。 3. 你点头的那一刻在做什么？ —— 在为它的方向背书，所以要看三句：有没有动不要动的、漏没漏要做的、怎么验。

相关笔记