一、八个坑，按代价从大到小

没写 SPEC 就开工（改了三遍需求）、一次交整块功能（跑完不知道哪错）、 没有假数据（最后才发现流程跑不通）、没有回退手段（改坏了只能重写）——这四个是【大】。 拿真数据调试（一次报错就泄底）、界面做太早、每周用的活不检查——这三个是【中】。 没记账（不知道哪步最花时间）——这个是【小】。

二、前四个坑的共同点

都能在动手前用一句话避免。 写一句 SPEC、把活切小、准备假数据、装上版本管理——每一件都是开工前的五分钟。 所以这一节真正要记的不是这八条坑，是那个共同点：先想清楚，再动手。

三、为什么【没记账】虽然小却值得提

因为记账会让你看见自己的时间花在哪。 大多数人以为自己时间花在写代码上，实际往往花在【来回改需求】和【找东西】上。 看见之后才知道该改进哪一步——这是唯一一条能持续改进的机制。

四、怎么用这一节

把前四条抄进规则文件——它们是开工前的检查项。 剩下四条记在备忘录里——它们是过程中的提醒。 两类位置不同：开工前该看的和过程中该看的，不能放一起。

五、动手 Demo：我踩过的坑，你别再踩

下面把八个坑按代价排序，并标出严重程度。

pits = [(u"没写 SPEC 就开工", u"改了三遍需求", u"大"),
        (u"一次交整块功能", u"跑完了不知道哪错了", u"大"),
        (u"没有假数据", u"最后才发现流程跑不通", u"大"),
        (u"没有回退手段", u"改坏了只能重写", u"大")]

实跑输出：

--------------------------------------------------------------------
我踩过的坑，你别再踩
--------------------------------------------------------------------

本章最实用的一节。八个坑，按代价从大到小排：

  坑                   代价                       严重程度
  ---------------------------------------------------------
  没写 SPEC 就开工     改了三遍需求               大
  一次交整块功能       跑完了不知道哪错了         大
  没有假数据           到最后才发现流程跑不通     大
  没有回退手段         改坏了只能重写             大
  拿真数据调试         一次报错就泄了底           中
  界面做太早           核心还没跑通就装修门面     中
  每周用的活不检查     小错重复一百次             中
  没记账               不知道哪步最花时间         小

前四个都是【大】——它们有一个共同点：**都能在动手前用一句话避免。**
所以这一节真正要记的不是这八条坑，是那个共同点：**先想清楚，再动手。**

前四个都是【大】——而它们有一个共同点：都能在动手前用一句话避免。 所以这一节真正要记的不是这八条坑，是那句：先想清楚，再动手。

30 秒实验

1. 把前四个坑抄进规则文件——它们是开工前的检查项。
2. 从这周起记一次账：今天的时间花在哪儿了？这是唯一能持续改进的机制。

常见误区

1. 把这些坑当成别人的事。它们不是能力问题，是顺序问题——改顺序就行。
2. 把八条坑一起贴在一个地方。开工前该看的和过程中该看的，要分开。

• ☐ 下一节（9.11 本章练习）

相关笔记

• 🐳 DeepSeek Harness技术架构原理 · 索引 — 踩坑与复盘的系统方法
• 🧡 Claude Code橙皮书 · 索引